On Mon, 28 Mar 2005, Andi Kleen wrote:
>
> "H. J. Lu" <[email protected]> writes:
> > The new assembler will disallow them since those instructions with
> > memory operand will only use the first 16bits. If the memory operand
> > is 16bit, you won't see any problems. But if the memory destinatin
> > is 32bit, the upper 16bits may have random values. The new assembler
>
> Does it really have random values on existing x86 hardware?
The upper bits are not written at all, so it's not random.
> If it is a only a "theoretical" problem that does not happen
> in practice I would advise to not do the change.
My preference too. The reason we use "movl" is because we really do want
the 32-bit versions, since they are faster. It's a conscious choice. In
contrast "movw" generates bigger and slower code on all assemblers out
there, and "mov" doesn't make it clear which one it is. Is it the slow
one, or the fast one?
For example, "mov %ds,%eax" does seem to generate the (faster) 32-bit code
on modern assemblers, while "mov %ds,%ax" generates (slower) 16-bit code
that leaves the high bits of %eax untouched. Sometimes you may want the
slower one, sometimes the faster one. I have this pretty strong memory of
old versions of gas not making any difference between %ax and %eax as a
target, and that you really needed to set the size explicitly.
Now, those versions of gas may be so old that nobody cares, but the
explicit size still is a GOOD THING. The size DOES MATTER. People who want
the smaller and faster version do not want to just rely on gas
automatically getting it right, especially since gas has historically been
very very bad at getting things right.
What is the advantage of not allowing "movl %ds,mem"? Really? Especially
since I suspect the kernel is pretty much the only one who does this, and
the kernel really does do it on purpose. The kernel explicitly wants the
32-bit version, knowing that the upper bits are undefined.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
