On Mon, Nov 24, 2014 at 11:51:06AM +0100, Bert Freudenberg wrote:
>
> On 24.11.2014, at 05:09, David T. Lewis <lewis at mail.msen.com> wrote:
> > (*) As a former field service engineer for Harris Computer Systems, I
still
> > consider the 48-bit floating point format of the H800 series to be
superior to
> > the awkward compromises of 32-bit and 64-bit floating point
representations ;-)
> > See pages 2-2 and 6-1 of the manual for descriptions of the floating
point data
> > formats (I think I have a paper copy of this moldering away in my
basement).
> >
> > http://bitsavers.informatik.uni-stuttgart.de/pdf/harris/0830007-000_Series_800_Reference_Man_Aug79.pdf
>
> Oh, I got excited for a moment there, thinking that maybe this could be
> the origin of Smalltalk-78's weird 48 bit floating point format. But it's
> completely different.


It's just a coincidence I'm sure. A 48 bit float makes a lot of sense.
Minicomputers were typically 16 bit machines, but the H800 was a 24 bit
machine with 48 and 96 bit floating point data types and 24 bit registers.
24 bits was a lot of address space, and a 48 bit float was far superior to
a 32 bits for scientific and numeric computing. In those days, "Super
Minicomputer" was a market category, and the H800 was marketed that way,
targeting applications such as finite element analysis.

I would not be surprised if 16 bit Smalltalk systems arrived at similar
conclusions for general purpose floating point representation. 32 bits
would have been too small, and 64 bits too big. 48 bits was just about the
right size to be useful for serious work on a small machine.

Very large mantissa ranges also make sense for interative numeric work,
where I expect that they would reduce the need to keep track of numeric
overflow in some kinds of calculations (just guessing, but I'm sure that
was the reason).

> I had to reverse-engineer it because Dan could not remember (only later
> we got a printout of the VM's 8086 assembly source code). It's optimized
> for a software implementation with the mantissa on a 16-bit word boundary.
> Not sure why the exponent's sign bit is in the LSB though. But 16 bits of
> exponent, can you imagine the range? Luckily there were no insanely large
> instances in the snapshot. They get converted to modern floats when parsing
> the original object space dump:
>
>     wordsAsFloat: function() {
>         // layout of NoteTaker Floats (from MSB):
>         // 15 bits exponent in two's complement without bias, 1 bit sign
>         // 32 bits mantissa including its highest bit (which is implicit
in IEEE 754)
>         if (this.words[1] == 0) return 0.0; // if high-bit of mantissa
is 0, then it's all zero
>         var nt0 = this.words[0], nt1 = this.words[1], nt2 = this.words[2],
>             ntExponent = nt0 >> 1, ntSign = nt0 & 1, ntMantissa = (nt1 &
0x7FFF) << 16 | nt2, // drop high bit of mantissa
>             ieeeExponent = (ntExponent + 1022) & 0x7FF, // IEEE: 11 bit
exponent, biased
>             ieee = new DataView(new ArrayBuffer(8));
>         // IEEE is 1 sign bit, 11 bits exponent, 53 bits mantissa
omitting the highest bit (which is always 1, except for 0.0)
>         ieee.setInt32(0, ntSign << 31 | ieeeExponent << (31-11) |
ntMantissa >> 11); // 20 bits of ntMantissa
>         ieee.setInt32(4, ntMantissa << (32-11)); // remaining 11 bits of
ntMantissa, rest filled up with 0
>         // why not use setInt64()? Because JavaScript does not have 64
bit ints
>         return ieee.getFloat64(0);
>     }
>

Cool! I had no idea that you were dialing your wayback machine this far
back in time. Very impressive indeed.

Dave