создан 64битный кросс-тулчейн для DOS: dj64dev

В Ring3 она вызовет исключение, т.к. является привелигированной инструкцией. Т.е. использовать так можно, но я не слышал о таком.

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

Я предполагаю, что вы CLI делали как-то поздновато. Прерывание успевало проскочить, когда уже обработчики защ режима все деинициализированы.

Чего? Там ничего не надо деинициализировать.

Кстати… а вот такой вопрос: если у вас экстендер использует риалмод, то как же он обеспечит обработку в защ режиме тех прерываний, которые пришли пока мы были в реалмоде?

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

А под экстендером ведь кто-то может попробовать протмодовые драйвера

Где ты такие нашёл и зачем?

Чего? Там ничего не надо деинициализировать.

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

Он их и не обрабатывает в защищённом, они все досовские реального режима.

Да не, он их все как раз обрабатывает, и, если только прот-модовский клиент НЕ установил собственный обработчик, тогда экстендер перекинет прерывание в риалмоду. Если же установил - изволь вызвать клиентский обработчик.

например клавиатурный драйвер несложен, ради него переключаться в реальный режим может и не стали

Не, клава как раз часто в риалмод пробрасывалась. Но были ещё прерывания 2х таймеров (PIT, RTC), были прерывания от SB16. Последний вообще обязательно в прот моде обрабатывался, тут, что называется, без всяких Но и Если.

Где ты такие нашёл и зачем?

Как он там назывался… майлс-гордон саунд систем, чтоль? Не помню уже. Но все игрушки, что работали с дос4гв, использовали эту звуковую библиотеку. Она была полностью протмодовской, со всеми дровами, ЕМНИП.

не, она для этого как раз. :)

Наткнулся на ещё одну статью, почему довольно маловероятно, чтобы hlt использовалась в качестве syscall - в старые времена было много плохих компов (и особенно ноутбуков) с вероятно кривой реализацией acpi, которые зависали при её вызове.

Так что если кто-то её использовал так, то вряд ли во времена троек или на массовом ПО.

https://www.transl-gunsmoker.ru/2008/11/blog-post_13.html

Так вы же что-то путаете: статья про использование хлт в ядре винды95, то есть, по прямому её назначению: для павер менеджмента. А я говорю про её «альтернативное» назначение: делать сисколлы из в86.

Там написано, что оно висло на ряде дешёвых кривых ноутов. Т.е. проблема не в процессоре или ядре, а в кривом чипсете, acpi и т.д. Т.е. скорее всего оно бы висло при любом вызове hlt.

Это кстати объясняет, почему msdos не использовал её, а когда добавили - внесли не в ядро, а в отдельный драйвер power.exe, хотя freedos может без него.

Да не висело бы оно при любом вызове, как вы себе это представляете вообще? Команда даже не начинает выполняться в в86, а сразу бросает исключение. Там до павер менеджмента, коим и руководит ацпи, дело вообще не дойдет. Грубо говоря, проц не дернет ни 1 пином, сообщающим чипсету о необходимости задействовать павер менеждмент.

Пробовал я эти ребуты, проц в итоге терял прерывания время от времени (те, которые пришли во время ребута)

А, я кажется понял, в чём прикол. https://frolov-lib.ru/books/bsp.old/v06/ch2.htm

Смотрите, Фролов тут маскирует все прерывания через PIC.imr, а cli он, по ходу, вообще не делает при возврате (ну или я где-то пропустил). Спрашивается, зачем так делать? Ведь cli обычно хватает. Ни 1 программист вам не даст ответ. Но вот схемотехник вам бы мгновенно ответил, ведь для него ответ лежит на поверхности. Когда мы даём ресет на любую микросхему, у неё, как правило, все логические пины выставляются в +5в, то есть в единицу. И вот тут-то нас ожидает проблема, по тому, как ножка IntA тоже поднимется! Я говорил, что контроллер прерываний даже не узнает о ресете, но похоже, что тут-то я и попался: он как раз таки узнает, по поднятию IntA. После этого, затриггерится PIC.isr, ну и всё.

Вывод: читайте Фролова, и делайте всё как у него. :) Хоть там и нет объяснений, почему cli не достаточно, но, видимо, надо маскать именно через контроллер, а не через cli. В этом случае паразитный IntA будет просто проигнорирован контроллером. Кстати, Фролов так же отключает немаскируемые прерывания на время ресета. Зачем? Опять таки, неизвестно. Но, раз он это делает, то, значит, делать надо именно так. :)

если только прот-модовский клиент НЕ установил собственный обработчик, тогда экстендер перекинет прерывание в риалмоду. Если же установил - изволь вызвать клиентский обработчик.

А, собсно, этот вопрос тогда снимается сам собой. Ведь если делать всё по Фролову и маскать прерывания на контроллере, а не через cli, то в риалмоде они и не возникнут ни при каком раскладе. А значит, протмодовый обработчик не будет «обворован».