[Doug McIlroy writes:] 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.And thank you Dr. McIlroy for sharing that. I had heard some of that story, but you have helped put the parts I know together more sensibly. These past few years dad was not able to remember and talk about these things, and it is really great to be about to recover some of that personal history I thought was lost.
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 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.
Thanks, Dan and Anthony [Sucheston], for the blog and for sniffing me out. I'd lost track of Doug after he moved to Wyoming. In fact I last tried Googling for him only about a month ago, but found only stale information. I'm delighted to be able to post some reminiscences of Doug, with whom I collaborated on my first professional work, which turned out to be a great success and a source of pride for both of us. I've passed the news to some other old Bell Labs hands, who met him considerably later and mainly in passing. But they all remember him nonetheless for his competence and gentlemanly ways.
More information here.
[images Dartmouth College Department of Computer Science]