This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
re: better handling of unknown operands
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- subject: re: better handling of unknown operands
- From: matthew green <mrg at cygnus dot com>
- Date: Thu, 22 Mar 2001 14:30:04 +1100
- Cc: cgen at sources dot redhat dot com, Ben Elliston <bje at redhat dot com>
- organisation: Red Hat, Inc.
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.