> On 2011-01-20 15:49:13, Brad Beckmann wrote: > > I've only had a chance to briefly review this, but I do have a couple > > comments: - The hammer cache changes didn't seem to upload cleanly. Can you try to post them again? - I just want to confirm that the libruby interface is still useful to you all at Wisconsin, correct? I just want to make sure I understand why the libruby files exist after your change. Is it possible to eliminate at least a few of these functions? For example the libruby_init() function that takes a configuration file name as an argument? > > Nilay Vaish wrote: > Brad, > > The purpose of the patch is not to do away with libruby. I don't know what > the purpose of libruby was. That's is why I have not ventured in to > removing > it.
The original purpose of the libruby files was to add an interface for Derek's ROCKS/BOCHS simulator. Ever since we changed configuration methodologies from the ruby language methodology to the python/SimObject methodology, I'm pretty sure this interface has been broken. We didn't delete it at the time because I thought there might be some effort to update the interface to the new configuration methodology. However, it has been a year and I suspect that we may never update it. Could you check with Derek what his plans are? We can debate whether removing libruby all together needs to be part of this patch or not. However, if there are no plans for libruby in the future, this patch effectively removes any usefulness of those files. - Brad ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/#review791 ----------------------------------------------------------- On 2011-01-21 05:19:07, Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/327/ > ----------------------------------------------------------- > > (Updated 2011-01-21 05:19:07) > > > Review request for Default. > > > Summary > ------- > > The goal of the patch is to do away with the CacheMsg class currently in use > in coherence protocols. In place of CacheMsg, the RubyRequest class will > used. This class is already present in libruby.hh. In fact, objects of class > CacheMsg are generated by copying values from a RubyRequest object. > > This is not complete as of yet. I am facing some difficulty in handling the > RefCountingPtr. To me it seems that I am creating the reference correctly. > So, the object gets deleted before all the references have gone out of scope. > > > Diffs > ----- > > src/cpu/testers/rubytest/RubyTester.hh 494b5426e70d > src/mem/protocol/MOESI_hammer-cache.sm 494b5426e70d > src/mem/protocol/RubySlicc_Exports.sm 494b5426e70d > src/mem/protocol/RubySlicc_Profiler.sm 494b5426e70d > src/mem/protocol/RubySlicc_Types.sm 494b5426e70d > src/mem/ruby/SConscript 494b5426e70d > src/mem/ruby/common/Address.hh 494b5426e70d > src/mem/ruby/common/Address.cc 494b5426e70d > src/mem/ruby/common/DataBlock.hh 494b5426e70d > src/mem/ruby/common/DataBlock.cc 494b5426e70d > src/mem/ruby/filters/BlockBloomFilter.cc 494b5426e70d > src/mem/ruby/filters/BulkBloomFilter.cc 494b5426e70d > src/mem/ruby/filters/LSB_CountingBloomFilter.cc 494b5426e70d > src/mem/ruby/filters/MultiGrainBloomFilter.cc 494b5426e70d > src/mem/ruby/filters/NonCountingBloomFilter.cc 494b5426e70d > src/mem/ruby/libruby.hh 494b5426e70d > src/mem/ruby/libruby.cc 494b5426e70d > src/mem/ruby/libruby_internal.hh 494b5426e70d > src/mem/ruby/profiler/AccessTraceForAddress.cc 494b5426e70d > src/mem/ruby/profiler/AddressProfiler.hh 494b5426e70d > src/mem/ruby/profiler/AddressProfiler.cc 494b5426e70d > src/mem/ruby/profiler/Profiler.hh 494b5426e70d > src/mem/ruby/profiler/Profiler.cc 494b5426e70d > src/mem/ruby/recorder/CacheRecorder.hh 494b5426e70d > src/mem/ruby/recorder/CacheRecorder.cc 494b5426e70d > src/mem/ruby/recorder/TraceRecord.hh 494b5426e70d > src/mem/ruby/recorder/TraceRecord.cc 494b5426e70d > src/mem/ruby/recorder/Tracer.hh 494b5426e70d > src/mem/ruby/recorder/Tracer.cc 494b5426e70d > src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION > src/mem/ruby/slicc_interface/RubyRequest.cc PRE-CREATION > src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh 494b5426e70d > src/mem/ruby/slicc_interface/RubySlicc_Util.hh 494b5426e70d > src/mem/ruby/slicc_interface/SConscript 494b5426e70d > src/mem/ruby/storebuffer/stb_interface.cc 494b5426e70d > src/mem/ruby/storebuffer/storebuffer.cc 494b5426e70d > src/mem/ruby/system/CacheMemory.hh 494b5426e70d > src/mem/ruby/system/CacheMemory.cc 494b5426e70d > src/mem/ruby/system/DMASequencer.hh 494b5426e70d > src/mem/ruby/system/DMASequencer.cc 494b5426e70d > src/mem/ruby/system/PerfectCacheMemory.hh 494b5426e70d > src/mem/ruby/system/RubyPort.hh 494b5426e70d > src/mem/ruby/system/RubyPort.cc 494b5426e70d > src/mem/ruby/system/Sequencer.hh 494b5426e70d > src/mem/ruby/system/Sequencer.cc 494b5426e70d > src/mem/ruby/system/SparseMemory.cc 494b5426e70d > src/mem/slicc/parser.py 494b5426e70d > > Diff: http://reviews.m5sim.org/r/327/diff > > > Testing > ------- > > > Thanks, > > Nilay > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
