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
