any update on plans for {fortran,C} support of 128-bit floats?

[ Article crossposted from comp.sys.sgi.misc,comp.sys.sgi.bugs,comp.sys.sgi ]

[ Author was Penio Penev ]

[ Posted on Sun, 20 Dec 1992 00:41:50 GMT ]

: Nearly a year ago I groused a bit about the fact that neither C nor

: fortran (under IRIX 4.0.x) support 128-bit floats, and that (worse!)

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.

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.)

On the R3000 the largest precision of the mantissa one can get using

the built-in formats is 52 bits. R4000 makes a step further, defining

the binary fixed point format, but unfortunately, only for 32 bits. I

have not heard (and will be interested to) about the R4400.

What I'd love to see in a future implementation is fast integer

multiply/divide of the sort 32*32=64, 64/32=32. This should allow one

to device high precision operators effectively. Adding a possibility

to shift an arbitrary number of bits the hi:lo register pair will

allow a fast fixed point operations on single and high precision

numbers. My favorite model for math instruction set is the Harris

RTX2010 FORTH processor. Of course, the instructions for converting

between fractions and float should be preserved.

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.

An example from the practice: Here, at Rockefeller University, labs

buy SGI machines to run specific programs - protein

modeling/visualisation, X ray data collection, structure

solving/refinement. None of these programs really needs floating

point, and all will benefit a lot if they used clever fixed point

routines. I think, that the situation in quantum chemistry is the

same, and am sure, that the situation in stat physics ans Monte Carlo

simulations is the same. If SGI is aiming at the scientific market, I

think, that they can gain much from better performing number crunchers

in their boxes.

The above stated opinion is mine, and I'll be interested in hearing

others'.

-- Penio.