Rod Pemberton wrote:
> "Frank Kotler" <spamtrap@[EMAIL PROTECTED]
> wrote in message
> news:JN2Ej.7276$rR1.5825@[EMAIL PROTECTED]
>
>>rhyde@[EMAIL PROTECTED]
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 "im****tant" 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
|
