[gccsdk] VFP in GCC 4.6

John Tytgat John.Tytgat at aaug.net
Tue Mar 1 14:22:33 PST 2011

[ 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).

> > Also, the produced ELF binary contains the VFP and other ABI details used,
> > so if VFPSupport SWIS really have to be called to start a RISC OS
> > binary, perhaps the ELFLoader should do that ?
> Perhaps, yes - although there'd obviously still be some code needed for 
> static AIF binaries.
> >> * 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 ?

> >> 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 ?

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list