home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / forth / 3649 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.9 KB
  1. Xref: sparky comp.lang.forth:3649 comp.sys.mips:1136
  2. Newsgroups: comp.lang.forth,comp.sys.mips
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!venezia!penev
  4. From: penev@venezia (Penio Penev)
  5. Subject: any update on plans for {fortran,C} support of 128-bit floats?
  6. Followup-To: comp.sys.sgi.misc
  7. Sender: nobody@ctr.columbia.edu
  8. Organization: Rockefeller University
  9. Date: Sun, 20 Dec 1992 00:51:49 GMT
  10. X-Newsreader: TIN [version 1.1 PL6]
  11. Message-ID: <1992Dec20.005149.15002@sol.ctr.columbia.edu>
  12. Reply-To: penev@venezia.rockefeller.edu
  13. X-Posted-From: venezia.rockefeller.edu
  14. NNTP-Posting-Host: sol.ctr.columbia.edu
  15. Lines: 66
  16.  
  17. [ Article crossposted from comp.sys.sgi.misc,comp.sys.sgi.bugs,comp.sys.sgi ]
  18. [ Author was Penio Penev ]
  19. [ Posted on Sun, 20 Dec 1992 00:41:50 GMT ]
  20.  
  21. Mark Bartelt (sysmark@helios.physics.utoronto.ca) wrote:
  22. : Nearly a year ago I groused a bit about the fact that neither C nor
  23. : fortran (under IRIX 4.0.x) support 128-bit floats, and that (worse!)
  24.  
  25. I wonder who will do the calculations with 128 bit integers, even if
  26. the structure is supported in both languages. The R3000,4000,6000 do
  27. not have support to this, so on them one should do the high-precision
  28. entirely in software. The MIPS architecture has room for extending the
  29. data type of the math coprocessor, but I have not heard this step to
  30. have been taken in R4400. 
  31.  
  32. Implementing high-precision divide in software must be done without the
  33. multiply/divide machinery, because the instructions are unsuited to
  34. this. Contrary to the i386/486 line, MIPS RISC (at least the current
  35. implementations) do not have the simple (and very useful) divide
  36. instruction, which takes 64 bits, divides them by 32 and gives a 32
  37. bit result. Using it one could easily define Nx32/32=(N-1)x32 math,
  38. which is very handy. 
  39.  
  40. So this type of calculations should be done by the brute-force
  41. shift-subtract algorithm, which is unacceptably slow. (There are ways
  42. of getting 20-30% enhancement, but this doesn't live one with joy
  43. in his heart.)
  44.  
  45. On the R3000 the largest precision of the mantissa one can get using
  46. the built-in formats is 52 bits. R4000 makes a step further, defining
  47. the binary fixed point format, but unfortunately, only for 32 bits. I
  48. have not heard (and will be interested to) about the R4400.
  49.  
  50. What I'd love to see in a future implementation is fast integer
  51. multiply/divide of the sort 32*32=64, 64/32=32. This should allow one
  52. to device high precision operators effectively. Adding a possibility
  53. to shift an arbitrary number of bits the hi:lo register pair will
  54. allow a fast fixed point operations on single and high precision
  55. numbers. My favorite model for math instruction set is the Harris
  56. RTX2010 FORTH processor. Of course, the instructions for converting
  57. between fractions and float should be preserved.
  58.  
  59. A final note on fractions. It is very frequently the case in
  60. scientific computing, that the data is expressed in given units. And
  61. an upper limit on the precision of data is known in advance. So
  62. actually the most common (in my opinion) case is using fixed point
  63. numbers, which for the lack of support are represented as float point
  64. ones. If this knowledge is exploited in writing the programs, and
  65. given a suitable instruction set, a lot of unnecessary operations may
  66. be avoided. This of course leads to superior performance.
  67.  
  68. An example from the practice: Here, at Rockefeller University, labs
  69. buy SGI machines to run specific programs - protein
  70. modeling/visualisation, X ray data collection, structure
  71. solving/refinement. None of these programs really needs floating
  72. point, and all will benefit a lot if they used clever fixed point
  73. routines. I think, that the situation in quantum chemistry is the
  74. same, and am sure, that the situation in stat physics ans Monte Carlo
  75. simulations is the same. If SGI is aiming at the scientific market, I
  76. think, that they can gain much from better performing number crunchers
  77. in their boxes.
  78.  
  79. The above stated opinion is mine, and I'll be interested in hearing
  80. others'.
  81.  
  82. -- Penio.
  83.