[gccsdk] VFP in GCC 4.1.2
John.Tytgat at aaug.net
Mon Nov 29 14:03:54 PST 2010
In message <Pine.WNT.4.62.1011281808010.2664 at c203>
Jeffrey Lee <me at phlamethrower.co.uk> wrote:
> * 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.
I'm not really convinced any VFP work is best spend on the GCC 4.1 branch.
There are significant improvements done in GCC 4.5/4.6 concerning VFP and
going for a softfp ABI is probably going to be suboptimal as well (poor
scheduling, bugs etc).
IMHO we should go for AAPCS/EABI flavour so that any RISC OS specific
changes to GCC/Clang/binutils/gdb are as minimal as possible and try to
follow the latest GCC/Clang/binutils developments. Hence next port
should be GCC 4.6.x. Again, IMHO.
I've done some groundwork for such GCC 4.6 AAPCS/EABI tryout based on
UnixLib (also had a go with Clang) and IMHO it is very viable option
(initial testing programs were all working). There is still some
development work to be done and perhaps more importantly serious testing.
No idea when a first release could be done, it all depends on the
developers dedicated to help out and the problems found on the way.
Cfr. gccsdk/branches/developers/joty/gcc 's STATUS-BRANCH for a fairly
up-to-date status of this work.
> * 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?
You need a multilib flavour built for UnixLib with the settings you
want to have. Currently we have as multilibs:
- soft-float, UnixLib
- hard-float, application, SCL
- hard-float, module, SCL
Not so long ago I added some basic VFP support in UnixLib but we're not
> * 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?
Cfr. our build Makefile GCC_BUILD_FLAGS.
> * 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  and a forum thread too . 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.
I need to catch up on this as I'm not intimate familiar with all ins and
outs of VFP but I'm wondering why UnixLib would need VFPSupport ? Why
not simply have a couple of VFP instructions in UnixLib itself in its
setjmp/longjump and pthread implementation (and this only for UnixLib
multilib configuration built for VFP usage) ?
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc