This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ia32 suffix inconsistency


Mer 15.12.10, H.J. Lu <hjl.tools@gmail.com> wrote:
> > $ echo 'and $1,(%ebx)' | as
> > $ echo 'cmp $1,(%ebx)' | as
> > $ echo 'xor $1,(%ebx)' | as
> > $ echo 'or $1,(%ebx)' | as
> 
> Those insns extend immX to 32bit first.

I am just saying that this default make it easy to make an error.
For me, I was thinking I was accessing a byte - or more exactly
that AS would optimise it to a byte access because of the smaller
hexadecimal encoding of $1.

> > Note that optimising 'orl $0,(%ebx)' to 'orb $0,(%ebx)'
> > is incorrect
> 
> I don't quite follow you.
> 
> or $1,(%ebx)
> 
> has the same result as
> 
> or $0x00000001,(%ebx)
> 
> Both apply to 32bit memory.

But
orb $0,(%ebx)
does the or (no change of the value) and set the
zero flag if the *byte* is zero, and:
orl $0x00000000,(%ebx)
does the or (no change of the value) and set the
zero flag if the *dword* is zero, isn't it?

If the constant is not zero, anyway the zero flag will not
be set, so AS could optimise the hexadecimal encoding.
AS cannot optimise 'xor' and 'and' because the result can
be zero, but having a zero byte result is not the same as
a zero dword result.

Or did I suffer from a lack of coffee?

Regards,
Etienne.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]