Halt and Catch Fire

Существование некой ассемблерной команды, выполнение которой приводило бы компьютер в состояние неработоспособности, приписывалось компьютерам архитектуры IBM System/360. Мнемоническое обозначение ассемблерных команд выполнялось по аббревиатуре основной выполняемой функции команды, например ADD (добавить к числу другое число) или CMP (сравнить числа). В числе этих команд были неоднозначно интерпретируемые команды типа ZAP (буквально «Ударить током», на самом деле — Zero and Add Packed, «Обнулить регистр и добавить к нему упакованное десятичное число»)[1]. Программисты, работавшие с этим ассемблером, стали придумывать собственные мнемонические обозначения и приписывать им юмористическое толкование. Так, например, были придуманы команды XPR (Execute Programmer, «Казнить программиста»), CAI (Corrupt Accounting Information, «Испортить бухгалтерские данные»)[2], а также «SDI» (Self Destruct Immediately, «Немедленно самоуничтожиться»)[2] и CRN (Convert to Roman Numerals, «Преобразовать в римские числа»)[3]. Среди этих юмористических обозначений также появилась команда HCF (Halt and Catch Fire, «Зависнуть и загореться»)[4][5][6]. Первые упоминания о HCF появились где-то в середине 1970-х годов[4][5].

В первоначальном смысле значение catch fire подразумевало не буквальное воспламенение, а полную потерю функционирования до следующей «жёсткой» перезагрузки. Но были слухи и о поломках аппаратуры от неверных команд[7]. Существует городская легенда: на одном компьютере 1960-х годов всё повышали и повышали быстродействие магнитной памяти, прошитой тонкими проволочками. Обычной работе повышенные токи не мешали, однако операция HLT (Halt, ожидание сигнала от внешнего устройства) была реализована как «если сигнала не было, прыгнуть на тот же адрес». Многократное чтение одной и той же ячейки приводило к перегоранию соответствующей проволочки.

Микропроцессор Motorola 6800 стал первым процессором, в котором была обнаружена недокументированная инструкция, действия которой были схожи с HCF[8]. Компанией-разработчиком было документировано 197 операций (опкодов), тогда как архитектура процессора допускала 256 возможных комбинаций. Исследователь Джерри Вилер попробовал по очереди подать процессору оставшиеся 59 «недействительных команд», что привело к неожиданным результатам: одна из инструкций перевела процессор в нерабочий режим[8]:

Когда инструкция исполнялась, выяснить, что происходит, можно было только осциллографом. С пользовательской точки зрения машина останавливается и пресекает все попытки перезапустить. Индикаторы на адресной шине показывают, что процессор начинает очень быстро последовательно перечитывать всю память. В итоге адресная шина превращается в 16-битный счётчик. Тем не менее, процессор не обрабатывает то, что читает… он только читает.

Оригинальный текст (англ.)[показатьскрыть]

When this instruction is run the only way to see what it is doing is with an oscilloscope. From the user's point of view the machine halts and defies most attempts to get it restarted. Those persons with indicator lamps on the address bus will see that the processor begins to read all of the memory, sequentially, very quickly. In effect, the address bus turns into a 16 bit counter. However, the processor takes no notice of what it is reading… it just reads.

Другой исследователь, Девид Аданс, на это позднее отметил: «Инструкция DD переводила процессор в бесконечный цикл последовательного чтения адресного пространства памяти (некоторые инженеры называли эту инструкцию HCF, но мы ее называли инструкцией Drop Dead [Упасть замертво]). Режим Drop Dead отлично подходил для выявления проблем с аппаратной частью с помощью осциллографа; чтение адресов памяти и работа частотного генератора укладывались в красивые прямоугольные волны»[9]. Таким образом, данная инструкция являлась фактически недокументированной функцией ввода процессора в диагностический режим[10].

В других процессорах, во многом из-за ошибок проектирования либо недокументированных возможностей, также возможен эффект, похожий на режим команды HCF. Так в процессорах семейства Intel 8086 существовала инструкция HLT (Halt, «Остановка»), которая прекращала выполнение дальнейших инструкций и переводила процессор в режим остановки, из которого можно было выйти при получении соответствующего прерывания, исключения отладки, по сигналу BINIT, INIT или RESET[11]. В некоторых ранних чипах семейства 80486DX4 существовала проблема, из-за которой выход из режима HLT был невозможен, и систему оставалось только перезагрузить. Чтобы обойти эту проблему, разработчики ОС вводили режим no-hlt, который запускал бесконечный цикл ожидания вместо исполнения данной инструкции[12].

В более поздней линейке Intel Pentium существовала аппаратная проблема при выполнении инструкции F00F C7C8. В обычных условиях появление такой инструкции невозможно, однако злонамеренный программист мог вручную внести эту инструкцию в исполняемый код, что приводило к зависанию компьютера до следующей перезагрузки. Для решения проблемы Intel выпустила микрокод, исправляющий ошибку, а в дальнейшем избавилась от этой проблемы в последующий ревизиях процессоров[13][14].

У другого широко применявшегося в 1980-е годы процессора MOS 6502 существует 12 недействительных команд, которые приводят к его зависанию[15][16].

Процессор Z-80 также имеет последовательность команд, приводящую к зависанию: DI, HALT. В честь неё была названа демопати DiHalt.