Originally posted by jabl
View Post
When you look at the sheer extent of the extensions space (how many extensions were talked about at the meet-up last week? twenty? thirty? some insane number) it seems hard to believe that this is viable on-going path. Maybe OK if your goal is to stick with the world of very limited high volume MCUs running bespoke code that's never updated, but unlikely to get you out of that ghetto and even to the world of Raspberry Pi's, let alone the promised land of phones, servers, and desktops.
So what happens next? I have no idea. It's is clear that academia has embraced RISC-V for all the reason you'd expect. It's equally clear that academia wants to generate an on-going stream of new extensions, again for all the reasons you'd expect; and that the companies making these cores all want their special snowflake to be different from everyone else (and ideally leaving just painful enough to make it not worth doing). Not sure why anyone expected things to turn out differently.
So do we now get something like the WiFi Alliance, an industry group that POLITICALLY does not set standards, oh no, that's for the RISC-V Foundation, and they take no stance on extensions; but that PRACTICALLY says "here's what WE support --- you get our blessing if you support it and good luck if you want to do anything else"?
As for the "it's a better ISA", come on. Better based on what?
It's an *adequate*, easy-to-decode/implement ISA, like a hundred other RISC ISAs. It avoids the most unfortunate errors of many of the early RISC ISAs, but it shows no flashes of genius (something that I think is frequently evident in the AArch 64 ISA). At every stage faced with the decision of "what's easiest to implement" vs "what would be the most powerful" (in some sort of sense) RISC-V has gone for ease of implementation. Which is fine for MCUs, but doesn't mean that you have some sort of wonder-ISA, and means that you're starting from behind when it comes to trying to grow up into phones and beyond.
(The sorts of things I mean are the AArch64 CSel options, the way ARM encodes immediates, load-store pairs, all that sort of stuff that's harder to implement but substantially amplifies the power of your instruction set once you've crossed the implementation hurdle.)
Comment