Comment by messe
3 years ago
> AFAICT, Zig is halfway step between C and C++ for desktop and mobile developers.
What does this even mean? Zig very much has embedded use as a target as well, with freestanding use being a first-class citizen. The majority of the standard library works without an OS (and if you wish, you can provide your own OS-like interfaces quite easily, and use the OS-dependent parts in a freestanding environment). I've written a UEFI bootloader in Zig, and right now I'm using it on an RP2040 as well, cross compiling from an M1 Mac without the need to install any additional cross compilers.
I'd argue that it might be even better for embedded than C/C++ eventually, as unlike them, allocation is even more tightly controlled, with a convention that only functions (or datastructures) that take an allocator as an argument will allocate memory on the heap. Future versions may even restrict recursion in certain contexts to guarantee max stack depths.
Cool, you've targeted ARM on a common SoC and a desktop PC. Now do sh2, sh4, m68k or even xtensa with Zig with a standard build.
They chose to build Zig on top of the worst compiler backend toolchain for embedded support.
Man, it hasn’t even fucking reached 1.0 yet. The fact that the default install can target multiple architectures (including C dependencies) is nothing short of impressive.
Does GCC target any of those in its standard build? Oh. Wait. It doesn’t. It builds for only one architecture at a time and if you want anything else you’ll need to recompile the compiler.
LLVM is even intended to be optional in future, and the Zig team is well on their way to making that a reality with the work on stage2.
What backend would you suggest for embedded support?
Zig is 6 years old, and years-old issues exist in their task tracker requesting support for some of these targets.
You _cannot_ simply recompile LLVM to support the targets I listed without using unsupported, risky patches from community sources; if any such patches exist. The multiple architecture support in one binary is a pointless feature when installing multiple GCC builds only takes a tiny, insignificant fraction of my development machine's disk space. Never in my life have I thought "Wow, I'd really speed up development if GCC was one enormous binary holding all possible targets."
Zig's best path forward is to support targeting C as a first tier target; which they seem to be interested in doing.