32-разрядные регистры реального режима

Question

Я пишу код реального режима и использую 32-разрядные регистры для этого (с использованием префикса 0x66).

Я просматривал руководства Intel и не могу найти информацию, которую я ищу. См.: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html (я снял том 1 главы 1-7, а также конкретные инструкции из тома 2)

Гарантирует ли Intel конкретное поведение для следующего кода в коде реального режима? Это то же самое, что и код защищенного режима?

mov eax, <some constant> 
mov ebx, <some constant> 
add ax, bx ; Are the top bits of ax zero'd, sign extended or left? 
mov ax, <some constant> ; Does this leave top 16bits unchanged? 
; From what I can tell, the top 16bits are unchanged, but where is this documented? 

Примечание: Я не после того, как конкретных реализации акта (то есть код, который проверяет его - если каждая реализация не всегда действовала та же), там, где Intel зафиксировала это поведение.

Похожие: x86_64 registers rax/eax/ax/al overwriting full register contents

Как это отличается: Этот вопрос относится конкретно к реальной работе режима, и были ли замечание от связанного вопроса действительны в режиме реального времени.

Может ли кто-нибудь помочь мне найти, где я могу найти это документально для реального режима?

Answer 1

Тот факт, что 16-битные и 8-битные альтернативные имена регистров доступа только их соответствующие подразделы более или менее описаны в разделе 3.4.1 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture:

Как показано на рисунке 3-5, то более низкие 16 бит регистров общего назначения отображают непосредственно набор регистров, найденный в процессорах 8086 и Intel 286, и на них можно ссылаться на имена AX, BX, CX, DX, BP, SI, DI, и SP. Каждый нижних двух байтов регистров EAX, EBX, ECX и EDX может ссылаться на имена AH, BH, CH и DH (высокие байты) и AL, BL, CL и DL (низкие байты) ,

Поскольку документация не описывает эти альтернативные регистры как доступ ничего, кроме указанных частей регистра, нет никаких оснований предполагать, что они будут. Также обратите внимание, что раздел 3.4.1 применяется ко всем режимам работы процессора, кроме 64-битного режима, поэтому он также включает в себя реальный режим.

Раздел 3.4.1.1 охватывает то, что происходит в 64-битном режиме, что, когда поведение, описанное в посте вы связаны исходит от:

Когда в 64-битном режиме, размер операнда определяет количество значащих битов в регистре общего назначения:

• 64-разрядные операнды генерируют 64-разрядный результат в целевом регистре общего назначения.
• 32-разрядные операнды сгенерируют 32-разрядный результат с нулевым расширением до 64-битного результата в регистре назначения общего назначения .
• 8-разрядные и 16-разрядные операнды генерируют 8-разрядный или 16-разрядный результат. Верхние 56 бит или 48 бит (соответственно) регистра общего назначения назначения не изменяются операцией. Если результат 8-разрядной или 16-разрядной операции предназначен для вычисления 64-разрядного адреса, явным образом выставляю регистр до полного 64-битного.

Следует отметить, что 8-битные и 16-разрядные альтернативные регистры работают таким же образом в 64-битных режимах, как они это делают в других режимах.

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

Answer 2

Содержимое первых 16 бит остается неизменным. Существуют отдельные инструкции для нулевого расширения (MOVZX) и для расширения знака (MOVSX). Я уверен, что где-то там документировано, что топор относится к младшим 16 битам регистра eax, и в этом случае нулевое расширение будет «не по умолчанию», как в x86_64. Такое поведение также четко указано в документации x86_64.