<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Is it really that big a deal?<br>
    <br>
    I think the negatives outweigh the positives in the changes implied
    here. Say what you want about the priciples about the instruction
    sets(ARM and Thumb2), but they still share 95% of the backend code.<br>
    <br>
    When you're dealing with lowlevel targets like embedded arm you'll
    still need to know the RTL code pretty well. The build system isn't
    really very complex either. I personally see no reason to change the
    way it is<br>
    <br>
    Den 23-08-2011 16:01, John Clymer skrev:
    <blockquote
      cite="mid:1314108070.52118.YahooMailRC@web1116.biz.mail.sk1.yahoo.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <style type="text/css"><!-- DIV {margin:0px;} --></style>
      <div style="font-family:times new roman,new
        york,times,serif;font-size:12pt">
        <div>Digging some more around it today, came up with the
          following idea...<br>
          <br>
          In the rtl/embedded folder - there is the "system" file for
          "ARM" - it is ALL pascal - and compiles to either of Thumb2 or
          ARMV4 - but not both.<br>
          <br>
          In that folder's Makefile.fpc, the units to be built are
          listed - the could be switched to listing directories to get
          built.<br>
          <br>
          One folder for ARMV4, one for Thumb2.  A "system" file and
          rtl.cfg file sits in each folder.  The "system" file just
          bounces back down and includes the current system files from
          the rtl/embedded folder, but the library gets built in the
          core specific folder.<br>
          <br>
          That's the easy part, the more difficult part will to be to
          get the compiler to choose the correct system file.  That is,
          the "usual" ARM folder where the libraries sit would need to
          have the same 2 seperate subdirectorie, the compiler would
          have to choose which one based on the core it's currently
          compiling for.<br>
          <br>
          John<br>
        </div>
        <div style="font-family:times new roman, new york, times,
          serif;font-size:12pt"><br>
          <div style="font-family:arial, helvetica,
            sans-serif;font-size:10pt"><font face="Tahoma" size="2">
              <hr size="1"><b><span style="font-weight: bold;">From:</span></b>
              David Welch <a class="moz-txt-link-rfc2396E" href="mailto:dwelch@dwelch.com"><dwelch@dwelch.com></a><br>
              <b><span style="font-weight: bold;">To:</span></b> FPC
              developers' list <a class="moz-txt-link-rfc2396E" href="mailto:fpc-devel@lists.freepascal.org"><fpc-devel@lists.freepascal.org></a><br>
              <b><span style="font-weight: bold;">Sent:</span></b> Tue,
              August 23, 2011 10:39:50 AM<br>
              <b><span style="font-weight: bold;">Subject:</span></b>
              Re: [fpc-devel] ARM vs Thumb2 - can't have both<br>
            </font><br>
            <br>
            Most if not all of my references to thumb meant the original
            ARMv4T thumb instruction set, definitely not the thumb2
            extensions, nor ARMv5 or ARMv6 extensions.<br>
            <br>
            If for example you had a thumb backend to fpc, you could
            easily solve this problem, all of these libraries would run
            on both platforms, one compiler, one set of libraries,
            compiled one time.<br>
            <br>
            There is no thumb backend at the moment, this is the first
            problem to that solution.<br>
            <br>
            I figure most folks would not want to sink to the lowest
            common denominator.<br>
            <br>
            I would then recommend splitting the arm/arm7/ARMv4
            architecture from the cortex-m3/ARMv7m, as implemented now
            they are two incompatible instruction sets.  One instruction
            set happens to share the name of the company, move beyond
            that sticking point and create two architectures.<br>
            <br>
            The third alternative is do what others do and build two
            sets of libraries, one for each cpu type if that is the
            preferred term to distinguish arm and thumb2.  Even if they
            are in the same library file but by name the linker extracts
            the arm cpu whatsit function from the thumb2 cpu whatsit
            function it is still two compilations of the whatsit
            function.<br>
            <br>
            You really have to pick one of those solutions, same
            instruction set or compile the libraries twice either as two
            arches build one or the other but not both, or two cpus
            within an arch and both/all cpus for an arch get built when
            the arch compiler is built.<br>
            <br>
            David<br>
            <br>
            On 08/22/2011 01:15 AM, John Clymer wrote:<br>
            > Yes, all my references of Thumb meant Thumb2.<br>
            > <br>
            <br>
            _______________________________________________<br>
            fpc-devel maillist  -  <a moz-do-not-send="true"
              ymailto="mailto:fpc-devel@lists.freepascal.org"
              href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
            <span><a moz-do-not-send="true" target="_blank"
                href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a></span><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>