|My Favorite Languages|
It was great when it all began
Long ago, the Reader's Digest Young People's Annual for 1963 had an article by Martin Gardner on a simplified form of chess called Hexapawn to be played on a three by three board, and how to build a computer out of two dozen matchboxes that learns how to play the game. Each matchbox bears a diagram corresponding to a possible board position and has coloured arrows for the moves that can be made from that position. Within are smarties corresponding to the arrows, and when a particular move is determined to be bad, its smarty is devoured...
At Hutt Valley High School, the Physics master had in 1968 a contact with Balm Paints, whereby we pupils could write a programme for their IBM360, and we were set the task of solving A*X + B = C for given values of A, B, and C. In COBOL. Inspired by this, and vexed by the mathematics classes that incessantly set us to making sketch plots of various arbitrary functions, I thought of a way of having the computer doing the work. The idea was to have a sketch pad of 120 by 60 character positions (a lineprinter page), and with suitable scaling say from -6 to +6 for character positions 1 to 120, etc, have the computer consider an expression A(x,y) = B(x,y) for the 120 by 60 possible spots and if the LHS and RHS differed by less than 1, say, for some (x,y) = (column,line) place a splot to be printed. Thus, a LHS expression might be A = "y" and the RHS expression be B = "3*x**2 + x - 6"
The COBOL programme would read text into variables A and B, set values into x and y, and if A was "numeric" and B was "numeric", proceed. Alas, I was unclear on the distinction between programme source statements, and run-time compiled code. There are of course many languages whereby exactly this would work, possibly with the introduction of something like an "evaluate(A)" statement, but, COBOL is not one of them. Ah well.
First Machine Code
In 1970 at Auckland University, the Applied Mathematics class introduced the AMI computer, a decimal computer with a thousand five-digit words of storage, which one programmed in machine code only, thus learning about the bootstrap, the loader and the relocating loader. I still recall the bootstrap sequence, as its comprehension required the assimilation of novel ideas: on "power on", memory is cleared to zero and the instruction register holds 17000 - two digit operation code, three digit address. This is to read from the "paper tape" input (actually, a deck of punched cards) a five-digit sequence and place it at address zero. As the instruction address register is already zero, this code is then executed. The input is the three-number bootstrap sequence 17001 17002 12000, where opcode 12 is a JUMP TO. Now follows what you desire to be loaded, in the form of 17adr and xxxxx pairs in sequence whereby xxxxx is placed at the desired address. End that sequence with 12adr to jump to the desired start point of the programme just loaded. I noticed that this bootstrapper is actually a limited AMI interpreter, in that it executes whatever opcodes are presented in the input stream, though jump instructions would require special treatment. An assignment aimed at completing some straightforward calculation with the minimum number of steps executed was thus achieved well ahead of others that first used the loader protocol to read in the calculation's op codes. The loader had first to be loaded by the bootstrap sequence, but its advantage was that it placed the input stream's data at consecutive positions without requiring the alternation of load, datum pairs. I later devised a slimmed-down version of the loader that used fewer steps per datum. The relocating loader was more complex, as each word to be loaded was prefixed by a word having zero or one, the one signifying that the address field was to be adjusted. This was called the assembler, but there were of course no mnemonics, just straight machine code.
Once we had bootstrapped our comprehension to this higher level, the course moved on to the likes of writing machine code programmes to calculate sin(x), etc. with Tschebychev polynomials used to spread the accuracy more evenly and with fewer terms though odder coefficients. This computer was actually manifested via an interpreter on an IBM1130. We were also introduced to Fortran IV, and could have actual operating access to its predecessor, an IBM1620 which worked in Fortran II. This computer's electronics were discrete transistors on printed circuit boards - I missed out on "first generation" valve electronics for computers and the still earlier electro-mechanical devices, though we did have access to a cardpunch/printer whose electro-mechanical workings could be somewhat programmed via a plug board, and the Physics lab offered a Friden electric-powered mechanical calculator - and like everyone else, I tried out dividing by zero. Whirrrrrr... Thus, I am a dinosaur of the Jurassic period, not the Triassic.
Later that year I wrote an interpreter for the AMI system in Fortran II for the IBM1620, and thereby won four milkshakes from a friend, Michael Dowling, who took the AMI course the following year and used my programme for test runs. On one of his assignments, he had difficulty and test runs were facilitated by the immediate feedback. Indeed, by flicking certain switches on the computer's console, trace output for each step could be elicited, hammered out at ten key whacks a second on the heavy-duty console typewriter, there being no lineprinter for this installation. I happened by, and the discussion went somewhat as follows:
"It will work." "No, it won't" - first milkshake.
"This time it will work." "No, it still won't" - second milkshake.
"I suppose it won't work." "Yes it will!" - this time, double milkshakes.
Although the paper tape reader only accepted five-character numbers as input there was a dispensation: rather than typing out the code of the bootstrap, etc. every time, we could instead put BOOT or LOAD or ASSEM that would be recognised by the interpreter's input processor to save us the trouble. My interpreter went a little further. First it read special input presenting these names and their replacement, and it also allowed additional names to be described, such as FACT, which computed factorial numbers recursively - for 1971 the AMI computer had been converted to working with a stack for entry and return. Since the interpreter's processor for the READ opcode knew the address at which the datum being read was to be placed, it therefore knew where the first word of the FACT routine was being placed. Subsequent appearances of FACT in the input (such as in the expansion of FACT) were converted to a single word, the ENTER opcode with that address. Interpreters can reach across levels of interpretation for special effects!
Once my interpreter was working reliably, attention turned to issues of speed. An early improvement involved removing excessive testing. Because the only IF-statement form was the three-way IF-test (and this ever since has provoked me to consider at least briefly the possibility of unexpected values, such as negative when only zero or positive were expected) it was often the case that one IF-test was followed by another for which some of the possibilities had been precluded by the earlier tests. Ah, but what if there was some mistake? Surely this should be checked, since it was a further option of an already-needed test? In the event, no such test ever was triggered and I decided to remove them, resulting in less code, fewer error messages, and somewhat speedier execution. However, computer arithmetic can deviate from mathematics, and adding some positive value may not in fact produce a more positive result. With the IBM1620's signed arithmetic the results are not as dramatic as with two's complement arithmetic but there are still opportunities, and alas, the modernisers have discarded the IF OVERFLOW and similar tests. It is best if the arithmetic in use is certain to not provoke overflows, and then they need not be tested for...
More effective speedups beckoned. I modified my interpreter to replace the Fortran code that loaded and decoded the opcode by certain nonsense statements, then, once the compiler had produced the machine code card deck, replaced the card bearing the rubbish code with one containing choice IBM1620 machine code operations (of just the same size) that performed those critical steps much faster. The payoff was an advance from about five to fifteen AMI operations a second. A fellow the year ahead of me had done likewise, and his interpreter ran at thirty steps a second. Thus began early a relaxed attitude to code twiddling and disdain for those who would prevent it.
By now I was quite clear on the distinction between source code (as in COBOL) and compiled code, but despite all these interpreters, I still couldn't work out how Fortran compiled FORMAT statements, especially since different WRITE statements might use the same FORMAT statement. Was each WRITE statement compiled with reference to its named FORMAT statement? Surely that would be very messy...
During this period the console typewriter flung the slug for the letter W from its key and we had to adjust our programmes to use VV instead, much to the amusement of our lecturer Gary Tee who noted that we were reversing a millenium-old development in orthography.
Over the Christmas and summer holidays I gained money instead of milkshakes: employed by the computer centre to write a data-checking system in Fortran IV plus my first introduction to IBM1130 assembler, under the tutoring of John Nevil Brownlee the director of the computer centre. The objective was to devise routines that would store the data in arrays as records in a disc file, with later random retrieval and modification. Although Auckland's IBM1130 had the maximal storage allowance of 32,768 words of sixteen bits, there were those for which that was not enough. An assembler routine could gain access to the free disc space whereas ordinary file access, as via Fortran, could only work with fixed-size pre-allocated file storage areas. This introduced me to the notion of the "end" part having a name corresponding to the "begin" part, as might these days appear as END FUNCTION FACT, or IF ... END IF, or DO I ... NEXT I (in BASIC, but not elsewhere, alas), and to the idea of having a running commentary explaining the workings of the statements, off to the side so as not to impede sight of the statements and their shape. But the slowness of the offline card to typewriter listing process (and its noise!) strongly discouraged verbosity, and my listing of my AMI interpreter has not a single comment...
In 1972 the family moved to Wellington on my father's promotion to Chief Surveyor, and so to Victoria University where we students had access to the IBM1130 and Clive Nicolson was the pre-eminent expert and the same height as me - 6'4" so we could not overlook each other. We got stuck in to the operating system and miscellaneous device drivers, none of which had much to do with our course work, which had little to do with computers or the likes of tables of prime numbers, or e calculated to 132,800 places. Thus, the analysis of the results of a physics experiment might be facilitated by using a computer programme, but using computers was not a part of the course. In other words, unlike computer science courses where the programme is assessed on aesthetic grounds, these programmes were written to produce results, and correct ones at that. This proved to be an employment advantage.