stringtranslate.com

Самоизменяющийся код

В информатике самомодифицирующийся код ( SMC или SMoC ) — это код , который изменяет свои собственные инструкции во время выполнения — обычно для уменьшения длины пути инструкции и повышения производительности или просто для уменьшения иным образом повторяющегося похожего кода , тем самым упрощая обслуживание . Этот термин обычно применяется только к коду, где самомодификация является преднамеренной, а не в ситуациях, когда код случайно изменяет себя из-за ошибки, такой как переполнение буфера .

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

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

Этот метод часто используется для условного вызова тестового/отладочного кода без необходимости дополнительных вычислительных затрат для каждого цикла ввода/вывода .

Изменения могут быть выполнены:

В любом случае изменения могут быть выполнены непосредственно в инструкциях машинного кода путем наложения новых инструкций на существующие (например: изменение сравнения и перехода на безусловный переход или, в качестве альтернативы, на « NOP »).

В архитектуре IBM System/360 и ее последователях вплоть до z/Architecture инструкция EXECUTE (EX) логически накладывает второй байт своей целевой инструкции на младшие 8 бит регистра 1. Это обеспечивает эффект самомодификации, хотя фактическая инструкция в хранилище не изменяется.

Применение на языках низкого и высокого уровня

Самостоятельная модификация может быть достигнута различными способами в зависимости от языка программирования и его поддержки указателей и/или доступа к динамическим «движкам» компилятора или интерпретатора:

язык ассемблера

Самоизменяющийся код довольно просто реализовать при использовании языка ассемблера . Инструкции могут динамически создаваться в памяти (или же накладываться поверх существующего кода в незащищенном хранилище программ) [1] в последовательности, эквивалентной тем, которые стандартный компилятор может генерировать как объектный код . С современными процессорами могут быть непреднамеренные побочные эффекты в кэше ЦП , которые необходимо учитывать. Этот метод часто использовался для тестирования условий «первого раза», как в этом соответствующим образом прокомментированном примере ассемблера IBM/360 . Он использует наложение инструкций для уменьшения длины пути инструкций на (N×1)−1, где N — количество записей в файле (−1 — накладные расходы на выполнение наложения).

SUBRTN NOP ОТКРЫЛСЯ ЗДЕСЬ ВПЕРВЫЕ?* NOP — x'4700'<Адрес_открытия> OI SUBRTN+1,X'F0' ДА, ИЗМЕНИТЬ NOP НА БЕЗУСЛОВНЫЙ ПЕРЕХОД (47F0...) ОТКРЫТЬ ВХОД И ОТКРЫТЬ ФАЙЛ ВХОДА, ТАК КАК ЭТО ПЕРВЫЙ РАЗОТКРЫТО ПОЛУЧИТЬ ВХОД НОРМАЛЬНАЯ ОБРАБОТКА ВОЗОБНОВЛЯЕТСЯ ЗДЕСЬ ...

Альтернативный код может включать проверку «флага» каждый раз. Безусловный переход немного быстрее, чем инструкция сравнения, а также сокращает общую длину пути. В более поздних операционных системах для программ, находящихся в защищенном хранилище, этот метод не мог использоваться, и поэтому вместо него использовалось изменение указателя на подпрограмму . Указатель находился бы в динамическом хранилище и мог бы быть изменен по желанию после первого прохода, чтобы обойти OPEN (необходимость сначала загрузить указатель вместо прямого перехода и ссылки на подпрограмму добавила бы N инструкций к длине пути, но было бы соответствующее сокращение N для безусловного перехода, который больше не требовался бы).

Ниже приведен пример на языке ассемблера Zilog Z80 . Код увеличивает регистр "B" в диапазоне [0,5]. Инструкция сравнения "CP" изменяется в каждом цикле.

;========== ORG 0H CALL FUNC00 HALT ;========== FUNC00: LD A , 6 LD HL , label01 + 1 LD B ,( HL ) label00: INC B LD ( HL ), B label01: CP $ 0 JP NZ , label00 RET ;==========

Самоизменяющийся код иногда используется для преодоления ограничений в наборе инструкций машины. Например, в наборе инструкций Intel 8080 нельзя ввести байт из входного порта, указанного в регистре. Входной порт статически закодирован в самой инструкции, как второй байт двухбайтовой инструкции. Используя самомодифицирующийся код, можно сохранить содержимое регистра во втором байте инструкции, а затем выполнить измененную инструкцию, чтобы достичь желаемого эффекта.

