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

Rod Pemberton wrote:
> "Frank Kotler" <spamtrap@[EMAIL PROTECTED]
> wrote in message
> news:pxeEj.12292$FK1.10586@[EMAIL PROTECTED]
> 
>>"properly, even if unnecessary" strikes me as an oxymoron.
> 
> Otherwise, you introduce asymmetric behavior into the assembler... i.e.,
> higher probability of coding errors IMO.  That's more confusing than an
> oxymoron.  ;)

Worse than a moreyoxon, even. But I don't see how matching the behavior 
of the hardware increases the probability of coding errors.

[even if we write "mov eax, ds"...]
>> how likely is it that anyone gives a
>>damn what happens to the high word?)
> 
> It' not likely I'd ever need it, but if I did it's likely I would expect
> 'mov ax, ds' in BITS32 to execute exactly like BITS16 - leaving upper
bits
> alone...

Agreed. We *need* the override here, no question. (when we need the 
instruction at all in 32-bit code...) But if an assembler were to screw 
up an instruction, this'd be a fairly painless one.

> As for the cpu dependent version, it's possible someone could be
> using that "defect" in a cpu detection routine.

What's the "CPU dependent version"? "mov eax, ds" (no override, in 
32-bit code)? Okay, you got it. (I'm not sure this *does* ever do 
anything but zero the high bits, but feel free to check.)

> I guess I believe in "Do no harm." when it comes to assemblers.

That's why we should *never* emit the useless, redundant, cache-filling 
override when segreg is the *destination*. This one really *is* "always 
16 bits". Might as well emit a "nop". Again, it'd be a painless one to 
get wrong.

Best,
Frank