Re: [Gems-users] Why should Opal issue speculative store to ruby?

[Luke Yen <lyen@xxxxxxxxxxx>]

  Also, regading memory requests on mis-predicted paths:

   Opal doesn't do anything to squash any outstanding requests in Ruby
that issued on mis-predicted paths.  This would complicate the Opal-Ruby
interface.

   A solution would be always issue prefetch
requests for any load/store prior to commit, and only issue the actual
demand request at commit time.  Then you could modify the protocol to
treat prefetches as lower priority than demand requests, or ignore them
altogether.

   Luke

On Tue, 21 Nov 2006, [utf-8] ���^P wrote:

> Thanks for your reply.
> This explanation, just as I expected, may be the only one that can justify Opal's behavior. But it doesn't meet the code quite well. Or at least the code is misleading. Remember, in method 'store_inst_t::continueExecution()', there is a branch that explicitly issues a pre-fetch to ruby when the value is not ready yet.
> And the README.memory_consistency file also gives wrong information:
> Quote:
>    2) Stores are executed out of program order.  Stores are not treated as a special type of instruction, and thus will execute when its operands are ready (both address and data to be stored).  Note this is not the same as a cache line write permission prefetch, which do occur for stores which have its address computed but the data to be stored is not ready yet.
> ________________________________________
> > From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx] On Behalf Of Dan Gibson
> > Sent: Monday, November 20, 2006 10:46 PM
> > To: Gems Users
> > Subject: Re: [Gems-users] Why should Opal issue speculative store to ruby?
> >
> > Since Ruby doesn't actually store values, you can think of the "issue" of the store as a permission prefetch. Ruby only tracks cache line metastate anyway (it doesn't need to track actual values in the cache). The store remains resident in the LSQ until commit-time. It is true that "issuing" the store changes the Ruby statistics-- but store prefetching isn't really pollution, merely a possible optimization from an out-of-order core, and it is consistent to use store prefetching, provided that the actual store value doesn't appear to other processors before commit-time.
> >
> > > Hi,
> > >          After reading the source code of Opal, I come to the point that it doesn’t pay any attention to store instructions in mis-predicted branch. It may have issued load/stores to Ruby when the pipeline has been flashed.
> > >     Yes, I understand that Opal was designed to be a very aggressive optimistic OOO processor. I find it ok to even issue stores out of order, and so is to   issue loads speculatively. But it’s unacceptable to me if the stores are speculatively issued to Ruby, which will pollute the statistics of Ruby and be impractical to real-world systems.
> > >      Can anybody prove me wrong or explain why it was designed like this?
> > >
> > > G.R.
>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>