C Is Not a Low-level Language (2018)

The Cell processor was a very different architecture from x86. It sacrificed cache coherency and required the programmer to manually manage each core&#x27;s cache, in exchange for state-of-the-art performance. This was all done in C (although FORTRAN compiler was also available, of course). The Cell processor simply introduced new intrinsic functions to the C compiler, to allow the programmer to access the new hardware functionality. It all works perfectly fine with the rest of C, although people felt it was too difficult to program and the architecture quickly went extinct.<p>NVIDIA GPUs are also innovative hardware, mentioned in the article, and CUDA is also just an extension of C. CUDA is wildly popular, and lots of higher level abstractions had been built on top of it. The only thing lower level than CUDA is the NVVM IR code which is generated by the C compiler (eg. LLVM NVVM backend) and is only compiled into final machine code by the GPU driver at run-time. So C is the lowest level.<p>The problem doesn&#x27;t lie with the language, it lies with the x86 processors and different trade-offs that companies like Intel must make, such as trying to sell processors to developers who have been instructed by their employers to be productive and use a &quot;safe&quot; and high level language (e.g. Java CRUD application developers, or JavaScript web developers, etc).<p>edit: typos

This is a rewording of the original title, which is:<p>C Is Not a Low-level Language Your computer is not a fast PDP-11.<p>&quot;Trying to expose a PDP-11&quot; is misleading here, because how it&#x27;s written in this title suggests that C is not a low level language because it fails at exposing a PDP-11.<p>Rather, the article suggests that modern processors are made in a way to expose abstractions which are similar to a fast PDP-11, which lacks real ways to represent their true complexity.<p>It&#x27;s an interesting article, but this misleading title might give the wrong idea.

This article presents a false premise.<p>Intel (and other) processors present a serial programming model in spite of parallelism under the hood because that is required for stable semantics in assembly language programming, and for the instruction set architecture to be a stable target for any higher level language whatsoever. It&#x27;s not because of the expectations of the C programming model.<p>The unoptimized, instruction by instruction fetch-decode-execute model of the instruction set pins down what the code means, which is super important, otherwise there is chaos.<p>Moreover, machine language executables must continue to work across evolution of the architecture family. The way an new Intel processor is today has as much to do with C compilers as it does with the need for someone out there to run MS-DOS or Windows 95.<p>Compilers could better deal with chaos at the architecture level, because breakages at the architecture level can be treated as a new back-end target, and code can be recompiled. It&#x27;s the code that doesn&#x27;t get recompiled that you have to worry about.

&quot;Low level&quot; is relative. The article says that there doesn&#x27;t exist any &quot;low level&quot; languages that programmers can use, this isn&#x27;t a very helpful definition. If we go by the languages that programmers actually have access to, then machine code is as close as you get to the metal, and C maps very well to machine code. So by any reasonable definition C is a low level language for programmers. For a hardware engineer who works on CPU architecture it is of course different, but we are talking from a programmers perspective here.

This one caught my eye:<p>&gt; for example, you must be able to compare two structs using a type-oblivious comparison (e.g., memcmp), so a copy of a struct must retain its padding.<p>This definitely doesn&#x27;t work in the real world because the padding bytes will contain random junk which isn&#x27;t copied along in some situations, depending on the compiler and optimization level.<p>Also, IMHO what the article calls &quot;low level&quot; might be important for compiler writers, but isn&#x27;t really all that relevant for most programmers when the comparison is to &quot;high level&quot; languages like Java, C#, Javascript or Python.<p>In my mind, the most important property of a low level langauge is to provide explicit control over how data is layed out in memory, this is usually an afterthought in high-level languages, if possible at all.<p>Or more generally: how much explicit control does the language allow before the programmer hits the &quot;manual optimization wall&quot;. In that sense C <i>is</i> fairly high level, especially without non-standard extensions, but still much lower level than most other programming languages. I think there is definitely room for more experimental languages between C and assembly.

C&#x27;s pre&#x2F;post-increment is from B which was designed for an older arch, not PDP, and B still had the pre&#x2F;post increment and decrement. It&#x27;s now a well known misconception that C was based on the PDP&#x27;s instructions, it doesn&#x27;t hold water with the facts. C did redesign for one thing on the PDP and that&#x27;s byte addressing... and we&#x27;re still using byte addressing most places, and frankly if you don&#x27;t then C isn&#x27;t incapable with that.

