On 12/16/2015 10:13 AM, Jonas Maebe wrote:
Anthony Walter wrote:
Because these devices have a fairly large amount of memory I have been
using ARM instruction set (-CIARM option) to simplify the assembler code
required for the low level interfaces, however early on I noticed that
if I specify the options -CpARMV7A (or -CpARMV6) and –CIARM I end up
with code that doesn’t work.
I traced the problem to the use of BLX <Label> instructions which
according to the ARM documentation seem to always causes an
unconditional change to Thumb state. If I remove the
CPUARM_HAS_BLX_LABEL capability and rebuild the compiler the code
produced uses only BL <Label> and always works correctly. There seems to
be no problem with BLX <Register> or BX <Register> instructions which
use bit[0] of the register to determine the target state.
The compiler and assembler mark which code is ARM and which is Thumb.
Normally, when the linker processes the object files, it will replace
the blx instructions with bl if they go from ARM to ARM or from Thumb
to Thumb. The reason that a compiler/assembler cannot do this, is that
the target of a call may be in another object file and the
compiler/assembler cannot know whether this object file has been
compiled in ARM or Thumb mode.
Are you not processing the generated code with a linker at all?
Jonas
Just adding to Jonas's answer here.
While it's true that BLX always changes instructions set, I've heard
some reports indicating that some assembler/linker combinations on OSX
(apparently clang based?) have been behaving strangely with this lately.
GCC+binutils have always been following the "emit blx and let the linker
fix it" recipe, just as fpc does.
Best Regards,
Jeppe
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel