> 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.
>
> Nilay Vaish wrote:
> 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.
>
> Gabe Black wrote:
> I'm not following you. An add instruction will write to the condition
> code bits unless it's been told to partially write to the one bunch of
> condition code bits that are updated together. If that happens and the other
> add instruction is doing the same thing, the normal dependency tracking
> mechanisms will take care of it. This function is called needToRead, takes
> two sets of flags (which should be the same type for consistency btw, just
> noticed that) and returns a bool, hardcoded to true at the moment. needToRead
> what? How do the sets of flags help you figure that out? Why does it always
> return true?
The way we currently recognise the CC register needs to be read, is that
it appears on the RHS of some assignment statement. It seems to me that
this would remain true even after the register is split. The expression
will just change to something like
zaps = genZaps(zaps, <something>);
The isa parser would then mark zaps as both source and destination. And the
two add instructions would still not execute in parallel, as the second one
would be dependent on the first for the value of the zaps register.
We can either --
a. drop the default assumption that we need to make partial updates, and handle
partial update as a special case.
b. keep the default assumption that we need to make partial updates, and handle
full update as a special case.
Current patches are along the lines of the second option.
As far as needToRead() is concerned, the function is for deciding whether or not
the CC register should be read. It takes in the read and write sets of CC
bits that this microop is going read and write respectively. The types are
different
because the function check_condition() has a different encoding for CC bits
compared
to say genFlags(). It currently returns true because it has not been decided
yet what
the final condition would be, in part because of the difference in encodings.
The condition would be, I think, some thing like this --
if (read_set is not empty || write set is not full) return true;
return false;
- 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
