🚀 go-pugleaf

Mark Bartelt (sysmark@helios.physics.utoronto.ca) wrote:
: 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.