Nilay,

Are you trying to replace CacheMsg with RubyRequest?  I agree that we can 
probably get rid of one of them.  If I recall, right now RubyRequest is defined 
in libruby.hh.  Is the Ruby library interface still important to you all at 
Wisconsin?  If not, I would like to get rid of the libruby files.

Brad


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Nilay Vaish
> Sent: Tuesday, January 18, 2011 10:45 AM
> To: M5 Developer List
> Subject: Re: [m5-dev] Question on SLICC
> 
> Figured that out last night. I also noticed that there is comment about it in
> RubySlicc_Types.sm (should read files more carefully). Actually, I am trying 
> to
> get rid of CacheMsg class. Currently, RubyRequest is created from packet
> (which I believe is an m5 primitive) and then a CacheMsg is created from
> RubyRequest.
> 
> Thanks
> Nilay
> 
> 
> On Tue, 18 Jan 2011, nathan binkert wrote:
> 
> >> There are certain types defined in the file
> >> src/mem/protocol/RubySlicc_Types.sm. For each of the type is .hh is
> >> gets written which contains the path of the actual header file to be
> >> used. For example, the file RubySlicc_Types.sm defines CacheMemory
> >> type. This type is actually defined in the file
> >> src/mem/ruby/system/CacheMemory.hh. When a protocol is compiled,
> the
> >> file build/<protocol_name>/mem/protocol/CacheMemory.hh gets
> written.
> >> This file contains just one line - #include "<path to
> >> CacheMemory.hh>"
> >>
> >> My question is which script writes this file. I have looked around
> >> but have not been able to figure it out yet.
> >
> > That gets done in src/mem/ruby/SConscript.  The reason it gets done
> > there is because the .hh file is actually in the system directory, but
> > the way the slicc code is generated, it tries to include it from the
> > protocol directory.  In the original slicc/ruby, this didn't matter
> > because all directories were in the include search path, but in M5 we
> > need to know the path.  There was no easy way to fix this, so this
> > ugly band aid exists.  Be awesome to get rid of it.
> >
> >  Nate
> > _______________________________________________
> > m5-dev mailing list
> > [email protected]
> > http://m5sim.org/mailman/listinfo/m5-dev
> >

_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to