4 ms·
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
by 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 agoIs 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 agoRISC-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 agoI guess I'm talking about the base ISA for unix systems. This whole discussion started because someone designed a processor without the C extension and now they have to rebuild every Linux package without that. The base ISA for unix like systems was originally G (IMAFD) without C and it changed. So the base for unix systems will be whatever the major distributions decide it will be regardless of what the RISC-V foundation says. So far they are in alignment. If the P extension ends up costing little area beyond GC and a bunch of developers want it because of audio/video applications they're going to want to rebuild everything with it by default - because server chips should just include it anyway. I'm not saying this exact scenario or the V on will come to pass, just that I expect the standard set of options widely in use will continue to change like it already has.
- nickik 8y agoG was just a shortform to bundle commen extentions, it was never defined by the foundation as 'the base ISA for linux'. That was just what the first released version of RISC-V spec had in it. I would assume that the V,B,J and possibly P extentions will all end up in the most used linux profile. However I think the RV64GC will still be the relevant fallback that most distros will over to cover a very large range of chips.