PERFORCE change 133911 for review

[Marcel Moolenaar]

On Jan 25, 2008, at 10:13 AM, Rafal Jaworowski wrote:

> IIRC, almost any AIM binary I tried executing caused FP exceptions  
> (actually,
> an illegal instrusction ;) on e500, even such that wouldn't be  
> expected tu use
> FPU. I didn't investigate this at all, but maybe the compiler was  
> using FPRs
> for optimizations or something of that sort, don't know, so the  
> frequency
> might not be that low in reality.

We didn't see this at all. We typically only saw ntpdate
and top crap out, because they actually use FP. Most of
the binaries were fine without -softfloat.

Note also that a stray FP status register initialization
operation in crtX can cause all processes to fail, even
if there's no FP in the process. Your problem may have
been caused by libc, crt or libgcc. In fact, we may have
seen it ourselves as well and fixed that place to get to
where we ended up without softfloat (i.e. only ntpdate,
top, etc capping out).

BTW: Juniper uses softfloat at this time.

> The interesting aspect about the trapped approach is that we could  
> dispatch
> the call farther, as please remember that embedded PowerPC can have  
> floating
> point/signal processing engines that can do the job, but just not the
> traditional model. This is the very case of PQ3 and its SPE/SPFP  
> which lay
> idle at the moment..

Exactly: EABI is unrelated to FP. I'd like us to support
softfloat (we already use it here at Juniper) for those
who build their own kernel and world, but I'd like us to
release a single FreeBSD/powerpc that works anywhere.

Juniper uses EABI, but there's no advantage. In fact,
there are only disadvantages... We may end up not using
EABI in the end.

-- 
Marcel Moolenaar
xcllnt at mac.com