Hacker News Reader

Comment by wildmusings | Hacker News Reader

>I'm asking out of curiosity because I want to learn a "system" programming language

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.

View on HN

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

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.

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.

Precisely my point - learning both together as they compliment each other instead of C abstracting the underlying computer away.

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?

See 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/s.... It does seem like glibc impl doesn't involve syscalls: https://groups.google.com/forum/#!topic/comp.unix.programmer...

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

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.

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

Reply on news.ycombinator.com