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
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)
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
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
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