Языки высокого уровня

Некоторые компилируемые языки явно разрешают самомодифицирующийся код. Например, глагол ALTER в COBOL может быть реализован как инструкция ветвления, которая изменяется во время выполнения. [2] Некоторые методы пакетного программирования подразумевают использование самомодифицирующегося кода. Clipper и SPITBOL также предоставляют возможности для явного самомодифицирования. Компилятор Algol на системах B6700 предлагал интерфейс для операционной системы, посредством которого исполняемый код мог передавать текстовую строку или именованный файл диска компилятору Algol и затем мог вызывать новую версию процедуры.

В интерпретируемых языках «машинный код» является исходным текстом и может быть подвержен редактированию «на лету»: в SNOBOL исходные операторы, которые выполняются, являются элементами текстового массива. Другие языки, такие как Perl и Python , позволяют программам создавать новый код во время выполнения и выполнять его с помощью функции eval , но не позволяют изменять существующий код. Иллюзия изменения (даже если на самом деле никакой машинный код не перезаписывается) достигается путем изменения указателей функций, как в этом примере JavaScript:

 var f = функция ( x ) { return x + 1 };         // присваиваем новое определение f: f = new Function ( 'x' , 'return x + 2' );

Макросы Lisp также позволяют генерировать код времени выполнения без анализа строки, содержащей программный код.

Язык программирования Push — это генетическая система программирования , которая специально разработана для создания самомодифицирующихся программ. Хотя это не язык высокого уровня, он не такой низкий уровень, как язык ассемблера. [3]

Модификация соединения

До появления множественных окон системы командной строки могли предлагать систему меню, включающую изменение запущенного командного скрипта. Предположим, что файл скрипта DOS (или "пакетный") MENU.BAT содержит следующее: [4] [nb 1] 

 :начинать SHOWMENU.EXE

При запуске MENU.BAT из командной строки SHOWMENU отображает экранное меню с возможной справочной информацией, примерами использования и т. д. В конце концов пользователь делает выбор, требующий выполнения команды SOMENAME : SHOWMENU завершает работу после перезаписи файла MENU.BAT, чтобы он содержал

 :начинать SHOWMENU.EXE НАЗЫВАЙТЕ КАКОЕ-НИБУДЬ .BAT GOTO начало

Поскольку интерпретатор команд DOS не компилирует файл сценария и не выполняет его, не считывает весь файл в память перед началом выполнения и не полагается на содержимое буфера записи, при выходе из SHOWMENU интерпретатор команд находит новую команду для выполнения (она должна вызвать файл сценария SOMENAME в каталоге и через протокол, известный SHOWMENU), и после завершения этой команды он возвращается к началу файла сценария и повторно активирует SHOWMENU, готовый к следующему выбору. Если бы в меню был выбран выход, файл был бы перезаписан обратно в исходное состояние. Хотя это начальное состояние не использует метку, она или эквивалентный объем текста требуются, поскольку интерпретатор команд DOS вызывает позицию байта следующей команды, когда он должен начать следующую команду, таким образом, перезаписанный файл должен поддерживать выравнивание для точки начала следующей команды, чтобы действительно быть началом следующей команды.

Помимо удобства системы меню (и возможных дополнительных функций), эта схема означает, что система SHOWMENU.EXE не находится в памяти, когда активируется выбранная команда, что является существенным преимуществом в условиях ограниченного объема памяти. [4] [5]

Контрольные таблицы

Интерпретаторы управляющих таблиц можно считать, в некотором смысле, «самомодифицирующимися» с помощью значений данных, извлеченных из записей таблицы (а не специально вручную закодированными в условных операторах вида «IF inputx = 'yyy'»).

Программы канала

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

История

IBM SSEC , продемонстрированный в январе 1948 года, имел возможность изменять свои инструкции или иным образом обрабатывать их точно так же, как данные. Однако эта возможность редко использовалась на практике. [6] В ранние дни компьютеров самомодифицирующийся код часто использовался для сокращения использования ограниченной памяти или повышения производительности, или и того, и другого. Он также иногда использовался для реализации вызовов подпрограмм и возвратов, когда набор инструкций предоставлял только простые инструкции ветвления или пропуска для изменения потока управления . [7] [8] Такое использование все еще актуально в некоторых ультра- RISC -архитектурах, по крайней мере, теоретически; см., например, компьютер с одним набором инструкций . Архитектура MIX Дональда Кнута также использовала самомодифицирующийся код для реализации вызовов подпрограмм. [9]

