Quoting Steve Reinhardt <ste...@gmail.com>:
On Sun, Aug 15, 2010 at 6:07 PM, Min Kyu Jeong <mkje...@gmail.com> wrote:
I needed to spit out a code that reads from a register, and writes to it
again. The thing is arch reg indices are renamed (reg renaming and shadow
reg file), so many structures are needed to be looked up to find a
previous/current physical register for the given arch reg name. These
indirections are handled in ISA-specific code and encapsulated, and the
operand section of the ISA description specifies which one to use.
I think we're thinking of these things on different levels... the
operand registers are available via StaticInst::srcRegIdx() and
destRegIdx(), and can be accessed via (for example) readIntReg() in
o3/thread_context_impl.hh, none of which are ISA dependent. I don't
see why you can't build on these calls to handle this entirely within
the O3 model in an ISA-independent fashion (i.e., a way that would
generalize to any ISA with universal predication, if we ever run into
another one).
Steve
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
I was actually thinking this could be handled at a level higher than
the parser, namely in the ISA description.
If the predicate is false, then the instruction still needs to forward
the value from the physical source register to the physical
destination register so future consumers get the right thing. For
renaming to work, it's necessary for all those registers to be listed
as both sources and destinations. By putting a fall through condition
in the instruction as defined by the ISA description that just assigns
registers to themselves (DestReg = DestReg; SrcReg1 = SrcReg1) both of
those conditions are satisfied automatically without the CPUs having
to get any smarter/complex/constrained and without retrofitting the
ISA parser.
This will mean having to change a lot of instruction templates so that
they have the fall through case and so that the definitions know what
registers to assign to themselves. That's going to be tedious, but
hopefully fairly mechanical to do.
If the ISA parser were a python framework instead of a parser, then
it's conceivable this sort of thing could be handled automatically and
cleanly by subclassing, replacing default function implementations,
etc. etc., and kept local to ARM. That would give the benefits you
might have been going for by changing the parser (the parser does the
work, fewer bugs...) , but without impacting the complexity seen by
all the other ISAs. That's not going to happen tomorrow or possibly
ever so I hestitated to mention it and don't make any plans around it,
but it's something I would really like to see happen.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
