Re: [Gems-users] Ruby-Opal interface

[Gilles Pokam <gpokam@xxxxxxxxxxx>]

Luke Yen wrote:

> > #ifndef FAKE_RUBY
> > #ifdef  DEBUG_RUBY
> >     if (requestType != X86_IFETCH) {
> >       DEBUG("[%d] rubycache:: access %s 0x%0llx\n", m_id,
> >                 memop_menomic(requestType), la_t lineaddr );
> >       print();
> >     }
> > #endif
> >
> >     // ruby may call opal api to change m_fastpath_hit's value
> >     (*ruby_api->makeRequest)( m_id, lineaddr, m_block_size,
> >                               requestType, vpc, priv );
> > #else
> >     // complete the request about 25% of the time
> >     if ( random() % 4 == 0 ) {
> >       complete( lineaddr );
> >     }
> > #endif
> >
> >     if ( m_fastpath_hit ) {
> >       // hit in fast path
> >       return HIT;
> >     }
> >
> > First, could someone explain to me what the FAKE_RUBY macro does ?
> > Now, assume this macro has not been defined anyway, meaning that the
> > makeRequest call gets executed. What I don't understand is the comment
> > just near the code saying that ruby may call opal api to change
> > m_fastpath_hit's value. Indeed, the m_fastpath_hit is tested just at the
> > end of the macro. I'v tried to look in Ruby's code where this variable
> > actually gets modified but I was not successful. Could you please
> > point me in Ruby's code where this variable gets modified ?
> >
> > Thanks.
> >    
>
>   FAKE_RUBY is used during the Opal tester, not during actual execution,
> so you shouldn't worry about that section of code.
>
>   Regarding the Opal/Ruby call sequence.  Notice the 3 lines preceding
> the makeRequest:
>
>  // if ruby does accept requests, try for a "fast path hit"
>    m_fastpath_request     = lineaddr;
>    m_fastpath_outstanding = true;
>    m_fastpath_hit         = false;
>
>  When makeRequest() is invoked, and fastpath hits are turned ON, what
> happens is that on fastpath hits the hitCallback() informing Opal that
> Ruby is done processing the request invokes complete() (also in
> rubycache.C).  Here the first couple of lines from that function are as
> follows:
>
> // check for fast path completion
>  if ( m_fastpath_outstanding && physical_address == m_fastpath_request )
> {
> #ifdef DEBUG_RUBY
>    DEBUG_OUT("[%d] rubycache:: fastpath complete 0x%0llx\n", m_id,
> physical_address);
> #endif
>    m_fastpath_hit = true;
>    return;
>  }
>
>   The m_fastpath_outstanding and m_fastpath_request are
> set by the 3 lines before makeREquest(), so on fastpath hits this
> condition should be true, thus setting the m_fastpath_hit flag.  Then
> complete() returns control to access(), to the lines following
> makeRequest.  There the m_fastpath_hit check should be true, allowing for
> fastpath hits to return from access() with HIT.
>
>   Luke
>
>
>  
Thanks for replying. Now I think I catch how it works. So, in case you 
have a miss in Ruby, the pseq set the value of m_fetch_status to 
PSEQ_FETCH_ICACHEMISS. Meanwhile, the request has been issued to the L1 
cache controller via the issueRequest function in Ruby, right ? At 
completion, either one of write/read Callback function is invoked, which 
in turn invokes the hitCallback and the Complete function in rubycache ? 
This is where the wakeup function of the pseq is invoked, changing the 
fetch status to ready, right ?

--
Gilles