Tom Lyon âś…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.
MarkD@aka_pugs Really was the beginning of the modern era of computing, starting with the normalisation of 8-bit bytes and character addressable architecture.
Well, that's all true so long as we don't mention EBCDIC 🙂
Steve Bellovin@aka_pugs @markd ASCII mode was only about how some of the decimal arithmetic instructions behaved. For the printers, the character set was pretty arbitrary, and the Translate instruction would have allowed for easy compatibility no matter what. The real EBCDIC issue was the card reader—and per Fred Brooks, IBM wanted to go with ASCII but their big data processing customers talked them out of it.. But that's a story for another post. (And 8-bit bytes? Brooks felt that 8-bit bytes and 32-bit words was one of the most important innovations in the S/360 line. It wasn't a foregone conclusion—many scientific computing folks really wanted to stick with 36-bit words, for extra precision. IBM ran *lots* of simulations to assure everyone that 32 bit floating point was ok.)
Why yes, in grad school I did take computer architecture from Brooks…
@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 @SteveBellovin IBM had a huge lead in commercial data processing because of their punch card business. And that world did not care about floating point. The model 91 was an ego-relief product, not a real business. IMO.
Data processing and HPC markets never converged - until maybe AI.
JohnMashey@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.
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 @markd @SteveBellovin I love this quote from Boeing about the 360.
See https://drive.google.com/file/d/1Zb6s_Ti7ON-6DNGg8VB2VvLSbh72_bgM/view?usp=sharing
See https://drive.google.com/file/d/1Zb6s_Ti7ON-6DNGg8VB2VvLSbh72_bgM/view?usp=sharing
Stuart Marks@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 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.
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.
@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
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.
Indeed, truly bet-the company, and despite the issues, still pretty good.
@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.
@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.