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

John Clymer john at johnclymer.net
Mon Aug 22 04:36:38 CEST 2011

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 

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. 


From: David Welch <dwelch at dwelch.com>
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Sent: Mon, August 22, 2011 6:00:29 AM
Subject: Re: [fpc-devel] ARM vs Thumb2 - can't have both

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


0x00000:  b _pre_start

    ldr r0,_start
    bx r0

0x0000:  _stac_top
0x0004:  .word _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

    .globl _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.

On 08/21/2011 05:58 PM, John Clymer wrote:
> 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
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel

fpc-devel maillist  -  fpc-devel at lists.freepascal.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110821/f785bbf5/attachment.html>

More information about the fpc-devel mailing list