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

51–60 of 159 posts

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

#51

Post by nvme0n1p1 »

ozgrakkurt wrote: post #43
nvme0n1p1 wrote: post #15

Earlier quoted context omitted.

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

@ptrCast, > Converts a pointer of one type to a pointer of another type. [1] [1] https://ziglang.org/documentation/master/#toc-ptrCast So it is not the same. You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic instead of using @mempcy for everything

Take the address and deref afterwards, and it's exactly the same. Or to say another way: if you want bits to be reinterpreted raw as if they're in memory, then... put them in memory, then reinterpret them.

> You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic

Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast.

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

#52

Post by ozgrakkurt »

jjmarr wrote: post #27
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…

> Just don't allow casting to u24, as it makes no sense unless you define u24 to be u32 sized as I think c standard does. The reason u32->u24 casting must be well defined is because some hardware (e.g. many GPUs, microcontrollers) only have floating point multipliers. A 24 bit unsigned integer (stored in a 32 bit register) can be losslessly converted to a 32 bit float by the hardware, multiplied, then converted back.…

I am criticizing the part where they allowed [3]u8 to u24 bitCast in the first place. It doesn't make sense logically as u24 is likely not 24 bits in any targets let alone portably on every target.

Interpreting u24 like it is actually 24 bits sounds like programming in crazy land since it is not 24 bits in any relevant architecture afaik.

They didn't allow []u24 with a similar rationale as far as I can remember. I agree with this as someone programming at this level should be able to understand there is no real u24 layout and they should use []u32. Going with the same magical rational they went with here, compiler should generate unaligned u24 loading code when you use []u24 since it is "logically 24 bits"

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

#54

Post by ozgrakkurt »

nvme0n1p1 wrote: post #51
ozgrakkurt wrote: post #43

Earlier quoted context omitted.

@ptrCast, > Converts a pointer of one type to a pointer of another type. [1] [1] https://ziglang.org/documentation/master/#toc-ptrCast So it is not the same. You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic instead of using @mempcy for everything

Take the address and deref afterwards, and it's exactly the same. Or to say another way: if you want bits to be reinterpreted raw as if they're in memory, then... put them in memory, then reinterpret them. > You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic Yes, and this is one reason @bitCast was changed to have different semantics that are not…

> Take the address and deref afterwards, and it's exactly the same.

It is significantly worse to take address and deref afterwards.

You have to do something like:

@as(const u32, @ptrCast(&x)).

instead of just

@bitCast(x)

> Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast.

This makes sense except breaking existing code that properly handled endianness by doing a conditional @byteSwap. And what you end up with is a more complicated intrinsic compared to something that reinterprets values with same layout size

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

#55

Post by ulbu »

allthetime wrote: post #41
zamadatix wrote: post #16

This change + the existing packed struct logic will be great for working with bit packed binary headers w/o having to manually twiddle so much about the bit handling along the way.

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-prone ordeal.

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

#56

Post by grayhatter »

ryan_n wrote: post #39
grayhatter wrote: post #14

Earlier quoted context omitted.

??

Think theyre just implying that the quoted text comes off as a bit pretentious..

oh, I think it's mostly frustration over how eager everyone is to delegate their thinking to literally anything else, accelerated by [gestures at reality]. Is frustration with apathy really pretentious?

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

#57

Post by jmalicki »

mathisfun123 wrote: post #47
jjmarr wrote: post #27

Earlier quoted context omitted.

> Just don't allow casting to u24, as it makes no sense unless you define u24 to be u32 sized as I think c standard does. The reason u32->u24 casting must be well defined is because some hardware (e.g. many GPUs, microcontrollers) only have floating point multipliers. A 24 bit unsigned integer (stored in a 32 bit register) can be losslessly converted to a 32 bit float by the hardware, multiplied, then converted back.…

> many GPUs Citation please - every single GPU in the literal world supports integer arithmetic for operating on tid, gid, etc.

While the GP might be technically wrong in a narrow sense, GPUs are built for FP, and that's what you want to be doing if you're using them as accelerators.

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

#58

Post by mathisfun123 »

jmalicki wrote: post #57
mathisfun123 wrote: post #47

Earlier quoted context omitted.

> many GPUs Citation please - every single GPU in the literal world supports integer arithmetic for operating on tid, gid, etc.

While the GP might be technically wrong in a narrow sense, GPUs are built for FP, and that's what you want to be doing if you're using them as accelerators.

You don't know what you're talking about: an enormous amount of TOPs now runs through quantized (read: integer) kernels. Many GPUs don't have even FP64 or even FP32 support.

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

#59

Post by f13f1f1f1 »

epolanski wrote: post #19

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…

Andrew pushes lots of "social issues" so he has that crowd and they push zig as a way of pushing their social views.

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

#60

Post by grayhatter »

epolanski wrote: post #19

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…

I can only answer for me, and while I do think it's more significant a metric for me, I equally assume it probably has some influence on others as well.

C3 uses :: for namespaces, that makes it a competitor with C++ more than C. Equally Odin's syntax is more at home among python, not systems programming.

The appeal of Zig is it feels like C. To many people, this is a downside. C is very very scary to them. But for people who feel at home in C, it's not a downside.

Additionally, the selling point for both are "c replacement" where the selling point of Zig is "good systems programming language" C is only mentioned by it's users as a heuristic.

If 2 groups are trying to replace a language that people are running away from, and that's their best selling point... I'd assume they're less likely to be as successful as a different language just trying to be as good as it can be.

I've even stopped comparing Zig to C, IMO, it does a disservice to both. And I say that as someone who likes C.

Full disclosure, I need to spend a bit more time with both odin and c3 to know exactly how this compares. But the reason I keep writing Zig, and still love it, is how simple it is. Zig is aggressively insistant on simplicity at the expense of functionally or comfort. The only other high level language I know of that is as aggressive about it's design simplicity is infact C. While I assume it's an accident when C does it, it's definitely not an accident in Zig.

Post reply on HN