Sorry, I misspoke. It should be working for both of the simple CPUs
right now, but no other models.
Gabe
Dibakar Gope wrote:
> Hi Gabe,
>
> Thanks for your reply. So in order to make the predecode logic work for
> timing simple CPU-model, which source code tree I should look for other than
> fetch-decode code tree (src/cpu/o3)and build/X86_FS/arch/x86 code tree? And
> how this predecode logic behaves differently for atomic & timing cpu mode?
> Please let me know.
>
> Regards,
> Dibakar
>
>
>
> Hello. The x86 predecode logic is working on the atomic CPUs but no
> other CPU model right now. I've started to get it to work, but I'm going
> to have to set that aside for a while.
>
> Gabe
>
> dibakar gope wrote:
> > Hi All,
> >
> > I have few queries regarding the fetch & predecode logic
> > implementation for variable-length x86 instruction in M5.
> >
> > (1) The next few lines of code has been taken from
> > src/cpu/o3/fetch_impl.hh to illustrate the way fetch logic extracts
> > MachInst (8 bytes)from the cacheline and send it to the predecoder for
> > building a complete x86 instruction in terms of ExtMachInst object.
> >
> > src/cpu/o3/fetch_impl.hh:-
> > line 1120:- // Get the instruction from the array of the cache line.
> > inst = TheISA::gtoh(*reinterpret_cast<TheISA::MachInst *>
> > (&cacheData[tid][offset]));
> >
> > predecoder.setTC(cpu->thread[tid]->getTC());
> > predecoder.moreBytes(fetch_PC, fetch_PC, inst); //
> > here inst is an instantiation of fixed-length MachInst (8 bytes)
> >
> > ext_inst = predecoder.getExtMachInst();
> > staticInst = StaticInstPtr(ext_inst, fetch_PC);
> > if (staticInst->isMacroop())
> > line 1130:- macroop = staticInst;
> >
> > fetch_PC is the start of the cacheline.
> > predecoder.moreBytes function (src/arch/x86/predecoder.hh) gets 8
> > bytes of MachInst data, process it & Populates the fields in
> > ExtMachInst object.
> > predecoder.getExtMachInst (src/arch/x86/predecoder.hh) checks whether
> > the ExtMachInst have got all the bytes for an particular x86
> > instruction, otherwise this function will assert an error message.
> >
> > src/arch/x86/predecoder.hh:-
> > const ExtMachInst & getExtMachInst()
> > {
> > assert(emiIsReady);
> > emiIsReady = false;
> > return emi;
> > }
> >
> > So everytime an x86 instruction exceeds the given MachInst (8 bytes) &
> > extends to the next 8 bytes, then in that iteration, the
> > predecoder.getExtMachInst will always assert this error message &
> > return an incomplete ExtMachInst back to calling fetch logic, but
> > ideally it should not. So have anyone thought about that or is there
> > anything missing in populating the ExtMachInst object?
> >
> > (2) predecoder.moreBytes function in above line of code shown is
> > invoked with (fetch_PC, fetch_PC, inst) arguments, which will make the
> > local variable "offset" zero in the code shown below.
> > src/arch/x86/predecoder.hh:-
> >
> > line 189:- //Use this to give data to the predecoder. This should be
> > used
> > //when there is control flow.
> > void moreBytes(Addr pc, Addr fetchPC, MachInst data)
> > {
> > DPRINTF(Predecoder, "Getting more bytes.\n");
> > basePC = fetchPC;
> > offset = (fetchPC >= pc) ? 0 : pc - fetchPC;
> > fetchChunk = data;
> > outOfBytes = false;
> > process();
> > line 199:- }
> >
> >
> > This above local variable "offset" decides the starting byte in the
> > given MachInst (8 bytes) from where the predecoder logic start
> > considering a new x86 instruction. But since this above function in
> > invoked with (fetch_PC, fetch_PC, inst) arguments, so everytime the
> > offset variable will get a value of 0 irrespective of any correct
> > starting byte of an instruction. And in turn the predecoder logic will
> > consider a wrong byte as the start byte of an x86 instruction.
> >
> > So in short, has the logic for fetching an x86 variable length
> > instruction (using the fetch, predecode & its interface logic)
> > implemented entirely / or the implementation is still in progress? is
> > the x86 fetch-predecode logic up & running and completely verified or
> > something is still missing & need some fixes?
> >
> > Any kind of help will be highly appreciated.
> >
> > Thanks & Regards,
> > Dibakar Gope
> > Texas A&M university
> > _______________________________________________
> > m5-users mailing list
> > [email protected]
> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> >
>
> _______________________________________________
> m5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
>
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
