[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cirrus ep93xx support (was: Re: Debian ARM success story: Debian desktop on a TS-7300)

On Mon, 31 Jul 2006, Lennert Buytenhek wrote:

On Mon, Jul 31, 2006 at 05:54:31PM +0300, Petko Manolov wrote:

The current advantage of Maverick over something like iWMMXt,
considering that Debian is still hardfpa, is that Maverick is on
coprocessors 4,5,6 so it doesn't conflict with FPA, whereas if you want
to use iWMMXt at all, you have to use either softfloat or EABI for
everything because it conflicts with FPA.

Even though FPA and Maverick doesn't conflict in hardware aspect, it is
still impossible to mix both in the same dynamically linked executable.
The problems are numerous, but think about the data representation in the
memory (and within the FPUs), C argument passing, return values (as per
current GCC convention), etc.

If you want to emit Crunch assembly from C code, it indeed won't work
without a bunch of hacking.  (I have successfully used inline Crunch
assembly in FPA binaries, though.)

About three years ago Cirrus asked us to fix the upcoming gcc-3.4 so it should be able to compile randomly chosen C floating point code which actually work. Along the way we figured out that we need to fix Glibc as well. So technically there is a toolchain that can generate working code. Due to the errata, however, this FPU is not accurate enough for high precision mathematical applications.

The only sane way of using Maverick code is by having it in a statically linked executable.

Or by using EABI?

Using EABI (i can remember only a few fragments, it was in draft back then) should theoretically help, although i don't know how far the actual implementation has gone. What's the state of gcc-4.1 in terms of generating usable Maverick Crunch code? Has anyone worked on getting GCC EABI compliant in case of Maverick Crunch? This part at least should be easy.

This, however, implies that the corresponding libc has been built
with Maverick support.

Why can't we use a Crunch app on top of a, say, VFP soft-float libc?
As long as the calling conventions are the same (which they are, in
this case), I don't see why it would be a problem that the app uses
Crunch while the C library does not..

Well, as i said above, theoretically ... it should. ;) So far the ARM Linux port is using the old FPA format and mixing both is no good except in the case when the user-level application is statically built.

Any plans on migrating to EABI compliant libraries, applications, etc.?


Reply to: