[gccsdk] VFP in GCC 4.1.2
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  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) ?
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!
More information about the gcc