You can thank Rob Pike for that, about a decade ago he wrote a Google Plus post arguing that one of the things C brought to the table was that it essentially was portable assembly compared to most other high level language projects at the time. I guess the tiny sliver of nuance that the "essentially" added was quickly lost.
Technically that's true because of the "C virtual machine", but pragmatically, C is still the "lowest-level high-level programming language" at least among the popular programming languages (arguably only Forth is lower level, but Forth isn't exactly mainstream).
(and I'd argue that C is closer to assembly than assembly is to what's actually happening inside the CPU, e.g. assembly itself is a high-level abstraction layer that's still pretty close to C - which isn't all that surprising because both probably developed as a symbiosis over time - especially when you look at all the non-standard language extensions in various C compilers)
You're thinking of the C abstract machine, not a virtual machine. Abstract art is when this is a painted blue circle but it's about the feeling of sadness when losing somebody close to you - virtual art is when somebody persuades you a crappy GIF of a monkey is worth a million dollars.
And no, it's just not usefully true to model things this way. The C abstract machine is pretty weird even compared to a PDP-11, and your modern computer is nothing like a PDP-11.
C was intended to be efficiently implementable, so that's nice, but it has numerous defects in practice in this regard, because it pre-dates a lot of discoveries about how to implement programming languages.
The machine doesn't have types. At all. They're just not a thing. C has types. They're not very good types, and they're poorly implemented, but they are definitely types. Several other languages from that era don't bother, C does because it's a "high level language" and you'll do better embracing that understanding than trying to pretend it's assembler.
Assembler has types : bytes, words, floats, addresses, even strings and "functions". They are easily worked around by design though, in similar ways in assembler and C.
May I suggest you give arguments why it is not (and why we should care about those arguments from a practical standpoint), and what language should better earn the title?
Others have already made a few in response, but for reference, this ACM queue article [1] is a good place to start. It has been widely discussed both on HN and elsewhere, and a simple search of the title can bring up several counter-arguments etc. if you're interested and want to know more.
This article states that "C is not a Low-Level Language", not that it is not a thin abstraction over assembly. The arguments in the article could as well be used to make a point that "Assembly is not a Low-Level Language".
Many features of C do not directly correspond with most modern assembly languages. You cannot predict the exact assembly it will generate without knowing a lot of details about your compiler and platform, and even then it's often iffy. It seems like a bit of a leap to call something "a minimal abstraction" if you can't even correctly describe how an operation in the abstraction corresponds to operations in the lower level.
That's mainly the result of optimizer passes, C itself doesn't have much to do with it.
Assembly languages actually haven't changed all that much since the 70's, but compilers have improved a lot. The output of early C compilers did indeed match the source code quite closely (and not just on the PDP-11), but even today that's true if you disable optimizations (and even with optimizations is usually pretty straightforward to map the C source to the assembly listing - if you're somewhat aware what optimizer passes in modern compilers are doing).
Of course CPU ISAs are already human-friendly abstractions over what's actually happening down in the hardware.
C has everything to do with optimizer passes, the language definition is what allows them to happen! The fact that you get about what you'd expect on -O0 is merely incidental, the specification does not afford you this.
It's true and false at the same time. The operations C gives you map 1-to-1 with assembly. Given some C code you can quite accurately predict which loads/stores will be elided by the compiler and what the resulting assembly will be.
I can't name another language for which this is true.
I get that you're hinting at the insane level of undefined behaviour enforcement by compilers, but I don't think it matters all that much once you understand how optimizing compilers work.
And conversely you don’t have access to a few things assembly can do: arbitrary stack access, PC register, flags. Some operations like bit rotation, zero bit counting, or fancier addressing modes have informal code patterns with a hope they’ll optimize right, but nothing guaranteed in the standard.
Pretty much a matter of optimization isn't it? Try disabling them. But I take it that this was never the point anyway. I think the point is that the representation of language objects and the runtime are rather straightforward compared to many other languages.
Only one of those (inlining) is an optimization. Two are language features (implicit casts and volatile) and the other is a calling convention (passing arguments on registers vs. stack).
Calling conventions aren't (mainly) a C feature either though, but are defined by the ABI specified for a specific OS/CPU combination (and all languages which want to talk to system APIs need to implement that ABI, not just C).
> It's true and false at the same time. The operations C gives you map 1-to-1 with assembly. Given some C code you can quite accurately predict which loads/stores will be elided by the compiler and what the resulting assembly will be.
I mean, can you though? After all you won't even have the same output depending on compiler and flags. And of course not all architectures have the same capabilities, so the same code can compile to a various number of instructions depending on the target architecture.
Not to mention things like bitfield access that can result in non-atomic load/stores for a simple `foo->bar = 1;`
I'm not sure in what sense you could say that C operations map 1-to-1 with assembly any more than Rust, C++ or basically any compiled language.
> The operations C gives you map 1-to-1 with assembly
int test(int x, int y) {
return x % y;
}
test: // @test
sdiv w8, w0, w1
msub w0, w8, w1, w0
ret
Surprisingly, assembly doesn't have the remainder instruction, but instead it has a multiply-then-subtract instruction which is not corresponding 1-to-1 to anything in C.
x86 has remainder: IDIV calculates both the quotient and the remainder at the same time and places them in different registers just like many other ISAs before it did. In fact, DIV instruction of PDP-11 worked that way too:
Description: The 32-bit two's complement integer in R and Rv1 is divided
by the source operand. The quotient is left in R; the remain-
der in Rv1. Division will be performed so that the remainder
is of the same sign as the dividend. R must be even.
Example: CLR RO
MOV #20001,R1
DIV #2, RO
Before After
(RO) = 000000 (RO) = 010000 Quotient
(R1) = 020001 (R1) = 000001 Remainder
PDP-11 also had ADC and SBC (add/subtract with carry) instructions which weren't (and still aren't) exposed in C either.
Of course you can, but this is implementation defined. So you need to create code that does different things based on the underlying implementation. Every reasonably large C code base checks the current implementation to define what type of integers, pointers, etc. they're dealing with.
This is by design, because C was created do deal with disparate processors and OSs. When it was crated it would be difficult and unwise to assume that an integer has size of 2 bytes, for example, since each machine would define its own preferred length.
> When it was crated it would be difficult and unwise to assume that an integer has size of 2 bytes
It was still a bad design. Of course this is in hindsight, but history has taught is it would have been much better if the default was for specific sized integers, with an option to use `uint_fast32_t` or whatever.
Then we would be stuck with 16 bits integers. We are lucky to be in a point in time where integer types have been stable for a while, but it wasn't always so.
It would still be good if it was written in a different language. Probably even better because the developers would have more time to improve the software instead of reinventing wheels, writing boilerplate code and chasing down segfaults.
No it didn't. C happened to be the most popular language for a long time but that doesn't mean people couldn't have written software without it, or that if it hasn't been so popular a better language wouldn't have arisen.
English is very popular but you wouldn't say "English is what made all those books possible" would you?
