[HN Gopher] Alibaba Cloud gets more of Android working on RISC-V...
       ___________________________________________________________________
        
       Alibaba Cloud gets more of Android working on RISC-V silicon
        
       Author : rguiscard
       Score  : 112 points
       Date   : 2022-04-27 06:12 UTC (2 days ago)
        
 (HTM) web link (www.theregister.com)
 (TXT) w3m dump (www.theregister.com)
        
       | akmittal wrote:
       | Related: India govt planning to launch RISC-V processor by 2023
       | https://swarajyamag.com/tech/modi-govt-launches-digital-indi...
        
       | humanwhosits wrote:
       | This is a pretty big deal for all the other companies working on
       | RISC-V too, raises all the boats
        
         | yjftsjthsd-h wrote:
         | Mostly, I'm surprised that Google isn't the one leading the
         | charge here. Although it's kind of cool from an ecosystem
         | perspective to see somebody else moving things forward.
        
           | humanwhosits wrote:
           | They might be worried that it would fragment their app store,
           | as plenty of apps use native ARM code
        
             | yjftsjthsd-h wrote:
             | Android used to support MIPS and x86_64 - in fact I _think_
             | it still supports the latter. Of course, that might just
             | mean that Google is painfully aware of how annoying that is
             | to handle:)
        
               | tadfisher wrote:
               | They do, as well as x86 (32-bit); they are targets for
               | emulator system images.
        
           | caleb-allen wrote:
           | Is Google using ARM for their custom TPU systems? Perhaps
           | they have some sort of non-compete agreement with ARM
        
             | saagarjha wrote:
             | TPUs are custom ASICs.
        
       | Phurist wrote:
       | x86 is dead, long live ...
        
       | xvilka wrote:
       | Looking forward to RISC-V machines in Travis CI or other
       | services.
        
       | fithisux wrote:
       | And a set of GPU instructions are on the horizon. Yay!
        
       | wmertens wrote:
       | This is so cool - I'd like an open source CPU in my next phone
       | please!
       | 
       | (Of course, I would also like it to be fast, so that will
       | probably not happen in the next 5 years)
       | 
       | The article doesn't say if their port is also open source.
       | There's a blog post here but I don't see any patches.
       | https://riscv.org/blog/2021/11/how-alibaba-is-porting-risc-v...
        
         | shakna wrote:
         | I think this [0] is their Android port. You'll also find four
         | RISC-V cores under that account that Alibaba open sourced near
         | the end of last year.
         | 
         | [0] https://github.com/T-head-Semi/riscv-aosp
        
         | Narishma wrote:
         | > I'd like an open source CPU in my next phone please!
         | 
         | Just because it's RISC-V doesn't mean the CPU is open source.
        
           | usrn wrote:
           | Yeah. It's not licensed under the GPL or anything like that.
           | I'm not sure it's as good as people seem to think.
        
           | monocasa wrote:
           | AliBaba has been open sourcing their designs though. AFAIK,
           | this work is mainly against their XuanTie C910 cores that
           | have the source published here: https://github.com/T-head-
           | Semi/openc910
        
           | yjftsjthsd-h wrote:
           | Not all RISC-V ends up open, but it has better odds than
           | anything else.
        
       | jasoneckert wrote:
       | A large organization like Alibaba spending the effort to get
       | Android running on their own RISC-V platform seems like a clear
       | sign that we're on the cusp of seeing RISC-V development and
       | adoption snowball in the next few years.
        
         | 2OEH8eoCRo0 wrote:
         | I sure hope so. I think we may be on the cusp of a renaissance
         | in the CPU space. Intel UCIe, RISC-V, ARM, etc, have all been
         | quite exciting lately.
         | 
         | I'm an optimist so I imagine buying made to order CPUs from
         | Intel or TSMC where you can pick and choose features and
         | chiplets that can come from any number of companies.
        
           | not2b wrote:
           | The problem with your "mix and match" idea is that it's
           | hugely expense to create masks for chip design, even for
           | chips that simple compositions of predesigned cores, memory,
           | and interconnect, and that expense only pays off because the
           | one mask is used to fabricate anywhere from tens of thousands
           | to millions of chips. A custom choice just for you would be
           | very pricy.
           | 
           | We already live in a world where chip designers pick and
           | choose cores and components from any number of companies:
           | processors we all know about, but things like USB3, HDMI,
           | Bluetooth, and many others are often licensed from third
           | parties. But for the numbers to work you've got to make lots
           | of chips to handle the fixed costs.
        
             | monocasa wrote:
             | Does anyone have a decent break down of the cost of masks?
             | I've never really gotten a good sense of what's actually
             | COGS of the actual mask set, and how much is NRE costs
             | that's subject to disruption if chip making is commoditized
             | as we get further up the s-curve that is Moore's Law.
        
               | not2b wrote:
               | While it isn't directly applicable, here's a decent
               | analysis of the costs of doing a custom ASIC to replace
               | generic components, should provide an idea.
               | 
               | https://www.electronicdesign.com/technologies/embedded-
               | revol...
        
             | not2b wrote:
             | ugh, typos: "hugely expensive", "even for chips that are
             | simple compositions".
        
           | usrn wrote:
           | We've had free CPU designs before: 8051 and MIPS. I think
           | RISC-V popularity will just lead to less compatibility.
        
             | monocasa wrote:
             | Neither of those were free designs.
             | 
             | 8051s are heavily cloned, but it's not like there's heavily
             | used HDL floating around for free. Additionally the gate
             | count niche of an 8051 is rather constrained.
             | 
             | MIPS made a big deal about being open, but at the end of
             | the day that seemed to just mean that they put their sales
             | contacts on the main page. 'Open' in that case meant 'open
             | access for our business partners to make RTL changes with
             | the right signed contract'.
        
           | mhh__ wrote:
           | We the consumer will probably never do that but in industry
           | that's been the case for a while. It's a SoC game not a CPU
           | game anymore.
        
         | stingraycharles wrote:
         | Could someone elaborate a bit on how RISC-V relates to ARM?
         | 
         | From what I understand the former is a completely open source
         | spec, and ARM is a proprietary one. But both are just specs,
         | right? It's not as if I can buy a RISC-V CPU from an
         | organization behind it, it'll have to be from a manufacturer
         | that produces their own RISC CPUs?
         | 
         | Is it also an entirely different instruction set? How does it
         | compare to x86 and ARM in terms of performance?
         | 
         | Last but not least, other than it being free / opensource, what
         | are some of the reasons why anyone would choose RISC? Phrased
         | differently, if they are going to take marketshare in the CPU
         | world in the next decade, what will be the reason?
        
           | 2Gkashmiri wrote:
           | take my comment with a bag full of sand, i am no expert,
           | still
           | 
           | when you talk about ARM, you have to license designs from the
           | ARM, inc. Apple with its apple silicon is licensing from ARM
           | the designs and IP from them.
           | 
           | with RISC-v, there is no company to hold you hostage for
           | designs and all. its all open source so you can build your
           | own chip, own design, own tech, everything.
           | 
           | this also means i assume that in the long run, if RISC-v and
           | ARM are on equal footing, RISC-v would be more freer, cheaper
           | because there is no licensing and other corporate stuff to go
           | through like with ARM, inc
        
             | goodpoint wrote:
             | > with RISC-v, there is no company to hold you hostage for
             | designs and all
             | 
             | No no no. The RISC-V ISA is open.
             | 
             | The implementation of RISC-V CPUs is often proprietary.
        
               | 2Gkashmiri wrote:
               | OK. So can't there be multiple competing implementations?
               | Proprietary but some like those university projects, Foss
               | ?
        
               | monocasa wrote:
               | Yeah, the spec is free with a permissive license, and
               | individual implementations are expanding to fill the full
               | gamut of free to proprietary.
        
             | WanderPanda wrote:
             | How to prevent e.g. Alibaba from embrace-extend-
             | extinguishing RISC-V? It seems so obvies that this will
             | happen in one way or another
        
               | snvzz wrote:
               | Upstream toolchains won't readily accept extensions that
               | aren't part of the standard, and maintaining forks is
               | costly.
               | 
               | There is no incentive not to get extensions standardized.
               | In the first place, what's even missing in RISC-V? As of
               | December's 15 extensions, it is pretty much there
               | already, in terms of functionality.
        
             | f0xJtpvHYTVQ88B wrote:
             | ARM does develop their own core designs which they license
             | to many companies. However, they have several different
             | licenses available which range from using ARM's designs,
             | tweaking ARM's designs, up to the Architectural license
             | which allows companies to develop their own ARM ISA
             | compatible cores own their own. Apple is one of the
             | companies which has an Architectural license. The current
             | cores used by Apple were designed by Apple and not based on
             | designs from ARM.
        
           | jchw wrote:
           | Nit: you shouldn't use RISC as a shorthand for RISC-V. The
           | former is a well-known term.
           | 
           | Yes, RISC-V is an open ISA, yes, like ARM there is no fab
           | making canonical RISC-V chips. It does at least have the
           | benefit of having support in the UEFI spec pretty much right
           | out of the gate, which offers a standard boot path of sorts
           | (Arm64 also supports UEFI, but most devices to this day have
           | their own bespoke boot firmware and protocols, AFAIK. The
           | unifying factor tends to be something like uboot, again,
           | AFAIK.) but it also has more flexibility, which has the
           | knock-on effect that it may be harder to know which RISC-V
           | software can run on which RISC-V hardware.
           | 
           | I'm very curious to see where it goes. As a tinkerer I
           | definitely have been looking for entire desktop computers
           | that, weak or not, are truly open source and documented from
           | the ground up. RISC-V platforms don't solve that entirely (in
           | fact it's probably the remainder of SoC IP that poses the
           | biggest problems) but it does offer an interesting option for
           | a CPU.
        
           | monocasa wrote:
           | The spec is free, and a lot of cores are free as well. Here's
           | the HDL for AliBaba's cores they've been developing this
           | against: https://github.com/T-head-Semi/openc910
           | 
           | There are also non-free RISC-V cores, but they essentially
           | have to continuously make the argument for their existence
           | against the free cores that are available (support,
           | verification resources, just being better designs in the
           | short term, already being hardened for proprietary process
           | nodes, etc.)
        
           | imtringued wrote:
           | >Is it also an entirely different instruction set? How does
           | it compare to x86 and ARM in terms of performance?
           | 
           | It's a bit of a mixed bag. I'd say if macro op fusion turns
           | out to be viable, it can become the fastest of the three, if
           | not, it will be somewhere between ARM and x86 due to its
           | unique compression scheme. This obviously depends on your
           | particular chip. Apple is way ahead of Qualcomm on the same
           | ISA.
        
             | snvzz wrote:
             | >macro op fusion turns out to be viable
             | 
             | Macro-op fusion predates RISC-V.
             | 
             | What's new is that RISC-V has been designed with knowledge
             | of Macro-op fusion, which gave it some opportunities.
             | 
             | I'd say it weights very little overall; RISC-V is very
             | clever, irrespective of fusion.
        
           | mhh__ wrote:
           | RISC-V is a nice clean design but ARM is also a fairly clean
           | but less nice design, by people who have their face on the
           | grindstone 24/7.
           | 
           | Winning is likely to be a question of luck (a la Unix
           | perhaps) and implementation quality.
        
       ___________________________________________________________________
       (page generated 2022-04-29 23:01 UTC)