Happy Mainframe Day
-
@JohnMashey @hyc @aka_pugs @markd Brooks said that the 24-bit address decision was an economic one. But he also recognized, and stated, that "every successful architecture runs out of address space." (Aside: that's one reason why IPv6 addresses are 128 bits instead of 64—I and a few others insisted on it, and I specifically quoted Brooks' observation.) But there was one really crucial error in the S/360 architecture: the Load Address instruction was defined by the architecture to zero the high-order byte, making it impossible to use that instruction on 32-bit address machines. Since LA was the most common instruction used, per actual hardware traces, this was a serious issue. (It wasn't only used for addresses; indeed, many of the instances were to provide what Brooks called the "indispensable small positive constant".) The I/O architecture was also 24-bit, but that didn't bother the architects—they figured it would be replaced with something smarter later on anyway.
Update: I forgot about the Branch and Link instructions, which were used for subroutine calls. Per the Principles of Operation manual, "The rightmost 32 bits of the PSW, including the updated instruction address, are stored." The high-order 8 bits of the PSW included the "condition code", used for conditional branches, and the "program mask", which could be and was changed by application programs to disable some software-related interrupts, e.g., fixed-point overflow. This instruction was also not 32-bit-address compatible. (In Blaauw and Brooks, they note that extension to 32-bit addressing was seen as desirable and necessary from the very beginning.)
@SteveBellovin @hyc @aka_pugs @markd
Agreed, I wrote a lot of S/360 assembly code & LA was very useful.
Although not architectural, but software convention, using high-order bit in last ptr argument in argument list persisted.On economics, I do wonder how much $ the 360/30-based decision cost IBM in the long term, in terms of software/hardware complexity.
-
@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.
@stuartmarks @aka_pugs @JohnMashey @markd I checked what Blaauw and Brooks said about the S/360 floating point architecture. "The use of a hexadecimal base was intended to speed up the implementation, yet the resulting loss of precision was underestimated. The absence of a guard digit in the 64-bit format had to be corrected soon after the first machines were delivered."
-
@SteveBellovin @aka_pugs If you were on the non-EBCDIC side of the fence you got the impression that IBM sales pushed EBCDIC pretty hard as a competitive advantage - even if their engineering covertly preferred ASCII.
The 32-bit word must have been a harder-sell for the blue suits since the competition were selling 60bit and 36bit amongst other oddballs.
Fortunately the emergence of commercial customers marked the declining relevance of scientific computing... Did IBM get lucky or were they prescient?
But yeah, the S/360 definitely marked the end of the beginning of computing in multiple ways.
@markd @aka_pugs It's not clear to me that scientific computing declined in relevance then. But the S/360 line was, as @JohnMashey indicated, a way to unify the scientific and commercial lines of computers. (To be sure, on the lower-end models, the decimal instruction set and the floating point instruction set were options—and the 360/91 emulated the decimal instructions in the kernel (which IBM calls a nucleus).) One interesting way this was relevant: memory parity. Before the S/360, commercial computers had parity bits on memory; scientific ones did not. After all, commercial computers were used for things like banking, where you couldn't afford to lose money because of a hardware problem, whereas scientific computers were only used for things like bridge and nuclear reactor design, which of course don't cost money… There was also the moral issue—lives could be at stake—which was also Brooks' justification for insisting that all S/360s (including the /44, intended only for scientific computing) would have parity. The CDC 6600, a supercomputer of the day, did not have parity; the designer, Seymour Cray, said "Parity is for farmers" (https://en.wikipedia.org/wiki/ECC_memory#Personal_computers). The successor, the 7600, did have parity. (Note: to understand Cray's line, see https://en.wikipedia.org/wiki/Doctrine_of_parity.)
-
@aka_pugs @markd @SteveBellovin
But still, FORTRAN IV got lots of use especially on 360/50…85 in universities & R&D labs. i suspect not much on /30 /40.
I still think of 360 as a huge bet to consolidate the chaos of the 701…7094 36-bit path and the 702…7074 &1401 variable-string paths.
And for fun: I asked both Gene Amdahl & Fred Brooks why they used 24-bit addressing, ignoring high 8-bits… which caused a lot of problems/complexity later.
A: save hardware on 360/30, w/8-bit data paths.@JohnMashey @aka_pugs @markd The purpose of the higher-end machines was to sell the very profitable lower-end machine, by showing that there was an upgrade path. And then they blew it by having incompatible operating systems…
-
@stuartmarks @aka_pugs @JohnMashey @markd There are many different points here to respond to; let me first address the EBCDIC/ASCII issue, and why IBM's sales reps pushed it.
As @aka_pugs pointed out, IBM had a huge commercial data processing business dating back to the pre-computer punch card days. (IBM was formed by the merger of several companies, including Hollerith's own.) Look at the name of the company: International *Business* Machines. You could do amazing things with just punch card machines—Arthur Clarke's classic 1946 story Rescue Party (https://en.wikipedia.org/wiki/Rescue_Party) referred in passing to "Hollerith analyzers". But punch cards had a crucial limit: your life was much better if all of the data for a record fit onto a single 80-column card. This meant that space was at a premium, so it was common to overpunch numeric columns, e.g., age, with "zone punch" in the 11 or 12 rows. Thus, a card column with just a punch in the 1 row was the digit 1, but if it had a row 12 punch as well it was either the letter A *or* the digit 1 and a binary signal for whatever was encoded by the row 12 punch. The commercial computers of the 1950s, which used 6-bit "bytes" for decimal digits as "BCD"—binary-coded decimal—mirrored this: the two high-order bits could be encoded data.
The essential point here is that with BCD, it was possible to do context-free decomposition, in a way that you couldn't do with ASCII. The IBM engineers wanted the S/360 to be an ASCII machine, but the big commercial customers pushed back very hard. IBM bowed to the commercial reality (but with the ASCII bit for dealing with "packed decimal" conversions), and marketed the machine that way: "you don't have to worry about your old data, because EBCDIC"—extended BCD interachange code—"your old files are still good." That's why the sales people talked it up—they saw this as a major commercial advantage.@SteveBellovin @stuartmarks @aka_pugs @JohnMashey All of which (punch card focus, overloading high order pointer bits, packed decimal, 6bit bytes, scientific vs commercial, memory parity, two-speed memory) signalled the beginning of the end of an era where programmers and engineers counted every bit, every machine cycle and every memory reference. An era where programmers optimised hardware rather than round the other way.
While the need to deal with feeble compute power created interesting and novel architectures (Singer System Ten anyone? - https://en.wikipedia.org/wiki/Singer_System_Ten), the lock-in was a nightmare for customers embarking on their (oftentimes first) tech refresh.
So sure, one can readily admire the S/360 design, nonetheless, its biggest contribution may have been as an extinction event for all those oddball architectures due to market dominance.
-
@SteveBellovin @stuartmarks @aka_pugs @JohnMashey All of which (punch card focus, overloading high order pointer bits, packed decimal, 6bit bytes, scientific vs commercial, memory parity, two-speed memory) signalled the beginning of the end of an era where programmers and engineers counted every bit, every machine cycle and every memory reference. An era where programmers optimised hardware rather than round the other way.
While the need to deal with feeble compute power created interesting and novel architectures (Singer System Ten anyone? - https://en.wikipedia.org/wiki/Singer_System_Ten), the lock-in was a nightmare for customers embarking on their (oftentimes first) tech refresh.
So sure, one can readily admire the S/360 design, nonetheless, its biggest contribution may have been as an extinction event for all those oddball architectures due to market dominance.
@markd @stuartmarks @aka_pugs @JohnMashey Sure—and IBM did have excellent salespeople. But what should they have done? The IBM 7030 (https://en.wikipedia.org/wiki/IBM_7030_Stretch ) was a dead end, though the engineers learned a lot, and the IBM 8000 (https://en.wikipedia.org/wiki/IBM_8000) was canceled. IBM was by no means omniscient, and its attempts at smaller computers (the 1130 and 1800 and the 360/20 and /44) had much less interesting architectures than, say, the PDP-11 or the later VAX. It was by no means obvious, in 1964, that the S/360 was going to be a runaway market success, and it was very much a bet-the-company project. (Aside: Brooks offered his resignation to TJ Watson after the 8000 was canceled. Watson replied, "I just spent a billion dollars educating you; why should I fire you now?"—and Brooks became the chief architect of the S/360.)
There have been many technical criticisms of the S/360 architecture. Most of those concerned issues that Brooks, Blaauw, and Amdahl considered and rejected, e.g., a stack architecture, as infeasible given the technology of the time. And yes, they did make mistakes, as I pointed out earlier; the design was by no means perfect -
@markd @stuartmarks @aka_pugs @JohnMashey Sure—and IBM did have excellent salespeople. But what should they have done? The IBM 7030 (https://en.wikipedia.org/wiki/IBM_7030_Stretch ) was a dead end, though the engineers learned a lot, and the IBM 8000 (https://en.wikipedia.org/wiki/IBM_8000) was canceled. IBM was by no means omniscient, and its attempts at smaller computers (the 1130 and 1800 and the 360/20 and /44) had much less interesting architectures than, say, the PDP-11 or the later VAX. It was by no means obvious, in 1964, that the S/360 was going to be a runaway market success, and it was very much a bet-the-company project. (Aside: Brooks offered his resignation to TJ Watson after the 8000 was canceled. Watson replied, "I just spent a billion dollars educating you; why should I fire you now?"—and Brooks became the chief architect of the S/360.)
There have been many technical criticisms of the S/360 architecture. Most of those concerned issues that Brooks, Blaauw, and Amdahl considered and rejected, e.g., a stack architecture, as infeasible given the technology of the time. And yes, they did make mistakes, as I pointed out earlier; the design was by no means perfect@SteveBellovin @markd @stuartmarks @aka_pugs
Indeed, truly bet-the company, and despite the issues, still pretty good. -
@aka_pugs @mappingsupport So you could use ASCII character terminals with a mainframe?
I know the 3270s were more like a browser where you got a whole screenful at a time, and the response was only sent back when you pressed enter or a function key.
I ran into one of those IBM block terminals at a university library once, and it's still one of the fastest interactive query systems I've ever seen. They had that optimized.
@mike805 @aka_pugs @mappingsupport Many large libraries used NOTIS https://en.wikipedia.org/wiki/NOTIS which ran exclusively on System/360 and successor architectures. I wouldn't be surprised if there were some still running it on a zSeries mainframe today.
-
@stuartmarks @aka_pugs @JohnMashey @markd I checked what Blaauw and Brooks said about the S/360 floating point architecture. "The use of a hexadecimal base was intended to speed up the implementation, yet the resulting loss of precision was underestimated. The absence of a guard digit in the 64-bit format had to be corrected soon after the first machines were delivered."
@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.
-
@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)
