home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / recreation / fasterfp_2 / fp / Readme < prev    next >
Text File  |  1997-09-03  |  3KB  |  60 lines
  1. Readme for NewFP:
  2. -=-=-=-=-=-=-=-=-
  3. NewFP is simply a hacked version of the FPEmulator. It will work on any RPC
  4. and it's main reason for creation was getting Quake to run faster. It
  5. provides on average a 50-100% increase in FP operations. Quake now runs at
  6. an average of 3-4 fps compared to 2fps! :(
  7.  
  8. A complete rewrite is really what's needed, but I couldn't be bothered as
  9. I know no one would buy it. I'm off to PC land now anyway ...
  10.  
  11. A small history:
  12. -=-=-=-=-=-=-=-=
  13. The FPEmulator as in RO3.7 and every RO version before (yes, it's the same
  14. code :( ) was originally written in 1984-1985 on an emulated Arm platform. It
  15. was not written for RO, but for ARX, the precursor to RO (long story).
  16.  
  17. Anyway, ARX got axed, and Arthur was cobbled together quickly. Essentially
  18. the FPEmulator code was taken, made into a relocatable module, and stuck on
  19. the Arthur floppy disc.
  20.  
  21. Various bug fixes ensued, and some optimisation was done for the RO2 release.
  22. An interesting note here is that this explains the use of the TRANS pin on
  23. Arm2's in the FP code. ARX had different memory maps for each processor state
  24. using MEMC's abilities in this regard ie; in supervisor everything was in a
  25. different place than in user etc. The TRANS pin (utilised using LDRT or STRT
  26. and STMIA ... ^ when PC isn't in the list etc) forces a memory map context
  27. change to user mode ie; it accesses using the user mode memory map. RO never
  28. had this feature, and hence the TRANS pin was never needed nor did RO code
  29. use the TRANS pin.
  30.  
  31. Anyway, the FP emuator was then played with for the Arm2 FP unit (no one
  32. bought it), and also when the Arm7 FPU was being dreamed of. The main hacks
  33. were the replacement of the trig routines with other FP instructions (not
  34. clever) as the envisaged FPU would only do adds and multiplys (the two most
  35. common operations). Also for RO3.5 and the Arm6 a fudge was applied to change
  36. the environment from 32 bit Arm6 to an emulation of the 26 bit Arm2/3. This
  37. code still gets executed every time a FP instruction happens.
  38.  
  39. Never mind this, but the original FP code wasn't exactly quick anyway. All
  40. operations, irrespective of the precision you specify, are carried out to
  41. extended precision. Yes, all 96 bits worth. And then (best of all) it goes
  42. through a rounding process to round the result to the precision you asked
  43. for. This happens for *every* FP op.
  44.  
  45. Now Quake only requires single precision, sometimes double. It doesn't
  46. require long double. However, I'm not about to rewrite the fp emulator, so
  47. instead I hacked the code to stop rounding on exit and instead just truncate.
  48. I didn't bother replacing SIN and COS with their original (much faster) code
  49. though. Someone else can bother.
  50.  
  51. Anyway, this simple change makes a huge difference. It goes much quicker. But
  52. as now have a PC with a Millenium II and GLQuake, I don't really care
  53. anymore. I'm off to play Quake at 30fps with bilinear filtered graphics ...
  54. :)
  55.  
  56. Anyway, the notes and hatchet basic file are all enclosed. Enjoy someone!
  57.  
  58. Cheers,
  59. Niall Douglas.
  60.