Operand-size and Address-size prefix bytes 
Author Message
 Operand-size and Address-size prefix bytes

Quote:

> I'm trying to understand the instruction encoding for the 80386 and am
> somewhat confused by the prefix bytes 0x67 & 0x66, which are called
> the "address-size" prefix, and "operand-size" prefix respectively.

> Using these prefix bytes toggles you from 16->32 bit mode or 32->16
> bit mode as appropriate.  However, it's unclear from the documentation
> I have exactly what all the ramifications are.

> Here's what I believe is currently what happens.  (Assume we're
> currently in 32-bit mode):

> Address-size prefix:

>  - Any displacement field in the instruction being decoded should be
>    interpreted to be 16-bits.
>  - The calculation of the "effective-address" (i.e. segment offset)
>    should be done as a 16-bit calculation.

Plus, it switches to using 16-bit addressing modes, which are different
from the 32-bit addressing modes (you can index off any reg in 32 bits
but not 16 bit modes for example)
Quote:

> Operand-size prefix:

>  - Any register reference should be to a 16-bit register.
>  - Any memory reference should be to 16-bits of memory.
>  - Any immediate data field in the instruction being decoded should be
>    interpreted to be 16-bits.

> If all of these assumptions are true, then I'm most of the way there
> in understanding how these encodings work.  However, one additional
> thing that's confusing is this -- if the "address-size" prefix is
> present, does the entire instruction encoding revert to the 8086
> 16-bit encoding?  This is important, because there are differences in
> how the modrm byte is interpreted in 16 versus 32-bit encoding....

Yep, like I say it does revert.  Same thing if you're in a 16-bit
segment, then address-size will switch you to using the 32-bit
encodings.

Davidwq

- Show quoted text -

Quote:
> Thanks.



Mon, 02 Mar 1998 03:00:00 GMT  
 Operand-size and Address-size prefix bytes
I'm trying to understand the instruction encoding for the 80386 and am
somewhat confused by the prefix bytes 0x67 & 0x66, which are called
the "address-size" prefix, and "operand-size" prefix respectively.

Using these prefix bytes toggles you from 16->32 bit mode or 32->16
bit mode as appropriate.  However, it's unclear from the documentation
I have exactly what all the ramifications are.

Here's what I believe is currently what happens.  (Assume we're
currently in 32-bit mode):

Address-size prefix:

 - Any displacement field in the instruction being decoded should be
   interpreted to be 16-bits.
 - The calculation of the "effective-address" (i.e. segment offset)
   should be done as a 16-bit calculation.

Operand-size prefix:

 - Any register reference should be to a 16-bit register.
 - Any memory reference should be to 16-bits of memory.
 - Any immediate data field in the instruction being decoded should be
   interpreted to be 16-bits.

If all of these assumptions are true, then I'm most of the way there
in understanding how these encodings work.  However, one additional
thing that's confusing is this -- if the "address-size" prefix is
present, does the entire instruction encoding revert to the 8086
16-bit encoding?  This is important, because there are differences in
how the modrm byte is interpreted in 16 versus 32-bit encoding....

Thanks.



Mon, 02 Mar 1998 03:00:00 GMT  
 Operand-size and Address-size prefix bytes

Quote:
>I'm trying to understand the instruction encoding for the 80386 and am
>somewhat confused by the prefix bytes 0x67 & 0x66, which are called
>the "address-size" prefix, and "operand-size" prefix respectively.

Yes, you seem to understand the operand and address override prefixes.
The operand size prefix is the most straightforward of the two.
The address size prefix is more quirky. As you stated, the address size
prefix will cause the ModR/M to be interpreted as an 8086 would.
The 386's ModR/M and 8086's ModR/M are different since the 386
has more possible addressing combinations, eg [EAX+EBX*2].
Also, the address size prefix is ineffectual for implicit stack operations,
eg PUSH EAX, as the address size is determined by the B bit in the
SS descriptor (SP or ESP), so only an operand size prefix applies before
PUSH EAX.

+-----------------------------------------------------------------------------+

+-----------------------------------------------------------------------------+



Tue, 03 Mar 1998 03:00:00 GMT  
 Operand-size and Address-size prefix bytes

