Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> Nate, the idea behind this set of changes is to do away with the debug > support (including DEBUG_EXPR) provided by Ruby. Deciding whether given > volume of debug output is too verbose or not will vary from situation to > situation. Since M5 does not have a verbosity level, it is better not to >

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

Nate, the idea behind this set of changes is to do away with the debug support (including DEBUG_EXPR) provided by Ruby. Deciding whether given volume of debug output is too verbose or not will vary from situation to situation. Since M5 does not have a verbosity level, it is better not to have i

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> 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

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

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

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/ --- (Updated 2010-10-26 10:17:01.760756) Review request for Default and Ruby Reviewers.

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 neede

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/#review422 --- Ship it! Overall, it looks good to me. The only thing I would like to se

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-21 13:35:21, Steve Reinhardt wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 332 > > > > > > This DPRINTF is broken (and several others like it)... it needs a trace > > flag as the first arg, and

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/ --- (Updated 2010-10-25 13:10:22.143949) Review request for Default and Ruby Reviewers.

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/#review420 --- Looking much better. There are two main questions: 1) Do we want Ruby to p

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> If we just want to insert __FILE__ and __LINE__ as part of the prefix, > we should define a new flavor of DPRINTF that does that in the same > header where DPRINTF itself is, and use that version as-is in SLICC. > Maybe call it DPRINTFL? Which __FILE__ and __LINE__ are getting inserted? Somethi

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> Does that mean that format specifiers used in DPRINTF() statements are just > place holders? In not, what would be the format specifier for printing an > object of some class that supports << operator? No. %s passes a string in an unprocessed way, but the other format specifiers do various os

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/#review419 --- src/mem/protocol/MESI_CMP_directory-L2cache.sm

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

On Mon, Oct 25, 2010 at 7:57 AM, Nilay Vaish wrote: > > >> On 2010-10-24 21:45:51, Steve Reinhardt wrote: >> > src/mem/SConscript, line 61 >> > >> > >> >     Nate and I agreed that it would be nice not to prefix all of these >> > w

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

On Mon, Oct 25, 2010 at 7:54 AM, Nilay Vaish wrote: > > I have removed the _to_string() function calls that were appearing in .sm > files. Also, I have added a comment for the changes made to the > FuncCallExprAST.py. Great, thanks. I didn't realize that the operator<< definitions already exis

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-24 21:45:51, Steve Reinhardt wrote: > > src/mem/SConscript, line 61 > > > > > > Nate and I agreed that it would be nice not to prefix all of these with > > "Ruby", though if other people feel this decision needs m

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/ --- (Updated 2010-10-25 07:54:18.182412) Review request for Default and Ruby Reviewers.

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-24 21:45:51, Steve Reinhardt wrote: > > src/mem/ruby/storebuffer/storebuffer.cc, line 163 > > > > > > In these cases (and the ones below) where this is really a fatal error, > > I believe the whole ERROR_OUT/DEBU

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/#review415 --- Thanks, this is hugely improved. Just a few little things I noticed still

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/ --- (Updated 2010-10-24 08:59:56.664764) Review request for Default and Ruby Reviewers.

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

On Sat, Oct 23, 2010 at 1:59 PM, Nilay Vaish wrote: > > >> On 2010-10-21 13:35:21, Steve Reinhardt wrote: >> > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 332 >> > >> > >> >     This DPRINTF is broken (and several others l

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

On Sat, Oct 23, 2010 at 1:52 PM, Nilay Vaish wrote: > > >> On 2010-10-21 13:35:21, Steve Reinhardt wrote: >> > src/cpu/testers/rubytest/CheckTable.cc, line 114 >> > >> > >> >     These adjacent DPRINTFs should be consolidated into

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-21 13:35:21, Steve Reinhardt wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 332 > > > > > > This DPRINTF is broken (and several others like it)... it needs a trace > > flag as the first arg, and

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-21 13:35:21, Steve Reinhardt wrote: > > src/cpu/testers/rubytest/CheckTable.cc, line 114 > > > > > > These adjacent DPRINTFs should be consolidated into one. It's more > > efficient (since it's a single check of

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

ent: Friday, October 22, 2010 3:38 PM To: M5 Developer List Subject: Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support On Fri, Oct 22, 2010 at 3:12 PM, nathan binkert wrote: >> So I guess the upshot is that if there are complex Ruby types (not >> just type

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

On Fri, Oct 22, 2010 at 3:12 PM, nathan binkert wrote: >> So I guess the upshot is that if there are complex Ruby types (not >> just typedefs of builtin types) that want to have standard ways of >> printing themselves out, that's kind of inconsistent with M5 right >> there :-), but if you want to

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

One exception to that are the PCState structs I'm in the process of adding. These each overload << to print themselves as (X1=>X2=>X3).(Y1=>Y2) where the X*s are as many architecture level PCs as are needed and the Y*s are microPCs. This is in the middle where it's too complex for a single

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> So I guess the upshot is that if there are complex Ruby types (not > just typedefs of builtin types) that want to have standard ways of > printing themselves out, that's kind of inconsistent with M5 right > there :-), but if you want to keep that behavior then overloading > operator<< is the way

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

I think part of the confusion is that we don't typically overload operator<< in M5 because we don't typically define complex types that have standard ways of printing themselves out. So for example simple M5 types like Tick and Addr are just typedefs for uint64_t (or something like that), so << ju

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

One additional comment, there is no reason that the implementation of operator<< couldn't itself use cprintf. e.g.: iostream & operator<<(iostream &out, const Foo &foo) { ccprintf(out, "<%d:%s>", foo.val, foo.name()); return out; } On Fri, Oct 22, 2010 at 2:29 PM, nathan binkert wrote:

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> Nilay, I apologize for the confusion here.  It seems that Nate and I are > suggesting you go in two different directions in terms of the operator<<.  I > personally wanted to get away from the operator<< overloading, so that Ruby > objects looked more similar to most M5 objects.  Especially be

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

; Nathan Binkert Subject: Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/#review406 -

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/#review406 --- Ship it! Overall, I have two major comments. 1) You should get rid of pr

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-21 13:35:21, Steve Reinhardt wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 333 > > > > > > We should get rid of these commented-out lines, either deleting them if > > they're not needed or just

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-21 13:35:21, Steve Reinhardt wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 332 > > > > > > This DPRINTF is broken (and several others like it)... it needs a trace > > flag as the first arg, and

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-21 15:23:04, Brad Beckmann wrote: > > src/mem/ruby/common/Debug.hh, line 231 > > > > > > I agree with Steve's point that adding "__PRETTY_FUNCTION__, __FILE__, > > __LINE__" to every Ruby DPRINTF call is too cumb

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

> On 2010-10-21 13:35:21, Steve Reinhardt wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 332 > > > > > > This DPRINTF is broken (and several others like it)... it needs a trace > > flag as the first arg, and

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/#review399 --- I think Steve covered most of the main points. Please see my detailed com

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/#review398 --- src/cpu/testers/rubytest/CheckTable.cc

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/ --- (Updated 2010-10-19 17:30:48.985205) Review request for Default and Ruby Reviewers.

[m5-dev] Review Request: Moving Ruby to M5's debug print support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/ --- Review request for Ruby Reviewers. Summary --- Ruby currently uses GEMS debug