On Mon, 24 Nov 2014, Beckmann, Brad wrote:
Hi Nilay,
On July 24, 2013 you removed the RubySlice_Profiler.sm,
RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh
files. See changeset 9771:57aac1719f86. By removing those files, you
removed the ability to provide protocol specific profiling. Your
I think you need to define what you mean by protocol specific profiling.
The .sm file just contained some function prototypes. The actual
definitions were calling on the RubySystem to get the RubyProfiler, both
of which can be instantiated only once.
comment seems to suggest that you expect that all profile functions
called by the .sm files to use functions defined in AbstractController.
Is that correct? That solution doesn't seem very scalable and it will
lead to a very large AbstractController definition (I'm quite surprised
how much that file has grown in the past two years...20+ modifications).
If you need a new statistic, it should be defined in the .sm file for the
controller that needs the statistic. That would be protocol specific.
Defining everything in a single place is not protocol specific.
Do you see a better way to support protocol specific profiling? We
could add back in the RubySlice_Profiler.sm,
RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh
files, but I understand the benefit to have the functions be defined on
a per machine basis.
If you want the previous setup back, you can bring it back. Otherwise you
can add code to RubySlicc_Util.hh in fashion similar to
RubySlicc_Profiler.hh.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
