This is the mail archive of the
mailing list for the binutils project.
Re: gas and prefix's on x86
- From: Andrew Macleod <amacleod at cygnus dot com>
- To: amacleod at cygnus dot com, amodra at bigpond dot net dot au
- Cc: binutils at sources dot redhat dot com, bug-binutils at gnu dot org, ian at airs dot com
- Date: Mon, 29 Apr 2002 07:52:50 -0700
- Subject: Re: gas and prefix's on x86
>> > >> Andrew Macleod <firstname.lastname@example.org> writes:
>> > >>
>> > >> > However, we can't issue that from the asm statement in
>> > >> > the conmpiler.
>> > >>
>> > >> Can you do
>> > >> lock; incw [eax]x;
>> > No, same results:
>> > t1.cpp:110: expected instruction opcode
>> Use "lock/incw [eax]x" on linux, *bsd, i386aix.
>> "lock\incw [eax]x" on others.
That works in the assembler (If Im writing a .s file), but it doesn't
work from with an 'asm' insn in the C compiler.. We lose everything
after the lock, and I get the same message.
Why don't we fix the assembler to accept prefixes
with a space instead of having to specify a seperator character?
(I'm guessing there is some history here?)
The disassembler prints it with a space.
Hmm, actually, after fooling around a bit, I find that we do sometimes
accept prefixes with a space.. ie,
lock incw (%eax)
is accepted quite happily.... The reason is that
the assembler doesn't munge this line into
like it does with the '[' character.. so md_assemble()
sees the space between the incw and the operands.
This appears to be handled in do_scrub_chars() via a state machine. Im currently
looking at that to see if we could be handling the '[' the same as we do
a '(' character...?