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 <[email protected]>
*To:* FPC developers' list <[email protected]>
*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 - [email protected]
<mailto:[email protected]>
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
