It sounds like a fairly good idea to me to have the zero register handled as part of the register flattening. It sounds like it'll help abstract a lot of the ISA parts of the CPU, which makes it sound worthwhile to include.
Kevin Quoting Gabe Black <[EMAIL PROTECTED]>: > It actually simplifies things a bit which I think is probably a win. I'm > most of the way through implementing it right now. This way, the ISA is > the only thing responsible for ISA level semantics which I'd say is also > a win. I like the idea of having fewer parts, namely a single constant > instead of several and fewer special cases in the CPU, and that you can > have an arbitrary number of special registers that behave in arbitrary ways. > > Gabe > > Steve Reinhardt wrote: >> 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] >> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> >> >>>> http://m5sim.org/mailman/listinfo/m5-dev >> >>>> >> >>>> >> >>> _______________________________________________ >> >>> m5-dev mailing list >> >>> [email protected] <mailto:[email protected]> >> >>> http://m5sim.org/mailman/listinfo/m5-dev >> >>> >> >>> >> >>> >> > _______________________________________________ >> > m5-dev mailing list >> > [email protected] <mailto:[email protected]> >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] <mailto:[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
