On Thu, 9 Apr 1998, David wrote:

> I don't know for sure.  I don't even know if it's actually using the FPU
> at the mo - that's on my list of things to check out.  Somethings
> cheerfully bomb out listing a fault at a FP instruction, whilst somethings
> (which I had assumed to use FP)  work perfectly well.  (My current kernel
> doesn't have the FPE built in because it refuses to compile.)  I'm
> presuming this is because-as the ARM documentation says-some of the FP is
> done on chip and some in software, so presumably I still need the FPE in
> the kernel.

If the FPE is configured in then the FP instructions will be supported.
However as the default compiler behaviour is to build soft-float
(post 1.2G) these instructions will not be used unless you are running old
binaries. This was in order to get greated floating point performance
across the majority of machines which do not have an FPA.
Further more interleaving soft-float and hard-float code was promblematic
due to the way in which floating point values where returned from
functions. (with 2.8.x I believe a new APCS variation is supported that
will allow the floating point value to be returned in both integer and fp
registers to allow hard-float and soft-float code mixing).

If one wished to utilise hard-float on the ARM7500FE there are two
choices. Rebuild everything with -mhard-float or modify libc so that the
soft-float functions i.e. the basic FP arithmetic is actually done via the
FP instructions. Whilst this would not be quite as fast as the first
method it would be a lot simpler to implement if someone really wanted to
try and use heavy FP.

As a matter of interest has anyone benchmarked an ARM7500FE doing hard-fp
against an SA110 doing soft-fp ?

Cheers,
				Mark