|Re: [hatari-devel] memory snapshot format/issues|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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.