> 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. > > Brad Beckmann wrote: > 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.
You can safely get rid of any remaining libruby functions. - Derek ----------------------------------------------------------- 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
