Xref: utzoo comp.arch:7627 comp.lang.fortran:1643
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.fortran
Subject: Re: Quadruple-Precision Floating Point ?
Summary: Multiple precision can be vectorized; it is just clumsy.
Keywords: REAL*16 hardware
Message-ID: <1072@l.cc.purdue.edu>
Date: 21 Dec 88 11:36:19 GMT
References: <8561@alice.UUCP> <3688@s.cc.purdue.edu> <8899@ut-emx.UUCP>
Organization: Purdue University Statistics Department
Lines: 55

In article <8899@ut-emx.UUCP>, reeder@ut-emx.UUCP (William P. Reeder) writes:
> In article <3688@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman) writes:
< <In article <8561@alice.UUCP> wcs@alice.UUCP (Bill Stewart, usually) writes:
< <>Are there any machines that implement quad-precision (128-bit) floating
< <>point numbers in hardware?
< <Basically all of the CDC, ETA, and Cray machines support 128-bit floating
< <point numbers, but it is called double precision, not quad precision.
< <Dave Seaman	ags@j.cc.purdue.edu

The CDC6000 series and related Cybers, and the CRAYs have 48-bit mantissas;
the Cyber 205 and ETA has essentially 47 bits.  The CRAYs do not have the
necessary hardware to make multiple precision reasonable, while the others
have the hardware to make approximately twice that precision relatively
easy.  For more precision, it is necessary to integerize the floating point
procedures.

> Sure, they support them, but would you say they support them "in hardware"?
> 
> I have used/programmed both a CDC 170/750 and a Cray X/MP-24 (in FORTRAN
> and in assembly).
> 
> The CDC machine had a 96-bit accumulator used by all f.p. instructions.
> Some instructions (FXi) performed an arithmetic operation and returned the
> upper 48-bits of the result, others (DXi) returned the lower 48-bits.  The
> operands were always single-precision floating-point values (in
> registers).  So, for example, to get the double precision sum of two
> (single-precision) values required two instructions, an FXi and a DXi.
> Unfortunately, when I think of double-precision I expect that I should be
> able to (for example) add two double-precision operands and get a double
> precision result.  To do this on the CDC would require a function or
> subroutine, it is not provided *in hardware*.

Still, this helps greatly in getting roughly twice the accuracy.  I would 
expect to lose one bit of accuracy at most in the program.  If the operations
above were included, the cycle begins again; what if we want twice that
precision?  And without additional operations, the situation would be as
bad as on the CRAYs; see below.

> The X/MP is even worse, it does not even have the equivalent of the DXi
> instructions found on the CDC's.  As a result, double-precision
> computations are done entirely in software (meaning without the benefit of
> any special dp hardware) and are anywhere from 30 to 90 times slower than
> the corresponding single-precision operations.  This is probably the
> reason dp operations can't be vectorized (as someone pointed out in an
> earlier posting).

It is not all that difficult to vectorize multiple precision operations on
the CRAYs, providing the precision is fixed.  Because of the lack of good
multiplication operations on those machines, numbers must be broken into
24-bit mantissas; this is why it is so slow.  But even for greater precision,
where the operations must be essentially done in integerized floating point,
fixed precision can be vectorized, albeit with difficulty.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)