An instruction that sets the CWP is serializing because our CPU models don't speculatively update it's value to present to later instructions. That means that until the CWP is updated later in the pipeline, instructions later in the program but which have started executing will be using the wrong register window. You could add a mechanism that updated CWP speculatively, although that probably won't be very easy. Coincidentally, I'm working on a chance to how PCs are handled, and for the small, fairly unrealistic benchmarks I have working for SPARC the IPC changes significantly due, I think, to significantly better branch predictor performance. The implementation in place now is functionally correct, but I think it gets tripped up relatively often by SPARC's branch delay slots, delay slot annulling, etc. This change will hopefully be in the repository relatively soon, but it's big enough that it'll take a while to finish and test adequately. I may also find that the big gains aren't there for more realistic workloads.
Gabe john wrote: > My mistake, it looks like the CWP is set as serializing... > Thus, no way to increase IPC on a sparc? > > On Thu, Aug 26, 2010 at 2:48 AM, john <[email protected] > <mailto:[email protected]>> wrote: > > Hello, > > I have been simulating the MiBench suite using SPARC and noticed a > very strange behaviour (changeset used 7514:b28e7286990c). Even in > the default configuration of m5 (which is 8-wide) I couldn't get > proper IPC rates. > > e.g. running mibench/automotive/basicmath_small for ~1/3 of the > total instructions: > .. > System.switch_cpus.ipc_total 0.336181 > # IPC: Total IPC of All Threads > .. > System.switch_cpus.committedInsts_total 50000001 > # Number of Instructions Simulated > .. > System.switch_cpus.numCycles 148729557 > # number of cpu cycles simulated > .. > System.switch_cpus.rename.RENAME:serializeStallCycles 59054076 > # count of cycles rename stalled for > serializing inst > System.switch_cpus.rename.RENAME:serializingInsts 6605490 > # count of serializing insts renamed > > Now this means that 40% of the cycles are due to serializing > instructions. Some more inspection (if I'm correct) shows that > decoder.isa declares only tcci, tccx as serialized instructions. > Single stepping in gdb shows that the "save" instruction / > mnemonic is serialized. Indeed, in the generated > build/SPARC_SE/arch/sparc/decoder.cc file (line ~7527): > inline Save::Save(ExtMachInst machInst) > : IntOp("save", machInst, IntAluOp) > { > > .... > flags[IsInteger] = true; > flags[IsNonSpeculative] = true; > flags[IsSerializeAfter] = true; > flags[IsSerializing] = true;; > } > > The question is, is "save" supposed to be serialized? If so, I > must find another reason why my IPC rates are so low, otherwise > this looks like a bug on the generation of the decoder.cc file. > > Thanks in advance, > John > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
