Been playing with the ARM / Thumb2 part - specifically for the Thumb2 line-up.

The compiler proper can be built to switch between the two with a command line switch. However, the RTL gets called as <ARCH>-<SYSTEM>, this only allows the RTL to compiled for one or the other.

This may be by design - in which case there should be a big BOLD note added to the Arm port page. Or it may be unintentional - in which case it should be switched to <ARCH>-<CPU>-<SYSTEM> OR Thumb2 should get rolled out as a separate <ARCH>.

Not sure I will have time to get into changing <ARCH>, but if there is a [somewhat] easy fix to add <CPU> to the RTL path for architectures that support it, I may have time to dig into that.

John

except for a few older ARM's both platforms support thumb code, so anything that is shared could be compiled for thumb with some target specific trampolines to get there

ARM:

0x00000: b _pre_start
...

_pre_start:
ldr r0,_start
bx r0
.pool

cortex-m3:
0x0000: _stac_top
0x0004: .word _start

.thumb_func
_start:
limit to thumb instructions (no thumb2)

same works for interrupts as well...

If everything is written in an thumb interwork fashion then you can jump around from target specific block to target specific block, PASCALMAIN can be arm for the arm target and thumb2 for the cortex-m3 target for example and it all works.

BTW if you add .thumb_func

.thumb_func
.globl _start
.text
_start:

you dont have to do this:
.long _start+1
you can do this instead:
.long _start

at least for gnu as, not sure if this code is targeted at different assemblers.

Yes, I'm somewhat familiar with mixing Thumb and Arm in C.

However, I believe the intent is to target FPC for the newbie market (that's what I'm getting from wanting all the hardware peripheral registers installed in the controller unit file...) A newbie is NOT going to have any luck intermixing the two.

That also doesn't solve the problem of the SYSTEM unit. As the compiler is laid out now - the system unit sits in a directory of the name <ARCH>-<SYSTEM>. So, to support BOTH ARM and THUMB (i.e. Cortex and native ARM7TDMI) SYSTEM files, 2 different builds are needed. However - they can't both sit in the same directory (not with the current setup of Makefiles and code.)

I've seen where the compiler inserts the system unit and controller units, so supporting both would only be a few lines of code there. I've also seen when running the compiler in verbose mode (-Va) that the -Cp processor switch is getting defined to a constant - so one could possibly massage the makefiles into supporting <ARCH>-<CPUTYPE>-<SYSTEM> directories to seperate the two system units.

Otherwise, one has the following problem:
1) building for ARM - all the controllerunits compile (because the assembler can assemble the thumb startup code into arm startup code). However, when one builds a program with the resulting SYSTEM and controllerunit file, the startup will be in ARM mode and cause the program not to run.)
2) building in THUMB - the ARM startup code in the lpc and sam7 controllerunit files fail to build - as they have ARM specific assembly code in them.

However, if you are claiming that an ARM binary can be linked against a THUMB SYSTEM unit, then only the startup code remains to get fixed - and things aren't as messy as I'm perceiving them.

John

________________________________

All I am saying is thumb (not thumb2) is common between many ARM cores and the cortex-m3. These lpc21xx parts use an ARM7TDMI which is an ARMv4T and supports thumb. the lpc2000 are also ARM7TDMI's and LPC1000 is cortex-m0 which is the successor to cortex-m3 so no doubt it is thumb/thumb2 based as well. All of the ARM based microcontrollers I know of (have used) str7, stm32, lpc2000, lpc1000, stellaris, sam7 (at91sam7) support thumb instructions (if you limit yourself to the original ARMv4T supported instructions). the sam9 and str9 both appear to be ARMv5T based so they support thumb as well.

So long as all code modules use a "thumb interwork" as folks like to call it interface, then dules like PASCALMAIN can be compiled for arm, thumb or thumb2 and be called and return to arm, thumb or thumb2 code, mix and the exception table or vector table at address zero has to be different for ARM7 vs cortex-m, no way to work around that. If that is the root of the problem and that code wants to move out of the target specific rtl (stellaris.pp, lpc21x4.pp, etc) then, yeah, there is a big problem.

If the exception and vector tables can be custom to the target as they are now (stellaris.pp, lpc21x4.pp, etc) then you could do a couple of things.

One would be the interwork thing. The arm startup code, within the target specific rtl would have to do a two step to get from arm mode to thumb/interwork mode. The arm cores traditionally handles exceptions in arm mode. What I described in the prior email but not necessarily exactly like that. Any shared code between the ARM and cortex-m would be strictly thumb (limited to ARMv4T ideally). Any instructions like mrs/msr that thumb is lacking would want to be calls to arm code in the target specific startup area. The cortex-m vector table could simply point directly at the thumb mode shared code (and have matching named functions for mrs/msr and other instructions)

The second solution, would be to use the lowest common denominator, everything except the exception/vector tables, and some architecture specific stuff (like any need for mrs/msr calls) be compiled for thumb (limited to ARMv4T). Unfortunately there is no thumb backend.

With the second solution the compiler could be compiled one time, one way and so far all the targets are supported by that one compiler.

I guess a third solution would be to treat the cortex-m3 as a completely different architecture, in the same way that the avr is a separate target (looks like there is at least a directory for the avr, but the code is arm so a work in progress). I would be super happy to see an msp430 target in there as well but that is another story. From what you were talking about <ARCH><SYSTEM> becoming <ARCH><CPUTYPE><SYSTEM>, cortex-m could be a separate <ARCH> instead of being part of the ARM architecture and <ARCH><SYSTEM> would work.

Sorry for being dense, I am a newbie here so dont know enough about the detail to know where the problem is. I still have not gotten past the problem I had trying to get that startup code to build right for the cortex-m3. Lots of arm experience, almost no fpc experience.

I assume what you are calling a thumb system is the cortex-m3 based systems, you you cannot have arm code there. I assume the <ARCH> is for now ARM (the company not the instruction set). And <SYSTEM> is either ARM (the instruction set) or thumb2/cortex-m3? Am I understanding that so far? Or is <ARCH> ARM or cortex-m3 and <SYSTEM> is stellaris, lpc21x4, etc?

David

Yes, all my references of Thumb meant Thumb2.

The problem is not building the compiler - the compiler works correctly supporting Thumb2 and ARM.

The problems is building the libraries. Doing a standard build process, the compile chain gets into the rtl/embedded folder. It makes one pass through and compiles the SYSTEM unit. This gets built in whatever mode the crosscompiler has been told to be in. It defaults to ARM code, unless told to Thumb2 code (via a CROSSOPT=-Cpcortexm3 on the MAKE command line - or via an override in the RTL.CFG file in the embedded folder.)

Now, if it's in Thumb2 mode - it compiles the STM32 and STELLARIS unit files fine, and makes a Thumb2 SYSTEM ppu. But, then it chokes on compiling the ARM controller unit files.

BUT - if it's in ARM mode, it will compile everything, including the start-up routines for the Thumb2 parts - in full blown ARM mode. This will make the compiler finish it's job. BUT attempting to run anything on a M3 device will fail - as the M3 can NOT run ARM code.

So, in order to get a working setup for an M3 device, one needs to manually remove the ARM controller files from the makefile, then re-build with -Cpcortexm3 in the RTL.CFG file in the embedded folder (or it could be added to the Makefile) - OR the make "clean buildbase installbase" line needs to have a CROSSOPT=-Cpcortexm3 added. Otherwise the system and startup files end up being ARM files.

<ARCH> is ARM - but that is NOT the code generation, that is strictly because the company's name is ARM.
<SYSTEM> is "embedded" - as that's what I'm building <CPUTYPE> (not referenced in any build files) is either ARM (for ARMV3-V5) OR Thumb2 (for Cortex M3 OR armv7m)

Again, the compiler builds just fine - it's the RTL that has the issue. If you are having troubles building for Cortex, the magic that I'm using to make it work is:

make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm CROSSBINDIR=/home/stimey/CodeSourcery/bin BINUTILSPREFIX=arm-none-eabi- CROSSOPT=-Cpcortexm3 INSTALL_PREFIX=/home/stimey/fpc

The CROSSOPT item forces the RTL to be compiled as M3 / Thumb2.

John

________________________________

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

John Clymer wrote

Yes, all my references of Thumb meant Thumb2.

David Welch wrote

I figure most folks would not want to sink to the lowest common denominator.

I feel that M3 and friends might be worth investing in thumb support for "embedded" devices. But I understand that the more relevant targets for ARM-FPC seem to be Smartphones, Tablet PCs, mini-Servers and upcoming high performance cortex A15 Servers. Her I feel that thumb does not make much sense, while most legacy ARM hardware does not _need_ thumb based software, even it would be able to run it.

Just my version of the rule of thumb. :)

-Michael

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

________________________________

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

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

________________________________