[fpc-devel] ARM vs Thumb2 - can't have both

John Clymer john at johnclymer.net
Tue Aug 23 18:10:08 CEST 2011


The only major issue is if you want to build for Thumb2 - you have to manually 
edit makefiles - because the full ARM cores support and startup files will choke 
the build process.

i.e. Building for Thumb2 with the freshly checked out subversion, when the 
compiler gets to compiling rtl/embedded/arm/lpc21x4.pp - it will choke because 
there are non-Thumb2 instructions in the boot code.

I just submitted a potential patch to the mailing list to switch the controllers 
arrays to structures - part of that patch has ifdef's in the controller files 
lpc21x4's and at91sam7x256's - so that when compiling for Thumb2 - the boot code 
for those controllers gets bypassed.

However, part of the confusion is that if you want Thumb2 RTL's - you have to 
append an extra option to Make process - otherwise, the RTL will compile - but 
it will choke on real hardware.

There has been discussion on how the RTL should include every register for every 
machine - to make the user's life "easier."  Yet - how easy is it to switch from 
Thumb2 to ARMV4 chips with the current setup ?  In order to do that now, you 
need two different RTL's - via either separate compiles of the compiler - or 
different CFG files in the project directory (pointing to different system 
libraries).

If we are looking to save the user time by defining every peripheral register - 
why not save them time by not having to become a compiler expert ?

Again, these are my (sometimes random) thoughts on trying to make things easier 
for the end user.  someone that wants to write controller code - not fitz with 
the compiler.

That said, school is starting - and I have a working compiler - so I am just as 
content to leave the status quo be...

John





________________________________
From: Jeppe Græsdal Johansen <jjohan07 at student.aau.dk>
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Sent: Tue, August 23, 2011 7:42:51 PM
Subject: Re: [fpc-devel] ARM vs Thumb2 - can't have both

 Is it really that big a deal?

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.

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

Den 23-08-2011 16:01, John Clymer skrev: 
Digging some more around it today, came up with the           following idea...
>
>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.
>
>In that folder's Makefile.fpc, the units to be built are           listed - the 
>could be switched to listing directories to get           built.
>
>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.
>
>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.
>
>John
>
>
>
>
________________________________
From: David Welch <dwelch at dwelch.com>
>To: FPC               developers' list <fpc-devel at lists.freepascal.org>
>Sent: Tue,               August 23, 2011 10:39:50 AM
>Subject: Re: [fpc-devel] ARM vs Thumb2 - can't have both
>
>
>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.
>
>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.
>
>There is no thumb backend at the moment, this is the first             problem 
>to that solution.
>
>I figure most folks would not want to sink to the lowest             common 
>denominator.
>
>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.
>
>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.
>
>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.
>
>David
>
>On 08/22/2011 01:15 AM, John Clymer wrote:
>> Yes, all my references of Thumb meant Thumb2.
>> 
>
>_______________________________________________
>fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110823/a5ca029c/attachment.html>


More information about the fpc-devel mailing list