Re: gas and prefix's on x86

Re: gas and prefix's on x86

[Andrew Macleod]

>> On Tue, Apr 30, 2002 at 10:26:50AM +0930, Alan Modra wrote:
>> > On Mon, Apr 29, 2002 at 02:50:59PM -0700, Andrew Macleod wrote:
>> > > 	* config/tc-i386.c (extra_symbol_chars): Add '[' to the list.
>> > 
>> > OK.
>> 
>> Since I'm running around tidying loose ends, I've committed this
>> to mainline.

Thanks, I don't think I have write access to binutils anyway.

Andrew

Re: gas and prefix's on x86

[Alan Modra]

On Tue, Apr 30, 2002 at 10:26:50AM +0930, Alan Modra wrote:
> On Mon, Apr 29, 2002 at 02:50:59PM -0700, Andrew Macleod wrote:
> > 	* config/tc-i386.c (extra_symbol_chars): Add '[' to the list.
> 
> OK.

Since I'm running around tidying loose ends, I've committed this
to mainline.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gas and prefix's on x86

[Alan Modra]

On Mon, Apr 29, 2002 at 02:50:59PM -0700, Andrew Macleod wrote:
> 	* config/tc-i386.c (extra_symbol_chars): Add '[' to the list.

OK.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gas and prefix's on x86

[Andrew Macleod]

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

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

>> 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 currentlylooking at that to see if we could be handling the '[' the same as we do
>> a '(' character...?
>> 


OK, so if we add the '[' character to extra_symbol_chars[] in tc-i386.c,
this prevents do_scrub_chars from removing the space. extra_symbol_chars
claims to be a list of characters that an operand can start with that aren't
in the generic list. Seems like we should put '[' in the list too?

This patch solves my problem quite nicely:


Andrew

	* config/tc-i386.c (extra_symbol_chars): Add '[' to the list.

Index: config/tc-i386.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gas/config/tc-i386.c,v
retrieving revision 1.172.12.1
diff -c -p -r1.172.12.1 tc-i386.c
*** tc-i386.c	2001/12/10 22:39:04	1.172.12.1
--- tc-i386.c	2002/04/29 20:42:34
*************** typedef struct _i386_insn i386_insn;
*** 149,157 ****
  /* List of chars besides those in app.c:symbol_chars that can start an
     operand.  Used to prevent the scrubber eating vital white-space.  */
  #ifdef LEX_AT
! const char extra_symbol_chars[] = "*%-(@";
  #else
! const char extra_symbol_chars[] = "*%-(";
  #endif
  
  /* This array holds the chars that always start a comment.  If the
--- 149,157 ----
  /* List of chars besides those in app.c:symbol_chars that can start an
     operand.  Used to prevent the scrubber eating vital white-space.  */
  #ifdef LEX_AT
! const char extra_symbol_chars[] = "*%-(@[";
  #else
! const char extra_symbol_chars[] = "*%-([";
  #endif
  
  /* This array holds the chars that always start a comment.  If the

Re: gas and prefix's on x86

[Andrew Macleod]

>> > >> Andrew Macleod <amacleod@cygnus.com> 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...?

Andrew

Re: gas and prefix's on x86

[Alan Modra]

On Thu, Apr 25, 2002 at 11:46:14AM -0700, Andrew Macleod wrote:
> >> 
> >> Andrew Macleod <amacleod@cygnus.com> 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.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gas and prefix's on x86

[Andrew Macleod]

>> 
>> Andrew Macleod <amacleod@cygnus.com> 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

Andrew

Re: gas and prefix's on x86

[Ian Lance Taylor]

Andrew Macleod <amacleod@cygnus.com> writes:

> However, we can't issue that from the asm statement in 
> the conmpiler.

Can you do
     lock; incw [eax]x;
?

Ian

gas and prefix's on x86

[Andrew Macleod]

I've run into a problem using prefix's in the assembler on an x86 target
It looks like the initial processing of a line to be assembled strips out 
all the spaces after the first mnemonic. So the line 

   lock incw [eax]x

get compressed to

   lock incw[eax]x

before its passed to md_assemble(). When it is handled there, a '['
character is not expected to by jammed up against the instruction
like that (it seems to still be expecting a space), so we issue an 
error saying the '[' is invalid.  It does accept the lock prefix if
its on a seperate line by itself. ie

   lock
   incw [eax]x

works fine. However, we can't issue that from the asm statement in 
the conmpiler. The original source code looks like:

main()
  int x;
  asm {
     lock incw [eax]x;
  }
}

and its invalid to specify it as 
 asm {
     lock 
     incw [eax]x;
  }

Is this patch OK? I've tried to make it so that we won't accept incw[eax]x
by itself on a line.  Are there other characters other than a '[' that
we need to concern ourselves with?  Or should the space after incw simply
not have been removed at all?

Andrew



	* config/tc-i386.c (md_assemble): An instruction with a prefix can
	be followed by  a ']' character, as in 'lock incw [eax]x'


Index: gas/config/tc-i386.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gas/config/tc-i386.c,v
retrieving revision 1.172.12.1
diff -c -p -r1.172.12.1 tc-i386.c
*** gas/config/tc-i386.c	2001/12/10 22:39:04	1.172.12.1
--- gas/config/tc-i386.c	2002/04/25 16:24:40
*************** md_assemble (line)
*** 1269,1275 ****
  	if (!is_space_char (*l)
  	    && *l != END_OF_INSN
  	    && *l != PREFIX_SEPARATOR
! 	    && *l != ',')
  	  {
  	    as_bad (_("invalid character %s in mnemonic"),
  		    output_invalid (*l));
--- 1269,1280 ----
  	if (!is_space_char (*l)
  	    && *l != END_OF_INSN
  	    && *l != PREFIX_SEPARATOR
! 	    && *l != ','
! 	    /* If a prefix is present, there may be no space between the 
! 	       instruction and its operands, so we must allow certain other 
! 	       seperators if the instruction is not the first thing
! 	       on this line.  */
! 	    && (!(*l == '[' && (token_start != line))))
  	  {
  	    as_bad (_("invalid character %s in mnemonic"),
  		    output_invalid (*l));