- 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.)