Was Taken For Granted, Now Forgotten
I found a computing treasure in a local Goodwill store three weeks ago: a book about System/360 assembly language. (Assembly language is the human-readable form of the concrete instructions carried out by the computer.) In earlier years, this would have been a wonderful surprise, but a previous find precludes that from happening… Last year, I found a special treat in the discount bin of a local grocery store: a movie, in Mongolian. In the rural Midwest USA, that is difficult to surpass that for surprise finds.
Anyway, the System/360 project had a huge mandate from IBM: the design had to include software which would hide the differences among the different System/360 models. (That software became OS/360, from which experience Fred Brooks wrote the inestimable volume The Mythical Man-month.) The system was a success, despite numerous obstacles, and became so popular that today’s powerful System/390 will still run programs built on the original System/360.
This philosophy on programming by intentions, rather than to the hardware, gave rise to the compact and highly symbolic (hence immensely popular) C programming language, designed by the originators of the portable Unix operating system.
This book gives some real insight into the way computer programming used to be:
- Economy of temporary storage. A low-end System/360 had 8,192 bytes of online memory, for both the running program and its workspace. Temporary storage was precious, and a program using it showed its purpose clearly.
- Economy of long-term storage. In terms of computing time, accessing the disk or tape was a very expensive operation. Finding and retrieving the desired data could take several thousand to several million machine cycles. The book’s first example of long-term storage retrieval involves reading punched cards, while demonstrating how issuing the read operation well ahead of using the retrieved data allows the processing to be distributed over different components of the system.
- No stack. Almost all modern computers have some sort of LIFO storage instructions built-in, for storing data into a holding area in memory. Some, like Intel and Zilog, have it explicitly, while others, like Sparc, ARM and MIPS, have it by implicit convention. But this book shows no evidence that the System/360 had anything resembling a stack. Temporary data was managed by the program explicitly, and a subroutine’s return address was typically stored in a CPU register. If a subroutine called another subroutine, it had to store its own return address somewhere before the next subroutine used the same register for its own (return address) purposes. Other data, which might be over-written by the called subroutine, also had to be stored in memory, typically in a fixed location. This makes recursion impossible without designing it into the software.
- The humans worked harder. A programmer’s time cost less than a computer’s time, so the programmer was expected to put much more offline work into checking the program before its first online test. Interactive debugging was nearly impossible; code instrumentation was strongly discouraged, due to the extra memory it required.
- The expected installation base is obvious. Both addition and subtraction support several numeric formats: the usual binary, plus packed decimal and unpacked EBCDIC, in arbitrary widths. All numeric values could be negative. These are accompanied by a plethora of format conversion instructions, so that even a packed decimal can be turned into unpacked, printable characters, complete with a currency marker, comma grouping, and right-justified in a field. On the typical desktop computer, the processor would require several hundred instructions, and a few thousand machine cycles, to accomplish the same conversion. The System/360 needs just a few instructions, plus a “map” describing the intended printout. Clearly, it was made for business accounting and reporting.
So far, I have read the foundational chapters, plus chapters on program modules and subroutines, and one on debugging (including how to read a printed System/360 core dump!). I am now reading the chapter about assembly macros.
Some may deride such “old school” studies. My response is to remind them that great work comes from great challenges. The sonnet form gave William Shakespeare a framework for the greatest soliloquies in the English language. What would Georges Seurat‘s paintings be like without the slow, dot-by-dot technique? The first running version of Unix was on a PDP-11/20, the very first delivered PDP-11 model, very weak by today’s standards.
Only by looking at the past, can we truly appreciate the future.