>>68
The hardware designers shouldn't be dumbing-down the ISA for stupid compiler writers.
It's not ``dumbing-down the ISA'' because the x86 ISA already is dumb. What's dumb is having to push things onto the stack because operands need to be in certain registers. What's dumb is needing "instruction sequences" to do things that RISCs can do with single instructions. What's dumb is booting in 16-bit mode and having megabytes of firmware that can't be used after the boot process because they're still made for 16-bit OSes. What's dumb is still expecting software to fit the hardware even though all of Intel's attempts to do that (TSS task switch, 32-bit segmented mode, A20 line, lack of V86 in the 286) have failed. I find it easier to write assembly for ARM than for x86, but I guess it would be ``dumbing-down the ISA'' for stupid assembly programmers too.
Hardware should be designed for the programmer, to fit the software, not the other way around. Why make programmers and compiler writers bend over backwards at Intel's whim?
Perhaps I should say "misguided" and not "stupid", since the problem seems more that they are not approaching the task of code generation in the right way.
What is ``the right way''? Most CPUs have a flat register file and a separate flat register file for floating-point. x86 has quirky integer registers and a stack for floating-point. Do you mean that compilers should use a separate back-end for x86 just because Intel wants to pretend it still has an accumulator?