i’ve been reading various threads discussing “why we’re moving away from LLVM”, and wanted to understand the impact of this decision on cross-compilation support…
my use-case targets deeply-embedded, resource-constrained, 8/16/32 bit MCUs – many of which are currently supported by LLVM (avr, msp430, riscv32); and even in “mainline” targets like arm, my interest is really with cortex-m0 for example…
from zig’s perspective, these are “tier 4” targets; from my perspective, they are TIER 0 !!! about 99% of the zig std library makes no sense on targets with as little as 8K of program memory; it’s zig’s potential as a “higher-level alternative to C” which keeps me engaged…
FWIW: i just returned from the embedded world show in europe – with 500+ exhibitors and 50,000+ attendees… suffice it to say, NOBODY HAS HEARD OF ZIG…
when i position the language as “like rust is to C++, zig is a more robust C”, folks do grok that analogy… but when i then say that zig uses LLVM as a backend, everyone finally shows some interest… why??? because LLVM supports most of the target architectures of interest to the broader embedded community…
what happens to support for these targets when LLVM-- == 0 ???
I believe they are trying to move debug to being independent first because it apparently speeds up compilation dramatically. I doubt that they’re willing to sink the whole project and just jump ship from LLVM entirely - that would be a really bad move and I’m sure they’ve calculated that cost.
In short, I don’t think you have anything to worry about.
having an “external package” in the form of LLVM should be no real burden, as the embedded development flow is already dependent on external tools for (say) flashing the target via JTAG/SWD…
that’s all good… i guess i’ll stick with zig in my quest to find a better language for deeply-embedded programming…
The first line produces test.c without using llvm.
The second line compiles test.c without standard library, adding zig.h include path.
The third line runs the C compiler output: a.out
Is it the case that the standard library of other programming languages work great on machines with 8K of memory? What do you feel is lacking? Do you use MicroZig?
And what do you want us to do about those people who haven’t heard of Zig?
Also, I don’t understand some other comments on this thread make it sound like they aren’t completely sure what’s going on. Issue #16270 explicitly says:
Note that there would still be an LLVM backend for outputting .bc files (#13265), but the Zig compiler would lack the capability to compile .bc files into object files. LLVM or Clang would need to be installed and invoked separately for that use case.
long story: i have a large and robust “library” which i’ve been carrying around for the past 15+ years, which i’m effectively trying to “zigify” at this time… i’ll hopefully have something to share with this community sooner rather than later…
i have looked at MicroZig, which seems to be on a different trajectory from my own… again, i’m hoping to have more details shortly…
i was just making an observation from a lifetime of experience in the embedded space; pass my comments on to the marketing department
but seriously, i’m quickly becoming a fan a zig (which i had never heard of until late march); and i’m hoping to help proliferate its use within the embedded space…