Re: It bears repeating: Building a CPU that runs C fast considered harmful.
Whist in general I agree with your [ost, it is possible to optimise for certain high level languages.
C for example, along with many other languages uses (a/the) stack as a pointer to temporary variable space.
This avoids the overheads associated with memory allocation and garbage collection, but opens a security hole in that the stack is not just for data, but for instruction pointers as well.
So a chip designed for C MIGHT have a second data stack pointer. Or a register that represents the l
limits in the stack space where access is allowed.
Its not easy to cover all the bases, but it could be possible.
What I am saying is that chips were originally designed to run assembler, and the compiler was a faster way to write it.
Nowadays we know that they will probably be executing C code most of the time, and it makes sense to adjust the hardware to match that.
C does produce tight assembler that looks remarkably like C, but what it does not do is produce optimal assembler using constructs taht do not suit te language.
I never did manage to get an early C compiler to construct a call table - a list of addresses of subroutines to call depending on the index value in some register. Mostly because the syntax of indirection was so ugly and it hadn't been written to[parse it.
On the other hand a CASE statement or a set of ifthenelses was fine, if bulkier.
That is C.
Other languages that suffer/benefit from lots of dynamic memory allocation might in fact have chips with parallel cores handling the mapping of real memory to a virtual memory space, such as an SSD does ..thereby freeing the main cores from garbage collection and memory allocation
Or take FORTH. That is a language that benefits from certain hardware features too, but absolutely doesn't need loads of registers.
Hardware drove language development in the 70s. But the reverse is true today.
Biting the hand that feeds IT
