This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


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

re: better handling of unknown operands


   
   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.


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