|=========>........................................| Exams 20%, ETA 10d
Every computer user knows those fancy progress bars that we face day after day… whether half-transparent with rounded corners on stylish Macs, or minimalistic as the above one, the waiting time they indicate is one big constant of computers. They might get twice as fast every two years, but my Gigahertz-calculater still takes at least as much time to boot than the first PC I worked with, a 20MHz 386 machine running MS-DOS. At least as much.
Today, however, while studying for my next exam about operating systems (studying might be too noble a word, though… I focussed more on interesting rather than relevant things), I discovered a very nice description about the old days of computing. It is taken from An Operating Systems Vade Mecum (PDF, 1.3MB), a freely available book by Raphael A. Finkel, published in 1988.
The machine had two major components, its transput [I/O] devices and its ability to execute a program. A typical session on the IBM 1620, a computer in use around 1964, involved several steps in order to compile and execute a program. First, the user would load the first pass of the Fortran compiler. This operation involved clearing main store by typing a cryptic instruction on the console typewriter; putting the compiler, a 10-inch stack of punched cards, in the card reader; placing the program to be compiled after the compiler in the card reader; and then pressing the “load” button on the reader. The output would be a set of punched cards called “intermediate output.” If there were any compilation errors, a light would flash on the console, and error messages would appear on the console typewriter. Assuming everything had gone well so far, the next step would be to load the second pass of the Fortran compiler just like the first pass, putting the intermediate output in the card reader as well. If the second pass succeeded, the output was a second set of punched cards called the “executable deck.” The third step was to shuffle the executable deck slightly, load it along with a massive subroutine library (another 10 inches of cards), and observe the program as it ran.
The output of a program might appear on cards or paper. Frequently, the output was wrong. To figure out why involved debugging, which often took the form of peeking directly into main store and even patching the program by using console switches. If there was not enough time to finish, a frustrated user might get a line-printer listing of main store (known as a dump of store [memory dump]) to puzzle over at leisure.
Simply amazing…