The Problem is not with C alone however.<p>Speculative Execution, branch prediction and look ahead to the next 25 instructions, wasting huge amounts of power,...I mean, what?<p>The article even mentions that there is another way:<p>&gt; <i>In contrast, GPUs achieve very high performance without any of this logic, at the expense of requiring explicitly parallel programs.</i><p>Yes, C doesn&#x27;t support that very well. But it could, and other languages, namely Rust, Go &amp; Julia already can. So maybe it&#x27;s time to do in CPU design what Go did in language design, and hit the brakes on complexity?<p>We don&#x27;t need smarter processors, we need processors that can do high throughput on many execution units, and languages that support that well.

It&#x27;s really fun (?) to work with hardware designers, for whom even the registers that the code accesses is considered &quot;high-level&quot;.<p>Abstractions, all the way down... even our digital bits are a joke to the analog designers.

Previous HN discussions with many comments:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16967675" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16967675</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21888096" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21888096</a>

One should always think of a C as high level Assembler. Not less, not more. Everything else (parallel programming, threading, ...), are &quot;higher&quot; level paradigms, where C &quot;robustness&quot; is more of an obstruction, not a help.<p>Imo, from hw designers perspective C is a language as &quot;high&quot; as it goes, when for a software engineers it&#x27;s often &quot;as low as it goes&quot;.

I am lost here, the mentioned bugs are a result of optimizations like speculative execution, branch prediction, prefetching etc.<p>These are language independent optimizations. For example, any language (that allow for loop like constructs) compiled to intel machine code and executed on intel processor will be exposed to these bugs, it is not C specific. Am I missing anything?

Maybe this doesn&#x27;t matter so much. Remember, the cpu may be re-writing your code and re-ordering many operations. The latest Intel processors can examine your code and write new microcode to do it more efficiently. Heck, even identifying a fault to an instruction in &#x27;your&#x27; code has become problematic!

&quot;Assembly isn&#x27;t a Low-Level Language: Your heterogeneous multicore Apple M1 with integrated GPU and multi-tier SRAM cache isn&#x27;t a 1970s PDP-11 minicomputer, you can&#x27;t just MOV RAX, EAX and expect it to work, you complete and utter jackwagon!&quot;

&gt; C Is Not a Low-level Language Anymore<p>Pretty sure C was always considered a high-level language.

Looks like C being Low-level or not needs a precise or formal definition of low-level language. Without that, it falls down to opinion.

Pretty sure K&amp;R calls C a high level language. Just a matter of perspective, innit: a high level language to assembly programmers, a low level language to .NET&#x2F;JVM&#x2F;web programmers, and prob something like a lower-mid-level language to someone looking at the whole tower from a distance

This article is my go to url when arguing on the internet with people who are under the illusion that &quot;C is portable assembler&quot; when it really isn&#x27;t and their mental model is actually not what a computer actually does today (or has performed in the past few decades).

As hinted by the article LLVM IR [1] is a lower level language and yet it&#x27;s only intermediate as per the i in IR.<p>And it&#x27;s true that the actor model makes writing parallel programs easier. I tend to use queues and message passing when I write multi threaded programs in sequential languages like Python or Ruby. That&#x27;s easier to do in a language like Elixir. Unfortunately when I work with Elixir I&#x27;m a little discouraged by all the boilerplate needed to make supervisors and GenServers work. I think there is a lot of room for improvement for a higher level language that makes most of that disappear.<p>[1] <a href="https:&#x2F;&#x2F;llvm.org&#x2F;docs&#x2F;LangRef.html#instruction-reference" rel="nofollow">https:&#x2F;&#x2F;llvm.org&#x2F;docs&#x2F;LangRef.html#instruction-reference</a>

&gt; In C, a read from an uninitialized variable is an unspecified value and is allowed to be any value each time it is read. This is important, because it allows behavior such as lazy recycling of pages: for example, on FreeBSD the malloc implementation informs the operating system that pages are currently unused, and the operating system uses the first write to a page as the hint that this is no longer true. A read to newly malloced memory may initially read the old value; then the operating system may reuse theunderlying physical page; and then on the next write to a different location in the page replace it with a newly zeroed page. The second read from the same location will then give a zero value.<p>What? What is the benifit of such behaviour?<p>What does other OSes do in this regard?

