My initial reaction to Gabe's email is that I'd rather go the other way, and make SERIALIZE_SCALAR() look more like paramOut() than the other way around. I don't generally like preprocessor macros, but in this case the convenience of not having to type the variable name twice justified it. I don't like the implicit 'os' parameter that SERIALIZE_SCALAR() requires.
Just brainstorming, but maybe we could create a macro like #define VAR(x) #x, x then get rid of most or all of the SERIALIZE_* and UNSERIALIZE_* macros because you could just write: paramOut(os, VAR(foo)) and paramIn(os, VAR(foo)) etc. If we do do this, I agree that VAR() is a crappy name, but I couldn't come up with anything better in five seconds. I sympathize with Joel's point about compatibility, but 90% of the vars have the same name in the checkpoint and I don't want the redundancy of saying things twice. I think the answer there is not to change the infrastructure but just to be more sensitive in the review process and not just let patches go through that rename serialized vars, but instead insist that in those cases the patch should explicitly use paramOut/paramIn to allow the var name to change but leave the serialization name unchanged where that makes sense. Steve On Fri, Jan 21, 2011 at 10:55 AM, Joel Hestness <hestn...@cs.utexas.edu>wrote: > I like this idea a lot. Not only would it solve the SERIALIZE_* v. > paramOut usage problem, but it would also decouple the code variable name > from the name written to the checkpoint. If used intelligently, this could > alleviate some of the pain of fixing old checkpoints when code changes. > > Joel > > > On Fri, Jan 21, 2011 at 12:57 AM, Gabe Black <gbl...@eecs.umich.edu>wrote: > >> From time to time It seems to be that we need to serialize something >> but call it something other than its variable name. Would it make sense >> to add SERIALIZE_*_AS macros that take a name argument as well? It's not >> that hard to create a temporary variable or use those param functions >> directly, but it would at least make things look more consistent to >> always (or almost always) use SERIALIZE_FOO. >> >> Gabe >> >> On 01/20/11 22:11, Steve Reinhardt wrote: >> > changeset 494b5426e70d in /z/repo/m5 >> > details: http://repo.m5sim.org/m5?cmd=changeset;node=494b5426e70d >> > description: >> > checkpointing: fix bug from curTick accessor conversion. >> > >> > Regex replacement of curTick with curTick() accidentally >> > changed checkpoint key string for serialization but not >> > for unserialization. >> > >> > diffstat: >> > >> > src/sim/serialize.cc | 2 +- >> > 1 files changed, 1 insertions(+), 1 deletions(-) >> > >> > diffs (12 lines): >> > >> > diff -r f84bfd45d607 -r 494b5426e70d src/sim/serialize.cc >> > --- a/src/sim/serialize.cc Wed Jan 19 16:22:23 2011 -0800 >> > +++ b/src/sim/serialize.cc Thu Jan 20 22:13:33 2011 -0800 >> > @@ -400,7 +400,7 @@ >> > Globals::serialize(ostream &os) >> > { >> > nameOut(os); >> > - SERIALIZE_SCALAR(curTick()); >> > + paramOut(os, "curTick", curTick()); >> > >> > nameOut(os, "MainEventQueue"); >> > mainEventQueue.serialize(os); >> > _______________________________________________ >> > m5-dev mailing list >> > m5-dev@m5sim.org >> > http://m5sim.org/mailman/listinfo/m5-dev >> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > > > > -- > Joel Hestness > PhD Student, Computer Architecture > Dept. of Computer Science, University of Texas - Austin > http://www.cs.utexas.edu/~hestness > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
