Along these lines, I've wanted to distinguish between macroops/regular instructions executed and microops executed. When in SE, if you change the microcode implementing an instruction (admittedly that pretty much only affects me), it's impossible to tell if the number of committed instructions changed because of the length of the microops, or if different instructions were executed. With the two separated, if the number of microops changes but the number of macroops/regular instructions stays the same, that's a good indication that (probably) nothing broke.
Gabe Quoting Korey Sewell <[email protected]>: > Hi all, I'm interested in getting this cleaned up but some minor > details need to be hashed out. > > The first thing I would ask is there are a lot of places where there > is a Counter value and a Stat value holding the same value. > Apparently, you can't access the value of a stat so another variable > needs to be kept for book-keeping. It would be really nice if the stat > and counter could be merged. For instance, in simple cpu there is a > "numInst" (Counter) and a "numInsts" stat that get updated at the same > point. > > Secondly, > Steve mentioned: >> sim_insts is the total across all cores, so we do need a per-core total. > The sim_insts is configured through the "totalInstructions" function > in BaseCPU. > > In SimpleCPU, that function is just " return numInst - startNumInst;". > The startNumInst counter seems to be used to reset Stats, but its > usefulness got counted out by changeset 3125 (yr.2006) so I dont think > it's useful anymore. So I want to delete the use of startNumInst. > > Third, > the naming scheme across CPU models for committed instructions should > be consistent but first some ambiguity needs to be cleared up. > > All CPUs have: > sim_insts ... # Number of instructions simulated > > SimpleCPU refers to: > num_inst ... # Number of instructions executed > > O3CPU refers to: > system.cpu.commit.COM:count 6403 # > Number of instructions committed > system.cpu.commit.commitCommittedInsts 6403 # The number > of committed instructions > system.cpu.committedInsts 6386 > # Number of Instructions Simulated > system.cpu.committedInsts_total 6386 # > Number of Instructions Simulated > > The ambiguity is in the meaning of "simulated", "executed", and > "committed". In O3, executed and committed would mean different things > obviously. > > So should we use "num_inst" across cpu models to mean instructions > committed or "committedInsts"? > > > > Fourth, >> Why is there an "SMT side of things?" I don't think we need two sets of >> stats (one for SMT and one not), we just need per-thread stats and a >> per-core total. So I can see having two committed inst counts for >> system.cpu (one that's clearly labeled as thread 0's and one that's the core >> total), but not four. > > For SMT, we can have a "num_inst" for per core and then I guess a > "num_inst_thread_x" for the per thread counts. > >> I would really love it if O3 could use the same names as SimpleCPU for the >> stats that correspond. I also don't like the all-caps bits like "COM:"... >> those are from waaay back in SimpleScalar days, and they're totally >> redundant wrt the "cpu.commit." prefix. Renaming stats is a pretty big >> change that could break people's analysis scripts so it's not something we >> want to do lightly, but if we're going to rename them at all, I'd say we >> should try and go all the way to where we really want to be in one shot. > There are also a bunch of those prefixes in O3 for RENAME and > Writeback and etc. > > On some level, I can understand in the IEW stage as there are multiple > "stages" within 1 stage to track. Using all-caps is probably a bit > annoying but for the IEW stage at least the prefixes are unnecessarily > redundant. > > Once we can come to an agreement on these, i can come up with a patch > that changes the O3 stats for everyone to review... > -- > - Korey > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
