First a bit of background, on arm ebi gcc has three options for "-mfloat-abi"

soft: do all floating point in software, ignore the fpu type selection softfp: use the selected fpu type but use the same calling conventions as "soft" (that is parameters are passed using integer registers). This gives binary compatibility with soft float code but in the case of vfp it comes at a substantial performance cost as all parameters must be moved between fpu and integer registers which causes pipeline stalls hard: use the selected fpu type and use fpu type specific calling conventions.

Debian is in the process of introducing a new port called "armhf" which uses -mfloat-abi=hard with VFP (which seems to be become the dominant FPU now).

Afaict from quick tests freepascal does support vfp but based on my tests always uses the "soft" calling convention. So it won't link correctly with C code that uses floating point parameters on debian armhf.

1: can someone who knows the fpc arm code confirm the above statement? 2: does anyone have any idea what it would take to add support for the eabi vfp calling convention and for building fpc binaries that use it by default (just as armel FPC binaries use eabi by default) 3: does anyone have any plans to actually do so (I might attempt it but i'm not a compiler developer nor am I an arm assembly programmer, just someone who uses both freepascal and debian on an arm system that could benefit from armhf)

peter green wrote

Afaict from quick tests freepascal does support vfp but based on my tests always uses the "soft" calling convention. So it won't link correctly with C code that uses floating point parameters on debian armhf. 1: can someone who knows the fpc arm code confirm the above statement?

FPC indeed only supports the soft and softfp conventions.

2: does anyone have any idea what it would take to add support for the eabi vfp calling convention and for building fpc binaries that use it by default (just as armel FPC binaries use eabi by default)

Someone has to implement support for that calling convention in compiler/arm/cpupara.pas. Maybe some assembler code in the RTL also has to be modified.

3: does anyone have any plans to actually do so

Not me.

Jonas

+++ peter green [2011-09-06 02:05 +0100]:

I have no idea about the internals of pascal, but you have understood the variants correctly, and the reference doc for this stuff is here (I believe that's a freely accessible doc):
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

section 5 tells you about the calling conventions, and section 6 about the normal variants (note the bit about it applying only to non-variadic functions - does pascal support variadic functions?)

The things to bear in mind when considering the change from armel to armhf are as follows:

1) The calling convention change: you can use FP registers instead of integer registers

2) The extra functionality available: a VFP unit with 31 single precision or 16 double precision registers. Note that newer hardware will have twice as many registers, but that doesn't affect the calling convention. In debian armhf (and Ubuntu armhf, and hopefully everyone else shipping arm binary distros) we've picked the VFP3d16 hardware variant as a baseline to build for. Obviously it is useful to people who build their own code if the compiler supports the d32 hardware variants too, but that won't be used in distro-built binaries.

3) Some other things change that might catch you out: a) Thumb interworking needs to be supported, which has requirements on state between function calls (any function can be thumb or not-thumb). b) The SWP instruction is gone. It may fault, it may get fixed up by the kernel (slowly), but it shouldn't be used anymore (it's not compatible with mutli-core designs, Load/store exclusive should be used instead).

Hopefully that's helpful to anyone

Wookey wrote

section 5 tells you about the calling conventions, and section 6 about the normal variants (note the bit about it applying only to non-variadic functions - does pascal support variadic functions?)

It does, in two ways:
a) calling variadic functions implemented in C (-> uses the variadic calling convention from the ABI)
b) it's own variant, which uses a non-variadic calling convention from the ABI (the variadic part there is implemented via an array that is constructed on the caller side)

We already support both (with the softfp calling convention).

3) Some other things change that might catch you out: a) Thumb interworking needs to be supported, which has requirements on state between function calls (any function can be thumb or not-thumb).

If that only means that you have to use b(l)x everywhere, we already support that (only in svn trunk though).

b) The SWP instruction is gone. It may fault, it may get fixed up by the kernel (slowly), but it shouldn't be used anymore (it's not compatible with mutli-core designs, Load/store exclusive should be used instead).

swp is currently replaced with ldrex/strex in the run time library in you target ARMv6 or above.

Hopefully that's helpful to anyone , and nice to see you again in a completely different setting :)

Jonas

For linux systems where you can't use ldrex unconditionally you should be using the __kuser_cmpxchg helper. See linux
Documentation/arm/kernel_user_helpers.txt

This should still give a fairly efficient implementation on later cores.

Paul