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 match at will.
Obviously 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 On 08/21/2011 10:36 PM, John Clymer wrote:
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
_______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
