On 04/27/12 11:01, Nilay Vaish wrote: > On Fri, 27 Apr 2012, Gabe Black wrote: > >> On 04/27/12 07:02, Nilay Vaish wrote: >>> On Wed, 25 Apr 2012, Nilay Vaish wrote: >>> >>>> On Wed, 25 Apr 2012, Gabriel Michael Black wrote: >>>> >>>>> Quoting Steve Reinhardt <[email protected]>: >>>>> >>>>>> On Wed, Apr 25, 2012 at 11:00 AM, Gabriel Michael Black < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Quoting Nilay Vaish <[email protected]>: >>>>>>> >>>>>>>> Two things that I want to say in response -- >>>>>>>> >>>>>>>> a. With respect to memory usage, it would go down if we do what >>>>>>>> Gabe >>>>>>>> suggested in his review i.e. introduce members for each of the >>>>>>>> registers >>>>>>>> instead of using an array. This would also remove the >>>>>>>> indirection. I'll get >>>>>>>> performance numbers from some of the regression tests to carry >>>>>>>> out a >>>>>>>> performance comparison. >>>>>>>> >>>>>>>> b. The aim for these set of patches is remove the RAW >>>>>>>> dependence on >>>>>>>> condition code register in x86. Current approach is to figure out >>>>>>>> at run >>>>>>>> time whether or not the CC register needs to be read. We require >>>>>>>> this >>>>>>>> dynamic map to correctly read the registers. In ARM ISA >>>>>>>> description, some >>>>>>>> thing similar has been done. At runtime, if a certain condition >>>>>>>> is true, >>>>>>>> the CC register is reda, otherwise register 0 is read. IIRC, no >>>>>>>> instruction >>>>>>>> can write to reg 0 in a RISC isa. Hence, there is no RAW >>>>>>>> dependence. Can we >>>>>>>> do this in x86 as well? May be a register that is only visible to >>>>>>>> the >>>>>>>> microcode. >>>>>>>> >>>>>>> >>>>>> I agree, at a high level, that keeping the existing _srcRegIdx[] >>>>>> array and >>>>>> just dealing with the fact that it may have gaps in it seems like an >>>>>> alternative that's at least worth exploring. >>>>>> >>>>>> We could also have a special register index like -1 that just means >>>>>> invalid >>>>>> so that we don't rely on piggybacking on some potentially >>>>>> ISA-specific >>>>>> characteristics to make it work. >>>>> >>>>> That's essentially what the index constant ZeroReg does currently. >>>>> >>>>>> >>>>>> >>>>>>> The special handling of the zero register is actually somewhat >>>>>>> annoying. >>>>>>> The CPU has to check for it and treat it specially, and, last I >>>>>>> recall, the >>>>>>> way it holds its zero value is to be rewritten with zero over and >>>>>>> over and >>>>>>> over to squash any errant updates. I would like to get rid of this >>>>>>> mechanism if possible, so my gut reaction is not to build more on >>>>>>> top of >>>>>>> it. That said, the zero register behavior isn't going away so it >>>>>>> has to >>>>>>> keep working somehow anyway. That may be a viable way to avoid >>>>>>> adding >>>>>>> storage to the StaticInst classes. >>>>>> >>>>>> >>>>>> With Alpha, the decoder generates a no-op for any instruction whose >>>>>> destination is the zero register, regardless of the opcode. In >>>>>> theory, >>>>>> this should make rewriting the zero value every cycle unnecessary. >>>>>> I don't >>>>>> know if some cases were missed, or if it's still needed for other >>>>>> ISAs, but >>>>>> that's the direction I'd want to go to get rid of that aspect. We >>>>>> could >>>>>> always just replace the overwrite with an assertion and see how far >>>>>> we get. >>>>>> >>>>>> On the input side, it would seem that instructions that read the >>>>>> zero >>>>>> register could be decoded into StaticInsts that act as if it were an >>>>>> immediate zero operand. >>>>>> >>>>>> So I'd think it's at least theoretically possible to make the >>>>>> current >>>>>> zero-register implementation go away. >>>>>> >>>>>> Also, PowerPC has funky semantics in which the zero register >>>>>> actually holds >>>>>> a value, and whether you get that value or 0 depends on the >>>>>> opcode. I'm >>>>>> not sure how that's implemented in gem5, but we can't assume that >>>>>> the >>>>>> zero-register behavior is universal. >>>>>> >>>>>> Steve >>>>>> _______________________________________________ >>>>>> gem5-dev mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>>> >>>>> >>>>> That's not necessarily feasible because you'd end up with lots of >>>>> variations of everything where one or more sources and/or one or >>>>> more destinations are replaced in some way. It's also not desirable >>>>> to turn them into nops because you may still want side effects like >>>>> setting condition codes. This is how at least the cmp instruction is >>>>> implemented as microcode in x86. >>>>> >>>>> A long time ago I proposed using our index flattening mechanism to >>>>> flatten dests that had magical zero properties to a dead register, >>>>> and I think that would still make sense. There would be a little bit >>>>> of overhead because sources will still read from a zero register and >>>>> dests will still write to a /dev/null register, but renaming sorts >>>>> of operations would be minimal. >>>>> >>>>> Gabe >>>> >>>> >>>> Seems like the main discussion is getting side tracked. So do people >>>> think that we should do this? The zeroth micro int register is >>>> defined to be the ZeroReg. Does that mean if the operand is ZeroReg, >>>> it would map to 0? Also, where are these micro int registers being >>>> used? There aren't many places where INTREG_MICRO() is in use. >>>> >>>> -- >>>> Nilay >>>> >>> >>> I went through some of the code. It seems that the 't*' registers used >>> in the microcode would map to the MicroInt registers. I think it is >>> possible to do a zero register. We can introduce a new register that >>> does the job. Or else we can reuse one of the micro int registers. >>> t13/t14 are not in use at all. So they can be used. But we will have >>> to maintain a discipline of not using these any where else. >>> >>> -- >>> Nilay >>> _______________________________________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/gem5-dev >> >> Don't use t13 or t14. t0 is already defined as the zero register. >> >> Gabe > > > But t0 is use in lots of places. Are you fine with changing those to > t13/t14? > > -- > Nilay > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev
No. t0 is already the zero register, and yes it's used in a lot of places. Nothing about the registers needs to change. Every ISA in gem5 has a zero register already because Alpha has one (which is somewhat unfortunate), and its index is specified with the ZeroReg constant. Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
