public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* RE: Gas error messages
@ 2005-09-14 11:06 Will Newton
  2005-09-14 13:59 ` Dave Brolley
  0 siblings, 1 reply; 6+ messages in thread
From: Will Newton @ 2005-09-14 11:06 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: cgen

 
> > The function is actually called "parse_byte_offset6" and is 
> definitely 
> > called. [...]
> 
> Then the question is why is the cgen_parse_keyword function 
> also called for your instruction.  You may need to put a 
> breakpoint on TARGET_cgen_parse_operand and work through it.  
> Chances are something is wrong with your .opc/.cpu file, but 
> without seeing relevant excerpts of those and a test case, I 
> can't be much more specific.

The assembler I am writing supports a number of addressing modes,
expressed like:

GET    D0.0,[D0.1+D0.2] ; D0.0 <- mem[base(D0.1)+offset(D0.2)]
GET    D0.0,[D0.1+#20]  ; D0.0 <- mem[base(D0.1)+offset(20)]

I have specified these a separate instrucions, e.g.:

(dni ...
    "GET $DataReg1,[$DataReg2+$DataReg3]"
    ...
)
(dni ...
    "GET $DataReg1,[$DataReg2+#$Immed]"
    ...
)

The immediate form is parsed by my custom parser, which returns it's
error message. However, it seems that cgen goes on to attempt to parse
the immediate as a register name, which fails with "unrecognized
keyword". Is there a way to control this behaviour? Once I have hit the
hash I would like to treat the value as always an immediate.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Gas error messages
  2005-09-14 11:06 Gas error messages Will Newton
@ 2005-09-14 13:59 ` Dave Brolley
  0 siblings, 0 replies; 6+ messages in thread
From: Dave Brolley @ 2005-09-14 13:59 UTC (permalink / raw)
  To: Will Newton; +Cc: Frank Ch. Eigler, cgen

Will Newton wrote:

> 
>  
>
>The assembler I am writing supports a number of addressing modes,
>expressed like:
>
>GET    D0.0,[D0.1+D0.2] ; D0.0 <- mem[base(D0.1)+offset(D0.2)]
>GET    D0.0,[D0.1+#20]  ; D0.0 <- mem[base(D0.1)+offset(20)]
>
>I have specified these a separate instrucions, e.g.:
>
>(dni ...
>    "GET $DataReg1,[$DataReg2+$DataReg3]"
>    ...
>)
>(dni ...
>    "GET $DataReg1,[$DataReg2+#$Immed]"
>    ...
>)
>
>The immediate form is parsed by my custom parser, which returns it's
>error message. However, it seems that cgen goes on to attempt to parse
>the immediate as a register name, which fails with "unrecognized
>keyword". Is there a way to control this behaviour? Once I have hit the
>hash I would like to treat the value as always an immediate.
>  
>
This will happen once you finish implementing your parse function and it 
indicates "success" by returning NULL. Right now your parse function 
stub is indicating an error, so CGEN correctly attempts other parsing 
possibilities.

Another thing to consider is that CGEN will attempt to parse the insn 
variants in the order in which they appear in the .cpu file 
(undocumented but relied on by several existing ports). You should be 
able to get the behaviour you want by defining the immediate form of the 
insn last.

I hope this helps,
Dave


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Gas error messages
  2005-09-13 16:09 Will Newton
@ 2005-09-13 16:17 ` Frank Ch. Eigler
  0 siblings, 0 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2005-09-13 16:17 UTC (permalink / raw)
  To: Will Newton; +Cc: cgen

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

Hi -

On Tue, Sep 13, 2005 at 05:08:55PM +0100, Will Newton wrote:
> [...]
> > Are you sure this function in the .opc file is being used?  
> > Parsers are normally named "parse_*" instead of "Parse_*".
> 
> Sorry, I have to use Outlook for my email. [...]

I am so very sorry.  :-)


> The function is actually called "parse_byte_offset6" and is definitely
> called. [...]

Then the question is why is the cgen_parse_keyword function also
called for your instruction.  You may need to put a breakpoint on
TARGET_cgen_parse_operand and work through it.  Chances are something
is wrong with your .opc/.cpu file, but without seeing relevant
excerpts of those and a test case, I can't be much more specific.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Gas error messages
@ 2005-09-13 16:09 Will Newton
  2005-09-13 16:17 ` Frank Ch. Eigler
  0 siblings, 1 reply; 6+ messages in thread
From: Will Newton @ 2005-09-13 16:09 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: cgen

 

> > I'm parsing an operand with a custom parser, e.g.:
> > [...]
> > And then in the .opc file:
> > Parse_my_parser(...)
> > [...]
> 
> Are you sure this function in the .opc file is being used?  
> Parsers are normally named "parse_*" instead of "Parse_*".

Sorry, I have to use Outlook for my email. It is most insistent that my
sentences begin with capital letters.
 :-)

The function is actually called "parse_byte_offset6" and is definitely
called.

> > However, when the error message is returned, instead of printing my 
> > error message, as expected, gas spits out:
> > test.s:28: Error: unrecognized keyword/register name [...]
> 
> It's hard to say definitively.  The error message could come 
> from a prior operand, or a different problem.  It may be 
> informative to inspect the opcodes/ generated files, put 
> debugger breakpoints or printf's into the code, and running 
> the test again.

I have added printfs and if I return anything other than NULL I get the
error above.
I'm using binutils 2.16.1 and cgen HEAD. I'll try with a newer binutils
and see if that changes anything.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Gas error messages
  2005-09-13 14:51 Will Newton
@ 2005-09-13 14:56 ` Frank Ch. Eigler
  0 siblings, 0 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2005-09-13 14:56 UTC (permalink / raw)
  To: Will Newton; +Cc: cgen

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

Hi -

On Tue, Sep 13, 2005 at 03:50:47PM +0100, Will Newton wrote:

> I'm parsing an operand with a custom parser, e.g.:
> [...]
> And then in the .opc file:
> Parse_my_parser(...)
> [...]

Are you sure this function in the .opc file is being used?  Parsers
are normally named "parse_*" instead of "Parse_*".


> However, when the error message is returned, instead of printing my
> error message, as expected, gas spits out:
> test.s:28: Error: unrecognized keyword/register name
> [...]

It's hard to say definitively.  The error message could come from a
prior operand, or a different problem.  It may be informative to
inspect the opcodes/ generated files, put debugger breakpoints or
printf's into the code, and running the test again.

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Gas error messages
@ 2005-09-13 14:51 Will Newton
  2005-09-13 14:56 ` Frank Ch. Eigler
  0 siblings, 1 reply; 6+ messages in thread
From: Will Newton @ 2005-09-13 14:51 UTC (permalink / raw)
  To: cgen


I'm parsing an operand with a custom parser, e.g.:

(define-operand
   ...
   ...
   (handlers (parse "my_parser"))
)

And then in the .opc file:

Parse_my_parser(...)
{
    if (error)
        return "an error occurred";
}

However, when the error message is returned, instead of printing my
error message, as expected, gas spits out:

test.s:28: Error: unrecognized keyword/register name

Am I doing something wrong or is this a bug?

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2005-09-14 13:59 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-09-14 11:06 Gas error messages Will Newton
2005-09-14 13:59 ` Dave Brolley
  -- strict thread matches above, loose matches on Subject: below --
2005-09-13 16:09 Will Newton
2005-09-13 16:17 ` Frank Ch. Eigler
2005-09-13 14:51 Will Newton
2005-09-13 14:56 ` Frank Ch. Eigler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).