Re: [m5-dev] RefCountingPtr
I get the feeling you are asking about using the same RefCountingPtr instance in multiple places: don't do that. It will only complicate matters. Just copy the RefCountingPtr, like you would copy a standard pointer. The copy constructor and destructor in RefCountingPtr will make sure it's handled properly, so you don't have to worry about it. If you'd like more documentation on this, Qt provides very similar functionality with the QSharedPointer class: http://doc.trolltech.com/4.6/qsharedpointer.html#details Qt also has a number of other Pointer-replacing classes that are all slightly different. Reading about those might be interesting, too Grts, Jeroen On Thu, 2011-01-20 at 12:28 -0600, Nilay Vaish wrote: So how would you handle pointer to an object which is reference counted? Pointer to the same object may be being used at multiple places. I am facing some trouble with this. Should I post the code on the review board? Nilay On Thu, 20 Jan 2011, nathan binkert wrote: What's the need of having reference counting? And more specifically, why do we need message going into ruby to be reference counted? Reference counting is a garbage collection strategy. It also happens to be one that is easily used in C++. The specific reason why we use reference counting in a few places is because it can some times be difficult to keep track of an object and know when to delete it. For example, if you fire off a message into the memory system, who is responsible for deleting it? There are many different paths that a message could take and potentially many different endpoints where a message could be finished. With reference counting, when the last reference is given up, the object is automatically destroyed. For more info, I suggest wikipedia or google. 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
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] Error in Simulating Mesh Network
Indeed it helped. Thanks Nilay On Thu, 20 Jan 2011, Joel Hestness wrote: Hi Nilay, I believe that this error is fixed in one of the patches that I worked on while at AMD. Brad has pushed it up for review: http://reviews.m5sim.org/r/381/. It's a one line fix. Hope this helps, Joel On Thu, Jan 20, 2011 at 8:15 AM, Nilay Vaish ni...@cs.wisc.edu wrote: Brad, I tried simulating a mesh network with four processors. ./build/ALPHA_FS_MOESI_hammer/m5.prof ./configs/example/ruby_fs.py --maxtick 2000 -n 4 --topology Mesh --mesh-rows 2 --num-l2cache 4 --num-dir 4 I receive the following error: panic: FIFO ordering violated: [MessageBuffer: consumer-yes [ [71227521, 870, 1; ] ]] [Version 1, L1Cache, triggerQueue_in] name: [Version 1, L1Cache, triggerQueue_in] current time: 71227512 delta: 1 arrival_time: 71227513 last arrival_time: 71227521 @ cycle 35613756000 [enqueue:build/ALPHA_FS_MOESI_hammer/mem/ruby/buffers/MessageBuffer.cc, line 198] Do you think that the options I have specified should work correctly? Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] RefCountingPtr
No, my idea was not to share the same RefCountingPtr. I was trying to share the pointer to an object reference to which are being counted. If you take a look at the patches that I have posted on the m5 review board, I am trying to use the same RubyRequest object in multiple places. The class RubyRequest is reference counted and I was trying to make sure that the multiple pointers to same object of this class are handled correctly. -- Nilay On Fri, 21 Jan 2011, Jeroen De Wachter wrote: I get the feeling you are asking about using the same RefCountingPtr instance in multiple places: don't do that. It will only complicate matters. Just copy the RefCountingPtr, like you would copy a standard pointer. The copy constructor and destructor in RefCountingPtr will make sure it's handled properly, so you don't have to worry about it. If you'd like more documentation on this, Qt provides very similar functionality with the QSharedPointer class: http://doc.trolltech.com/4.6/qsharedpointer.html#details Qt also has a number of other Pointer-replacing classes that are all slightly different. Reading about those might be interesting, too Grts, Jeroen On Thu, 2011-01-20 at 12:28 -0600, Nilay Vaish wrote: So how would you handle pointer to an object which is reference counted? Pointer to the same object may be being used at multiple places. I am facing some trouble with this. Should I post the code on the review board? Nilay On Thu, 20 Jan 2011, nathan binkert wrote: What's the need of having reference counting? And more specifically, why do we need message going into ruby to be reference counted? Reference counting is a garbage collection strategy. It also happens to be one that is easily used in C++. The specific reason why we use reference counting in a few places is because it can some times be difficult to keep track of an object and know when to delete it. For example, if you fire off a message into the memory system, who is responsible for deleting it? There are many different paths that a message could take and potentially many different endpoints where a message could be finished. With reference counting, when the last reference is given up, the object is automatically destroyed. For more info, I suggest wikipedia or google. 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
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] breaking up ISA generated files
Agreed. On Wed, Jan 19, 2011 at 1:50 PM, Ali Saidi sa...@umich.edu wrote: I would not complain if the build times went up slightly but I didn't need 8GB of RAM to do a -j 6 build. ;) Ali On Wed, 19 Jan 2011 09:02:13 -0800, nathan binkert n...@binkert.org wrote: I don't think anyone would have any problems if you did it, no? I've done many things because they annoyed *me*. The question is, if it is worth it. For someone that just rebuilds ISAs all the time, I can imagine that it is worth it even if it did increase overall build time slightly. I think it's a fair trade-off to have a neutral build time or even a slight increase if it meant that you could get your machine to work on a file in a better way. My guess is that the major concern was compiling the same thing many time. One thing to consider when you're doing this is to use precompiled headers. I'm pretty sure that gcc supports them and they could in this instance make a difference. (Of course, we need to make it work without PCH). Nate On Wed, Jan 19, 2011 at 2:21 AM, Gabe Black gbl...@eecs.umich.edu wrote: I know we've talked about this before, but another reason for breaking up ISA generated files occurred to me as I'm waiting for X86_SE to build. On a machine with a moderate amount of memory, compiling, say, 8 way parallel works just fine since the memory footprint fits and there's enough work for the CPUs to do. If you happen to hit 2 or 3 (or 4 or 5) of the monster ISA files, though, the memory requirements go up substantially and you could end up blowing out your memory. This has happened to me in the past, and I've end up swapping so bad I had to ssh in from another machine to kill the build since X stopped responding. Needless to say the build time suffers as well. By breaking these really big files into smaller chunks, the memory ceiling of builds stays at a reasonable level throughout. Otherwise if you hit that bottleneck, the only way to move past it is to reduce parallelism for the whole build which makes large parts of it suboptimal. Of course this all sounds nice but is a pain or at least a lot of work to implement, and there was a sentiment (which is quite possibly justified) that the shorter compile times * more compiles comes out in the wash. I think this issue, however, is harder to ignore and a good reason to give this more thought. Gabe ___ 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
[m5-dev] Review Request: [mq]: foo.diff
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/436/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- This discussion of reference counting brings up an interesting issue that came up with a different project of mine. That is constness. Often people use Foo * and const Foo *, but as the class is currently written, we can't do that properly with our refcount stuff. There are a few simple changes that do make this work (see diff). The essential issue is that the reference count itself should be mutable, and the methods that access the actual pointer in the smart pointer class should be const (since you're not changing the smart pointer when you're accessing them). Anyway, there's no rush or really even any need on my part for this, but in theory, we are doing it wrong and if people are trying to use const FooPtr, they're probably doing the wrong thing. I could just leave well enough alone and not touch this, or if people agree that what we have is wrong, I can make sure that this diff is correct run regressions, and commit it. This would mean using two typedefs: typedef RefCountingPtrFoo FooPtr; typedef RefCountingPtrconst Foo ConstFooPtr; Diffs - src/base/refcnt.hh de7601e6e19d Diff: http://reviews.m5sim.org/r/436/diff Testing --- Thanks, Nathan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Question on SLICC
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
Re: [m5-dev] changeset in m5: checkpointing: fix bug from curTick accessor co...
I like this idea a lot. Not only would it solve the SERIALIZE_* v. paramOut
usage problem, but it would also decouple the code variable name from the
name written to the checkpoint. If used intelligently, this could alleviate
some of the pain of fixing old checkpoints when code changes.
Joel
On Fri, Jan 21, 2011 at 12:57 AM, Gabe Black gbl...@eecs.umich.edu wrote:
From time to time It seems to be that we need to serialize something
but call it something other than its variable name. Would it make sense
to add SERIALIZE_*_AS macros that take a name argument as well? It's not
that hard to create a temporary variable or use those param functions
directly, but it would at least make things look more consistent to
always (or almost always) use SERIALIZE_FOO.
Gabe
On 01/20/11 22:11, Steve Reinhardt wrote:
changeset 494b5426e70d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=494b5426e70d
description:
checkpointing: fix bug from curTick accessor conversion.
Regex replacement of curTick with curTick() accidentally
changed checkpoint key string for serialization but not
for unserialization.
diffstat:
src/sim/serialize.cc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diffs (12 lines):
diff -r f84bfd45d607 -r 494b5426e70d src/sim/serialize.cc
--- a/src/sim/serialize.ccWed Jan 19 16:22:23 2011 -0800
+++ b/src/sim/serialize.ccThu Jan 20 22:13:33 2011 -0800
@@ -400,7 +400,7 @@
Globals::serialize(ostream os)
{
nameOut(os);
-SERIALIZE_SCALAR(curTick());
+paramOut(os, curTick, curTick());
nameOut(os, MainEventQueue);
mainEventQueue.serialize(os);
___
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
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Restricting W-W reordering in O3
Hi,
How can I enforce the reordering restriction between stores in the O3 (W-W
restriction)? To make an store to be executed only after all stores issued
before it were executed.
I tried adding this condition in the executeStore method in
lsq_unit_impl.hh, but it didn't work:
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
return genMachineCheckFault();
}
Thanks,
--
Eberle Rambo.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] 3 Bugs in the checkpoint_restore for spec2006
I agree with your point about dup. I imagine we can keep an additional field
that determines whether a file descriptor was created by dup and if so,
re-open it with dup at the point of checkpoint restore. I will work on a fix
and post the diff.
Best,
-Rick
On Thu, Jan 20, 2011 at 10:32 PM, Steve Reinhardt ste...@gmail.com wrote:
Hi Rick,
Thanks for figuring this out. The last one is clearly just my dumb
mistake; I just committed a fix. The serialization/unserialization of mode
is an obvious enough oversight too.
I'm not quite so sure about the dup fix though... I think the original
sim_fd_obj() is doing the right thing, it's just that perhaps that's not
what dupFunc() needs or wants. That just means dupFunc() shouldn't be
calling it though. Maybe dupFunc() needs to call a different function that
doesn't exist. However, I'm not so sure about that, because I'm not
convinced the overall strategy for checkpointing and restoring dup'd fds is
even right. At first glance, it looks like when we unserialize a pair of
dup'd fds, we'll end up opening the file twice, rather than calling dup()
again, which seems more correct.
Steve
On Thu, Jan 20, 2011 at 11:41 AM, Richard Strong rstr...@cs.ucsd.eduwrote:
Hi all,
I uncovered 3 bugs when trying to resume in ALPHA_SE from a checkpoint for
the spec2006 benchmarks. They are:
(1) Unserializing curTick failed because the checkpoint file wrote
curTick()=, but the unserializing code was expecting curTick=
(2) The mode bit was not being stored in the file descriptor checkpoint. I
added a feature to store the mode bit.
(3) The dup function was duplicating the wrong file descriptor.
Let me know what you think, I give the diff below along with a traceflag
that allowed me to find the problem.
Best,
-Rick
diff --git a/src/sim/SConscript b/src/sim/SConscript
--- a/src/sim/SConscript
+++ b/src/sim/SConscript
@@ -77,3 +77,4 @@
TraceFlag('Thread')
TraceFlag('Timer')
TraceFlag('VtoPhys')
+TraceFlag('FileDescriptors')
diff --git a/src/sim/process.cc b/src/sim/process.cc
--- a/src/sim/process.cc
+++ b/src/sim/process.cc
@@ -268,6 +268,7 @@
int
Process::alloc_fd(int sim_fd, string filename, int flags, int mode, bool
pipe)
{
+DPRINTF(FileDescriptors, alloc_fd fd:%d filename:%s\n, sim_fd,
filename);
// in case open() returns an error, don't allocate a new fd
if (sim_fd == -1)
return -1;
@@ -295,6 +296,7 @@
void
Process::free_fd(int tgt_fd)
{
+DPRINTF(FileDescriptors, free_fd fd:%d name:%s\n, tgt_fd, NULL);
Process::FdMap *fdo = fd_map[tgt_fd];
if (fdo-fd == -1)
warn(Process::free_fd: request to free unused fd %d, tgt_fd);
@@ -324,8 +326,16 @@
{
if (tgt_fd MAX_FD)
panic(sim_fd_obj called in fd out of range.);
+
-return fd_map[tgt_fd];
+//return fd_map[tgt_fd];
+for (int x = 0; x = MAX_FD; x++) {
+ if (fd_map[x].fd == tgt_fd){
+ return fd_map[x];
+ }
+ }
+ panic(sim_fd_obj could not find system fd.);
+ return NULL;
}
bool
@@ -458,6 +468,7 @@
if (fdo-fd != -1) {
fdo-fileOffset = lseek(fdo-fd, 0, SEEK_CUR);
} else {
+DPRINTF(FileDescriptors, find_file_offsets fd:%d
filename:%s\n, fdo-fd, fdo-filename);
fdo-filename = NULL;
fdo-fileOffset = 0;
}
@@ -480,6 +491,7 @@
SERIALIZE_SCALAR(flags);
SERIALIZE_SCALAR(readPipeSource);
SERIALIZE_SCALAR(fileOffset);
+SERIALIZE_SCALAR(mode);
}
void
@@ -491,6 +503,7 @@
UNSERIALIZE_SCALAR(flags);
UNSERIALIZE_SCALAR(readPipeSource);
UNSERIALIZE_SCALAR(fileOffset);
+UNSERIALIZE_SCALAR(mode);
}
void
diff --git a/src/sim/serialize.cc b/src/sim/serialize.cc
--- a/src/sim/serialize.cc
+++ b/src/sim/serialize.cc
@@ -411,7 +411,7 @@
{
const string section = name();
Tick tick;
-paramIn(cp, section, curTick, tick);
+paramIn(cp, section, curTick(), tick);
curTick(tick);
mainEventQueue.unserialize(cp, MainEventQueue);
___
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
Re: [m5-dev] changeset in m5: checkpointing: fix bug from curTick accessor co...
My initial reaction to Gabe's email is that I'd rather go the other way, and
make SERIALIZE_SCALAR() look more like paramOut() than the other way around.
I don't generally like preprocessor macros, but in this case the
convenience of not having to type the variable name twice justified it. I
don't like the implicit 'os' parameter that SERIALIZE_SCALAR() requires.
Just brainstorming, but maybe we could create a macro like
#define VAR(x) #x, x
then get rid of most or all of the SERIALIZE_* and UNSERIALIZE_* macros
because you could just write:
paramOut(os, VAR(foo))
and
paramIn(os, VAR(foo))
etc.
If we do do this, I agree that VAR() is a crappy name, but I couldn't come
up with anything better in five seconds.
I sympathize with Joel's point about compatibility, but 90% of the vars have
the same name in the checkpoint and I don't want the redundancy of saying
things twice. I think the answer there is not to change the infrastructure
but just to be more sensitive in the review process and not just let patches
go through that rename serialized vars, but instead insist that in those
cases the patch should explicitly use paramOut/paramIn to allow the var name
to change but leave the serialization name unchanged where that makes sense.
Steve
On Fri, Jan 21, 2011 at 10:55 AM, Joel Hestness hestn...@cs.utexas.eduwrote:
I like this idea a lot. Not only would it solve the SERIALIZE_* v.
paramOut usage problem, but it would also decouple the code variable name
from the name written to the checkpoint. If used intelligently, this could
alleviate some of the pain of fixing old checkpoints when code changes.
Joel
On Fri, Jan 21, 2011 at 12:57 AM, Gabe Black gbl...@eecs.umich.eduwrote:
From time to time It seems to be that we need to serialize something
but call it something other than its variable name. Would it make sense
to add SERIALIZE_*_AS macros that take a name argument as well? It's not
that hard to create a temporary variable or use those param functions
directly, but it would at least make things look more consistent to
always (or almost always) use SERIALIZE_FOO.
Gabe
On 01/20/11 22:11, Steve Reinhardt wrote:
changeset 494b5426e70d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=494b5426e70d
description:
checkpointing: fix bug from curTick accessor conversion.
Regex replacement of curTick with curTick() accidentally
changed checkpoint key string for serialization but not
for unserialization.
diffstat:
src/sim/serialize.cc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diffs (12 lines):
diff -r f84bfd45d607 -r 494b5426e70d src/sim/serialize.cc
--- a/src/sim/serialize.ccWed Jan 19 16:22:23 2011 -0800
+++ b/src/sim/serialize.ccThu Jan 20 22:13:33 2011 -0800
@@ -400,7 +400,7 @@
Globals::serialize(ostream os)
{
nameOut(os);
-SERIALIZE_SCALAR(curTick());
+paramOut(os, curTick, curTick());
nameOut(os, MainEventQueue);
mainEventQueue.serialize(os);
___
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
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
___
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
Re: [m5-dev] changeset in m5: checkpointing: fix bug from curTick accessor co...
I sympathize with Joel's point about compatibility, but 90% of the vars have the same name in the checkpoint and I don't want the redundancy of saying things twice. I think the answer there is not to change the infrastructure but just to be more sensitive in the review process and not just let patches go through that rename serialized vars, but instead insist that in those cases the patch should explicitly use paramOut/paramIn to allow the var name to change but leave the serialization name unchanged where that makes sense. We had discussed changing serialization so that there was a serializer class and paramOut/paramIn were methods of that class (getting rid of the os parameter for ParamOut and the cp and section parameters of param in). The goal was to eventually get away from serializing directly to an ostream, and instead allow something more intelligent (like serializing into a map or into python directly and then dumping whatever format afterwards maybe XML is better? :P, also this would allow sub objects and stuff like that). That said, if anyone is going to make a bunch of changes to how serialization is done across the whole codebase, I'd like to at least get a serializer in that does exactly what we do now so that we can reduce the number of across the board changes yet still enable forward compatibility with future serialization mechanisms. My initial reaction to Gabe's email is that I'd rather go the other way, and make SERIALIZE_SCALAR() look more like paramOut() than the other way around. I don't generally like preprocessor macros, but in this case the convenience of not having to type the variable name twice justified it. I don't like the implicit 'os' parameter that SERIALIZE_SCALAR() requires. Just brainstorming, but maybe we could create a macro like #define VAR(x) #x, x then get rid of most or all of the SERIALIZE_* and UNSERIALIZE_* macros because you could just write: paramOut(os, VAR(foo)) and paramIn(os, VAR(foo)) etc. If we do do this, I agree that VAR() is a crappy name, but I couldn't come up with anything better in five seconds. For this thing, I worry that picking a #define that is too short will risk a name collision. There is a trick we can play with variadic macros: #define SERIALIZE_SCALAR(x, ...) serializer.ParamOut(x, #x, __VA_ARGS__) Then we have two versions of ParamOut. The two argument version where the second argument is the name, and the three argument version where the third argument is the name and the second argument is ignored. (Disgusting, I know). All that said, if we can come up with a more generalized name for VAR that can be used anywhere that this comes up (since this is certainly not the only place this happens). I'm not at all opposed to that. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] 3 Bugs in the checkpoint_restore for spec2006
I was thinking about this a little more, and I think if we really want to get it right we need a more comprehensive change that better mirrors what's going on inside the OS, where dup'd fds are really just different pointers to the same underlying file object (including the file pointer). So most of the stuff in FdMap should be in a separate file object so that multiple fds can point to it, and the fdMap itself should just have the host fd and a pointer to the file object. Then dupFunc() would call dup() to get a new host fd, then create a new fdMap entry that has the new host fd but just copies the pointer from the original fdMap entry. Obviously the serialize/unserialize gets more complicated now, and if you really want to do it right you'll need some kind of ref counting on the file objects so that a dup()/close() sequence does the right thing... I didn't say it would be a small change, but IMO this is what it will take to really do it right. And I see that the Process field is really fd_map, but that's actually a historical anomaly that goes against our style... it should be fdMap. This is a good idea and if we have a serializer object that supports sub-objects and a way to mark an object as already having been serialized, this (and other things like it, e.g. events, packets, etc.) wouldn't be a big deal at all. In general that sort of support would be quite welcome I should think. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: checkpointing: fix bug from curTick accessor co...
On Fri, Jan 21, 2011 at 11:33 AM, nathan binkert n...@binkert.org wrote: We had discussed changing serialization so that there was a serializer class and paramOut/paramIn were methods of that class (getting rid of the os parameter for ParamOut and the cp and section parameters of param in). [...] Agreed, there's plenty of other room for improvement in serialization and it may make sense to fold some other steps in that direction into this kind of change. I was trying to ignore that for now and just focus on the issue that kicked off the discussion. If we do do this, I agree that VAR() is a crappy name, but I couldn't come up with anything better in five seconds. For this thing, I worry that picking a #define that is too short will risk a name collision. Agree here too, that's one of the main things that makes it a crappy name. There is a trick we can play with variadic macros: #define SERIALIZE_SCALAR(x, ...) serializer.ParamOut(x, #x, __VA_ARGS__) Then we have two versions of ParamOut. The two argument version where the second argument is the name, and the three argument version where the third argument is the name and the second argument is ignored. (Disgusting, I know). I was thinking that something could be done with variadic macros, but didn't go so far as to come up with a concrete solution... perhaps my tolerance is lower so I just got revolted by the idea sooner than Nate did :-). I would still like to have something where the two forms look more similar; the nice thing about the VAR() approach is that it's clear you're calling the same function and just taking a shortcut on providing the name. All that said, if we can come up with a more generalized name for VAR that can be used anywhere that this comes up (since this is certainly not the only place this happens). I'm not at all opposed to that. Yea, I really like the idea of getting rid of *all* the different (UN)SERIALIZE_* macros and replacing them with a single mechanism. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] FYI
I have changed the wiki to say that we recommend using the development repository (over m5-stable), since in practice that really is better. Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] FYI
In general, the algorithm should probably be: - pick one and try it... if it works for you, great. - if not, try the other one - if neither one works, ask on m5-users If people followed this approach, then it wouldn't matter nearly as much which one they started with. Steve On Fri, Jan 21, 2011 at 2:50 PM, Lisa Hsu h...@eecs.umich.edu wrote: I have changed the wiki to say that we recommend using the development repository (over m5-stable), since in practice that really is better. Lisa ___ 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
Re: [m5-dev] FYI
I'm on a roll with overhead stuff at work today. Updated again to reflect the sentiment below. On Fri, Jan 21, 2011 at 3:09 PM, Steve Reinhardt ste...@gmail.com wrote: In general, the algorithm should probably be: - pick one and try it... if it works for you, great. - if not, try the other one - if neither one works, ask on m5-users If people followed this approach, then it wouldn't matter nearly as much which one they started with. Steve On Fri, Jan 21, 2011 at 2:50 PM, Lisa Hsu h...@eecs.umich.edu wrote: I have changed the wiki to say that we recommend using the development repository (over m5-stable), since in practice that really is better. Lisa ___ 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
Re: [m5-dev] Review Request: mcpat: Adds McPAT performance counters
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/380/ --- (Updated 2011-01-21 16:39:38.310375) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- mcpat: Adds McPAT performance counters Updated patches from Rick Strong's set that modify performance counters for McPAT Diffs (updated) - src/cpu/BaseCPU.py 9f9e10967912 src/cpu/base.hh 9f9e10967912 src/cpu/base.cc 9f9e10967912 src/cpu/o3/commit.hh 9f9e10967912 src/cpu/o3/commit_impl.hh 9f9e10967912 src/cpu/o3/cpu.hh 9f9e10967912 src/cpu/o3/cpu.cc 9f9e10967912 src/cpu/o3/iew_impl.hh 9f9e10967912 src/cpu/o3/inst_queue.hh 9f9e10967912 src/cpu/o3/inst_queue_impl.hh 9f9e10967912 src/cpu/o3/rename.hh 9f9e10967912 src/cpu/o3/rename_impl.hh 9f9e10967912 src/cpu/o3/rob.hh 9f9e10967912 src/cpu/o3/rob_impl.hh 9f9e10967912 src/cpu/simple/atomic.cc 9f9e10967912 src/cpu/simple/base.hh 9f9e10967912 src/cpu/simple/base.cc 9f9e10967912 src/cpu/simple/timing.cc 9f9e10967912 src/sim/System.py 9f9e10967912 src/sim/system.hh 9f9e10967912 src/sim/system.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/380/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: SConstruct: Fix the librt check in SConstruct.
changeset d38c1f650a4e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d38c1f650a4e
description:
SConstruct: Fix the librt check in SConstruct.
diffstat:
SConstruct | 7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diffs (17 lines):
diff -r 494b5426e70d -r d38c1f650a4e SConstruct
--- a/SConstructThu Jan 20 22:13:33 2011 -0800
+++ b/SConstructFri Jan 21 17:51:22 2011 -0800
@@ -704,8 +704,11 @@
Exit(1)
# Check for librt.
-have_posix_clock = conf.CheckLib(None, 'clock_nanosleep', 'time.h') or \
-conf.CheckLib('rt', 'clock_nanosleep', 'time.h')
+have_posix_clock = \
+conf.CheckLibWithHeader(None, 'time.h', 'C',
+'clock_nanosleep(0,0,NULL,NULL);') or \
+conf.CheckLibWithHeader('rt', 'time.h', 'C',
+'clock_nanosleep(0,0,NULL,NULL);')
if not have_posix_clock:
print Can't find library for POSIX clocks.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
