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 is INT, FP or Miscellaneous. For finding this they use FP_Base_DepTag. After finding this, the flattened index is found. Later they try to get the physical index corresponding to this flattened index. This physical index is used for reading the register value for example in the readFloatReg function in cpu.cc I hope this understanding is correct. It is important to note that 1416 is the decoded index for CPSR register and 33 is the decoded index for Zero register. Thanks Vanchinathan V On Tue, Jan 14, 2014 at 6:40 AM, Martin Brown <mbr...@cs.fsu.edu> wrote: > 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). I think I did > that because I saw it being done elsewhere, as I was trying to get the > logical register index. > > Can anyone verify that this is the right way? > > > On Fri, Jan 3, 2014 at 8:15 AM, Mitch Hayenga < > mitch.hayenga+g...@gmail.com> wrote: > >> 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 instructions enter the processor back-end until the CPSR write >> completes. These control registers tend to be mostly read-only, so >> tolerating a pipeline stall on writes is not unreasonable. >> >> So, it likely is being used, it's just not renamed. >> >> >> On Fri, Jan 3, 2014 at 1:41 AM, Vanchinathan Venkataramani < >> dcsv...@gmail.com> wrote: >> >>> 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 is being accessed in rename stage but not in >>> iew stage. Does this mean that the CPSR is not required for these >>> instructions? >>> >>> Thanks >>> V Vanchinathan >>> >>> >>> On Thu, Jan 2, 2014 at 10:03 PM, Mitch Hayenga < >>> mitch.hayenga+g...@gmail.com> wrote: >>> >>>> 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 >>>> counting flags that can add more. R37-39 or so are the flags). >>>> >>>> In the past I tried to find a way to compile without predication too. >>>> Never found a way. >>>> >>>> Hope this helps. >>>> >>>> Sent from my phone. >>>> On Jan 2, 2014 7:38 AM, "Vanchinathan Venkataramani" <dcsv...@gmail.com> >>>> wrote: >>>> >>>>> Hi all >>>>> >>>>> I tried to print the list of source registers in a given assembly >>>>> instruction during the decode stage for ARM ISA. It turns out that many >>>>> instructions have Register 33 as one of the source registers. I would like >>>>> to know what this Register 33 signifies. >>>>> >>>>> Also I would like to know on what basis a macroop is split into >>>>> microops since they introduce a lot of temporary registers. >>>>> >>>>> Is there a way to disable predication in ARM ISA while compiling? >>>>> >>>>> Thanks >>>>> V Vanchinathan >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> gem5-users@gem5.org >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > Martin > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
