Hi, Korey, Thanks for reply. About your suggestion " 1) Why do anything to rename? Instead, why dont you change the number of physical registers to equal the number of architectural/logical registers?" , I think we did the same thing. If I understand right, the default prev_reg is set to architectural regs when the rename_map initialized. And then prev_reg's value changed during the simulation. So I just make the renamed_reg=prev_reg. Please correct me if I'm wrong. Thanks
Regards Xiangyang On Mon, Jul 15, 2013 at 12:09 PM, Korey Sewell <[email protected]> wrote: > Suggestions: > 1) Why do anything to rename? Instead, why dont you change the number of > physical registers to equal the number of architectural/logical registers? > > 2) To debug, run the same benchmark with the SimpleCPU and compare the > committed instructions to your run. You should be able to figure out where > you simulation breaks (i.e. last committed instruction) and also track down > which instruction should be providing data to the instruction stuck in the > ROB. > > > On Sat, Jul 13, 2013 at 8:13 PM, Xiangyang Guo <[email protected]> wrote: > >> Hi, Gem5-users, >> >> I need to use in order CPU for ARM ISA, so I need to modify O3 to InOrder. >> >> I disable the rename part by keeping the renamed reg same as prev reg, >> also change all the widths to 1 to keep in order issue and exe. In term of >> WAW and WAR, I just add a flag to each reg, if one inst is in the pipeline, >> I mark the flag of its regs to 1. And if one inst wants to insert to the >> InstQueue, first check the dest reg's flag, if the flag is 1 meaning there >> is WAW/WAR, should block(tid), I bind this checking with isfull() together >> because I think they are doing the similar thing, which decides whether >> inserting this inst or not. >> >> But then I get the error : >> Exiting @ tick 9223372036854775807 because simulate() limit reached >> >> It seems that I get a deadlock, And I also get the trace and find that >> the one inst stays in the ROB and cannot be ready for a long time. >> >> So could you give me some suggestion about this? Any hint is appreciable. >> >> Thanks >> >> Xiangyang >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > - Korey > > _______________________________________________ > 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
