Мачо-программисты, барабанная память и криминалистический анализ машинного кода 1960-х годов

macho programmisty barabannaya pamyat i kriminalisticheskij analiz mashinnogo koda 1960 h godov

Настоящие программисты не используют PASCAL

Сегодня программисты создают распределенные программы и искусственные нейронные сети. Они используют функциональное реактивное программирование, веб-фреймворки с открытым кодом и бессерверную среду. Тем не менее, синдром самозванца реален, и программисты все еще критикуют друг друга за то, что они не «настоящие программисты».

Я много лет работал доцентом Музея истории компьютеров. Понятие «настоящий программист» существует с самого начала программного обеспечения. И я могу это доказать рассказ.

История начинается с письма 1983 года «Настоящие программисты не используют PASCAL», написанное Эдом Постом. Письмо было опубликовано в Datamation, и в нем обсуждалась «мачо» сторона программирования. Это потребность в тех, кто презирает пользователей высшего уровня языка как нет «настоящие программисты».

«История Мела» является онлайн-ответом на это письмо. 21 мая 1983 года он опубликовал Эд Натер в Usenet.

Мел и Эд были коллегами в компании, производившей пишущие машинки, занимавшейся созданием компьютеров. Их прорывным успехом стал LGP-30: компьютер с барабанной памятью с клавиатурой Flexowriter и считывающим устройство бумажной ленты. (Изображение заголовка в этой статье – это приборная панель LGP-30.) Мелу поручили переписать популярную программу для следующего компьютера RPC-4000.

Порт? Что это значит?

После того как Мэл покинул компанию, Эду поручили переписать часть этой программы. В истории он обнаруживает бесконечный цикл в коде, который почему-то не мешает программе работать:

Возможно, больше всего меня поразило, когда я нашел невинную петлю, в которой не было теста.
Без теста. Ни одного.
Здравый смысл говорил, что это должен быть замкнутый цикл, где программа будет кружиться вечно, бесконечно.
Однако управление программой проходило через него и благополучно выходило с другой стороны.

Эд обнаружил, что замкнутый цикл влечет за собой переполнение, которое переписало код инструкции. Результатом переполнения был a прыгать инструкция, перемещение управления программой в другую область памяти.

Это отличная история. Но проверяется ли?

Анализ судебного кода: проверяется ли история?

Наш первый шаг – поиск технических деталей машины, для которой написана программа. Хотя в истории многое упоминается о LGP-30, на самом деле программа работала на RPC-4000. (Помните, его нужно было переписать для этой новой машины.)

Обе машины использовали барабанную память для хранения программ. (Интересный факт: приблизительным эквивалентом вашего современного жесткого диска была барабанная память, бумажная лента, перфокарты или магнитная лента!) Одна линия электромагнитных головок считывала/записывала данные, когда барабан вращался с постоянной скоростью под ними. Вот визуальная справка:

zJIzg5uyEQoFMEUDYz9gmS1SWMgNoRgksyeg
Схема барабана памяти. Источник: Руководство RPC-4000

Данные хранились и извлекались из разных секторов и дорожек барабана. Чтобы узнать больше о формате данных, мы можем обратиться к руководству по программированию RPC-4000, которое archive.org отсканировало и сохранило в Интернете.

На странице 20 руководства мы находим следующую диаграмму слов данных:

7vhFSaJoslnlHki9MxXaOymDWxKfin32mF7X
Диаграммы в формате Word RPC-4000

Командное слово разбивается на:

  • 5 бит для команды
  • 13 бит для расположения дорожки/сектора операнда
  • 13 бит для дорожки/сектора адреса следующей команды

Бит 31 есть индексный тег который, когда установлен, активировал индексный регистр:

[The index register] разрешил программисту написать программный цикл, использующий индексированную инструкцию внутри; каждый раз номер в индексном регистре добавлялся в адрес этой инструкции, чтобы он ссылался на следующий в серии.

В истории упоминается, что «бит индекса» есть «бит, лежащий между адресом и кодом операции в командном слове». Тем не менее, диаграмма выше показывает, что бит тега индекса фактически находится на 31 бите, вне команды и адресов. Лично я отношу это к неправильному запоминанию автором в период между тем, как он проверил код и когда история была записана.

К счастью, это не влияет на аспект переполнения истории. Поскольку слово инструкции загружалось в память и увеличивалось, бит индекса все равно нужно было установить на чтобы инкремент переполнял Следующий адрес.

Чтобы воспроизвести командные слова в цикле, нам нужно узнать больше о том, как работала программа. Вот цитата из критической части истории:

Он нашел данные, над которыми работал, в верхней части памяти.
наибольшие места, которые могут касаться инструкции.
следовательно, после обработки последнего данного, увеличение адреса инструкции приведет к его переполнению.
Перенос добавил бы один к коду операции, изменив его на следующий в наборе инструкций: инструкцию перехода.
Конечно, следующая инструкция программы была в нулевой адрес и программа успешно пошла своим путем.

Гипотетическая реализация: «Покажи мне биты!»

Вот потенциальная инструкция, которая может быть инструкция по прыжку упоминается в истории:

YTmPExJNbmY8-Kx2r3UTaJSJ311QxjRn2Fc4

Мы видим командные биты 10111. Если Филиальный контроль отключено, «следующей инструкцией является указанный в поле Следующий адрес». Таким образом, одна гипотетическая ситуация заключалась бы в том, что после переполнения реестр (с использованием каналов для обозначения разделения между битовыми полями) читал:

10111 | 0000000 | 0000000 | 0

Экстраполируя назад, к приросту и переполнению, реестр должен выглядеть:

10110 | 1111111 | 1111111 | 1

Одним интересным побочным эффектом работы с этой реализацией является то, что используемая инструкция не имеет значения. Каждая инструкция RPC-4000 содержит адрес следующей инструкции. Переполнение бита индекса в следующее поле адреса приведет к переходу в этот адрес независимо от битов команды.

Эпилог

MiGjYka4199vjdbxDAskYWf9anRYPPUg72Ev
Групповое фото из Librazette августа 1956 года

Мел Кэй (на фото стоит, крайне справа) продолжал работать и в конце концов ушел на пенсию. Фанат по имени Энтони Куоццо написал в 2014 году, что пытался связаться с Мелом:

В конце концов мне удалось связаться с Мэлом, но, к сожалению, я его отпугал. Это история на другой день… :-/ (источник)

Из уважения к конфиденциальности Мела я не буду публиковать никакой личной информации и придерживаюсь программы и истории. Если кто-то знает, как Мэл относится к своей популярности в Интернете, я хотел бы услышать от вас.

Я не поддерживал связи с Мелом, поэтому не знаю, подвергался ли он когда-либо потоку изменений, захлестнувших технику программирования с тех давно прошедших дней. Мне нравится думать, что он этого не сделал. – Эд Натер

Другие источники:

Дэйв работает отделом по связям с разработчиками в IBM. По каким-то причинам IBM не имеет SDK для RPC-4000.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *