On Thu, Sep 21, 2017 at 10:20 AM, Andreas Sandberg <[email protected]
> wrote:
> Hi Gabe,
>
> I think this is very good idea. When I refactored the checkpoint
> interfaces to make the hierarchy explicit, I had this sort of use case
> in mind.
>
> Before getting busy, could you write up a proposal for the new
> checkpoint format? There are a few things related to how we represent
> data that we need to think about.
>
I suppose I'd assumed since there was already a config.json this had been
largely hammered out, but I guess not necessarily?
>
> 1. How do we represent values in serialised objects? Do we need some
> mechanism to describe the type? Type is currently implicit, but we could
> make it an explicit part of the format in the future. For example:
>
> # Attribute
> "size": {
> "@type": "@scalar",
> "value": 4
> },
>
> # Attribute
> "pio": {
> "@type": "@port_ref",
> "value": "system.physmem.master",
> },
>
> # SimObject
> "disk": {
> "@type": "DiskImage",
> "image_file" : {
> "@type": "@string",
> "value": "foo"
> }
> },
>
I don't think we'd need this for scalar values for sure, since those are
already roughly binned into strings, floats, and integers. I think within
those, it's reasonable to leave the exact interpretation up to the
consumer, ie 32 vs 64 bit ints, etc. As far as SimObjects, for similar
reasons I'm thinking the sort of duck typing we've got might be fine, since
it leaves wiggle room to change what types are called for instance. On the
other hand I see the potential value as well, so I'm not sure there. Maybe
we could leave out types for now, but optionally include them in the
future? Using your example syntax above, there would be no problem if they
were optional but not present, or present but not consumed.
>
> 2. How do we distinguish between attributes/params and child objects? Do
> we need some sort of naming convention / prefix for attributes to avoid
> clashes between object names and attributes?
>
Could you give an example of where that conflict might happen? I agree it's
worth addressing if it can happen, but I'm not seeing where that would crop
up. I might just be missing it.
>
> 3. How do we handle large structures? For example, the display FIFO is
> ~2KiB and is serialised as a vector of integers. Similarly, the vector
> register file can be very large. Do we need a mechanism to store binary
> data in separate files? We could potentially remove the slightly ad-hoc
> mechanism we use to serialise memories if we get this right.
>
That's not a bad idea, although it could also be done after the conversion
to json by, for instance, hiding it in the macros which load the values
from the checkpoint. There could be a special flag value or specially
formatted value setting which means "this is in that file over there" which
could be added at some point.
>
> Cheers,
> Andreas
>
>
> On 19/09/2017 00:25, Gabe Black wrote:
>
>> Hi folks. I know I've proposed a lot of things I haven't sent any patches
>> for yet, but here's one more. I recently debugged a problem where some
>> names had changed from the system a checkpoint was taken from and the one
>> it was loaded into. This left some objects uninitialized, and the
>> simulation didn't work. What I'd like to do is print some sort of warning
>> if there are unconsumed sections in the checkpoint (I think generally
>> checkpoints go from less to more or equal levels of complexity). It looks
>> like there's some very vestigial support for this sort of thing in the ini
>> parser code, but the only thing that used it was removed from the code
>> base
>> sometime back in I think 2006.
>>
>> While digging around, it occurred to me how fairly crusty the old INI
>> support is, and how it would be nice to simplify/streamline the checkpoint
>> and config system and move it over to something which is truly
>> hierarchical
>> like json. I found that we're already outputting a config.json, so that
>> will bring us a lot of the way there all on its own.
>>
>> One complication with this approach is that C++ doesn't have a built in
>> mechanism to parse json files. In some other work we've been doing, this
>> library seems to be doing the job pretty well.
>>
>> https://github.com/open-source-parsers/jsoncpp
>>
>> Would anybody object strongly if I went made this a dependency and
>> retrofitted things which produce/consume INI files to use json files
>> instead?
>>
>> Gabe
>> _______________________________________________
>> gem5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/gem5-dev
>>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
