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