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.
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"
}
},
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?
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.
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
