Re: [PATCH] APM support doesn't compile with binutils 2.8.1.0.24

H. J. Lu (hjl@freya.yggdrasil.com)
Wed, 25 Mar 1998 12:29:14 -0800 (PST)

>
>
>
> On Wed, 25 Mar 1998, H. J. Lu wrote:
> > >
> > > push %ds : legal, should default to 32-bit mode, no override
> >
> > Does esp really change by 4 with opcode "0x1e" or "0x661e"?
>
> 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.

Please tell me how opcode "8c d8" will trach the high 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).

That is wrong since performance should be same for 16-bit and
32-bit forms. The only difference is "mov/movl %ds,%eax" will
trach the high 16 bits of %eax.

>
> > 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.
>

Can you send me a small code to very it on x86?

Thanks.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu