better handling of unknown operands

better handling of unknown operands

[Ben Elliston]

I observed some undesirable behavior in cgen this morning.  Before I
set out to fix it, I'd like to discuss possible solutions.  When
defining the assembly syntax string for an instruction, I typo'd the
following:

	" .. $(rs) .."
rather than:
	" .. ($rs) .."

It looks like the parser encountered the `$', advanced to the `(' and
stopped.  In the generated code, I see a reference to OP () which is
wrong.

More generally, shouldn't cgen complain about any operand that appears
in the syntax string but not the field format list, or vice-versa?

Ben

Re: better handling of unknown operands

[Ben Elliston]

>>>>> "Ben" == Ben Elliston <bje@redhat.com> writes:

  Ben> More generally, shouldn't cgen complain about any operand that appears
  Ben> in the syntax string but not the field format list, or
  Ben> vice-versa?

I haven't heard any comments on this, but it would be a nice thing to
have.  I've left it as a TODO for now.

Ben

Re: better handling of unknown operands

[Frank Ch. Eigler]

Hi -

:   Ben> More generally, shouldn't cgen complain about any operand that appears
:   Ben> in the syntax string but not the field format list, or
:   Ben> vice-versa?
: 
: I haven't heard any comments on this [...]

It's not quite like that -- keep in mind ifields that embody padding or
reserved bits, and need no mentino in the syntax string.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6uKaFVZbdDOm/ZT0RAtP2AJ0b8WRTSLm0nuW36vYQAKGP9CN3RwCffuhp
Xp1Px4IPd1yTVkreTDbOZYs=
=Nq44
-----END PGP SIGNATURE-----

Re: better handling of unknown operands

[Ben Elliston]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

  Frank> :   Ben> More generally, shouldn't cgen complain about any operand that appears
  Frank> :   Ben> in the syntax string but not the field format list, or
  Frank> :   Ben> vice-versa?

  Frank> : I haven't heard any comments on this [...]

  Frank> It's not quite like that -- keep in mind ifields that embody padding or
  Frank> reserved bits, and need no mentino in the syntax string.

But you're referring to ifields.  I'm talking about *operands*:

    "beq $rm, @$rn"
    (+ (f-fixed 16) rm rn (f-subop 10) (f-0 0))

Both `rm' and `rn' (and only `rm',`rn') should appear in both places.
Right?

Ben

Re: better handling of unknown operands

[Frank Ch. Eigler]

Hi -

bje wrote:
: [...]
:     "beq $rm, @$rn"
:     (+ (f-fixed 16) rm rn (f-subop 10) (f-0 0))
: Both `rm' and `rn' (and only `rm',`rn') should appear in both places.
: Right?

Sounds ... right ... for the usual cases.  I can imagine operands
invented for parsing purposes only, and operands for semantic
processing only, and let them cover the same ifields.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6uSS/VZbdDOm/ZT0RApkqAJ9UExRcPYLJKLOvCFK6W2B2WO2MRQCfVPCh
5xA95Q2cj98gC8ecKwFHkqc=
=fHql
-----END PGP SIGNATURE-----

Re: better handling of unknown operands

[Ben Elliston]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

  Frank> Sounds ... right ... for the usual cases.  I can imagine operands
  Frank> invented for parsing purposes only, and operands for semantic
  Frank> processing only, and let them cover the same ifields.

OK.  Let's leave this one for now, then.

Ben

Re: better handling of unknown operands

[Doug Evans]

Frank Ch. Eigler writes:
 > I can imagine operands
 > invented for parsing purposes only, and operands for semantic
 > processing only, and let them cover the same ifields.

I can too.

Re: better handling of unknown operands

[Ben Elliston]

>>>>> "Doug" == Doug Evans <dje@transmeta.com> writes:

  >> I can imagine operands invented for parsing purposes only, and
  >> operands for semantic processing only, and let them cover the
  >> same ifields.

  Doug> I can too.

OK, I see now.

re: better handling of unknown operands

[matthew green]

   
   bje wrote:
   : [...]
   :     "beq $rm, @$rn"
   :     (+ (f-fixed 16) rm rn (f-subop 10) (f-0 0))
   : Both `rm' and `rn' (and only `rm',`rn') should appear in both places.
   : Right?
   
   Sounds ... right ... for the usual cases.  I can imagine operands
   invented for parsing purposes only, and operands for semantic
   processing only, and let them cover the same ifields.

can't forgot about those SEM-ONLY operands, but we do know that they
exist.  i believe ben is onto a good diagnostic here, and we should
try to make it work.  cgen's diagnostics are one of it's worst areas.
if you change the assertion to be:

	every format op is either:
		- SEM-ONLY, or
		- has a matching syntax op, and
	every syntax op has matching format op.


is there a case that this doesn't work with?  i looked at the current
cgen input files and none of them appear to use the former currently,
but it definately should be supported.  i can't think of a case for
operands used for parsing purposes that don't have format ifields, but
if there were, you could extend this with a (new? same?) attribute to
indicate it was such.


.mrg.

re: better handling of unknown operands

[Ben Elliston]

>>>>> "matthew" == matthew green <mrg@cygnus.com> writes:

  matthew> can't forget about those SEM-ONLY operands, but we do know that they
  matthew> exist.  i believe ben is onto a good diagnostic here, and we should
  matthew> try to make it work.  cgen's diagnostics are one of it's worst areas.
  matthew> if you change the assertion to be:

  matthew> 	every format op is either:
  matthew> 		- SEM-ONLY, or
  matthew> 		- has a matching syntax op, and
  matthew> 	every syntax op has matching format op.

  matthew> is there a case that this doesn't work with?  i looked at the current
  matthew> cgen input files and none of them appear to use the former currently,
  matthew> but it definately should be supported.  i can't think of a case for
  matthew> operands used for parsing purposes that don't have format ifields, but
  matthew> if there were, you could extend this with a (new? same?) attribute to
  matthew> indicate it was such.

Anyone?  Anyone?

Ben

re: better handling of unknown operands

[Doug Evans]

Ben Elliston writes:
 >   matthew> if you change the assertion to be:
 > 
 >   matthew> 	every format op is either:
 >   matthew> 		- SEM-ONLY, or
 >   matthew> 		- has a matching syntax op, and
 >   matthew> 	every syntax op has matching format op.
 > 
 >   matthew> is there a case that this doesn't work with?  i looked at the current
 >   matthew> cgen input files and none of them appear to use the former currently,
 >   matthew> but it definately should be supported.  i can't think of a case for
 >   matthew> operands used for parsing purposes that don't have format ifields, but
 >   matthew> if there were, you could extend this with a (new? same?) attribute to
 >   matthew> indicate it was such.
 > 
 > Anyone?  Anyone?

I don't quite understand the question.

re: better handling of unknown operands

[Ben Elliston]

>>>>> "Doug" == Doug Evans <dje@transmeta.com> writes:

  matthew> every format op is either:
  matthew> - SEM-ONLY, or
  matthew> - has a matching syntax op, and
  matthew> every syntax op has matching format op.

  matthew> is there a case that this doesn't work with?  i looked at the current
  matthew> cgen input files and none of them appear to use the former currently,
  matthew> but it definately should be supported.  i can't think of a case for
  matthew> operands used for parsing purposes that don't have format ifields, but
  matthew> if there were, you could extend this with a (new? same?) attribute to
  matthew> indicate it was such.

  >> Anyone?  Anyone?

  Doug> I don't quite understand the question.

We're talking about improving the parsing of syntax strings and format
fields and validating their contents.  In this way, you'll be warned
if the operands appearing in the syntax string don't match what is
expected in the format field.  And we're just trying to discover all
of the corner cases before doing so.

Ben