Author here, thanks for posting!
Happy to answer any questions about Mach (or my experience working with Zig.)
Mach v0.1: Cross-platform Zig graphics
11–20 of 48 posts
Re: Mach v0.1: Cross-platform Zig graphics
#12Good 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…
My memory on this specific issue is a bit fuzzy, but as far as I remember the issue was regarding the definition/ABI compatibility of C++ member functions. The doc you linked aren't really clear what to do in the case of C++ member functions, as they always take a hidden "this" class instance pointer as the first argument (in MSVC). So which one is passed first when you have both?
If you look at godbolt/or disassembly output of an MSVC compiled binary, you can find that it is actually passing the class pointer first, then the return value pointer. Which definitely doesn't match the absolute "the caller must allocate memory for the return value and pass a pointer to it as the first argument" statement from their own docs.
Prior discussion about this at https://news.ycombinator.com/item?id=29613640
Re: Mach v0.1: Cross-platform Zig graphics
#13Earlier quoted context omitted.
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
#14Good 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 calle…
Apparently, the OP’s issue was ABI incompatibility between VC++ (also used by Windows SDK and everything built on top, including Direct3D 12), and System V (used on Linux, also MinGW on Windows).
VC++ documentation says structures are returned through a caller-allocated pointer. Pretty sure modern VC++ optimizes that thing when it can, especially with link time code generation enabled, but for functions and COM methods imported from DLLs that’s not an option.
System V http://c9x.me/compile/doc/abi.html only classifies values as MEMORY when they exceed 16 bytes. The D3D12_CPU_DESCRIPTOR_HANDLE only has a single size_t field, and therefore returned in RAX register in that convention. Moreover, a structure of two size_t fields would be returned in RAX + RDX registers.
Re: Mach v0.1: Cross-platform Zig graphics
#15What’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.
raylib is awesome and a great source of inspiration for me. It's definitely way more complete & comprehensive today than Mach is, too.
Longer term, I think you'll find raylib to be better for simpler applications, and Mach looking a little more like an Unreal/Unity/Godot & geared towards more complex applications. All speculation, though, they're both improving rather quickly!
The other obvious difference would be language it's written in (C vs. Zig)
Re: Mach v0.1: Cross-platform Zig graphics
#16Author here, thanks for posting! Happy to answer any questions about Mach (or my experience working with Zig.)
What do you think of Zig so far?
How do you recommend people get into it, especially those who don't have systems programming experience? Should you learn C first?
Re: Mach v0.1: Cross-platform Zig graphics
#17Earlier quoted context omitted.
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 ?
What do you mean? It can link against OpenSSL just like any other library. I don’t know if OpenSSL supports static builds, but if it does you can link it statically as well.
Re: Mach v0.1: Cross-platform Zig graphics
#18i'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 ?
Do you have experience cross compiling? If so, you’re likely familiar with the headache: getting the right tool chains, sysroots, compiler flags, libraries, etc. There are entire businesses and open source tools whose raison d'être is providing these tool chains and making the process simpler.
With Zig, that all goes away. It’s as simple as saying `zig build -Dtarget=aarch64-linux-gnu` or `zig build -Dtarget=riscv32-freestanding-none` and it just works. It’s pretty incredible.
Zig has set the bar for how cross compilation should be done and all other languages should be measured against it. Rust is close but is still a headache. The only other language that compares at the moment (IMO) is Go.
Re: Mach v0.1: Cross-platform Zig graphics
#19Earlier quoted context omitted.
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 calle…
Apparently, the OP’s issue was ABI incompatibility between VC++ (also used by Windows SDK and everything built on top, including Direct3D 12), and System V (used on Linux, also MinGW on Windows). VC++ documentation says structures are returned through a caller-allocated pointer. Pretty sure modern VC++ optimizes that thing when it can, especially with link time code generation enabled, but for functions and COM metho…
System V is only a C ABI, not a C++ ABI, so of course it wouldn't cover C++-only details. What C++ ABI does MinGW use on Windows?
Re: Mach v0.1: Cross-platform Zig graphics
#20What’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.
raylib is awesome and a great source of inspiration for me. It's definitely way more complete & comprehensive today than Mach is, too. Longer term, I think you'll find raylib to be better for simpler applications, and Mach looking a little more like an Unreal/Unity/Godot & geared towards more complex applications. All speculation, though, they're both improving rather quickly! The other obvious difference would be la…
> Mach looking a little more like an Unreal/Unity/Godot
Right now, Mach is probably something more like Bevy, Magnum.Graphics or BGFX. ie: a _framework_.
But your post alludes that that is not the goal. That Mach seeks to build asset importing, animation tools, navigation system, etc? ie: A FULL GAME ENGINE!?