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

Rod Pemberton wrote:
"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."

That's what I intended to say, more or less.

Since Randall was
referring to 16-bit instructions, I thought he was referring to 16-bit mode
too...

I'm pretty sure Randy remembers 16-bit code, but I don't think HLA does, so what we do in 32-bit code is probably the "important" point here.

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

Bloat! Bloat! Bloat! :)

Seriously, I'll agree that this one *really* "doesn't matter". But it seems "wrong" to me for an assembler to emit *any* unneeded byte. Besides the two "unneeded" cases - one if we're talking 32-bit code - I don't think there's any issue.

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.

"properly, even if unnecessary" strikes me as an oxymoron.

But, the override prefixes are required to ensure the proper operation for
ax/eax.

If segreg is the source, yes.

Randy's up to his ears, or deeper, in x86 encoding right now, so *surely* he knows better than to expect any such concept from x86, but he phrased the question as if "mov ds, ax" and "mov ax, ds" were "symmetrical". They are not. With ds as a destination, it really is "always 16-bit". With ds as source, the prefix makes a difference.

Eric Isaacson claims to have an "identifiable" object signature (based on other instructions, not these). Maybe Randy could emit the "bloat prefix" every third time it comes up. Then, if it showed up every six years, we'd know you were using HLA! :)

(maybe better make it 12 years... this is really small potatos! even with reg16/32 as a destination, how likely is it that anyone gives a damn what happens to the high word?)

Best,
Frank

.

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)