Since its been working fine for me and Dibakar I think, I'll get it into a
state to be submitted (currently have ruby and classic changes in the same
patch). I'll split them into two patches and post them to reviewboard
today.
On Tue, Nov 20, 2012 at 9:20 AM, Ali Saidi wrote:
> **
>
> Any updat
Any updates Mitch?
Thanks,
Ali
On 11.10.2012 20:44, Mitch
Hayenga wrote:
> Hi,
>
> I have a patch that fixes this in classic
and ruby. I was waiting for another student (Dibakar, he runs a lot more
parallel code than I do) to test it out before submitting to the
reviewboard. I'll bug h
Hi,
I have a patch that fixes this in classic and ruby. I was waiting for
another student (Dibakar, he runs a lot more parallel code than I do) to
test it out before submitting to the reviewboard. I'll bug him and see if
he's tested it out yet.
On Thu, Oct 11, 2012 at 7:32 PM, Ali Saidi wrote:
Hi Mitch,
Did you end up getting it working?
Thanks,
Ali
On Sep 26, 2012, at 3:39 PM, Steve Reinhardt wrote:
> That's a reasonable hardware implementation. Actually you need a register
> per hardware thread context, not just per core.
>
> Our software implementation is intended to model suc
That's a reasonable hardware implementation. Actually you need a register
per hardware thread context, not just per core.
Our software implementation is intended to model such a hardware
implementation, but the actual software is different for a couple of
reasons. The main one is that we don't w
Hmm, I had normally thought that LL/SC were handled with special address
range registers @ the cache controller. Since a core should really only
have one outstanding LL/SC pair, a register per core would suffice and
exactly encode the range. Basically doing the same thing that your
more-fine grai
This is a pretty interesting issue. I'm not sure how it would be handled
in practice. Since the loads and stores in question are not to the same
address, in theory at least store set predictor should not be involved. My
guess is that the most straightforward fix would be to record the actual
ran
Thanks for the reply.
Thinking about this... I don't know too much about the O3 store-set
predictor, but it would seem that load-linked instructions should care
about the entire cache line, not just if the store happens to overlap.
Since, it looks like the pending stores write to the address rang
Hi Mitch,
I wonder if this happens in the steady state? With the
implementation the store-set predictor should predict that the store is
going to conflict the load and order them. Perhaps that isn't getting
trained correctly with LLSC ops. You really don't want to mark the ops
as serializing a
Background:
I have a non-o3, out of order CPU implemented on gem5. Since I don't have
a checker implemented yet, I tend to diff committed instructions vs o3.
Yesterday's patches caused a few of these diffs change because of
load-linked/store-conditional behavior (better prediction on data ops tha
10 matches
Mail list logo
