The TC-16 and Model 709: A Unique Floating-Point Format

[Quadibloc]

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

[Scott Lurndal]

Post by Quadibloc
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,
(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,
(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
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]

Post by Scott Lurndal
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
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

[Bob Eager]

Post by Quadibloc

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

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.

[Quadibloc]

Post by Bob Eager
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)

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

[Robin Vowels]

Post by Quadibloc

Post by Bob Eager
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
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)
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.

Post by Quadibloc
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.
.

Post by Quadibloc
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.
- 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.

[Quadibloc]

Post by Robin Vowels
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
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

[Quadibloc]

Post by Bob Eager
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?

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]

Post by Bob Eager
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,
4130 with hardware floating point.

The first machine I really used, and programmed in assembler.

[Quadibloc]

Post by Bob Eager
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...
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

[Bob Eager]

Post by Quadibloc

Post by Bob Eager
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...
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.

Yes, I had the same problem. I have a programmer's booklet and I expected
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]

Post by Bob Eager
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!

John Savard

[Bob Eager]

Post by Quadibloc

Post by Bob Eager
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.

It also seems that ICL adopted the same format for the 2900 series in the
name of compatibility, although why that would matter...

[Quadibloc]

Post by Bob Eager
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.

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.

Post by Bob Eager
It also seems that ICL adopted the same format for the 2900 series in the
name of compatibility, although why that would matter...

Well, it saves space on magnetic tape if you can ship your data in binary form
instead of printing it out in ASCII or EBCDIC.

John Savard

[Bob Eager]

Post by Quadibloc

Post by Bob Eager
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

[Peter Flass]

Post by Bob Eager

Post by Quadibloc

Post by Bob Eager
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
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
memory that this was implemented in microcode for System/370.

[John Levine]

Post by Quadibloc

Post by Bob Eager
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

Post by Quadibloc
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.

[Quadibloc]

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

[Robin Vowels]

Post by John Levine

Post by Quadibloc

Post by Bob Eager
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

Post by Quadibloc
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.
.

Post by John Levine
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.

[Robin Vowels]

Post by Bob Eager

Post by Quadibloc

Post by Bob Eager
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.

[Quadibloc]

Post by Robin Vowels
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,
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

[Robin Vowels]

Post by Bob Eager
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.

[Peter Flass]

Post by Bob Eager

Post by Quadibloc

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

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.

SDS 9<whatever>?

[John Levine]

Post by Bob Eager
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.

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.

[Quadibloc]

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

[Quadibloc]

Post by Quadibloc
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:

http://www.quadibloc.com/comp/cp0201.htm

John Savard