Quote:
>I'm trying to understand the instruction encoding for the 80386 and am
>somewhat confused by the prefix bytes 0x67 & 0x66, which are called
>the "address-size" prefix, and "operand-size" prefix respectively.

..

Quote:
>If all of these assumptions are true, then I'm most of the way there
>in understanding how these encodings work.  However, one additional
>thing that's confusing is this -- if the "address-size" prefix is
>present, does the entire instruction encoding revert to the 8086
>16-bit encoding?  This is important, because there are differences in
>how the modrm byte is interpreted in 16 versus 32-bit encoding....

Yes, you're correct. Don't forget Protected Mode isn't necessary 32-bit mode,
the 386 is capable of executing 16-bit and 32-bit code simultanously (hope
I spelled it right). The segmentation unit and address generation unit have
no clue about real/protected, 16- or 32-bit instructions. It just gets a
segment, a base, an index and a scale. These are generated by the instruction
decoder. The instruction decoder uses the 'D'-bit XOR 'override(s)' to
determine if it should decode the next instruction as 16 or 32-bit. Yes, 16-bit
addresses are converted to 32-bit prior sending it to the address generation
unit...

('D' bit is found in the Code Segment Descriptor)

Herman



Tue, 03 Mar 1998 03:00:00 GMT  
 Operand-size and Address-size prefix bytes
Thanks for all the help.  Here's a summary of what I think I've been
told:

There are two modes of operation for interpreting instructions for the
80386.  These modes are independent of real/protected mode. and are
based on the "D" bit in the current code segment attribute bits.

If the "D" bit is 1, the default is 32-bit addresses and 32-bit or
8-bit operands.  Instructions are decoded using 80386 interpretations.

If the "D" bit is 0, the default is 16-bit addresses and 16-bit or
8-bit operands.  Instructions are decoded using 80286 interpretations
(which I believe for the most part are the same as the 8086).

There are two prefix bytes that invert the meaning of the "D" bit for
the current instruction being executed.  They are 0x67 & 0x66, called
the "address-size" prefix, and the "operand-size" prefix respectively.

Assuming we're in 32-bit mode ("D" bit is 1), the address-size prefix
will cause any displacement field in the instruction to be fetched as
a 16-bit value.  Also, the calculation of the segment offset is done
as a 16-bit calculation.

The operand-size prefix will cause any operand (register, immediate or
memory) to be 16-bits, and also implies any immediate operand being
decoded will be fetched as a 16-bit value.

If the "D" bit is 0 (we're in 16-bit mode), the reverse is true
(i.e. substitute "32" for "16" in the above two paragraphs).

These differences in operand and address calculation, and instruction
decoding are independent of the current mode ("protected", etc.) of
the processor.  They are based only on the setting of the "D" bit in
the current code segment description, and the usage of the two prefix
bytes.

Of course, one simple question begs to be asked -- why are there *two*
prefix bytes, but only one flag in the code segment descriptor?  I
suppose it might make sense to use the "operand-size" prefix byte if
you want to do a 16-bit operation while you're in 32-bit mode (or
vice-versa), however, the "address-size" prefix byte does not seem
that useful....

By the way -- one of these days I'm going to figure out all the subtle
differences between real/protected/virtual-8086 mode.  Does anyone
have a pointer to some "definitive" document talking about this?

Quote:

> I'm trying to understand the instruction encoding for the 80386 and am
> somewhat confused by the prefix bytes 0x67 & 0x66, which are called
> the "address-size" prefix, and "operand-size" prefix respectively.

> Using these prefix bytes toggles you from 16->32 bit mode or 32->16
> bit mode as appropriate.  However, it's unclear from the documentation
> I have exactly what all the ramifications are.

>  . . .



Tue, 03 Mar 1998 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. operand size prefix

2. Newbie: Q about default operand and address sizes

3. Why does loop use address size prefix

4. ANS Forth: Cell Size vs. Address Size

5. operand size

6. please help - operand size overrides

7. illegal size for operand

8. Equates - Operand Size

9. error: operands not same size

10. please help - operand size overrides

11. Memo file size error, 0 bytes filesize returned

12. Cluster size in bytes programatically

 

 
Powered by phpBB® Forum Software