Here's a new version that fixes the 80-columns and uses NDEBUG.
- Clint
instcount.patch
Description: Binary data
On Oct 29, 2008, at 6:33 PM, nathan binkert wrote:
This looks good. It would probably be nice to make the instcount stuff not happen at all when we're compiling m5.fast, so we should wrap all of the instcount stuff with "#ifndef NDEBUG". Also, I'm anal about style. You've introduced several lines that are now over 80 columns.If you don't want to generate a new patch, I can take care of all of this.NateOn Wed, Oct 29, 2008 at 2:45 PM, Clint Smullen <[EMAIL PROTECTED]> wrote:This does not attempt to address any particular issues with x86, but here is a simple revision of it. I've merely moved instcount to be a non- static member of the O3 and ozone CPU classes, declared near where snList was (which is also used by the dyninst stuff, which is why I placed it in the particular implementations rather than in cpu/base.hh). The values increment and decrement as before, but the 1500 limit is accredited per CPU, and the DPRINTF for dyninst also includes the name of the processor. It is possible that that is not sufficiently identifying for someone doing debugging, but I could not find anything more identifying which is generic to all CPUs.If this is the type of change you had in mind, it would be easy to then make the limit adjustable, though, since it is more of a debugging feature, the instcount declaration and code could be placed within DEBUG, as the seqnumlist stuff is. - Clint On Oct 29, 2008, at 4:12 PM, nathan binkert wrote:I'd say that someone working on that sort of extension would want to have that mechanism in place. If the error is made per CPU and the value were configurable, then we could provide a pretty reliable mechanism. Of course, I could be wrong too. NateOn Wed, Oct 29, 2008 at 12:57 PM, Korey Sewell <[EMAIL PROTECTED]> wrote:Honestly, it might be time to just comment out or delete that assertion.As I recall, that was used when testing the O3CPU for correctness andto make sure we didnt run out of memory allocating instructions and never deleting them.But now it might be more of a hindrance as people simulate with more CPUs. Doing it perCPU would be nice, but then what happens in x86 codewhen you have more microOps (?) or if someone adds some type of new extension to the front end of the CPU? I say just go ahead and comment that line out or maybe put a DEBUG, DPRINTF warning there ... ... But I could be wrong...On Wed, Oct 29, 2008 at 1:06 PM, nathan binkert <[EMAIL PROTECTED]> wrote:I think that you're probably right that this number is too low.Rather than just increasing this number, it would be nice if we could move the instcount variable into the cpu (the dyn inst has a pointer to the CPU) so we can get a PerCPU count. We could then set instcountbased on the ROB size or something like that. Any chance you'd be willing to try that out? NateOn Wed, Oct 29, 2008 at 8:49 AM, Clint Smullen <[EMAIL PROTECTED] >wrote:When using four stock O3CPUs, I hit the following assertion after running a long time: m5.fs.opt: build/ALPHA_FS/cpu/base_dyn_inst_impl.hh:178: void BaseDynInst<Impl>::initVars() [with Impl = O3CPUImpl]: Assertion `instcount <= 1500' failed.Given that instcount is a static shared by all processors, and the1500 is not scaled to account for the number of processors, is itpossible the value is just too low? I have attempted to tally up how many instructions could microarchitecturally been in flight, but I am not familiar enough with the precise organization of the O3CPU to say for sure whether or not four cores would clear this limit, though itappears that eight or more cores would easily hit this limit.Is there an issue in the O3 CPU that I am possibly running into, orcan I safely disable it? Thanks, - Clint Smullen _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users-- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
