PERFORCE change 133911 for review

[Peter Grehan]

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

  It would be interesting to see what is going on. Maybe gcc4 is using
FP a lot more than gcc3, which is what the compiler was when the initial
ppc FP trap code was done.

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

  Another option is to vector the trap back to user-space and deal with
the emulation there. I heard a rumour that the sparc64 port does this:
it sounded like a good idea since the process causing the traps would be
the one paying the price, not the system at large.

later,

Peter.