Estimated reading time: 6–7 minutes
“— Why do you bother with Assembler?
— So that I don’t bother worse later on.”
There was, however, a third category, kept further down in the folder, like a spare key you do not use every day but without which you might find yourself locked out of your own house: routines written in Assembler.
There were not many of them. But they were the kind of pages that, when needed, shortened your day and lengthened your reputation.
Why would you need Assembler in 1972, when you already had FORTRAN and COBOL, two “serious” languages, each with its own prestige?
Because FORTRAN and COBOL were two civilised professionals, but with their limitations. FORTRAN was good at calculations, COBOL was good at files and reports. Only the real world does not respect departmental boundaries. It demanded speed, and control, and precision, and “let it work first time round” — all within the same program.
And sometimes it demanded something that high-level languages could not provide with any elegance: direct access to the “installation.”
For instance, precisely in the area I was speaking about earlier — direct data access. On paper, hashing was simple: divide, take the remainder, you have your address. In reality, to jump directly to a place on disk, you needed to come to an understanding with the operating system and its input/output mechanisms. There, you could no longer get by with polite words and elegant parentheses. There, you had to speak “the language of the house.”
That is how Assembler routines came about: small intermediaries between your idea and the iron.
You wrote a routine that knew how to do one concrete and repetitive thing: read fast, write fast, manage buffers, use the system’s access methods, check a critical condition, exit with a clear message, and not let the program die theatrically, complete with the dump printed in ten copies.
In short: FORTRAN and COBOL were good at sentences. Assembler was good at nuts and bolts.
And there was one more reason, perfectly pragmatic, that anyone can understand: I did not want to write the same thing twice.
If I had a good routine in Assembler, I could call it from FORTRAN as well as from COBOL. I wrote it once, tested it once, cursed it once. Then I used it whenever I needed to. In 1972, that was already a form of luxury.
I remember a brief exchange, the kind that never takes place in meetings but stays lodged in your head:
— Why do you bother with Assembler?
— So that I don’t bother worse later on.
And here I arrive at the part that frightens many but captivated me: Assembler itself.
I learned it surprisingly easily. And I believe, in all honesty, that it is easy to learn — perhaps even easier than a “high-level” language. Not because it is friendlier, but because it is more direct.
A high-level language is like a courteous civil servant: it tells you, “Leave your application here, we shall take care of it.” Assembler, on the other hand, is like the man in the basement, in overalls, with the key to the boiler room: he says nothing pleasant, but he shows you exactly which pipe the water runs through.
In Assembler you do not say “calculate the tariff” or “search the file.” You say things that are very simple and very precise: move, compare, add, jump, call, return. Few verbs, much responsibility. Like the army, except that here nobody shouts at you. The programmer shouts at himself.
That is why it is easy at first: there is no jungle of concepts. There is only the machine and its rules. The difficulty comes later, when you realise that the machine takes everything literally. If you have been vague, it does not ask, “Is that what you meant?” It executes the vagueness. And prints out the result, perfectly aligned, so as to make you doubt your own judgement.
But now comes a nuance, and an important one:
Assembler on a mainframe was not the same animal as Assembler on a microprocessor.
On a mainframe (an IBM 360, or the Siemens 4004 compatible with it), Assembler was “the language of a factory.” You had many registers, addressing schemes, strict conventions, and above all you had a powerful neighbour: the operating system. It was the building superintendent. It provided services, but on the basis of rules. And much of the time you worked with system macros, not merely with raw instructions. It was Assembler, but in a suit and tie and following protocol.
On a microprocessor (8080, Z80, 8086), Assembler was “the language of a workshop.” Few registers, little memory, no operating system to hold your umbrella. There it was just you and the machine, in a small room. If you made a mistake, the superintendent did not ring you up. The lights went out.
The same alphabet, but a different life.
And that is precisely why I loved it: you changed the machine, you changed the dialect, but you did not change the principle. Everything came down to the same simple truth: to gain control, you must give up comfort.