Programmers today build distributed applications and artificial neural networks. They use functional reactive programming, open source web frameworks, and serverless environments. Nevertheless, the impostor syndrome is real, and programmers still criticize each other for not being “real programmers”.

I worked as an outright for the Computer History Museum for years. The trope of a “real programmer” has been around since the beginning of software. And I can prove it with a story.

The story begins with a 1983 letter, Real Programmers Don’t Use Pascal, written by Ed Post. The paper was published in Datamation, and discussed the “macho” side of programming. It is needed by people who do not consider high-level language users to be “real programmers”.

The Story of Mail is an online answer to that letter. It was posted to Usenet by Ed Nather on May 21, 1983.

Mel and Ed were coworkers at a typewriter company that built computers. Their breakthrough breakthrough was the LGP-30: a drum memory computer with a flexowriter keyboard and paper tape reader. (The header image in this article is the dashboard of an LGP-30.) Mail was assigned to rewrite a popular program for the successor computer, the RPC-4000.

After Mel left the company, Ed was tasked with rewriting part of the program. In the story, he discovers an infinite loop in the code, which somehow does not prevent the program from functioning:

Ed discovered that the closed loop was causing an overflow, which rewritten the instruction code. The result of the overflow was a jump instruction, moving control of the program to a different memory location.

That is a great story. But does it check?

Forensic code analysis: does the story check?

Our first step is to look for the technical details of the machine the program was written for. While the story makes extensive mention of the LGP-30, the program was actually running on the RPC-4000. (Remember, this will need to be rewritten for this new machine.)

Both machines used drum memory for program storage. (Fun fact: the rough equivalent of your modern hard drive was drum memory, paper tape, punch card or magnetic tape!) A row of electromagnetic heads would read/write data as the drum rotated beneath them at a constant velocity. Here is a visual reference:

Data was stored and retrieved from different areas and tracks of the drum. To learn more about the format of the data, we may consult the RPC-4000 Programming Manual, scanned and preserved online by archive.org.

The story mentions that the “index bit” is “the bit that lies between the address and the operation code in the instruction word.” Nevertheless, the diagram above shows that the index tag bit is actually at bit 31, which precedes the command and address. Personally, I chalk it up to being mistakenly remembered by the author in the years when he reviewed the code and when the story was recorded.

Fortunately, this doesn’t affect the overflow aspect of the story. As the instruction word was being pulled into memory and incremented, the index bit would still need to be set in order for the increment to overflow to the next address.

We can see that the command bits are 10111. If Branch Control is off, “The next instruction is the one specified in the next-address field.” So a hypothetical situation would be that, after overflow, read the register (using a pipe to denote separation between bitfields):

An interesting side effect of working through this implementation is that the instruction used doesn’t really matter. Each instruction in the RPC-4000 includes the address of the next instruction. An overflow in the index bit in the next address field will result in the command jumping to that address regardless of the bits.

In respect of Mail’s privacy, I will not post any personal information, and will stick to the schedule and story. If anyone knows how Mel feels about his internet fame, I’d love to hear from you.

Leave a Reply

Your email address will not be published. Required fields are marked *