3 ms·
VLIW processors with dynamic configuration of the opcode instruction group has a lot of potential in the future, in my opinion. E.g. 128 or 256 bit "opcode grou
by faragon 11y ago
VLIW processors with dynamic configuration of the opcode instruction group has a lot of potential in the future, in my opinion. E.g. 128 or 256 bit "opcode groups" with variable-size opcodes, using their own temporary registers, even custom programable opcodes for ad-hoc opcode compression, etc.
The failure of the Itanium because of cheap x86 chips doing "macro-op" execution, more efficiently than the Itanium explicit VLIW, is the other side of the same coin: no matter if explicit or implicit, the way to increase single-thread IPC (instruction per clock) rate is doing more in parallel and hiding execution latency. So, explicit, or as hidden abstraction, VLIW-esque execution seems to be unavoidable.
- WallWextra 11y agoParallel, speculative execution is what's unavoidable. The VLIW idea of statically compiler-scheduled parallelism and speculation has not been successful for general-purpose code. The last generation of Itanium abandoned explicit, statically-scheduled parallelism and switched to out of order execution, like every fast general-purpose CPU uses.
- anon4 11y ago> has not been successful for general-purpose code Let me interject that it has also not been successful for AMD's line of videocards - they used a VLIW architecture before transitioning to a SIMD architecture codenamed Graphics Core Next or GCN in 2011. nVidia had been using SIMD for quite a while before that, but some of their latest cards have a few VLIW features like the option to explicitly specify parallelism between instructions.
- WallWextra 11y agoApparently they switched because VLIW wasn't good for GPGPU workloads, which is in keeping with the general theme, that VLIW works very well on certain highly-specific DSP-ish workloads.