I feel, low to high level is a spectrum, not a binary. C is arguably in the lowest third of languages, exposing you to a lot of machine primitives like memory and thread management. It may not be as low level as assembly, but it is arguably lower level than Java or Go, and definitely nowhere near the Pythons and JS of this world.
> exposing you to a lot of machine primitives like memory and thread management
Except it doesn't really, the standard leaves most of the really machine-dependent parts undefined; only very few things are left implementation-defined.
Plus, of course, C is quite unsuitable for any platform that uses segmented memory/non-flat addresses (which are things that are trying to come back in vogue but C's wide spread really, really hinders that).
It's a certain kind of low level - specifically a PDP-11 kind of low level.
If your hardware is significantly different, it only looks low level. In reality plenty of mapping and conversion goes on behind the scenes - sometimes with hilarious consequences.
The C standard is a description of an abstract machine. You get UB and unexpected miscompilations, because the optimizer is not evaluating how your code runs on the machine you're compiling for, but simulates running your code on the weirdly abstract C machine, one that can't overflow signed integers.
And C abstracts away almost everything about stack, stack frames, and all the complexities of memory and cache hierarchies. They are abstracted to be uniform linear address space.
C supports CHERI quite well. It’s modern languages used to flat address spaces and 64-bit pointers that are having a hard time, because they defined a lot of “obvious” behaviors that the standard leaves flexible.
Yes, juggling near and far pointers was somewhat annoying but then Intel, as a part of the 32-bit transition, modified their ISA to be a more pleasant target for C implementations.
Incidentally, C never really became popular on 6502 because, arguably, that ISA is somewhat hostile towards efficient implementations of higher-level languages.
True. The code generated by https://cc65.github.io/ is pretty decent but there are a few places where hand-rolled assembler will perform much better when you need it. Although I've made things for 6502-based systems in C with this handy compiler (thanks cc65 contributors!).
Is there something intrinsic to how C handles addressing that makes segmented architectures more painful than they ought to be? Or maybe is there a language where segmented addressing is easier?
By that do you mean exposing a non-uniform memory hierarchy as separate addressable spaces (but with coherent views from each hardware thread) or something like thread-local scratch pads?
Either way, C is equipped ok for that - at least as well as most systems languages C++, Rust, etc. - simply because dealing with allocation and raw addressing (at least raw within the process memory space) is a fundamental part of the experience. Throw in a few compiler extensions (because you'll need to change the compiler to make use of this anyway) for things like where to locate static allocations and use library functions that add dynamic allocation in specific spaces. It will get hairy, but it's at least possible with some very careful programming.
Honest question - is there any language at all between C and Assembly? Because if there is, I haven't heard of it. For that reason alone, my mental model has always been "C is the lowest you can go before hitting direct instructions to the processor."
While staying portable across architectures, probably not. But you can make a little language that's nicer to jse than assembly for a particular CPU.
COMFY-65 is a compiler for a small Lisp language that provides all non-branching operations of the 6502 processor as primitives (e.g. tests for carries, overflows, zero, and negative; set decimal arithmetic mode; etc.). However, programs still consist of subroutines, loops, and tests, with no "go to label" construct provided. It's surprisingly simple and, I would say, elegant.
C makes lots of things undefined behavior which are perfectly fine in assembler — read a stack without first writing to it, doing overflow signed internet arithmetic, treating the same memory location as different types.
Also there is quite a lot in modern assembler that you can’t really get to from C, like prefetch and cache flushing instructions.
Newer languages don't make use of any of those features, to my knowledge. They're only available in assembly, and only on modern processors. Because C was made on and designed for hardware that was crappy even in the 1970s, which didn't have a cache or do out of order execution, C doesn't fully reflect the capabilities of modern processors. That's what they're implying with the last sentence, I'm pretty sure.
"C does not behave as a typical ‘high-level’ language, because it offers a number of features which are more normally associated with ‘low-level’ languages such as assembly language. These include the ability to write data to and from particular memory addresses, facilities for operations on the contents of memory locations, and instructions for incrementing and decrementing integer variables ... Thus C allows the programmer the flexibility and efficiency of working at low level with the advantages of working at high-level, for example the more advanced data structures and program flow controls typical of today’s computer languages. For this reason, C is sometimes described as a ‘high-level low-level language’ or as a ‘low-level high-level language’." - https://archive.org/details/computerprogramm0000ford/page/13...
