Quoting Nilay Vaish <[email protected]>:
On Tue, 24 Apr 2012, Gabe Black wrote:
On 04/23/12 14:32, Nilay Vaish wrote:
In the sparc isa, there are some instructions that will have problem
with proposed changes. To over come the problem, we can introduce
a mapping from
the original order of the operands (as discovered by the isa
parser) to the run time
order of the operands. This mapping is created with in the
constructor of the microop.
When executing the microop, the mapping will be used for reading
the operand.
It seems that this would take care of the issue, but changes would
have to be made to
the arm isa. In the isa files for arm, at times source and
destination register indices
are built with in the isa file, instead of letting the isa parser
generate that code.
So this mapping would also have to be done in the isa files.
- Nilay
We seem to whittled down my objections to a valid problem :-). One
possibility which would change how the ISAs are implemented currently
would be to have scalar members of the StaticInsts which implement the
instructions which would hold the indexes to use for the various
operands. These could be added programaticly like how the operands are
declared in the various functions automatically. This has several benefits.
Are you saying that each class defined in decoder.hh will have
members, where each member will be an index to some operand in the
src / dest array?
Each member would hold the register index directly, and the index
would also be in the src/dest array. The instruction would use the
member and the CPU would use the array.
First, it means the indexing problem is reduced because the indexes
don't come out of the array any more.
Second, it potentially makes it easier in, say, a disassembly function
to determine which register indexes are which so that the right thing
can be printed in the right position. This can be tricky when you can
have things like condition codes, implicit registers, etc., getting
mixed in with the more explicit sources and destinations.
Third, it leads into another idea where these operand index members are
actually objects which know how to read the right register bits for a
read and write the right bits for a write without having to build those
smarts into the parser. They could automatically populate the source and
dest index arrays for the benefit of the CPU, but they would be what
ultimately actually reads registers foo, bar, and baz and turns it into
a register. That would be useful for the composite operands like a
condition code register which is actually a bunch of smaller registers,
or, say, a double precision floating point value which needs to read two
singles to form a complete register.
There are costs associated with doing things this way too, namely that a
lot of code would have to be adjusted so it works this new way. It could
be done in stages, though, at least during development, where each ISA
could be converted individually. I think with the parser's help it could
be somewhat mechanical as well.
What do you think? Do you have another possible solution you'd like to
propose?
Gabe
I don't know enough about the ISA implementation to make any comment
about the impact of your proposed change. I just want to keep the
implementation as simple as possible.
That's reasonable. I think the basics of this proposal aren't too
complicated, although it affects a lot of existing code. The fancier,
more future looking parts wouldn't be necessary to get things working.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
