> 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.
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). The goal was to eventually get away from serializing directly to an ostream, and instead allow something more intelligent (like serializing into a map or into python directly and then dumping whatever format afterwards maybe XML is better? :P, also this would allow sub objects and stuff like that). That said, if anyone is going to make a bunch of changes to how serialization is done across the whole codebase, I'd like to at least get a serializer in that does exactly what we do now so that we can reduce the number of across the board changes yet still enable forward compatibility with future serialization mechanisms. > 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. For this thing, I worry that picking a #define that is too short will risk a name collision. There is a trick we can play with variadic macros: #define SERIALIZE_SCALAR(x, ...) serializer.ParamOut(x, #x, __VA_ARGS__) Then we have two versions of ParamOut. The two argument version where the second argument is the name, and the three argument version where the third argument is the name and the second argument is ignored. (Disgusting, I know). All that said, if we can come up with a more generalized name for VAR that can be used anywhere that this comes up (since this is certainly not the only place this happens). I'm not at all opposed to that. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
