Hacker News Reader

Comment by grotorea | Hacker News Reader

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

View on HN

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.

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?

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.

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

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.

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

> 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

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.

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

Does ARM64 count?

DC CIVAC: https://developer.arm.com/documentation/ddi0595/2021-12/AArc...

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.

Intrinsics are not part of C though. C is the abstract machine defined in various specs and its syntax and semantics.

C is as much its implementations as it is its spec. And the spec came much later than the implementations, and really was designed as a common subset.

Any language can have intrisics, C is not a special snowflake.

So if intrisics count, than any language goes.

Any of those instructions could be wrapped in a C function or intrinsic if they were valuable enough

Wrapping other languages does not count when describing the hight-of-level of a language. In almost any language you can embed machine code, even in spoken languages.

It would be like 'English is not easier than Chinese, since I can quote a Chinese sentence in English.'

There's a bit of a difference in that C has ways to closely integrate assembly as needed. Most languages don't.

They aren't part of C, they are compiler specific extensions.

Any language can have compiler specific extensions.

Playing fair game, all non toy languages can load modules written in Assembly.

In fact that was the only way in K&R C, compiler extensions came later.

As the article notes, that's because CPUs are designed to run existing C code fast. You could create an instruction set that provided this control, but it might be a tough sell in a world full of C code.

Reply on news.ycombinator.com