Wow, today I learned there are only low-level programming languages.
In fact, one could argue that assembly removes everything irrelevant and is the highest-level language possible.
It's not meant to be taken seriously
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
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.
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!)
OSDeveloper•8mo ago
Detrytus•8mo ago
renewedrebecca•8mo ago
mystified5016•8mo ago