LOADALL — это общее название для двух разных недокументированных машинных инструкций процессоров Intel 80286 и Intel 80386 , которые обеспечивают доступ к областям внутреннего состояния процессора, которые обычно находятся за пределами области действия API IA-32 , например, к регистрам кэша дескрипторов . LOADALL для процессоров 286 имеет кодировку 0Fh 05h, [1] , а LOADALL для процессоров 386 — 0Fh 07h. [2]
Оба варианта, как следует из названия, загружают все внутренние регистры ЦП за одну операцию. LOADALL обладал уникальной способностью настраивать видимую часть сегментных регистров (селектор) независимо от их соответствующей кэшированной части, что позволяло программисту переводить ЦП в состояния, не разрешенные официальной моделью программирования.
В качестве примера полезности этих методов можно отметить, что LOADALL может настроить ЦП на разрешение доступа ко всей памяти из реального режима без необходимости переключения его в нереальный режим (который требует переключения в защищенный режим , доступа к памяти и, наконец, переключения обратно в реальный режим). режим). Такие программы, как версии RAMDRIVE.SYS (1985) до XMS , [3] [1] [4] SMARTDRV.SYS (1986) [4] , а также HIMEM.SYS (2.03, 1988-08-04; 2.04). , 17 августа 1988 г.) [4] драйверы в MS-DOS , The Extender (1985) и The Connector (1985) Uniform Software Systems для Lotus 1-2-3 , Upper Disk (1986) [5] ( LIMulator компанией Upper Software (ранее Tele-Ware West, также известной как Los Angeles Securities Group), которая преобразовывала пространство на жестком диске или расширенную память в расширенную память ), а OS/2 1.0 [3] [1] и 1.1 [6] использовали инструкцию 286 LOADALL. DOS 3.3 и 4.0 зарезервировали 102-байтовый буфер по адресу 0070:0100h (который обычно был занят данными DOS BIOS ), так что не было необходимости сохранять и восстанавливать его для LOADALL. Microsoft EMM386.EXE использует в своем обработчике недопустимого кода операции инструкции LOADALL 286 и 386 . [7] Исследование кода монитора виртуальной машины в Windows/386 2.10 показывает, что он использует как 286 [ нужна цитата ] , так и ещё менее известный вариант 386 [ нужна цитата ] . Microsoft HIMEM.SYS версии 2.06 [8] также использовала LOADALL для быстрого копирования в расширенную память и из нее в 286 системах.
Еще одно интересное использование LOADALL, изложенное в книге « Проектирование OS/2» [ 9], могло бы заключаться в том, чтобы позволить запускать бывшие программы реального режима в 16-битном защищенном режиме, который использовался в Concurrent DOS 286 компании Digital Research с тех пор . 1985, [10] [11] [12] , а также ОС FlexOS 286 [13] и IBM 4680 [14] [15] с 1986 года. Пометка всех кешей дескрипторов в GDT и LDT как «отсутствующие» позволила бы работать система для перехвата перезагрузок регистров сегментов, а также попыток выполнения «арифметики сегментов», специфичной для реального режима, и эмуляции желаемого поведения путем обновления дескрипторов сегментов (снова LOADALL). Однако этот « режим эмуляции 8086 » для 80286 был слишком медленным, чтобы быть практичным. Более того, от этой идеи пришлось отказаться из-за ошибок в некоторых ранних процессорах Intel 80286 до перехода на степпинг E-2 . [10] [11] [13] В результате OS/2 1.x – а также Windows в «стандартном» режиме – должны были запускать программы DOS в реальном режиме. Тем не менее идея не пропала; это привело к тому, что Intel представила виртуальный режим 8086 для 80386, что позволило наконец реализовать « коробки DOS » относительно эффективным и документированным способом.
Поскольку LOADALL не выполнял никаких проверок достоверности данных, загружаемых в регистры процессора, можно было загрузить состояние процессора, в которое невозможно было нормально войти, например, используя реальный режим (PE=0) вместе с подкачкой (PG=1). ) на процессорах класса 386. [2]
Внутрисхемный эмулятор (ICE) — это инструмент, используемый для низкоуровневой отладки. В Intel 80386 установка недокументированного контакта в позиции B6 приводит к тому, что микропроцессор останавливает выполнение и переходит в режим ICE. Микропроцессор сохраняет все свое состояние в области памяти, изолированной от обычной системной памяти. Расположение этой области подходит для инструкции LOADALL, и эта инструкция используется кодом ICE для возврата к нормальному выполнению.
В более поздних процессорах это превратилось в режим управления системой (SMM). В SMM инструкция RSM используется для загрузки полного состояния ЦП из области памяти. Структура этой области памяти аналогична той, которая используется инструкцией LOADALL. [16] Инструкция LOADALL в стиле 386 также может быть выполнена на 486, но только в режиме SMM. В более поздних процессорах ее роль взяла на себя инструкция RSM, с другой кодировкой.
Codeview 3.0 от Microsoft и Turbo Debugger 2.0 от Borland правильно декодируют инструкции LOADALL 286 и 386. [1]
Поскольку две инструкции LOADALL никогда не документировались и не существуют в более поздних процессорах, коды операций были повторно использованы в архитектуре AMD64 . [17] Код операции для инструкции 286 LOADALL, 0F05, стал инструкцией AMD64 SYSCALL; инструкция 386 LOADALL, 0F07, стала инструкцией SYSRET. Эти определения были реализованы даже на процессорах Intel с появлением реализации AMD64 в Intel 64 . [18]
Код операции 0F05. Инструкция считывает данные с адресов 0x00800–0x00866 независимо от содержимого регистров сегмента.
Инструкцию 80286 LOADALL нельзя использовать для переключения из защищенного обратно в реальный режим [19] (она не может очистить бит PE в MSW). Однако использование инструкции LOADALL позволяет вообще избежать необходимости переключения в защищенный режим.
Код операции 0F07. Инструкция загружает данные с адреса ES:EDI. На самом деле он использует ES, а не дескриптор ES.