Comment by AlotOfReading
1 day ago
The natural comparisons are libraries like glibc and newlib, which do support lots of architectures and more importantly make porting to new architectures or taking advantage of platform features pretty straightforward.
people also greatly underestimate the performance of glibc and the insane work and literal decades it's taken to achieve. people keep relearning this lesson the hard way when they link musl and suffer perf issues. one needs not look further than the libc mailing lists and if they were so dedicated could probably find a discussion on every performance issue they face with the glibc alternatives over the decades.
for embedded defs not against portable alternatives like this tho.
however ops post sure gets off on the wrong foot by saying this is "fixing C". the hubris of mankind on full display, yet again
I’m not as experienced as some people here, but in ~10 years, I’ve never needed to write code for anything other than x86 or arm. So I agree with the author on their priorities.
Not all ARM systems are created equally. For example many of the 32bit ARM processor didn’t even support floating point ops. So they’d have to be calculated in software.
Aside from various different variations of ARM, I’ve worked several variations of x86 and AMD64, SPARC, PowerPC, MIPS and others I’ve likely forgotten. Not to mention a few 8-bit CPUs too, but those there more than 20 years ago and not really fair to discuss here.
in just the past ten years i’ve had to write asm for x86, arm, mips, riscv, 8051 and something else i can’t even remember. generalizing rules