|
"Hi, I'm an assembler programmer."
September 09, 2008
URL:http://www.drdobbs.com/tools/a-personal-history-of-systems-and-comput/210600113
Dan can be contacted at [email protected].
In January 1966, I went to work for the Bell Telephone Company of Pennsylvania in Philadelphia and I began to learn IBM 1401 Autocoder. I described much of what I learned about Autocoder in the Part 1 of this series. After three weeks, along with a few of my classmates, I was selected to learn the IBM 360 Basic Assembler Language (BAL). So, on another Monday morning, I reported to the IBM Education Center at Suburban Station in Philadelphia to begin my study.
There were six or seven of us from the previous class that had been chosen to learn BAL and when we arrived at the Education Center, we were directed to our new classroom. The room had four rows of tables, enough chairs for the students, but no lectern for an instructor. Promptly at 9:00, two gentlemen, one from IBM and one from Bell Tell, arrived and explained that we were to be part of an experiment called "programmed instruction." We would be given paper-bound text books, Assembler Language coding pads, and pencils, but otherwise left on our own to learn a new generation of computer architecture and the language used to program it. Every 90 minutes an IBM expert would join us and ask us if we had questions. After a brief discussion with the expert, we would take a break.
Over the years, as I've thought about this experience, the only explanation that rings true is that the Bell Telephone company, faced with the need to train more than a hundred programmers in Assembler Language, made a deal with IBM to try to reduce their education costs. We, however, were only told that programmed instruction was the wave of the future and that it would soon replace instructor-led training. The fact that any of us learned BAL was due to the determination of my classmates and not the craziness of throwing half-a-dozen guys in an empty room with some books and telling them not to come out until they knew the Basic Assembler.
My strong-minded fellow students were male. We were Bell Telephone company employees who had taken the programmer aptitude test, then transferred to the computer department. Most of the students were from Philadelphia or the suburbs. In our original class of 15, only two other students were from out-of-town. I was from Harrisburg, another from Allentown, and the third, I believe, from Scranton. All of my classmates had installed or repaired telephones and they were happy to be in a warm room in February instead of a cold truck. So, despite the difficulty, we set out to stay warm and learn BAL.
The IBM 360 was made from integrated circuits, unlike the 1401's transistors. And, unlike the 1401 Autocoder, the 360's assembler language was based on the binary number system. Our programmed instruction text reported, "The binary system works under the exact same principles as the decimal system, only it operates in base 2 rather than base 10." No single sentence would cause me more problems. The binary system wasn't the same as anything that I had learned before, it was different.
We read that, as its name suggested, the binary number system used only two digits, 0 and 1. I was all right until the number 2. The number 10 (base 2) was the same as the number 2 (base 10), we were told. Our book showed long strings of zeros and ones, then an equal sign followed by a tidy two or three digit decimal number. Our book demonstrated how we could add and subtract these long strings of digits should we ever find the need to do so. I was confused.
When the expert joined us, I asked for some explanation of the binary system. He smiled, seemed nervous, and confided that we would probably never need to know about binary numbers. The expert advised us that rather than 1s and 0s, we should really concentrate on hexadecimal. Hearing no other questions, he left the room. He was the expert and he was right.
The hexadecimal system (called hex) substitutes a single character for four binary digits. Thus, once again, 2 was 2. Or, more accurately, 0010 was 2. It did get a little messy when you got past 9 because A was 10, B was 11, and so on until F being 15, but I could handle hex numbers. They just looked better to me. And, with that, we finished our first day of programmed instruction.
On Tuesday we learned that the binary numbering system was the basis for something called "bytes" which, in turn, made half-words (two bytes), full words (four bytes) and double words (no nibbles). A byte was eight bits of individual binary digits. Two hex numbers could be used to show the value of any byte which, therefore, ranged from 00 to FF. The binary number 1111 1111 was equal to FF in hex and 255 in decimal. So far, so good.
At this point our text wanted us to add and subtract in hex. To prove the solution, the book would transform the hex numbers to decimal numbers, perform the math, and transform the decimal back to hex. I don't know about the other students, but that's the way I learned it. It was just like speaking French. I translated the French to English, decided on a response in English, and then translated my response back to French. When I performed hex mathematics, I transformed the operators to decimal, did the math, and then transformed the answer back to hex. It wasn't the fastest or the best way, but it worked for me. Having instructed us on binary and hexadecimal numbers, bits, bytes and words; our text was programmed to proceed to the study of the IBM 360 Assembler Language, itself.
A BAL operation code, we learned, was one byte long. That meant that there were a maximum of 255 operation codes. Looking at the list of op codes, it seemed that they had used most of the 255 possibilities. But at least one operation was missing. Where was the Read? How was I going to get an 80-column card into memory? The text was silent. Instead, before teaching us about individual operation codes, it told us that there were two types of instructions. One type of instruction was privileged and the other type was normal. Aside from deciding that I really wanted to write only privileged instructions, the whole idea was lost on me. It was something to ask the expert.
As it happened, our expert had taught me Physics in high school a few years earlier. He didn't remember me and it was just as well that he didn't. I had been an uninspired physics student. He left teaching physics, joined IBM and, later, went on to lead IBM's development of OS/360. There could hardly have been anyone better to ask about privileged instructions running in something called the supervisory state.
In response to my questions, the expert introduced us to the supervisor call instruction (SVC). We could enter the supervisory state of machine operations, the place where privileged instructions were executed, be issuing an SVC and indicating the purpose of the call. For instance, if we wanted to read a card, we could write an SVC and request an input/output operation. With that, our problem programs were put on hold and a higher-level entity took over for us. Privileged instructions, it seemed, primarily dealt with input and output. In rapid succession, the expert mentioned PSWs (Program Status Words), CSWs (Channel Status Words), CCWs (Channel Control Words), and CAWs (Channel Address Words). All these words were needed to read cards, or any other device, for that matter. With a knowing wink, the expert assured us that we problem programmers didn't really need to worry about such things.
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."
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.