Нереальный режим: преимущества и недостатки

Есть еще и третье мнение - правильное. Лимит нужно обязательно настраивать в PM, потому что в RM при перезаписи сегментных регистров он не затрагивается. В PM можно также настроить "большую" сегментную базу, но в этом нет особого смысла, потому что в RM при первой же перезаписи сегментного регистра она будет переписана как новое значение умножить на 16, причем мы должны сами выполнить эту операцию после возврата в RM, иначе текущие значения сегментных регистров могут оказаться недействительными.

 

Зы Это было второе мнение, извиняйте.

 

Я неявно уже назвал такой процессор - это i80386 - он портил лимит cs, правда, не факт, что это происходило именно в момент записи в cs, возможно, сброс происходил, когда обнулялся бит PE.

 

Мы вообще-то говорим не про разрядность кода, а про большие сегменты. Это мягко говоря не очень связано между собой. Единственный момент - это используемая процессором в RM разрядность (E)IP. Если процессор не позволяет изменить/не использует в RM старшие 16 бит EIP, то код максимум может иметь базу 0xFFFF0 и соответственно диапазон смещений 0-0xFFFF, т.е. размещаться максимум под границей 1 м 64 к - 16 б.

 

А вот мне интересно вот что: не будет ли выигрыша в скорости при использовании unreal?

Представим себе сферическую абстрактную задачу которой нужно относительно много вычислений сделать с использованием сучественного объема памяти (допустим, 40M). Допустим поиск коллизий у hash-func или что там еще.

Если ее реализовать на асме под a) PE, self-supervisor, задача выполняется в нулевом кольце с максимально простыми сегментами; b) Ring3, под управлением своего супервизора но идет выполнение в самом низком кольце; c) unreal режим; - где будет выше производительность (считаем что эффект прерываний нивилирован)?

 

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

 

Согласен. Я недаром разглагольствовал про нативный 32-разрядный код. В RM такое невозможно хотя бы в силу того, что там постоянно используется сторонний 16-разрядный код BIOS. Получается перед каждой 32-разрядной командой минимум один лишний префикс. Если учесть, что в современных процессорах на обработку префикса часто тратится не меньше времени, чем на выполнение самой команды, получается весьма красноречивая картина неэффективности использования 32-разрядного кода в нереальном режиме.

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

 

SII, Phantom_84

Вообще кажеццо что так и должно быть (по крайней мере я в таблице (старой) выполнения команд ф тактах видел что ring3 vs ring0 проигрывает, причем не только в in/out командах (особенно сильно), а и в обычных тоже).

Однако есть также ощущение что это не совсем нуль но малая вероятность что - несмотря на префиксы замены (которые конвеер по-идее глотает на-ура) unreal может обогнать ring0 за счет меньшего числа проверок всяких страничных выравниваний или атрибутов селекторов (чего он очевидно или не очень очевидно) не делает в realmode. Если взять за факт ring0 is faster than ring3 при прочих равных условиях то это как бы доказательство что все эти слои защиты могут играть роль большую долей процента в производительности...

Вообще все эти кэши второго и третьего уровня - они заточены прежде всего под ring3 (== под пользовательские проги) или под ring0?

 

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

под ring 2 и 3

 

т.е. я хотел сказать 1 и 2

 

Тут много говорили о неэффективности 32 битного кода в 16 битном нереальном режиме.
А простая мысль, что unreal может быть 32-битным в голову не приходила? )))

 

Не может.
Все обработчики прерываний установленные BIOS 16-битные.
Первое же аппаратное прерывание вызовет падение (разрядность 32->16 не переключится).
Код BIOS преимущественно 16-битный - т.е. вызывать тоже нельзя.
И нафига он тогда такой нужен, если BIOS не вызвать, сидеть с отключёнными прерываниями либо писать все обработчики самому.
Тогда проще писать все те же обработчики, но в PM32.

 

Мысль приходила, но не прошла контроль качества

 

А давайте попробуем замутить long unreal mode, может, прокатит

 

Проблема обходится. Все прерывания забираются себе. В обработчике переключаемся в обычный RM и вызваем биос, при возврате обратно в нереальный32. Правда возникают нюансы - к примеру, если во время работы биоса (обычный RM) возникнет неблокируемое прерывание. В этом случае наши обработчики должны правильно отработать как в 16, так и в 32 разрядном варианте.

 

а это как?

 

Medstrax

А зачем так нужно поддерживать BIOS в unreal32?

Если выйдет так что CPU будет работать быстрее и может быть еще быстрее за счет того как ты предлагаешь убрать префиксы - то выйдет чистая машина с полным доступом ко всей памяти и готовая к какой-нибудь расчетной задаче. Данные скидывать на винт?... Наверное, но их можно копить в памяти и переключаццо (редко) действительно в real mode.

Кстати, можно переключаться по всем прерываниям из unreal в ... обработчег SMM. В этом режиме проц опять в-какой-то мере восстановит real mode и уже оттуда можно звать BIOS... по крайней мере реальные обработчики SMI вызывают некоторые CALLBACK'и.

 

Детектить разрядность кодового сегмента, в зависимости от этого отдавать управление той или иной ветке

 

По идее можно, только накладные расходы большие, сохранение/чтение контекста не самая быстрая операция

 

так как детектить? я в этой проблеме не разбирался, но код то разный будет.