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

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.


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

I thought there were going to be a bunch of cc registers.


- 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

Reply via email to