Comment by titzer
15 days ago
You might want to have a look at the unboxing and packing annotations that are proposed for Virgil. The unboxing mechanism is implemented and there was a prototype of the packing mechanism implemented by Bradley for his thesis. I am working on making a more robust implementation that I can land.
https://arxiv.org/abs/2410.11094
I'm not sure I understand your example; if I am looking at it right, it has overlapping bitfields.
But supposing you didn't want overlapping fields, you could write:
type Dang(tom: u11, baz: u16, bar: u5, foo: u5) #packed;
And the compiler would smash the bits together (highest order bits first).
If you wanted more control, you can specify where every bit of every field goes using a bit pattern:
type Dang(tom: u11, baz: u16, bar: u5, foo: u5) #packed 0bTTTTTTTT_TTTbbbbb_bbbbbbbb_bbbzzzzz_????fffff
Where each of T, b, z, and r represent a bit of each respective field.
Overlapping. I have my needs.
I'm curious if some of the bits in your data types are "control bits" that determine what the format of the other bits are. If that's the case, then it sounds like an algebraic data type would be a natural way to express it. If you read the linked paper, algebraic datatypes in Virgil can have different encodings for the cases. As long as the cases are distinguishable via a decision tree, it should be possible to just describe the formats declaratively and have the compiler do all the encoding/decoding/matching.