Re: mov seg, reg/mov reg, seg and size prefix


"Frank Kotler" <spamtrap@xxxxxxxxxx> wrote in message
news:JN2Ej.7276$rR1.5825@xxxxxxxxxxx
rhyde@xxxxxxxxxx wrote:
One curious thing I've noticed is that the presence/absence of a 0x66
size prefix byte, for 16-bit only instructions, is all over the map.
For example, consider the following two instructions:

mov ds, ax
mov ax, ds

Clearly, there are only 16-bit versions of these two instructions.

True, "mov ds, ax" and "mov ds, eax" - with and without the prefix, IOW
- do exactly the same thing. "mov ax, ds" and "mov eax, ds" are *not*
the same, and the prefix is relevant.

Some assemblers *always* put a 0x66 size prefix byte in front of the
encodings, some never do, and at least one (MASM) puts size prefix
bytes before one but not the other.

That's interesting... Nasm went round-and-round on the issue a while
back. Referring to segreg as a *destination*, Intel said "most
assemblers" emit the size prefix, and you could use "mov ds, eax"
(absurd, on the face of it) to avoid it. It sounded like they were
saying you should do it, but if you read closer, they almost said that
those "most assemblers" were "doing it wrong" to emit the useless prefix
- or making us write something that *looks* like a size-mismatch to
avoid it. We took an informal survey, and Masm was about the only
assembler that *was* doing it, at that time (Nasm used to, but stopped).
Sounds like Masm has stopped, too. Who's doing "both"?


Wow... That's not what I got from their doc's. What I got was, "If you use
the 16-bit form of mov to a segment register in 32-bit mode, instead of
using the 32-bit form of mov to a segment register in 32-bit mode, some
assemblers will generate an unecessary 0x66 operand size override prefix due
to the 16-bit segment register in the instruction." Since Randall was
referring to 16-bit instructions, I thought he was referring to 16-bit mode
too...

This is what I would expect an assembler to do:

BITS 16
mov ds, ax ; no 0x66
mov ds, eax ; yes 0x66, but unneeded
mov ax, ds ; no 0x66
mov eax, ds ; yes 0x66 - required because of cpu dependent 32-bit operation

BITS 32
mov ds, ax ; yes 0x66, but unneeded
mov ds, eax ; no 0x66
mov ax, ds ; yes 0x66 - required to ensure 16-bit only operation
mov eax, ds ; no 0x66

The reason I expect that is because the address and operand size prefixes
can be used to execute 16-bit code in a 32-bit segment and vice-versa. So,
I expect the assembler to place the overrides properly, even if unecessary.
But, the override prefixes are required to ensure the proper operation for
ax/eax.


Rod Pemberton

.

Relevant Pages

  • Multi-Statements Lines
    ... Therefore, i have developed and proposed a new Assembler, with ... Instructions are not isolated things, ... mov eax 0 ... a News Group that is supposed to address Assembly Programmers, ...
    (alt.lang.asm)
  • Re: Multi-Statements Lines
    ... Instructions are not isolated things, ... mov eax 0 ... a News Group that is supposed to address Assembly Programmers, ... Also when dealing specifically with assembler, it further separates the source from the disassembled code, making it even more difficult to debug nasty problems. ...
    (alt.lang.asm)
  • Re: Multi-Statements Lines
    ... Instructions are not isolated things, ... mov eax 0 ... assembler instructions as having one function. ... bash at learning Windows assembler programming. ...
    (alt.lang.asm)
  • Re: TYPE and SIZE Equivalent in NASM?
    ... If you are going to have an assembler perform type ... Instructions themselves don't have types - only data and instruction ... The same goes for all the MOV, ADD, INC instructions and all the other ... argument because MOVZX accepts this type/size there. ...
    (comp.lang.asm.x86)
  • Re: Type Checking, C vs. Assembly, & other stuff
    ... So the question I ask is "why do you disagree that an assembler ... >should check the types of the operands you feed to the instructions?" ... mov al, ... fild word [var] ...
    (alt.lang.asm)