Использование

Самоизменяющийся код может использоваться в различных целях:

Оптимизация цикла, зависящего от состояния

Пример псевдокода :

повторить N раз { если СОСТОЯНИЕ равно 1 увеличить А на единицу еще уменьшить А на единицу сделай что-нибудь с А}

В этом случае самомодифицирующийся код будет просто представлять собой переписывание цикла следующим образом:

повторить N раз { увеличить A на единицу сделай что-нибудь с А когда ГОСУДАРСТВО должно переключиться { замените код операции «увеличение» выше на код операции «уменьшение» или наоборот }}

Обратите внимание, что двухступенчатую замену кода операции можно легко записать как «xor var по адресу со значением «opcodeOf(Inc) xor opcodeOf(dec)»».

Выбор этого решения должен зависеть от значения N и частоты изменения состояния.

Специализация

Предположим, что набор статистических данных, таких как среднее значение, экстремумы, местоположение экстремумов, стандартное отклонение и т. д., должен быть рассчитан для некоторого большого набора данных. В общей ситуации может быть возможность связывания весов с данными, так что каждый x i связан с aw i и вместо проверки наличия весов для каждого значения индекса, могут быть две версии расчета, одна для использования с весами и одна без, с одной проверкой в ​​начале. Теперь рассмотрим еще один вариант, когда каждое значение может иметь связанное с ним логическое значение, чтобы обозначить, следует ли пропустить это значение или нет. Это можно было бы сделать, создав четыре пакета кода, по одному для каждой перестановки и раздувания кода. В качестве альтернативы, массивы весов и пропусков можно было бы объединить во временный массив (с нулевыми весами для пропускаемых значений) за счет обработки, и все равно будет раздувание. Однако с модификацией кода в шаблон для расчета статистики можно было бы добавить по мере необходимости код для пропуска нежелательных значений и для применения весов. Не будет никакого повторного тестирования опций, а доступ к массиву данных будет осуществляться один раз, как и к массивам весов и пропусков, если они задействованы.

Использовать как камуфляж

Самоизменяющийся код сложнее анализировать, чем стандартный код, и поэтому может использоваться в качестве защиты от обратного проектирования и взлома программного обеспечения . Самоизменяющийся код использовался для сокрытия инструкций по защите от копирования в дисковых программах 1980-х годов для таких систем, как IBM PC-совместимые и Apple II . Например, на IBM PC инструкция доступа к дисководу неint 0x13 отображалась в образе исполняемой программы, но она записывалась в образ памяти исполняемого файла после начала выполнения программы.

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

Самореферентные системы машинного обучения

Традиционные системы машинного обучения имеют фиксированный, заранее запрограммированный алгоритм обучения для настройки своих параметров . Однако с 1980-х годов Юрген Шмидхубер опубликовал несколько самомодифицирующихся систем с возможностью изменять свой собственный алгоритм обучения. Они избегают опасности катастрофических самопереписываний, гарантируя, что самомодификации выживут только в том случае, если они полезны в соответствии с заданной пользователем функцией приспособленности , ошибки или вознаграждения . [14]

Операционные системы

Ядро Linux в частности широко использует самомодифицирующийся код; это делается для того, чтобы иметь возможность распространять один двоичный образ для каждой основной архитектуры (например, IA-32 , x86-64 , 32-битный ARM , ARM64 ...), адаптируя код ядра в памяти во время загрузки в зависимости от конкретной обнаруженной модели ЦП, например, чтобы иметь возможность использовать преимущества новых инструкций ЦП или обойти аппаратные ошибки. [15] [16] В меньшей степени ядро ​​DR-DOS также оптимизирует критические для скорости разделы себя во время загрузки в зависимости от базового поколения процессора. [10] [11] [nb 2]

Несмотря на это, на метауровне программы по-прежнему могут изменять свое собственное поведение, изменяя данные, хранящиеся в другом месте (см. метапрограммирование ) или используя полиморфизм .

