Re: EP9312, Maverick Crunch fixes

[Petko Manolov <petkan at nucleusys dot com>]

On Thu, 26 Feb 2004, Richard Earnshaw wrote:

> > > - is the binary format of Maverick FP numbers the same as the ABI in use?
> >
> > The format is IEEE-754 single and double precision floating point;
> >
>
> ... but so was the FPA.  However, the word-order of double-precision
> numbers on the FPA was always word-containing-exponent-first (this
> resulted in a mixed-endian order on a little-endian machine).  As I
> understand it, Maverick (like VFP) uses a 'pure-endian' model.  Hence the
> data stored in a memory location by the FPA would be interpreted
> differently by the Maverick.

Oops, sorry.  Didn't quite realized what you were talking about.  Maverick
is exactly like VFP in this regard.  However the internal registers layout
is a bit different.

> I strongly suggest that you either adopt a pure core-registers-only
> calling standard, or a full floating point ABI.  Have a look at sections 5
> and 6 of
>
> 	http://www.arm.com/products/DevTools/abi/aapcs.pdf
>
> which describes models for soft and hard floating point ABIs (but remember
> that this document has slightly different alignment rules).

I read it and i think we'll go for full floating point ABI since the speed
is the main goal.  This won't help linking VFP and Maverick object files
safely, but this is not the point anyway.

> If you adopt a model similar to the base standard in the AAPCS then it
> probably could.

Yep, but that imply using r0-rN for argument passing and r0[,r1] for the
return value.  Too much overhead for each function call unless they are
declared inline or being macroses.  Compatible, but i am afraid, slow.

Maverick doesn't have hw division so i believe it's better to avoid any
additional slowdown.

> That's normally OK.  The system library can be expected to have knowledge
> of the system the code is running on.

nod;

> No, I was thinking about C++ exceptions, but your statement might also
> apply.  However, mostly FP exception handling can be wrapped up in calls
> into the C library (which as previously stated, just has to know about the
> system).

Yep, i think this could be mended in the appropriate library.

> Correct.  It also tells the compiler that it may use them, but only if
> they don't change the ABI in any way (but for now lets assume that GCC
> won't use them in these circumstances).

Fair enough.

> > The second should be used for user level applications where binary image
> > follow the conventions dictated by the selected FPU.
> >
>
> I think this is close enough.  My concern is that a user with a standard
> Linux install on an ep9312 board should be able to invoke GCC with
>
> 	arm-unknown-linux-gnu-gcc -mcpu=ep9312 ....
>
> and still get binaries that work with their system.
>
> However....
>
> I don't see why a compiler configured as
>
> 	ep9312-unknown-linux-gnu-gcc
>
> shouldn't give you a full ep9312-tailored system.  This is conceptually no
> different to the changed ABIs that you get if you have
> armeb-unknown-linux-gnu (for a big-endian processor).  The above
> configuration would effectively mean that the compiler defaulted to
> -mfpu=maverick as well.

I personally don't like the idea of having 2 sets of C compiler and/or
binutils just to be able to compile some FP code for Maverick.  The
additional changes to GCC are relatively small and could totally be
handled by one more flag.  This is what we have now and using multilib
is sufficient for the purpose.

May be if we get gcc to recognize -mfpu=... this case will be handled with
more grace.

> Does that give you sufficient scope to achieve Cirrus' requirements?

Yes, i think.  Thanks for your time.  However, i'll preserve the right to
shamelessly CC you if another issue(s) arise. :-)


cheers,
Petko