Hi, I guess O3 doesn't model every piece of real hardware behavior at all. In terms of squashing, squashed instruction doesn't release all resources, instead it (squashed one) retires from ROB when it comes to ROB head.
Code handling branch miss prediction spreads around multiple files, at least
iew_impl.hh, commit_impl.hh, fetch_impl.hh. Basically, iew signals commit
stage it detected branch mis-prediction, commit stage signals fetch stage with
correct PC, then fetch stage squashes all insts from wrong path and redirect
its PC to new one. Delay slot inst in MIPS ISA is treated specially.
----
' Huang He (Henry)
/-\\ CPU Design and Verification
/---\'\ Advanced Micro Devices, Inc
/-----\'`\ AMD Technology Development (Beijing) Co., Ltd.
/-------\'`,\ Beijing, China
/---------\' ,`7 O: +(86) 10 62801421 M: +(86) 18616862712
/-----------\' /
/-------------\/ [cid:image001.jpg@01CE0E9A.2B553540] Visit us at:
Facebook<https://www.facebook.com/AMD> | amd.com<http://www.amd.com/>
From: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] On
Behalf Of Jianghao
Sent: Tuesday, July 30, 2013 9:33 AM
To: gem5 users mailing list
Subject: Re: [gem5-users] O3 CPU Squash
Hi Xiangyang,
Thanks for your information.
"if this inst is squashed, meaning we need to get this inst out of pipeline.
And the method to get this inst out of pipeline is to set the flags"
This is something I'm a little confused. If we decide to squash an instruction,
why this instruction still need to go through pipelines, instead of directly
removing it and younger instructions from the same thread in ROB and some
related queues, and free resources.
Another related question is during branch mis-prediction, what steps the
simulator will go through to correct the execution? Which code I should take a
look about this?
In various CPU design, branch speculative execution can be handled in different
pipe stages, so I'm wondering how gem5 handle this in simulation.
Thanks again for your advice.
On 7/29/2013 5:50 PM, Xiangyang Guo wrote:
Hi, Jianghao,
I guess the main purpose of setCanCommit or setExecuted is to forward this
instruction to the next stage. Because if one inst is in the pipeline, we set
different flags to this inst( to indicate which stage this inst is), if this
inst is squashed, meaning we need to get this inst out of pipeline. And the
method to get this inst out of pipeline is to set the flags (CanCommit() or
Executed()), otherwise we will get deadlock. Of course, I may be wrong. Hope
other guys can give you more detailed explain.
Regards
Xiangyang
On Mon, Jul 29, 2013 at 2:38 PM, Jianghao Guo
<guojh...@gmail.com<mailto:guojh...@gmail.com>> wrote:
How is squash handled in gem5 o3 CPU? What's exactly done in squash?
>From codes under src/cpu/o3, there are squash functions defined in different
>pipeline resources, like iew, inst_queue, lsq etc. Does this mean each part
>can initialize squash?
In following code, when an instruction is squashed, why we still set it as
Executed and canCommited?
Thanks
DefaultIEW<Impl>::executeInsts()
// Check if the instruction is squashed; if so then skip it
if (inst->isSquashed()) {
inst->setExecuted();
inst->setCanCommit();
++iewExecSquashedInsts;
decrWb(inst->seqNum);
continue;
}
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
<<inline: image001.jpg>>
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
