> On 2010-07-11 11:58:39, Korey Sewell wrote:
> > src/cpu/pred/bpred_unit_impl.hh, line 207
> > <http://reviews.m5sim.org/r/47/diff/1/?file=725#file725line207>
> >
> >     But isnt the depth of a stack limited by the size of the RAS anyway?
> >     
> >     Say we have 16 entries, then the call stack is limited by 16 no?
> >     
> >     I have 2 concerns here (and for surrounding RAS code):
> >     (1) If the RAS does overflow and we want to just keep overwriting, then 
> > are we always overwriting the to the right entry?
> >     
> >     (2) If there is no valid RAS entry (in the case of the call stack being 
> > greater than the RAS size), then the branch prediction needs to either 
> > return false or simply stall until resolution (similar to the BTB concern I 
> > had)

Hi Korey... this is the way RAS's typically work.  If your call stack is deeper 
than your RAS size, you obviously want to keep the most recent entries rather 
than the older ones, so you just let it wrap around an overwrite the oldest 
entries.  Once you pop off all the valid entries, you will get bad predictions 
from re-using the overwritten slots, but the conventional wisdom is that the 
penalty of doing that (both in terms of the frequency of it happening and the 
cost of each occurrence) is low enough that it's not worth trying to track when 
it happens.  The conventional wisdom may or may not be correct, but it is what 
it is...


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/47/#review78
-----------------------------------------------------------


On 2010-07-09 18:08:18, Timothy Jones wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/47/
> -----------------------------------------------------------
> 
> (Updated 2010-07-09 18:08:18)
> 
> 
> Review request for Default.
> 
> 
> Summary
> -------
> 
> BranchPred: Take the branch predictor out of O3CPU and make it a stand-alone
> SimObject.  This then allows the same branch predictor to be shared amongst
> several CPUs.
> 
> This patch is unfinished.  I would like to take the branch predictor out of
> the inorder CPU as well, but want comments on whether this is the best
> approach to take first.
> 
> 
> Diffs
> -----
> 
>   src/cpu/o3/O3CPU.py 249f174e6f37 
>   src/cpu/o3/SConscript 249f174e6f37 
>   src/cpu/o3/bpred_unit.hh 249f174e6f37 
>   src/cpu/o3/bpred_unit.cc 249f174e6f37 
>   src/cpu/o3/bpred_unit_impl.hh 249f174e6f37 
>   src/cpu/o3/cpu_builder.cc 249f174e6f37 
>   src/cpu/o3/cpu_policy.hh 249f174e6f37 
>   src/cpu/o3/fetch.hh 249f174e6f37 
>   src/cpu/o3/fetch_impl.hh 249f174e6f37 
>   src/cpu/pred/BaseBPredUnit.py PRE-CREATION 
>   src/cpu/pred/SConscript 249f174e6f37 
>   src/cpu/pred/base.hh PRE-CREATION 
>   src/cpu/pred/base.cc PRE-CREATION 
>   src/cpu/pred/bpred_unit.hh PRE-CREATION 
>   src/cpu/pred/bpred_unit.cc PRE-CREATION 
>   src/cpu/pred/bpred_unit_impl.hh PRE-CREATION 
>   src/cpu/pred/builder.cc PRE-CREATION 
> 
> Diff: http://reviews.m5sim.org/r/47/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Timothy
> 
>

_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to