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

11–20 of 30 posts

Re: Memory layout in Zig with formulas

#11

Post by LexiMax »

peesem wrote: post #8
LexiMax wrote: post #5

Earlier quoted context omitted.

To wit: https://ziglang.org/documentation/master/#extern-struct > An extern struct has in-memory layout matching the C ABI for the target. Zig is really good at speaking the C ABI of the target, but the upshot seems to be that it appears there is no stable Zig-native ABI. If I'm correct, I wonder if there are plans to settle on a stable ABI at some point in the future. I do know that in other languages the lack of a…

Andrew Kelley has said relatively recently that there are no plans to introduce a Zig ABI: https://github.com/ziglang/zig/issues/3786#issuecomment-2646...

What's interesting is that the scope of the proposal isn't a Zig-specific ABI, but a codified way of expressing certain Zig concepts using the existing C ABI.

That could be an interesting middle ground.

Re: Memory layout in Zig with formulas

#12

Post by dnautics »

rvrb wrote: post #4
dnautics wrote: post #3

Earlier quoted context omitted.

i could be wrong but i believe the zig compiler reserves the right to lay things out differently depending on compilation mode? especially debug. unless it's extern or packed, in which case the layout will be defined.

`extern` and `packed` container types have well defined layouts. a regular `struct` is an "auto" layout - and the compiler can and will rearrange whenever it wants. if you need a well defined layout, use `extern`. if your struct makes sense to represent as an integer, use `packed`. I think it is often ill advisable to use `packed` otherwise. you can explore this yourself on the Type info returned from @TypeInfo(T): h…

in practice, as long as you match the version and release mode, it's fine (though you are playing with fire). I pass raw pointers to zig structs/unions/etc from the zig compiler into a dynamically loaded .so file (via dlload) and as long as my .so file is compiled with the same compiler as the parent (both LLVM, in my case) it's peachy keen.

Re: Memory layout in Zig with formulas

#13

Post by sestep »

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

Re: Memory layout in Zig with formulas

#14

Post by Lvl999Noob »

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; };

Are you saying you want foo and bar to completely overlap? And baz and foo / bar to partially overlap? And have lots of unused bits in there too?

Re: Memory layout in Zig with formulas

#15

Post by Cloudef »

LexiMax wrote: post #11
peesem wrote: post #8

Earlier quoted context omitted.

Andrew Kelley has said relatively recently that there are no plans to introduce a Zig ABI: https://github.com/ziglang/zig/issues/3786#issuecomment-2646...

What's interesting is that the scope of the proposal isn't a Zig-specific ABI, but a codified way of expressing certain Zig concepts using the existing C ABI. That could be an interesting middle ground.

Yeah the new translate-c package already kind of does that.

Re: Memory layout in Zig with formulas

#16

Post by Cloudef »

dnautics wrote: post #12
rvrb wrote: post #4

Earlier quoted context omitted.

`extern` and `packed` container types have well defined layouts. a regular `struct` is an "auto" layout - and the compiler can and will rearrange whenever it wants. if you need a well defined layout, use `extern`. if your struct makes sense to represent as an integer, use `packed`. I think it is often ill advisable to use `packed` otherwise. you can explore this yourself on the Type info returned from @TypeInfo(T): h…

in practice, as long as you match the version and release mode, it's fine (though you are playing with fire). I pass raw pointers to zig structs/unions/etc from the zig compiler into a dynamically loaded .so file (via dlload) and as long as my .so file is compiled with the same compiler as the parent (both LLVM, in my case) it's peachy keen.

You are still playing with fire as the data inside those pointers may be different even if they are the same type. Zig is free to optimize them in anyway it likes depending on the code that touches them (aka its free to assume they never leave the program).

Re: Memory layout in Zig with formulas

#18

Post by [deleted] »

_bohm wrote: post #10
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 can kinda do this with Zig’s packed structs and arbitrary-width integers

[deleted]

Re: Memory layout in Zig with formulas

#19

Post by bsder »

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; };

Look at Erlang bit syntax: https://www.erlang.org/doc/system/bit_syntax.html

It can even be used for pattern matching.

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

Re: Memory layout in Zig with formulas

#20

Post by metaltyphoon »

Lvl999Noob wrote: post #14
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; };

Are you saying you want foo and bar to completely overlap? And baz and foo / bar to partially overlap? And have lots of unused bits in there too?

C# can do this with structs. Its kind of very nice to unpack wire data.
Post reply on HN