Re: EP9312, Maverick Crunch fixes

[Richard Earnshaw <rearnsha at arm dot com>]

> On Wed, 25 Feb 2004, Paul Brook wrote:
> 
> > On Wednesday 25 February 2004 6:36 pm, Petko Manolov wrote:
> > > Probably for some reason the flag is omitted in 'cpu_variant' variable.
> > > How can i check this quickly (i am afraid i am a bit lazy :-) ?
> >
> > The default FPU is overridden on linux and netbsd targets. See FPU_DEFAULT in
> > tc-arm.c
> 
> Ah, saw it.  It seems that if we get 'Maverick float format' flag set in
> the elf header by -mcpu=ep9312 for linux target we'll break the existing
> policy.
> 
> On other side people should use -mcpu=ep9312 only if they mean using
> Crunch instructions.  Since ep9312 is built around arm920t core it makes
> no sense using this switch in any other circumstances.  The chip has
> lots of other peripheral devices but none of them relates to gas/ld/gcc.
> 

That's part of it, but it's not as simple as that (you knew I'd say that, 
didn't you :-)   There are a number of questions that have to be 
considered:

- is the binary format of Maverick FP numbers the same as the ABI in use?
- are the calling conventions the same (which arguments are passed in 
which registers and how are values returned)?
- will calling and callee functions behave correctly if I use a 
co-processor they don't know about?
- will longjmp/setjmp work correctly?
- will exception unwinding work correctly?

In addition, on an OS you also have to consider

- can the OS correctly context switch if I use this co-processor.

You can use any instructions you like provided all the above are satisfied.

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

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.

Finally note that the current GNU way of marking attributes in an ARM 
binary is *very* broken and should really be considered to be deprecated 
(it's incompatible with the AAELF specification http://www.arm.com/products
/DevTools/ABI.html, it's inextensible and it can't support 3-way 
attributes (eg set, clear, dontcare)).

Oh, and finally, finally, we need a better way for the compiler to tell 
the assembler how to set the attribute flags.  Doing it slavishly from 
-mcpu/-mfpu etc can mean we mark objects as using specific floating point 
formats when in fact they contain no floating point at all.

R.