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 > >>>> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > >>>> http://m5sim.org/mailman/listinfo/m5-dev > >>>> > >>>> > >>> _______________________________________________ > >>> m5-dev mailing list > >>> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > >>> http://m5sim.org/mailman/listinfo/m5-dev > >>> > >>> > >>> > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > http://m5sim.org/mailman/listinfo/m5-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
