This is the mail archive of the 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: gas and prefix's on x86

>> > >> Andrew Macleod <> 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

    lock incw(%eax)

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


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