Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory layout in Zig with formulas

raymondtana.github.io

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Memory layout in Zig with formulas

#21

Post by titzer »

thechao wrote: post #9

I know this is a bit cursed; but, I always wanted a bitfield-on-steroids construct: struct Dang : bits 64 // 64 bits wide, int total { foo : bits 5 @ 0; // 5 bits wide at bit offset 0 bar : bits 5 @ 0; baz : bits 16 @ 4; // 16 bits wide at bit offset 4 tom : bits 11 @ 32; };

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.

Re: Memory layout in Zig with formulas

#22

Post by titzer »

sestep wrote: post #13
thechao wrote: post #9

I know this is a bit cursed; but, I always wanted a bitfield-on-steroids construct: struct Dang : bits 64 // 64 bits wide, int total { foo : bits 5 @ 0; // 5 bits wide at bit offset 0 bar : bits 5 @ 0; baz : bits 16 @ 4; // 16 bits wide at bit offset 4 tom : bits 11 @ 32; };

I think you can do this with Virgil, but I'm having trouble finding the exact doc page at the moment: https://github.com/titzer/virgil

The description is in the paper, but not all of it is implemented.

https://arxiv.org/abs/2410.11094

Bradley implemented a prototype of the packing solver, but it doesn't do the full generality of what is proposed in the paper.

Re: Memory layout in Zig with formulas

#23

Post by a_t48 »

thechao wrote: post #9

I know this is a bit cursed; but, I always wanted a bitfield-on-steroids construct: struct Dang : bits 64 // 64 bits wide, int total { foo : bits 5 @ 0; // 5 bits wide at bit offset 0 bar : bits 5 @ 0; baz : bits 16 @ 4; // 16 bits wide at bit offset 4 tom : bits 11 @ 32; };

It is a bit cursed, but you can do this in C/C++.

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;
        };
    };
The member types don't actually matter here so we can have a little fun and macro it without having to resort to templates to get "correct" types.

    #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();
Highly recommend not doing this in production code. If nothing else, there's no compiler protection against offset+size being > total size, but one could add it with a static assert! (I've done so in the godbolt link)

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

Re: Memory layout in Zig with formulas

#25

Post by repiret »

raymondtana wrote: post #2

I've been learning Zig, and needed a refresher on memory layout (@sizeOf and @alignOf). Wrote this blog post to summarize what I think are the right ways to understand alignment and size for various data types in Zig, just through experimentation. Let me know any and all feedback!

> CPUs fetch data from memory in fixed-size blocks of so-many bytes, and performance degrades when data is misaligned.

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.

Re: Memory layout in Zig with formulas

#26

Post by travisgriggs »

> I imagine just about any computer science major would have learned the rules of memory layout according to some kind of C-like compiler.

I have worked with a number of fresh grads over the last ten years. I can think of one who may have had a good handle on this. At best the rest range from “vague memory recall about this” to a blank stare.

On the flip hand, it’s something someone can pick up pretty quickly if motivated.

Re: Memory layout in Zig with formulas

#27

Post by Joker_vD »

repiret wrote: post #25
raymondtana wrote: post #2

I've been learning Zig, and needed a refresher on memory layout (@sizeOf and @alignOf). Wrote this blog post to summarize what I think are the right ways to understand alignment and size for various data types in Zig, just through experimentation. Let me know any and all feedback!

> CPUs fetch data from memory in fixed-size blocks of so-many bytes, and performance degrades when data is misaligned. 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 su…

It's small, but not unnoticeable... depending on the exact size of the workload and the amount of computation per element. In fact, for huge arrays it may be beneficial to have structs packed if that leads to less memory traffic.

[0] https://jordivillar.com/blog/memory-alignment

[1] https://lemire.me/blog/2012/05/31/data-alignment-for-speed-m...

[2] https://lemire.me/blog/2025/07/14/dot-product-on-misaligned-...

Re: Memory layout in Zig with formulas

#28

Post by zozbot234 »

thechao wrote: post #9

I know this is a bit cursed; but, I always wanted a bitfield-on-steroids construct: struct Dang : bits 64 // 64 bits wide, int total { foo : bits 5 @ 0; // 5 bits wide at bit offset 0 bar : bits 5 @ 0; baz : bits 16 @ 4; // 16 bits wide at bit offset 4 tom : bits 11 @ 32; };

Bitfields are kind of a fake feature because they can't be individually addressed like variables can. So they just turn into inlined getters and setters. Old compilers could not inline arbitrary short functions so bitfields were required as an extra hack, but this is no longer the case today.

Re: Memory layout in Zig with formulas

#29

Post by thechao »

titzer wrote: post #21
thechao wrote: post #9

I know this is a bit cursed; but, I always wanted a bitfield-on-steroids construct: struct Dang : bits 64 // 64 bits wide, int total { foo : bits 5 @ 0; // 5 bits wide at bit offset 0 bar : bits 5 @ 0; baz : bits 16 @ 4; // 16 bits wide at bit offset 4 tom : bits 11 @ 32; };

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 bi…

Overlapping. I have my needs.

Re: Memory layout in Zig with formulas

#30

Post by titzer »

thechao wrote: post #29
titzer wrote: post #21

Earlier quoted context omitted.

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 bi…

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.
Post reply on HN