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
________________________________
From: David Welch <dwe...@dwelch.com>
To: FPC developers' list <fpc-devel@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
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.
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@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
