Hi guys, Slightly off topic, but it sounds like you want some form of inheritance structure between the protocols.
Andreas On 03/12/2014 01:16, "Beckmann, Brad via gem5-dev" <[email protected]> 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? > >Brad > > > >-----Original Message----- >From: Nilay Vaish [mailto:[email protected]] >Sent: Monday, November 24, 2014 6:50 PM >To: Beckmann, Brad >Cc: gem5 Developer List ([email protected]) >Subject: RE: Protocol Specific Profiling > >On Tue, 25 Nov 2014, Beckmann, Brad wrote: > >> Thanks Nilay for the prompt reply. An example of a protocol specific >> statistic would be if say in a region coherence protocol [Power et >> al.], I was profiling the latencies of downgrade request-acks and I >> wanted to do that for the cross-product of requestor and request type. >> That is just one example, there are a million different possible >> statistics one could imagine wanting to collect. The specific example >> isn't important, the important part is we need any easy way to add >> protocol specific statistic processing. In other words, I want to >> collect data that doesn't neatly match a current gem5 statistic type >> and instead requires some sort of C++ customization before being added >>to a static data type. > >I think you are using a map or vector of some type. I would probably >make SLICC understand what those types are. If you don't want to go that >way, then you will have to do something similar to the earlier setup. >Prototype a function in one of the .sm files, then define it say in >RubySlicc_Util.hh and add the corresponding variable in the Profiler >class. > >> >> I'm not advocating for the prior solution. I completely agree going >> through the RubySlicc_Profile files was not great, but it is better >> than going through the AbstractController. At least the >> RubySlicc_Profile files were only collecting profile features. The >> AbstractController is growing into a beast. Perhaps what I'm looking >> for is an AbstractProfiler class that we can offload the current >> profiling work done by the AbstractController. > >Going through the abstract controller can be another way. I am actually >not worried about the size of the class, unless you think that some >function or data member is unecessary. We can define a class with in the >AbstractController if you are worried about the profiling variables. If >I am counting correctly, there are just three of them right now. > >> >> I like the work you've done to collate statistics from independent >> object instantiations to a common set of data structures. We need to >> work on how those data structures are printed out, but your overall >> approach seems great. It seems the real problem we have now is that >> the generated collateStats functions directly cast to the >> AbstractController, thus all the stat interface functions need to be >> in the AbstractController. Instead, we to generate a protocol >> specific controller profiler that perhaps inherits from a >> to-be-determined AbstractProfiler class. >> > >The Profiler class still exists. You can still define a globally visible >function that calls on the profiler to store some statistic. This is >what use to happen before. The only other way I can think of is to make >SLICC understand the different data structures we want to work with and >use them in .sm files. > >-- >Nilay >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
