4 ms·
Neither V nor B are ratified, nor are they part of the Unix platform standard (and hopefully never will be). V is close, B is not. There are exactly 0 chips o
by FullyFunctional 6y ago
Neither V nor B are ratified, nor are they part of the Unix platform standard (and hopefully never will be).
V is close, B is not. There are exactly 0 chips or even IP on the market with standard B (which is really a family of sub-standards), but there are chips with pre-standard V (alas, a few of them aren't compatible with the current draft - the perils of running ahead).
Overall, yes you are right, this is most useful for people interested in seriously evaluating RV64GC and/or porting code. It's a one of the necessary steps on the path to more adoption, but not the last one.
- snvzz 6y ago>(and hopefully never will be) Do you have a rationale for this? I understand that: * The unix platform standard is a relatively fat selection of extensions already. * The nature of V's flexible width allows it to be implemented in very small scale to very large scale, so it would have little impact on the complexity of the minimum platform, while allowing great benefits as it scales up to larger platforms.
- FullyFunctional 6y ago1. Cores already exist or are coming that satisfy the existing platform. They would be obsoleted by a change in the requirements. 2. RV64GC is already quite big. Piling more requirements onto it will make it harder to introduce small cores. 3. V is pretty complex and I don't agree with your assertion. In contrast I'm aware of cores with vector where the vector part takes up 50% of the die and does exactly nothing for the scalar apps that don't use it. I'd much rather spend that silicon on more IPC or a 2nd core.