On Sat, Oct 23, 2010 at 1:59 PM, Nilay Vaish <[email protected]> wrote: > > >> On 2010-10-21 13:35:21, Steve Reinhardt wrote: >> > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 332 >> > <http://reviews.m5sim.org/r/277/diff/1/?file=4455#file4455line332> >> > >> > This DPRINTF is broken (and several others like it)... it needs a >> > trace flag as the first arg, and "%str" probably isn't the format string >> > you want (basically it's just like printf, so you probably mean "%s"). >> >> Nilay Vaish wrote: >> The DPRINTF statements that appear in .sm files are re-written by the >> SLICC compiler. SLICC compiler provides the trace flag. Looking at the >> format specifier, the compiler will add a .c_str() after print_str(). But in >> a comment above, you mentioned that c_str() is not required. May be we can >> drop %str altogether. I need to look in to this. >> >> Steve Reinhardt wrote: >> OK, thanks for the clarification. I missed the SLICC compiler code >> before but I found it now. I have two comments on that: >> - Unless there's a real need to have a different syntax, it would be >> nice to just write the SLICC code as a regular DPRINTF and pass DPRINTF >> calls through unmodified. I'd like to better understand why you think it's >> needed (if you still think it's needed after making the c_str() change). >> - If we do end up needing a DPRINTF replacement with different syntax in >> SLICC, let's call it something other than DPRINTF to make it clear that it >> is different. >> > > DPRINTF() calls will have to be modified since we want to add line number of > the .sm files where the call appears. I think we can maintain the syntax of > DPRINTF() as used in other places.
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? > But in order to combine adjacent DPRINTF() statements, we would need change > to the way DPRINTF() call is processed. As per my understanding, currently > SLICC compiler assumes that only one object / variable would be printed at a > time. I don't understand this... if we just pass the call through verbatim, the SLICC compiler shouldn't care at all, and even if there are minor tweaks, I don't see why it couldn't handle a variable number of arguments. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
