On Wed, 3 Dec 2014, Beckmann, Brad wrote:
I have more questions/issues on this topic of protocol specific profiling. I do not believe this issues should be fixed by having SLICC understand more STL types. I should have pointed out before that many times it is not one specific protocol that needs special profiling, but rather a set of protocols that need special profiling. In the past, this has been handled by adding special profiling to either the profiler or sequencer, often by using the GenericMachineType. Unfortunately, you've removed GenericMachineType so if one where to compile a protocol that did not create those specific machine types, any special profiling functions that relied on them will fail to build. Why did you remove that enum definition from RubySlicc_Types.sm? Is there any reason we cannot add it back?
I am ok with adding GenericMachineType back. In addition, I would prefer that we stop defining MachineType dynamically and instead make each MachineType used in a .sm file be one of those generic types. I think this will also allow us to compile all the protocols simultaneously.
-- Nilay _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
