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

[David Savinkoff <dsavnkff@xxxxxxxxx>]

----- Nicolas Pomarède wrote:
> 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..
> 
> Hi
> 
> 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
> 

Here are a few more suggestions:

  - component n id (maybe the variable name as text)
  - component n size (size of the data type)
  - component n nmemb (number or elements -- see: $man fread)
  - component n data

MemorySnapShot_Store(&Control, sizeof( Control ));
would become:
MemorySnapShot_Store("Control", sizeof( Control ), nmemb, &Control);

This format would allow the format to be endian independent because
the file would be written as bytes (byte file access will never go away).

The snapshot file can even be alphabetically insertion-sorted (quicksort)
as it is made so that it can be quickly parsed for collisions, errors etc.

Saving structures with different data types will require the "name"
text to identify each element. This doesn't have to cause problems
with an alphabetically sorted list, as the full path can be given.


> 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.
> 
> Nicolas
> 
> 
> 
>