Once the "_" vs "." change is tested by Ali and checked in, the next
step to get generic operand types working is to address a deficiency in
how is_src and is_dest is determined by the parser. Right now it uses
this regular expression to determine if something is a dest, and if it's
not being used as a dest it's a src. This is for a particular instance,
so one operand can be both if it's used more than once.

assignRE = re.compile(r'\s*=(?!=)', re.MULTILINE)

Basically what that does is it ensures that is described by this comment:
# if the token following the operand is an assignment, this is
# a destination (LHS), else it's a source (RHS)

That's worked quite well, especially considering how simple it is, and
I'd like to preserve both its accuracy and its simplicity. The problem,
however, is that the operand name won't necessarily be the last thing
before the equals if an operand is being used as a dest. As a simple
example, if I wanted to set the foo field of the Bar operand, it might
look like this:

Bar.foo = 42;

Here, I believe the regular expression above would determine that Bar
was a source because .foo appeared immediately after it.

There are two possible solutions I see for this so far. First, we could
make the regular expression ignore "."s and identifiers in addition to
whitespace on its way to the equals sign. Second, we could make it
ignore *everything* on its way to the equals sign, except a "," or a ";"
which would, roughly, denote the end of the expression.

Neither of these approaches seem like they'll be fool proof, so I was
wondering what you guys think? Can you think of any naturally occurring
bit of code that would make one or the other get the wrong answer? The
original wasn't fool proof either, but in practice it worked really
well. I'd like to go for the same thing, so it's ok for it to be wrong
sometimes. I just don't want there to be something common case where it
messes up.



Also, there's still the issue of how partial writes, like my example
actually, are handled as far as being a dest or a src or both. In the
example above, Bar is actually both a source and a destination because
the non-foo bits are set to their old values. That changes, though, if
those other bits are necessarily set later, or if Bar is one of the new
types of MiscReg Ali added that accumulate partial writes over time,
useful for fault bits in floating point. If the Bar.foo = 42 case makes
Bar a dest, maybe all we need to do is add "Bar = Bar" where it needs to
be both and leave the parser alone. This puts the burden on the ISA
description, although it may need to be there anyway, and it feels a
little hacky. I want to deal with this after the issue above, but I
wanted to mention it since it'll becoming up next probably.

Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to