5 ms·
The past was CISC, past future was RISC, and present is CISC-decoded-to-RISC. Future looks like more of that, i.e. the shorter the opcodes, the better: if a sho
by faragon 12y ago
The past was CISC, past future was RISC, and present is CISC-decoded-to-RISC. Future looks like more of that, i.e. the shorter the opcodes, the better: if a short opcode can mean complex things, even memory-to-memory operations, it will not be a problem when being scheduled in OoOE CPUs.
In my opinion, we'll have following things to come:
- Simple in-order execution CPUs with tons of ALUs, as the generalization of current GPUs (a la Larrabee or AMD/nVidia/ARM VLIW). This would be used for graphics and signal processing.
- Complex OoOE CPUs with expressive ISA for complex r-r/r-m/m-m operations, transactional operations, runtime-defined opcodes, focused to maximize sequential execution. With operating system support, it could allow to re-optimize code, defining opcodes for groups of operations, so code could get faster/smaller (code self-compression de facto).
- Rusky 12y agoThe Mill CPU (http://millcomputing.com/ http://millcomputing.com/) seems to be going down both those routes- it's a very in-order, VLIW-like design with some tweaks to make it work well with typical OOE workloads, including several ways to make the encoding much smaller.
- faragon 12y agoIt looks interesting. The VLIW with OoOE approach will make sense, may be they will follow that path, some day. In my opinion Industry has not yet reached global adoption of that because of having still some room for enhancements, being the macro-ops from Intel/AMD the last bullet in that regard. IMO, if not explicit VLIW ISA, current ISAs (x86 and ARM) will follow a de facto VLIW transcoding, like Transmeta did back in the day (they had no OoOE VLIW, but in-order VLIW, in order to reach their power comsumption goals).