Hacker News Reader

You say “ This is not the definition used in the article. There is literally a paragraph called "what is a low level language" at the beginning:”

Then say C fails this test of being low-level:

> A modern Intel processor has up to 180 instructions in flight at a time (in stark contrast to a sequential C abstract machine [..]) > [..] the C abstract machine's memory model: flat memory. This hasn't been true for more than two decades. > Unfortunately, simple translation providing fast code is not true for C.

None of this is true for assembly either. To my knowledge neither x86 nor ARM expose primitives to control runtime instruction parallelism nor cache. You just have to know what that looks like and how to adjust that implicitly as best you can (still with no guarantees). Maybe a CPU architecture like Vulkan would work where there’s low-level primitives and vendor-specific plugins but I don’t know. GPU programming has gotten significantly harder and error-prone with Vulkan. Additionally, game-programming doesn’t need pixel-perfect behavior while you do typically want that out of your CPU (yes it’s slightly inaccurate with GPU compute advancements, but that’s still significantly more expensive as a development target and reserved for problems where the value is worth it)

You'll find that you are indeed correct and that it is the point of the article that neither C nor assembly are compelling low level programing languages.

But by that definition, programming in binary isn't low level either! If by the definition, there is no low level programming possible, then it's not a very useful definition.

(I mean, the point that "it's higher level than you think" might be a reasonable one to make. But arguing about the definition of "low level" may not be the best way to make that point.)

I agree with your take, but I still find the article really informative regarding the relative high-levelness of x86 instructions and as someone else wrote: “while js, java, etc. developers learned that the programming model used by the language is quite distinct from the CPU’s one, C programmers like to live in their fantasy land where they just have a very fast PDP-11” (I may have combined a few sentences from the thread, but the point is the same)

By the way: what’s your take on VLIW architectures? Possibly with the currently hardware level optimizations moved to software?

So I think we could say that 1) C is low level, and 2) the distance between C and what's really going on is much larger than it used to be, partly because the distance between assembly opcodes and what's really going on is much larger than it used to be.

Re VLIW architectures: I don't know enough to have a take about them specifically. But I fear moving the optimizations from hardware to software, because it's going to be really hard to optimize as well as Intel/AMD/Arm do, and it's going to be really easy to mess something up. (I don't write assembly if I can help it - I let the compiler writer do it. I don't manage memory if I don't need to. And so on.)

I can see some people might benefit from this, but I suspect that it's bleeding-edge people only. Most of us won't gain from going this route.

Note well: Just my take. Your mileage may vary.

They do expose cache control operations, but they’re rarely useful. If you get a lot of cache misses then you can add prefetches but this is very sensitive to what processor you’re on so it’s not always worth it.

And of course if you’re writing EFI code sometimes you haven’t turned the RAM on yet and cache is what you’re executing out of.

> The article's core point is literally a contradiction to this.

No. The article's core point is that machine code maps poorly to what the CPU does.

Modern CPUs expose no low level access to the way they execute code.

> For a language to be "close to the metal," it must provide an abstract machine that maps easily to the abstractions exposed by the target platform.

C does map perfectly well to the abstractions exposed by x86 CPU. By this definition, C is a low level language. The author himself states that modern processors are fast pdp-11 emulators. This is exactly the "abstractions exposed by the target platform".

If C is not a low level language by that definition, then nothing is. Assembly uses the same PDP-11 abstract machine model that C does. Hence the parents point that this definition is useless.

> The author himself states that modern processors are fast pdp-11 emulators.

Not sure how to say it but they state the exact opposite! Modern processors are not pdp-11 emulators and people are led to believe that because of immense work done by compilers (hence not low level).

> Assembly uses the same PDP-11 abstract machine model that C does.

Not really (assembly has things for SMP memory consistency and cache management), but even that is irrelevant since the article's point is a call to stop shoehorning modern processor capabilities onto that old sequential model and designing an actual low level language with full access to these capabilities (explicitely and not implicitely as is currently done for eg ILP).

It's not done by the compilers, though. It's done by the CPU itself.

>Not sure how to say it but they state the exact opposite! Modern processors are not pdp-11 emulators.

The author very clearly states that modern processors _are_ presenting a PDP-11 interface. The author argues that they shouldn't be doing that, but all modern processors are still presenting a pdp-11 like abstract machine:

> The root cause of the Spectre and Meltdown vulnerabilities was that processor architects were trying to build not just fast processors, but fast processors that expose the same abstract machine as a PDP-11.

yeah low level is relative. Assembly would be the place to manipulate hardware, but then developer need to have knowledge of the chip design, etc.

Depending on what you want to do. One can also go a level lower with machine code, or physics as how some quantum computers are coming on the scene now days.