[gccsdk] VFP in GCC 4.1.2

Jeffrey Lee me at phlamethrower.co.uk
Mon Nov 29 15:44:26 PST 2010

On Mon, 29 Nov 2010, John Tytgat wrote:

> In message <Pine.WNT.4.62.1011281808010.2664 at c203>
>          Jeffrey Lee <me at phlamethrower.co.uk> wrote:
>> * 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.
> 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) ?

There are a few reasons why you might want/need to use VFPSupport:

* At the moment, VFP/NEON access is disabled by default. And the correct 
way to enable access is to talk to the VFPSupport module and set up at 
least one 'context' (i.e. register save area). The main reasoning behind 
this is that by forcing programs to talk to the VFPSupport module, it 
allows us to have one centralised piece of code for checking whether the 
hardware features that a program requires are actually available (Although 
GCC is likely to produce fairly vanilla VFP/NEON code, there are 10+ 
different VFP/NEON variants, and most likely there'll be more introduced 
in the future). Of course if you feel that having VFP/NEON access disabled 
by default is a bad thing to do, feel free to plead your case on the ROOL 

* The VFPSupport module supports lazy context switching, which could be 
useful for boosting performance in some situations. But the operative word 
here is "could", so there may or may not be any downside to implementing 
your own context switching code.

* If the VFP hardware in use is capable of generating asynchronous 
exceptions, then extra, implementation-defined registers need to be saved 
and restored, otherwise the pending exception will fire in the middle of 
your context switch code. This could make it tricky for unixlib to 
properly deal with the exception. VFPSupport will obviously know how to
switch the context without triggering any exceptions.

* VFPSupport provides a 'fast' API which allows you to call the context
switching code directly instead of via a SWI. So there'll only be a 
small overhead compared to implementing the context switching yourself. 
Unfortunately the code does require the processor to be in a privileged 
mode, so if you need bleeding fast context switching from user mode then 
implementing it yourself is the only option. Note also that the only way 
of switching context without triggering a pending exception is to do it 
from a privileged mode (since you need access to the FPEXC register). In 
fact if you're in user mode, you can't even check whether an exception is 
pending, so there's no possibility of implementing context switching code 
that stays in user mode unless absolutely necessary.

I hope that makes things a bit clearer!


- Jeffrey

More information about the gcc mailing list