After he left the room, we left the supervisory state and moved on to problem program instructions. Our text told us that five instruction formats were supported by the 360 Assembler and that each format, in one way or another, used registers. There were register-to-register instructions, register-to-storage and back again instructions, registers-with-index-register instructions, immediate instructions with registers, and storage-to-storage instructions. Before digging into the individual instruction formats, we had to learn about registers.
There were 16 general-purpose and 4 floating-point registers in the 360. The general-purpose registers were 4 bytes long and the floating-point registers 8 bytes long. Since I never programmed floating-point arithmetic, I won't mention the floating-point registers again. The general-purpose registers, however, were used as operands, holding binary numbers, and as a base for storage addresses. Of the many revolutionary achievements of IBM's 360 computer, its method for using registers to address main storage is high on the list of its accomplishments. Unlike the 1401 computer which directly addressed main storage, a 360 address was a combination of a register, called the "base register," and a displacement. An address was represented in a half-word where the first 4 bits was the base register and the remaining 12 bits was the displacement. The base register typically held the actual address of the starting location of the program. The displacement, then, was the number of positions beyond the start of the program where the next instruction or a constant was located.
Every BAL program began with the same three instructions:
Begin Start BALR R3, R0 Using *, R3
The Branch and Link Register (BALR) instruction places the absolute memory address of the instruction following the BALR into the register shown as the first operand, in this case R3. When used with register 0, as shown here, no branch takes place but program execution resumes with whatever instruction follows the Using assembler command. The "*" is the location counter. The result of these two assembler commands (Start and Using) and one register-to-register instruction is that register R3 contains the physical storage location of the start of the program and that R3 is designated as the program's base register. Shown in base and displacement format, the address of the next instruction, in hex, is 3000. The choice of R3 as a base register is arbitrary; any register other than 0 would work.
Dr. Amdahl and the others who designed IBM's 360 computer intended that problem programs would be relocatable. Wherever the supervisor loaded a program into main storage, the base and displacement technique made it feel at home.
Although we could now get our assembler programs started and with more than half of our first week of programmed instruction over, we still couldn't read a card. Our next expert had the answer. He brought with him a few mimeographed copies, one for each student, with directions for using the Input Output Control System (IOCS). It was simple. To read a card, we used Read as the op code. Sure, we had to tell IOCS what device to read (our choices were cards or tapes) and where to put the data it read, but it wasn't much more difficult than 1401 Autocoder. We didn't know it then but IOCS was the forerunner for all of IBMs operating systems. Next, the expert told us how to punch cards, write tape, and send print lines to the printer with IOCS. We were to use the op code Write. These new op codes, he explained, were something called macros. When the assembler saw an op code that wasn't a native BAL instruction, it would look in its macro library. If it found the op code in the macro library, the assembler placed the library instructions into our programs. When I got my first BAL program listing with IOCS macros, I looked at the instructions that the assembler put in my program and there it was. It was IOCS that used the SVC instruction.
Dogged perseverance got us through our first week of programmed instruction. We wrote our first programs, read cards, and printed lines. The Education Center had several 360s on display and we could use one of the 360 model 30s to assemble our programs. The Ed Center also had a few keypunch machines and I used one to keypunch my first BAL program. As we left the Suburban Station that Friday, me to return to Harrisburg for the weekend and the others to travel to their homes around Philadelphia, we felt that we had accomplished something substantial. With little more than books and advice, we were becoming assembler programmers.
In the next installment, I'll finally get back to Harrisburg to stay. I go back to take a job with a company that converts its data processing from punched card machines to an IBM 360 model 20. I'll also have to learn a programming language other than BAL and Autocoder.
It occurs to me that of the total number of instructions that I've written during my career as a programmer, fewer than 20 percent have been assembler instructions. The numbers don't matter. When I'm asked, I proudly introduce myself as just that.
"Hi, my name is Dan Wohlbruck and I'm an assembler programmer."
- A Personal History of Systems and Computers: Part 1
- A Personal History of Systems and Computers: Part 2
- A Personal History of Systems and Computers: Part 3
- A Personal History of Systems and Computers: Part 4
- A Personal History of Systems and Computers: Part 5
- A Personal History of Systems and Computers: Part 6
- A Personal History of Systems and Computers: Part 7
- A Personal History of Systems and Computers: Part 8
- A Personal History of Systems and Computers: Part 9
