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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
