- no access to carry/overflow flag in registers making it a chore to write bigint libraries
- no way to guarantee emitting add with carry or sub with borrow even though those are simple instructions and some architecture (6502) don't even provide a normal add/sub
- need to drop down to assembly to implement resumable function/fibers to avoid the syscall costs of ucontext/setjmp/longjmp
- no access to hardware counters like RDTSC
- no way to get the CPU frequency in a portable and reliable way
- no portable threadID function and then, those that are available (pthread_self, and Windows') rely on expensive syscalls.
- no way to do CPU feature detection (SSE, AVX, ARM Neon, ...)
- no way to control emission of common intrinsics like popcount, bit-scan-reverse, lowest bit isolation in a portable way.
The portable assembly narrative breaks down rapidly when you actually need specific code to be emitted.
> - no access to carry/overflow flag in registers making it a chore to write bigint libraries
C is portable assembly: so it provides access to a minimum common set of features which allow the code to be portable:
good luck trying to use the carry flag on the RISC-V..
Is there any way to have those concepts be portable across ISAs/architectures. I don’t think those types of ops are exposed in LLVM-IR or GCC’s various intermediate levels (but could be wrong). I’d love to be able to investigate a language that enables a level of hardware access possible in a portable manner.
Which syscalls would be involved in setjmp/longjmp?
And for longjmp, Apple source for example https://opensource.apple.com/source/Libc/Libc-262/i386/sys/s.... It does seem like glibc impl doesn't involve syscalls: https://groups.google.com/forum/#!topic/comp.unix.programmer...
(FreeBSD provides the non-portable _setjmp/_longjmp, which do not preserve signal mask state and avoid the syscall. There are also the POSIX sigsetjmp/siglongjmp, which with savesigs=0 may bypass the syscalls as well. Both FreeBSD and Linux provide the POSIX routines.)
If you mean that you don't know any right now, just learn C. This isn't web programming, where everyone is always hopping to the latest fads. C is the lingua franca, the sine qua non of systems programming. It will be a long time before that changes. The C machine model is what everyone is working with anyway. C is small, despite some devious and fun corners of it, and mostly just exposes you to that model and way of interacting with the machine.
You can’t even appreciate the new systems languages unless you have a firm grasp of C and systems programming. They are all a response to C, addendum and proposed evolutions to it.