MIPS and FLOAT.C

[Jeff]

as we all know, MS released the windows CE 3.0 source not too long ago (http://www.microsoft.com/windows/embedd ... efault.asp).  anyway, being a e125 user, I was pretty interested when I saw float.c.  here is a quote in the comments:<br><br><br>This module implements a software emulation of the IEEE single and double floating operations. It is required on MIPS processors since the hardware does not fully support all of the operations required by the IEEE standard. In particular, infinitives and Nans are not handled by the hardware, but rather cause an exception. On receipt of the exception, a software emulation of the floating operation is performed to determine the real result of the operation and if an exception will actually be raised.<br>    Since floating exceptions are rather rare events, this routine is written in C. Should a higher performance implementation be required, then the algorithms contained herein, can be used to guide a higher performance assembly language implementation.<br><br><br>Well, floating point ops aren't rare in PQ!  Does anyone think that porting this lib to asm would be the answer to speeding up PQ for the MIPS?  Just my .02

[Dan East]

I believe what that is saying is that the routines that handle infinitives ( overflow / underflow ) and NaNs (Not A Number, like sqrt( -1 ) ) exceptions are not written in assembly. Quake should not be causing either of those exceptions, so that exception handling routine which was written in C should never be called.<br>Thanks for digging up the info though! <br><br>Dan East

[Jeff]

*sigh* Does anyone know why won't they just put a math coprocesser in PPCs?  What's wrong with this world? Stop the insanity!

[Digby]

Three reasons: die size, power requirements, and probably the most important of all, the devices are selling pretty well already without an FPU. <br><br>Why would they add a feature that few people require and have to raise the price and decrease the battery life for everyone?<br>

[Moose or Chuck]

PocketPCs don't run that many 3D Applications that require floating points, so it was never really an issue. It would only raise costs for no reason. And any App the needs floating point can take as much time as it wants because that would only be Excel or Money.

[R0B]

Just out of curiosity, would it be possible to make a math math coprocesser in CF form.  Well, I know that it is probably possible, but how much affect would it have on games like PQ.  I don't know how fast the speed to and from a CF card is, but it seems like it might work.

[Moose or Chuck]

The CF Slot speed isn't fast enough for any kind of graphics accelerator. Even the PC Card expansion slot isn't fast enough.<br><br>Well, that's actually not the problem. The problem is that the CF and PC Card ports don't have direct access to the memory and CPU like an AGP or PCI port does. The Bus is inaccessible to the various PPC expansion ports.

[Moose or Chuck]

Plus, even if you did edit the FLOAT.C file, you'd have to compile it into the WinCE OS onto the ROM.

[DeFrAgGeD]

Yes and that would be a little hard, unless you got a rom programmer and some other needed tools