Happy Mainframe Day
-
@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.
-
@JohnMashey @SteveBellovin @aka_pugs @markd Ah, the “Motivation” section on that page covers it. Thank you.
-
@JohnMashey @SteveBellovin @aka_pugs @markd Ah, the “Motivation” section on that page covers it. Thank you.
@stuartmarks @JohnMashey @aka_pugs @markd What I’d add: their book notes that shifting for normalization was the most expensive part of addition and subtraction, especially back then when you couldn’t afford a fast shifter on the lower-end models.
-
@SteveBellovin @markd @stuartmarks @aka_pugs
Indeed, truly bet-the company, and despite the issues, still pretty good.@JohnMashey @markd @stuartmarks @aka_pugs Other than marketing issues, I've heard three major criticisms of the architecture—and bear in mind that these decisions were made in the early 1960s; unless you were programming then or shortly thereafter, your instincts on RAM and logical complexity are likely wrong.
The first is the I/O architecture. Blaauw and Brooks, in their book, agree that it wasn't the greatest. That said, I know of some amazing (or weird) things that could be done with it, which I'll save for another day. The second is that it should have been a stack machine. That was, in fact, the original goal, but Amdahl showed that it wasn't wise from cost/performance perspective: except on the high-end models, you couldn't afford to have more than two levels of the stack in registers; the rest would be in RAM (which we called "core"…). Yes, the machine did have 16 "general registers", but it didn't need the circuitry for moving data around as entries were pushed onto or popped from the stack. The extra references to RAM were not good for performance, and needed more logic.
The third was addressing: the S/360 used "base-displacement" addressing for RAM. An actual address was the sum of a general register's contents and a 12-bit displacement.* Together, the two fields occupied 16 bits. To use absolute addresses, you'd have needed 32 bits, plus more for an index register and probably an indirect address bit. The cost in RAM for instruction space and in time to fetch the extra data from memory—this was before memory caches, which weren't until four years later—was prohibitive. (I once overheard a conversation between Blaauw and Brooks on that topic, ~10 years after that S/360 was announced—they still didn't see what they could have done differently, given the technology of the time.) As a fringe benefit, writing position-independent and reentrant code became very easy, and object and executable files needed very little disk space for relocation information.
One thing often missed about the S/360 is one of the things Brooks was proudest of: how precisely they were able to specify the semantics of every instruction, and have that work, across six models, the /30, /40, /50, /60, /62, and /70**, with very different implementations and price/performance.*Minor exceptions apply
**The /60, /62, and /70 were never shipped, being replaced by the /65 and /75; a variant of the /65 with virtual memory was shipped as the /67. The full history is complex; see https://en.wikipedia.org/wiki/IBM_S/360 for details. -
@JohnMashey @markd @stuartmarks @aka_pugs Other than marketing issues, I've heard three major criticisms of the architecture—and bear in mind that these decisions were made in the early 1960s; unless you were programming then or shortly thereafter, your instincts on RAM and logical complexity are likely wrong.
The first is the I/O architecture. Blaauw and Brooks, in their book, agree that it wasn't the greatest. That said, I know of some amazing (or weird) things that could be done with it, which I'll save for another day. The second is that it should have been a stack machine. That was, in fact, the original goal, but Amdahl showed that it wasn't wise from cost/performance perspective: except on the high-end models, you couldn't afford to have more than two levels of the stack in registers; the rest would be in RAM (which we called "core"…). Yes, the machine did have 16 "general registers", but it didn't need the circuitry for moving data around as entries were pushed onto or popped from the stack. The extra references to RAM were not good for performance, and needed more logic.
The third was addressing: the S/360 used "base-displacement" addressing for RAM. An actual address was the sum of a general register's contents and a 12-bit displacement.* Together, the two fields occupied 16 bits. To use absolute addresses, you'd have needed 32 bits, plus more for an index register and probably an indirect address bit. The cost in RAM for instruction space and in time to fetch the extra data from memory—this was before memory caches, which weren't until four years later—was prohibitive. (I once overheard a conversation between Blaauw and Brooks on that topic, ~10 years after that S/360 was announced—they still didn't see what they could have done differently, given the technology of the time.) As a fringe benefit, writing position-independent and reentrant code became very easy, and object and executable files needed very little disk space for relocation information.
One thing often missed about the S/360 is one of the things Brooks was proudest of: how precisely they were able to specify the semantics of every instruction, and have that work, across six models, the /30, /40, /50, /60, /62, and /70**, with very different implementations and price/performance.*Minor exceptions apply
**The /60, /62, and /70 were never shipped, being replaced by the /65 and /75; a variant of the /65 with virtual memory was shipped as the /67. The full history is complex; see https://en.wikipedia.org/wiki/IBM_S/360 for details.@SteveBellovin @markd @stuartmarks @aka_pugs
Agreed. A few more notes:
I always admired Burroughs B5000,etc for software-oriented hardware design… but seemed harder to aggressively pipeline than general-register machines. (After all, 360/44 subset was not too far away from typical RISCs)
Also, simplicity for expression evaluation was rendered less useful by global optimizing compilers with 16+ registers, ie Fortran IV(H), ~1968.
I was impressed by day course in optimization by Cocke & Allen. -
Happy Mainframe Day!
OTD 1964: IBM announces the System/360 family. 8-bit bytes ftw!Shown: Operator at console of Princeton's IBM/360 Model 91.
@aka_pugs my father-in-law showing my son (software engineer) his IBM 360 study materials:
https://photos.app.goo.gl/gtDTHsYCC7P7oUUF8
He learned on-site in NYC.
-
Happy Mainframe Day!
OTD 1964: IBM announces the System/360 family. 8-bit bytes ftw!Shown: Operator at console of Princeton's IBM/360 Model 91.
My first one was an Eastern Germany copy of a later model of the IBM 370
-
@SteveBellovin @markd @stuartmarks @aka_pugs
Agreed. A few more notes:
I always admired Burroughs B5000,etc for software-oriented hardware design… but seemed harder to aggressively pipeline than general-register machines. (After all, 360/44 subset was not too far away from typical RISCs)
Also, simplicity for expression evaluation was rendered less useful by global optimizing compilers with 16+ registers, ie Fortran IV(H), ~1968.
I was impressed by day course in optimization by Cocke & Allen.@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)
-
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.
Iconic consoles of the IBM System/360 mainframes, 55 years old
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)
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.
Iconic consoles of the IBM System/360 mainframes, 55 years old
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)
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.
Iconic consoles of the IBM System/360 mainframes, 55 years old
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)
@stuartmarks @kenshirriff Well, in looking at the model 44 functional characteristics, I'm surprised to see the 2315 disk with fixed-block size and addressing. Unlike all the Count-Key-Data drives of the rest of the line. AFAIK, FBA wouldn't should up again until the late 70s with the 3370 line.
-
@stuartmarks @kenshirriff Well, in looking at the model 44 functional characteristics, I'm surprised to see the 2315 disk with fixed-block size and addressing. Unlike all the Count-Key-Data drives of the rest of the line. AFAIK, FBA wouldn't should up again until the late 70s with the 3370 line.
@aka_pugs @stuartmarks @kenshirriff It's the same disk used for the IBM 1130 and 1800: http://ibm1130.org/hw/disk/.
