Interesting.  I'd click ship it, but it seems that maybe a little bit more thought on how we can make the checkpoint version number stuff actually work in practice would be good.  

src/sim/root.cc (Diff revision 1)

Since this is only ever used here, you could simply do this and avoid the change to config/the_isa.hh:

#define __STRINGIFY(X) #X
std::string isa = __STRINGIFY(TheISA);
#undef __STRINGIFY

Show all issues

1. Ali Saidi May 30, 2012, 3:27 a.m. (May 30, 2012, 3:27 a.m.)

   I'm happy to change this, but it seems like trading a auto-generated value which doesn't hurt anything but is everywhere for a bit if isolated ugliness. I guess I lean slightly toward the way it's currently done. 

src/sim/serialize.hh (Diff revision 1)

It seems that this could easily get out of sync.   Any ideas how to prevent that from happening?  Be cool if we could somehow hash the various checkpoint functions.  Should we do the versioning on a per-object basis?  That way a change in one isa wouldn't affect another, and it might be more likely that someone notices the need to update the version number for an object checkpoint.

Show all issues

1. Ali Saidi May 30, 2012, 3:27 a.m. (May 30, 2012, 3:27 a.m.)

   I think that that is more complicated than needed. If a certain revision doesn't need any changes the code as written will just skip it. I think the only way that people are going to notice is with a checkpoint regression. While the restoring is a bit hard to do with our framework, the actually generation of the m5.cpt file shouldn't be too bad. 
   
   

Ship It!