On Fri, Jan 21, 2011 at 11:33 AM, nathan binkert wrote:
> We had discussed changing serialization so that there was a serializer
> class and paramOut/paramIn were methods of that class (getting rid of
> the os parameter for ParamOut and the cp and section parameters of
> param in). [...]
>
Agre
> 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
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'
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
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
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 serializat
