[gccsdk] VFP in GCC 4.1.2

Jeffrey Lee me at phlamethrower.co.uk
Sun Nov 28 11:36:19 PST 2010


Yesterday I had a "quick" go at getting VFP working in GCC 4.1.2. Luckily, 
it looks like only a couple of simple changes are required in order to 
allow GCC to use VFP (details at end of message). However, for the
resulting binaries to be usable (or to even link correctly), several 
things still need to happen:

* We need to sort out the ABI. "Luckily" GCC 4.1 doesn't support using the 
hard-float ABI with VFP, so the only sensible option is to go with the 
softfp ABI. Since the softfp & softfloat ABIs use the same calling 
conventions, that means that we shouldn't have any extra work to do beyond 
removing the two lines of code that are curently preventing softfp from 
being selected.

* Now that we've sorted out the ABI, we need to sort out the libraries. 
Unfortunately, although the docs suggest that it should be possible to 
link softfp code with softfloat code, this doesn't seem to be the case, as 
the linker complains when I try linking a VFP'd object file to unixlib. I 
have a feeling that this could be down to the difference in how doubles 
are stored (FPA uses big endian word order, VFP uses little endian), but
I haven't fully looked into it yet. So before I dive too deep into GCC's
source, does anyone here know what word order our current softfloat
library uses?

* But irrespective of the answer to the above question, we'd probably want 
to compile a VFP version of unixlib anyway. Apart from the obvious speed
gains from using VFP for any float operations, we may also get speed gains
elsewhere since we'd be able to change the minimum CPU architecture from
ARMv3 to something more recent like v6. So with that in mind, can anyone 
give me some pointers on how to set up an extra unixlib configuration?

* And last but not least, we need to add code to the runtime 
library/libraries to talk to the VFPSupport module. Currently when 
programs start they aren't given any access to the VFP/NEON coprocessor, 
and only by talking to VFPSupport will they be given access. VFPSupport
also handles context switching, so the pthreads code will also need
modifying to set up per-thread register contexts with VFPSupport and to
ask for the contexts to be switched on thread changes. cmunge will also
need modifications so that VFP contexts are created/destroyed inside SWI 
handlers, callbacks, etc. Admittedly you could write your own code to 
perform context switching for pthreads, but I don't think there'll be any 
significant advantages compared to using VFPSupport directly (especially
if/when we have to start dealing with VFP variants which can throw
exceptions). For more information about the VFPSupport module, there's a
SWI spec on the ROOL wiki [1] and a forum thread too [2]. Feedback on the
API/implementation is of course welcome!

Since I wrote the VFPSupport module, and I'm quite eager to get VFP/NEON 
working, and have the right hardware to test everything with, I'm more 
than willing to do the work necessary to integrate VFPSupport with all the
appropriate runtime bits and pieces. But for the other bits (i.e. setting 
up a new unixlib configuration) I'd appreciate it if anyone could give me 
a few pointers on where to start.


- Jeffrey

[1] https://www.riscosopen.org/wiki/documentation/pages/VFPSupport
[2] https://www.riscosopen.org/forum/forums/3/topics/401


GCC changes to get VFP working:

* /gcc4/srcdir/gcc/gcc/config/arm/arm.c:

In arm_override_options(), get rid of these two lines (around line 1267):

   if (arm_float_abi == ARM_FLOAT_ABI_SOFTFP)
     sorry ("arm-unknown-riscos and -mfloat-abi=softfp");

* /gcc4/srcdir/gcc/gcc/config/arm/riscos-elf.h:

The bit that picks a default -mfpu value is broken. The line should be 
changed from this:

"%{!mfpu:%{mhard-float|mfloat-abi=hard:-mfpu=fpa; :-mfpu=softfpa}}" \

to this:

"%{!mfpu=*:%{mhard-float|mfloat-abi=hard:-mfpu=fpa; :-mfpu=softfpa}}" \

With those two changes, you should be able to compile (but not link!) by 
using "-mfpu=vfp -mfloat-abi=softfp -march=armv6". Hacking the linker 
to get rid of the error message will allow you to link against the 
softfloat libraries, but since I haven't actually tried running any code 
yet I can't guarantee whether there'll be any knock-on effects or not.

More information about the gcc mailing list