Because I want to simulate performance variations of different core sizes, I tried changing issue width, commit width, and some other parameters, but this does not work. The job is terminated.
# system under test can be any CPU (TestCPUClass, test_mem_mode, FutureClass) = Simulation.setCPUClass(options) TestCPUClass.clock = '2GHz' DriveCPUClass.clock = '2GHz' Above is the part of the original fs.py, I added below part: TestCPUClass.issueWidth = 16 TestCPUClass.fetchWidth = 16 TestCPUClass.decodeWidth = 16 TestCPUClass.renameWidth = 16 TestCPUClass.dispatchWidth = 16 TestCPUClass.wbWidth = 16 TestCPUClass.RASSize = 32 TestCPUClass.LQEntries = 64 TestCPUClass.SQEntries = 64 TestCPUClass.numIQEntries = 128 TestCPUClass.numROBEntries = 384 issueWidth, fetchWidth...are defined in src/cpu/o3/O3CPU.py. I am not sure what is wrong with it. Thanks, ________________________________________ From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]] Sent: Friday, April 27, 2012 2:22 PM To: [email protected] Subject: gem5-dev Digest, Vol 60, Issue 100 Send gem5-dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://m5sim.org/mailman/listinfo/gem5-dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of gem5-dev digest..." Today's Topics: 1. Re: Review Request: ISA Parser: Decide source register indices at runtime (Gabe Black) 2. Re: x86 spec06 patches from Vince Weaver (Gabe Black) 3. Re: Review Request: ISA Parser: Decide source register indices at runtime (Nilay Vaish) 4. Re: x86 spec06 patches from Vince Weaver (Steve Reinhardt) 5. Re: Review Request: ISA Parser: Decide source register indices at runtime (Gabe Black) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 Apr 2012 10:53:25 -0700 From: Gabe Black <[email protected]> To: [email protected] Subject: Re: [gem5-dev] Review Request: ISA Parser: Decide source register indices at runtime Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 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 ------------------------------ Message: 2 Date: Fri, 27 Apr 2012 10:55:41 -0700 From: Gabe Black <[email protected]> To: [email protected] Subject: Re: [gem5-dev] x86 spec06 patches from Vince Weaver Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 On 04/27/12 07:46, Steve Reinhardt wrote: > So we've had these patches outstanding for over a year, and now we've got > people on the gem5-users list swapping tips about which syscalls you have > to change to get spec06 to work (by changing "fatal" to "warn" in some > cases). We should really get those patches pushed. > > It seems like they're mostly OK. There are a few minor issues that would > be nice to clean up. Unfortunately no one "owns" these patches, so the > cleanup isn't happening. I'm not sure where Vince went, but clearly he's > doing other things. Lisa did the favor of posting them to reviewboard, but > I don't think she ever intended to take full responsibility, and even if > she did, she's still on maternity leave. > > Does anyone want to step up and make this happen? I think the overhead is > pretty low if you've already got the spec06 x86 binaries and infrastructure > around (which I don't). > > If not, at this point I'd rather see them go in than continue to not commit > them because of minor issues that no one is willing to fix. > > The easiest way I've found is just go to Lisa's page and look for the ones > with "Vince Weaver" in the title: > http://reviews.gem5.org/users/hsul/ > > Steve > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev If I recall, there were real problems with at least some of those patches. The last time we brought them up we acknowledged at least a problem with the ioctl patch(es) but I don't think they were ever addressed. Gabe ------------------------------ Message: 3 Date: Fri, 27 Apr 2012 13:01:05 -0500 (CDT) From: Nilay Vaish <[email protected]> To: gem5 Developer List <[email protected]> Subject: Re: [gem5-dev] Review Request: ISA Parser: Decide source register indices at runtime Message-ID: <[email protected]> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 ------------------------------ Message: 4 Date: Fri, 27 Apr 2012 11:12:30 -0700 From: Steve Reinhardt <[email protected]> To: gem5 Developer List <[email protected]> Subject: Re: [gem5-dev] x86 spec06 patches from Vince Weaver Message-ID: <CAHgMoh9=fmc49pe9i92qhdlmioutqe+x1wqsgxk930szqzf...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 27, 2012 at 10:55 AM, Gabe Black <[email protected]> wrote: > If I recall, there were real problems with at least some of those > patches. The last time we brought them up we acknowledged at least a > problem with the ioctl patch(es) but I don't think they were ever > addressed. > The problems have not been addressed, no. How significant they are is a matter of opinion. Ideally someone would step up and address them and we'd be done with it. I'm saying that if no one is going to do that, we should consider just committing them anyway, with comments indicating what needs to be fixed, rather than forcing users to work around their absence for years to come. Steve ------------------------------ Message: 5 Date: Fri, 27 Apr 2012 11:22:18 -0700 From: Gabe Black <[email protected]> To: [email protected] Subject: Re: [gem5-dev] Review Request: ISA Parser: Decide source register indices at runtime Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 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 End of gem5-dev Digest, Vol 60, Issue 100 ***************************************** _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
