Well, C is an Algol-type language, it just has different syntax and ordering of parameters, but the basic internal workings are the same. This is why AT&T’s own processor designs were “stack like”, conceptually they were stack machines but had hardware to make the stack work quickly. At least, to my limited knowledge of how they worked.
That’s an interesting question actually. I have one Intel machine in my home, two Macs, an iPad and two iPhones. I think the router is ARM as well. We also have a Nest, and I don’t know what that uses, and then various appliances.
ARM definitely outsells and out populates Intel by a wide margin these days, there’s something like 300 billion active ARMs in the world. Intel doesn’t publish numbers, but there are something like 3 billion laptops and desktops in the world, and 70% are intel, so maybe 2.5 billion on the outside. That’s x86-ish Intel, not all their other designs.
I’d bet the total number of “others” is probably around the same as ARM, at least the same order of magnitude. There’s some sort of moderately complex controller in my thermostat, and the furnace and other appliances all have simple controllers, so maybe a dozen total?
You could make “real” RISC at any time, and I recall one such design for a minicomputer - Raytheon perhaps? No, not them, it was one of the US industrial/aerospace companies anyway.
RISC was really aimed at addressing one issue: microcode. In the Moto 68k, you had ~68,000 gates, of which about 23,000 were running the microcode, and taking up, along with the code store, something like 1/4 to 1/2 of the entire chip. And yet, as Codd demonstrated, the vast majority of these instructions were never used. Removing all the fancy addressing modes made the otherwise identical actual processor inside much cheaper and run faster because there was no overhead decoding everything. So now you can build a processor on exactly the same line that has the same internal guts with half the transistors (or less, the original MIPS was ~23k IIRC), or use the same 68k transistors, but now it has, for instance, a complete 32-bit ALU instead of 16-bit, and maybe more registers, and maybe a pipeline. Those will all make the processor run way faster than all those fancy instructions no one was using in the first place.
Microcode costs. Cost was meaningless to IBM, and the advantages are huge for them - it lets them completely re-engineer the actual machine while all their programs keep running. This is Intel’s model to this day. But for a microprocessor designer, where lowest cost/performance is the main goal and you don’t have backward compatibility to worry about, what’s the point? Moto seems to have added all this because “that’s the way you design processors, just look at IBM and DEC”. When I was in uni I took a course on CPU design and it basically just right out assumed microcode was the only way to make one.
Now why weren’t people using all those fancy instructions? Mostly because the compilers didn’t. Why didn’t they? What Codd found was that they selected the one version of any instruction that they knew ran the fastest on the lowest-end machines, because then at least it wouldn’t bog down on those platforms, and if we’re giving up some performance on the higher-end systems, well, such is life. They didn’t have the memory or performance needed to put in code to figure out the best instruction for any particular machine, and that killed the cross-system compatibility (in a way), so they punted.
Today this is not a problem, our compilers do dozens of passes across the code, and they can easily take advantage of these sorts of things. So we see people trying things like VLWI and such where more of the load is put on the compiler. The Mill is also sort of attacking that issue too, but in a different way.
