Compact CBOR Example

[JohnAZoidberg]

Based on #12

---

Here's a very compact version of #8. It uses positioning in lists, instead of dictionaries with keys, which are very efficient in CBOR. Total size is now 156 bytes.

Includes an example C program to parse the CBOR and dump some information about it.

I still haven't fully used the capabilities of CBOR and CDDL, so I might be able to compact it a little further, while making it easier to write. We certainly wouldn't want to write this JSON by hand, but rather use a templating language on top.

TODO

• [x] Eliminate string keys from CBOR
• [ ] Represent e.g. bitfields more compactly
• [ ] Use something nicer than JSON as the input format (e.g. Dhall, JSON5, Jsonnet, ...)
• [ ] Compare with protobuf
• [ ] Check how future-proof this is

Output of test.sh

- Remove generated instance.cbor
- Generate example instance.json from spec.cddl as random-instance.json
- Validate instance.json
- Convert instance.json to instance.cbor
- Dump instance.cbor as hex in instance.cbor.hex
- Compile CBOR parsing tool
- Parse CBOR and dump some information:
5 hart configs present
Harts: 0        have 1 different configuration types
Harts: 1 to 4   have 1 different configuration types
Harts: 0, 2, 4  have 2 different configuration types
Harts: 1, 3     have 2 different configuration types
Harts: 1, 4     have 1 different configuration types

[timsifive]

Cool!

I didn't take the time to look into detail, but I'm excited about the size, although obviously some additional tooling would be required on top. One option is to modify the code I have and have it generate compact JSON from the coarse JSON.

One question: Is it possible for a parser that doesn't know the full CDDL to ignore parts of the binary format that it doesn't know about?

[JohnAZoidberg]

One question: Is it possible for a parser that doesn't know the full CDDL to ignore parts of the binary format that it doesn't know about?

Yes, that's part of what CBOR is designed for. You don't need a schema to fully parse it. CDDL is completely optional but if we didn't have it, we'd have to tell people in some other way how to interpret it. Just like people use OpenAPI/Swagger for JSON APIs.

[timsifive]

If we build a language on top, does that mean we should also generate the CDDL from the language on top? It should be easy for task groups to specify what/how their data must be encoded.

[JohnAZoidberg]

That's one option if we use a typed language like Dhall or json5 with schema. I don't think any tools for that exist yet. But it would be possible with pure Dhall I think, even.

Otherwise we could use CDDL for validating the JSON or CBOR that's generated from the input format. There are tools that can do exactly that.

Or we could even have two separate schemas. Since we can translate from human to binary automatically and check both of them automatically, I think that could also be a viable option.