On Jun 30, 12:38am, Rik Griffin wrote:
> Subject: Re: Floating point performance
> In message <Pine.GSO.3.93.960628133752.9471A-100000@stingray.ivision.co.uk>
you wrote:
>
> > Hello all,
> >
> > I am looking at ways to optimise the FPE at the moment, and have a few
> > ideas.  However before I go ahead I need to know whether or not it can
> > really be optimised that much.
> >
> > Can someone/has someone done a comparison with the speed of the RiscOS
> > FPE? If so can I have the result/s please so I can work out whether
> > it is really worth bothering or not.
>
> I was going to provide some 'real world' figures for you from POVray,
> but for some reason it doesn't seem to like RiscBSD :-(
>
> It compiles fine, but on running, crashes out with a data abort, at
> address 0x0000000c. If anyone can help, I can provide more info.

This looks like the same problem as with X. I think it is something to do with
signal delivery, but as I haven't been able to reproduce it reliably I haven't
got very far with tracing it. If you have a test case which reliably produces
the problem I'm sure Mark would like to know about it.

> By the way, does the RiscBSD compiler do FP in the same way as the
> RISCOS one does? IE - assemble FPA instructions into the binary, then
> these are trapped when excecuted by the emulator ?

GCC compiles floating point coprocessor instructions into the binary. When the
binary is executed and hits a coprocessor instruction (for a coprocessor it
doesn't have) it jumps to the undefined instruction vector (in undefined32
mode). The FPE code hangs off this vector and interprets the floating point
coporcessor instructions. This is pretty much the same as RiscOS except that
there is some wrapper code in RiscBSD which handles things like signal
delivery.

Cheers

Rob Black

--