Steve and I have solved the bug. The solution fixes the MC146818 unserialize function and adds ISA serialize and unserialize function calls to simple_thread.cc.
I'll push the patch momentarily. Brad -----Original Message----- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of nathan binkert Sent: Wednesday, October 14, 2009 8:02 PM To: M5 Developer List Subject: Re: [m5-dev] Possible Bug in MC146818 > The logic there isn't really needed, but you'll need to either assign > txEvent.when() to a local variable for the SERIALIZE_SCALAR() macro to > work right. You can use paramOut/In manually. > > Was there some reason that we just don't serialize the event directly? > Event has serialize/unserialize methods. However if you have more than > one event in an object there is probably a name issue. We kinda want a > SERIALIZE_SUBOBJECT() method which swizzles the naming. It's the name thing. If you look at the EtherPacket and PacketFifo, I do a subobject hack. What would actually be a lot better would be to have a SerializationContext object and pass that in instead of just the raw stream. Then we could provide some virtual functions in there. I hate to say it, but having hierarchy a la XML would be another way to make life better. There's no way to serialize a sub object without prefixing its variable names with something. If there were a way to nest, it would work better. Actually, come to think of it, life would be way better if we just used a dict of dicts and then wrote it out instead of just directly writing to the stream. Some of these things would actually be pretty easy to do. Nate _______________________________________________ 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
