Рабочий пример инструкций CLI и STI в 16-битной сборке x86

Конечно, весь смысл cli/sti заключается в управлении обработкой аппаратных прерываний, поэтому вам необходимо некоторое понимание того, как вообще работают аппаратные прерывания.

Вот краткий обзор: аппаратное устройство, подключенное к ЦП, может инициировать аппаратное прерывание (в случае 8086, подключив высокое напряжение к выводу INTR на микросхеме ЦП и используя другие выводы, чтобы сигнализировать, какой вектор прерывания должен быть называется). Когда это происходит, если установлен флаг прерывания, то ЦП завершает выполнение инструкции, которая в данный момент выполняется, затем помещает в стек CS, IP и FLAGS и переходит к адресу, указанному в соответствующей записи таблицы векторов прерываний, что это младшие 1024 байта памяти (0000:0000-0000:0400). Программист должен был предварительно установить эту запись так, чтобы она указывала на блок кода (обработчик прерываний), который должен выполняться в ответ. Обработчик прерывания сделает все необходимое для обработки аппаратного прерывания, а затем выполнит IRET, чтобы вернуться к тому коду, который был прерван. Примерами устройств, вызывающих аппаратные прерывания, могут быть: нажатие клавиши на клавиатуре, поступление байта на последовательный порт, прерывание по таймеру (MS-DOS настраивает внешний таймер на генерацию прерывания с частотой 18,2 Гц, т. е. каждые 55 мс).

Если флаг прерывания не установлен, ничего не происходит, но обработчик прерывания будет вызван, когда флаг снова будет установлен.

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

Например, рассмотрим прерывание по таймеру. Простой обработчик может ничего не делать, кроме как увеличивать счетчик, чтобы основной поток выполнения мог сказать, сколько времени прошло. (В 8086 не было другого встроенного оборудования часов.) Если 16-битного счетчика достаточно, вы могли бы просто иметь:

ticks DW 0
handler:
    inc word ptr [ticks]
    iret

main_code:
    mov ax, [ticks] ; now ax contains the number of ticks

Но при 18,2 Гц мы получаем очень близкое к 65536 тикам в час (думаю, поэтому было выбрано число 18,2), так что счетчик будет переполняться примерно каждый час. Это нехорошо, если вам нужно отслеживать более длинные временные интервалы, поэтому вместо этого мы должны использовать 32-битный счетчик. Поскольку x86-16 не имеет 32-битных арифметических инструкций, мы должны использовать пару ADD/ADC. Наш код может выглядеть так:

ticks DD 0
handler:
    add word ptr [ticks], 1
    adc word ptr [ticks+2], 0
    iret

main_code:
    mov ax, [ticks]
    ;;; BUG what if interrupt occurs here ???
    mov dx, [ticks+2]
    ; now dx:ax contains the 32-bit number of ticks

Но в этом коде есть ошибка. Если случайно произойдет прерывание таймера между инструкциями, помеченными BUG, основной код получит несинхронизированные младшее и старшее слова ticks. Предположим, например, что значение ticks равно 0x1234ffff. Основной код загружает младшее слово 0xffff в ax. Затем происходит прерывание таймера и увеличивается ticks, так что теперь это 0x12350000. Обработчик прерывания возвращается, и основной код выполняет mov dx, [ticks+2], получая значение 0x1235. Итак, теперь основной код загрузил значение 0x1235ffff, что очень неправильно: оно на целый час позже фактического времени.

Мы могли бы исправить это, используя cli/sti для отключения прерываний, чтобы прерывание не могло произойти на сайте, помеченном BUG. Исправленный код будет выглядеть так:

main_code:
    cli
    mov ax, [ticks]
    mov dx, [ticks+2]
    sti

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

Регистры процессора также являются общим ресурсом, как в примере с SS:SP, который вы заметили. Предположим, что стек в настоящее время находится на 1234:5678, и основной код хочет переключить его на 2222:4444. Вы бы подумали сделать:

switch_stack:
    mov ax, 0x2222
    mov ss, ax
    ;;; BUG: what if interrupt occurs here?
    mov sp, 0x4444

