People not working with the ISA parser can stop here.
I have my changes out for review which remove the special handling of
the twin data types which are used for twin loads and stores in SPARC,
and generally demote integers and floating point values to simply be
opaque types. That's not quite true, but it mostly is. The idea is
that other types, which are now just as special as integer and
floating point types, can be used for operands with no (or only a
little) special effort.
The next step in making that useful is to not use "." as a way to
attached a type override to operands. Before I mentioned using @, and
I have a patch that makes that change in the parser and in all the ISA
descs. It was less painful than you may assume.
Then after that, I want to start actually taking advantage of this new
capability in the places where BitUnion types and Twin types were
being used in awkward ways to pacify the parser. These might look like:
FOO foo = Foo;
foo.a = 1;
Foo = foo;
Here FOO is the BitUnion type, foo is a variable of that type, and Foo
is the recognized operand. This is more cumbersome than it seems it
should be in a perfect world.
I started implementing this, but it confuses the parser's detection of
sources and destinations, partially because of syntax and partially
because it becomes intrinsically more complicated. The parser assumes
any operand which is followed by an equal sign is a destination, and
otherwise it's a source. This works remarkably well most of the time,
but it can already be confused in certain circumstances.
I have a change that makes Twin type operands first class and which
allows getting at their values in place with no disambiguating
parenthesis. This works because the twin types are being used as
sources.
For other types, things get messier since in "Foo.a = 1", the thing
after Foo is actually .a, not =. Also, this only partially modifies
Foo, so really Foo may be a source and a destination from this line.
I don't think there's a good way to figure out whether operands are a
source and/or destination in a setup like this. In the past, I've
tried to come up with a scheme that would force gcc/C++ to figure it
out for us, but no matter how clever/depraved I allow my solutions to
be, they still don't work. It might be possible to use a fancy
compiler system like LLVM to build a new tool to do it, but that isn't
a near term solution (although I wouldn't rule it out entirely).
Another solution might be to explicitly list source and destination
operands like inline assembly blocks. This isn't as big a burden as it
might seem if instructions could be grouped into classes that all
shared the same or substantially similar set of operands. Then the
individual instructions could specify their differences instead of the
whole set of inputs/outputs. This relies on instruction definition
working differently than it does, but I've been independently hoping
to move it towards that sort of model at some point.
Any ideas how we can get this to work better? This is a big stumbling
block for this sort of set up, and this will lead to operand types
which can be automatically composited from component values instead of
having to have hacks that, for instance, retrofit/filter code blobs to
build double precision floating point values from single precision
ones behind the scenes, or to merge control and condition code bits
everywhere the whole control register is needed, etc. I expect that
last part to be important for x86 to get the control flags dependency
issues fixed in O3.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
