5 ms·
No, the problem is not that modern CPUs want to be a PDP-11, it's that they want to be an 8086 for compatibility reasons. From the software's perspective, the
by snickerbockers 4y ago
No, the problem is not that modern CPUs want to be a PDP-11, it's that they want to be an 8086 for compatibility reasons. From the software's perspective, the ISA *is* the hardware. It doesn't matter if the CPU is internally recompiling everything to a RISC-like architecture with an arbitrary number of registers because there's nothing i can do to access that.
If there's ever a radical new ISA which supplants x86 where C's constructs prove to be a bottleneck, and that ottleneck only applies to C, you will finally see it fall to the wayside.
>These types of arguments feel like they come from people who don't realize how much the compiler reworks your code to make it act like it does what you told it to do.
I guess it's hard to argue against a vague undefined term like "rework" but i can assure you that the output of gcc largely resembles what i expect it to. If the compiler does something bizarre i will know about it because i actually do check the assembly.
- bhawks 4y agoOP links to: https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 Which in the very initial paragraphs points out it is not about having a hidden set of registers to work with - it's about exploiting parallelism and the tension between a sequential programing language and massively parallel hardware architecture. The ISA is not the hardware it's a 40 decade old abstraction that the hardware bends itself into to make your code run.
- mpweiher 4y ago> From the software's perspective, the ISA is the hardware Precisely! And because the weirdness happens below the ISA, all the mismatches Dave Chisnall describes apply to any other language just as much including actual machine language. So raw machine language is not a low-level language? <head scratch>.
- bhawks 4y agoIt is rare to build general purpose computing hardware in lockstep with software. The two worlds are only bridged by the ISA interface. It'd be interesting to see what interface we'd choose today with multiple decades of hardware and software development.
- mpweiher 4y agoConsidering we're still trapped by the Gentle Tyranny of Call/Return, we'd probably choose the same interfaces...never mind the huge path-dependence on optimising all the parts around those interfaces. I have a sneaking suspicion that a more dataflow-oriented interface might be useful. The CPUs do dataflow analysis, the compiler does dataflow analysis, and higher levels are also often dataflow, but all communicate using a non-dataflow instruction stream. On the other hand, the only commercial dataflow CPU I am aware of, the NEC 7281 (http://www.merlintec.com/download/nec7281.pdf http://www.merlintec.com/download/nec7281.pdf) was less than successful.
- AshamedCaptain 4y ago> It'd be interesting to see what interface we'd choose today with multiple decades of hardware and software development A worse one? Not a couple days ago there were a couple stories about Itanium here on HN (a designed-from-scratch ISA that turned out to be practically worse than the much more ad-hoc x86_64). Even e.g. RISC-V (which is not entirely free of legacy) is practically 1:1 with ancient ISAs like ARM.
- astrange 4y agoARM is an evolving ISA. AArch64 is quite different from ARMv7, and has nicer security features than the other leading brand, who can barely manage to ship SGX.
- AshamedCaptain 4y agoIt's not like x86 or RISC-V are not "evolving ISAs" either. And personally I would classify SGX and other "security" features as misfeatures, but that's for another day...