On Sat, 2011-05-07 at 00:09 +1200, Michael Hope wrote: > On Fri, May 6, 2011 at 6:57 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote: > > Jon Masters wrote: > >> If you read how VFPv3 actually implements its registers, you'll see that > >> the extra 16 (for D32) really are totally separate anyway as far as the > >> ABI is concerned, so I remain unconvinced we lose a lot by being D16. > > > > Can you clarify that? Does that mean that a we can have a D16 distro > > with D32 kernel/glibc? > > VFPv3-D16 and VFPv3-D32 code are compatible. You can call D16 code > from D32 code and vice-versa. This isn't stated in AAPCS but I assumed it to be the case since the register context preservation extends only to the first 16 registers. So, Phillipe can correct us if we're wrong, but this sounds right. As far as I know, the first 16 are the only registers mandated for passing parameters, etc. which is why there is compatibility. And the other 16 registers would only be used at the local function level, so they would not really buy you very much, especially in non-floating point code! Especially in the kernel, I don't see any realized benefit from building with D32, but some math library might benefit marginally. We can optimize for A9+ VFPv3-D16 and then there can be packages that are D32 later on, but I suspect it would be more likely that one would create optimized NEON binaries and perhaps one day switch to a D32 base set of configuration flags once nobody is using D16 v7 devices. Philippe: If I'm crazy, let me know ;) Jon. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
