Re: [gem5-users] Macro Ops splitting and Register 33

2014-01-13 Thread Vanchinathan Venkataramani
Thanks Martin for your reply. Assume that we have an instruction the tries to modify float register f0. In decode stage, this f0 is modified as 0 + FP_Base_DepTag. If FP_Base_DepTag = 1344 say, f0 will be decoded as 1344. Now in rename stage this register index is first checked to know whether it

Re: [gem5-users] Macro Ops splitting and Register 33

2014-01-13 Thread Martin Brown
Mitch, he may be trying to get the correct register index, but is getting values like 33 and 1416 instead. Am I right V? I sort of tried to answer this in your other post http://www.mail-archive.com/gem5-users@gem5.org/msg09046.html. I got around it by calling BaseSimpleCPU::getFlatRegIdex(regIdx)

Re: [gem5-users] Macro Ops splitting and Register 33

2014-01-03 Thread Mitch Hayenga
In general control registers are not often renamed (regardless of ISA - ARM, x86, etc). If any instruction modifies the CPSR, it should be marked as "serializing". This ensures that any writes to the register will be properly seen by any younger instructions. It works by not letting any younger

Re: [gem5-users] Macro Ops splitting and Register 33

2014-01-02 Thread Vanchinathan Venkataramani
Thanks a lot for your reply. Similar to R33, R37-R39 and so on there is register with id 1416 which exists as a source for many instructions. I found that this instruction is the CPSR register. I tried looking at the rename and iew stages for a given instruction. It turns out that this register i

Re: [gem5-users] Macro Ops splitting and Register 33

2014-01-02 Thread Mitch Hayenga
R33 is a "zero register". It is used whenever a zero is required. It is also often sourced unnecessarily if an instruction requires fewer source registers. In gem5 the basis for splitting is solely up to whoever wrote the ISA decoder. For arm its mostly what you would expect 2 real sources (not