4 ms·

You 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 en

by hajile 4y ago

You 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 ago
Traditionally 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 ago
    My 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 ago
      I 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 ago
  That's not too different from how the B and K extensions for RISC-V were designed...
  - Joel_Mckay 4y ago
    Quantifying the original assertion model variant/fragmentation being a problem for long term standardization as an architecture. =)

by hajile 4y ago

Joel_Mckay 4y ago

Traditionally 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 ago
  My 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 ago
    I 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 ago
That's not too different from how the B and K extensions for RISC-V were designed...
- Joel_Mckay 4y ago
  Quantifying the original assertion model variant/fragmentation being a problem for long term standardization as an architecture. =)