home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sgi / 18267 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.6 KB

  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!doc.ic.ac.uk!cc.ic.ac.uk!imperial.ac.uk!vulture
  2. From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: any update on plans for {fortran,C} support of 128-bit floats?
  5. Message-ID: <1992Dec22.143328.14243@cc.ic.ac.uk>
  6. Date: 22 Dec 92 14:33:28 GMT
  7. References: <BzGLB0.90v@helios.physics.utoronto.ca> <1992Dec20.004150.14551@sol.ctr.columbia.edu>
  8. Sender: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
  9. Reply-To: cmaae47@imperial.ac.uk
  10. Organization: Imperial College of Science, Technology and Medicine
  11. Lines: 54
  12. Nntp-Posting-Host: cscgc
  13.  
  14. In article <1992Dec20.004150.14551@sol.ctr.columbia.edu>, penev@venezia (Penio Penev) writes:
  15. - I wonder who will do the calculations with 128 bit integers, even if
  16. - the structure is supported in both languages. The R3000,4000,6000 do
  17. - not have support to this, so on them one should do the high-precision
  18. - entirely in software. The MIPS architecture has room for extending the
  19. - data type of the math coprocessor, but I have not heard this step to
  20. - have been taken in R4400. 
  21. - Implementing high-precision divide in software must be done without the
  22. - multiply/divide machinery, because the instructions are unsuited to
  23. - this. Contrary to the i386/486 line, MIPS RISC (at least the current
  24. - implementations) do not have the simple (and very useful) divide
  25. - instruction, which takes 64 bits, divides them by 32 and gives a 32
  26. - bit result. Using it one could easily define Nx32/32=(N-1)x32 math,
  27. - which is very handy. 
  28.  
  29. Well, use the bottom 16 bit, and define your numbers as an array of shorts,
  30. then all the 32 bit integer instructions will work for you. Yes, there is a
  31. little overhead, but if the overall processing time is too long you could
  32. go to any of the mips chip licensees and have them design for you a chip
  33. which has 64/32 -> 32/32 bit divide  instructions. 
  34.  
  35. - So this type of calculations should be done by the brute-force
  36. - shift-subtract algorithm, which is unacceptably slow. (There are ways
  37. - of getting 20-30% enhancement, but this doesn't live one with joy
  38. - in his heart.)
  39.  
  40. Total garbage, just implement long division as you learnt it at age 10 or so,
  41. it does not matter conceptually if you do it base 10, base 10000 or base 2**32.
  42. For numbers up to base**10 or so in length this is still acceptably fast,
  43. beyond that, you can use the Newton-Raphson algorithm.
  44. .....
  45. - A final note on fractions. It is very frequently the case in
  46. - scientific computing, that the data is expressed in given units. And
  47. - an upper limit on the precision of data is known in advance. So
  48. - actually the most common (in my opinion) case is using fixed point
  49. - numbers, which for the lack of support are represented as float point
  50. - ones. If this knowledge is exploited in writing the programs, and
  51. - given a suitable instruction set, a lot of unnecessary operations may
  52. - be avoided. This of course leads to superior performance.
  53.  
  54. Life would be so much nicer if we had an infinite amount of programmers and
  55. hardware designers solving the problems for us, and and infinite amount of
  56. money to pay them with. This dilemma is what got CISC chips into a rut, 
  57. and why CISC chips are some 2 to 3 years behind RISC chips in exploiting a
  58. new hardware technology.
  59.                                   Thomas
  60. -- 
  61. *** This is the operative statement, all previous statements are inoperative.
  62. *   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
  63. *   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
  64. *   snail: Imperial College of Science, Technology and Medicine
  65. *   The Center for Computing Services, Kensington SW7 2BX, Great Britain
  66.