4 ms·

> C is low level for at least one reason: manual memory management. Especially with modern hardware, memory management is at the center of programming. Ok, but

> C is low level for at least one reason: manual memory management. Especially with modern hardware, memory management is at the center of programming. Ok, but even with C we can't actually low level manage memory how the processor does it. You can't tell the processor what to keep or not on what level of cache, what to send to virtual memory, etc. It's lower level than say Python but I don't think it is low level memory management in the way PDP-11 C was.

Chabsff 3y ago
A lot of that is just a property of modern OSs, with good reason, intentionally not exposing these features to userspace processes. It's not really a function of the language itself.
- grotorea 3y ago
  Hmm, true for virtual memory, didn't think of that, but CPU caches are inside the processor, can even the kernel control it at all?
  - Chabsff 3y ago
    It's not really a question of whether or not it's feasible, but rather: If the hardware were supports such operations, would they be expressible within the language? If they are, then we should point at the accessibility of the functionality rather than C. In this case, I could definitely see `set_cache_behavior(ptr, len, options)` being perfectly reasonable, so I'd argue that, again, the fact that we can't do it is more a property of the environment than the language itself.
wang_li 3y ago
You can control what goes into cache if you want to. The effort to make an open source bios do this in order to have working memory before the DRAM controllers are initialized.[0] 0. https://www.coreboot.org/data/yhlu/cache_as_ram_lb_09142006.pdf https://www.coreboot.org/data/yhlu/cache_as_ram_lb_09142006....
theamk 3y ago
The reference point for when we talk about low memory languages is not transistor but rather machine code. In this aspect we say that C is low level because one pointer dereference in C translates directly into memory load of machine code. The fact that modern memory load operation involves cache, protection, memory mapping, etc.. is not a property of language, but rather of the environment (CPU + OS).
- grotorea 3y ago
  That's fair enough, but it doesn't seem to be the most useful that it can be then. Low level to me could mean that we control all the details. But modern processors have microcode between transistors and the x86 machine code. And we can't control all that memory stuff. But those aren't abstractions that we can treat as black boxes, we need to know them and how to code taking them into account without actually having control inside the black box.
ilyt 3y ago
> Ok, but even with C we can't actually low level manage memory how the processor does it. You can't tell the processor what to keep or not on what level of cache, what to send to virtual memory, etc. neither can assembler so it is useless distinction
- CJefferson 3y ago
  There are CPU instructions to pull memory into cache, send cache back to main memory, and Mark things in cache as not worth writing out to memory. All hard to use from C, the last type basically impossible.
  - monocasa 3y ago
    > pull memory into cache, send cache back to main memory I haven't had much of an issue with intrinsics. > Mark things in cache as not worth writing out to memory Can you give an example of this in a surviving architecture?
    - oasisaimlessly 3y ago
      Does ARM64 count? DC CIVAC: https://developer.arm.com/documentation/ddi0595/2021-12/AArch64-Instructions/DC-CIVAC--Data-or-unified-Cache-line-Clean-and-Invalidate-by-VA-to-PoC https://developer.arm.com/documentation/ddi0595/2021-12/AArc...
      - monocasa 3y ago
        That isn't really marking cache items as not being worth writing out to memory. It's a feature for communicating with non coherent devices to tell the cache that any lines it might have speculatively loaded might have changed out from under it. "Not being worth" reads like cache perf management, as opposed to uses of DC CIVAC, which are strict correctness issues.
    - bjourne 3y ago
      Intrinsics are not part of C though. C is the abstract machine defined in various specs and its syntax and semantics.

Chabsff 3y ago

A lot of that is just a property of modern OSs, with good reason, intentionally not exposing these features to userspace processes. It's not really a function of the language itself.

grotorea 3y ago
Hmm, true for virtual memory, didn't think of that, but CPU caches are inside the processor, can even the kernel control it at all?
- Chabsff 3y ago
  It's not really a question of whether or not it's feasible, but rather: If the hardware were supports such operations, would they be expressible within the language? If they are, then we should point at the accessibility of the functionality rather than C. In this case, I could definitely see `set_cache_behavior(ptr, len, options)` being perfectly reasonable, so I'd argue that, again, the fact that we can't do it is more a property of the environment than the language itself.

wang_li 3y ago

You can control what goes into cache if you want to. The effort to make an open source bios do this in order to have working memory before the DRAM controllers are initialized.[0] 0. https://www.coreboot.org/data/yhlu/cache_as_ram_lb_09142006.pdf https://www.coreboot.org/data/yhlu/cache_as_ram_lb_09142006....

theamk 3y ago

The reference point for when we talk about low memory languages is not transistor but rather machine code. In this aspect we say that C is low level because one pointer dereference in C translates directly into memory load of machine code. The fact that modern memory load operation involves cache, protection, memory mapping, etc.. is not a property of language, but rather of the environment (CPU + OS).

grotorea 3y ago
That's fair enough, but it doesn't seem to be the most useful that it can be then. Low level to me could mean that we control all the details. But modern processors have microcode between transistors and the x86 machine code. And we can't control all that memory stuff. But those aren't abstractions that we can treat as black boxes, we need to know them and how to code taking them into account without actually having control inside the black box.

ilyt 3y ago

> Ok, but even with C we can't actually low level manage memory how the processor does it. You can't tell the processor what to keep or not on what level of cache, what to send to virtual memory, etc. neither can assembler so it is useless distinction

CJefferson 3y ago
There are CPU instructions to pull memory into cache, send cache back to main memory, and Mark things in cache as not worth writing out to memory. All hard to use from C, the last type basically impossible.
- monocasa 3y ago
  > pull memory into cache, send cache back to main memory I haven't had much of an issue with intrinsics. > Mark things in cache as not worth writing out to memory Can you give an example of this in a surviving architecture?
  - oasisaimlessly 3y ago
    Does ARM64 count? DC CIVAC: https://developer.arm.com/documentation/ddi0595/2021-12/AArch64-Instructions/DC-CIVAC--Data-or-unified-Cache-line-Clean-and-Invalidate-by-VA-to-PoC https://developer.arm.com/documentation/ddi0595/2021-12/AArc...
    - monocasa 3y ago
      That isn't really marking cache items as not being worth writing out to memory. It's a feature for communicating with non coherent devices to tell the cache that any lines it might have speculatively loaded might have changed out from under it. "Not being worth" reads like cache perf management, as opposed to uses of DC CIVAC, which are strict correctness issues.
  - bjourne 3y ago
    Intrinsics are not part of C though. C is the abstract machine defined in various specs and its syntax and semantics.