Re: [hatari-devel] memory snapshot format/issues

[ Thread Index | Date Index | More Archives ]

Le 09/05/2015 00:50, Steven Noonan a écrit :
AFAIK it's primarily meant for snapshots that are used by
the same binary, e.g. when you're actively debugging things.
It's not meant as something portable.

I understand. It's a fair first pass at snapshotting, but it is fragile.


I'm not satisfied too with current snapshot, it's not flexible enough.

IIRC I posted about this some months ago, with the idea of splitting every component in it's own structure, doing a kind of linked list :

 - component 1 id
 - component 1 size
 - component 1 data
 - component n id
 - component n size
 - component n data

This way, an Hatari version would load eveything but would ignore components with an unknown id or a different size that what is expected.

So, if a newer hatari version add a new component, the snapshot could still be loaded by an older version.

Also if we add more data in an existing component, we should add them at the end of the existing data, so an older version would still be able to read its data and would then skip to the next component (using "size"), ignoring the new data.

This implies that saving/restoring structure as a whole, which is very convenient, would not be used anymore, we would save every member one by one.

When saving every variable, we can also ensure that 16 bit and 32 bit ints are always saved by writing 2 bytes or 4 bytes in a OS/CPU independant way (little endian for example), so the same snapshot would be usable on big/little endian cpu.

But I'm not sure we have time to do this before next release as it would imply lots of rewrite and test to do, better for the next one.


Mail converted by MHonArc 2.6.19+