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
