Heh - had to go look up storage protect, aka 'red light errors' . Kept getting in trouble in the beginning of my career when I didn't realize snooping about lit up lights on the front panel . :-)
IBM System/360 Principles of Operation (1964) [pdf]
11–20 of 36 posts
Re: IBM System/360 Principles of Operation (1964) [pdf]
#12Fair warning: this is not an introduction.
It's a typical programmer's hardware manual for the period. More or less until the IBM PC, it was normal for computer vendors to supply a detailed bit-level breakdown of instructions, memory operation, data formats, interrupt structure, and so on.
Although similar information was of course also available for the IBM PC even if it wasn't as routinely used. An assembly language reference for a PC contains much of the same information as a POO for a mainframe or mini.
Re: IBM System/360 Principles of Operation (1964) [pdf]
#13In 1970, I actually got paid a salary to write applications in this Assembler language. Abjectly inefficient, but what a blast!
Re: IBM System/360 Principles of Operation (1964) [pdf]
#14Fair warning: this is not an introduction.
It is compared to the rest of their documentation. 360s would come with a bookshelf of binders going down to the circuit level.
Re: IBM System/360 Principles of Operation (1964) [pdf]
#15In 1970, I actually got paid a salary to write applications in this Assembler language. Abjectly inefficient, but what a blast!
360 Assembly was actually pretty ok once you get past the whole EBCDIC thing. I still judge other companies documentation versus the banana book.
Re: IBM System/360 Principles of Operation (1964) [pdf]
#16This was my bible for many years. We called it POOP (Principles Of OPeration. I loved assembler on the 360 and the 370. I learned Assembly Language by cross listing my COBOL programs and using POOP to find out what the op codes meant.
Re: IBM System/360 Principles of Operation (1964) [pdf]
#17Fair warning: this is not an introduction.
It's a typical programmer's hardware manual for the period. More or less until the IBM PC, it was normal for computer vendors to supply a detailed bit-level breakdown of instructions, memory operation, data formats, interrupt structure, and so on.
Things were different in the early days. In the 1970's I worked at a company that had an IBM S/370 and a clone, an Itel AS/5.
IBM supplied hardware schematics and microcode listings for their S/370 hardware. They were in the machine room and freely available for perusal by us.
In a bit of irony, they also supplied schematics and microcode for the Itel clone. That's because the Itel was a true clone. It was designed by copying IBM's circuitry, but implemented in Motorola 10K series ECL instead of IBM's proprietary technology.
You read that right. In order to debug a problem with the Itel, the Itel field service engineers used IBM's schematics.
I think a lot of this free availability was because IBM was facing antitrust pressure from the US government. I don't know all the details.
Here's more history about the clone: http://www.silogic.com/NAS/NAS.html
Re: IBM System/360 Principles of Operation (1964) [pdf]
#18This was my bible for many years. We called it POOP (Principles Of OPeration. I loved assembler on the 360 and the 370. I learned Assembly Language by cross listing my COBOL programs and using POOP to find out what the op codes meant.
System 370 assembler was the first language I worked in professionally. We called it the POPS manual. As I recall it was a paragon of technical writing. I learned how to read technical documentation on this manual.
Re: IBM System/360 Principles of Operation (1964) [pdf]
#19That's the easy one. z/Arch is way more intricate. As noted in my moniker, you can do fun stuff with BXLE,as described in the "Difficult Code" section on FINCH (aka program fetching) in an OS/360 PLM (Program Logic Manual).
Re: IBM System/360 Principles of Operation (1964) [pdf]
#20I did a tour of duty as a CPU logic designer at Amdahl. The POO was my bible, although it was the 370 version in those days. The thing to remember about ISA specs like this is that they are works of fiction. The contract goes: “If you programmers are willing to pretend this is how the machines work, we will build a machine that pretends to work that way.” That concept is the key innovation of the 360 system architecture, attributed to Gene Amdahl.
After leaving Amdahl I worked for a while in Electronic Design Automation. One year at the IEEE Design Automation Conference I met a random person at a happy hour who was an ex-IBM OS programmer. He said that he once spent a year rewriting a part of the OS to use a particular instruction entirely because “Amdahl didn’t have it yet.” Says I: “When was this?” ... “Ah, at that time part of my job was adding that instruction to the Amdahl CPU.”
The conversation felt like an old Mad Magazine “Spy vs. Spy” cartoon. We were both bemused.