[gccsdk] VFP in GCC 4.6

Jeffrey Lee me at phlamethrower.co.uk
Sat Mar 5 08:57:11 PST 2011

On Tue, 1 Mar 2011, John Tytgat wrote:

> [ Apologies for the delay, I got an aaug.net mail outage around the
> time of this discussion. ]
> In message <Pine.WNT.4.62.1102172020290.3168 at c203>
>          Jeffrey Lee <me at phlamethrower.co.uk> wrote:
>> On Thu, 17 Feb 2011, John Tytgat wrote:
>>> I'm still unclear why precisely UnixLib needs to call VFPSupport SWIs
>>> and why it can't just save/restore/initialise the VFP state itself
>>> if necessary (based on the VPP flavour used to compile it).
>> Unixlib could do all the context switching itself if it wanted. Using
>> VFPSupport for context switching just makes things easier, since you won't
>> have to worry about writing a new variant of the context switching code
>> for each VFP version.
> Well, I don't think we have new VPF versions that often.  Moreover
> we better tune for right __JMP_BUF_SIZE for each version we want to
> support (something which VFPSupport can't help us as this is only
> helpful at runtime).

Actually __JMP_BUF_SIZE should stay the same between VFP versions. 
EABI/AAPCS says that only d8-d15 (aka s16-s31) need preserving by function 
calls, and those registers exist in all VFP versions.

>>>> * At the moment the context size is hard-coded as 32 doubleword registers. In
>>>> future I'm thinking it would be nice if the -mfpu=... option could be built
>>>> into the executable somehow, so that Unixlib/SUL/VFPSupport can check for the
>>>> right hardware variant(s) and use the appropriate context size at runtime.
>>> I don't think I understand this.
>> When you create a VFPSupport context, you specify how many doubleword
>> registers you need. If you were to request more registers than are
>> available (e.g. 32 on a VFPv2 CPU) then VFPSupport will complain and the
>> program won't be allowed to run. At the moment UnixLib uses a hard-coded
>> context size of 32 registers, so even if you compile for a VFPv1/v2 target,
>> VFPSupport won't allow the code to run on such a target because it's
>> requesting more registers than are available. So this obviously needs
>> changing so that UnixLib uses a context size that's appropriate to the
>> compiler options that were used to generate the code.
> I see.  This might all be solvable by adopting the ELF attributes which
> EABI defines and let ELFLoader do the checks (and using VFPSupport).
> This needs to be tried out but I don't think you can link a VFPvX compiled
> UnixLib with VFPvY usercode as the link will see that those attributes
> are imcompatible.  Or perhaps with softfp you can get away with this but
> how can UnixLib at initialisation time know the superset to pass on to
> VFPSupport ?

For staticly linked programs, can't we just get the linker to examine the 
ELF attributes and spit out a special symbol containing the right features 
for UnixLib to check for?

>>>> I'm
>>>> guessing this would have to be done by having lots of different unixlib
>>>> versions, rather than one copy of unixlib that works with all VFP/NEON
>>>> versions.
>>> For the static case, won't this be a nightmare for the developer ? He
>>> needs to supply his program in all those versions.  The shared lib case
>>> would be a better solution but currently we don't support shared libs
>>> for different multilib configurations.
>> It's only a nightmare for the developer if he decides to provide optimised
>> binaries for each hardware configuration. As long as there's a baseline
>> (VFP-enabled) unixlib configuration which will work on all (VFP-enabled)
>> hardware then it's not a problem.
> And what could be such a baseline ? VFPv1 ?

I'd say VFPv1, but:

* Don't rely on trapped exceptions being supported (since they're 
unsupported on standard VFPv3)
* Don't rely on 'short vectors' being supported (aka using VFP on vectors 
instead of scalars). Short vectors are deprecated in VFPv3, and IIRC 
aren't supported at all in ARMv7-R. I'm not sure about VFPv4.

I believe short vectors are a moot point as far as GCC is concerned (I don't
think GCC has ever been able to take advantage of them from compiled code),
but it might be something for us to consider when it comes to hand-written 
assembler (i.e. how can people indicate that their code uses vectors, so 
that UnixLib/ELFLoader can check for support at initialisation time? Or
should we just force people to perform their own manual checks?)


- Jeffrey

More information about the gcc mailing list