There must be dozens of stories I could tell about Dad and our time in the Boy Scouts. I'll have to work on that.
Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
In memorium: A place to share stories and memories.
The Authors
Blog Archive
Labels
- Computer Science (1)
- family (2)
- grief (1)
- important things (1)
- Memorial (3)
- Memories (9)
- Monty Python (1)
- Music (1)
- obituary (1)
- photos (1)
- Scouting (2)
On joining the Bell Labs math department, I was given an office next to Doug Eastwood's. Soon after, George Mealy (of finite-state machine fame) suggested to a small group of us that a macro-instruction facility be added to our assembler (the program that converted human-readable machine language into machine-readable binary code.) This idea caught the fancy of us two Dougs, and set the course of our research for some time to come. We split the job in half: Eastwood took care of defining macros; McIlroy handled the expansion of macro calls.
ReplyDelete[A macro is simply a shorthand for a command. For example, you might declare that "cook rice 20", means get rice from storage, put it in a pot, cover it with water, set the pot on the stove, and turn it on for 20 minutes. Once you've told what "cook" means, you can use it over and over again in macro calls like "cook beans 4" or "cook potatoes 15".]
The macro system we built enabled truly astonishing applications. Macros took hold in the Labs' most important project, electronic switching systems, in an elaborated form that served as their primary programming language for a couple of decades.
Once macros had been incorporated, the assembler was processing code written wholesale by machine (i.e. by the assembler itself) rather than retail by people. This stressed the assembler in ways that had never been seen before. The size of of its vocabulary jumped from about 100 different instructions to that plus an unlimited number of newly defined ones. The real size of programs jumped because one human-written line of code was often shorthand for many, many machine-written lines. And the number of symbolic names in a program jumped, because macros could invent new names like crazy.
Foreseeing these stresses, Doug set out to improve the affected parts of the assemble. His most dramatic improvement was to cope with the proliferation of symbols, which was particularly pernicious because each factor of 10 in number of symbols incurred a factor of 100 in running time. The time to assemble code could now far exceed the time to run it.
By deploying a newly published sorting method, Doug squashed the cost of symbol lookup back to seconds. Another of his improvements gained only a bit of speed, but had the effect of letting one change the meaning of basic instructions! This enabled some quite powerful programming tricks.
I can still hear Doug's resonant voice, and see his friendly smile, just as in the photos on this blog. His office saw a steady stream of clients looking for advice. This he gave unstintingly, with the same sense of service that permeated his later life, too. Many people at the Labs were helped over hard places by him, but probably none had their future more notably shaped by collaboration with Doug than I. It was a lucky day when I drew the office next to him.
Doug McIlroy