[Info-vax] Reading Gordon Bell's VAX strategy document

[gah4]

On Monday, September 25, 2023 at 11:29:39 AM UTC-7, John Dallman wrote:
> In article <cb83004a-46f6-424f... at googlegroups.com>,
> ga... at u.washington.edu (gah4) wrote: 
 
> > One not talked about much, but that I have known for a long time, is 
> > that hexadecimal floating point is more convenient for pipelining.

> Do you have a citation for that? I've been updating Wikipedia's page on 
> hexFP, simply because I'd dug into the idea a bit, and started to realise 
> why it lost more precision than the architects had expected.

I don't, though there is a little in the Blaauw and Brooks book.

Some time ago, I was thinking about how to do floating point,
and especially fast floating point, on an FPGA.  
(Not much need for slow floating point.)

The biggest part of an adder is the barrel shifter for pre,
and post-normalization.  That is, logic to shift N digits
in one operation. (No clocked shift register.) It is much easier
(and smaller) in a higher radix.  

In an FPGA with LUT4 logic, that takes N levels for 
pre-normalization, one level to do the add/subtract, and
N levels for post normalization.  

As with the previous question, if they were planning the 360/91
(well, 92) from the beginning, that might have been considered.

The 91 does floating point addition in two clock cycles, multiply in three,
single precision divide in 12, and double precision in 18. 
The divide algorithm is based on using the parallel multiplier
used for multiply.  Normalization isn't the biggest part of
those, so it isn't quite as obvious as you might want.

The other advantage of hexadecimal floating point, is that it
is a lot easier to read in hex dumps. 

In a microprogrammed machine, you can shift in hex digits.