Thanks Nilay for the response. I like the idea of statically defining MachineType and all the associated helper functions. Let's plan on doing that.
Brad -----Original Message----- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Wednesday, December 03, 2014 11:26 AM To: Beckmann, Brad Cc: gem5 Developer List (gem5-dev@gem5.org) Subject: RE: Protocol Specific Profiling 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
