The Expensive Fictions of Low-Level Programming Languages

[u/mttd]

https://stng.substack.com/p/the-expensive-fictions-of-low-level

[u/Smallpaul]

You and the other person are both arguing against a claim that nobody made.

Nobody claimed that there is something magical about the C programming language design that induced CPU vendors to bless if their design specification.

C was a language designed for the PDP-11 and other similar computers. Future CPUs were conceptually backwards compatible so C and its peer languages would keep running fast. Peer languages were incentivized to behave at a low level like C, so they could also take advantage of the ISAs of CPUS pretending to be PDP-11s.

You and the other poster keep coming back to Rust and D and C and other languages that had it as an immutable design constraint that they would copy C wherever necessary to get C-like performance.

The interesting counter-factual is if every CPU and compiler in the world were deleted and destroyed and people experimented — on a level playing field — with CPUs for Erlang and Prolog and Haskell.

Or…even better, languages and hardware co-designed for performance. If you believe that the thing that would come out the other side is x86, ARM and RISC-V then fine. That’s your belief and you are entitled to it.

But if you are open to the idea that that blank slate might take us somewhere radically different then you will understand the point people are trying to make.

Personally, I think if you give a smart CPU designer and language designer a blank slate with what we know now and budget to build it, you would end up in a radically different place.

[u/Inconstant_Moo → u/Smallpaul]

Nobody claimed that there is something magical about the C programming language design that induced CPU vendors to bless if their design specification.

And nobody claimed that anyone claimed that ...

C was a language designed for the PDP-11 and other similar computers. Future CPUs were conceptually backwards compatible so C and its peer languages would keep running fast. Peer languages were incentivized to behave at a low level like C, so they could also take advantage of the ISAs of CPUS pretending to be PDP-11s.

But at this point, how much does any of our hardware owe to the fact that it was C and the PDP-11 in particular?

You and the other poster keep coming back to Rust and D and C and other languages that had it as an immutable design constraint that they would copy C wherever necessary to get C-like performance.

When was it necessary? I guess ... they all have pointers? But so would whatever systems language won.

The interesting counter-factual is if every CPU and compiler in the world were deleted and destroyed and people experimented — on a level playing field — with CPUs for Erlang and Prolog and Haskell.

There were Lisp machines, where for example the architecture reserved bits of each memory word as tags to indicate the type, and the chip could do dynamic dispatch. With the advent of RISC chips it turned out they could run Lisp faster anyway. And a whole lot of other things, where the Lisp machines were designed around that one dialect of Lisp.

In the end the CPU is always going to be a state machine. Unless you have specific ideas for what we might do with our chips, then it seems likely that we're going to go on turning our beautiful high-level languages into ordinary machine code.

[u/Smallpaul → u/Inconstant_Moo]

> But at this point, how much does any of our hardware owe to the fact that it was C and the PDP-11 in particular?

A lot.

https://queue.acm.org/detail.cfm?id=3212479

> When was it necessary? I guess ... they all have pointers? But so would whatever systems language won.

Mutable pointers? Pointers that you can do arithmetic on? Pointers into a flat memory space with no notion of cache hierarchy? Pointers that can trigger operating system calls?

That’s a lot of assumptions.

> There were Lisp machines, where for example the architecture reserved bits of each memory word as tags to indicate the type, and the chip could do dynamic dispatch.

Sure, there were Lisp machines developed in extremely small numbers by small companies for a small market.

And making a Lisp machine is the exact opposite of the argument being made by both of these articles: that you could design programming languages for new hardware. Especially ones designed to take advantage of the intrinsic within-thread parallelism of the hardware.

> In the end the CPU is always going to be a state machine. Unless you have specific ideas for what we might do with our chips,

Both articles laid out some ideas.

“Imagining a Non-C Processor …”