5 ms·

Thank you. I sure tried C too (also C++ for gui programming), though I wouldn't say I "know" it (which to me would imply at the very least one significant real-

by guggle 7y ago

Thank you. I sure tried C too (also C++ for gui programming), though I wouldn't say I "know" it (which to me would imply at the very least one significant real-world experience with it), I do understand why some projects try to modernize "system" programming. I just want to evaluate alternatives, but I may very well go for C in the end...

baq 7y ago
C is portable assembly, I’d recommend learning it together with the assembly for the platform you’re learning on, so you can actually understand the stack, heap, calling conventions, etc.
- mratsim 7y ago
  C is portable assembly until it isn't: - 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.
  - baq 7y ago
    Precisely my point - learning both together as they compliment each other instead of C abstracting the underlying computer away.
  - sigjuice 7y ago
    need to drop down to assembly to implement resumable function/fibers to avoid the syscall costs of ucontext/setjmp/longjmp Which syscalls would be involved in setjmp/longjmp?
    - mratsim 7y ago
      See http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers http://www.1024cores.net/home/lock-free-algorithms/tricks/fi... on ucontext And for longjmp, Apple source for example https://opensource.apple.com/source/Libc/Libc-262/i386/sys/setjmp.s.auto.html 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/LvUP9H-7Aes https://groups.google.com/forum/#!topic/comp.unix.programmer...
    - loeg 7y ago
      For inexplicable reasons, ucontext/setjmp/longjmp include signal masks, which, for lack of VDSO implementation, must be obtained by invoking syscalls. (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.)
  - throwaway17_17 7y ago
    The following is a genuine question (not a flippant remark): 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.
  - renox 7y ago
    > C is portable assembly until it isn't: > - 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..

by guggle 7y ago

baq 7y ago

C is portable assembly, I’d recommend learning it together with the assembly for the platform you’re learning on, so you can actually understand the stack, heap, calling conventions, etc.

mratsim 7y ago
C is portable assembly until it isn't: - 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.
- baq 7y ago
  Precisely my point - learning both together as they compliment each other instead of C abstracting the underlying computer away.
- sigjuice 7y ago
  need to drop down to assembly to implement resumable function/fibers to avoid the syscall costs of ucontext/setjmp/longjmp Which syscalls would be involved in setjmp/longjmp?
  - mratsim 7y ago
    See http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers http://www.1024cores.net/home/lock-free-algorithms/tricks/fi... on ucontext And for longjmp, Apple source for example https://opensource.apple.com/source/Libc/Libc-262/i386/sys/setjmp.s.auto.html 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/LvUP9H-7Aes https://groups.google.com/forum/#!topic/comp.unix.programmer...
  - loeg 7y ago
    For inexplicable reasons, ucontext/setjmp/longjmp include signal masks, which, for lack of VDSO implementation, must be obtained by invoking syscalls. (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.)
- throwaway17_17 7y ago
  The following is a genuine question (not a flippant remark): 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.
- renox 7y ago
  > C is portable assembly until it isn't: > - 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..