猛男教你写代码_猛男程序员，鼓存储器和1960年代机器代码的取证分析

最新推荐文章于 2024-11-04 20:33:37 发布

cumi6497

最新推荐文章于 2024-11-04 20:33:37 发布

阅读量192

点赞数

文章标签： java 编程语言 python linux 大数据

原文链接：https://www.freecodecamp.org/news/macho-programmers-drum-memory-and-a-forensic-analysis-of-1960s-machine-code-6c5da6a40244/

版权

猛男教你写代码

真正的程序员不使用PASCAL (Real programmers don’t use PASCAL)

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

今天的程序员构建了分布式应用程序和人工神经网络。他们使用功能性React式编程，开源Web框架和无服务器环境。但是，冒名顶替综合症是真实的，程序员仍然相互批评自己不是“真正的程序员”。

I worked as a docent 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 starts with a 1983 letter, Real Programmers Don’t Use PASCAL, written by Ed Post. The letter was published in Datamation, and discussed the “macho” side of programming. It needled those who disparage higher-level language users as not “real programmers.”

故事始于1983年由Ed Post撰写的《 Real Programmers Do n't Use PASCAL 》一书。这封信发表在Datamation上，并讨论了编程的“男子气概”方面。它针刺那些谁贬低高级语言的用户不会 “真正的程序员。”

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

梅尔的故事是对该信的在线回复。它由Ed Nather于1983年5月21日发布到Usenet。

Mel and Ed were colleagues at a typewriter company that had branched out into building computers. Their breakout success 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.) Mel was assigned to rewrite a popular program for the successor computer, the RPC-4000.

梅尔和埃德是一家打字机公司的同事，该公司已扩展到制造计算机。他们的突破性成功是LGP-30 ：鼓式存储计算机，带有Flexowriter键盘和纸带阅读器。 (本文的标题图像是LGP-30的仪表板。)梅尔被指派为后继计算机RPC-4000重写一个流行的程序。

Port? What does that mean?

港口？那是什么意思？

After Mel left the company, Ed was tasked to rewrite part of this program. In the story, he discovers an infinite loop in the code, which somehow doesn’t prevent the program from functioning:

梅尔(Mel)离开公司后，埃德(Ed)被要求重写该程序的一部分。在故事中，他发现了代码中的无限循环，这在某种程度上不会阻止程序运行：

Perhaps my greatest shock came when I found an innocent loop that had no test in it.

当我发现一个没有测试的无辜循环时，也许我最大的震惊就来了。

No test. None.

没有测试。没有。

Common sense said it had to be a closed loop, where the program would circle, forever, endlessly.

常识说，它必须是一个闭环，程序将在其中无限循环。

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

Ed发现闭环导致溢出，从而重写了指令代码。溢出的结果是一条跳转指令，将程序的控制权转移到另一个存储器位置。

It’s a great story. But does it check out?

这是一个很棒的故事。但这是否结帐？

法证分析：故事是否结账？ (Forensic code analysis: Does the story check out?)

Our first step is to look for 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 an RPC-4000. (Remember, it needed to be re-written for this new machine.)

我们的第一步是查找程序编写机器的技术细节。尽管这个故事广泛提及了LGP-30，但该程序实际上是在RPC-4000上运行的。 (请记住，需要为此新机器重写它。)

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

两台机器都使用鼓存储器来存储程序。 (有趣的事实：现代硬盘驱动器的大致等同物是鼓存储器，纸带，打Kong卡或磁带！)当鼓在其下方以恒定速度旋转时，一行电磁头将读取/写入数据。这是视觉参考：

Data was stored and retrieved from the various sectors and tracks of the drum. To find out more about the format of the data, we can consult the RPC-4000 programming manual, which archive.org has scanned and preserved online.

从鼓的各个扇区和轨道中存储和检索数据。要查找有关数据格式的更多信息，我们可以查阅RPC-4000编程手册，archive.org已在线对其进行扫描和保存。

On page 20 of the manual, we find the following data word diagram:

在手册的第20页上，我们找到以下数据字图：

The command word breaks down into:

命令字可分为：

5 bits for the command
5位命令
13 bits for the track/sector location of the operand
13位用于操作数的轨道/扇区位置
13 bits for the track/sector of the next command’s address
下一个命令地址的轨道/扇区的13位

