Does x86 have a zero register? Also note that if we're trusting the ISA to not issue writes to the zero register, we don't absolutely have to check every write, we just need a central check that will catch it eventually so that we can go debug the problem. We could also put an assert in writeReg().
It seems to me that the "sentry value" is just using remapping to standardize the index of the zero register (as opposed to using TheISA::ZeroRegister), but doesn't get rid of needing an explicit check against that index, where trusting the ISA not to issue writes to it (in a trust-but-verify sort of way) avoids having to do any explicit checks at all (outside the assert, i.e., not in fast mode). Steve On Mon, Aug 25, 2008 at 2:00 PM, <[EMAIL PROTECTED]> wrote: > Originally I had thought about splitting up reads and writes for exactly > this > sort of scenario. The reads would read from registers that were always > ready > since they were never written to, and the writes would harmlessly go to > some > other register to be ignored. The problem was that even though those writes > were being ignored, they were still using up (a) physical register(s). The > sentry index solves that problem by being a flag to the CPU or anything > else > that the register is basically /dev/null and shouldn't get any resources. > > I also seriously considered making leaving the zero register alone an on > your > honor sort of requirement and putting in an assert, but there are just too > many > different places you could write to the zero register to special case them > all. > In a lot of cases in x86 at least you can't blindly replace the instruction > with a nop because, for instance, the control flags need to be updated. > > Gabe > > Quoting Steve Reinhardt <[EMAIL PROTECTED]>: > > > What about dependencies? One thing we need to avoid is having an > > instruction that reads from the zero register being dependent on an > > instruction that writes the zero register. If we hide too much semantics > > inside the reg file itself then we might lose that. > > > > I guess I'm still a little confused about why we can't just initialize > the > > zero register to zero and then make sure it doesn't get overwritten, > e.g.: > > > > assert(!(TheISA::HasZeroRegister && regs[TheISA::ZeroRegister] != 0)); > > > > Steve > > > > On Mon, Aug 25, 2008 at 1:07 PM, Kevin Lim <[EMAIL PROTECTED]> wrote: > > > > > 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 > > > >> >>>> 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
