Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
On Sat, 19 Mar 2011, Nilay Vaish wrote: On Fri, 18 Mar 2011, Lisa Hsu wrote: What's going on with this patch? I don't believe it's been committed but it seems like it should. I've also got some patches waiting behind this because they used to touch CacheMsg and I don't want to mess Nilay up, so I've been waiting to serialize behind this. Lisa Lisa, the original patch was pretty long and after some of the changes that Brad submitted, almost the whole of the patch required rework. I have already committed some parts of the original patch. I have posted two more patches on the review board that cover some more portion of the patch. You can ignore the original patch. Assume that I will not post more patches that touch CacheMsg or related structures apart from the two that I posted 5 minutes ago. -- Nilay Lisa, I have updated the patch. If you want, you can commit your patches before I commit this. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
What's going on with this patch? I don't believe it's been committed but it
seems like it should. I've also got some patches waiting behind this
because they used to touch CacheMsg and I don't want to mess Nilay up, so
I've been waiting to serialize behind this.
Lisa
On Wed, Feb 9, 2011 at 1:28 PM, Brad Beckmann brad.beckm...@amd.com wrote:
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/327/
Overall, this patch looks good to me as well. I just have a couple minor
questions. Though your comment says this patch removes libruby, the diff
seems to indicate that the file still remains. Am I reading that correctly?
Also it seems that in several places you unecessarily generate the line
address, even though the line address already exists in the ruby request (see
comments below).
src/mem/ruby/storebuffer/storebuffer.cchttp://reviews.m5sim.org/r/327/diff/6/?file=10042#file10042line183
(Diff
revision 6)
StoreBuffer::checkForLoadHit(RubyRequest request)
183
if ((req.paddr m_block_mask) != lineaddr)
183
if ((req.m_PhysicalAddress.getAddress() m_block_mask) != lineaddr)
Instead of masking the physical address, can we just use the m_LineAddress?
src/mem/ruby/storebuffer/storebuffer.cchttp://reviews.m5sim.org/r/327/diff/6/?file=10042#file10042line233
(Diff
revision 6)
StoreBuffer::returnMatchedData(RubyRequest request)
233
if ((it-m_request.paddr m_block_mask) == lineaddr) {
233
if ((it-m_request.m_PhysicalAddress.getAddress() m_block_mask) ==
lineaddr) {
Same here. Can we just use the m_LineAddress?
src/mem/ruby/storebuffer/storebuffer.cchttp://reviews.m5sim.org/r/327/diff/6/?file=10042#file10042line308
(Diff
revision 6)
StoreBuffer::complete(uint64_t id)
308
if ((from_buffer.m_request.paddr m_block_mask) == lineaddr
308
if ((from_buffer.m_request.m_PhysicalAddress.getAddress()
m_block_mask) == lineaddr
And here
src/mem/ruby/system/Sequencer.cchttp://reviews.m5sim.org/r/327/diff/6/?file=10051#file10051line232
(Diff
revision 6)
Sequencer::insertRequest(SequencerRequest* request)
230
line_addr.makeLineAddress();
231
Address line_addr(ruby_request-m_LineAddress);
Why is this line address conversion necessary? Isn't m_LineAddress already
set correctly in the constructor?
src/mem/ruby/system/Sequencer.cchttp://reviews.m5sim.org/r/327/diff/6/?file=10051#file10051line455
(Diff
revision 6)
Sequencer::hitCallback(SequencerRequest* srequest,
451
Address request_line_address(ruby_request.paddr);
453
Address request_line_address(ruby_request-m_PhysicalAddress);
Can you just use the m_LineAddress variable of ruby_request instead of
converting the paddr to a line address.
- Brad
On January 25th, 2011, 9:15 a.m., Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.
*Updated 2011-01-25 09:15:23*
Description
Remove CacheMsg class from SLICC
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.
The changes relating to removal of libruby have been moved to separate patch.
Diffs
- src/cpu/testers/rubytest/RubyTester.hh (31a04e5ac4be)
- src/mem/protocol/MESI_CMP_directory-L1cache.sm (31a04e5ac4be)
- src/mem/protocol/MI_example-cache.sm (31a04e5ac4be)
- src/mem/protocol/MOESI_CMP_directory-L1cache.sm (31a04e5ac4be)
- src/mem/protocol/MOESI_CMP_token-L1cache.sm (31a04e5ac4be)
- src/mem/protocol/MOESI_CMP_token-dir.sm (31a04e5ac4be)
- src/mem/protocol/MOESI_hammer-cache.sm (31a04e5ac4be)
- src/mem/protocol/RubySlicc_Exports.sm (31a04e5ac4be)
- src/mem/protocol/RubySlicc_Profiler.sm (31a04e5ac4be)
- src/mem/protocol/RubySlicc_Types.sm (31a04e5ac4be)
- src/mem/ruby/SConscript (31a04e5ac4be)
- src/mem/ruby/common/Address.hh (31a04e5ac4be)
- src/mem/ruby/common/Address.cc (31a04e5ac4be)
- src/mem/ruby/common/DataBlock.hh (31a04e5ac4be)
- src/mem/ruby/common/DataBlock.cc (31a04e5ac4be)
- src/mem/ruby/filters/BlockBloomFilter.cc (31a04e5ac4be)
- src/mem/ruby/filters/BulkBloomFilter.cc (31a04e5ac4be)
- src/mem/ruby/filters/LSB_CountingBloomFilter.cc (31a04e5ac4be)
- src/mem/ruby/filters/MultiGrainBloomFilter.cc (31a04e5ac4be)
- src/mem/ruby/filters/NonCountingBloomFilter.cc (31a04e5ac4be)
- src/mem/ruby/libruby.hh (31a04e5ac4be)
- src/mem/ruby/libruby.cc (31a04e5ac4be)
- src/mem/ruby/libruby_internal.hh (31a04e5ac4be)
- src/mem/ruby/profiler/AccessTraceForAddress.cc (31a04e5ac4be)
- src/mem/ruby/profiler/AddressProfiler.hh (31a04e5ac4be)
- src/mem/ruby/profiler/AddressProfiler.cc (31a04e5ac4be)
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
On Fri, 18 Mar 2011, Lisa Hsu wrote: What's going on with this patch? I don't believe it's been committed but it seems like it should. I've also got some patches waiting behind this because they used to touch CacheMsg and I don't want to mess Nilay up, so I've been waiting to serialize behind this. Lisa Lisa, the original patch was pretty long and after some of the changes that Brad submitted, almost the whole of the patch required rework. I have already committed some parts of the original patch. I have posted two more patches on the review board that cover some more portion of the patch. You can ignore the original patch. Assume that I will not post more patches that touch CacheMsg or related structures apart from the two that I posted 5 minutes ago. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/#review841 --- Overall, this patch looks good to me as well. I just have a couple minor questions. Though your comment says this patch removes libruby, the diff seems to indicate that the file still remains. Am I reading that correctly? Also it seems that in several places you unecessarily generate the line address, even though the line address already exists in the ruby request (see comments below). src/mem/ruby/storebuffer/storebuffer.cc http://reviews.m5sim.org/r/327/#comment1201 Instead of masking the physical address, can we just use the m_LineAddress? src/mem/ruby/storebuffer/storebuffer.cc http://reviews.m5sim.org/r/327/#comment1202 Same here. Can we just use the m_LineAddress? src/mem/ruby/storebuffer/storebuffer.cc http://reviews.m5sim.org/r/327/#comment1203 And here src/mem/ruby/system/Sequencer.cc http://reviews.m5sim.org/r/327/#comment1199 Why is this line address conversion necessary? Isn't m_LineAddress already set correctly in the constructor? src/mem/ruby/system/Sequencer.cc http://reviews.m5sim.org/r/327/#comment1200 Can you just use the m_LineAddress variable of ruby_request instead of converting the paddr to a line address. - Brad On 2011-01-25 09:15:23, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-25 09:15:23) Review request for Default. Summary --- Remove CacheMsg class from SLICC 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. The changes relating to removal of libruby have been moved to separate patch. Diffs - src/cpu/testers/rubytest/RubyTester.hh 31a04e5ac4be src/mem/protocol/MESI_CMP_directory-L1cache.sm 31a04e5ac4be src/mem/protocol/MI_example-cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_directory-L1cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_token-L1cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_token-dir.sm 31a04e5ac4be src/mem/protocol/MOESI_hammer-cache.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Exports.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Profiler.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Types.sm 31a04e5ac4be src/mem/ruby/SConscript 31a04e5ac4be src/mem/ruby/common/Address.hh 31a04e5ac4be src/mem/ruby/common/Address.cc 31a04e5ac4be src/mem/ruby/common/DataBlock.hh 31a04e5ac4be src/mem/ruby/common/DataBlock.cc 31a04e5ac4be src/mem/ruby/filters/BlockBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/BulkBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/LSB_CountingBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/MultiGrainBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/NonCountingBloomFilter.cc 31a04e5ac4be src/mem/ruby/libruby.hh 31a04e5ac4be src/mem/ruby/libruby.cc 31a04e5ac4be src/mem/ruby/libruby_internal.hh 31a04e5ac4be src/mem/ruby/profiler/AccessTraceForAddress.cc 31a04e5ac4be src/mem/ruby/profiler/AddressProfiler.hh 31a04e5ac4be src/mem/ruby/profiler/AddressProfiler.cc 31a04e5ac4be src/mem/ruby/profiler/Profiler.hh 31a04e5ac4be src/mem/ruby/profiler/Profiler.cc 31a04e5ac4be src/mem/ruby/recorder/CacheRecorder.hh 31a04e5ac4be src/mem/ruby/recorder/CacheRecorder.cc 31a04e5ac4be src/mem/ruby/recorder/TraceRecord.hh 31a04e5ac4be src/mem/ruby/recorder/TraceRecord.cc 31a04e5ac4be src/mem/ruby/recorder/Tracer.hh 31a04e5ac4be src/mem/ruby/recorder/Tracer.cc 31a04e5ac4be 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 31a04e5ac4be src/mem/ruby/slicc_interface/RubySlicc_Util.hh 31a04e5ac4be src/mem/ruby/slicc_interface/SConscript 31a04e5ac4be src/mem/ruby/storebuffer/stb_interface.cc 31a04e5ac4be src/mem/ruby/storebuffer/storebuffer.cc 31a04e5ac4be src/mem/ruby/system/CacheMemory.hh 31a04e5ac4be src/mem/ruby/system/CacheMemory.cc 31a04e5ac4be src/mem/ruby/system/DMASequencer.hh 31a04e5ac4be src/mem/ruby/system/DMASequencer.cc 31a04e5ac4be src/mem/ruby/system/PerfectCacheMemory.hh 31a04e5ac4be src/mem/ruby/system/RubyPort.hh 31a04e5ac4be src/mem/ruby/system/RubyPort.cc 31a04e5ac4be src/mem/ruby/system/Sequencer.hh 31a04e5ac4be src/mem/ruby/system/Sequencer.cc 31a04e5ac4be
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-25 09:15:23.221045) Review request for Default. Summary (updated) --- Remove CacheMsg class from SLICC 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. The changes relating to removal of libruby have been moved to separate patch. Diffs (updated) - src/cpu/testers/rubytest/RubyTester.hh 31a04e5ac4be src/mem/protocol/MESI_CMP_directory-L1cache.sm 31a04e5ac4be src/mem/protocol/MI_example-cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_directory-L1cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_token-L1cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_token-dir.sm 31a04e5ac4be src/mem/protocol/MOESI_hammer-cache.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Exports.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Profiler.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Types.sm 31a04e5ac4be src/mem/ruby/SConscript 31a04e5ac4be src/mem/ruby/common/Address.hh 31a04e5ac4be src/mem/ruby/common/Address.cc 31a04e5ac4be src/mem/ruby/common/DataBlock.hh 31a04e5ac4be src/mem/ruby/common/DataBlock.cc 31a04e5ac4be src/mem/ruby/filters/BlockBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/BulkBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/LSB_CountingBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/MultiGrainBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/NonCountingBloomFilter.cc 31a04e5ac4be src/mem/ruby/libruby.hh 31a04e5ac4be src/mem/ruby/libruby.cc 31a04e5ac4be src/mem/ruby/libruby_internal.hh 31a04e5ac4be src/mem/ruby/profiler/AccessTraceForAddress.cc 31a04e5ac4be src/mem/ruby/profiler/AddressProfiler.hh 31a04e5ac4be src/mem/ruby/profiler/AddressProfiler.cc 31a04e5ac4be src/mem/ruby/profiler/Profiler.hh 31a04e5ac4be src/mem/ruby/profiler/Profiler.cc 31a04e5ac4be src/mem/ruby/recorder/CacheRecorder.hh 31a04e5ac4be src/mem/ruby/recorder/CacheRecorder.cc 31a04e5ac4be src/mem/ruby/recorder/TraceRecord.hh 31a04e5ac4be src/mem/ruby/recorder/TraceRecord.cc 31a04e5ac4be src/mem/ruby/recorder/Tracer.hh 31a04e5ac4be src/mem/ruby/recorder/Tracer.cc 31a04e5ac4be 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 31a04e5ac4be src/mem/ruby/slicc_interface/RubySlicc_Util.hh 31a04e5ac4be src/mem/ruby/slicc_interface/SConscript 31a04e5ac4be src/mem/ruby/storebuffer/stb_interface.cc 31a04e5ac4be src/mem/ruby/storebuffer/storebuffer.cc 31a04e5ac4be src/mem/ruby/system/CacheMemory.hh 31a04e5ac4be src/mem/ruby/system/CacheMemory.cc 31a04e5ac4be src/mem/ruby/system/DMASequencer.hh 31a04e5ac4be src/mem/ruby/system/DMASequencer.cc 31a04e5ac4be src/mem/ruby/system/PerfectCacheMemory.hh 31a04e5ac4be src/mem/ruby/system/RubyPort.hh 31a04e5ac4be src/mem/ruby/system/RubyPort.cc 31a04e5ac4be src/mem/ruby/system/Sequencer.hh 31a04e5ac4be src/mem/ruby/system/Sequencer.cc 31a04e5ac4be src/mem/ruby/system/SparseMemory.cc 31a04e5ac4be src/mem/slicc/parser.py 31a04e5ac4be 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
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
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
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-24 20:26:28.555420) Review request for Default. Summary (updated) --- Remove CacheMsg class from SLICC 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. With this update, all the protocols have been changed. Also, libruby.hh and libruby.cc have been removed. Only problem is that there are still a couple of files DeterministicDriver.cc, RaceyPseudoThread.hh, ... which still refer to libruby.hh. I don't know how to compile these. Diffs (updated) - src/cpu/testers/rubytest/RubyTester.hh 31a04e5ac4be src/mem/protocol/MESI_CMP_directory-L1cache.sm 31a04e5ac4be src/mem/protocol/MI_example-cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_directory-L1cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_token-L1cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_token-dir.sm 31a04e5ac4be src/mem/protocol/MOESI_hammer-cache.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Exports.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Profiler.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Types.sm 31a04e5ac4be src/mem/ruby/SConscript 31a04e5ac4be src/mem/ruby/common/Address.hh 31a04e5ac4be src/mem/ruby/common/Address.cc 31a04e5ac4be src/mem/ruby/common/DataBlock.hh 31a04e5ac4be src/mem/ruby/common/DataBlock.cc 31a04e5ac4be src/mem/ruby/filters/BlockBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/BulkBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/LSB_CountingBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/MultiGrainBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/NonCountingBloomFilter.cc 31a04e5ac4be src/mem/ruby/libruby.hh 31a04e5ac4be src/mem/ruby/libruby.cc 31a04e5ac4be src/mem/ruby/libruby_internal.hh 31a04e5ac4be src/mem/ruby/profiler/AccessTraceForAddress.cc 31a04e5ac4be src/mem/ruby/profiler/AddressProfiler.hh 31a04e5ac4be src/mem/ruby/profiler/AddressProfiler.cc 31a04e5ac4be src/mem/ruby/profiler/Profiler.hh 31a04e5ac4be src/mem/ruby/profiler/Profiler.cc 31a04e5ac4be src/mem/ruby/recorder/CacheRecorder.hh 31a04e5ac4be src/mem/ruby/recorder/CacheRecorder.cc 31a04e5ac4be src/mem/ruby/recorder/TraceRecord.hh 31a04e5ac4be src/mem/ruby/recorder/TraceRecord.cc 31a04e5ac4be src/mem/ruby/recorder/Tracer.hh 31a04e5ac4be src/mem/ruby/recorder/Tracer.cc 31a04e5ac4be 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 31a04e5ac4be src/mem/ruby/slicc_interface/RubySlicc_Util.hh 31a04e5ac4be src/mem/ruby/slicc_interface/SConscript 31a04e5ac4be src/mem/ruby/storebuffer/stb_interface.cc 31a04e5ac4be src/mem/ruby/storebuffer/storebuffer.hh 31a04e5ac4be src/mem/ruby/storebuffer/storebuffer.cc 31a04e5ac4be src/mem/ruby/system/CacheMemory.hh 31a04e5ac4be src/mem/ruby/system/CacheMemory.cc 31a04e5ac4be src/mem/ruby/system/DMASequencer.hh 31a04e5ac4be src/mem/ruby/system/DMASequencer.cc 31a04e5ac4be src/mem/ruby/system/PerfectCacheMemory.hh 31a04e5ac4be src/mem/ruby/system/RubyPort.hh 31a04e5ac4be src/mem/ruby/system/RubyPort.cc 31a04e5ac4be src/mem/ruby/system/Sequencer.hh 31a04e5ac4be src/mem/ruby/system/Sequencer.cc 31a04e5ac4be src/mem/ruby/system/SparseMemory.cc 31a04e5ac4be src/mem/slicc/parser.py 31a04e5ac4be 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
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
To be honest, I think that libruby removal should really be a separate diff. Nate With this update, all the protocols have been changed. Also, libruby.hh and libruby.cc have been removed. Only problem is that there are still a couple of files DeterministicDriver.cc, RaceyPseudoThread.hh, ... which still refer to libruby.hh. I don't know how to compile these. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-21 05:03:54.622452) 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 (updated) - src/mem/ruby/recorder/Tracer.hh f84bfd45d607 src/mem/ruby/recorder/Tracer.cc f84bfd45d607 src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION src/mem/ruby/recorder/TraceRecord.cc f84bfd45d607 src/mem/ruby/profiler/Profiler.cc f84bfd45d607 src/mem/ruby/recorder/CacheRecorder.hh f84bfd45d607 src/mem/ruby/recorder/CacheRecorder.cc f84bfd45d607 src/mem/ruby/recorder/TraceRecord.hh f84bfd45d607 src/mem/ruby/profiler/AccessTraceForAddress.cc f84bfd45d607 src/mem/ruby/profiler/AddressProfiler.hh f84bfd45d607 src/mem/ruby/profiler/AddressProfiler.cc f84bfd45d607 src/mem/ruby/profiler/Profiler.hh f84bfd45d607 src/mem/ruby/libruby_internal.hh f84bfd45d607 src/mem/ruby/libruby.cc f84bfd45d607 src/mem/ruby/filters/LSB_CountingBloomFilter.cc f84bfd45d607 src/mem/ruby/filters/MultiGrainBloomFilter.cc f84bfd45d607 src/mem/ruby/filters/NonCountingBloomFilter.cc f84bfd45d607 src/mem/ruby/libruby.hh f84bfd45d607 src/mem/ruby/filters/BlockBloomFilter.cc f84bfd45d607 src/mem/ruby/filters/BulkBloomFilter.cc f84bfd45d607 src/mem/ruby/common/DataBlock.cc f84bfd45d607 src/mem/ruby/common/DataBlock.hh f84bfd45d607 src/mem/ruby/common/Address.cc f84bfd45d607 src/mem/ruby/common/Address.hh f84bfd45d607 src/mem/ruby/SConscript f84bfd45d607 src/mem/protocol/RubySlicc_Types.sm f84bfd45d607 src/mem/protocol/RubySlicc_Profiler.sm f84bfd45d607 src/mem/protocol/RubySlicc_Exports.sm f84bfd45d607 src/cpu/testers/rubytest/RubyTester.hh f84bfd45d607 src/mem/protocol/MOESI_hammer-cache.sm f84bfd45d607 src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh f84bfd45d607 src/mem/ruby/slicc_interface/RubySlicc_Util.hh f84bfd45d607 src/mem/ruby/slicc_interface/SConscript f84bfd45d607 src/mem/ruby/storebuffer/stb_interface.cc f84bfd45d607 src/mem/ruby/storebuffer/storebuffer.cc f84bfd45d607 src/mem/ruby/system/CacheMemory.hh f84bfd45d607 src/mem/ruby/system/CacheMemory.cc f84bfd45d607 src/mem/ruby/system/DMASequencer.hh f84bfd45d607 src/mem/ruby/system/DMASequencer.cc f84bfd45d607 src/mem/ruby/system/PerfectCacheMemory.hh f84bfd45d607 src/mem/ruby/system/RubyPort.hh f84bfd45d607 src/mem/ruby/system/RubyPort.cc f84bfd45d607 src/mem/ruby/system/Sequencer.hh f84bfd45d607 src/mem/ruby/system/Sequencer.cc f84bfd45d607 src/mem/ruby/system/SparseMemory.cc f84bfd45d607 src/mem/slicc/parser.py f84bfd45d607 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
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
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? 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. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/#review791 --- On 2011-01-21 05:03:54, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-21 05:03:54) 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/mem/ruby/recorder/Tracer.hh f84bfd45d607 src/mem/ruby/recorder/Tracer.cc f84bfd45d607 src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION src/mem/ruby/recorder/TraceRecord.cc f84bfd45d607 src/mem/ruby/profiler/Profiler.cc f84bfd45d607 src/mem/ruby/recorder/CacheRecorder.hh f84bfd45d607 src/mem/ruby/recorder/CacheRecorder.cc f84bfd45d607 src/mem/ruby/recorder/TraceRecord.hh f84bfd45d607 src/mem/ruby/profiler/AccessTraceForAddress.cc f84bfd45d607 src/mem/ruby/profiler/AddressProfiler.hh f84bfd45d607 src/mem/ruby/profiler/AddressProfiler.cc f84bfd45d607 src/mem/ruby/profiler/Profiler.hh f84bfd45d607 src/mem/ruby/libruby_internal.hh f84bfd45d607 src/mem/ruby/libruby.cc f84bfd45d607 src/mem/ruby/filters/LSB_CountingBloomFilter.cc f84bfd45d607 src/mem/ruby/filters/MultiGrainBloomFilter.cc f84bfd45d607 src/mem/ruby/filters/NonCountingBloomFilter.cc f84bfd45d607 src/mem/ruby/libruby.hh f84bfd45d607 src/mem/ruby/filters/BlockBloomFilter.cc f84bfd45d607 src/mem/ruby/filters/BulkBloomFilter.cc f84bfd45d607 src/mem/ruby/common/DataBlock.cc f84bfd45d607 src/mem/ruby/common/DataBlock.hh f84bfd45d607 src/mem/ruby/common/Address.cc f84bfd45d607 src/mem/ruby/common/Address.hh f84bfd45d607 src/mem/ruby/SConscript f84bfd45d607 src/mem/protocol/RubySlicc_Types.sm f84bfd45d607 src/mem/protocol/RubySlicc_Profiler.sm f84bfd45d607 src/mem/protocol/RubySlicc_Exports.sm f84bfd45d607 src/cpu/testers/rubytest/RubyTester.hh f84bfd45d607 src/mem/protocol/MOESI_hammer-cache.sm f84bfd45d607 src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh f84bfd45d607 src/mem/ruby/slicc_interface/RubySlicc_Util.hh f84bfd45d607 src/mem/ruby/slicc_interface/SConscript f84bfd45d607 src/mem/ruby/storebuffer/stb_interface.cc f84bfd45d607 src/mem/ruby/storebuffer/storebuffer.cc f84bfd45d607 src/mem/ruby/system/CacheMemory.hh f84bfd45d607 src/mem/ruby/system/CacheMemory.cc f84bfd45d607 src/mem/ruby/system/DMASequencer.hh f84bfd45d607 src/mem/ruby/system/DMASequencer.cc f84bfd45d607 src/mem/ruby/system/PerfectCacheMemory.hh f84bfd45d607 src/mem/ruby/system/RubyPort.hh f84bfd45d607 src/mem/ruby/system/RubyPort.cc f84bfd45d607 src/mem/ruby/system/Sequencer.hh f84bfd45d607 src/mem/ruby/system/Sequencer.cc f84bfd45d607 src/mem/ruby/system/SparseMemory.cc f84bfd45d607 src/mem/slicc/parser.py f84bfd45d607 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
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-21 05:19:07.165598) 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 (updated) - 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
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
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
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/#review790 --- src/mem/ruby/system/Sequencer.cc http://reviews.m5sim.org/r/327/#comment1112 This is the portion of code that is not working correctly. If I compile this code, it works correctly with ruby random tester. But if I were to un-comment this line and comment out the one below, the code exits due to segmentation fault. In the debug mode, the code fails one of the assertion on the request type. - Nilay On 2011-01-20 14:06:16, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-20 14:06:16) 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 UNKNOWN src/mem/protocol/MOESI_hammer-cache.sm UNKNOWN src/mem/protocol/RubySlicc_Exports.sm UNKNOWN src/mem/protocol/RubySlicc_Profiler.sm UNKNOWN src/mem/protocol/RubySlicc_Types.sm UNKNOWN src/mem/ruby/SConscript UNKNOWN src/mem/ruby/common/Address.hh UNKNOWN src/mem/ruby/common/Address.cc UNKNOWN src/mem/ruby/common/DataBlock.hh UNKNOWN src/mem/ruby/common/DataBlock.cc UNKNOWN src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN src/mem/ruby/libruby.hh UNKNOWN src/mem/ruby/libruby.cc UNKNOWN src/mem/ruby/libruby_internal.hh UNKNOWN src/mem/ruby/profiler/AccessTraceForAddress.cc UNKNOWN src/mem/ruby/profiler/AddressProfiler.hh UNKNOWN src/mem/ruby/profiler/AddressProfiler.cc UNKNOWN src/mem/ruby/profiler/Profiler.hh UNKNOWN src/mem/ruby/profiler/Profiler.cc UNKNOWN src/mem/ruby/recorder/CacheRecorder.hh UNKNOWN src/mem/ruby/recorder/CacheRecorder.cc UNKNOWN src/mem/ruby/recorder/TraceRecord.hh UNKNOWN src/mem/ruby/recorder/TraceRecord.cc UNKNOWN src/mem/ruby/recorder/Tracer.hh UNKNOWN src/mem/ruby/recorder/Tracer.cc UNKNOWN src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh UNKNOWN src/mem/ruby/slicc_interface/RubySlicc_Util.hh UNKNOWN src/mem/ruby/slicc_interface/SConscript UNKNOWN src/mem/ruby/storebuffer/stb_interface.cc UNKNOWN src/mem/ruby/storebuffer/storebuffer.cc UNKNOWN src/mem/ruby/system/CacheMemory.hh UNKNOWN src/mem/ruby/system/CacheMemory.cc UNKNOWN src/mem/ruby/system/DMASequencer.hh UNKNOWN src/mem/ruby/system/DMASequencer.cc UNKNOWN src/mem/ruby/system/PerfectCacheMemory.hh UNKNOWN src/mem/ruby/system/RubyPort.hh UNKNOWN src/mem/ruby/system/RubyPort.cc UNKNOWN src/mem/ruby/system/Sequencer.hh UNKNOWN src/mem/ruby/system/Sequencer.cc UNKNOWN src/mem/ruby/system/SparseMemory.cc UNKNOWN src/mem/slicc/parser.py UNKNOWN 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
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/#review791 --- 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? - Brad On 2011-01-20 14:06:16, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-20 14:06:16) 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 UNKNOWN src/mem/protocol/MOESI_hammer-cache.sm UNKNOWN src/mem/protocol/RubySlicc_Exports.sm UNKNOWN src/mem/protocol/RubySlicc_Profiler.sm UNKNOWN src/mem/protocol/RubySlicc_Types.sm UNKNOWN src/mem/ruby/SConscript UNKNOWN src/mem/ruby/common/Address.hh UNKNOWN src/mem/ruby/common/Address.cc UNKNOWN src/mem/ruby/common/DataBlock.hh UNKNOWN src/mem/ruby/common/DataBlock.cc UNKNOWN src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN src/mem/ruby/libruby.hh UNKNOWN src/mem/ruby/libruby.cc UNKNOWN src/mem/ruby/libruby_internal.hh UNKNOWN src/mem/ruby/profiler/AccessTraceForAddress.cc UNKNOWN src/mem/ruby/profiler/AddressProfiler.hh UNKNOWN src/mem/ruby/profiler/AddressProfiler.cc UNKNOWN src/mem/ruby/profiler/Profiler.hh UNKNOWN src/mem/ruby/profiler/Profiler.cc UNKNOWN src/mem/ruby/recorder/CacheRecorder.hh UNKNOWN src/mem/ruby/recorder/CacheRecorder.cc UNKNOWN src/mem/ruby/recorder/TraceRecord.hh UNKNOWN src/mem/ruby/recorder/TraceRecord.cc UNKNOWN src/mem/ruby/recorder/Tracer.hh UNKNOWN src/mem/ruby/recorder/Tracer.cc UNKNOWN src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh UNKNOWN src/mem/ruby/slicc_interface/RubySlicc_Util.hh UNKNOWN src/mem/ruby/slicc_interface/SConscript UNKNOWN src/mem/ruby/storebuffer/stb_interface.cc UNKNOWN src/mem/ruby/storebuffer/storebuffer.cc UNKNOWN src/mem/ruby/system/CacheMemory.hh UNKNOWN src/mem/ruby/system/CacheMemory.cc UNKNOWN src/mem/ruby/system/DMASequencer.hh UNKNOWN src/mem/ruby/system/DMASequencer.cc UNKNOWN src/mem/ruby/system/PerfectCacheMemory.hh UNKNOWN src/mem/ruby/system/RubyPort.hh UNKNOWN src/mem/ruby/system/RubyPort.cc UNKNOWN src/mem/ruby/system/Sequencer.hh UNKNOWN src/mem/ruby/system/Sequencer.cc UNKNOWN src/mem/ruby/system/SparseMemory.cc UNKNOWN src/mem/slicc/parser.py UNKNOWN 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
