Also, is it possible to use only a handful of RVC-enabled binaries on a system that otherwise doesn't use RVC? If so, it might not be so bad.
Some people building Linux-capable processors decided to include RVC.
Some people with Linux distributions (Fedora, Debian), seeing that all known current efforts to build linux capable processors were supporting RVC, and seeing the large benefits it provides, decided to build their distros using RVC.
If someone wants a Linux distro that doesn't use RVC .. it's not a problem. The instructions supported are exactly the same. There are no portability problems. If a package will build successfully with RVC then it will compile without it, no problem, with no additional human work. Just change one configure flag when you build the compiler (to default to rv64g instead of rv64gc). The only difference is the binaries will all be 30% to 50% bigger.
Some more build machines will be required, and a few GB of disk space. Theses are trivial things.
It's absolutely nothing like the difference between, say, armeabi and armhf or the differences between armv4, armv4t, armv5, armv6, armv7.
You might find my 15 minute talk at the RISC-V workshop interesting on this subject: https://rwmj.wordpress.com/2018/05/21/my-talk-from-the-risc-...
The bit about RISC-V on servers starts around 5 mins in.
I think your points in the video is important - or rather, should be important - but from the fragmentation of ARM it seems they are not as important to chip makers as they should be. However ARM's fragmentation seems to have not been a serious impediment to it's adoption.
I think though going forward the solution may be to target higher level machines (i.e. JVM). This obviously is not realistic for the kernel - but for software that most people want to run on RHEL it would most likely be fine.
ARM has distinctly not been popular in the data center (despite years of work). That's for many reasons but one is surely the fragmentation of the platform.
At least for the server realm, ARM defined the "Server Base System Architecture" standard
> https://en.wikipedia.org/w/index.php?title=Server_Base_Syste...
exactly to avoid fragmentation in an area where custumers desire standardization.
Can i ask off-topic about the build farm you mention (approx 12:00). Is build performance an issue ? How long do typical builds take ? Would a x5 performance improvement become a must-have feature ?
RISC-V has an extensible ISA so it's likely to be a mess by design. I'm huge fan of risc-v so I really feel bad saying this. It's telling that RV-IMAFDC is the base for unix systems. It was originally IMAFD = G, but now GC is the standard. Then there's the V extension which I think will be very important and it already sounds like it may be fragmented (graphics and AI may be extra beyond vectors). But then there is space in the instruction encodings explicitly for custom extensions.
These variations are important, and the ability to customize in a standard way is too. I think it's going to be an amazing decade or two in the CPU space because of risc-v but it's also going to be a lot of churn IMHO.
Once open designs catch up to the state of the art and a real base ISA solidifies I hope a RISC-6 comes along with a more optimal encoding and things become really stable for a long time. But that's just my optimism getting out of hand.
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.
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.
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.
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.
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.
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.
Perhaps ARM actually did have a point with their "FUD" campaign against RISC-V:
(EDIT: in particular, consider point 3).
RISC-V does allow you to define other extensions in a methodical and detectable way, and we intend to detect those at runtime (as you would, for example, with something like AES-NI or AVX on Intel). However RVC impacts every bit of compiled code so there's no way to deal with it at runtime (something like that would make all binaries much bigger and would greatly complicate the toolchain).
> The standard compressed ISA extension described in Chapter 14 reduces code size by providing compressed 16-bit instructions and relaxes the alignment constraints to allow all instructions (16 bit and 32 bit) to be aligned on any 16-bit boundary to improve code density.