I think both do exactly the same thing, but 0x661e is slower. I'd have to
test to be really sure.
> > mov %ds,%eax : legal, should default to 32-bit mode, no override
>
> FYI, binutils 2.8.1.0.25 doesn't allow it. I can fix it in
> 2.8.1.0.26. But according to Intel, the 2 high order bytes
> may be undefined in eax. I decide not to change it unless
> it is absolutely necessary.
It _is_ absolutely necessary, how do I generate the fastest possible code
otherwise (if I don't care about the high 16 bits)?
> > mov %ds,%ax : if gas notices that "%ax" is 16-bit it would be great.
>
> Yes, it does.
Good.
> > movw %ds,%ax : 16-bit, operand size override REQUIRED
>
> Why? binutils 2.8.1.0.25 optimizes it out. Intel says the override
> is NOT REQUIRED.
It _is_ required. If you don't have the operand size override, the
instruction will trash the high 16 bits of %eax, which is not what the
programmer asked for. The programmer asked for an instruction that will
only modify the low 16 bits of %eax.
> > movl %ds,%eax : 32-bit, no override
>
> It is the same as "mov %ds,%eax" in 2.8.1.0.25.
Right. But it _has_ to be different from "movw %ds,%ax", and gas _has_ to
accept both forms (the 32-bit form for performance, the 16-bit form
because a programmer may require the high bits to not change).
> Which Intel manual are you using? Mine explicitly says the 16-bit
> override is not required when moving data bewteen a segment register
> and a general purpose register.
It is wrong. Look at what the instruction actually does to the high 16
bits, and you will see why it is wrong.
IF all you care about is the low 16 bits in the register, then the operand
size does not matter, and leaving it out results in smaller and faster
code. But if you care about the high 16 bits being unmodified (ie "movw")
then you have to have the operand size override.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu