On Fri, Jan 21, 2011 at 11:33 AM, nathan binkert <[email protected]> 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). [...] > Agreed, there's plenty of other room for improvement in serialization and it may make sense to fold some other steps in that direction into this kind of change. I was trying to ignore that for now and just focus on the issue that kicked off the discussion. > > 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. Agree here too, that's one of the main things that makes it a crappy name. > 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). > I was thinking that something could be done with variadic macros, but didn't go so far as to come up with a concrete solution... perhaps my tolerance is lower so I just got revolted by the idea sooner than Nate did :-). I would still like to have something where the two forms look more similar; the nice thing about the VAR() approach is that it's clear you're calling the same function and just taking a shortcut on providing the name. > 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. > Yea, I really like the idea of getting rid of *all* the different (UN)SERIALIZE_* macros and replacing them with a single mechanism. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
