3 ms·
The problem with simple high-performance RISC (and to even larger extent VLIW) designs is that invariably micro architecture details are going to leak into inst
by dfox 10y ago
The problem with simple high-performance RISC (and to even larger extent VLIW) designs is that invariably micro architecture details are going to leak into instruction set, either explicitly (branch delay slots, instruction combinations that do not handle hazards, weird memory models) or implicitly in form of micro architecture specific performance traps.
And main thing that seems to be required for general purpose computing is binary compatibility, which can be done almost for free on CISC designs while it makes RISC designs into complex nests of special cases.
Micro architectures that are not designed to directly execute user code (GPUs and such) do not have this problem and thus can do anything that makes the hardware go fast regardless of whether the resulting ISA looks sensible and whether it can be implemented in any other way (eg. drop pipeline stalls and forwarding paths, have separate register set for each execution unit...).
Another thing that limits general purpose CPUs is multitasking as it requires context-switches to be reasonably cheap, which means reasonably small and accessible architectural state (ie. not hundreds of architectural registers).
- jakub_h 10y agoIt sounds horrible that we should compromise potential performance (including per watt and per transistor) by giving up on (micro)architectural flexibility. Why should branch delay slots, instruction combinations that do not handle hazards and weird memory models matter in an era in which something like IBM's TIMI could be used for compatibility if you need it, and native ISA accessed if you don't or if you have your own toolchain?
- dfox 10y agoThat seems to be caused by market forces. Customers expect CPU's that are backward compatible by themselves and do not depend on few tens of MB worth of binary blobs for backward compatibility, microcode of modern x86 CPUs does not count as such blob as it's essentially invisible (it can be patched, but the CPU still looks like x86 when you don't load any blobs into it). (edit: it's also probably immaterial whether such blobs are or are not opensource) Also, TIMI is probably not good example of how to implement high performance ISA abstraction as it's about abstraction first and performance second. Transmeta's x86 CPUs and things like HP Dynamo have better approach to this problem.
- vertex-four 10y agoTheoretically, if Mill isn't vaporware, its plan is to distribute binaries in a format independent of certain hardware implementation details, and have a "specializer" in the BIOS or kernel to compile from the generic instruction set to the machine-specific instruction set on demand, reordering operations and grouping them into instructions, inserting delays, and spilling belt (register) contents to on-chip RAM where necessary. Essentially, the idea is to move all the CISC stuff out to software, and do VLIW internally. That could possibly help?
- kjs3 10y agoTheoretically, if Mill isn't vaporware... I see the problem with your conjecture.