Re: EP9312, Maverick Crunch fixes

[Richard Earnshaw <rearnsha at arm dot com>]

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

> > - are the calling conventions the same (which arguments are passed in
> > which registers and how are values returned)?
> 
> Maverick Crunch uses the same convention for passing arguments, but
> returns in "mvd0" or "mvf0" (double or float respectively);
> 

Yuck!  I think that's propagating a misfeature of the ABI that was used on 
Linux (which dates back to the days of the RISC iX, Acorn's first Unix 
operating system for the ARM).

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

> > - will calling and callee functions behave correctly if I use a
> > co-processor they don't know about?
> 
> Most likely not;

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

> 
> > - will longjmp/setjmp work correctly?
> 
> Yes, if the corresponding code in glibc is fixed for Maverick Crunch, like
> we did;

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

> 
> > - will exception unwinding work correctly?
> 
> If you're talking about FP exceptions - probably not.  For one thing, the
> status word has completely different format;
> 

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

> > In addition, on an OS you also have to consider
> >
> > - can the OS correctly context switch if I use this co-processor.
> 
> Yep.  This is achieved with the cost of extra flag in the process
> structure.  I have a version of Linux kernel that runs standard ARM Linux
> apps along with Crunch powered ones with no side effects.  However Crunch
> apps are staticly linked - there is no easy way to mix both if you want
> them dynamic.
> 
> > Now as I understand the Maverick CP it has two aspects -- a floating point
> > unit and some extended integer operations.  Even if it's not possible to
> > use the FP instructions, it might be OK to use the integer ones.  It might
> > even be possible to use the single-precision FP instructions only if the
> > binary formats are the same (though returning FP values will be
> > interesting if you need to run on Linux, since there the result must be
> > returned in FPA register f0).
> 
> Using 64bit integer arithmetics with Crunch is not feasible since the FPU
> doesn't provide enough flags to cope with signed/unsigned operations.
> This is the reason we dropped the support for these in GCC-3.4.
> 
> Crunch also doesn't have FP division instruction so it still rely on
> software emulation.  This makes it not a complete FP platform, but some
> sort of mixed between hard and soft float beast.
> 
> It's quite hard to satisfy these requirements in GCC.  It will impact
> performance if functions return the result in f0.  Cirrus would like to
> get the best from Crunch even if it breaks some compatibility.

I don't think I was seriously suggesting you wanted to go that route -- I 
was just trying to show how it could be done...

> 
> > Now it's not possible to convey all that information to the compiler
> > through the single -mcpu flag.  The -mcpu flag tells the compiler if the
> > instructions are available, but additional constraints may restrict
> > whether or not it will use them.
> 
> Well, given the above i can't see how even 2 flags can solve all the
> issues, but this is not the point anyway.  I do agree we should follow
> whatever is the current flags passing convention, good or bad.
> 
> So at the end let me do a short resume:
> 
> 	* -mcpu=ep9312 tells gas about Maverick Crunch instructions;

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

> 	* -mfpu=maverick sets Maverick flag in the elf header - we assume
> 	  the resulting binary comply with Crunch conventions;
> 
> The first should be useful when one writes code for, lets say, OS kernel.
> This will allow gas to recognize the instructions in the context saving
> functions/macroses without setting bogus elf flags which will later puzzle
> the linker.
> 
> 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.

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

R.