Yes it is. I’m unswayed by your arguments. You start out by defining a low level language, concede that C meets your definition, and then go on to argue that even so, it’s not a low level language.
Yeah, it's weird. State the definition, admit that C meets it, and then argue that the definition is wrong? Hey, author, you put forward that definition. Maybe you should propose one that you think is more accurate?
CPUs evolved to execute C-like code quickly. They couldn't dramatically change the way C interfaces with the CPU, so they had to change the hidden internals instead.
For example, CPUs didn't have an option to hide DRAM latency with a SIMT architecture, so they've went for complex opaque branch prediction and speculative execution instead.
The way C is built and deployed in practice didn't leave room for recompiling code for a specific CPU, so explicit scheduling like VLIW failed. Instead there's implicit magic that works with existing binaries.
When there were enough transistors to have more ALUs, more registers, more of everything in parallel, C couldn't target that. So CPUs got increasingly complex OoO execution, hidden register banks, and magic handling of stack as registers.
Contrast this with the current GPUs that have register-like storage available that is explicitly divided between threads (sort of like 6502's zero page – something that C couldn't target well either!)
The author apparently has never heard of microcontrollers, or in fact is aware that the 68000 is still in widespread use and in production to this day, nearly half a century later.
The author's entire argument seems to be that modern x86 CPUs are completely and totally distinct from the simple processors of yore, and one cannot apply the same mental model to them. That's fair, even if it's not strictly true.
Then they take a logical leap to say that nobody can program bare metal x86 like a 68000, therefore C cannot be a low level language at all in any circumstances for any platform. Which is just obviously false?
On simple CPUs like modern RISCs and AVRs or indeed 68000s, C is just assembly with extra steps. We still program these CPUs the same way we have for decades. In this situation, C is as bare metal as it gets without writing assembly. In C, you're still manipulating CPU registers, you still have to manage memory yourself, you're still programming the machine itself with only the lightest of abstractions.
If the author wanted to claim that there is no such thing as a low level language on x86, that's fine. I strongly disagree, but it's a valid argument. Asserting that C is not a low level language is not a valid argument.
Is C a bad model for modern processors? Yes, absolutely. Does that reflect on C itself in any way? No, these are two different things. We absolutely do need a better model and language than C for modern systems, but C is still the same as it's always been. It's still a low level language because millions of developers still use it on simple non-pipelined CPUs every day. The existence of other types of processors doesn't somehow change that fact.
If it has inline assembly it’s low-level in my opinion. This feature (or at a minimum the ability to link against and interface with assembled objects) is _the_ requirement for all hardware-facing programming, since general purpose programming languages cannot represent all possible hardware minutiae within the language.
> it is possible to make C code run quickly but only by spending thousands of person-years building a sufficiently smart compiler
Just because some of the C++ code I write heavily relies on ISA-specific SIMD intrinsics doesn’t replace the language with some other one, it’s remains to be C++. Compared to solving the general problem by making a sufficiently smart automatically vectorizing C compiler, learning SIMD intrinsics is way more manageable.
BTW, a few years ago I wrote an article about SSE 1-4 and AVX 1-2 ISA extensions, as exposed to C and C++ languages: http://const.me/articles/simd/simd.pdf
I would say it is only a low level language if it's a form of assembly or used in systems programming like Linux or OpenBSD or whatever else in the kernel land
Yes it is. I’m unswayed by your arguments. You start out by defining a low level language, concede that C meets your definition, and then go on to argue that even so, it’s not a low level language.
Yeah, it's weird. State the definition, admit that C meets it, and then argue that the definition is wrong? Hey, author, you put forward that definition. Maybe you should propose one that you think is more accurate?
>> "A programming language is low level when its programs require attention to the irrelevant."
Wow, today I learned there are only low-level programming languages.
I guess that means assembly is a high-level language. Assembly requires careful attention and everything is important.
In fact, one could argue that assembly removes everything irrelevant and is the highest-level language possible.
>from epigrams on programming
It's not meant to be taken seriously
By many of these arguments assembly is also not a low-level language
It is! I think that's not an accident.
CPUs evolved to execute C-like code quickly. They couldn't dramatically change the way C interfaces with the CPU, so they had to change the hidden internals instead.
For example, CPUs didn't have an option to hide DRAM latency with a SIMT architecture, so they've went for complex opaque branch prediction and speculative execution instead.
The way C is built and deployed in practice didn't leave room for recompiling code for a specific CPU, so explicit scheduling like VLIW failed. Instead there's implicit magic that works with existing binaries.
When there were enough transistors to have more ALUs, more registers, more of everything in parallel, C couldn't target that. So CPUs got increasingly complex OoO execution, hidden register banks, and magic handling of stack as registers. Contrast this with the current GPUs that have register-like storage available that is explicitly divided between threads (sort of like 6502's zero page – something that C couldn't target well either!)
The author apparently has never heard of microcontrollers, or in fact is aware that the 68000 is still in widespread use and in production to this day, nearly half a century later.
The author's entire argument seems to be that modern x86 CPUs are completely and totally distinct from the simple processors of yore, and one cannot apply the same mental model to them. That's fair, even if it's not strictly true.
Then they take a logical leap to say that nobody can program bare metal x86 like a 68000, therefore C cannot be a low level language at all in any circumstances for any platform. Which is just obviously false?
On simple CPUs like modern RISCs and AVRs or indeed 68000s, C is just assembly with extra steps. We still program these CPUs the same way we have for decades. In this situation, C is as bare metal as it gets without writing assembly. In C, you're still manipulating CPU registers, you still have to manage memory yourself, you're still programming the machine itself with only the lightest of abstractions.
If the author wanted to claim that there is no such thing as a low level language on x86, that's fine. I strongly disagree, but it's a valid argument. Asserting that C is not a low level language is not a valid argument.
Is C a bad model for modern processors? Yes, absolutely. Does that reflect on C itself in any way? No, these are two different things. We absolutely do need a better model and language than C for modern systems, but C is still the same as it's always been. It's still a low level language because millions of developers still use it on simple non-pipelined CPUs every day. The existence of other types of processors doesn't somehow change that fact.
If it has inline assembly it’s low-level in my opinion. This feature (or at a minimum the ability to link against and interface with assembled objects) is _the_ requirement for all hardware-facing programming, since general purpose programming languages cannot represent all possible hardware minutiae within the language.
> it is possible to make C code run quickly but only by spending thousands of person-years building a sufficiently smart compiler
Just because some of the C++ code I write heavily relies on ISA-specific SIMD intrinsics doesn’t replace the language with some other one, it’s remains to be C++. Compared to solving the general problem by making a sufficiently smart automatically vectorizing C compiler, learning SIMD intrinsics is way more manageable.
BTW, a few years ago I wrote an article about SSE 1-4 and AVX 1-2 ISA extensions, as exposed to C and C++ languages: http://const.me/articles/simd/simd.pdf
I would say it is only a low level language if it's a form of assembly or used in systems programming like Linux or OpenBSD or whatever else in the kernel land
I would say that any language that has if-else instruction, for loop, and the ability to define functions/procedures is "high level".
You can do all those things with a macro assembler.
Assembly has all of these features.