Qualcomm talks up RISC-V, roasts 'legacy architecture' amid war with Arm As Qualcomm tries to fight off a lawsuit from Arm demanding Qualcomm destroy its custom cores, the Snapdragon giant has signaled it may have a bigger future with RISC-V. And that's all while Qualcomm criticized an "existing legacy architecture" for having useless features and not meeting certain requirements. At the RISC-V …
We can proliferate to hell it with custom instruction set extensions that make it impossible to grow an open ecosystem, and thus ensure that it is an much more difficult for an upstart to develop the firmware blobs that are critical locking for our chipset+blobs monopoly.
It's very easy to see how this kind of instruction set manipulation works very well for a giant incumbent against upstarts who want a toehold, as another anti competitive layer in the Qualcomm onion
Exactly this. As former chip-design upper-middle-management in the Q, this is exactly the solution I would be pursuing with my senior veep, to be embedded into Snapdragon. And now is the perfect technological time to do it. Custom “RISCV” instructions would be “something AI”, maybe a layer of CNN, but with some “special Qualcomm sauce”.
The benefit is that such an instruction doesn’t need to be fully publically defined like an adder, instead just spec what the target outcome is, e.g. interrupt on trigger-phrase, object-detect-in-image, or photo-enhance. Hard to copy, easy to argue that anyone else’s version is both a poor substitute *and* an infringement on Q IP. And bingo, you now have an app ecosystem that only the “premium” 70% of smartphone manufacturers that buy Snapdragon anyway can support.
Welcome to the future that the open-source evangelists built.
Honestly this is why, word for word, ARM does not often sell architecture licenses and prohibits custom instructions.
The reason ARM standardized the CPU + interrupt controller and forced custom hardware out of the CPU into accelerators was to create an ecosystem of good compilers, transferable software and transferable employee skills vs. the absolute horror of the old ARM7 & ARM11 days.
ARM was getting stuck with the support burden of customized IP blocks, custom instructions, different interrupt controllers & the inability of software to be reused especially to design a compiler properly to support lots of this stuff.
On one hand, a great benefit of RISC-V is that you can add all sorts of crap to the base instruction set...but on the other hand fragmentation is a problem (when everybody else adds crap to the instruction set and things clash).
How does Qualcomm expect to rationalise these issues without basically making themselves a gatekeeper and, in the process, turning into a mini-ARM, only without the core IP to back them up?
They won't. They'll simply keep adding extensions that suit their needs and expect the entire value-chain (compilers, software libraries) to support them.
These big companies only pay lip service to standardization. The article mentions that Qualcomm needed specific extensions for its own needs, but they fail to elaborate what they were and why they needed them or why they couldn't have used other extensions. My guess is it just happened to work out for them financially or lead-time wise and they went with it, not caring whether anyone else had dome something similar.
They don't.
They want the open source 'community' to be the gatekeepers.
Meanwhile, they'll add on whatever junk they want to their SoCs, while making it so no one else can. And as long as maintain a market lead and so many devices use their SoCs... they'll get away with it.
Maybe they are looking at the success of other open source projects and thinking this could apply to hardware too?
It may not make sense to screw the platform you are heavily invested in?
Perhaps Arm will die and RiscV will grow for exactly this reason, and the early adopters will benefit the most?
Just a thought, but that is what most people are explicitly saying, and at first glance it seems to be working rather well.
IMO, the RISC-V instruction set will be defined by LLVM and GCC. You can add all the extra commands you like, but if the compiler doesn't generate the opcodes, it's a waste of silicon.
Also, GCC and LLVM will not want to generate code that doesn't run on all RISC-V chips, so it's inevitable that RISC-V will remain reasonably unfragmented.
I can see how porting Android will encourage a RISC V ecosystem to grow, but you are implying that said ecosystem could not grow unless an Android port was done.
Is that really the interpretation you intended? If so, can you explain why a lack of Android would be stopping RISC V elsewhere? Serious question - I don't see how Android is gate keeping other applications, but I'd be glad to be informed.
- confused of Tunbridge Wells
For Risc-V to be used on IoT devices, there's no need for an ecosystem as they're quite isolated. Hotpoint don't have to worry that their washing machine Smart AI UltraClean® software isn't portable.
For Risc-V to be used on TVs, phones, wearables, etc. (which pretty much all use android) app developers will need to see that the platform they develop for is mature enough so their apps can be easily supported on a wide range of devices. Until that happens device manufacturers won't risk (fnar fnar) changing SoC.
I love how Qualcomm references ARM as the "legacy architecture" as if they already have one foot in the grave.
If they are stupid enough to lose against ARM and change architecture out of spite, most of their customer base will have gone elsewhere before they drag RISC V up to anywhere close to ARM's current performance and performance per watt (for real production chips, not limited single core prototypes). We'll see who has one foot in the grave then.
When did the word "legacy" apparently gain an entirely negative sense?
In AU Legacy is an organization the supports the dependents of veterans and has no such derogatory sense - the legacy here, I imagine, is that we are not forced to speak german or japanese, or more tellingly that we are free to do so if we wish.
In my younger days a legacy was the couple of bob granny left you in her will.
When we have corroded this word to meaninglessness* are we to speak of "heritage" architectures?
*Five seconds after my telling a student who was complaining that a text had too many long words, that "words with more than ten letters were meaningless" ... oops. But its a good rule - the silly sod couldn't get past the learned introduction amongst other erudite front matter and was never getting to the text itself - dealing with the monkey...
I think with RISC-V gaining more momentum lately, there is no better time to create an open OS for mobile devices. Sure there are Linux versions for touchscreen but they haven't really caught on because Android already dominates it. If someone doesn't take advantage of this time to get a head start for when we do see RISC-V become common for phones then it will be much harder and more time consuming in the future.
They should chat up Samsung about maybe porting Tizen over to RISC-V and creating a few low-end phones for release in limited markets as a kind of proof of concept. I know Tizen has largely been relegated to TVs these days, but it is, and always has been, a direct Android replacement should Google ever try to push the license terms too far. It started out on mobile devices and then was retooled for TVs. Maybe even do a few TV sets where the SoC controlling it is RISC-V based, not ARM or whatever else it might be.
Then try changing the compiler target for those existing Linux versions to RISC-V and build a device around it. It won't do any better than ARM versions did, because the average user, and even the technical user when not building the device, doesn't care what instruction set is in there. A phone with RISC-V and a phone with ARM look the same to a buyer, at least if the processors are similar in performance and power consumption (which is probably not the case right now anyway).
Just because a part is undergoing a major change doesn't make it any easier to replace other components. The efforts to build a better mobile OS, which I wholeheartedly support, will not be boosted by a different ISA. We'll have to build them the hard way, which means that we'll get the same results if we stick with ARM and cross-compile later.
Exactly correct, with a side-order of "check out the history of all of the great-but-failed mobile OSes that fell by the wayside while the Android/iOS duopoly was establishing itself". (Meego, Tizen, Sailfish, Blackberry/QNX, Windows--three attempts, KaiOS, ...)
Oddly enough, the most likely path to a working alternative to Android might just come from Google themselves (Fuchsia).
Fine with me.
I think it may be a strategic mistake if they dump ARM entirely too quickly. There are those who just want to get the "one model faster" chip and not have to port anything.
On the other hand, Linux is portable, virtuallly everything that sits on top of it is portable (i.e. not x86/x86-64 or in this case ARM-specific), the kernel and compiler are ported to work with RISC-V. Even these embedded systems generally have a "linux from scratch" type of build setup, where they could probably just set the target from ARM to RISC-V, build, and have the full stack built, up, and running on RISC-V.
To be clear, this is in direct contrast to "Windows for ARM" where Microsoft has the NT-based kernel that was portable (x86, MIPS, PowerPC, PA-RISC, Alpha.. oh and at some point Itanium) like 20 years ago but with decades of code after that that was likely written with just x86/x86-64 in mind. I don't now if they've gone over things to make them truly portable, or if they've hacked in "ifdef ARM64"'s into the code. But just to say, porting Linux and a distro on top of it to a new architecture is far FAR easier that what I'm seeing from Microsoft (where, for instance, they're still working on getting visual studio up natively on ARM.)
Microsoft's reluctance to ship products for ARM must surely be a commercial choice, not a technical one. (An odd one, to my mind, but I'm not paid the big bucks to know when it is smart to hobble your own products.)
Unless they are writing vast amounts of assembly language, which would be bizarre beyond belief in this day and age, porting *is* just flicking a few compiler switches and repeating (some parts of) your test suite on the new hardware.
(Obviously compilers and related tools are an exception, but equally obviously Microsoft have already ported those.)
The memory models are different.
This causes "impossible" bugs in long-tested software, because they made hidden assumptions - usually by accident - that are true on x86 and amd64, but are not true on other multicore CPUs.
Yes, the code is wrong, eg it has the wrong kinds of fences, but the reality is that finding the mistakes is incredibly difficult - this module hasn't been touched for a decade, it can't be that!
All RISCs are very much the same -- ARM, RISC-V, even Super-H (and don't forget MIPS). I've built products with all of them and I find that the odd one out is actually the ARM. Its got some twists to the instruction set (skips) but they're of limited use in practical code, its a "seemed like a good idea at the time" feature. The core ISA is 'regular array of (typically) 32 (typically) bit registers with some registers being reserved for specific functions (zero value, instruction counter etc.), three address (register tor register) instruction set, memory access being offset from a register and so on. The differences between them tend to be in the special function register(s) (processor status, cache control, traps handling) and external hardware.
I like RISC-V not because its the best but because its finally got around to standardizing all those annoying details that differentiate one processor line from another. The real differentiators are going to be external to the core processor such a memory and peripheral buses, caches, parallel / out of order execution and so on. Most of this is academic for microcontrollers and small embedded applications.
Never mind something newer and more powerful. Eben Upton was asked about RISCV in the Raspberry Pi and that was his response. They are fine for microcontrollers, but there’s nothing yet on the horizon that can compete with even slightly modern ARM cores, and it’s a 100+ man year project to produce something, even starting with an experienced team and an existing design.
Long story short, Qualcomm aren’t going to be able to roll a replacement non-ARM desktop/laptop class core any time soon.
When comparing ARM with RISC-V its a good idea not to look at today,s RISC-V but at the MIPS range of processors. These processors are quite powerful, unlike the ARM they never really started out life as 'low performance, long battery life, low chip area' devices, they've always been built for speed. This is what we can expect for the not too distant future and as its been adopted by numerous Chinese semiconductor companies you can expect "100 man years" to be a mere drop in the investment ocean.
The point I'm making is that there's nothing inherently stopping the RISC-V from being a highly competitive product. Mayve not next week but you can bet on it. You also have to ask yourself what a lot of today's computing power is being used for. ARMs are widely used in phones and as we all know much of the software running on the phone isn't actually doing anything useful, its chasing its tail trying ever more inventive ways to keep tabs on the phone's owner. We are going into some very interesting times.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
