Re: It bears repeating: Building a CPU that runs C fast considered harmful.
Both you and the website you have linked maintain a distinct lack of knowledge:
Processors do not run C code. Processors do not even run assembly. They run CPU instructions. When you compile a C program, it is turned into assembly, which is translated into instructions. When you run your "hello world" Java program, it is turned into corresponding assembly just in time to become instructions to be run. When you compile a Rust program, it is turned into assembly, which is translated into instructions.
The way CPU instructions (and therefore assembly) works is long and complicated, but it's essentially short computation instructions. Move address A to C. Divide address A by B, sending results to A. Grab a new free address, so we're not limited to addresses that were compiled in. Read from an output of another program that controls the keyboard, sending this number that represents a letter to that dynamically decided address. Simple stuff.
If you've ever read both, you'll notice C is quite close to assembly it becomes. In fact, it suffers from many of the same problems. In fact, it suffers from those problems because it doesn't try to abstract too much from the assembly it will ultimately be. When another language works around this, it does so by automatically working around it when compiled. This is abstraction, because you don't control it. Ultimately, it makes no difference, and the resulting assembly has no discerning features that point to one language or another.
Processor makers do not design for C because they have no way to figure out if the instructions they get are from C code, it could be from literally anything else. Because that's not how compiling works. All those processor problems claimed as workarounds to improve running C? It improved running code of literally every language on that processor as well. Because everything is instructions. The problem here is how instructions for a programmable calculator work, which ultimately decides how assembly is designed. Not C.
Additionally, I absolutely dare you to make a CPU incompatible with C. If you do, you will also find everything else is.
Biting the hand that feeds IT
