Can I convert a 300-byte message to Base64 with a single instruction? Like:
in: [300]u8;
out: [800]u3;
out = @bitCast(in);Zig's new bitCast semantics and LLVM back end improvements
121–130 of 159 posts
Re: Zig's new bitCast semantics and LLVM back end improvements
#122Earlier quoted context omitted.
Network byte order has nothing to do with the kernel and you have to care about it It’s a standard because neither side of the connection knows the endianness of the other side so there must be a standard. That standard is big endian regardless of your architecture or kernel or anything else So any serialization intended go over the network should be big endian
right, so a zig app will just do little endian. in the very unlikely event you have it running on a big endian machine you have to do extra work.
You may have never done socket programming, or do you use wrapper libs in Zig? Because you have to send the kernel big endian port numbers for example.
What do you do if you program a kernel in Zig, or just generally do low level networking?
My point is to refute the statement that everyone has agreed to little endian, and so there aren't use cases to want to do conversion. Programs do not exist in a vacuum, most programs do not.
Re: Zig's new bitCast semantics and LLVM back end improvements
#123Is pasting em-dashes everywhere some kind of inside joke?
You too could have it easily accessible on your keyboard by using EurKEY: https://eurkey.steffen.bruentjen.eu/
Re: Zig's new bitCast semantics and LLVM back end improvements
#124> 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 completely disagree.
> As a general rule, the new semantics tend to match the behavior of the old semantics on little-endian targets.
They've basically said that bit casting is going to be little endian. This simplifies things for the 100% of people that are on little endian machines, while making the code still work for the 0% of people (rounded to the nearest 0.0000001%) that are using big endian machines.
Re: Zig's new bitCast semantics and LLVM back end improvements
#125Can 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 operation! (But maybe LLVM would surprise me.)
Re: Zig's new bitCast semantics and LLVM back end improvements
#126OT: 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…
Zig has a really great backwards compatibility story with C, and it also is a better C compiler even if you don't write a single line of Zig. It's not hard to see why that is popular.
Re: Zig's new bitCast semantics and LLVM back end improvements
#127Earlier quoted context omitted.
It's so interesting to read comments like this and contrast them with the "don't read the code" type of vibes out right now. It feels like half of the developer world is optimizing low-level struct packing and the other half is YOLO'ing 300 KLOC Electron apps. Very confusing.
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?
Re: Zig's new bitCast semantics and LLVM back end improvements
#128This 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.
It's so interesting to read comments like this and contrast them with the "don't read the code" type of vibes out right now. It feels like half of the developer world is optimizing low-level struct packing and the other half is YOLO'ing 300 KLOC Electron apps. Very confusing.
[deleted]
Re: Zig's new bitCast semantics and LLVM back end improvements
#129Earlier quoted context omitted.
From page 175 of the AMD CDNA4 ISA: https://www.amd.com/content/dam/amd/en/documents/instinct-te... > V_MUL_U32_U24 >,Multiply two unsigned 24-bit integer inputs and store the result as an unsigned 32-bit integer into a vector register. D0.u32 = 32'U(S0.u24) * 32'U(S1.u24) > Notes > This opcode is expected to be as efficient as basic single-precision opcodes since it utilizes the single-precision floating point multi…
That's literally only for 32bx24b (I don't remember why we did that specifically for CDNA - I'll ask someone) but as you see from V_MUL_HI_I32, V_MUL_LO_U32 there is very much vector arithmetic hardware (nevermind that we're not talking about VALU but conventional scalar ALU).
I think he has a point, but I am still not 100% convinced by the arguments relating to casting.
There is a difference between a u24 data type inside u32 and a u24 datatype inside u24 and that is what's so frustrating here. u24 is an alignment nightmare so it will basically never exist as "u24 in u24" and only ever as "u24 in u32".
For casting to make sense, the alignment must be compatible and it's not clear how you can simultaneously make arbitrary bit data types simultaneously useful for the scenario of describing bit fields in packets, where padding is inherently undesirable and performing integer arithmetic with an FPU, where padding is an acceptable cost for alignment. These appear to be mutually exclusive use cases.
Re: Zig's new bitCast semantics and LLVM back end improvements
#130Earlier 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?
So vibe coding = copy/paste from SO = interpreter with GC = compiler = punch cards. Got it.