Hi, Korey Thanks a lot! Yes, I am using two seqNum now. The O3CPU decodes macroop into microops at fetch stage and all macroops and microops use the same variable for seqNum. This is easier but seems not the same as real CPUs. The microops consume fetch bandwidth instead of decode bandwidth which might cause performance error.
Another question is that whether only those instructions whose destination register is pc are IsIndirectControl instructions. The instructions like mov pc, ldr pc, cause troubles. I want to identify such type of instructions. Whether it works by calling method isIndirectCtrl() in base_dyn_inst.hh? From: koreylsew...@gmail.com [mailto:koreylsew...@gmail.com] On Behalf Of Korey Sewell Sent: Thursday, September 12, 2013 2:23 PM To: GE ZHIGUO Cc: gem5 users mailing list Subject: Re: [gem5-users] ARM InOrder implement [inline] 1. For InorderCPU, as the instruction seqNum is assigned during fetch while microcode is created at decode stage, so this is a problem. Why not like O3CPU, create microcode at fetch stage, then seqNum will not be a problem, am I right? The InOrder model needs to create the initial seqNums in Fetch because it's a generic fetch stage that allows the user to customize what happens in fetch. Without having sequence numbers in fetch, how else would the pipeline stage know which "future" instruction need to be fetched branch predicted, passed on to the next stage, etc.? I'd suggest running the hello world binary with the inorder model and running for only 10 instructions with the InOrderCPUAll trace flag. If you do that, you'll have a clearer idea of how fetch uses the initial sequence numbers to get the pipeline running. With regard to microcode, the way that it's intended to work is have a macro-instruction number (number generated by fetch) and then have micro-instruction numbers that correspond to the macro numbers. Thus, each instruction would be in a "macroSeqNum.microSeqNum" abstract format and you can identify microcode within macro instructions that way. To do this, you'd need to add the microSeqNum in yourself and then in the squash code in the branch predictor (and other resource objects), you'd need to account for this numbering scheme. 2. If I am not wrong, Inorder CPU does not support predicate which is used by ARM. there is a patch about this http://reviews.m5sim.org/r/1013/diff/#index_header . May I know whether this patch has solved the predicate issue? if not how to enable it? This patch was simply to enable ARM-inorder to be compile in a previous version of gem5. I'm not sure it's relevant to predicate instructions. With regards to predicate instructions, there's no reason that the model would not support it as it's run things like delay slots in MIPS or reg. windows for a basic SPARC workload. The squash mechanism in InOrder is modeled after how O3 did this so the basic support should be there. To be sure, you'll have to run a workload with predicate instructions of interest and verify the code path does the right thing. - Korey
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
