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

[David Welch]

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
>