Ядро синтеза Массалина

Ядро Synthesis, представленное в докторской диссертации Алексии Массалин [ 17] [18], представляет собой крошечное ядро ​​Unix , которое использует структурированный или даже объектно -ориентированный подход к самомодифицирующемуся коду, где код создается для отдельных кваджектов , таких как файловые дескрипторы. Генерация кода для определенных задач позволяет ядру Synthesis (как JIT-интерпретатору) применять ряд оптимизаций, таких как свертывание констант или устранение общих подвыражений .

Ядро Synthesis было очень быстрым, но было написано полностью на ассемблере. Полученное в результате отсутствие переносимости не позволило идеям оптимизации Массалина быть принятыми каким-либо производственным ядром. Однако структура методов предполагает, что они могли бы быть реализованы языком более высокого уровня , хотя и более сложным, чем существующие языки среднего уровня. Такой язык и компилятор могли бы позволить разрабатывать более быстрые операционные системы и приложения.

Пол Хаеберли и Брюс Карш возражали против «маргинализации» самомодифицирующегося кода и оптимизации в целом в пользу снижения затрат на разработку. [19]

Взаимодействие кэша и самомодифицирующегося кода

В архитектурах без связанного кэша данных и инструкций (например, некоторые ядра SPARC , ARM и MIPS ) синхронизация кэша должна быть явно выполнена модифицирующим кодом (очистить кэш данных и сделать недействительным кэш инструкций для измененной области памяти).

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

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

Большинство современных процессоров загружают машинный код перед его выполнением, что означает, что если инструкция, которая находится слишком близко к указателю инструкций , будет изменена, процессор не заметит этого, а вместо этого выполнит код таким, каким он был до изменения. См. prefetch input queue (PIQ). Процессоры ПК должны правильно обрабатывать самомодифицирующийся код по причинам обратной совместимости, но они далеки от эффективности в этом. [ необходима цитата ]

Проблемы безопасности

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

Одним из механизмов предотвращения вредоносной модификации кода является функция операционной системы W^X (от "write xor execute"). Этот механизм запрещает программе делать любую страницу памяти как доступной для записи, так и доступной для исполнения. Некоторые системы не позволяют когда-либо изменять доступную для записи страницу, делая ее доступной для исполнения, даже если разрешение на запись удалено. [ требуется цитата ] Другие системы предоставляют своего рода " черный ход ", позволяющий нескольким отображениям страницы памяти иметь разные разрешения. Относительно переносимый способ обойти W^X — создать файл со всеми разрешениями, а затем дважды отобразить файл в память. В Linux можно использовать недокументированный флаг разделяемой памяти SysV, чтобы получить исполняемую разделяемую память без необходимости создания файла. [ требуется цитата ]

Преимущества

Недостатки

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

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

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

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

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

В некоторых средах самоизменяющийся код вообще не может использоваться, например:

Смотрите также

Примечания

  1. ^ В более поздних версиях DOS (начиная с версии 6.0) была введена внешняя команда CHOICE (в DR-DOS также внутренняя команда и директива CONFIG.SYS SWITCH ), поэтому для этого конкретного примера применения системы меню больше не было необходимости обращаться к самомодифицирующимся пакетным заданиям, однако для других приложений это по-прежнему оставалось жизнеспособным решением.
  2. ^ ab Например, при работе на процессорах 386 или выше более поздние обновления Novell DOS 7 , а также DR-DOS 7.02 и выше динамически заменят некоторые последовательности 16-битных REP MOVSWинструкций («копировать слова») по умолчанию в образе времени выполнения ядра на 32-битные REP MOVSDинструкции («копировать двойные слова») при копировании данных из одного места памяти в другое (и вдвое меньшем количестве необходимых повторений) для ускорения передачи данных на диск. Пограничные случаи , такие как нечетные количества, учитываются. [10] [11]
  3. ^ Например, MBR и загрузочные секторы DR-DOS (которые также содержат таблицу разделов и блок параметров BIOS , оставляя менее 446 и 423 байт соответственно для кода) традиционно могли самостоятельно находить загрузочный файл в файловой системе FAT12 или FAT16 и загружать его в память целиком, в отличие от их аналогов MS-DOS / PC DOS , которые вместо этого полагались на системные файлы, занимающие первые две записи каталога в файловой системе, и первые три сектора IBMBIO.COM, которые хранились в начале области данных в смежных секторах, содержащих вторичный загрузчик, для загрузки оставшейся части файла в память (требуя от SYS соблюдения всех этих условий). Когда была добавлена ​​поддержка FAT32 и LBA , Microsoft даже перешла на требование 386 инструкций и разделила загрузочный код на два сектора из соображений размера, что не было вариантом для DR-DOS, так как это нарушило бы обратную и кросс-совместимость с другими операционными системами в сценариях мультизагрузки и цепной загрузки , а также со старыми ПК . Вместо этого загрузочные секторы DR-DOS 7.07 прибегали к самомодифицирующемуся коду, программированию на уровне опкода на машинном языке , контролируемому использованию (документированных) побочных эффектов , многоуровневому перекрытию данных/кода и алгоритмическим методам сворачивания , чтобы по-прежнему вмещать все в физический сектор размером всего 512 байт, не отказываясь ни от одной из своих расширенных функций.

