Re: [Gems-users] mandatory queue recycle() and program order

[Dan Gibson <degibson@xxxxxxxx>]

1. Each processor may only have one access to each block outstanding. If a processor attempts to issue a second request, Ruby's isReady() function returns false. In your example below of LD-ST-LD, the ST's isReady() would return false, and the coherence hierarchy wouldn't see the ST until the first LD had been fully handled (and therefore, the L1 would be in S).
2. Processor models (i.e., Opal or Simics) are assumed to handle the memory consistency and ordering side of things.

Regards,
Dan

On Tue, Dec 8, 2009 at 2:27 PM, Byn Choi <bynchoi1@xxxxxxxxxxxx> wrote:

Hi,

I have a question regarding using recycle() on mandatory queues
(Processor -> L1). One thing that I noticed from many of the protocols
that ships with GEMS is that, in an L1 line is in a pending state, say
IS for MESI_SCMP_bankdirectory protocol, subsequent Load or Store
requests are recycled, i.e. MessageBuffer::recycle(). My question is,
how is the original program order maintained in such implementation?

Say there were multiple requests to the same line issued by the
(aggressive) processor: LD, ST, LD. The first LD will cause a
transition to IS state, and subsequent ST and LD will be recycled
until the reply for the GETS comes back. Once that comes back, let's
say we go to S state. At that point, as far as I can tell, there is no
mechanism that would ensure the partial ordering that exist between
the ST and the second LD. So, isn't it possible that the
implementation would process the second LD and then ST, which would be
a violation of the original program ordering?

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

-- 
http://www.cs.wisc.edu/~gibson [esc]:wq!