3 ms·

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

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

mytailorisrich 3y ago
> Except it doesn't really, the standard leaves most of the really machine-dependent parts undefined Well that's because it is low level and, especially, simple, and doesn't try to abstract things.
- TheOtherHobbes 3y ago
  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.
- pornel 3y ago
  > and doesn't try to abstract things. 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.
mrpopo 3y ago
Can you or someone expand further on that? Which platforms are trying to use segmented addressing, and what benefits does it have?
- Joker_vD 3y ago
  CHERI project [0]. Look at figure 2.1: it's an improvement and further development of the segments of yore but the origins are quite visible. [0] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf
  - saagarjha 3y ago
    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.
robmccoll 3y ago
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.
agentultra 3y ago
We did ok with the 8086 processors, no?
- Joker_vD 3y ago
  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.
  - actionfromafar 3y ago
    Lisp is fine on 6502 though :-)
  - agentultra 3y ago
    True. The code generated by https://cc65.github.io/ 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? I hadn't really thought about it in a while. :)

mytailorisrich 3y ago

> Except it doesn't really, the standard leaves most of the really machine-dependent parts undefined Well that's because it is low level and, especially, simple, and doesn't try to abstract things.

TheOtherHobbes 3y ago
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.
pornel 3y ago
> and doesn't try to abstract things. 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.

mrpopo 3y ago

Can you or someone expand further on that? Which platforms are trying to use segmented addressing, and what benefits does it have?

Joker_vD 3y ago
CHERI project [0]. Look at figure 2.1: it's an improvement and further development of the segments of yore but the origins are quite visible. [0] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf
- saagarjha 3y ago
  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.

robmccoll 3y ago

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.

agentultra 3y ago

We did ok with the 8086 processors, no?

Joker_vD 3y ago
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.
- actionfromafar 3y ago
  Lisp is fine on 6502 though :-)
- agentultra 3y ago
  True. The code generated by https://cc65.github.io/ 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? I hadn't really thought about it in a while. :)