Ссылки

  1. ^ "HP 9100A/B". MoHPC - Музей калькуляторов HP . 1998. Перекрывающиеся данные и память программ / Самоизменяющийся код. Архивировано из оригинала 2023-09-23 . Получено 2023-09-23 .
  2. ^ "Оператор ALTER". Справочник языка COBOL. Micro Focus .
  3. ^ Спектор, Ли. «Эволюционные вычисления с Push: Push, PushGP и Pushpop» . Получено 25.04.2023 .
  4. ^ ab Fosdal, Lars (2001). "Самомодифицирующийся пакетный файл". Архивировано из оригинала 21-04-2008.
  5. ^ Пол, Матиас Р. (13 октября 1996 г.) [21 августа 1996 г., 1994]. Konzepte zur Unterstützung Administrationr Aufgaben in PC-Netzen und deren Realisierung für eine konkrete Novell-LAN-Umgebung unter Benutzung der Batchsprache von DOS . 3.11 (на немецком языке). Ахен, Германия: Lehrstuhl für Kommunikationsnetze ( ComNets ) и Institut für Kunststoffverarbeitung (IKV), RWTH. стр. 51, 71–72.(110+3 страницы, дискета) (Примечание. Разработка и реализация централизованно контролируемой модульной распределенной системы управления для автоматической настройки клиента и развертывания программного обеспечения с механизмом самовосстановления обновлений в средах LAN на основе самореплицирующихся и косвенно самомодифицирующихся пакетных заданий с нулевым объемом памяти вместо необходимости в резидентном программном обеспечении управления на клиентах.)
  6. ^ Баше, Чарльз Дж.; Бухгольц, Вернер ; Хокинс, Джордж В.; Ингрэм, Дж. Джеймс; Рочестер, Натаниэль (сентябрь 1981 г.). «Архитектура ранних компьютеров IBM» (PDF) . IBM Journal of Research and Development . 25 (5): 363–376. CiteSeerX 10.1.1.93.8952 . doi :10.1147/rd.255.0363. ISSN  0018-8646 . Получено 25.04.2023 . стр. 365: SSEC был первым работающим компьютером, способным обрабатывать свои собственные сохраненные инструкции точно так же, как данные, изменять их и действовать в соответствии с результатом. 
  7. ^ Миллер, Бартон П. (2006-10-30). «Binary Code Patching: An Ancient Art Refined for the 21st Century». Серия выдающихся лекторов Triangle Computer Science — семинары 2006–2007. Университет штата Северная Каролина , Кафедра компьютерных наук . Получено 25 апреля 2023 г.
  8. ^ Wenzl, Matthias; Merzdovnik, Georg; Ullrich, Johanna; Weippl, Edgar R. (июнь 2019 г.) [февраль 2019 г., ноябрь 2018 г., май 2018 г.]. "From hack to complicated techniques - A survey on binary rewriting" (PDF) . ACM Computing Surveys . 52 (3). Вена, Австрия: 49:1–49:36 [49:1]. doi :10.1145/3316415. S2CID  195357367. Статья 49. Архивировано (PDF) из оригинала 15.01.2021 г. . Получено 28.11.2021 г. . стр. 49:1: […] Первоначально двоичная перезапись была мотивирована необходимостью изменения частей программы во время выполнения (например, внесение исправлений во время выполнения на PDP-1 в 1960-х годах) […](36 страниц)
  9. ^ Кнут, Дональд Эрвин (2009) [1997]. "MMIX 2009 - RISC-компьютер для третьего тысячелетия". Архивировано из оригинала 2021-11-27 . Получено 2021-11-28 .
  10. ^ abcd "Caldera OpenDOS Machine Readable Source Kit (MRS) 7.01". Caldera, Inc. 1997-05-01. Архивировано из оригинала 2021-08-07 . Получено 2022-01-02 .[1]
  11. ^ abcd Пол, Маттиас Р. (1997-10-02). "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT". Архивировано из оригинала 2003-10-04 . Получено 2009-03-29 .[2]
  12. ^ Уилкинсон, Уильям «Билл» Альберт (2003) [1996, 1984]. «Червь H89: тестирование памяти H89». Страница компании Билла Уилкинсона Heath Company . Архивировано из оригинала 13.12.2021 . Получено 13.12.2021 . […] Помимо извлечения инструкции, Z80 использует половину цикла для обновления динамической оперативной памяти . […] поскольку Z80 должен тратить половину каждого цикла извлечения инструкции на выполнение других задач, у него не так много времени для извлечения байта инструкции , как для байта данных. Если одна из микросхем ОЗУ в месте доступа к памяти немного медленная, Z80 может получить неправильную комбинацию битов при извлечении инструкции, но получить правильную при считывании данных. […] встроенный тест памяти не выявит этот тип проблем […] это строго тест чтения/записи данных. Во время теста все выборки инструкций производятся из ПЗУ , а не из ОЗУ […] в результате чего H89 проходит тест памяти, но все еще работает нестабильно в некоторых программах. […] Это программа, которая тестирует память, перемещаясь через ОЗУ. При этом ЦП печатает текущий адрес программы на ЭЛТ , а затем извлекает инструкцию по этому адресу. Если микросхемы ОЗУ в порядке по этому адресу, ЦП перемещает тестовую программу в следующую ячейку памяти, печатает новый адрес и повторяет процедуру. Но если одна из микросхем ОЗУ достаточно медленная, чтобы вернуть неправильную комбинацию битов, ЦП неправильно истолкует инструкцию и будет вести себя непредсказуемо. Однако вполне вероятно, что дисплей зависнет, отображая адрес неисправной микросхемы. Это сужает проблему до восьми микросхем, что является улучшением по сравнению с проверкой целых 32. […] Программа […] выполнит тест на червя, передав инструкцию RST 7 (RESTART 7) из нижнего конца памяти до последнего рабочего адреса. Остальная часть программы остается неподвижной и обрабатывает отображение текущего местоположения команды RST 7 и ее перемещение . Кстати, программа называется тестом на червя , потому что, когда инструкция RST 7 перемещается вверх по памяти, она оставляет за собой липкий след из NOP (NO OPERATION). […]
  13. ^ Ортис, Карлос Энрике (29.08.2015) [18.08.2007]. "О самомодифицирующемся коде и ОС космического челнока" . Получено 25.04.2023 .
  14. ^ Публикации Юргена Шмидхубера о самомодифицирующемся коде для самореферентных систем машинного обучения
  15. ^ Пальцев, Евгений (2020-01-30). "Самомодифицирующийся код в ядре Linux - что, где и как" . Получено 2022-11-27 .
  16. ^ Wieczorkiewicz, Pawel. "Linux Kernel Alternatives" . Получено 2022-11-27 .
  17. ^ Pu, Calton ; Massalin, Henry ; Ioannidis, John (1992). Synthesis: An Efficient Implementation of Fundamental Operating System Services (PDF) (диссертация). Нью-Йорк, США: Department of Computer Sciences, Columbia University . Заказ UMI No. GAX92-32050 . Получено 25.04.2023 .[3]
  18. ^ Хенсон, Валери (2008-02-20). "KHB: Синтез: Эффективная реализация фундаментальных служб операционных систем". LWN.net . Архивировано из оригинала 2021-08-17 . Получено 2022-05-19 .
  19. ^ Хэберли, Пол ; Карш, Брюс (3 февраля 1994 г.). «Ио Ной Боччони - История футуристического программирования». Графика Обскура . Проверено 25 апреля 2023 г.

Дальнейшее чтение

Внешние ссылки