3 ms·

The primary issue is the subsets of possible extensions to the core. Can it replace ARM? maybe in some roles that only require core features. Will it become

The primary issue is the subsets of possible extensions to the core. Can it replace ARM? maybe in some roles that only require core features. Will it become the popular standard? probably not, as the groups failed to learn what ARM did wrong. Most popular ARM cores have many advanced features disabled in the compilers for a few reasons: 1. Some ARM ASIC advanced features would err on some chips, or were simply unavailable on some silicon revisions. 2. Deploying chip specific compilers is unsustainable commercially when your competitor can port in billions of dollars of work with gcc (as bad as it is) 3. a complete RISC-V implementation with floating point and DSP extensions should have been the minimum core. Without these features, it dropped the whole generation 1 chip hardware into the low-end mcu domain. A saturated market, that has already fragmented. Is there possible solutions? Complete a fully open 64bit core with mmu, fpu, and DSP. Then give the design to companies that have had a proprietary hardware issue for decades like microchip. Allowing companies to make proprietary design variants was a mistake. Happy computing =)

deleted 4y ago
[deleted]
TheMagicHorsey 4y ago
> 2. Deploying chip specific compilers is unsustainable commercially when your competitor can port in billions of dollars of work with gcc (as bad as it is) Is it really that prohibitive to have your own custom compiler with LLVM (and CLANG)?
- Joel_Mckay 4y ago
  There are very good reasons llvm are not used in Real-Time systems. When running in multitasking environments it doesn't really matter. =)
  - daworl 4y ago
    Not coming from a Real-Time background, I'm quite curious as to why? Do you have some sources to point me to?
    - Joel_Mckay 4y ago
      The simplest explanation is the code motion optimization behavior, and even regular compilers must turn this off in some circumstances. Much of what makes llvm performant, can also make unpredictable execution times and latency worse. There is a deep rabbit hole here, that touches on clocks/hardware/schedulers like RTLinux OS/RTOS/compilers. I am the wrong person to teach you this subject. ;)
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

deleted 4y ago

[deleted]

TheMagicHorsey 4y ago

> 2. Deploying chip specific compilers is unsustainable commercially when your competitor can port in billions of dollars of work with gcc (as bad as it is) Is it really that prohibitive to have your own custom compiler with LLVM (and CLANG)?

Joel_Mckay 4y ago
There are very good reasons llvm are not used in Real-Time systems. When running in multitasking environments it doesn't really matter. =)
- daworl 4y ago
  Not coming from a Real-Time background, I'm quite curious as to why? Do you have some sources to point me to?
  - Joel_Mckay 4y ago
    The simplest explanation is the code motion optimization behavior, and even regular compilers must turn this off in some circumstances. Much of what makes llvm performant, can also make unpredictable execution times and latency worse. There is a deep rabbit hole here, that touches on clocks/hardware/schedulers like RTLinux OS/RTOS/compilers. I am the wrong person to teach you this subject. ;)

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