Google Wants RISC-V To Be a 'Tier-1' Android Architecture (arstechnica.com) 61
An anonymous reader quotes a report from Ars Technica: Google's keynote at the RISC-V Summit was all about bold proclamations [...]. Lars Bergstrom, Android's director of engineering, wants RISC-V to be seen as a "tier-1 platform" in Android, which would put it on par with Arm. That's a big change from just six months ago. Bergstrom says getting optimized Android builds on RISC-V will take "a lot of work" and outlined a roadmap that will take "a few years" to come to fruition, but AOSP started to land official RISC-V patches back in September. The build system is up and running, and anyone can grab the latest "riscv64" branch whenever they want -- and yes, in line with its recent Arm work, Google wants RISC-V on Android to be 64-bit only. For now, the most you can get is a command line, and Bergstrom's slide promised "initial emulator support by the start of 2023, with Android RunTime (ART) support for Java workloads following during Q1."
One of Bergstrom's slides featured the above "to-do" list, which included a ton of major Android components. Unlike Android's unpolished support for x86, Bergstrom promised a real push for quality with RISC-V, saying, "We need to do all of the work to move from a prototype and something that runs to something that's really singing -- that's showing off the best-in-class processors that [RISC-V International Chairman Krste Asanovic] was mentioning in the previous talk." Once Google does get Android up and running on RISC-V, then it will be up to manufacturers and the app ecosystem to back the platform. What's fun about the Android RunTime is that when ART supports RISC-V, a big chunk of the Android app ecosystem will come with it. Android apps ship as Java code, and the way that becomes an ARM app is when the Android Runtime compiles it into ARM code. Instead, it will soon compile into RISC-V code with no extra work from the developer. Native code that isn't written in Java, like games and component libraries, will need to be ported over, but starting with Java code is a big jump-start.
In her opening remarks, RISC-V International (the nonprofit company that owns the architecture) CEO Calista Redmond argued that "RISC-V is inevitable" thanks to the open business model and wave of open chip design that it can create, and it's getting hard to argue against that. While the show was mostly about the advantages of RISC-V, I want to add that the biggest reason RISC-V seems inevitable is that current CPU front-runner Arm has become an unstable, volatile company, and it feels like any viable alternative would have a good shot at success right now. [...] The other reason to kick Arm to the curb is the US-China trade war, specifically that Chinese companies (and the Chinese government) would really like to distance themselves from Western technology. [...] RISC-V is seen as a way to be less reliant on the West. While the project started at UC Berkeley, RISC-V International says the open source architecture is not subject to US export law. In 2019, the RISC-V Foundation actually moved from the US to Switzerland and became "RISC-V International," all to try to avoid picking a side in the US-China trade war. The result is that Chinese tech companies are rallying around RISC-V as the future chip architecture. One Chinese company hit by US export restrictions, the e-commerce giant Alibaba, has been the leading force in bringing RISC-V support to Android, and with Chinese companies playing a huge part in the Android ecosystem, it makes sense that Google would throw open the doors for official support. Now we just need someone to build a phone.
One of Bergstrom's slides featured the above "to-do" list, which included a ton of major Android components. Unlike Android's unpolished support for x86, Bergstrom promised a real push for quality with RISC-V, saying, "We need to do all of the work to move from a prototype and something that runs to something that's really singing -- that's showing off the best-in-class processors that [RISC-V International Chairman Krste Asanovic] was mentioning in the previous talk." Once Google does get Android up and running on RISC-V, then it will be up to manufacturers and the app ecosystem to back the platform. What's fun about the Android RunTime is that when ART supports RISC-V, a big chunk of the Android app ecosystem will come with it. Android apps ship as Java code, and the way that becomes an ARM app is when the Android Runtime compiles it into ARM code. Instead, it will soon compile into RISC-V code with no extra work from the developer. Native code that isn't written in Java, like games and component libraries, will need to be ported over, but starting with Java code is a big jump-start.
In her opening remarks, RISC-V International (the nonprofit company that owns the architecture) CEO Calista Redmond argued that "RISC-V is inevitable" thanks to the open business model and wave of open chip design that it can create, and it's getting hard to argue against that. While the show was mostly about the advantages of RISC-V, I want to add that the biggest reason RISC-V seems inevitable is that current CPU front-runner Arm has become an unstable, volatile company, and it feels like any viable alternative would have a good shot at success right now. [...] The other reason to kick Arm to the curb is the US-China trade war, specifically that Chinese companies (and the Chinese government) would really like to distance themselves from Western technology. [...] RISC-V is seen as a way to be less reliant on the West. While the project started at UC Berkeley, RISC-V International says the open source architecture is not subject to US export law. In 2019, the RISC-V Foundation actually moved from the US to Switzerland and became "RISC-V International," all to try to avoid picking a side in the US-China trade war. The result is that Chinese tech companies are rallying around RISC-V as the future chip architecture. One Chinese company hit by US export restrictions, the e-commerce giant Alibaba, has been the leading force in bringing RISC-V support to Android, and with Chinese companies playing a huge part in the Android ecosystem, it makes sense that Google would throw open the doors for official support. Now we just need someone to build a phone.
Re:ARM just broke-out in a cold sweat... (Score:4, Insightful)
I have seen no examples that show RISC-V can be faster
Billions have been invested in making ARM faster. Very little has been invested in RISC-V so far.
Also, speed is not the only criterion. Power, heat, density, and cost are also important.
Re: (Score:3)
Power, heat, density, and cost are also important.
Yeah and it fails at those too.
Re: (Score:3)
Billions have been invested in making ARM faster. Very little has been invested in RISC-V so far.
I would be curious how much work it would be for Apple to create a really fast RISC-V chip using everything they do in their really fast ARM chips. Like RISC-V with massive caches, 500 rename registers, and so on. Of course others wouldn't benefit because Apple wouldn't hand those designs out (and if it was a legal requirement then they wouldn't build it).
Re: ARM just broke-out in a cold sweat... (Score:1)
Speed of what? After Android becomes a Tier-1 architecture, only then you can compare devices to devices.
Step aside, Android (Score:2)
With RISC-V, Solaris will finally shine again. /s
Comment removed (Score:5, Interesting)
Re: (Score:2)
I do feel the whole "Look at us we're RISC!" thing that RISC-V has in its name means it's stuck in the 1980s. It was definitely the best way to design a CPU in the 1980s, but is it really relevant right now?
You get more registers, you can shorten your pipeline (which means more pipelines or more potential for lengthening the pipeline), you have less potential for weird security bugs in your silicon.
The register crunch isn't quite so bad in the x64 as it was in x86, but it's still there.
Re: (Score:3, Insightful)
An average CPU right now has hundreds of millions of transistors, the "saving" RISC was supposed to give was ditching microcode to give you space for more registers, and using a standardized instruction set so you could easily pipeline everything. Are either of these relevant today?
Every. Single. Popular. Processor. Is. RISC. Internally.
The amount of area taken up by implementing a design that uses microcode is negligible compared to even the functional units, let alone the cache.
What does RISC-V really bring to the table?
Lack of licensing fees. It's not ARM that made ANY of these fast ARM chips, they laid the groundwork and it's the licensors that did that. They can do it again with RISC-V.
Re: (Score:2)
Re: (Score:2)
But Squiggie! It has two caches! TWO CACHES!" they counterargue
Weird, since they contain three caches
Re: (Score:2)
Re: (Score:2)
I looked it up and the p3 was the last truly internally RISC Intel chip, I resolve to remember
Re: (Score:2, Insightful)
The main thing RISC-V brings to the table is open hardware, but also a common ISA across the multitude of other embedded processors in any typical system, and thus common tooling. Theoretically this should lead to less licensing cost and easier maintenance, fewer bugs, etc.
RISC-V cores can be extremely small and efficient, surpassing even ARM. Another benefit is a sane vector extension that offers an escape from the perpetual churn of packed SIMD. (though ARMv8 also has SVE.)
Sadly though, RISC-V really does
Re: (Score:2)
Google just took a stab... (Score:3)
RISC-V (Score:3)
We know RISC-Vs only purpose from day one was to be used as faux-competition against ARM. It's really for nothing other than telling ARM "give me a good deal or else!" It's the equivalent of when you're trying to sell your used car to a prospective buyer, you have your cousin Billy come over at the same time pretending to also be interested in the car.
Re:RISC-V (Score:4, Insightful)
Hmm, you mean like how companies use Linux and LibreOffice only as leverage to get a better deal with MS for Windows and Office site licenses the next time around? I'm sure some do, but certainly not all these days! And those that are heavily involved with RISC-V have a different take on it than your opinion.
I'm a bit conflicted on RISC-V. I hope that we can get some common platforms based on RISC-V such that I can install any generic distro (Fedora, Debian) on a device without any custom kernels, firmwares, or funky boot/flash methodologies, unlike the mess that is ARM. But I'm not confident this will happen. I worry that vendors will treat RISC-V the same as ARM and make proprietary SoCs that only work with their special kernel, or their special image of Android with proprietary blobs for GPU drivers, etc. Hopefully the boot situation is better on RISC-V. Projects like tow-boot are making booting on disparate ARM SoCs a lot more sane, though.
Re: (Score:2)
The main problem will be power and performance. ARM put a lot of R&D into those things and RISC-V needs a lot of money throwing at it to catch up.
Re: (Score:2)
And just like that, open source chip development is misunderstood.
Re: (Score:2)
it's even worse with RISC-V. Parts
Re: (Score:2)
That's really unfortunate. RISC-V, like ARM, is just never going to make any inroads in laptops, desktops, and servers without standardization like that. ARM works for Apple because they are the platform. But it's never going to be a great Linux or Windows platform. RISC-V is never going to make inroads beyond embedded controllers and Android devices. Which I'm sure will make companies lots of money like ARM does. At this point the only difference between ARM and RISC-V comes down to the costs to the v
Good, hope they follow through (Score:3)
Google certainly had their own selfish reasons but really everyone online today owes them some amount of gratitude for buying On2 and opening up the codec for everyone and now with AV1 we can all tell mpeg group to eat it.
With RISC-V again they have their own incentives for sure but an open standard is probably the best path to fight what is an effective monopoly on the mobile market by ARM.
I wonder if devices with RISC-V could help with the ever present Android upload dilemma, could these devices be more standardized like PCs and OS updates divided from the hardware itself?
Re: (Score:2)
I wonder if devices with RISC-V could help with the ever present Android upload dilemma, could these devices be more standardized like PCs and OS updates divided from the hardware itself?
As far as I understand the RISC-V license, there isn't anything about it that would guarantee a longer update window. However, it does seem like it would be easier for companies to spin their own and support it longer.
Re: (Score:2)
Unlikely I'm afraid. The updates issue is twofold.
You have SoC manufacturers who can't be bothered to support 1 year old chips. Only the phone manufacturers buying from them can do anything about that, at additional cost and with a couple of years lead time.
Then you have the modems. Networks don't want you to be able to screw with the modem, it could cause havoc on their networks and disrupt service for other customers. Plus they are entirely proprietary and need to be certified with the OS every time it g
Re: (Score:2)
Then you have the modems. Networks don't want you to be able to screw with the modem, it could cause havoc on their networks and disrupt service for other customers. Plus they are entirely proprietary and need to be certified with the OS every time it gets updated. So basically the same issue as the SoCs.
Have any phones been successfully attacked through their baseband processor?
Re: (Score:2)
I remember people used to mix and match the drivers with Lineage, not sure if they still do.
Re: (Score:2)
I remember people used to mix and match the drivers with Lineage, not sure if they still do.
I have had phones where I flashed OS and radio images separately... One Android phone and also Motorola Triplets/RAZR. But that's not the question.
Re: (Score:2)
Yeah, that's what people do, use a modem firmware image from another phone. One where the gain is cranked up to compensate for a weak antenna.
I don't know if anyone has been hacked through the modem firmware, but that's not the concern of the networks.
Re: (Score:2)
An image from another phone wouldn't have worked at all in any of the cases where I was doing it. The radio images came from another software version of the same phone, possibly from another region. Same part, different SKU. On Triplets phones in particular the differences were very significant and only specific versions made improvements, and further some were earlier and some were later. There was no apparent rhyme or reason, though no doubt someone with enough knowledge of the regulatory landscape and Mo
Re: (Score:2)
No, and that's likely just due to obscurity.
The baseband processor code and DSP code for it is, frankly, horrible. It would not surprise me if there were tons of security holes if you fuzzed it just right.
The only thing keeping people from doing it is relative obscurity - until recently hardware that lets you fuzz from the RF side had been relatively expensive and unobtainable, while today it's easy to find an SDR like a HackRF to d
Great, they are learning the lessons from history (Score:1)
When those MIPS/SPARC/POWER RISC processors unseated the mighty CISCs that drove the VM360 and similar, they were runing a system that their creators wanted to call ENUCS because of the lack of functionality compared to its inspiartion MULTICS (Tanembaum dixit).
When the lowly x86 unseated all the mighty RISC processors that handled Unix and stuff, they ran MS-DOS and Win9x.
ARM, which is in the process of unseating X86, originally ran android and embesdded OSs.
Is only fitting that RISC-V, the current contede
Re: (Score:3)
What?
Arm originally powered desktop computers running RiscOS, 2 decades before android existed.
Also unics not euncs. Otherwise the joke doesn't work.
Re: (Score:1)
I always wanted one of these for my collection. https://wiki.preterhuman.net/D... [preterhuman.net]
Re: (Score:2)
What the heck is that? I've never even heard of that one. Guessing it's StrongARM of its DEC. A fellow student had a StrongARM based Risc PC when I was at uni. Was a pretty slick machine.
I was originally thinking of the acorn Archimedes though.
Re:Great, they are learning the lessons from histo (Score:5, Informative)
It will take decades, but RISC-V is the future of instructions sets.
no, really, it isn't. read this - it's the best independent analysis i've encountered which
outlines the problem:
https://news.ycombinator.com/i... [ycombinator.com]
summary: the over-simplification of the RISC-V ISA comes with a price:
larger binary size and greater hardware complexity to compensate. RISC-V
advocates claim that "Compressed" compensates compared to other ISAs
(it doesn't: adrian_b explains why).
what *will* take several years is for "everyone expecting optimal-performance
hardware to turn up" to realise what that person (adrian_b) is talking about.
what's actually happening is that large organisations betting on RISC-V in
high-performance are being backed with extremely large grants and large
investment, only to find that RISC-V cannot deliver. the problem is that the
committment in terms of funding and time to get to an actual ASIC is so large
that they can't back out.
to illustrate: the only reason that the Alibaba Group's Xiantue910 could claim
better performance than a high-performance ARM Cortex A73 was because
they added FIFTY PERCENT more Custom (rogue) instructions to the RISC-V
ISA.
oink.
by complete contrast, in the *low-end* embedded arena where the binary
size is immaterial vs the cost of licensing an ARM Cortex M0/3/4, RISC-V
is taking the world by storm, because zero royalties is unbeatable.
Re: (Score:2)
How do we know this is an independent analysis?
It's also ill-informed about HPC. It's the easily extendable instruction set of RISC-V that makes it a win. This is part of the design and not a defect. The top computers need to get performance out of GPUs or customized vector instructions. Using basic CPU instructions uses too much energy to be practical. RISC-V allows instruction customization to support such addit
Re: (Score:2)
It's also ill-informed about HPC. It's the easily extendable
instruction set of RISC-V that makes it a win.
only in embedded products where compatibility and interoperability
is completely unimportant. a classic example is the Trinamic Stepper
Motor Driver ICs that adopted such an early version of RISC-V that
the standard hadn't even been ratified yet, but it in absolutely no way
mattered because the compilers worked, binutils worked, they could
*PRIVATELY* make as many custom modifications as they wanted,
shove the binary into metal masks and absolutely nobody would know.
in this situation (private, custom, secretive,
Re: (Score:2)
This is somewhat ironic. Part of the reason RISC V is so good in this space is that all the parts on the chip can use RISC V. Instead of a SOC having 10 different instruction sets, all the parts can use a single language making it easier to develop embedded products.
I'm no expert on RISC V, but I recommend you look at forums with experts who can rebut the claims you linked as they are not valid. Looking at on
Re: (Score:2)
This is somewhat ironic. Part of the reason RISC V is so good in
this space is that all the parts on the chip can use RISC V. Instead
of a SOC having 10 different instruction sets, all the parts can use a
single language making it easier to develop embedded products.
yes - although the licensing cost of those various CPUs is also
a key decision factor (a plus). however it's not quite that simple.
take for example a company i know of that has developed its own
RISC-V embedded core: they added a custom instruction to it,
and then to binutils, and then to gcc, which greatly improved
performance. that means that for *that one core*, there is a
custom gcc/binutils toolchain that *only* works with that one core.
now repeat that exercise for all 10 (proposed, above) cores.
but, hey,
Re: (Score:2)
I was referring to all the support parts on a SOC, but OK let's assume they add different special instructions to 10 cores on a single chip. I imagine this product would fail because of the bad design. It's easy to make a bad product. Presumably it will fail in the market. Unlike software, it's non-trivial to make high performance chips given the cost of modern fabs. But as you say, if it's a proprietary product, it's their problem. Maybe th
Re: (Score:2)
What does RISC-V do better than ARM that enables it to be the future?
Re: (Score:2)
No macos, no Windows :)
Re: (Score:2)
When the lowly x86 unseated all the mighty RISC processors that handled Unix and stuff, they ran MS-DOS and Win9x.
By the time the lowly x86 unseated all those mighty processors, it was internally RISCy. Am586 and P54C both decompose x86 instructions into RISC micro-ops. 486s weren't displacing workstations.
Re: (Score:3)
It will take decades, but RISC-V is the future of instructions sets.
Is it? Or will it be the Mill CPU architecture?
Re: (Score:3)
I thought "future of instruction sets" would be some specialised instructions to support compilers better. For example, retain/release is 5 times faster on MacOS ARM than on MacOS x86 because of additions to the instruction set, and that is quite significant.
Re: (Score:2)
They're still working on it, although progress has been slow.
From Hackers (Score:4, Funny)
From the movie Hackers: "RISK IS GOOD!"
Java eh (Score:2)
OpenJDK released a build for RISC-V Linux last September, so there's progress. ART will have to catch up of course. But plenty of Android applications are not written in Java for performance reasons. Intel ran into this problem years ago when trying to push their Baytrail and Cherry Trail hardware into Android devices. If the applications aren't recompiled for the new uarch then, no bueno.
Re: (Score:2, Funny)
Intel ran into this problem years ago when trying to push their Baytrail and Cherry Trail hardware into Android devices.
Remember when one of Intel's defining characteristics was a really good compiler for each new architecture? Then they crashed the itanic into an AMDberg.
Re: (Score:2)
Even if Intel had provided a good compiler for Atom on Android, it's questionable as to whether app developers at the time would have bothered using it.
to hell with google (Score:3)
Re: (Score:2)
i don't trust google
whom do you trust?
China wants it, this is the real reason (Score:3)
How much AI tech did Google give to China with their AI research center in Beijing? Is Google an American company? ...sometimes I wonder.
Re: (Score:3)
Alibaba have been porting AOSP for a couple of years now, primarily for the domestic market as insurance against Huawei-style sanctioning.
It would be short-sighted for Google NOT to port Play and related Android services - once the technology gets sufficiently fast enough to substitute for ARM, the last thing they want is a competitor (c.f. Amazon Fire) to launch a Google free experience.
And.... (Score:3)
it's abandoned.