S
The other operations were much faster than multiplication and division, so it was probably deemed unnecessary to speed them up when shorter precisions were selected.
Multiplication and division, being much slower than the other operations, probably stood to benefit the most from the variable precision. Using 8 digits could be 2.7-3.8x faster than 14 digits. (4/4)
There’s a picture of this on Ken Shirriff’s @kenshirriff site, along with the consoles of the other 360 models. In the 360/44 pic, the knob is the bottom one of the trio of knobs at the center left.
The IBM System/360 was a groundbreaking family of mainframe computers announced on April 7, 1964. Designing the System/360 was an extremely...
(www.righto.com)
There is a general description of this feature on the Wikipedia page:
and fortunately it has a link to original source material on bitsavers:
https://bitsavers.org/pdf/ibm/360/functional_characteristics/A22-6875-5_360-44_funcChar.pdf (2/4)
Page 13 describes how this works. The value always occupied 64 bits, but digits beyond the selected precision were zeroed. It says “Model 44 always performs long-precision arithmetic with 56 bits.” So how were the lower-precision formats faster? The timing table on p. 15 reveals that only multiplication and division operations changed speed depending on the selected precision. Other operations’ timings were unchanged. (3/4)
@JohnMashey @SteveBellovin @markd @aka_pugs Speaking of the 360/44 and (previously) of IBM’s hex floating point, I went down a little rabbit hole I thought I’d share here. The 360/44 had variable-precision FP. Using a knob on the front panel, you could select long precision to have 8, 10, 12, or 14 hex digits, allowing you to trade precision for speed. (1/4)
@JohnMashey @SteveBellovin @aka_pugs @markd Ah, the “Motivation” section on that page covers it. Thank you.
@SteveBellovin @aka_pugs @JohnMashey @markd Very interesting. I’ve always suspected (or maybe I heard somewhere long ago) that the hex floating point was done for speed. I’m trying to understand why it would be faster. I’m guessing that most FP ops require a lot of shifting, and shifting by 4 bit places at a time would require fewer cycles than shifting 1 bit place at a time, but perhaps the folks here would know more.
@mwichary Arrrgh! The tractor-fed paper is misaligned!! 
On another note, the Data General stuff is *very* blue.
@aka_pugs @JohnMashey @markd @SteveBellovin Huh, interesting comment on hex floating point. I’ve long thought that a controversial choice. I remember hearing an IBM numerical analyst claim that the hex floating point was “cleaner” than competing formats (this predated IEEE 754) but much literature today echoes the criticism given here that the hex format effectively shortens the significand.
@rbreich I’m glad to hear you’re running. I’m 100% behind you! That’s mainly because I’m slow AF.
@jik Indeed.
@jik FWIW HP apparently had an unconditional 15-minute hold time for support calls. Even they eventually realized it was a bad idea…. (article from Feb 2025). https://arstechnica.com/gadgets/2025/02/misguided-hp-customer-support-approach-included-forced-15-minute-call-wait-times/
