A Complete History Of Mainframe Computing

Chuck Guzis cclist at sydex.com
Thu Jul 2 22:07:13 CDT 2009


On 2 Jul 2009 at 16:36, Warren Wolfe wrote:

> The same is true of ForTran.  The key was the bizarre way that
> floating point numbers were stored. in a 60 bit word.  The first 18
> bits (high order) were the exponent, and the remainder were the
> mantissa.  To assemble a FP value, place the mantissa in the lower
> bits.  1's complement it.  Then put in the exponent, and 1's
> complement it again.  Voila.

Uh, you mean 12 bits, not 18.  The mantissa was 48 bits.  A and B 
registers were 18 bits (as was the A register in the PPUs).

The high-order bit of an FP number was the sign of the mantissa; the 
exponent was biased by 2000 octal (i.e. range from 0000 to 3777).  
That was convenient because the 6000 had no condition codes--
conditional branches were performed based on the value of a specific 
register, so a sign test on the high-order bit worked for both 
integers and floating point numbers. 0000...000 was zero for both.

The 6000 series had only add and subtract for 60 bit integers; 
multiply and divide on integers were performed by using the floating-
point instructions. (There was later an "Integer Multiply" special 
feature that performed an integer multiply with the mantissas=0000 
instead of 2000 (octal).  It wasn't any faster, but you didn't have 
to pack and unpack (i.e. add and remove and exponent) the 2000 bias 
to the numbers). 
 
One oddity is that a double-precision operation involved issuing 
separate instructions to obtain the upper and lower parts of a 
result.  So, to multiply two integers, you used the double-precision 
multiply and obtained the lower 48 bits of a 96 bit product.  
Normalization of the result mantissa was not guaranteed unless both 
operands were normalized.

But in COBOL, a lot of fancy bit-twiddling (courtesy mostly of Rick 
James) allowed for direct addition of decimal numbers (10 digits at a 
pass), zero or space filling and quick conversion from decimal to 
binary with no branching.  It was possible to write a memory-to-
memory move that kept the both store units busy.

Coding for that machine was fun--the scheduling rules for 
instructions were very well documented.

--Chuck



More information about the cctalk mailing list