I think the purpose of libruby was that back in the day GEMS/Ruby was able to be hooked up to several other drivers like Bochs, and libruby encapsulated the APIs to be able to talk to these other guys.
Caveat - this is what I recall hearing Brad say, I can't say for sure. But since I'm going through my mail and saw this hadn't been answered, I decided to throw a bone. Lisa On Tue, Jan 18, 2011 at 8:17 PM, Nilay <ni...@cs.wisc.edu> wrote: > Brad, > > What was the purpose of libruby? > Don't want to sound critical, but when I went through that code, I had the > feeling it could have been done in a better fashion. I had similar > thoughts about ruby/common/Address.hh, in particular about the fact that > it makes calls to RubySystem. Those functions that make calls to > RubySystem should, in my opinion, go in to Address.cc. Keeping them in > Address.hh creates unnecessary cyclical dependencies. > > I am thinking of introducing a new header file RubyRequest.hh (which will > contain the request class currently in libruby) in slicc_interface > directory and doing away with CacheMsg class in RubySlicc_Exports. But > currently I am inclined towards keeping the RequestTypes and AccessModes > in RubySlicc_Exports (don't want to change protocol files). > > The patch is almost ready, except that it is not working correctly right > now :) > > Nilay > > > On Tue, January 18, 2011 1:33 pm, Beckmann, Brad wrote: > > 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: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] > >> 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 > >> > m5-dev@m5sim.org > >> > http://m5sim.org/mailman/listinfo/m5-dev > >> > > > > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
