75 views

Skip to first unread message

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

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.

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

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.

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

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

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

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

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

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.

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.

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

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

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.

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

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

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

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

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

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

May 22, 2021, 9:38:26 PM5/22/21

to

--

Pete

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

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.

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.

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.

.

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.

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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu