The story of Mel
The story of Mel
(programming, person)Lest a whole new generation of programmers grow up inignorance of this glorious past, I feel duty-bound todescribe, as best I can through the generation gap, how a RealProgrammer wrote code. I'll call him Mel, because that washis name.
I first met Mel when I went to work for Royal McBee Computer Corporation, a now-defunct subsidiary of the typewriter company.The firm manufactured the LGP-30, a small, cheap (by thestandards of the day) drum-memory computer, and had juststarted to manufacture the RPC-4000, a much-improved, bigger,better, faster -- drum-memory computer. Cores cost too much,and weren't here to stay, anyway. (That's why you haven'theard of the company, or the computer.)
I had been hired to write a Fortran compiler for this newmarvel and Mel was my guide to its wonders. Mel didn'tapprove of compilers.
"If a program can't rewrite its own code," he asked, "whatgood is it?"
Mel had written, in hexadecimal, the most popular computerprogram the company owned. It ran on the LGP-30 and playedblackjack with potential customers at computer shows. Itseffect was always dramatic. The LGP-30 booth was packed atevery show, and the IBM salesmen stood around talking to eachother. Whether or not this actually sold computers was aquestion we never discussed.
Mel's job was to re-write the blackjack program for theRPC-4000. (Port? What does that mean?) The new computerhad a one-plus-one addressing scheme, in which each machineinstruction, in addition to the operation code and the addressof the needed operand, had a second address that indicatedwhere, on the revolving drum, the next instruction waslocated. In modern parlance, every single instruction wasfollowed by a GO TO! Put *that* in Pascal's pipe andsmoke it.
Mel loved the RPC-4000 because he could optimize his code:that is, locate instructions on the drum so that just as onefinished its job, the next would be just arriving at the "readhead" and available for immediate execution. There was aprogram to do that job, an "optimizing assembler", but Melrefused to use it.
"You never know where its going to put things", he explained,"so you'd have to use separate constants".
It was a long time before I understood that remark. Since Melknew the numerical value of every operation code, and assignedhis own drum addresses, every instruction he wrote could alsobe considered a numerical constant. He could pick up anearlier "add" instruction, say, and multiply by it, if it hadthe right numeric value. His code was not easy for someoneelse to modify.
I compared Mel's hand-optimised programs with the same codemassaged by the optimizing assembler program, and Mel's alwaysran faster. That was because the "top-down" method of programdesign hadn't been invented yet, and Mel wouldn't have used itanyway. He wrote the innermost parts of his program loopsfirst, so they would get first choice of the optimum addresslocations on the drum. The optimizing assembler wasn't smartenough to do it that way.
Mel never wrote time-delay loops, either, even when the balkyFlexowriter required a delay between output characters towork right. He just located instructions on the drum so eachsuccessive one was just *past* the read head when it wasneeded; the drum had to execute another complete revolution tofind the next instruction. He coined an unforgettable termfor this procedure. Although "optimum" is an absolute term,like "unique", it became common verbal practice to make itrelative: "not quite optimum" or "less optimum" or "not veryoptimum". Mel called the maximum time-delay locations the"most pessimum".
After he finished the blackjack program and got it to run,("Even the initialiser is optimised", he said proudly) he gota Change Request from the sales department. The program usedan elegant (optimised) random number generator to shuffle the"cards" and deal from the "deck", and some of the salesmenfelt it was too fair, since sometimes the customers lost.They wanted Mel to modify the program so, at the setting of asense switch on the console, they could change the odds andlet the customer win.
Mel balked. He felt this was patently dishonest, which itwas, and that it impinged on his personal integrity as aprogrammer, which it did, so he refused to do it. The HeadSalesman talked to Mel, as did the Big Boss and, at the boss'surging, a few Fellow Programmers. Mel finally gave in andwrote the code, but he got the test backward, and, when thesense switch was turned on, the program would cheat, winningevery time. Mel was delighted with this, claiming hissubconscious was uncontrollably ethical, and adamantly refusedto fix it.
After Mel had left the company for greener pa$ture$, the BigBoss asked me to look at the code and see if I could find thetest and reverse it. Somewhat reluctantly, I agreed to look.Tracking Mel's code was a real adventure.
I have often felt that programming is an art form, whose realvalue can only be appreciated by another versed in the samearcane art; there are lovely gems and brilliant coups hiddenfrom human view and admiration, sometimes forever, by the verynature of the process. You can learn a lot about anindividual just by reading through his code, even inhexadecimal. Mel was, I think, an unsung genius.
Perhaps my greatest shock came when I found an innocent loopthat had no test in it. No test. *None*. Common sense saidit had to be a closed loop, where the program would circle,forever, endlessly. Program control passed right through it,however, and safely out the other side. It took me two weeksto figure it out.
The RPC-4000 computer had a really modern facility called anindex register. It allowed the programmer to write a programloop that used an indexed instruction inside; each timethrough, the number in the index register was added to theaddress of that instruction, so it would refer to the nextdatum in a series. He had only to increment the indexregister each time through. Mel never used it.
Instead, he would pull the instruction into a machineregister, add one to its address, and store it back. He wouldthen execute the modified instruction right from the register.The loop was written so this additional execution time wastaken into account -- just as this instruction finished, thenext one was right under the drum's read head, ready to go.But the loop had no test in it.
The vital clue came when I noticed the index register bit, thebit that lay between the address and the operation code in theinstruction word, was turned on-- yet Mel never used the indexregister, leaving it zero all the time. When the light wenton it nearly blinded me.
He had located the data he was working on near the top ofmemory -- the largest locations the instructions could address-- so, after the last datum was handled, incrementing theinstruction address would make it overflow. The carry wouldadd one to the operation code, changing it to the next one inthe instruction set: a jump instruction. Sure enough, thenext program instruction was in address location zero, and theprogram went happily on its way.
I haven't kept in touch with Mel, so I don't know if he evergave in to the flood of change that has washed overprogramming techniques since those long-gone days. I like tothink he didn't. In any event, I was impressed enough that Iquit looking for the offending test, telling the Big Boss Icouldn't find it. He didn't seem surprised.
When I left the company, the blackjack program would stillcheat if you turned on the right sense switch, and I thinkthat's how it should be. I didn't feel comfortable hacking upthe code of a Real Programmer."
[Posted to USENET by its author, Ed Nather
Was Mel, Mel Kaye?.