> I think the current situation is basically historical... the stats names > with underscores were inherited from SimpleScalar, and then we we went with > camelCase for variable names there was an inherent mismatch that has at > times been perpetuated and at other times ignored. True.
> It would be nice to have an official policy and to follow it for new stats, > and also go back and fix up existing stats to be consistent with that > policy. I'm not a big fan of having stats variables be > lower_with_underscores since we already are supposed to be using that to > distinguish local variables from class members (though we're not very > consistent about that either). If there's a desire to make the stats vars > consistent with the stats names, my preference would be to make the stats > names camelCase, but I can see where that could cause a lot of work for > people who have scripts that process stats.txt. I have a slight preference to come up with some way to differentiate state vars from regular member vars. The reason is that people try to use stats like normal vars and are confused when it doesn't work. Perhaps this is no big deal though. Changing names might not be so nice because of scripts, but it'd be nice to get consistent (and do it once.) One inconsistency we also have is that most objects in config files are lower_with_under, and having stat vars match that means that foo.bar_blah.stat_with_under looks a bit better than foo.bar_blah.statCamelCase. One thing I feel strongly about is that stat names and variable names should be valid identifiers in both python and C++. We currently have some stats with :: in them and that's no good. Nate Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
