> The current gas defaults to 16-bit and rejects movl. I can make it to
> accept "movl". I don't see it should default to 32-bit.
Does that mean that "push %ds" generates 0x66 0x1e ? If so that is
broken. Doing that not only incurs the extra cycles of the 0x66 override,
but also misaligns the stack (which causes all subsequent stack operations
to run slower).
In 32-bit code, if you think of the segment registers as 32-bit registers
with the top half unspecified and undefined then it all logically fits
together with the behaviour of x86 chips... regardless what the manuals
say.
For example, in 32-bit code, 0x1e causes a 4 byte quantity to be pushed on
the stack, the low two bytes of which are the 16-bits of %ds; the high two
bytes are undefined (and in fact differ from one processor to another --
we saw an instance of a bug involving this recently in Alan's 2.0.34pre2
patch which was fixed in pre3).
(And in 16-bit code if you think of the segregs as 16-bit registers
everything matches up with observed behaviour.)
It sucks yes, the manuals are wrong. But that's not unnormal for Intel's
manuals. There may even be an eratta on this issue, but I really wouldn't
waste time looking for it.
The defaults you chose for "push %segreg", "pop %segreg", "mov
%segreg,%eax" and so on should all be those which generate the fastest
correct code -- that is, they should all be without the 0x66 override.
When someone explicitly says "pushw", "popw", or "movw", or "mov
%segreg,%ax" then you must generate the override.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu