info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
The TC-16 and Model 709: A Unique Floating-Point Format
80 views
Skip to first unread message
Quadibloc
May 21, 2021, 4:33:07 PM5/21/21
to
Most floating-point formats found on historical computers fall into two
categories.
The IEEE-754 floating-point format, and the IBM 360 floating point format,
and many others, are organized like this:
(sign)
(exponent sign)
(exponent)
(significand, mantissa, coefficient)
Computers that don't have hardware floating-point, however, instead of
ordering the components of a floating-point number in terms of significance,
order them in a way that makes it easier for them to handle:
(exponent sign)
(exponent)
(sign)
(significand, mantissa, coefficient)
Since they don't have hardware floating-point, they organize a floating-point
number as two separate integers. The exponent doesn't have to come first.
And then there's a third kind of format, which I found on a few computers,
mostly with a 24-bit word length. It was similar to the format listed above,
but with the significand first and the exponent second. But one strange thing
stood out; the first bit of the second word of the floating-point number was
unused.
I put this down to those computers being large enough to come with a
hardware multiply feature. Omitting the first bit on the second word, or
treating it as a duplicate sign bit, avoided an extra step in the use of the
hardware multiply in processing floating quantities.
Well, the Model 709 and the TC-16, two closely related computers fromt he
People's Republic of China, finally came up with a floating-point format that
is not related to this systematic summary of floating-point formats.
(Of course, the double-precision floating-point numbers on the ICL 1900 is
fairly weird too, but that's a Group III format also doubled-up in the classic
way used for 128-bit floats on the 360/85 and subsequent IBM mainframes,
or for double-precision on the IBM 704 to 7090.)
The order of components is:
(exponent)
(exponent sign)
(sign)
(significand, mantissa, coefficient)
One can think of it as a compromise between Group I and Group II. The two
signs are together, as in Group I, and yet the exponent and the number part
are both contiguous as well.
John Savard
categories.
The IEEE-754 floating-point format, and the IBM 360 floating point format,
and many others, are organized like this:
(sign)
(exponent sign)
(exponent)
(significand, mantissa, coefficient)
Computers that don't have hardware floating-point, however, instead of
ordering the components of a floating-point number in terms of significance,
order them in a way that makes it easier for them to handle:
(exponent sign)
(exponent)
(sign)
(significand, mantissa, coefficient)
Since they don't have hardware floating-point, they organize a floating-point
number as two separate integers. The exponent doesn't have to come first.
And then there's a third kind of format, which I found on a few computers,
mostly with a 24-bit word length. It was similar to the format listed above,
but with the significand first and the exponent second. But one strange thing
stood out; the first bit of the second word of the floating-point number was
unused.
I put this down to those computers being large enough to come with a
hardware multiply feature. Omitting the first bit on the second word, or
treating it as a duplicate sign bit, avoided an extra step in the use of the
hardware multiply in processing floating quantities.
Well, the Model 709 and the TC-16, two closely related computers fromt he
People's Republic of China, finally came up with a floating-point format that
is not related to this systematic summary of floating-point formats.
(Of course, the double-precision floating-point numbers on the ICL 1900 is
fairly weird too, but that's a Group III format also doubled-up in the classic
way used for 128-bit floats on the 360/85 and subsequent IBM mainframes,
or for double-precision on the IBM 704 to 7090.)
The order of components is:
(exponent)
(exponent sign)
(sign)
(significand, mantissa, coefficient)
One can think of it as a compromise between Group I and Group II. The two
signs are together, as in Group I, and yet the exponent and the number part
are both contiguous as well.
John Savard
Scott Lurndal
May 21, 2021, 5:14:55 PM5/21/21
to
Quadibloc <jsa...@ecn.ab.ca> writes:
>Most floating-point formats found on historical computers fall into two
>categories.
>
>The IEEE-754 floating-point format, and the IBM 360 floating point format,
>and many others, are organized like this:
>
>(sign)
>(exponent sign)
>(exponent)
>(significand, mantissa, coefficient)
>
>Computers that don't have hardware floating-point, however, instead of
>ordering the components of a floating-point number in terms of significance,
>order them in a way that makes it easier for them to handle:
>
>(exponent sign)
>(exponent)
>(sign)
>(significand, mantissa, coefficient)
>
>Since they don't have hardware floating-point, they organize a floating-point
>number as two separate integers. The exponent doesn't have to come first.
Burroughs B3500 _hardware_ floating point was SxxSyyyyyyyyyy...y
>Most floating-point formats found on historical computers fall into two
>categories.
>
>The IEEE-754 floating-point format, and the IBM 360 floating point format,
>and many others, are organized like this:
>
>(sign)
>(exponent sign)
>(exponent)
>(significand, mantissa, coefficient)
>
>Computers that don't have hardware floating-point, however, instead of
>ordering the components of a floating-point number in terms of significance,
>order them in a way that makes it easier for them to handle:
>
>(exponent sign)
>(exponent)
>(sign)
>(significand, mantissa, coefficient)
>
>Since they don't have hardware floating-point, they organize a floating-point
>number as two separate integers. The exponent doesn't have to come first.
Where the first digit was the sign of the exponent (C = +, D = -), the
next two digits (nibbles) were the exponent (00..99) followed
by the sign of the mantissa and a variable length BCD mantissa of
up to 100 digits.
Quadibloc
May 21, 2021, 7:19:28 PM5/21/21
to
On Friday, May 21, 2021 at 3:14:55 PM UTC-6, Scott Lurndal wrote:
> Burroughs B3500 _hardware_ floating point was SxxSyyyyyyyyyy...y
> Where the first digit was the sign of the exponent (C = +, D = -), the
> next two digits (nibbles) were the exponent (00..99) followed
> by the sign of the mantissa and a variable length BCD mantissa of
> up to 100 digits.
Oh, yes, it's not an invariable rule that hardware floating point has to be
> Burroughs B3500 _hardware_ floating point was SxxSyyyyyyyyyy...y
> Where the first digit was the sign of the exponent (C = +, D = -), the
> next two digits (nibbles) were the exponent (00..99) followed
> by the sign of the mantissa and a variable length BCD mantissa of
> up to 100 digits.
Group I and Group II floating-point has to be done in software. It's just
the general trend of what seems to me to be the most common.
John Savard
Robin Vowels
May 21, 2021, 11:32:03 PM5/21/21
to
On Saturday, May 22, 2021 at 6:33:07 AM UTC+10, Quadibloc wrote:
> Most floating-point formats found on historical computers fall into two
> categories.
>
> The IEEE-754 floating-point format, and the IBM 360 floating point format,
> and many others, are organized like this:
>
> (sign)
> (exponent sign)
> (exponent)
> (significand, mantissa, coefficient)
.
> Most floating-point formats found on historical computers fall into two
> categories.
>
> The IEEE-754 floating-point format, and the IBM 360 floating point format,
> and many others, are organized like this:
>
> (sign)
> (exponent sign)
> (exponent)
> (significand, mantissa, coefficient)
The IBM S/360 hardwarwe format was:
(mantissa sign) (biased exponent) (unsigned mantissa)
.
There was no separate sign bit for the exponent.
.
> Computers that don't have hardware floating-point, however, instead of
> ordering the components of a floating-point number in terms of significance,
> order them in a way that makes it easier for them to handle:
>
> (exponent sign)
> (exponent)
> (sign)
> (significand, mantissa, coefficient)
.
> ordering the components of a floating-point number in terms of significance,
> order them in a way that makes it easier for them to handle:
>
> (exponent sign)
> (exponent)
> (sign)
> (significand, mantissa, coefficient)
Again, that is false.
The mantissa was stored as a signed value; likewise,
the exponent stored was stored as a signed value.
Quadibloc
May 22, 2021, 1:32:19 AM5/22/21
to
On Friday, May 21, 2021 at 9:32:03 PM UTC-6, Robin Vowels wrote:
> The IBM S/360 hardwarwe format was:
> (mantissa sign) (biased exponent) (unsigned mantissa)
> .
> There was no separate sign bit for the exponent.
This, of course, applies to the IEEE-754 floating-point format as well.
> The IBM S/360 hardwarwe format was:
> (mantissa sign) (biased exponent) (unsigned mantissa)
> .
> There was no separate sign bit for the exponent.
For simplicity, I did not concern myself with details such as the
possible use of formats other than sign-magnitude for the exponent,
whether excess-n, one's complement, or two's complement. When the
exponent was fully contiguous in any of those forms, I took the first bit
as the sign bit.
My web page on floating-point formats has more space than a USENET
post, and there I do note these details correctly.
John Savard
Bob Eager
May 22, 2021, 6:34:08 AM5/22/21
to
can look up, but there is no real need).
The entry level machine had all floating point opcodes cause an
'extracode trap', whereupon the operation was handled in software.
The more expensive machines had hardware implementation of that same
format.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Quadibloc
May 22, 2021, 8:59:15 AM5/22/21
to
On Friday, May 21, 2021 at 11:32:19 PM UTC-6, Quadibloc wrote:
> My web page on floating-point formats has more space than a USENET
> post, and there I do note these details correctly.
Which web page is:
> My web page on floating-point formats has more space than a USENET
> post, and there I do note these details correctly.
http://www.quadibloc.com/comp/cp0201.htm
John Savard
Quadibloc
May 22, 2021, 9:17:04 AM5/22/21
to
On Saturday, May 22, 2021 at 4:34:08 AM UTC-6, Bob Eager wrote:
> The more expensive machines had hardware implementation of that same
> format.
Yes. Compatibility between hardware and software is a big reason why
> The more expensive machines had hardware implementation of that same
> format.
a format of a type usually used with one is also used with the other.
Basically, what I'm noting is that after looking at the floating-point formats
of a large number of historical machines, I found that most fell into one
of two categories:
Either:
the sign of the floating-point number as a whole
the exponent (including sign), most often as excess-n
the mantissa
- this format best preserves the ordering of floating-point numbers; if
the exponent and mantissa are inverted for negative numbers (as done
on the PDP-10 and the Sigma) floating-point numbers can have the
same ordering as two's complement integers
(I called this Group I)
Or:
the exponent as one integer, and
the sign of the floating-point number together with the mantissa
as another integer (although usually also normalilzed)
This is the easiest and most convenient format for software,
since you have two integers. The RECOMP II, with hardware
floating-point, used a version of this format to simplify the
hardware drastically, and the floating-point hardware add-on
for the PDP-8 also used it, as just two examples of it also
being used in hardware.
(I called this Group II)
And I found one variant of that to be worthy of mention in
its own right.
This is where:
- the mantissa+sign comes first;
- the format occupies two machine words;
- the first bit of the second machine word is either
a copy of the sign or unused.
The rationale behind that format was, in my opinion,
to allow efficient operation on a machine which
had hardware multiply for integers, but not floating-point
hardware... set up so that arithmetic on double-length
integers would be easy to do _if_ you didn't try to use
_all_ the bits, including the first bit, of the integer with
the less significant part, but instead allowed the sign to
be indicated in both halves.
(This is what I called Group III)
And so my point is that by having both the exponent and
mantissa in sign-magnitude form, putting the exponent
first, and putting the sign of the exponent at the end,
rather than the beginning of the exponent...
the Model 709 and TC-16 computers from the People's
Republic of China kept both sign bits together, just as they
are together (if the exponent were sign-magnitude, at least)
in Group I,
and yet both the bits of the exponent and the bits of the mantissa
are contiguous as they are in Group II...
thus making a unique format that doesn't really fit into any
of the categories that I found applied to all the other computers
I had seen.
John Savard
Quadibloc
May 22, 2021, 9:29:01 AM5/22/21
to
On Saturday, May 22, 2021 at 4:34:08 AM UTC-6, Bob Eager wrote:
> Indeed. The first machine I ever used had a particular format (which I
> can look up, but there is no real need).
> The entry level machine had all floating point opcodes cause an
> 'extracode trap', whereupon the operation was handled in software.
> The more expensive machines had hardware implementation of that same
> format.
Since the Atlas only came in one size, would that make that machine
> can look up, but there is no real need).
> The entry level machine had all floating point opcodes cause an
> 'extracode trap', whereupon the operation was handled in software.
> The more expensive machines had hardware implementation of that same
> format.
the ICL 1900?
I classed its format as a Group III format.
The format consisted of a mantissa in two's complement format,
followed by an exponent in two's complement format.
The most significant bit of the second word of the number, though,
wasn't part of the mantissa, which is why I classed it as being
Group III. However, instead of being a copy of the sign, or being
unused, it was an 'overflow' bit, so that machine had a NaN
capability.
That already made its format unique.
But there was more. Double-precision floats were 96 bits long, and
the second half of a double-precision float omitted the first bit of
both 24-bit words as well as the area corresponding to the exponent
which was still in the first half.
This, of course, was simply an application of the same basic principle
that the IBM 704 used for double precision, or that the System/360
Model 85 used for extended precision; use the existing floating-point
machinery for the second half of a double-length floating-point number,
so that you can only add the bits that are part of the mantissa proper.
This makes sense... _on a machine with hardware floating-point_.
But the floating-point format of the ICL 1900 was designed for a machine
that _didn't_ have hardware floating-point, but did have hardware multiply,
as that facilitated two-integer double-length integer arithmetic (instead of
double-length integer arithmetic that just appends all the bits of the second
word, so no need to skip the sign).
John Savard
Bob Eager
May 22, 2021, 10:51:07 AM5/22/21
to
On Sat, 22 May 2021 06:29:00 -0700, Quadibloc wrote:
> On Saturday, May 22, 2021 at 4:34:08 AM UTC-6, Bob Eager wrote:
>
>> Indeed. The first machine I ever used had a particular format (which I
>> can look up, but there is no real need).
>
>> The entry level machine had all floating point opcodes cause an
>> 'extracode trap', whereupon the operation was handled in software.
>
>> The more expensive machines had hardware implementation of that same
>> format.
>
> Since the Atlas only came in one size, would that make that machine the
> ICL 1900?
No, the NCR/Elliott/ICL 4100 series. 4120 with software floating point,
> On Saturday, May 22, 2021 at 4:34:08 AM UTC-6, Bob Eager wrote:
>
>> Indeed. The first machine I ever used had a particular format (which I
>> can look up, but there is no real need).
>
>> The entry level machine had all floating point opcodes cause an
>> 'extracode trap', whereupon the operation was handled in software.
>
>> The more expensive machines had hardware implementation of that same
>> format.
>
> Since the Atlas only came in one size, would that make that machine the
> ICL 1900?
4130 with hardware floating point.
The first machine I really used, and programmed in assembler.
Robin Vowels
May 22, 2021, 12:10:50 PM5/22/21
to
On Saturday, May 22, 2021 at 11:17:04 PM UTC+10, Quadibloc wrote:
> On Saturday, May 22, 2021 at 4:34:08 AM UTC-6, Bob Eager wrote:
>
> > The more expensive machines had hardware implementation of that same
> > format.
> Yes. Compatibility between hardware and software is a big reason why
> a format of a type usually used with one is also used with the other.
>
> Basically, what I'm noting is that after looking at the floating-point formats
> of a large number of historical machines, I found that most fell into one
> of two categories:
>
> Either:
>
> the sign of the floating-point number as a whole
> the exponent (including sign), most often as excess-n
> the mantissa
>
> - this format best preserves the ordering of floating-point numbers; if
> the exponent and mantissa are inverted for negative numbers (as done
> on the PDP-10 and the Sigma) floating-point numbers can have the
> same ordering as two's complement integers
>
> (I called this Group I)
>
> Or:
>
> the exponent as one integer, and
> the sign of the floating-point number together with the mantissa
> as another integer (although usually also normalilzed)
.
> On Saturday, May 22, 2021 at 4:34:08 AM UTC-6, Bob Eager wrote:
>
> > The more expensive machines had hardware implementation of that same
> > format.
> Yes. Compatibility between hardware and software is a big reason why
> a format of a type usually used with one is also used with the other.
>
> Basically, what I'm noting is that after looking at the floating-point formats
> of a large number of historical machines, I found that most fell into one
> of two categories:
>
> Either:
>
> the sign of the floating-point number as a whole
> the exponent (including sign), most often as excess-n
> the mantissa
>
> - this format best preserves the ordering of floating-point numbers; if
> the exponent and mantissa are inverted for negative numbers (as done
> on the PDP-10 and the Sigma) floating-point numbers can have the
> same ordering as two's complement integers
>
> (I called this Group I)
>
> Or:
>
> the exponent as one integer, and
> the sign of the floating-point number together with the mantissa
> as another integer (although usually also normalilzed)
The mantissa is not usually stored as an integer.
It is usually stored as a binary fixed-point value,
to 30 or 31 binary places (32-bit words), so that the value of the
mantissa lies between -0.5 and +0.5. That is, the mantissa is
normalised.
.
The DEUCE standard floating binary used two words of 32 bits
each. The exponent was held in the first word, and the mantissa
in the second word. Negative values were held in two's complement
form. The mantissa was held in fixed-point form, with 30 binary
places.
The GEORGE compiler for the same machine packed the mantissa and
exponent into a single word. The mantissa was stored in the upper
22 bits, and the exponent was stored in the lowest 10 bits.
If either mantissa or exponent was negative, that value
was held in two's complement form, respectively.
The mantissa was stored as fixed-point binary, with 31 binary places.
> This is the easiest and most convenient format for software,
> since you have two integers.
Not so. See above. Only the exponent is held in integer form.
Quadibloc
May 22, 2021, 12:11:15 PM5/22/21
to
On Saturday, May 22, 2021 at 8:51:07 AM UTC-6, Bob Eager wrote:
> No, the NCR/Elliott/ICL 4100 series. 4120 with software floating point,
> 4130 with hardware floating point.
>
> The first machine I really used, and programmed in assembler.
I had to use the Wayback Machine to follow up one of the links on your site...
> No, the NCR/Elliott/ICL 4100 series. 4120 with software floating point,
> 4130 with hardware floating point.
>
> The first machine I really used, and programmed in assembler.
that page spoke of a mysterious graphical display for the computer.
I encountered an issue of the Computer Weekly with a photograph of
"an Elliott 4100 graphical display actually in use"... for laying out pipes
at a chemical plant.
But while I had again found information I had seen previously on its
instruction formats, all I could find out about its floating-point format
was that it consisted of a 39-bit mantissa and a 9-bit exponent.
John Savard
Quadibloc
May 22, 2021, 12:14:30 PM5/22/21
to
On Saturday, May 22, 2021 at 10:10:50 AM UTC-6, Robin Vowels wrote:
> The mantissa is not usually stored as an integer.
> It is usually stored as a binary fixed-point value,
> to 30 or 31 binary places (32-bit words), so that the value of the
> mantissa lies between -0.5 and +0.5. That is, the mantissa is
> normalised.
Yes, the Burroughs machines (and the new decimal floating-point
> The mantissa is not usually stored as an integer.
> It is usually stored as a binary fixed-point value,
> to 30 or 31 binary places (32-bit words), so that the value of the
> mantissa lies between -0.5 and +0.5. That is, the mantissa is
> normalised.
standard) are among the very few exceptions to that.
However, normalized binary fixed-point values can be processed
in the arithmetic unit normally used for integers. Again, I was
oversimplifying to avoid getting into complications.
John Savard
Bob Eager
May 22, 2021, 1:03:33 PM5/22/21
to
that to have more, but it didn't.
That was the packed version of the format. You could also store a 3 word
(well, 2.5) version that had a 48 bit mantissa and a 12 bit exponent.
That was what the floating point register actually used.
Quadibloc
May 22, 2021, 1:15:02 PM5/22/21
to
On Saturday, May 22, 2021 at 11:03:33 AM UTC-6, Bob Eager wrote:
> That was the packed version of the format. You could also store a 3 word
> (well, 2.5) version that had a 48 bit mantissa and a 12 bit exponent.
> That was what the floating point register actually used.
Shades of the 8087's Temporary Real format!
> That was the packed version of the format. You could also store a 3 word
> (well, 2.5) version that had a 48 bit mantissa and a 12 bit exponent.
> That was what the floating point register actually used.
John Savard
Bob Eager
May 22, 2021, 4:01:59 PM5/22/21
to
As I understand it (you will know) the IBM 370 etc. format has some
problems with maintaining accuracy, and they had to engineer special math
libraries to help with that.
It also seems that ICL adopted the same format for the 2900 series in the
name of compatibility, although why that would matter...
Quadibloc
May 22, 2021, 6:32:57 PM5/22/21
to
On Saturday, May 22, 2021 at 2:01:59 PM UTC-6, Bob Eager wrote:
> As I understand it (you will know) the IBM 370 etc. format has some
> problems with maintaining accuracy, and they had to engineer special math
> libraries to help with that.
I wasn't aware IBM did create _special_ math libraries to help correct for
> As I understand it (you will know) the IBM 370 etc. format has some
> problems with maintaining accuracy, and they had to engineer special math
> libraries to help with that.
the weakness in their FP format.
Yes, there was a weakness: since the exponent was a power of 16 and not a power
of 2, the effective precision would vary during a computation, which would inject
random noise. So people had to be more careful about numerical analysis when
writing programs.
> It also seems that ICL adopted the same format for the 2900 series in the
> name of compatibility, although why that would matter...
instead of printing it out in ASCII or EBCDIC.
John Savard
Bob Eager
May 22, 2021, 7:09:55 PM5/22/21
to
On Sat, 22 May 2021 15:32:55 -0700, Quadibloc wrote:
> On Saturday, May 22, 2021 at 2:01:59 PM UTC-6, Bob Eager wrote:
>
>> As I understand it (you will know) the IBM 370 etc. format has some
>> problems with maintaining accuracy, and they had to engineer special
>> math libraries to help with that.
>
> I wasn't aware IBM did create _special_ math libraries to help correct
> for the weakness in their FP format.
I can't remember where I read that. It may have been a slightly mangled
> On Saturday, May 22, 2021 at 2:01:59 PM UTC-6, Bob Eager wrote:
>
>> As I understand it (you will know) the IBM 370 etc. format has some
>> problems with maintaining accuracy, and they had to engineer special
>> math libraries to help with that.
>
> I wasn't aware IBM did create _special_ math libraries to help correct
> for the weakness in their FP format.
reference to this:
https://dl.acm.org/doi/abs/10.1147/sj.101.0039
John Levine
May 22, 2021, 9:06:32 PM5/22/21
to
According to Quadibloc <jsa...@ecn.ab.ca>:
It had high quality implementations of several hundred mathenatical and statistical
operations intended to work with the 360's floating point.
http://www.ebyte.it/library/downloads/IBM_System360_SSP.pdf
>Yes, there was a weakness: since the exponent was a power of 16 and not a power
>of 2, the effective precision would vary during a computation, which would inject
>random noise. So people had to be more careful about numerical analysis when
>writing programs.
Right. They also truncated instead of rounding results, and the hex exponent meant
they couldn't use the hidden bit trick. So each operation lost three bits of accuracy
relative to a well-designed binary format. IBM sort of fixed that with double precison
and starting on the 360/85, quad precision for some operations.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
>On Saturday, May 22, 2021 at 2:01:59 PM UTC-6, Bob Eager wrote:
>
>> As I understand it (you will know) the IBM 370 etc. format has some
>> problems with maintaining accuracy, and they had to engineer special math
>> libraries to help with that.
>
>I wasn't aware IBM did create _special_ math libraries to help correct for
>the weakness in their FP format.
IBM wrote the Scientific Subroutine Package in 360 Fortran in the 1960s.
>
>> As I understand it (you will know) the IBM 370 etc. format has some
>> problems with maintaining accuracy, and they had to engineer special math
>> libraries to help with that.
>
>I wasn't aware IBM did create _special_ math libraries to help correct for
>the weakness in their FP format.
It had high quality implementations of several hundred mathenatical and statistical
operations intended to work with the 360's floating point.
http://www.ebyte.it/library/downloads/IBM_System360_SSP.pdf
>Yes, there was a weakness: since the exponent was a power of 16 and not a power
>of 2, the effective precision would vary during a computation, which would inject
>random noise. So people had to be more careful about numerical analysis when
>writing programs.
they couldn't use the hidden bit trick. So each operation lost three bits of accuracy
relative to a well-designed binary format. IBM sort of fixed that with double precison
and starting on the 360/85, quad precision for some operations.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Quadibloc
May 22, 2021, 9:33:01 PM5/22/21
to
On Saturday, May 22, 2021 at 7:06:32 PM UTC-6, John Levine wrote:
> Right. They also truncated instead of rounding results, and the hex exponent meant
> they couldn't use the hidden bit trick. So each operation lost three bits of accuracy
> relative to a well-designed binary format. IBM sort of fixed that with double precison
> and starting on the 360/85, quad precision for some operations.
And then they even came out, after the 8087 became popular, with an RPQ for "High
> Right. They also truncated instead of rounding results, and the hex exponent meant
> they couldn't use the hidden bit trick. So each operation lost three bits of accuracy
> relative to a well-designed binary format. IBM sort of fixed that with double precison
> and starting on the 360/85, quad precision for some operations.
Accuracy Arithmetic" which copied everything else from IEEE 754 except the hidden
bit in an alternate set of floating-point instructions for the 370.
It's on Bitsavers. SA-7093-0.
John Savard
Peter Flass
May 22, 2021, 9:38:26 PM5/22/21
to
--
Pete
Peter Flass
May 22, 2021, 9:38:27 PM5/22/21
to
Bob Eager <news...@eager.cx> wrote:
> On Sat, 22 May 2021 15:32:55 -0700, Quadibloc wrote:
>
>> On Saturday, May 22, 2021 at 2:01:59 PM UTC-6, Bob Eager wrote:
>>
>>> As I understand it (you will know) the IBM 370 etc. format has some
>>> problems with maintaining accuracy, and they had to engineer special
>>> math libraries to help with that.
>>
>> I wasn't aware IBM did create _special_ math libraries to help correct
>> for the weakness in their FP format.
>
> I can't remember where I read that. It may have been a slightly mangled
> reference to this:
>
> https://dl.acm.org/doi/abs/10.1147/sj.101.0039
I think it was the “high accuracy” math library. From somewhere I get a
> On Sat, 22 May 2021 15:32:55 -0700, Quadibloc wrote:
>
>> On Saturday, May 22, 2021 at 2:01:59 PM UTC-6, Bob Eager wrote:
>>
>>> As I understand it (you will know) the IBM 370 etc. format has some
>>> problems with maintaining accuracy, and they had to engineer special
>>> math libraries to help with that.
>>
>> I wasn't aware IBM did create _special_ math libraries to help correct
>> for the weakness in their FP format.
>
> I can't remember where I read that. It may have been a slightly mangled
> reference to this:
>
> https://dl.acm.org/doi/abs/10.1147/sj.101.0039
memory that this was implemented in microcode for System/370.
--
Pete
John Levine
May 22, 2021, 9:47:47 PM5/22/21
to
According to Bob Eager <news...@eager.cx>:
One clever version of it was on 286 based DOS PCs, where the 287
floating point chip was optional. Unfortunately, if you didn't have a
287 the float instructions didn't trap, they just did nothing. The C
compiler we used Wizard C (which later became Borland's Turbo C)
generated floating point instructions preceded by a CD "interrupt"
instruction. The first byte of every float instruction was in the
range D8 through DF so the interrupt handler for those interrupts
checked to see if there was a 287 and if so patched the CD to 90,
no-op, backed up the saved PC and returned. Or without a 287 it did
the operation in software.
That let the same code run at close to full speed with a 287 or interpreted without.
>The entry level machine had all floating point opcodes cause an
>'extracode trap', whereupon the operation was handled in software.
>
>The more expensive machines had hardware implementation of that same
>format.
That trick was used over and over again.
>'extracode trap', whereupon the operation was handled in software.
>
>The more expensive machines had hardware implementation of that same
>format.
One clever version of it was on 286 based DOS PCs, where the 287
floating point chip was optional. Unfortunately, if you didn't have a
287 the float instructions didn't trap, they just did nothing. The C
compiler we used Wizard C (which later became Borland's Turbo C)
generated floating point instructions preceded by a CD "interrupt"
instruction. The first byte of every float instruction was in the
range D8 through DF so the interrupt handler for those interrupts
checked to see if there was a 287 and if so patched the CD to 90,
no-op, backed up the saved PC and returned. Or without a 287 it did
the operation in software.
That let the same code run at close to full speed with a 287 or interpreted without.
Robin Vowels
May 22, 2021, 10:16:15 PM5/22/21
to
On Sunday, May 23, 2021 at 6:01:59 AM UTC+10, Bob Eager wrote:
> On Sat, 22 May 2021 10:15:01 -0700, Quadibloc wrote:
>
> > On Saturday, May 22, 2021 at 11:03:33 AM UTC-6, Bob Eager wrote:
> >
> >> That was the packed version of the format. You could also store a 3
> >> word (well, 2.5) version that had a 48 bit mantissa and a 12 bit
> >> exponent. That was what the floating point register actually used.
> >
> > Shades of the 8087's Temporary Real format!
> Indeed. I was reminded of that.
>
> As I understand it (you will know) the IBM 370 etc. format has some
> problems with maintaining accuracy, and they had to engineer special math
> libraries to help with that.
.
> On Sat, 22 May 2021 10:15:01 -0700, Quadibloc wrote:
>
> > On Saturday, May 22, 2021 at 11:03:33 AM UTC-6, Bob Eager wrote:
> >
> >> That was the packed version of the format. You could also store a 3
> >> word (well, 2.5) version that had a 48 bit mantissa and a 12 bit
> >> exponent. That was what the floating point register actually used.
> >
> > Shades of the 8087's Temporary Real format!
> Indeed. I was reminded of that.
>
> As I understand it (you will know) the IBM 370 etc. format has some
> problems with maintaining accuracy, and they had to engineer special math
> libraries to help with that.
IBM modified the 360 hardware to include a guard digit for floating-point.
.
Not heard of any special libraries.
Robin Vowels
May 22, 2021, 10:22:39 PM5/22/21
to
On Sunday, May 23, 2021 at 11:06:32 AM UTC+10, John Levine wrote:
> According to Quadibloc <jsa...@ecn.ab.ca>:
> >On Saturday, May 22, 2021 at 2:01:59 PM UTC-6, Bob Eager wrote:
> >
> >> As I understand it (you will know) the IBM 370 etc. format has some
> >> problems with maintaining accuracy, and they had to engineer special math
> >> libraries to help with that.
> >
> >I wasn't aware IBM did create _special_ math libraries to help correct for
> >the weakness in their FP format.
> IBM wrote the Scientific Subroutine Package in 360 Fortran in the 1960s.
> It had high quality implementations of several hundred mathenatical and statistical
> operations intended to work with the 360's floating point.
>
> http://www.ebyte.it/library/downloads/IBM_System360_SSP.pdf
> >Yes, there was a weakness: since the exponent was a power of 16 and not a power
> >of 2, the effective precision would vary during a computation, which would inject
> >random noise. So people had to be more careful about numerical analysis when
> >writing programs.
> Right. They also truncated instead of rounding results, and the hex exponent meant
> they couldn't use the hidden bit trick. So each operation lost three bits of accuracy
.
> According to Quadibloc <jsa...@ecn.ab.ca>:
> >On Saturday, May 22, 2021 at 2:01:59 PM UTC-6, Bob Eager wrote:
> >
> >> As I understand it (you will know) the IBM 370 etc. format has some
> >> problems with maintaining accuracy, and they had to engineer special math
> >> libraries to help with that.
> >
> >I wasn't aware IBM did create _special_ math libraries to help correct for
> >the weakness in their FP format.
> IBM wrote the Scientific Subroutine Package in 360 Fortran in the 1960s.
> It had high quality implementations of several hundred mathenatical and statistical
> operations intended to work with the 360's floating point.
>
> http://www.ebyte.it/library/downloads/IBM_System360_SSP.pdf
> >Yes, there was a weakness: since the exponent was a power of 16 and not a power
> >of 2, the effective precision would vary during a computation, which would inject
> >random noise. So people had to be more careful about numerical analysis when
> >writing programs.
> Right. They also truncated instead of rounding results, and the hex exponent meant
> they couldn't use the hidden bit trick. So each operation lost three bits of accuracy
No it didn't.
For single precision, only 21 bits of the 24 available were guaranteed, etc.
.
Robin Vowels
May 22, 2021, 10:25:38 PM5/22/21
to
On Sunday, May 23, 2021 at 6:01:59 AM UTC+10, Bob Eager wrote:
> On Sat, 22 May 2021 10:15:01 -0700, Quadibloc wrote:
>
> As I understand it (you will know) the IBM 370 etc. format has some
> problems with maintaining accuracy, and they had to engineer special math
> libraries to help with that.
.
>
> As I understand it (you will know) the IBM 370 etc. format has some
> problems with maintaining accuracy, and they had to engineer special math
> libraries to help with that.
The IBM 370 introduced an improved HER and HDR instruction that
normalised after the halving process.
Quadibloc
May 23, 2021, 5:42:04 AM5/23/21
to
On Saturday, May 22, 2021 at 8:16:15 PM UTC-6, Robin Vowels wrote:
> IBM modified the 360 hardware to include a guard digit for floating-point.
Yes. That modification took place very shortly after the 360 was released,
> IBM modified the 360 hardware to include a guard digit for floating-point.
because it turned out that the behavior of FP without a guard digit on the
initial machines was disastrous.
Even with the guard digit, with a hex exponent, and with truncation instead
of rounding, IBM floating-point was not the greatest, and so care in numerical
analysis was required with it. Of course, the Cray I was even worse, and the
MANIAC II hardly bears thinking of.
John Savard
0 new messages