I see. When I suggested to Nilay to implement the print functions and remove the operator<< functions, I was using M5's pkt print statements as loose inspiration. I should have been more thorough in my investigation because I know realize that there are a few M5 base objects that do the operator<< overloading. Fortunately, it should be pretty easy for Nilay to change his current print functions to operator<< ccprintf functions.
Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Reinhardt Sent: 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 <[email protected]> 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 keep that behavior then overloading >> operator<< is the way to do it. > > Gabe is adding a PC type though and I believe he's overloading > operator<<. I generally think that this is a pretty nice thing to do. > It's more or less analagous to implementing __str__ in python which > is a pretty nice thing to have, so I'd say that Ruby is pushing a good > idea into M5. Yea, I didn't mean to imply that M5's way was better, just that Brad's observation of Ruby's inconsistency with M5 was maybe focused on a symptom and not on the cause. There probably are places where M5's debug output could be improved by using operator<<, for example it would be nice to standardize on whether we print 0x in front of addresses in cache traces. Ruby's practice of always printing both the byte address and the block address is also interesting, though personally I find that pretty redundant and I've become practiced at creating regexes that can capture all the byte addresses within a block so it's pretty easy to egrep out the trace entries that relate to a particular block. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
