3 ms·
DSP and Quaternion operations in the core ASIC would greatly simplify a lot of code (as would pipeline media codecs). The problem with such instructions has a
by Joel_Mckay 4y ago
DSP and Quaternion operations in the core ASIC would greatly simplify a lot of code (as would pipeline media codecs).
The problem with such instructions has always been how to get compilers to leverage such feature automatically (see 30 years of GPU kludges). Perhaps some sort of standardized static library template could create/emulate a set of abstractions for the special opcodes within regular compiler contexts (i.e. still cross platform compatible like OpenCL, and hides the ugly inline assembly during binary optimization).
"RISC-V actually has a better story here", Time will tell, but we have all seen a lot of "better" cores disappear over the years. ;)
- hajile 4y agoYou could do this with a custom extension. No particular solution has proven to be definitely better than the rest, so I'd rather them hold off on officially endorsing one method and getting it wrong then being stuck with that forever.
- Joel_Mckay 4y agoTraditionally on CISC the process was: 1. Identify high-level language output greatest common sequence in binary image code regions 2. Check if that sequence profiles in the top CPU usage of generic processes 3. optimize that sequence in the languages 4. verify improved performance 5. repeat until you reach the no-op delay loops 6. Add optimization in the compiler 7. verify improved performance with sub-optimal original language samples 8. add optimization to ASIC 9. replace optimizations in the compiler with new opcodes 10. verify improved hardware performance with sub-optimal original language samples With RISC, many argued such processes were unnecessary, as every complex op can be emulated in simple code with a faster CPU. This ignores that fact Moore's law is effectively dead.
- notacoward 4y ago> This ignores that fact Moore's law is effectively dead. It wasn't ignoring anything. Moore's law wasn't dead at the time, and awareness of it very much informed the development of RISC.
- Joel_Mckay 4y agoMy point was the same reasoning does not hold for RISCV in replacing ARM or amd64 architectures. Remember when the Transputer was proposed as a replacement for the RISC/busy-register CPUs... fail... Enhance your calm. =)
- deleted 4y ago[deleted]
- notacoward 4y agoI was responding to what you actually said. If you meant something else you should have worded it better. Have a great day. You're the best. Peace and love.
- zozbot234 4y agoThat's not too different from how the B and K extensions for RISC-V were designed...
- Joel_Mckay 4y agoQuantifying the original assertion model variant/fragmentation being a problem for long term standardization as an architecture. =)