Помогите разобраться:
одна и таже последовательность команд генерирует разный код для разных режимов работы проца, а именно:
АСМ dump for 16 (real) dump for 32 (protected)
mov ax,0100 B81000 66B81000
mov ds,ax 8ED8 668ED8
xor si,si 33F6 6633F6
shl esi,4 66C1E604 C1E604
...
видно что дабавляюется коды 66, которые означают изменение разрядности операндов (ну или чтото такое ...)
анализируя этот пример можно придти к выводу что для РЕАЛ режима по умолчанию операнды подразумеваются по 16 бит, а для ПРОТЕКТЕД - по 32 бит. А чтобы уточнить разрядность операнда в конкретном случае используется префикс 66. Так ли это на самом деле или я чего то напорол выше ...?
И еще вопрос: что происходит если в реальном режиме проц доходит до операции с 32 битным операндом? разве не должно было происходить какоето исключение или еще чего ... Ведь в РЕАЛЕ проц работает как и8086, а ведь он не знает про ESI, например ...?

Тут дело не в защищённом и реальном режиме а разрядности
адреса сегмента кода.
Разрядность может быть 16и или 32х битная.
При этом в реальном и VM режимах она всегда 16и битная,
а вот в защищённом может быть и 16 и 32х.
Программистам проще делить в голове размерность операнда
на 3и возжможных величины байт, слово, двойное слово.
Но не так для декодера процессора.
Он делит на две группы - частичный операнд (всегда байт в обоих режимах) и полный (может быть слово или двойное слово).
И вторая группа разделяется на
1. Полный
2. Альтернативный полный.
Полный - всегда соответствует разрядности эффективного адреса.
Альтернативный полный - другой из двух (слово, двойное слово).
Так в 16и битном сегменте кода
полный - слово
альтернативный - двойное слово
в 32х битном
полный - двойное слово
альтернативный полный.

Частичный операнд (байта) в обоих режимах кодируется одинаково.
Префикс 66h как раз указывает что данная команда использует альтернативный полный.
Например
40h = inc ax в 16 битном коде, и inc eax в 32х битном
66h 40h = inc eax в 16 битном коде, и inc ax в 16и битном.

Огромный СЕНКС, многое прояснилось, но вот что еще затуманено: если в РЕАЛЕ и VM разрядность всегда 16х, то как расценивает проц работающий в одном из этих 2-х режимов появление 66h? Я лично не замечал ничего особенного - он их выполняет безовсяких проблем ...
Это под ДОС 7.1 (чистый) и под VM в ХР.

И еще сопутсвующий вопрос: можно ли както предопределить расположение сегментов в файле и соответственно в памяти после загрузки файла на исплнение, я имел в виду их очередь, т.к. по умолчанию он кидает сперва сегменты кода а затем сегменты данных.
И можно ли както узнать размер сегмента? Может есть какая-то директива? Или еще как. Думаю можно так:
begin_s equ $
.... ; data
end_s equ $
size equ end_s-begin_s
А альтернативного пути нет?

Дополнение к первому вопросу:

и реальном addr size можент быть 32, тк. он определяется атрибутами в скрытом дескрипторе, который универсален для всех режимов. На этом и основан нереальный режим: открываем вентиль (если надо более 1 мб), идем в защищенный, меняем атрибуты дескриптора кода в gdt (D=1), переходим на этот сегмент джампом, автоматом апдейтится скрытый дескриптор CS, возвращаемся в реальный и до перезагрузки CS пользуемся всеми благами 32-битного адреса.

Конечно, addr size влияет только на полный адрес, а не на imm8

А вот как расценивает проц в реальном смену размера адреса, когда переопеределяешь его, записанный в скрытом дескр, префиксом, уже не помню. Не поленись, бутнись с флопа, проверь сам, зацикливает ли его на 0xFFFF. Если не зациклит, то наверное будет GP. Если мне память не изменяет, когда я проверял, GP не было.

Не раз про него режим слышал но не разу не видел. Может у кого нибудь есть програмка которая его демонстрирует? Поделитесь пожалуйста!

Было все на тасме, но винт тот уже не восстановить. Выяснил почти все вопросы, осталось только выяснить, все ли атрибуты дескриптора поддерживаются в нереальном режиме, как винт упал. Отформатил, поставил 2k и уже почти 3 года наслаждаюсь!

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

А как на счет другой части вопроса - что происходит когда встречается префикс изменения разрядности операндов в реальном режиме? Как на это реагирует проц?

Досмотри мой предыдущ пост. Пожалуйста, проверь - интересно. Но в реальном, не виртуальном!

проверить могу, но давайте уточним - что должно быть в бутсекторе?
бутсектор грузится на 0000:7С00, нам надо прыгнуть на 0000:FFFE, записав туды предварительно JMP $, я правильно понял? т.е.
0000:7CXX ???? MOV word ptr [FFFE],FEEB
JMP FFFE
...
0000:FFFE EBFE JMP FFFE - по моему так

проверить могу, но давайте уточним - что должно быть в бутсекторе?
бутсектор грузится на 0000:7С00, нам надо прыгнуть на 0000:FFFE, записав туды предварительно JMP $, я правильно понял? т.е.
0000:7CXX ???? MOV word ptr [FFFE],FEEB
JMP FFFE
...
0000:FFFE EBFE JMP FFFE - по моему так

Да нет, я имею в виду 98-ую дискету!
Command prompt

Прога должна выводить через текстов видеобуф инфу обо всех исключениях и сбойн адрес!

Я тебя не совсем понял. Я еще не работал с исключениями, так что это проблематично ...
Может подкинешь алгоритм на скорую руку.

Извини, я подумал (и Svin тоже кажется) что ты про адрес .
С операндом все проще - он меняется на 32, не вопрос, бит D - просто дефолт. А вот с addr size (точнее даже с превышением предела сегмента) сложнее.

Это правка, про адрес "ответ" уже накатал:

Накатать могу, но проверять времени нет - работы много. Когда я сам трахал свой проц много ночей сидел прежде чем разобрался. Поэтому только псевдокод.
У тебя должна быть функция для преобразования числа в шестн. строку для вывода. Поищи где-нибудь или сам напиши - используй xlat например. Само исключение должно или скорее не должно возникать когда ты перепрыгиваешь через 64 кило эфф адреса в сегменте. Положи (ручками, энкодингом!) в конце 64-го кила и сразу после границы несколько валидных команд nop например и прыгни в конец не на последнюю. Она исполнится и дальше если адрес 16 бит вместо инструкции по 0x10000 будет исполнена по адресу 0x0000. Это для сравнения. Тебе для решения твоей проблемы надо прыгнуть теперь на инструкцию по адр 0x10002 скажем - она должна быть джампом на строго определенное место где ты выведешь в буфер информацию, что барьер преодолен. Этого не должно быть, но на всяк случай сделай. Вар 2 - будет фолт, обработчик должен быть настроен. Вариант 3 - адрес обрежет, вместо 0x10002 будет 0x0002 - и это ты должен вывести, по адресу 0x0002 должен сидеть обработчик. Проделай все near jump с размером операнда (target_addr) 16 и 32 и сравни. Обязательно расскажи - ведь поведение в реальном режиме должно чем-то отличаться от защищенного.



Хоть тебя opsize интересовал, все-таки тебе хорошее упражнение было бы с addr size разобраться.

Короче запомни формулу:
режим - пофигу,
адрес или операнд определяется дефолтом - битом D скрытого дескриптора,
префиксы 66h и 67h воздействуют не на опкоды с imm8, а на опкоды с imm16/32, reg/mem 16/32.
Тонкости - только с адресом в реальном режиме, если при этом D=0 - это надо проверить.

Так что реальный режим - тоже 32-разрядный, воспринимает команды с префиксом изменения размера операнда target_address (call, jmp, ret, но не iret конечно), но, возможно, обрезает target_address при D=0