Effing great article. I am starting down the path of learning rust and wondering how its mutable-first design and ownership model alleviate some of the problems identified in making C fast on contemporary machines.

Thanks for this interesting read.<p>Say a platform superseded that C platform the article is describing, allowing for an unleash of power and parallelism in computing, what are the implications for Linux and other operating systems?

I have an old button that says “C combines the power of assembly language with the flexibility of assembly language.” Might have changed now, but it was a humorous yet valid observation then.

Is there a language that exposes the stuff below assembly? Like assembly language presents a nice sequential ordered view of processors as if they execute instructions 1 by 1, but we know the reality is quite different - each instruction is many micro instructions, they compute data dependencies and parallelize accordingly, pipeline &amp; predict heavily etc. We do so much to fit async data dependent computation into sequential models, only for that to be translated back into async&#x2F;parallel by the CPU. I wonder what that kind of PL would look like?

&gt; which attempt to hide latency<p>It does exceptionally good job at these attempts. If you think manually managed caches are fun, read [1] for an illustration what amount of efforts is required to sum an array for an architecture where on-chip RAM is manually managed. Another interesting case was Cell CPUs in PS3, I don&#x27;t have hands on experience but I&#x27;ve read that it was equally hard to develop for.<p>&gt; A low-level language for such processors would have native vector types of arbitrary lengths.<p>A low-level language would have native vector types of exactly the same lengths as underlying hardware. &quot;arbitrary&quot; is overkill unless the CPU supports arbitrary-length vectors.<p>Despite not specified as a part of language standard, all modern C and C++ implementations support these things. Specifically, when compiling into AMD64 instructions, the compilers implement native vector types, and vector intrinsics, defined by Intel. Same with NEON, all modern compilers implementing what&#x27;s written by ARM.<p>&gt; you must be able to compare two structs using a type-oblivious comparison (e.g., memcmp)<p>Using memcmp on structures is not necessarily a great idea, these padding bytes can be random garbage, it&#x27;s not specified.<p>&gt; with enough high-level parallelism, you can suspend the threads.. The problem with such designs is that C programs tend to have few busy threads.<p>Not just C programs. User input is serial, it can only interact with 1 application at a time. Display output is serial, it delivers a sequence of frames at 60Hz. Web browsers tend to have few busy threads because JavaScript is single threaded, also streaming parsers&#x2F;decompressors&#x2F;decryptors are not parallelizable.<p>&gt; ARM&#x27;s SVE (Scalar Vector Extensions)—and similar work from Berkeley—provides another glimpse at a better interface between program and hardware.<p>Just because it&#x27;s different does not automatically make it better. The main problem with scalable vectors, it seems to be designed for problems CPUs no longer solving. For massively parallelizable vertical-only FP32 and FP64 math, GPGPU is the way to go, an order of magnitude faster while also being much more power efficient. CPU SIMD is used for more than vertical-only math. One thing is non-vertical operations i.e. shuffles, trivial use case: transpose a 4x4 matrix in 4 registers. Another one is operations on very small vectors, CPUs even have a DPPS instruction for FP32 dot product. For both use cases, scalable vectors make little sense.<p>&gt; a garbage collector becomes a very simple state machine that is trivial to implement in hardware<p>People tried that a few times, first with Lisp, then with Java chips. General-purpose CPUs were better.<p>&gt; Running C code on such a system would be problematic, so, given the large amount of legacy C code in the world, it would not likely be a commercial success.<p>nVidia did precisely that, made a processor designed purely for compute speed. I wouldn&#x27;t call them a commercial failure.<p>[1] <a href="https:&#x2F;&#x2F;www.nvidia.com&#x2F;content&#x2F;GTC-2010&#x2F;pdfs&#x2F;2260_GTC2010.pdf" rel="nofollow">https:&#x2F;&#x2F;www.nvidia.com&#x2F;content&#x2F;GTC-2010&#x2F;pdfs&#x2F;2260_GTC2010.pd...</a>

This article could have been 1&#x2F;8th of its length and the message would still be clear. Modern writing is vague, overly detailed and inelegant.