Re: [Gems-users] gems-users@xxxxxxxxxxx;gems-announce@xxxxxxxxxxx


Date: Fri, 09 May 2008 18:17:51 +0800
From: "Liangliang Tong" <nutspea@xxxxxxxxxx>
Subject: Re: [Gems-users] gems-users@xxxxxxxxxxx;gems-announce@xxxxxxxxxxx
Dear Greg,
I have got it. No need for answer. Thanks.

In your mail:
>From: "Liangliang Tong" <nutspea@xxxxxxxxxx>
>Reply-To: Liangliang Tong <nutspea@xxxxxxxxxx>,
       Gems Users <gems-users@xxxxxxxxxxx>
>To: gems-users@xxxxxxxxxxx
>Subject: Re: [Gems-users] gems-users@xxxxxxxxxxx;gems-announce@xxxxxxxxxxx
>Date:Fri, 09 May 2008 10:00:44 +0800
>
>
> Thanks Greg.
> Another questions, which are marked by //??, thanks in advance.
> 
> // Check to see if it is in the OTHER L1
>           if (L1IcacheMemory.isTagPresent(in_msg.Address)) {
> // The block is in the wrong L1, put the request on the queue to the shared L2
>             trigger(Event:L1_Replacement, in_msg.Address);
>           }
>           if (L1DcacheMemory.isTagPresent(in_msg.Address)) { 
>             // The tag matches for the L1, so the L1 ask the L2 for it
>            //?? when the tag matches, why L1 need request the L2? Another typo?
> what does event "mandatory_request_type_to_event(in.msg.Type)" fetch? Sorry to
ask
> such a simple question, 'cause I can not locate where the
> "mandatory_request_type_to_event" function is.
> 
>             trigger(mandatory_request_type_to_event(in_msg.Type),
> in_msg.Address);
>           } else {
>             if (L1DcacheMemory.cacheAvail(in_msg.Address)) {
>    // L1 does't have the line, but we have space for it in the L1 let's see if
the
> L2 has it
> //?? Another same event for different cases. When cacheAvail, the L1 need to
> requese data from L2, doesn't it?
>               trigger(mandatory_request_type_to_event(in_msg.Type),
> in_msg.Address);
> 
>             } else { 
>               // No room in the L1, so we need to make room in the L1
>               trigger(Event:L1_Replacement,
> L1DcacheMemory.cacheProbe(in_msg.Address));
>  
> 
> 
> 
> 
> In your mail:
> >From: Greg Byrd <gbyrd@xxxxxxxx>
> >Reply-To: Gems Users <gems-users@xxxxxxxxxxx>
> >To: Gems Users <gems-users@xxxxxxxxxxx>
> >Subject: Re: [Gems-users] gems-users@xxxxxxxxxxx;gems-announce@xxxxxxxxxxx
> >Date:Thu, 08 May 2008 21:43:33 -0400
> >
> >Liangliang Tong wrote:
> > > Hello everyone, when I am verifying one of my idea using gems, there are
> several
> > > questions I fail to figure out:
> > > 
> > > 1) In the MESI_CMP_directory protocol, there is a status called "idle",
> whereas
> > > the traditional status is "invalidate", so I wonder is there any
differences
> > > between these two statuses? if different, how?
> > 
> > No difference.  It means what you think it means.
> > 
> > > 
> > > 2)  IS, desc="L1 idle, issued GETS, have not seen response yet";
> > >     IM, desc="L1 idle, issued GETX, have not seen response yet";
> > >     SM, desc="L1 idle, issued GETX, have not seen response yet";
> > >     IS_I, desc="L1 idle, issued GETS, saw Inv before data because directory
> > > doesn't block on GETS hit";
> > > 
> > >     M_I, desc="L1 replacing, waiting for ACK";
> > >     E_I, desc="L1 replacing, waiting for ACK";
> > > 
> > > I just can not understand the explainations in the " ", they are the same
for
> IM
> > > and SM, or M_I and E_I? could anyone explain these four transient statuses 
> to
> > > me?
> > 
> > For SM, this is a typo.  Should be "L1 shared, issued GETX, ..."
> > 
> > For M_I and E_I, the explanations are accurate.  In both cases, the line is 
> > replaced and the ACK has not been seen.  The only difference is the starting
> state.
> > 
> > ...Greg
> > _______________________________________________
> > 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.
> > 
> >
> 
> 
> _______________________________________________
> 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.
> 
>


[← Prev in Thread] Current Thread [Next in Thread→]