5 ms·

Why do you talk about 'the real base ISA' solidifies? The 'real base ISA' is solidified and its designed to let you run a lot of software at minimal complexity.

by nickik 8y ago

Why do you talk about 'the real base ISA' solidifies? The 'real base ISA' is solidified and its designed to let you run a lot of software at minimal complexity. The problem is that there is NEVER one optimal ISA for all applications. It makes absolutely no sense to have V, T, J extensions in the new 'real base' because there are tons of systems that don't ever need it and it would be a waste. That's why the RISC-V foundation defines profiles for certain application domains. RV64GC is the logic one for Linux for the moment. Also you ignore that very often an ISA is not used as a mass market product, but rather in a smaller more specialized space. The costume extensions are very important for people like that. In other cases, the potential AI extensions for vector for example, will probably never gone show up in standard profile for Linux. I think what we are like gone see is that RV64GC will remain the base level for the Linux profile and eventually more advanced profile with V and potentially others will emerge. The whole point is that no long build everything around ISAs that is never optimal but rather around profiles.

phkahler 8y ago
>> Why do you talk about 'the real base ISA' solidifies? The 'real base ISA' is solidified and its designed to let you run a lot of software at minimal complexity. The "real base ISA" will be whatever set of options becomes widespread 10-15 years from now. In my mind it's entirely feasible (though not as likely) that the approach of using hundreds of minion cores (see Esperanto) to do graphics will become a common thing (since there is no free GPU and none around the corner). If that is the case, the V extension will become part of the "real base ISA" because everyone will want it. So far the A and C extension went from optional to necessary - it would be naive to think it will stop there. Also, as implementations improve someone may come up with a low cost (low area) way to implement DSP instructions. Maybe that becomes common because the low additional cost is a "why not?". That's part of my point too, the flexibility will bring innovation and that may lead to certain things naturally becoming part of most peoples expectations. It looks like OpenGL has done something similar. They had a few specifications (ES in particular) for different classes of hardware, but as it became clear that certain features could be handled by the lesser hardware variants those became part of the standard.
- nickik 8y ago
  Again, I don't see how even in that case, the V extension would be part of 'the real base ISA'. You seem to again ignore that there are many, many applications that don't need or want a graphics card or SIMD of any kind. What you are talking about is not the 'real base ISA' but the 'real os application profile'. By not hard coding these choices into the ISA you have much more freedom to create new profiles for future needs without changing anything about the ISA. > So far the A and C extension went from optional to necessary That is not the case. Its simple false. There are tons of RISC-V chips that don't have either, some of them are even in production. Before the Linux RV64GC profile was released there simply was no defined official standard for OS application like Linux. > Also, as implementations improve someone may come up with a low cost (low area) way to implement DSP instructions That already exists, its the P working group. > That's part of my point too, the flexibility will bring innovation and that may lead to certain things naturally becoming part of most peoples expectations. What you are missing is that 'most people expectations' are limited to a specific program domain. Nobody will ever expect graphics on a IoT edge processor. So the default profile for IoT will not include that.
  - cwyers 8y ago
    Is the volume for these specific problem domains ever going to get high enough to make yields worth it? There's a reason commodity CPUs took over.
    - nickik 8y ago
      RISC-V is designed to be universal. That means you have to support everything that is now dominated by MIPS, ARM, x86 and so on. There are lots of markets and even today we use lots of ISA. Lets remember that there BILLIONS of chips that are internal to companies doing other hardware and all of those should be RISC-V as well. So if you have that ambition you need to have a way to balance standardization and fragmentation. Profiles are way to find standards for specific use type primary in order to do software standardization on these profiles.
  - phkahler 8y ago

by nickik 8y ago

phkahler 8y ago

>> Why do you talk about 'the real base ISA' solidifies? The 'real base ISA' is solidified and its designed to let you run a lot of software at minimal complexity. The "real base ISA" will be whatever set of options becomes widespread 10-15 years from now. In my mind it's entirely feasible (though not as likely) that the approach of using hundreds of minion cores (see Esperanto) to do graphics will become a common thing (since there is no free GPU and none around the corner). If that is the case, the V extension will become part of the "real base ISA" because everyone will want it. So far the A and C extension went from optional to necessary - it would be naive to think it will stop there. Also, as implementations improve someone may come up with a low cost (low area) way to implement DSP instructions. Maybe that becomes common because the low additional cost is a "why not?". That's part of my point too, the flexibility will bring innovation and that may lead to certain things naturally becoming part of most peoples expectations. It looks like OpenGL has done something similar. They had a few specifications (ES in particular) for different classes of hardware, but as it became clear that certain features could be handled by the lesser hardware variants those became part of the standard.

nickik 8y ago
Again, I don't see how even in that case, the V extension would be part of 'the real base ISA'. You seem to again ignore that there are many, many applications that don't need or want a graphics card or SIMD of any kind. What you are talking about is not the 'real base ISA' but the 'real os application profile'. By not hard coding these choices into the ISA you have much more freedom to create new profiles for future needs without changing anything about the ISA. > So far the A and C extension went from optional to necessary That is not the case. Its simple false. There are tons of RISC-V chips that don't have either, some of them are even in production. Before the Linux RV64GC profile was released there simply was no defined official standard for OS application like Linux. > Also, as implementations improve someone may come up with a low cost (low area) way to implement DSP instructions That already exists, its the P working group. > That's part of my point too, the flexibility will bring innovation and that may lead to certain things naturally becoming part of most peoples expectations. What you are missing is that 'most people expectations' are limited to a specific program domain. Nobody will ever expect graphics on a IoT edge processor. So the default profile for IoT will not include that.
- cwyers 8y ago
  Is the volume for these specific problem domains ever going to get high enough to make yields worth it? There's a reason commodity CPUs took over.
  - nickik 8y ago
    RISC-V is designed to be universal. That means you have to support everything that is now dominated by MIPS, ARM, x86 and so on. There are lots of markets and even today we use lots of ISA. Lets remember that there BILLIONS of chips that are internal to companies doing other hardware and all of those should be RISC-V as well. So if you have that ambition you need to have a way to balance standardization and fragmentation. Profiles are way to find standards for specific use type primary in order to do software standardization on these profiles.
- phkahler 8y ago