Seems like a good idea to me. Ali
On Jul 17, 2013, at 11:04 AM, Joel Hestness <[email protected]> wrote: > Hi guys, > It looks as though the O3 CPU load-store queue automatically instantiates > 4 (MaxThreads) LSQUnits during the header of it's constructor. This > appears to be problematic when trying to use statistics that need to be > initialized in the LSQUnit, because these stats cannot be initialized if > the number of SMT threads being used is fewer than MaxThreads. The stats > initialization check in src/base/statistics.cc:~220 will fail on these > uninitialized LSQUnit stats. > > It seems to me that as long as the number of SMT threads specified by the > user in config scripts is not greater than MaxThreads, these LSQUnits > should be instantiated dynamically by the LSQ in it's constructor, so that > there aren't unused objects floating around in the simulation. This would > fix the stats initialization bug I'm running into. Is there any reason why > the LSQUnits aren't being dynamically instantiated (e.g. dynamically > changing SMT width during runtime)? > > Thanks, > Joel > > > -- > Joel Hestness > PhD Student, Computer Architecture > Dept. of Computer Science, University of Wisconsin - Madison > http://pages.cs.wisc.edu/~hestness/ > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
