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