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