Re: EP9312, Maverick Crunch fixes

[Petko Manolov <petkan at nucleusys dot com>]

On Thu, 26 Feb 2004, Richard Earnshaw wrote:

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

Well, i kind of knew it. :-)

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

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

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

Most likely not;

> - will longjmp/setjmp work correctly?

Yes, if the corresponding code in glibc is fixed for Maverick Crunch, like
we did;

> - will exception unwinding work correctly?

If you're talking about FP exceptions - probably not.  For one thing, the
status word has completely different format;

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

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


		Petko