3 ms·

Standardization at the MCU level doesn't matter very much. I can't just write code for ARM chip with M0 from company A and expect it to work with an M0 from com

by hajile 4y ago

Standardization at the MCU level doesn't matter very much. I can't just write code for ARM chip with M0 from company A and expect it to work with an M0 from company B. Likewise, having an M3 chip doesn't guarantee it will have Floats or SIMD (IIRC, it doesn't guarantee SIMD width either). And even going between M-series chips can change stuff like which Thumb 1/2 instructions are available. You're always a slave to whatever company's compiler and garbage Eclipse clone. RISC-V actually has a better story here. You basically have RV32IC (compressed will always be there outside of extremely niche chips because 400 gates for 25-35% smaller code saves more in RAM/ROM than it costs). Optionally, you may have Zmmul for only hardware multiplication or M for both multiplication and division (shouldn't make a difference outside of the size of the software routines if they are needed). On the desktop side, There are only two profiles that would actually be used -- RVA20S64 and RVA22S64. By the time actual desktop processors are finished, RVA24S64 will likely be around and make a couple optional extensions required. https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc https://github.com/riscv/riscv-profiles/blob/main/profiles.a... Ultra-tiny cores using the still not finalized RV32E may exist in the future, but a company choosing them would know full-well the tradeoffs they were making. The only poorly-specified area is DSPs, but that's a problem for the entire DSP industry. There are a lot of requirements from the barely-DSP up through units doing a lot of signal processing. On the whole, I'd prefer to look at a handful of letters than have to dig through hundreds of pages of esoteric manuals.

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 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]
        4y ago

by hajile 4y ago

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 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]
      - 4y ago