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
