At least for Alpha ALU ops, all the ones with a dest reg of r31 should get decoded to "nop". The original code for zeroing out the "zero register" was inherited from SimpleScalar (believe it or not), which did not handle r31 destinations specially and thus needed to reset the reg to zero before every instruction for correctness.
I don't know if there's anything different about float regs or other ISAs, but one way to test it would be to just put an assertion in rather than an assignment. I think just having TheISA::ZeroRegister as the index of the zero register (probably with another bool TheISA::HasZeroRegister, and another pair for FloatZeroRegister) is fine... I don't see a big win in embedding this into the register flattening stuff. Of course, this is all from (stale) memory, so if there's some consideration I'm missing just let me know. Steve On Sun, Aug 24, 2008 at 7:53 PM, Gabe Black <[EMAIL PROTECTED]> wrote: > Yes, but I don't know if it'd be a good idea. If you specialize the > instruction itself, then you end up with bunches of variations of the > instructions which bloats the decode function, slows down compile time, > and kills our decode cache and the host I cache. If you override the > register index right in the instruction as it's being built I think > that'd work, but we've already got a more flexible mechanism to do that > later. > > Gabe > > nathan binkert wrote: > > Actually, you could also handle this in the decode of the instruction, > > right? i.e. generate a different static instruction type if this is > > going on. > > > > Nate > > > > On Sun, Aug 24, 2008 at 7:47 PM, nathan binkert <[EMAIL PROTECTED]> > wrote: > > > >> This seems like a laudable goal and a reasonable plan, my main > >> question is, how much does the register flattening cost, and are you > >> going to make anything we already do more expensive? Register access > >> is certainly on the critical path. > >> > >> Nate > >> > >> On Sun, Aug 24, 2008 at 7:35 PM, Gabe Black <[EMAIL PROTECTED]> > wrote: > >> > >>> I went and thought some more, and I think a better solution would be to > >>> rely on the register flattening stuff put in place for SPARC. If > there's > >>> a constant register like a zero register (or a pi register, or a 1 > >>> register, or...), then that register is initialized to that value. To > >>> preserve it, writes and reads are flattened differently and the writes > >>> go off into oblivion. To support that, we could add a sentry register > >>> index, like for instance -1 of whatever type is used to index > registers, > >>> and then every CPU model and/or register file could know it doesn't > have > >>> to worry about anything going to that register. I think this captures > >>> all of the capabilities of the current system, except that you don't > >>> have to worry about the semantics of magical indices and arbitrary > >>> constant values in the CPU. > >>> > >>> Gabe > >>> > >>> Gabe Black wrote: > >>> > >>>> I'm working on eliminating as many occurances of THE_ISA == X as > is > >>>> reasonable, and one place it comes up is figuring out whether or not > to > >>>> zero the floating point zero register. I think we discussed this > before, > >>>> but would it make more sense for the register file to maintain that > >>>> semantic by always returning 0 or ignoring writes to the zero > register? > >>>> We couldn't do that directly since o3 doesn't use the ISA defined > >>>> register files, but we could for the simple CPUs. > >>>> > >>>> Gabe > >>>> _______________________________________________ > >>>> m5-dev mailing list > >>>> [email protected] > >>>> http://m5sim.org/mailman/listinfo/m5-dev > >>>> > >>>> > >>> _______________________________________________ > >>> m5-dev mailing list > >>> [email protected] > >>> http://m5sim.org/mailman/listinfo/m5-dev > >>> > >>> > >>> > > _______________________________________________ > > m5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
