Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segmentregister access)

[Linus Torvalds]

On Mon, 28 Mar 2005, Andi Kleen wrote:
>
> "H. J. Lu" <hjl@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/