3 ms·
I definitely wasn't around then, but Fred Brooks talks about it in some of his writing, and the System/360 work is cited by his Turing award. My understanding
by chubot 7y ago
I definitely wasn't around then, but Fred Brooks talks about it in some of his writing, and the System/360 work is cited by his Turing award.
My understanding is that before System/360, software was tied to particular machines, which were naturally of a particular speed and capacity (and such resources were a very big deal back then).
When institutions bought new machines, they would MANUALLY REWRITE their software in the assembly language of the new machine. In other words, they were like manual compilers.
I think a lot of the compilers were actually specific to the machine as well! The hardware manufacturers invented their own programming language for their own machines. Portability wasn't a "thing". Many institutions probably only owned a 1 or 3 computers from the same manufacturer anyway.
So basically System/360 was a single instruction set for a lot of different machines, with differing speed and capacity. So you didn't have to do this thing that seems crazy to us today -- you could run the same software on may machines.
Software back then was really just an extension of hardware... The views have changed a lot [1]
Also from what I'm reading, the notion of an "abstract" machine was also not really a thing. There's a conceptual leap from a physical machine on your department's floor to some binary interface you can program against abstractly (the ISA), which we take for granted today.
https://amturing.acm.org/award_winners/brooks_1002187.cfm https://amturing.acm.org/award_winners/brooks_1002187.cfm
Bob Evans promoted IBM’s vision to develop a single product line of general purpose computers with a common instruction set that permitted customers to preserve their investment in software as the moved from slower machines to faster ones. Evans assigned Brooks to lead the team to design this product line, called the System/360, which was announced in 1964. Brooks coined the term “computer architecture” to mean the structure and behavior of computer processors and associated devices, as separate from the details of any particular hardware implementation.
The importance of the System /360 cannot be understated: it was a widely successful project that transformed the face of business computing and reshaped the landscape of the computer companies throughout the world. Among many important contributions to the design of the System/360, Brooks was particularly proud of the 8-bit byte, which permitted the use of uppercase and lowercase alphabets and expanded the role of computers in text processing.
While the hardware architecture for the System/360 was well underway, it was clear that there was considerable risk in delivering the operating system for the new series of machines. Brooks was assigned to lead the software team in building what was perhaps the largest operating system project of its time. Brooks describes the lessons he learned in his classic text on software engineering, The Mythical Man-Month. It is from that experience that Brooks proposed “Brook’s Law”: that “adding manpower to a late software project makes it later."
[1] For another example of how wildly views have changed, I recall that early networking assumed that if you were admin on ANY MACHINE on the network, you had admin rights on this machine. There was almost no notion of network security.
- chongli 7y agonotion of an "abstract" machine was also not really a thing That's really bizarre to me. We've had the Church-Turing Thesis since the 1930s [1]. I would've thought it ought to have occurred to computer designers from the very beginning that they were following an abstract model of computation. Perhaps they were building bespoke programming languages for their computers in order to achieve lock-in? [1] https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis
- Someone 7y ago”I would've thought it ought to have occurred to computer designers from the very beginning that they were following an abstract model of computation” They were building bespoke instruction sets because nobody knew what a good instruction set looked like. The size of a byte wasn’t even settled upon yet (also, hardware changed significantly all the time, changing what the best instruction set looked like. If RAM gets ten times faster tomorrow, for example, CPUs might drop a few cache levels) There also was the fairly significant pressure of stuffing whatever you built in a few kilobytes. For example, the smallest 360 (https://en.wikipedia.org/wiki/IBM_System/360_Model_20 https://en.wikipedia.org/wiki/IBM_System/360_Model_20) ran with 4 kilobytes of RAM (and for a measly $2000 a month, you got a card reader/writer/sorter and a line printer with it)
- bogomipz 7y agoThanks I was familiar with the historical importance of IBM's System/360 but what is connection between System/360 and RISC-V? That was what I didn't understand in the OP's comment.
- PaulHoule 7y agoThe "360" in System/360 meant "General Purpose" or "Scalable". That is, you could get it in many different sizes and expect that you could buy a bigger one in the future that is compatible with your old programs. Contrast that to DEC, which had a PDP-8 that was comparable to the smallest 360 but cost about 1/5 as much. If you needed something better you needed to upgrade to the PDP-10 or PDP-11, neither of which was compatible with your PDP-8 programs. PDP-11 was wildly popular but it had no path to 32-bit, so DEC introduced the VAX architecture... Each need to go to an incompatible system was a chance to switch vendors, and that could be one reason IBM is still here and DEC isn't. Today the x86, POWER, and ARM architectures have all had long rides of continuous improvement, so the scalability ideas of the 360 are mainstream. RISC-V takes scalability to the next level, targeting various "backwater" areas such as storage controllers. Now that we have SSD's the processors in storage controllers can't keep up with the math to do RAID. Intel's "Rapid Storage Technology" doesn't seem like a scam anymore because there is so much excess power in the Intel architecture compared to the junk that is in contemporary storage controllers. RISC-V could create a huge market for chips that are scaled down in the ways they need to be scaled down, but scaled up in the ways they need to be scaled up. For instance that storage controller might need to be wicked fast, but it doesn't need floating point and it doesn't need virtual memory. RISC-V lets you pick and choose features but still stick with the some toolset for building code; thus you could port some software between chips with different capabilities.