6 ms·

Ahh perhaps I need to clarify: I don't love the noise of Zig, but I love the ability to clearly express my intent and the detail of my code in Zig. As for arit

Ahh perhaps I need to clarify: I don't love the noise of Zig, but I love the ability to clearly express my intent and the detail of my code in Zig. As for arithmetic, I agree that it is a bit too verbose at the moment. Hopefully some variant of https://github.com/ziglang/zig/issues/3806 https://github.com/ziglang/zig/issues/3806 will fix this. I fully agree with your TL;DR there, but would emphasize that gaining the same optimizations is easier in Zig due to how builtins and unreachable are built into the language, rather than needing gcc and llvm intrinsics like __builtin_unreachable() - https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Other-Builtins.html#Other-Builtins https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Other-Builtins.... It's my dream that LLVM will improve to the point that we don't need further annotation to enable positive optimization transformations. At that point though, is there really a purpose to using a low level language?

flohofwoe 1y ago
Yeah indeed. Having access to all those 'low-level tweaks' without having to deal with non-standard language extensions which are different in each C compiler (if supported at all) is definitely a good reason to use Zig. One thing I was wondering, since most of Zig's builtins seem to map directly to LLVM features, if and how this will affect the future 'LLVM divorce'.
- Retro_Dev 1y ago
  Good question! The TL;DR as I understand it is that it won't matter too much. For example, the self-hosted x86_64 backend (which is coincidentally becoming default for debugging on linux right now - https://github.com/ziglang/zig/pull/24072 https://github.com/ziglang/zig/pull/24072) has full support for most (all?) builtins. I don't think that we need to worry about that. It's an interesting question about how Zig will handle additional builtins and data representations. The current way I understand it is that there's an additional opt-in translation layer that converts unsupported/complicated IR to IR which the backend can handle. This is referred to as the compiler's "Legalize" stage. It should help to reduce this issue, and perhaps even make backends like https://github.com/xoreaxeaxeax/movfuscator https://github.com/xoreaxeaxeax/movfuscator possible :)
matu3ba 1y ago
> LLVM will improve to the point that we don't need further annotation to enable positive optimization transformations That is quite a long way to go, since the following formal specs/models are missing to make LLVM + user config possible: - hardware semantics, specifically around timing behavior and (if used) weak memory - memory synchronization semantics for weak memory systems with ideas from “Relaxed Memory Concurrency Re-executed” and suggested model looking promising - SIMD with specifically floating point NaN propagation - pointer semantics, specifically in object code (initialization), se- and deserialization, construction, optimizations on pointers with arithmetic, tagging - constant time code semantics, for example how to ensure data stays in L1, L2 cache and operations have constant time - ABI semantics, since specifications are not formal LLVM is also still struggling with full restrict support due to architecture decisions and C++ (now worked on since more than 5 years). > At that point though, is there really a purpose to using a low level language? Languages simplify/encode formal semantics of the (software) system (and system interaction), so the question is if the standalone language with tooling is better than state of art and for what use cases. On the tooling part with incremental compilation I definitely would say yes, because it provides a lot of vertical integration to simplify development. The other long-term/research question is if and what code synthesis and formal method interaction for verification, debugging etc would look like for (what class of) hardware+software systems in the future.
- eptcyka 1y ago
  For constant time code, it doesn’t matter too much if data spills out of a cache, constant time issues arise from compilers introducing early exits which leaves crypto open to timing attacks.
  - matu3ba 1y ago
    Thanks for the info. Do you have a good overview on what other hardware properties or issues are relevant?

flohofwoe 1y ago

Yeah indeed. Having access to all those 'low-level tweaks' without having to deal with non-standard language extensions which are different in each C compiler (if supported at all) is definitely a good reason to use Zig. One thing I was wondering, since most of Zig's builtins seem to map directly to LLVM features, if and how this will affect the future 'LLVM divorce'.

Retro_Dev 1y ago
Good question! The TL;DR as I understand it is that it won't matter too much. For example, the self-hosted x86_64 backend (which is coincidentally becoming default for debugging on linux right now - https://github.com/ziglang/zig/pull/24072 https://github.com/ziglang/zig/pull/24072) has full support for most (all?) builtins. I don't think that we need to worry about that. It's an interesting question about how Zig will handle additional builtins and data representations. The current way I understand it is that there's an additional opt-in translation layer that converts unsupported/complicated IR to IR which the backend can handle. This is referred to as the compiler's "Legalize" stage. It should help to reduce this issue, and perhaps even make backends like https://github.com/xoreaxeaxeax/movfuscator https://github.com/xoreaxeaxeax/movfuscator possible :)

matu3ba 1y ago

> LLVM will improve to the point that we don't need further annotation to enable positive optimization transformations That is quite a long way to go, since the following formal specs/models are missing to make LLVM + user config possible: - hardware semantics, specifically around timing behavior and (if used) weak memory - memory synchronization semantics for weak memory systems with ideas from “Relaxed Memory Concurrency Re-executed” and suggested model looking promising - SIMD with specifically floating point NaN propagation - pointer semantics, specifically in object code (initialization), se- and deserialization, construction, optimizations on pointers with arithmetic, tagging - constant time code semantics, for example how to ensure data stays in L1, L2 cache and operations have constant time - ABI semantics, since specifications are not formal LLVM is also still struggling with full restrict support due to architecture decisions and C++ (now worked on since more than 5 years). > At that point though, is there really a purpose to using a low level language? Languages simplify/encode formal semantics of the (software) system (and system interaction), so the question is if the standalone language with tooling is better than state of art and for what use cases. On the tooling part with incremental compilation I definitely would say yes, because it provides a lot of vertical integration to simplify development. The other long-term/research question is if and what code synthesis and formal method interaction for verification, debugging etc would look like for (what class of) hardware+software systems in the future.

eptcyka 1y ago
For constant time code, it doesn’t matter too much if data spills out of a cache, constant time issues arise from compilers introducing early exits which leaves crypto open to timing attacks.
- matu3ba 1y ago
  Thanks for the info. Do you have a good overview on what other hardware properties or issues are relevant?