Halt and Catch Fire

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Halt and Catch Fire (мнемонический код HCF) — гипотетическая ассемблерная команда, при выполнении которой центральный процессор компьютера перестает выполнять дальнейшие команды, из-за чего для восстановления работоспособности необходимо выполнить «жесткую» перезагрузку.

История возникновения[править | править код]

Существование некой ассемблерной команды, выполнение которой приводило бы компьютер в состояние неработоспособности, приписывалось компьютерам архитектуры 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-битный счётчик. Тем не менее, процессор не обрабатывает то, что читает… он только читает.

Другой исследователь, Девид Аданс, на это позднее отметил: «Инструкция 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.

Примечания[править | править код]

  1. IBM System/360 Principles of Operation. IBM. Дата обращения: 2 июля 2014.
  2. 1 2 Dunlap, Bryan A Proposed Instruction Set (недоступная ссылка). Physics Department, The Ohio State University. Дата обращения: 11 мая 2017. Архивировано 8 сентября 2017 года.
  3. Far out op codes, Werner Cirsovius, <http://www.cirsovius.de/Firmen/Uni-Chaos/FUN/opcodes.html>. Проверено 28 мая 2015. 
  4. 1 2 «Subject: HCF instruction: from Principles of Operation», Archived at textfiles.com
  5. 1 2 Apocryphal opcode mnemonics, long , 23/04/1990, alt.folklore.computers, (via Google Groups)
  6. Overextended Mnemonics, Creative Computing Т. 6 (4): 17 (hex) (flip-side), April 1980, <https://archive.org/stream/creativecomputing-1980-04/Creative_Computing_v06_n04_1980_Apr#page/n205/mode/2up>. Проверено 12 марта 2017. 
  7. HCF. www.catb.org. Дата обращения: 8 сентября 2017.
  8. 1 2 Wheeler, Gerry. Undocumented M6800 Instructions (англ.) // BYTE : magazine. — 1977. — December (vol. 2, no. 12). — P. 46—47.
  9. Agans, David J. Debugging: the 9 indispensable rules for finding even the most elusive software and hardware problems (англ.). — New York: American Management Association, 2002. — P. 77. — ISBN 9780814426784.
  10. Daniels, R. Gary; Bruce, William. Built-In Self-Test Trends in Motorola Microprocessors (англ.) // IEEE Design & Test  (англ.) : magazine. — 1985. — April (vol. 2, no. 2). — P. 64—71. — doi:10.1109/MDT.1985.294865. «HACOF thus became the first intentional built-in self-test feature on a Motorola microprocessor.»
  11. x86 Instruction Set Reference: HLT (недоступная ссылка). Дата обращения: 2 июля 2014. Архивировано 14 июля 2014 года.
  12. Gortmaker, Paul The Linux Boot Prompt-How To. The Linux Documentation Project (21 марта 2003). Дата обращения: 2 июля 2014.
  13. Collins, Robert R. The Pentium F00F Bug: Workarounds for a nasty problem. Dr. Dobb's Journal (1 мая 1998).
  14. Pentium Processor Specification Update (неопр.). — Intel, 1999. — С. 51—52.
  15. Steil, Michael How MOS 6502 Illegal Opcodes really work. pagetable.com.
  16. Offenga, Freddy 6502 Undocumented Opcodes. NesDev.