src/mem/ruby/system/CacheMemory.cc (Diff revision 1)

Just a bit surprised at the method of turning RubyRequestType_NUM into an int. Intentional? Why not (int) or static_cast<int>?

Show all issues

1. Nilay Vaish July 5, 2012, 3:37 a.m. (July 5, 2012, 3:37 a.m.)

   I just copied the code that was present in CacheProfiler.cc file earlier.

src/mem/slicc/symbols/StateMachine.py (Diff revision 1)

Is this change intended to be part of this patch?

Show all issues

1. Nilay Vaish July 5, 2012, 3:37 a.m. (July 5, 2012, 3:37 a.m.)

   This is correct. The code in question is being used to call the printStats() method. 
   Earlier both CacheMemory and DirectoryMemory appeared in the check. But since statistics 
   related to CacheMemory are being moved, so there is no need to call the printStats() method
   on CacheMemory. But DirectoryMemory will still use Ruby's style. It will also be converted
   in due course.

Nilay, can you hold off checking this patch in until I commit my changes.  We have a lot of internal code that uses the current Cache Profiler that I'll need to change.  I'd rather not do that in the next few weeks.

This patch reminds me of a larger question that is worth revisiting.  Is now the time to convert Ruby stats to gem5 stats, since gem5 stats are now python objects and can potentially be outputted in any format.  The last half of that statement may be a streach, so please correct me if that's untrue.  As you know, I've been relucant to convert Ruby stats to gem5 stats because many Ruby stats are useful in the debugging process, and Ruby's more condense format is much more readable.  Meanwhile, the default gem5 stats format is optimized for data extraction.  If we could use the new python support to generate an output file that looks a lot like the current ruby.stats file, then now maybe a good time to switch.  This is probably a better topic for a separate thread, but I wanted to mention that thought before I forgot.