By the way, I guess the the code of "insert inst to ROB" is located in the
commit_impl.hh  doesn't mean this one inst is inserted into ROB at commit
stage. I think It means every cycle, there are insts inserted into ROB from
rename stage. I mean when pipeline works, every cycle, we check if there
are insts available to insert into ROB, if yes, then insert it. So I guess
Gem5 inserts the inst into ROB after renaming finish.

Someone who is familiar with this could correct me.


On Wed, Aug 14, 2013 at 1:45 AM, GE ZHIGUO <[email protected]> wrote:

>  Hi, Henry****
>
> ** **
>
> Thanks for your reply! ****
>
> Yes, so this is even more confusing to me. ****
>
> In real CPU, when(in which stage) the instructions are put into ROB?****
>
> ** **
>
> Regards****
>
> ** **
>
> Zhiguo****
>
> * *
>
> * *
>
> * *
>
> ** **
>
> ** **
>
> *From:* [email protected] [mailto:[email protected]] *On
> Behalf Of *Huang, Henry
> *Sent:* Wednesday, August 14, 2013 12:19 PM
>
> *To:* gem5 users mailing list
> *Subject:* Re: [gem5-users] About the rename and dispatch stages in O3CPU*
> ***
>
>  ** **
>
> I think code in commit_impl.hh inserts renamed insts into ROB.****
>
> ** **
>
> #0  ROB<O3CPUImpl>::insertInst (this=0x27d8100, inst=...) at
> build/ALPHA/cpu/o3/rob_impl.hh:206****
>
> #1  0x0000000000b44936 in DefaultCommit<O3CPUImpl>::getInsts
> (this=0x27d79a8) at build/ALPHA/cpu/o3/commit_impl.hh:1318****
>
> #2  0x0000000000b34084 in DefaultCommit<O3CPUImpl>::commit
> (this=0x27d79a8) at build/ALPHA/cpu/o3/commit_impl.hh:884****
>
> #3  0x0000000000b30d0e in DefaultCommit<O3CPUImpl>::tick (this=0x27d79a8)
> at build/ALPHA/cpu/o3/commit_impl.hh:669****
>
> #4  0x0000000000b533fd in FullO3CPU<O3CPUImpl>::tick (this=0x27d4ff0) at
> build/ALPHA/cpu/o3/cpu.cc:604****
>
> #5  0x0000000000b6538e in FullO3CPU<O3CPUImpl>::TickEvent::process
> (this=0x27d50f8) at build/ALPHA/cpu/o3/cpu.cc:138****
>
> #6  0x0000000000762542 in EventQueue::serviceOne (this=0x193d2b0) at
> build/ALPHA/sim/eventq.cc:204****
>
> ** **
>
> 1296 void****
>
> 1297 DefaultCommit<Impl>::getInsts()****
>
> 1298 {****
>
> 1299     DPRINTF(Commit, "Getting instructions from Rename stage.\n");****
>
> 1300 ****
>
> 1301     // Read any renamed instructions and place them into the ROB.****
>
> 1302     int insts_to_process = std::min((int)renameWidth,
> fromRename->size);****
>
> 1303 ****
>
> 1304     for (int inst_num = 0; inst_num < insts_to_process; ++inst_num) {
> ****
>
> 1305         DynInstPtr inst;****
>
> 1306 ****
>
> 1307         *inst = fromRename->insts[inst_num];*
>
> * *
>
> * *
>
> Thanks,****
>
> ** **
>
> ----****
>
>         '              *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****
>
>   /-----------\' /****
>
>  /-------------\/      [image: cid:[email protected]]  Visit
> us at: Facebook <https://www.facebook.com/AMD> | amd.com<http://www.amd.com/>
> ****
>
> ** **
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of GE ZHIGUO
> Sent: Wednesday, August 14, 2013 11:59 AM
> To: gem5 users mailing list
> Subject: [gem5-users] About the rename and dispatch stages in O3CPU****
>
> ** **
>
> Hi, ****
>
> ** **
>
> I have a question about O3CPU pipeline in GEM5.****
>
> My understanding about the GEM5 O3CPU is that rename stage does not put
> instructions into instruction queue(issue queue) and ROB. Dispatch stage
> actually does the above. So, rename + dispatch in GEM5 is actually the
> rename stage of O3CPU. Please correct me if I am wrong. ****
>
> As the dispatch stage pushes the instructions into ROB and instruction
> Queue, I think that the free entries of ROB and instruction queue should be
> checked at this stage. However, the rename stage in gem5 check the free ROB
> and instruction queue size.****
>
> I cannot understand this. Can anyone help explain? ****
>
> ** **
>
> Thanks!****
>
> ** **
>
> Zhiguo****
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> gem5-users mailing list****
>
> [email protected]****
>
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users****
>
> ** **
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to