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

In article <1992Dec20.004150.14551@sol.ctr.columbia.edu> penev@venezia.rockefeller.edu writes:
>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. 

When I went to the NEC/MIPS/SGI R4000A ( R4400 ) conference earlier
this year, I specifically asked if the existing IEEE 754 SP and DP
coverage would be extended to EP also.  I was specifically told by the
guy that made the decision that it was not.

Furthermore, the original IEEE 754 hardware rounding is ( not
suprisingly ) still not supported.

That should clear up that question.

Perhaps the next chip?  No.  The FPX, and the low power R4000 ( I
forget its name ) are the two next chips.  Though I go not concrete 
answers, I got a solid feeling that these would also have only SP and
DP.  And the chip after that, the R5000?  I have no idea.  Call your 
salesman today.
-- 
	 Frank E Perdicaro, Systems Admin, etc.		Xyvision Color Systems
      Legalize guns, drugs and cash...today.		101 Edgewater Drive
   inhouse: frank@marvin, x5572				Wakefield MA
outhouse: frank@contex.com, 617-245-4100x5572		018801285

In article <3236@contex.contex.com>, frank@marvin.contex.com (Frank Perdicaro) writes:
|> In article <1992Dec20.004150.14551@sol.ctr.columbia.edu> penev@venezia.rockefeller.edu writes:
|> >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!)
 
|> Perhaps the next chip?  No.  The FPX, and the low power R4000 ( I
|> forget its name ) are the two next chips.  Though I go not concrete 
|> answers, I got a solid feeling that these would also have only SP and
|> DP.  And the chip after that, the R5000?  I have no idea.  Call your 
|> salesman today.

Well ... this probably won't help you much (calling your salesman,
that is), since the sales folks are fairly far away from chip architecture
decisions for several years out.

As it happens, the 128-bit FP issue is generally reviewed for each major
new round of chip design, and we tend to ask customers and industry experts
what they think, and the answers tend to go as follows:

Q: Would you like to have 128-bit FP?
   A: Yes, of course.
Q: Would you like to have faster 64-bit FP?
   A: Yes, of course.
Q: If, for the next design, we only have chip die area (and it is *always*
   limited) to give you 128-bit OR faster 64-bit, which should we do?
   A: Faster 64-bit.

1) When you allocate the space on a chip, there is a large range of
floating-point solutions where using more space gets more performance, by having
space-intensive FP units with lower latencies and higher repeat rates,
and/or by duplicating FP units, which is far more useful for FP performance
than it is for integer work, so far.  With current-sized chips, this is
still a tradeoff; 128-bit FP is not free.

2) As a result, I suspect it will be a while before 128-bit FP is
frequently found in microprocessors.  It will happen as chip features sizes
shrink (and *must* happen, for some classes of programs),
but it will take a while.  Of course, doing it all (or mostly) in software
can precede fast support in hardware, and there are ways to help this.

3) Given the lead-times involved, don't expect a 128-bit FP Rxxx in 1993 
or 1994; 1995 may well be impossible also.  Maybe later.

4) IF you think you really need 128-bit FP, it would probably help us to
post/email what you're doing.  Of course, if you were to post that you would
buy $100Ms of computers because of this feature, more attention would
be attracted :-)....  but seriously, we're interested in this area and willing
to listen to people on it. 

-- 
-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

In article <1993Jan6.005916.800@odin.corp.sgi.com>, mash@mash.wpd.sgi.com (John R. Mashey) writes:
|>In article <3236@contex.contex.com>, frank@marvin.contex.com (Frank Perdicaro) writes:
|>|> In article <1992Dec20.004150.14551@sol.ctr.columbia.edu> penev@venezia.rockefeller.edu writes:
|>|> >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!)
|> 
|> [discussion on tradeoffs to pay to have 128-bit FP on the processor]

I would also answer 'Faster 64-bit' rather than '128-bit'.
But if i remember correctly the original post (there is a bit of it above), the
question was "can we have 128-bit float support in your compilers" ?

I believe that having software support would still be very useful for
development of numerical algorithms.  sometimes you need a 'reference run'
to check the stability of differential equation solvers or whatever.
you may not care if this reference run is slow.  

so i would say, thanks hardware guys, don't worry about that,
and perhaps it's now the time for compiler folks to jump on this thread :-)

--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
furio@uiuc.edu                          |   furio@sissa.it