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

Zig's new bitCast semantics and LLVM back end improvements

ziglang.org

Post reply on HN
Print view View original

11–20 of 159 posts

Re: Zig's new bitCast semantics and LLVM back end improvements

#11

Post by tialaramex »

ozgrakkurt wrote: post #9

> Consider, for instance, bitcasting a [2]u8 to a u16. Under the old semantics, the result of this operation depends on the target endian: on big-endian targets, the first array element became the 8 most significant bits, whereas on little-endian targets, the first array element became the 8 least significant bits. Under the new semantics, because we only care about logical bit representation (which is endian-agnosti…

> This is a huge mistake. You would never expect something like bitCast to do this.

Is there at least some sort of @transmute or something ? If Zig wants to say "bitCast" means this odd operation, but provides the thing most people actually want under some plausible name that's just an extra thing to learn which seems OK.

Re: Zig's new bitCast semantics and LLVM back end improvements

#12

Post by hmry »

NooneAtAll3 wrote: post #10
y1n0 wrote: post #6

Earlier quoted context omitted.

As an fpga engineer dealing with bitwidths that are non-byte multiples is very normal and when I end up writing software for various reasons, I often miss it. Usually when trying to slice and parse or construct messages. Obviously there are ways around pretty much everything, but it’s nice to have first class language support for bit slices.

except it isn't bit slice, it isn't indexing within a range - it's just integer type that only allows values up to 2^width, with same alignment rounding up as with the rest

It's a bit slice if you put it in a packed struct.

I like them, they're nicer than C's bitfields: The order isn't implementation-defined, and the types remember their range rather than being converted to a power-of-two size upon read. (Maybe that's possible with C23 _BitInt(n), I haven't tried if those work in bitfields)

Re: Zig's new bitCast semantics and LLVM back end improvements

#13

Post by [deleted] »

frail_figure wrote: post #7
grayhatter wrote: post #2

> Quite long devlog coming up, apologies—I got a little carried away with this one! mlugg, please don't apologize for creating something I actually want to read. I'm drowning in low effort garbage, the in depth technical explanation is a refreshing breath of fresh air. Might as well apologize for creating a language without a garbage collector, sure most people are unwilling to think, but some of us like nice things…

[flagged]

[deleted]

Re: Zig's new bitCast semantics and LLVM back end improvements

#14

Post by grayhatter »

frail_figure wrote: post #7
grayhatter wrote: post #2

> Quite long devlog coming up, apologies—I got a little carried away with this one! mlugg, please don't apologize for creating something I actually want to read. I'm drowning in low effort garbage, the in depth technical explanation is a refreshing breath of fresh air. Might as well apologize for creating a language without a garbage collector, sure most people are unwilling to think, but some of us like nice things…

[flagged]

??

Re: Zig's new bitCast semantics and LLVM back end improvements

#15

Post by nvme0n1p1 »

ozgrakkurt wrote: post #9

> Consider, for instance, bitcasting a [2]u8 to a u16. Under the old semantics, the result of this operation depends on the target endian: on big-endian targets, the first array element became the 8 most significant bits, whereas on little-endian targets, the first array element became the 8 least significant bits. Under the new semantics, because we only care about logical bit representation (which is endian-agnosti…

You don't need to use @bitCast for the behavior you're talking about. @ptrCast still exists.

Re: Zig's new bitCast semantics and LLVM back end improvements

#17

Post by nvme0n1p1 »

hansvm wrote: post #8
simonask wrote: post #4

Interesting read, even as someone who isn't using Zig. I wonder, these arbitrary-width integers... Is it actually even really worth it? My intuition is to prefer manually packing/unpacking things instead (in any language, even C that has bit width for struct fields), because it gives me a better mental picture of the code that is actually generated. Particularly for something like an signed odd-bit integer - what kin…

IIRC, for "normal" bit widths the codegen basically uses the next larger machine type and preserves zero bits on the high end. An i3 is an i8 with five MSB zeroes (with more custom behavior for "packed" i3 values). It's UB to fill those with non-zero values. For larger bit widths, like u729, you concatenate many large machine types, the compiler generates instructions in an unrolled loop, and the LLVM optimization pa…

I can't imagine any situation where I'd use a u729 instead of a StaticBitSet. For size 729, it would end up backed by a bit_set.Array, not a bit_set.Integer.

https://ziglang.org/documentation/master/std/#std.bit_set.St...

Re: Zig's new bitCast semantics and LLVM back end improvements

#18

Post by mlugg »

grayhatter wrote: post #2

> Quite long devlog coming up, apologies—I got a little carried away with this one! mlugg, please don't apologize for creating something I actually want to read. I'm drowning in low effort garbage, the in depth technical explanation is a refreshing breath of fresh air. Might as well apologize for creating a language without a garbage collector, sure most people are unwilling to think, but some of us like nice things…

I appreciate the kind words :)

Re: Zig's new bitCast semantics and LLVM back end improvements

#19

Post by epolanski »

OT: I'm always surprised at how popular Zig discussions get here, or Youtube and other medias.

Don't get me wrong, I love Zig and I think it's a great C replacement, but I'm very confused on why C3 or Odin rarely get any attention at all, despite being in the same C-replacement crowd.

But still surprised at what Zig does better than these other projects? Is Andrew much better at marketing/promoting the language? He's very hard to dislike.

Re: Zig's new bitCast semantics and LLVM back end improvements

#20

Post by hansvm »

nvme0n1p1 wrote: post #17
hansvm wrote: post #8

Earlier quoted context omitted.

IIRC, for "normal" bit widths the codegen basically uses the next larger machine type and preserves zero bits on the high end. An i3 is an i8 with five MSB zeroes (with more custom behavior for "packed" i3 values). It's UB to fill those with non-zero values. For larger bit widths, like u729, you concatenate many large machine types, the compiler generates instructions in an unrolled loop, and the LLVM optimization pa…

I can't imagine any situation where I'd use a u729 instead of a StaticBitSet. For size 729, it would end up backed by a bit_set.Array, not a bit_set.Integer. https://ziglang.org/documentation/master/std/#std.bit_set.St...

Old habits :)

If I had to steel-man the idea, I'm pretty sure the integer-based solution has better codegen with many kinds of sparse, comptime-known masks. I think you're right though, StaticBitSet looks better.

Post reply on HN