Memory layout in Zig with formulas

A memory bus supports memory transactions of various sizes, with the largest size supported being a function of how many data lines there are. The following two statements are true of every memory bus with which I'm familiar, and I probably every bus in popular use: (1) only power-of-two sizes are supported; (2) only aligned transactions are supported.

Arm, x86, and RISC-V are relatively unique among the multitude of CPU architectures in that if they are asked to make an unaligned memory transaction, they will compose that transaction from multiple aligned transactions. Or maybe service it in cache and it never has to hit a memory bus.

Most CPU architectures, including PPC, MIPS, Sparc, and ColdFire/68k, will raise an exception when asked to perform a misaligned memory transaction.

The tradition of aligning data originated when in popular CPU architectures, if you couldn't assume that data was aligned, you would need to use many CPU instructions to simulate misalinged access in software. It continued in compilers for Arm and x86 because even though those CPUs could make multiple bus transactions in response to a single mis-aligned memory read, that takes time and so it was much slower.

I don't know for sure, but I would expect that on modern x86 and high performance Arm, the performance penalty is quite small, if there's any at all.

https://godbolt.org/z/vPKEdnjan

    union Dang
    {   
        uint64_t : 64; // set total width
        uint8_t foo : 5;
        uint8_t bar : 5;
        struct __attribute__((packed)) {
            uint8_t : 4;
            uint16_t baz : 16;
        };
        struct __attribute__((packed)) {
            uint32_t : 32;
            uint16_t tom : 11;
        };
    };

    #define OFFSET_BITFIELD_DECLARE(NAME, SIZE) \
        union NAME { \
            uint64_t : SIZE

    #define BITFIELD_MEMBER(NAME, SIZE, OFFSET) \
        struct __attribute__((packed)) { \
            uint64_t : OFFSET; \
            uint64_t NAME : SIZE; \
        }

    #define OFFSET_BITFIELD_END() }

    OFFSET_BITFIELD_DECLARE(Dang, 64);
        BITFIELD_MEMBER(foo, 5, 0);
        BITFIELD_MEMBER(bar, 5, 0);
        BITFIELD_MEMBER(baz, 16, 4);
        BITFIELD_MEMBER(tom, 11, 32);
    OFFSET_BITFIELD_END();

Edit: if you're talking about Zig, sorry!

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;

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

It can even be used for pattern matching.

I don't know whether Gleam or Elixir inherited it.