> There are lots of lines like the following in the patch(this if from the
> patch to arch/i386/kernel/head.S):
>
> - mov %dx,%ds; \
> - mov %dx,%es;
> + movl %dx,%ds; \
> + movl %dx,%es;
> [deleted]
> I might be totally off base here, but shouldn't all (most?) of these be
> "movw", not "movl" (16 bit moves, not 32 bit ones)?
The whole point of this patch is to *not* use the 16 bit moves. 16 bit
moves to/from segment registers cost a segment prefix; one extra byte,
and one extra cycle. Strictly speaking, we should use `movl %edx,%es'
and `movl %es,%edx', (or just `mov %edx,%es'), but I think old
assemblers don't accept these instructions (Can someone with
binutils-2.8.1 or 2.8.0 confirm this?).
Quoting from the Intel Architecture Instruction Set manual
(ftp download.intel.com:/design/intarch/manuals/24319101.pdf)
When operating in 32-bit mode and moving data between a segment
register and a general-purpose register, the Intel Architecture 32-bit
processors do not require the use of the 16-bit operand-size prefix (a
byte with the value 66H) with this instruction, but most assemblers
will insert it if the standard form of the instruction is used (for
example, MOV DS, AX). The processor will execute this instruction
correctly, but it will usually require an extra clock. With most
assemblers, using the instruction form MOV DS, EAX will avoid this
unneeded 66H prefix. When the processor executes the instruction with
a 32-bit general-purpose register, it assumes that the 16
least-significant bits of the general-purpose register are the
destination or source operand. If the register is a destination
operand, the resulting value in the two high-order bytes of the
register is implementation dependent. For the Pentium Pro processor,
the two high-order bytes are filled with zeros; for earlier 32-bit
Intel Architecture processors, the two high order bytes are undefined.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu