Zig 2024 roadmap
Zig 2024 roadmap
Posted Feb 4, 2024 2:20 UTC (Sun) by tialaramex (subscriber, #21167)In reply to: Zig 2024 roadmap by khim
Parent article: Zig 2024 roadmap
This hypothetical language would have wrapping overflow for all its integer types, it would define all bounds misses to result in a zero value, and its memory model would be an idealized vast array of raw bytes, thus enabling Provenance Via Integers. Know your allocator will have put this new Goose at an address in memory sixteen more than this string you're about to free up? Just make a pointer to it by adding sixteen to the string pointer, no problem, it's not important when you do this, before you free it, after, either works. To deliver Sequential Consistency it would deliberately lack multi-threading. To deliver type safety it would eliminate new-fangled types like booleans, while underscoring that enums are just integers, strings are just arrays of bytes, etc. instead of "Make illegal states unrepresentable" instead this language would strive to "Make all representations legal states".
I think such a language could be made to deliver software that's maybe a thousand times slower than Python, while remaining no easier to learn than C today, and with no better tooling, this would be entirely safe (though it's probably important not to tell the beneficiaries that you've made their language safe, say instead that it's now "authentic" or something). They wouldn't necessarily _write_ software in this revised C, but they could spend their days arguing with each other about the definitions, which keeps them off the streets.
Posted Feb 4, 2024 18:10 UTC (Sun)
by khim (subscriber, #9252)
[Link] (8 responses)
It wouldn't work. Because they are after efficiency, just feel that compiler have to provide it if possible and leave their low-level tricks alone if it doesn't understand something. Usually they even realize that some unlimited undefined behaviors are needed (look on their semi-serious proposals… Loosening the basic model part is precisely about that), they just couldn't accept the fact that it's either fully defined behavior, or fully undefined behavior, their dreams of, somehow, pulling And even if you would invent a way to define show right shift is supposed to work… they would immediately turn around and ask why compiler doesn't do the sensible thing and doesn't put local variables in registers (which is impossible in such a language). No, it wouldn't be even that much slower if you would use it as “portable assembler” and would write code like you are writing assembler and compiler (that may usually do some optimizations, but not if you “code for the hardware”) just doesn't do anything. The problem is that they wouldn't be satisfied, anyway. They don't really spend that much time arguing about things. They actually produce code and their rants are usually limited to complains about how this or that compiler misunderstands their genious ideas and instead of producing optimized code breaks their valuable programs. When asked about what compiler should do instead they usually either provide random incompatible answers or just say that “compiler should preserve hardware semantics” without elaborating what that phrase even means.
Posted Feb 5, 2024 14:53 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (7 responses)
Posted Feb 5, 2024 15:01 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (1 responses)
That then makes x >> y and x << y a multiple instruction sequence, not a single instruction sequence. On AArch64, for example, LSL x1, x2, x3 is defined as "take the bottom 6 bits of x3, shift x2 left by that amount"; this ignores the sign bit completely, and to implement the behaviour you're suggesting, I'd have to check the sign bit of x3, then choose whether to do an LSL, LSR, or ASR instruction based on signedness of x2's current contents and sign bit of x3.
Posted Feb 5, 2024 15:17 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Posted Feb 5, 2024 15:18 UTC (Mon)
by khim (subscriber, #9252)
[Link] (4 responses)
P1236R1 changed definition to precisely what you say in C++20. Are you sure C23 haven't picked up that change?
Posted Feb 5, 2024 15:24 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link]
Posted Feb 6, 2024 9:02 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
> 6.5.7 Bitwise shift operators
Posted Feb 6, 2024 10:13 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
Ugh. I think someone should propose to fix it, then. C++ have finally removed “undefined behavior” from there (crazy values still trigger undefined behavior when E2, the right operand is “strange”, but anything is accepted as E1, the left operand — starting from C++20), thus in practice compilers already have code to handle everything properly
Posted Feb 6, 2024 15:25 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link]
> My thinking for those "Portable assembler" people is a revision of C which eliminates all the Undefined Behaviour and in the process also removes any semblance of modern convenience or decent performance.
Zig 2024 roadmap
the rabbit out of the hat what-the-hardware-does behavior into high-level languages just wouldn't work.Zig 2024 roadmap
Zig 2024 roadmap
You are talking about right argument, pbonzini talks about left one.
Zig 2024 roadmap
Zig 2024 roadmap
Zig 2024 roadmap
Zig 2024 roadmap
>
> [...] 4 The result of E1 << E2 is E1 left-shifted E2 bit positions [...] if E1 has a signed type and nonnegative value, and E1 * 2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined
>
> 5 The result of E1 >> E2 is E1 right-shifted E2 bit positions [...] If E1 has a signed type and a negative value, the resulting value is implementation-defined
> Nope:
Zig 2024 roadmap
Zig 2024 roadmap