Bit 31 is the index tag which, when set, activated the index register:

位31是索引标签 ，该标签在置位后会激活索引寄存器：

[The index register] allowed the programmer to write a program loop that used an indexed instruction inside; each time through, the number in the index register was added to the address of that instruction, so it would refer to the next datum in a series.

[索引寄存器]允许程序员编写一个程序循环，该循环使用内部的索引指令；每次通过时，索引寄存器中的数字都会添加到该指令的地址中，因此它将引用系列中的下一个数据。

The story mentions that the “index bit” is “the bit that lay between the address and the operation code in the instruction word.” Yet, the diagram above shows that the index tag bit is actually at bit 31, past the command and addresses. Personally, I chalk this up to a mis-remembering by the author in the years between when he reviewed the code and when the story was recorded.

这个故事提到“索引位”是“位于指令字中地址和操作代码之间的位” 。但是，上图显示索引标记位实际上位于命令和地址之后的第31位。就我个人而言，我认为这可能是作者在回顾代码和记录故事之间的错误记忆。

Luckily, this doesn’t affect the overflow aspect of the story. Since the instruction word was being pulled into memory and incremented, the index bit would still need to be set on in order for the increment to overflow the Next Address.

幸运的是，这不会影响故事的溢出方面。由于指令字已被拉入存储器并递增，因此仍需要将索引位设置为on ，以使递增溢出下一个地址 。

To re-create the instruction words in the loop, we need to know more about how the program operated. Here is a quote from the critical part of the story:

要在循环中重新创建指令字，我们需要更多地了解程序的操作方式。这是故事关键部分的引文：

He had located the data he was working on near the top of memory —

他将正在处理的数据放在内存顶部附近–

the largest locations the instructions could address —

说明可以解决的最大位置-

so, after the last datum was handled, incrementing the instruction address would make it overflow.

因此，在处理完最后一个数据后，增加指令地址将使其溢出。

The carry would add one to the operation code, changing it to the next one in the instruction set: a jump instruction.

进位将向操作码添加一个，从而将其更改为指令集中的下一个：跳转指令。

假设的实现：“给我看看！” (Hypothetical implementation: “Show me the bits!”)

Here is a potential instruction that may be the jump instruction referenced in the story:

这是一个潜在的指令，可能是故事中引用的跳转指令 ：

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

我们可以看到命令位是10111 。如果关闭了分支控制 ，则“下一条指令是在下一个地址字段中指定的。” 因此，一种可能的情况是，在溢出之后，寄存器(使用管道表示位域之间的分隔)为：

10111 | 0000000| 0000000 | 0

10111 | 0000000 | 0000000 | 0

Extrapolating back, prior to the increment and overflow, the register would have read:

推断回去，在递增和溢出之前，寄存器将读取：

10110 | 1111111 | 1111111 | 1

10110 | 1111111 | 1111111 | 1个

One 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 into the next address field will result in a jump to that address irrespective of the command bits.

完成此实现的一个有趣的副作用是所使用的指令并不重要。 RPC-4000中的每条指令都包含下一条指令的地址。不管命令位如何，索引位到下一个地址字段的溢出都会导致跳转到该地址。

结语 (Epilogue)

Mel Kaye (pictured standing, rightmost) continued working and eventually retired. A fan named Anthony Cuozzo posted in 2014 that he tried to get into contact with Mel:

梅尔·凯(Mel Kaye)(如图所示，最右边)继续工作，最终退休。 2014年，一位名叫Anthony Cuozzo的粉丝发布了他试图与Mel联系的信息：

I did eventually manage to get in contact with Mel, but I scared him away, unfortunately. That’s a story for another day… :-/ (source)

最终，我确实设法与梅尔取得了联系，但不幸的是，我吓跑了他。这是另一天的故事……：-/( source )

Out of respect for Mel’s privacy, I won’t post any personal information, and stick to the program and the story. If anybody knows how Mel feels about his internet fame, I’d love to hear from you.

出于对梅尔(Mel)隐私的尊重，我不会发布任何个人信息，并坚持该程序和故事。如果有人知道梅尔对他的互联网声誉的感觉，我很想听听您的消息。

I haven’t kept in touch with Mel, so I don’t know if he ever gave in to the flood of change that has washed over programming techniques since those long-gone days. I like to think he didn’t. — Ed Nather