GEMS has supported multiple filter strings ever since I can remember and one could have added the ability to use multiple filter strings to .sm debug statements in the past, but there has never been the need to. It just seems redundant to explicitly specify the debug string and the .sm files are already quite verbose.
In my mind, we are needlessly adding a feature to the .sm files that we don't need and we're just further cluttering the .sm files. Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of nathan binkert Sent: Tuesday, October 26, 2010 9:48 AM To: M5 Developer List Cc: Nilay Vaish; Beckmann, Brad; Steve Reinhardt Subject: Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support > I would prefer not to have the .sm DPRINTF calls look exactly like the c++ > calls. In particular, it seems unecessary to specify the trace flag > "RubySlicc" at every DPRINTF statement. I don't think we'll ever need more > than one trace flag for the .sm debug statements. We've never needed more > than one in the past. Also by removing the trace flag, it will be one less > thing (though I understand it is relatively minor) for the protocol > programmer to worry about. Famous last words. First, I'd change RubySlicc to just Slicc (it's not like there's confusion there), but honestly, once you get used to having trace flags and start sprinkling them more liberally into the code, you'll honestly want to have more flags. For example, when the protocol interacts with the cache, it might make more sense for that flag to be tagged with cache, or when you interact with the directory, etc. I see little benefit from preventing this and I see a clear downside. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
