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

[David Savinkoff <dsavnkff@xxxxxxxxx>]

----- Nicolas Pomarède wrote:
> Le 09/05/2015 23:03, Nicolas Pomarède a écrit :
> > Le 09/05/2015 21:04, David Savinkoff a écrit :
> >> ----- 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.
> >>
> >
> > Hi
> >
> > I thought also about adding the variable's name to each saved variable,
> > but I'm not sure it's really necessary, if we save/restore variables
> > always in the same order and we add new variables at the end of the
> > existing component, then knowing the name of the variable is not
> > necessary IMO.
> 
> I saw that for component n you wrote "maybe the variable name", but in 
> my idea a component would be the complete set of variables used by an HW 
> chip for example (video, fdc, cpu, ym, ...)
> 

I wrote "maybe the variable name" because I think the 'id' field should be
a descriptive text string associated with the data it represents.

I thought more about floating point variables. Maybe they should be
formatted with fprintf and stored as a text string also. Maybe the complete
memory snapshot file should be a text file (alphabetically sorted also).

The memory snapshot file should not have an implicit structure where
arbitrary structures are used in the current-to-be-obsolete save-order.

The memory snapshot file is compressed, thus it doesn't need to have
an old fashioned 'move multiple registers to stack frame' look to it.

A general purpose Memory Snapshot file would have the machine state
saved in an insightful manner considering future uses.

There should be discussion on this matter so that a specification is in
place before the code.