From mboxrd@z Thu Jan  1 00:00:00 1970
From: "J. Johnston" <jjohnstn@cygnus.com>
To: cgen@sources.redhat.com
Subject: Instruction Parsing
Date: Thu, 05 Apr 2001 15:18:00 -0000
Message-id: <3ACCEF19.5F89163B@cygnus.com>
X-SW-Source: 2001-q2/msg00006.html

I have recently run into some problems with a port whereby there are multiple instructions with the
same mnemonic, but different operands.  In particular, there is a fixed register in each version of
the instruction that is either the source or the destination.

For example, a load instruction of the two forms:

              load x,offset(gpr)
              load gpr,x

where x is fixed in both cases and the offset and gpr fields are parsed operands.

What happens is that the parser tries each in succession and so we end up getting the error message
from the last attempt, no matter how poorly a fit that is.

What I would like to propose is that the instruction parser uses regular expressions and verifies
when a match on the fixed portion of the instruction occurs.  If the fixed portion doesn't match, we
don't start parsing the operands in the instruction.  This will stop us from overwriting meaningful
parse messages.

For example, let's say gprs can be one of k or l and that the offset must be <1024.

         load x,1025(k)

will fail when the parse for offset occurs.  It sets the error message to be something appropriate:
"gpr offset too large - must be <1024"

Currently, we continue on and try to do the load gpr,x version.  The parser for gpr complains that:
"x is not a gpr".

If instead, we rule out the second case because load .*,x is not matched, then we avoid trashing the
first and more appropriate error message.

This could have other benefits in truly recognizing when parentheses are required as part of the
instruction format rather than being treated as expression delimiters. 

-- Jeff J.