Mach v0.1: Cross-platform Zig graphics
devlog.hexops.com
Mach v0.1: Cross-platform Zig graphics
1–10 of 48 posts
Re: Mach v0.1: Cross-platform Zig graphics
#2i'm following zig's project from HN and i often see cross-compilation and c/c++ mentionned.
Why is zig often mentionned in that context ? it seems that cross-compilation and C can be achieved using llvm/clang without a lot of problem ? What is zig accomplishing in that matter that makes it so special ?
Re: Mach v0.1: Cross-platform Zig graphics
#3i'm following zig's project from HN and i often see cross-compilation and c/c++ mentionned. Why is zig often mentionned in that context ? it seems that cross-compilation and C can be achieved using llvm/clang without a lot of problem ? What is zig accomplishing in that matter that makes it so special ?
Best place to read more is probably on the Zig project website, specifically this section[1] on how/why Zig's compiler is also a C compiler and the benefits that provides.
[1] https://ziglang.org/learn/overview/#zig-is-also-a-c-compiler
Re: Mach v0.1: Cross-platform Zig graphics
#4Good article, 1 comment, still.
> slugging through the depths of hell where only a footnote from Raymond Chen himself will save you
The behavior is well documented: https://docs.microsoft.com/en-us/cpp/build/x64-calling-conve...
the caller must allocate memory for the return value and pass a pointer to it as the first argument. The remaining arguments are then shifted one argument to the right. The same pointer must be returned by the callee in RAX
Re: Mach v0.1: Cross-platform Zig graphics
#5What’s the value added in this over RayLib? Is it just building GLFW from source to dodge the dependency issues? Granted, that’s a lot bigger deal than I’m making it seem.
Re: Mach v0.1: Cross-platform Zig graphics
#6i'm following zig's project from HN and i often see cross-compilation and c/c++ mentionned. Why is zig often mentionned in that context ? it seems that cross-compilation and C can be achieved using llvm/clang without a lot of problem ? What is zig accomplishing in that matter that makes it so special ?
TL;DR the hardest part of cross compilation is usually getting the tool gains set up to do so. Zig ships a bunch of libc's in a lightweight compressed format which makes cross compilation completely trivial, it handles most of the work behind the scenes.
Re: Mach v0.1: Cross-platform Zig graphics
#7i'm following zig's project from HN and i often see cross-compilation and c/c++ mentionned. Why is zig often mentionned in that context ? it seems that cross-compilation and C can be achieved using llvm/clang without a lot of problem ? What is zig accomplishing in that matter that makes it so special ?
Best place to read more is probably on the Zig project website, specifically this section[1] on how/why Zig's compiler is also a C compiler and the benefits that provides. [1] https://ziglang.org/learn/overview/#zig-is-also-a-c-compiler
So, I read that, and it is vague about whether the zig compiler itself compiles C, or whether it launches a C compiler (cc).
---
I will resist making the obvious reference despite having said both "launch" and "zig" in the same sentence.
Re: Mach v0.1: Cross-platform Zig graphics
#8Good article, 1 comment, still. > slugging through the depths of hell where only a footnote from Raymond Chen himself will save you The behavior is well documented: https://docs.microsoft.com/en-us/cpp/build/x64-calling-conve... the caller must allocate memory for the return value and pass a pointer to it as the first argument. The remaining arguments are then shifted one argument to the right. The same pointer must…
This is also fairly standard as a calling convention as well? The Itanium C++ ABI (the standard for x64 on Linux) has the same text: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#non-trivi...
So either there's some extra COM consideration I'm not aware of, or there's a serious confusion in how calling conventions work. If someone returns an aggregate, what option do you have other than a pointer? If it's a callee-allocated pointer, what are the lifetime rules and how do you free it? Passing caller-allocated storage is the obvious answer and is far from unusual, or undocumented.
The difference I can tell between the MSVC and Itanium C++ ABIs is just that MSVC uses "this, ret" order for methods, and Itanium uses "ret, this". There's probably some subtle differences in what constitutes "non-trivial" between the two ABIs as well.
Re: Mach v0.1: Cross-platform Zig graphics
#9i'm following zig's project from HN and i often see cross-compilation and c/c++ mentionned. Why is zig often mentionned in that context ? it seems that cross-compilation and C can be achieved using llvm/clang without a lot of problem ? What is zig accomplishing in that matter that makes it so special ?
llvm/clang does not cross-compile "without a lot of problems". See this post from Zig's creator: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
zig cc uses clang under the hood, and Zig the language is also mostly based on LLVM, but zig cc ships a lot of versions of libc to ensure that it can properly compile to all platforms without weird linker errors.
Re: Mach v0.1: Cross-platform Zig graphics
#10i'm following zig's project from HN and i often see cross-compilation and c/c++ mentionned. Why is zig often mentionned in that context ? it seems that cross-compilation and C can be achieved using llvm/clang without a lot of problem ? What is zig accomplishing in that matter that makes it so special ?
TL;DR the hardest part of cross compilation is usually getting the tool gains set up to do so. Zig ships a bunch of libc's in a lightweight compressed format which makes cross compilation completely trivial, it handles most of the work behind the scenes.
How does it hande openssl ?