On most modern computers, the two most common sizes for floating-point numbers are 32 and 64 bits in length.
A 48-bit floating-point number can provide 10 decimal digits of precision. This is the same amount as provided by many pocket calculators, and is adequate for many problems.
Thus, the NORC computer provided only one floating-point data type, which retained 13 significant digits of precision.
And a paper by Werner Bucholz on the design of the IBM 701 computer noted that its 36-bit word was chosen on the basis that a numeric precision below 10 digits would mean that double precision would be required by too many problems, while one above 12 digits would be needed for too few problems to be worthwhile.
Certainly, a 48-bit data type can be provided on a computer oriented around data sizes of 8, 16, 32, and 64 bits; but then it is provided as three 16-bit cells in memory, and whatever the width of the bus to memory, a fetch of a 48-bit floating-point quantity might in some cases require two memory accesses.
If the bus to memory were 192 bits wide, then fetches of aligned 32, 48, and 64 bit quantities would always require only one memory access; that width could be reduced to 96 bits if double-precision numbers were made 96 bits long, but that would seem excessive.
Also, many programmers working on scientific problems found that they needed to resort to double-precision calculations, when before they could use single-precision arithmetic, when the IBM 360, with a 32-bit word, replaced the IBM 7090, with a 36-bit word. On the other hand, the 60-bit word length of the Control Data 6600 provided double-precision precision that was quite adequate.
If one divides memory into 12-bit cells, 36 bits uses three of them, 48 bits four, and 60 bits five. A 720-bit wide bus to memory would be excessive (but see below).
But a computer could provide a 36-bit single precision floating-point word and a 48-bit intermediate precision floating-point word with a bus to memory that was 144 bits wide, and that would also provide for double-precision floating-point numbers that were 72 bits wide.
Since 72 bits is generous as regards precision, possibly the exponent field would be made wider for 72 bit floats, and there might be two alternate forms of 48-bit floating-point number, one with the same exponent range as 36-bit floats, and the other with the same exponent range as 72-bit floats.
The precision provided by these formats, assuming that an additional bit of precision was not obtained by the technique of suppressing the first bit used in the IEEE 754 standard, would be:
36-bit 8 digits ( 8.12781) 48-bit (limited range) 10.5 digits (10.83708) 48-bit (extended range) 9.75 digits ( 9.93399) 72-bit 18 digits (18.06180)
In parentheses is, rounded to five decimal places, the result of an exact calculation of the precision, and before that is the precision as it would be conventionally expressed from a rough rule-of-thumb calculation.
One could imagine that the floating-point format would use extremely gradual underflow, but limited to no more than 15 zeroes preceding the first one bit, using gradual underflow (involving the zero value of the exponent only) afterwards. This would have three advantages. The exponent range would be significantly extended, using the available codes, through use of extremely gradual underflow, without the nonuniform value of a zero exponent imposed by suppressing the leading one bit. The use of only gradual underflow after a point, however, would ensure that the values provided around zero were all useful ones, as extremely gradual underflow, unlike gradual underflow, does not correct this fault in conventional floating-point representations. As well, a number of codes, those which would stand for highly unnormalized numbers with nonzero exponents, are left available for use in representing Not-a-Number values, so upwards equivalence to current standards is possible.
However, using the IEEE 754 techniques instead, for all but the 72-bit floating-point, would have the particular advantage of achieving 10 digit precision for the 48-bit extended range format.
Such a machine would have a 36-bit word as its basic unit, four of them being fetched at one time from memory.
In the previous section, a number of different formats were given for machine instructions composed of 16-bit halfwords. To have a base register indicate a 64 kilobyte span of memory, instead of a 4 kilobyte span of memory, the base register reference was moved in to the first word of the instruction. This was feasible, but it proved to result in a tight squeeze as far as opcode space was concerned. An 18-bit unit for instructions would allow a three-bit base register specification and a 15-bit address to share the same portion of an instruction, allowing orthogonal specification of memory to memory operations, and providing a generous supply of opcode space.
The basic memory-reference instructions on this architecture might look like this:
Base register contents would be in units of a 144-bit memory extent; displacements might address an 18-bit unit in memory, as is required for a jump address; thus, there would be halfword arithmetic instructions, but individual characters that were 6, 8, 9 or even 16 bits long would only be accessed as part of string instructions. In the case of instructions acting on 48-bit floating-point values, the first 12 bits of the displacement would indicate which 144-bit memory extent was addressed, and the last 3 bits would contain only 0, 1, or 2, indicating which of the three aligned values in that extent was being accessed.
It might be noted that the principle of having a 36-bit word, but fetching such words in groups of four, to allow additional factors of two in the number of bits in data objects handled, could be extended further.
For example, broader generality in the sizes of data types could be obtained with a 45-bit word length. If a machine were to fetch 16 such words from memory in a single operation (perhaps due to 4-way interleaving on a 180-bit wide bus), then the resulting 720-bit unit could be divided into:
thus again providing the 36-bit single-precision floating-point number found so much more satisfactory on the IBM 7090 than the 32-bit single-precision that came later, but now no longer extending double-precision from 64 bits to 72 bits, but instead trimming it down to 60 bits, as was found perfectly adequate on the Control Data 6600 computer.
And, since 45 is divisible by 5, memory can also be divided into blocks of 10 bits, which can be used efficiently by means of Chen-Ho encoding or related systems to represent groups of three decimal digits!
Ironically, although such a scheme would allow handling of 8-bit and 16-bit wide quantities, as the only factors of 2 present are those from the number of words fetched, what this could not handle would be values that were 32 bits or 64 bits in size.
Of course, the reasons for favoring floating-point lengths of 36, 48, and 60 bits are somewhat vague: 36 bits because some programmers found the 7090 single precision adequate, but System/360 inadequate (which led to DEC trying to squeeze everything out of the 32-bit floating-point on the PDP-11, ending up with the hidden first bit we still have today in the IEEE 754 standard), 48 bits because that can give 10 digits of precision, found on many pocket calculators, and 60 bits because that was good enough for the Control Data 6600.
The NORC computer suggests an alternative way of looking at floating-point precision. I have reason to believe its floating-point numbers had 13 digits of precision.
If so, this was certainly a brave choice! But if the computer is intended to calculate results for use in 10-figure tables, having three extra digits of precision carried throughout computations might be felt to be adequate in all but the most extraordinary cases.
I concluded that it had 13 digit precision from its exponent range, 10^31 to 10^(-43), or, for those with more modern browsers, 1031 to 10-43.
Let's suppose I want to be slightly more economical, but less brave. In a binary floating-point format, 10 bits of precision provide 3 digits of precision. So 40 bits provide 12 digits, and 43 bits would provide 12.944 digits of precision. Or 42 bits with a hidden leading 1 bit.
Some binary machines had a floating-point range of about 10^38 to 10^(-38), equivalent to 2^128 to 2^(-128), and others had one twice as large, from 10^76 to 10^(-76), equivalent to 2^256 to 2^(-256). Anything larger would mean that the exponent in a floating-point number would print with three digits, altering the expected format of numbers printed in exponential notation.
So this means eight bits for the exponent. And, of course, one extra bit for the exponent sign, and one extra bit for the sign of the number.
This adds up to a 53-bit word if the leading 1 bit is not hidden. As this is a prime number, perhaps it can be understood why there had never been a plethora of architectures with a 53-bit word.
One possibility not considered so far, however, is to remain with the standard 8, 16, 32, and 64-bit division of memory, but to tolerate a small amount of waste. If we do not require that a floating-point number of presumed optimum length fit exactly into memory organized in this way, one can divide 128 bits into three words of 42 bits with two bits left over, or one can divide 256 bits into five words of 51 bits with one bit left over.
The IBM System/360 Model 44 had a knob on the front which allowed one to set it for certain jobs so that double-precision arithmetic could either remain unmodified, or it could run faster by ignoring the last 8, 16, or 24 bits of the mantissa of a double-precision number, giving effectively alternate floating-point sizes of 64, 56, 48, or 40 bits with mantissas of 56, 48, 40, and 32 bits in length, or 14, 12, 10 and 8 hexadecimal digits in length, this last set of numbers being the ones used to label the settings of that switch.
Inspired by this, desiring to continue to use a 64-bit unit, convenient to fetch by any implementation within the currently popular layout of memory, and yet not seeking to permit any waste of memory if it can be avoided, yet another alternative remains available.
When a floating-point multiplication is performed, only the mantissas of the floating-point numbers involved are multiplied. The exponents are merely added, a comparatively trivial and fast operation. And, so, one could have an intermediate-precision floating-point format that occupies 64 bits of memory, that has the precision one might expect from a 48-bit floating-point format (or one slightly larger), and that employs the bits that the reduced precision no longer requires as part of the mantissa to extend the exponent.
So, if a conventional 64-bit floating-point floating-point number uses one bit for the sign, 11 bits for an excess-1,024 exponent (or, in the case of IEEE-754, 11 bits for what I would term an excess-1,022 exponent, although the standard, putting the implied radix point of the mantissa, which it terms the significand, after the hidden first bit, speaks of it as an excess-1,023 exponent), and the remaining 52 bits for the mantissa, one could imagine that an intermediate-precision floating-point number which also occupies 64 bits could use one bit for the sign, 23 bits for the exponent, and 40 bits for the mantissa, thereby providing 12 digits of precision.
Of course, this also envisages constructing another Wallace Tree multiplier for the 40-bit mantissas, so that their products could be calculated more quickly than the products of the 52-bit mantissas of conventional double-precision numbers, with a third one for the still shorter mantissas of single-precision numbers. Thus, this assumes there is plenty of chip real estate available, and that obtaining the maximum possible floating-point performance is an overriding consideration.
Under such a circumstance, incidentally, one might also feel the need, due to the nature of Goldschmidt division, to drop, but only for division, the condition imposed by the IEEE 754 standard that the simple arithmetic operations always yield the best possible answer, even under the condition that what is truncated looks like .49999... or .50001... considering the mantissa as if it were an integer.