Если бы в строке BUG произошло прерывание, значение SS:SP было бы 2222:5678, и именно здесь ЦП передаст значения CS/IP/FLAGS перед переходом к обработчику. Это было бы очень плохо, так как это не правильное расположение ни старого, ни нового стека. По этому адресу могут быть важные данные, которые ЦП сейчас перезаписывает, и поэтому теперь у нас есть трудно воспроизводимая ошибка повреждения памяти.

Таким образом, мы также подумали бы, чтобы исправить это с помощью

switch_stack:
    mov ax, 0x2222
    cli
    mov ss, ax
    ;;; interrupt can't occur here!
    mov sp, 0x4444
    sti

Сейчас так получилось, что это на самом деле частный случай. Поскольку в такой ситуации было бы особенно неприятно забыть отключить прерывания, разработчики 8086 решили оказать небольшую услугу программистам. Инструкция mov ss, reg имеет особую функцию, которая автоматически отключает прерывания для одной инструкции. Так что на самом деле, если вы кодируете mov ss, ax, за которым сразу следует mov sp, 0x2222, прерывание не может произойти между ними, и код на самом деле безопасен без cli/sti.

Но еще раз подчеркну, что это уникальный частный случай. Я считаю, что только mov ss, reg и pop ss обладают такой функциональностью, поэтому такие примеры, как 32-битный счетчик тиков, действительно нуждаются в cli/sti. И на самом деле, если бы вы поменяли местами две инструкции и закодировали mov sp, 0x2222, а затем mov ss, ax (что на первый взгляд выглядело бы так же хорошо), у вас снова была бы ошибка, и обработчик прерывания мог бы быть вызван со стеком, указывающим на 1234:2222. Также, как отметил @ecm в комментарии, некоторые ранние чипы 8086/8088 имели аппаратную ошибку (?), из-за которой функция «отключить прерывания для одной инструкции» не работала, поэтому на таких чипах вам также пришлось бы используйте cli/sti. (Или, может быть, эта функция не была частью спецификации до более позднего времени?)

В 386 добавлена ​​инструкция lss для загрузки как сегмента стека, так и указателя стека в одной инструкции, что было более надежным способом решения этой проблемы. Это также было более важно в этом случае, потому что в виртуальном режиме 8086 cli/sti не выполнялся бы напрямую, а вместо этого перехватывал бы операционную систему, которая была очень медленной, и ее лучше избегать, если это возможно.

Вы предполагаете, что, возможно, это настолько маловероятно, что нам не стоит об этом беспокоиться. Давайте посмотрим на наш пример с 32-битным таймером и представим приложение с функцией «будильник». Выполняя другую работу, он периодически проверяет счетчик тиков, скажем, около 100 раз в секунду, чтобы узнать, прошло ли заданное время, и если да, то делает что-то, чтобы предупредить пользователя. Если вы опустите cli/sti, то, если там произойдет прерывание с младшим словом, равным 0xffff (что происходит раз в час), он будет думать, что время на один час позже, чем оно есть, и поэтому может выдать предупреждение до одного. час слишком рано. (Если вы хотите быть более драматичным, замените «подать сигнал тревоги» на «активировать опасную технику», «запустить ракеты» и т. д.)

Инструкция mov ax, mem на процессоре 8086 заняла 10 тактов, то есть 1000 тактов в секунду, когда мы уязвимы. Первоначальный IBM PC работал на частоте 4,7 МГц, поэтому у нас есть вероятность 1/4700 в начале каждого часа срабатывания ошибки. Если вы отправляете свое приложение 50 000 пользователей, и каждый из них использует его по 8 часов в день, то, немного подсчитав, вы можете получить 425 жалоб на эту ошибку в течение первой недели после выпуска. Ваш босс будет очень зол.

И помните, мы вернулись в середину 1980-х, и Интернета нет, поэтому вам придется отправить каждому из ваших 50 000 клиентов по почте дискету с патчем. Эта ошибка обошлась компании в пару долларов плюс почтовые расходы примерно в 100 000 долларов. Напротив, ваша зарплата программиста начального уровня в 1984 году составляла около 20 000 долларов в год. Как вы относитесь к своим шансам сохранить работу?