> On April 21, 2012, 8:13 p.m., Gabe Black wrote: > > I don't understand what this patch is doing. It looks like you're adding > > members to keep track of flag bits and that sort of thing. If we didn't > > keep track of that before, we probably don't need to keep track of it now. > > Could you please explain what you're implementing here? > > Nilay Vaish wrote: > We did keep track of the bits before. But we need to keep track of the > bits that > need to read and that need to be written separately. To me it seems that > unless > we do that, we would never be able to execute two instructions in > parallel. Consider > the case when two add instructions are executed back to back. If both of > them are > writing to the CC register, then as of now they will read the register > first. This > would mean that the second add instruction is dependent on the first. To > break this > dependence, we need to figure out which bits written by the first > instruction are > read by the second. If there are none, then the two can go in parallel. > This requires > that the instructions specify their read and write bits separately. Based > on these bits > a runtime check that decide whether or not the CC register needs to be > read / written. > This patch introduces that run time check for the x86 ISA. > > Gabe Black wrote: > I understand why we want to get rid of the unnecessary read, I was asking > about what this patch is doing to help do that. > > Neither "cc" or "ext" are specific to reading or writing, and they > shouldn't be given special magical meaning like that. I suspect it's not > actually necessary to store them separately either.
I have given a thought about this, and I felt that we need the read and write sets to be separate. Otherwise it does not seems possible that we can at runtime decide whether or not a register needs to be read. As far as naming is concerned, I can change that something more descriptive. In one of the previous patches, I had allowed for introducing functions that decide (at runtime) whether or not a certain register can be read/written. This patch uses that functionality for the x86 ISA. It modifies isa description so that each instruction that would need to read/write the CC register specifies that read and the write flags. These two sets will be used for deciding whether or not the CC register should be read. > On April 21, 2012, 8:13 p.m., Gabe Black wrote: > > src/arch/x86/insts/microop.hh, line 125 > > <http://reviews.gem5.org/r/1160/diff/1/?file=26105#file26105line125> > > > > What are these functions for? > > Nilay Vaish wrote: > This functions are the run time checks that decide whether or not > the cc register needs to be read/written. > > Gabe Black wrote: > I thought there were going to be a bunch of cc registers. Ultimately, there will be. But splitting up the CC register will not solve the problem completely. Take the case of add instructions I outlined above. Even after splitting the CC register, these instructions cannot execute in parallel because they are still going to read those split registers, thus creating a Read-After-Write dependence. Therefore we need some functionality that prevents the registers from being read. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1160/#review2571 ----------------------------------------------------------- On April 21, 2012, 1:20 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1160/ > ----------------------------------------------------------- > > (Updated April 21, 2012, 1:20 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 8962:1c063dca6858 > --------------------------- > X86: Runtime read, write conditions for CCFlagBits register > This patch introduces runtime read, write conditions for CCFlagBits register. > The main idea is that each microop, while being used in the microcode, > should specify the condition code flags it would read and write. On the > basis of this info, at runtime, it would be decided which condition code > registers should be read and written. This would help in reducing the extent > of RAW dependence while using the o3 cpu with x86. Currently, the flags that > would read and written are specified together. Next couple of patches would > try to look in to splitting the flags in to read and write sets and split the > ccFlagBits register. > > > Diffs > ----- > > src/arch/x86/insts/micromediaop.hh 0bba1c59b4d1 > src/arch/x86/insts/microop.hh 0bba1c59b4d1 > src/arch/x86/insts/microregop.hh 0bba1c59b4d1 > src/arch/x86/isa/microops/debug.isa 0bba1c59b4d1 > src/arch/x86/isa/microops/mediaop.isa 0bba1c59b4d1 > src/arch/x86/isa/microops/regop.isa 0bba1c59b4d1 > src/arch/x86/isa/microops/seqop.isa 0bba1c59b4d1 > src/arch/x86/isa/microops/specop.isa 0bba1c59b4d1 > src/arch/x86/isa/operands.isa 0bba1c59b4d1 > > Diff: http://reviews.gem5.org/r/1160/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
