Zig's new bitCast semantics and LLVM back end improvements

Post by imtringued » Fri, Jun 26, 2026, 10:06 AM UTC

audunw wrote: post #112

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…

I may be damaged from working on IC hardware design and various weird architectures, but I truly can’t comprehend why you’d think this doesn’t make sense. Yeah, if your architecture doesn’t support 24-bit int it maps to 32-bits. But it also declares that the numbers you’re storing should never be larger than 2^24. It’s about type safety, and also run time checks in safe mode I believe. Bitcasting three bytes to a 24-…

Post by teo_zero » Fri, Jun 26, 2026, 10:27 AM UTC

mlugg wrote: post #125

teo_zero wrote: post #121

Can I convert a 300-byte message to Base64 with a single instruction? Like: in: [300]u8; out: [800]u3; out = @bitCast(in);

`u3` would be base 8, i.e. octal---I think you meant to use `[400]u6`? Aside from that: I'm not familiar with how standard base64 deals with endianness, so I'm not sure if it would match that, but this `@bitCast` would certainly give you a base64 encoding. But it would probably emit pretty terrible code to do that---our lowering of `@bitCast` isn't really optimized for moving around huge amounts of data in one operat…

Post by rllj » Fri, Jun 26, 2026, 1:56 PM UTC

tialaramex wrote: post #80

dnautics wrote: post #78

Earlier quoted context omitted.

@intCast

So, since I don't write Zig I had to go look this up, to save anyone else the bother this is what Rust would call an 'as' cast or C programmers might think of as a value cast, it's going to try to make a value which has a similar meaning but of another type, which may be arbitrarily expensive. What people often want here is a transmute, Rust's core::mem::transmute which changes nothing about the bits except what thos…

Post by echelon » Fri, Jun 26, 2026, 2:09 PM UTC

miki123211 wrote: post #127

rogerallen wrote: post #79

Earlier quoted context omitted.

Same as it ever was.

yeah, remember those newfangled fancy Node.js guys who would just copy/paste from Stackoverflow without any understanding? Or the Java guys who wrote bloated apps that wasted CPU cycles on garbage collection instead of writing in C++, like God intended? Or the Fortran / Cobol guys who wrote in those God-damned, wasteful, useless high-level languages, instead of using assembly, like a proper programmer should?

Post by hrydgard » Fri, Jun 26, 2026, 3:04 PM UTC

ulbu wrote: post #55

allthetime wrote: post #41

Earlier quoted context omitted.

Zig is already great for this with ‘packed struct’ and arbitrary size ints. Allows for very clean protocol creation between systems with known properties. This is another great step in that direction.

you need different packed structs for little- and big-endian data. and casting with little-endian data is a nightmare - you need to reverse-cascade your struct fields to be in accordance with the little-endian bit-pattern. (or have a comptime function that does it for you, of course. but then you lose all declarations for the struct). what should be a simple writing down of a protocol is now a pedantic and error-pron…