I am beginning work on this now.
On Wed, 3 Dec 2014, Beckmann, Brad wrote:
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
