> On Jan. 31, 2012, 10:05 a.m., Ali Saidi wrote: > > > > Ali Saidi wrote: > Is there a simulated performance difference (modulo subtle changes)?
I have not really carried out any comparison, but I don't think there is. For x86 FS, it pretty much takes the same time with and without these patches. > On Jan. 31, 2012, 10:05 a.m., Ali Saidi wrote: > > src/cpu/o3/fetch_impl.hh, line 1192 > > <http://reviews.gem5.org/r/1007/diff/2/?file=21613#file21613line1192> > > > > What is this line doing? > > Ali Saidi wrote: > Is there a simulated performance difference (modulo subtle changes)? IIRC, there are three ways in which the fetch stage can generate the next instruction. It can use the micro code ROM, or the current macroop, or the available cache block. I think when the code was originally written, there was some assumption that in a given cycle only one of the three ways would be used. But it seems over time, this changed. What can happen now is that the fetch stage might start fetching from one of the three possible ways, but midway through the cycle, it might switch to some other way. One of my previously posted patches fixes the handling for micro code rom. Over here before the fetch stage decides to make use of the cache block, it should confirm that the PC lies with in the address range of the cache block under consideration. If not, then the fetch stage should stop fetching instructions and access the icache. > On Jan. 31, 2012, 10:05 a.m., Ali Saidi wrote: > > src/cpu/o3/rob_impl.hh, line 550 > > <http://reviews.gem5.org/r/1007/diff/2/?file=21615#file21615line550> > > > > How often is this called? Would it make more sense to have a pointer to > > the previous instruction in every instruction that what through this > > (potentially 100+ element) list? It seems that the only place where the squashed instruction is in fetch stage where the current macroop is derived from it. We might want to change iew and commit to just send the current macroop to the fetch stage. Currently iew forwards only the instruction number, so that has to be looked up in the ROB to figure out the instruction itself. Since iew and commit stages have the microops, they can get the pointer to the macroop as well. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1007/#review2019 ----------------------------------------------------------- On Jan. 28, 2012, 9 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1007/ > ----------------------------------------------------------- > > (Updated Jan. 28, 2012, 9 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 8731:10a06bd36839 > --------------------------- > O3 CPU: Provide the squashing instruction > This patch adds a function to the ROB that will get the squashing instruction > from the ROB's list of instructions. This squashing instruction is used for > figuring out the macroop from which the fetch stage should fetch the microops. > Further, a check has been added that if the instructions are to be fetched > from the cache maintained by the fetch stage, then the data in the cache > should > be valid and the PC of the thread being fetched from is same as the address of > the cache block. > > > Diffs > ----- > > src/cpu/o3/commit_impl.hh 9d7c1dc54954 > src/cpu/o3/fetch_impl.hh 9d7c1dc54954 > src/cpu/o3/rob.hh 9d7c1dc54954 > src/cpu/o3/rob_impl.hh 9d7c1dc54954 > > Diff: http://reviews.gem5.org/r/1007/diff/diff > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
