> 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. > > Nilay Vaish wrote: > 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.
If it's a microop that reads, then they're interpreted as reads. If it's a microop that writes, they're interpreted as writes with the necessary reads thrown in automatically. Any required reads would be added in because we know ahead of time they need to be without having to store them in the instruction object explicitly. - Gabe ----------------------------------------------------------- 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
