[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Implementor support for the binary interchange formats


I did check my PA-RISC records and found an August 1983 internal spec 
documenting a quad format with a hidden bit.  There is a single table 
describing four binary floating-point formats: single, double, a 79-bit 
"extended" format, and the 128-bit quad format.  The extended and quad formats 
both had 15-bit exponents.  All formats had the hidden mantissa bit.

Surprisingly, and I have no memory of this, there was a defined decimal 
floating-point format.  While the binary formats were described with some 
detail, nothing was said about the decimal formats beyond a table indicating 
that most of the instructions could have either binary or decimal operands.

Given the philosophy of the architecture team, I would guess they felt it more 
RISC-like to do the encodings in a uniform way.  I joined HP in Sept of 1983 as 
a part of the that architecture team.  Dan was around before my arrival, so his 
memories are more relevant. The extended and decimal formats were dropped in 
subsequent revisions.  A public document in 1986 just shows the 3 formats and 
only binary floating-point operations.  We had software emulation built into 
the kernel to support the quad format and native HW support for single and 

The PA-RISC architecture was made public in 1986, so I'm not sure how we copied 
each other.  I thought all these decisions were made when the architectures 
were still being developed internally.  The Stanford MIPS and Berkeley RISC 
architectures were public, but I didn't think addressed the hidden bit issue in 
a quad format.  We might have known about the IBM early RISC designs and need 
to ask someone from IBM on their memory of the dates and decisions.

My only memory of trying to align encoding of formats was the means to 
distinguish signaling from quiet NaNs.  I think we attempted to align with 
big-endian machines thinking that might be more interesting for binary data 
interoperability.  In the end, no business was won or lost on that issue.

Jerry Huck
Hewlett Packard

-----Original Message-----
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx] On Behalf Of Dan Zuras IEEE
Sent: Tuesday, March 01, 2011 5:51 PM
To: Steven Hobbs
Cc: stds-754; Dan Zuras IEEE
Subject: Re: Implementor support for the binary interchange formats

From: Steven Hobbs <Steven.Hobbs@xxxxxxxxxxxxxxxx>
To: Dan Zuras IEEE <forieee@xxxxxxxxxxxxxx>, Michel Hack <hack@xxxxxxxxxxxxxx>
CC: stds-754 <stds-754@xxxxxxxxxxxxxxxxx>
Date: Tue, 1 Mar 2011 17:12:03 -0500
Subject: RE: Implementor support for the binary interchange formats

It has been a long time but I remember that the HP 128-bit FP and the Sun 1=
28-bit FP were different.  The HP 128-bit float representation had a 112 bi=
ts in the significand plus a "hidden" bit for 113 bits of precision.  The S=
un 128-bit FP float representation also had 112 bits in the significand but=
 had no hidden significand bit for 112 bits of precision.  Note that the In=
tel 80-bit extended type is like the Sun 128-bit float in that neither have=
 a hidden significand bit.

When the Alpha architecture was designed, it included both a 128-bit VAX FP=
 data type and a 128-bit IEEE extended data type.  There were no instructio=
ns for these two floating point types.  Implementation was in software.  Th=
e 128-bit VAX FP had been in the VAX hardware since 1980 and included 1 sig=
n bit, 15 exponent bits, 112 significand bits plus one additional hidden si=
gnificand bit for a total of 113 bits of precision.  The Alpha 128-bit IEEE=
 extended data type was identical to the HP 128-bit float type.  Alpha chos=
e the HP 128-bit representation over the Sun 128-bit representation because=
 it was more compatible with the VAX 128-bit representation which would mak=
e implementation easier (as well as making the architecture more regular.)

. . .

--Steve Hobbs

        This is interesting.

        I distinctly remember mentioning over dinner at an ARITH
        conference that I had copied the quad parameters from
        something I heard from Sun.  Then my dinner companion
        (from Sun) said, "That's funny.  We got it from you guys
        at HP."

        From what you say it is quite possible that I looked at
        the VAX parameters & misunderstood about the lack of a
        hidden bit turning ours into a 113 bit significand.
        Then the Alpha guys might have used our parameters to
        get theirs.

        We have always said we copied from each other.  It looks
        like we may have done just that.  They just did a better
        job of it than I did. :-)

        The things you learn decades after the fact...



754 | revision | FAQ | references | list archive