[HN Gopher] Arm is canceling Qualcomm's chip design license
___________________________________________________________________
Arm is canceling Qualcomm's chip design license
Author : necubi
Score : 539 points
Date : 2024-10-23 00:48 UTC (22 hours ago)
(HTM) web link (www.bloomberg.com)
(TXT) w3m dump (www.bloomberg.com)
| talldayo wrote:
| Could be the best thing that's ever happened for RISC-V!
| dietr1ch wrote:
| I think it's already a great thing for RISC-V, imagine things
| somehow go well for Qualcomm, do you really think they wouldn't
| prepare a plan B given ARM tried to get them out of the market?
| nahnahno wrote:
| I don't think they have a plan B. Architectures take half a
| decade of work. Porting from risc-v to arm is not a matter of
| a backup plan, it's that of a very costly pivot.
| gjsman-1000 wrote:
| No kidding; and while RISC-V is a massive improvement, I
| hate to be the wet blanket, but RISC-V will not change
| signed boot, bootloader restrictions, messy or closed
| source drivers, carrier requirements, DRM implementation,
| or other painful day to day paper cuts. Open source
| architecture != Open source software and certainly != Open
| source hardware; no matter what the YouTubers think.
| Atotalnoob wrote:
| Until arm or risc-v fix standardize the bootloader, it's
| always going to be a big deal for each arm/risc device
| added anywhere...
| snvzz wrote:
| Relevant RISC-V specs were released years ago and
| implementations follow them.
|
| I know of no boards that have application processors and
| yet not implement SBI. Furthermore, everybody seems to be
| using the opensbi implementation.
|
| ARM and RISC-V are not the same.
| betaby wrote:
| I suppose Google ( + Samsung ) can bear that cost in the
| context of Android Arm -> Android RISC-V.
| snvzz wrote:
| Qualcomm's been involved with RISC-V for several years now.
|
| If anything, ARM is the plan B that they'll likely end up
| abandoning.
| dagmx wrote:
| It's a bit much to say their primary product that they've
| done for decades is a plan B. By definition it cannot be
| a plan B if it's executed first and is successful.
|
| I think a lot of RISC-V advocates are perhaps a little
| too over eager in their perception of the landscape.
| snvzz wrote:
| Typo. Meant to write "ARM is the plan A that they'll
| likely end up abandoning".
| mkl wrote:
| Qualcomm has been working on RISC-V for a while, at
| outwardly-small scale. It's probably intended as a long-
| term alternative rather than a ready-to-go plan B. From a
| year ago: "The most exciting part for us at Qualcomm
| Technologies is the ability to start with an open
| instruction set. We have the internal capabilities to
| create our own cores -- we have a best-in-class custom
| central processing unit (CPU) team, and with RISC-V, we can
| develop, customize and scale easily." --
| https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-
| and..., more:
| https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web
| hajile wrote:
| Qualcomm pitched a Znew extension for RISC-V that
| basically removes compressed (16-bit) instructions and
| adds more ARM64-like stuff. It felt very much like trying
| to make an easier plan B for if/when they need/want to
| transition from ARM to RISC-V.
|
| https://lists.riscv.org/g/tech-
| profiles/attachment/332/0/cod...
| brucehoult wrote:
| Qualcomm have a Plan B.
|
| This time last year they were all over the RISC-V mailing
| lists, trying to convince everyone to drop the "C"
| extension from RVA23 because (basically confirmed by their
| employees) it was not easy to retrofit mildly variable
| length RISC-V instructions (2 bytes and 4 bytes) to the
| Aarch64 core they acquired from Nuvia.
|
| At the same time, Qualcomm proposed a new RISC-V extension
| that was pretty much ARMv8-lite.
|
| The proposed extension was actually not bad, and could very
| reasonably be adopted.
|
| Dropping "C" overnight and thus making all existing Linux
| software incompatible is completely out of the question.
| RISC-V will eventually need a deprecation policy and
| procedure -- and the "C" extension could potentially be
| replaced by something else -- but you wouldn't find anyone
| who thinks the deprecated-but-supported period should be
| less than 10 years.
|
| So they'd have to support both "C" and its replacement
| anyway.
|
| Qualcomm tried to make a case that decoding two instruction
| widths is too hard to do in a very wide (e.g. 8)
| instruction decoder. Everyone else working on designs in
| that space ... SiFive, Rivos, Ventana, Tenstorrent ... said
| "nah, it didn't cause us any problems". Qualcomm jumped on
| a "we're listening, tell us more" from Rivos as being
| support for dropping "C" .. and were very firmly corrected
| on that.
| wmf wrote:
| _Dropping "C" overnight and thus making all existing
| Linux software incompatible is completely out of the
| question._
|
| Android was never really Linux though.
| refulgentis wrote:
| This is officially too much quibbling, even if we settled
| philosophical questions like "Is Android Linux?" Then "If
| not, would dropping C make RISC nonviable", there isn't
| actually an Android version that'll do RISC anywhere near
| on the horizon. Support _reversed_ for it, got pulled 5
| months ago
| snvzz wrote:
| >Support _reversed_ for it, got pulled 5 months ago
|
| Cursory research will yield that this was a technicality
| with no weight in Google's strong commitment to RISC-V
| Android support.
| refulgentis wrote:
| If you trust PR (I don't, and I worked on Android for 7
| years until a year ago) - this is a nitpick 5 levels down
| -- regardless of how you weigh it, _there is no Android
| RISC-V_
| snvzz wrote:
| It is no nitpick.
|
| The Android RISC-V effort did not suffer any delay from
| this pure technicality that some news sites farmed at the
| time for drama and clicks.
| refulgentis wrote:
| There is no Android RISC-V. There isn't an Android
| available to run on RISC-V chips. There is no code to run
| on RISC-V in the Android source tree, it was all recently
| actively removed.[1]
|
| Despite your personal feelings about their motivation,
| these sites were factually correctly relaying what
| happened to the code, and they went out of their way to
| say exactly what Google said and respected Google's claim
| that they remain committed, with 0 qualms.
|
| I find it extremely discomfiting that you are so focused
| on how the news makes you _feel_ that you 're casting
| aspersions on the people you heard the news from, and
| ignoring what I'm saying on a completely different
| matter, because you're keyword matching
|
| I'm even more discomfited that you're being this
| obstinate about the completely off-topic need for us all
| to respect Google's strong off-topic statement of
| support[2] over _the fact they removed all the code for
| it_
|
| [1] "Since these patches remove RISC-V kernel support,
| RISC-V kernel build support, and RISC-V emulator support,
| any companies looking to compile a RISC-V build of
| Android right now would need to create and maintain their
| own fork of Linux with the requisite ACK and RISC-V
| patches."
|
| [2] "Android will continue to support RISC-V. Due to the
| rapid rate of iteration, we are not ready to provide a
| single supported image for all vendors. This particular
| series of patches removes RISC-V support from the Android
| Generic Kernel Image (GKI)."
| shash wrote:
| Actually, https://github.com/google/android-
| riscv64?tab=readme-ov-file
|
| And the mailing list is pretty active too:
| https://lists.riscv.org/g/sig-android/topics?sidebar=true
| refulgentis wrote:
| I don't know why people keep replying as if I'm saying
| Android isn't going to do RISC-V.
|
| I especially don't understand offering code that predates
| the removal from tree and hasn't been touched since. Or,
| a mailing list, where we click on the second link and see
| a Google employee saying on October 10th "there isn't an
| Android riscv64 ABI yet either, so it would be hard to
| have [verify Android runs properly on RISC-V] before an
| ABI :-)"
|
| That's straight from the horses mouth. There's no ABI for
| RISC-V. Unless you've discovered something truly novel
| that you left out, you're not compiling C that'll run on
| RISC-V if it makes _any_ system calls.
|
| I assume there's some psychology thing going on where my
| 110% correct claim that it doesn't run on RISC-V today is
| transmutated to "lol risc-v doesn't matter and Android
| has 0 plans"
|
| I thoroughly believe Android will fully support RISC-V
| sooner rather than later.
| weebull wrote:
| Dropping the compressed instructions is also a
| performance / power issue. That matters to mobile.
| eggsome wrote:
| What do you mean by Plan B? From what you've just said it
| sounds like their proposal was rejected, so there is no
| plan b now?
| brucehoult wrote:
| They can roll their sleeves up and do the small amount of
| work that they tried to persuade everyone else was not
| necessary. And I'm sure they will have done so.
|
| It's not _that_ hard to design a wide decoder that can
| decode mixed 2-byte and 4-byte instructions from a buffer
| of 32 or 64 bytes in a clock cycle. I 've come up with
| the basic schema for it and written about it here and on
| Reddit a number of times. Yeah, it's a little harder than
| for pure fixed-width Arm64, but it is massively massively
| easier than for amd64.
|
| Not that anyone is going that wide at the moment.
| SiFive's P870 fetched 36 bytes/cycle from L1 icache, but
| decodes a maximum of 6 instructions from it. Ventana's
| Veyron v2 decodes 16 bytes per clock cycle into 4-8
| instructions (average about 6 on random code).
| cesarb wrote:
| > Yeah, it's a little harder than for pure fixed-width
| Arm64, but it is massively massively easier than for
| amd64.
|
| For those who haven't read the details of the RISC-V ISA:
| the first two bits of every instruction tell the decoder
| whether it's a 16-bit or a 32-bit instruction. It's
| always in that same fixed place, there's no need to look
| at any other bit in the instruction. Decoding the length
| of a x86-64 instruction is much more complicated.
| Narishma wrote:
| Why do they use two bits for it? Do they plan to support
| other instruction lengths in the future?
| cesarb wrote:
| > Why do they use two bits for it?
|
| To increase the number of 16-bit instructions. Of the
| four possible combinations of these two bits, one
| indicates a 32-bit or longer instruction, while the other
| three are used for 16-bit instructions.
|
| > Do they plan to support other instruction lengths in
| the future?
|
| They do. Of the eight possible combinations for the next
| three bits after these two, one of them indicates that
| the instruction is longer than 32 bits. But processors
| which do not know any instruction longer than 32 bits do
| not need to care about that; these longer instructions
| can be naturally treated as if they were an unknown
| 32-bit instruction.
| eqvinox wrote:
| > Dropping "C" overnight and thus making all existing
| Linux software incompatible is completely out of the
| question.
|
| For general purpose Linux, I agree. But if someone makes
| Android devices and maintains that for RISC-V... that's
| basically a closed, malleable ecosystem where you can
| just say "f it, set this compiler option everywhere".
|
| But also, yes, another commenter pointed out C brings
| some power savings, which you'd presumably want on your
| Android device...
| snvzz wrote:
| It would be naive to think that Qualcomm is only starting
| its RISC-V effort today and from scratch.
| bhouston wrote:
| Most people do not realize how slow RISC-V is right now. Yes,
| it will definitely get better, but it will take some time given
| how far behind it is.
|
| Like 30x slower than a top of the line Apple Mx series CPU.
| Maybe there is a high performing RISC-V chip out there but I
| haven't yet run into one.
|
| RISC-V benchmarks:
| https://browser.geekbench.com/search?q=RISC-V. Compare to an
| Apple M4 benchmark:
| https://browser.geekbench.com/v6/cpu/8224953
|
| That said, RISC-V is good for embedded applications where raw
| performance isn't a factor. I think no other markets are yet
| accessible to RISC-V chips until their performance massively
| improves.
| tightbookkeeper wrote:
| Is it slower by design or just because it's implementations
| have not been aggressively optimized?
| bhouston wrote:
| I believe it is just lacking aggressive optimization. ARM
| is basically RISC as well, so it isn't an architectural
| limitation.
| tightbookkeeper wrote:
| (Naive question) then is it really a big hurdle for a
| company who knows how to make arm chips to try making
| riscv chips?
| bhouston wrote:
| I suspect not? I think the principles and methods of
| optimization are the same.
|
| But I say this as a software guy who doesn't actually
| know CPU design.
| 1123581321 wrote:
| It's not a big hurdle so long as they hire Jim Keller to
| rapidly improve yet another architecture. (Only half-
| joking.)
| topspin wrote:
| Jim Keller is actually working on this right now at
| Tenstorrent.
| snvzz wrote:
| Ascalon (claiming Zen5-tier performance) is done, and has
| been available for licensing for about a year now.
|
| It was then made public that LG bought a license right
| away.
| saagarjha wrote:
| It's easy to claim a lot of things.
| snvzz wrote:
| >It's easy to claim a lot of things.
|
| It certainly is easy to casually spread fear and doubt.
|
| But it is really far-fetched to think that the people at
| Tenstorrent, who have successfully delivered very high
| performance microarchitectures in other companies before,
| are lying about Ascalon, and that LG is helping them do
| that.
|
| It would even be more far fetched to claim that Ventana
| Veyron V2, SiFive P870, Akeana 5000-series, all of them
| available high performance IP, are lying about
| performance.
| saagarjha wrote:
| Two years ago you were saying last year. Last year you
| were saying this year. Now you're saying next year. Maybe
| it's coming someday but I'm surely not going to believe
| you for it. Especially since you never seem to have
| anything to back it up other than, like, random people
| moving around between these companies soaking up VC
| funding. Where is the chip that is 70% as good as the
| competition? Where's the chip that is competitive with
| Zen 3? Still seems a ways off, no?
| snvzz wrote:
| >Two years ago you were saying last year. Last year you
| were saying this year. Now you're saying next year. Maybe
| it's coming someday but I'm surely not going to believe
| you for it.
|
| Your apparent beef with me is misguided.
|
| >Especially since you never seem to have anything to back
| it up
|
| Refer to public announcements by these companies. I am
| but an observer.
| svnt wrote:
| The question is more of will your customers agree to go
| along with this major architectural shift that sets you
| back on price-performance-power curves by at least five
| years and moves you out of the mainstream of board
| support packages, drivers, and everything else software-
| wise for phones.
|
| Also we should not pretend that ARM is just going to sit
| there waiting for RISC-V to catch up.
| tightbookkeeper wrote:
| Yes. This caveat is most clear. I am wondering about the
| question of performance raised in this thread,
| bhouston wrote:
| > The question is more of will your customers agree to go
| along with this major architectural shift that sets you
| back on price-performance-power curves by at least five
| years and moves you out of the mainstream of board
| support packages, drivers, and everything else software-
| wise for phones.
|
| Embedded is moving to RISC-V where they have low
| performance needs.
|
| One example is the Espressif line of CPUs - which have
| shipped over 1B units. They have moved most of their
| offerings to RISC-V over the last few years and they are
| very well supported by dev tools:
| https://www.espressif.com/en/products/socs
| bluGill wrote:
| Well you need several years to catch up - and those doing
| arm are not standing still. Same problem big software
| rewrites have, some are successful but it takes a large
| investment while everyone is still using the old stuff
| that is better for now.
| dagmx wrote:
| Making the chip isn't an issue for them. It's the
| software compatibility post facto.
| hajile wrote:
| We're not quite there yet. A bunch of mission critical stuff
| like SIMD were only added in the last 2-3 years. As it takes
| 4-5 years to design/ship high-performance chips, we still
| have a ways to go.
|
| Ventana Veyron looks interesting. Tenstorrent's upcoming
| 8-wide design should perform well.
|
| Qualcomm pitched making a bunch of changes to RISC-V that
| would move it closer to ARM64 and make porting easier, so I
| think it's an understatement to say that they are considering
| the idea. If ISA doesn't matter, why pay tons of money for
| the ISA?
| bhouston wrote:
| It is much more than just SIMD.
|
| I think RISC-V chips in the wild do not do things like
| pipelining, out-of-order, register renaming, multiple
| int/float/logic units, speculation, branch predictors,
| smart caching.
|
| I think all existing RISC-V chips in the wild right now are
| just simplistic in-order processors.
| avvvv wrote:
| Could patents be one of the reason why? Genuine question.
| shash wrote:
| Almost all in-order processors will do pipelining, so
| that's there. Many are even multi-issue. Andes has an out
| of order core [1] and so does SiFive (though I don't know
| of many actual chips using these.
|
| [1] https://www.andestech.com/en/2024/01/05/andes-
| announces-gene... [2]
| https://www.sifive.com/cores/performance-p650-670
| hajile wrote:
| You are wildly mistaken here.
|
| Back in 2016, BOOMv1 (Berkley Out-of-Order Machine) had
| pipelining, register renaming, 3-wide dispatch, branch
| predictor, caches, etc. A quick google seems to indicate
| that it was started in 2011 and had taped out 11 times by
| 2016 (with actual production apparently being done on IBM
| 45nm).
|
| They are on BOOMv3 now.
| shash wrote:
| There were two competing SIMD specs, and personally I'm
| glad that RVV won out over PSIMD. It's an easier
| programmer's view and fewer instructions to implement.
| qiqitori wrote:
| There is a chip out there that contains both an ARM and a
| RISC-V core, the RP2350. It's reasonable to assume that the
| ARM part and RISC-V part are manufactured in the same
| process. There are some benchmarks pitting the two against
| each other on e.g. this page:
| https://forums.raspberrypi.com/viewtopic.php?t=375268
|
| For a generic logic workload like Fibo(24), the performance
| is essentially the same (quote from above page):
| Average Runtime = 0.020015 Pico 2 Average Runtime =
| 0.019015 Pico 2 RiscV
|
| Note that neither core on the RP2350 comes with advanced
| features like SIMD.
| 05 wrote:
| It's a Cortex-M33, a 32bit microcontroller core with no
| virtual memory. Are we really comparing microcontrollers to
| modern aarch64 processors?
| delfinom wrote:
| Yes? Because nobody has released a RISC-V MPU comparable
| to what you perceive as "moden" arm64 MPUs.
|
| RISC-V is simply a ISA and not a core. The ISA affects
| some of the core architecture but the rest is also
| implementor specific. High-end cores will take time to
| reach market. Companies with big guns like Qualcomm can
| most likely pump out if they wanted to, and will most
| likely be doing so in the future since they are pumping
| over $1 billion into the effort.
| kimixa wrote:
| How you design a core is very different based on if
| you're targeting ultra-low-power tiny microcontroller
| designs vs high performance and high power
| laptop/desktop-tier designs.
|
| And it's not been proven that RISC-V is a good match for
| the second group (yet).
|
| Remember it's sometimes very non-obvious what quirks of
| an ISA might be difficult until you actually try to
| implement it - one of the reasons ARM had a pretty much
| "clean sheet" rewrite in ARMv8 is things like the
| condition codes turned out to be difficult to manage in
| wide superscalar designs with speculative execution -
| which is exactly the sort of thing required to meet the
| "laptop-tier" design performance requirements.
|
| It may be they've avoided all those pitfalls, but we
| don't really _know_ until it 's been done.
| bhouston wrote:
| It is true you can find slow ARM chips. But you cannot find
| fast RISC-V chips.
| talldayo wrote:
| I wager that statement would be turned on it's head if we
| restricted the comparison to chips of similar transistor
| density. Fast ARM chips _do_ exist, as ARMv8 designs
| fabbed on 5nm TSMC with noncompliant SIMD
| implementations. If there were RISC-V chips in the same
| vein as Ampere or Nvidia 's Grace CPU, I don't see any
| reason why they couldn't be _more_ competitive than an
| ARM chip that 's forced to adhere directly to the ISA
| spec.
|
| RISC-V hedged it's bet by creating different design specs
| for smaller edge applications and larger multicore
| configurations. Right now ARM is going through a rift
| where the last vestiges of ARMv6/7 support is holding out
| for the few remaining 32-bit customers. But all the
| progress is happening on the bloating ARMv9 spec that
| benefits nobody but Apple and Nvidia. For all of ARM's
| success in the embedded world, it would seem like they're
| at an impasse between low-power and high-power solutions.
| RISC-V could do both better at the same time.
| IshKebab wrote:
| You're confusing the ISA with the chip. Current RISC-V chips
| are slower than high performance ARM ones, but that's because
| you don't start by designing high performance chips! You
| start with small embedded cores and work your way up.
|
| Exactly the same thing happened with ARM. It started in
| embedded, then phones, and finally laptops and servers. ARM
| was never slow, they just hadn't worked up to highly complex
| high performance designs yet.
| wmf wrote:
| _you don 't start by designing high performance chips! You
| start with small embedded cores and work your way up._
|
| I disagree. For example, the first PowerPC was pretty fast
| and went into flagship products immediately. Itanium also
| went directly for the high end market (it failed for
| unrelated reasons). RISC-V would be much better off if some
| beastly chips like Rivos were released early on.
| snvzz wrote:
| The high end requires specifications that were not
| available until RVA22 and Vector 1.0 were ratified. First
| chips implementing these are starting to show up as seen
| in e.g. MILK-V Jupiter, which is one of the newest
| development boards in the market.
|
| With the ISA developed in the open, the base specs
| microcontrollers can target would naturally tend to be be
| ratified first, and thus microcontrollers would show up
| first. RVA22+V were ratified November 2021.
|
| With the ISA developed inside working groups involving
| several parties, some slowness would be unavoidable, as
| they all need to agree on how to move forward. Thus the
| years of gap until RVA22+V from the time the privileged
| and unprivileged specs were ratified (2019).
|
| RVA23 has just been ratified. This spec is on par with
| x86-64 and ARMv9, feature-wise. Yet hardware using it
| will of course in turn take years to appear as well.
| bhouston wrote:
| Isn't the problem the lack of advanced features for
| executing the current ISA with speed? I thought RISC-V
| chips seen in the wild do not pipelining, out-of-order,
| register renaming, multiple int/float/logic units,
| speculation, branch predictors, multi-tier caching, etc.
| The lack of speed isn't really related to a few missing
| vector instructions.
| monocasa wrote:
| There's a lot of cores that do all of that.
|
| Most cores are pipelined; it is RISC after all.
|
| There are quite a few superscalar cores, even a c906 is
| superscalar.
|
| The c910/c920 is an OoO, renaming core, with speculation.
|
| What they're lacking is area and power. A ROB with six
| entries is not going to compete with a ROB of six hundred
| entries.
| IshKebab wrote:
| The first PowerPC chip was introduced in 1992! Itanium
| was in 2001, wasn't a from-scratch design and was
| famously a disaster!
|
| Not really comparable.
| dagmx wrote:
| Maybe fine for Android but this will set their windows plans
| back another decade if it happens
|
| It has taken them that long to make arm be a thing on windows
| and that's building on people porting stuff to arm for Mac to
| finally get momentum.
|
| RISC-V with windows will be an eternity to be feasible.
| snvzz wrote:
| >RISC-V with windows will be an eternity to be feasible.
|
| Will it now?
|
| Microsoft was already deeply involved in 2021 as per that
| years' summit RISC-V Foundation's technical talks. Ztso was
| pushed by them.
| dagmx wrote:
| Whether Microsoft has windows running on an architecture is
| a very different level from whether it's feasible to use it
| as a daily driver on windows. The ecosystem is what matters
| for most people.
|
| Windows for arm hails back to 2011. They're only just now
| getting native arm ports for several major packages. That's
| ~13 years for a well established architecture that's used
| much more universally than RISC-V. They don't even have arm
| ports for lots of software that has arm ports on macOS.
|
| RISC-V will take an aeon longer to get a respectable amount
| of the windows ecosystem ported over.
| snvzz wrote:
| >The ecosystem is what matters for most people.
|
| Absolutely agree.
|
| The key development Microsoft has demonstrated recently
| is the ability to run x86 Windows software in non-x86
| Windows systems.
|
| Now that this is in place -and will only get better-,
| there is no longer a chicken and egg situation.
|
| Instead, what we have is a clearly defined path to
| migrate away from x86.
| Atotalnoob wrote:
| Arm on windows may date to 2011, but it was mostly a side
| project with 1-2 maintainers. With sufficient investment,
| it shouldn't take 13 years to build up RISC-V support.
| snvzz wrote:
| This.
|
| It is evident to anybody paying attention that Microsoft
| has RISC-V support well underway.
|
| But even if they had to start from scratch, it would be
| much easier, thanks to ARM having paved the way.
| dagmx wrote:
| How do you imagine ARM having helped?
| monocasa wrote:
| The x86 emulator for one.
| dagmx wrote:
| Fair, though I don't think translation is a good long
| term strategy. You need native apps otherwise you're
| always dealing with a ~20-30% disadvantage.
|
| The competition isn't sitting still either and QC already
| hit this with Intel stealing their thunder with Lunar
| Lake. They're efficient enough that the difference in
| efficiency is far overshadowed by their compatibility
| story.
|
| Ecosystem support will always go to the incumbent and
| this would place RISC-V third behind x86 and ARM. macOS
| did this right by saying there's only one true way
| forward. It forces adoption.
| snvzz wrote:
| >You need native apps
|
| For native apps, you need users. For users, you need
| emulation.
|
| It cannot be overstated how important successful x86
| emulation is for the migration to anything else to be
| feasible.
| dagmx wrote:
| I think you just ignored the rest of my comment though
| which specifically addresses why I don't think just
| relying on translation is an effective strategy. Users
| aren't going to switch to a platform that has lower
| compatibility when the incumbent has almost as good
| efficiency and performance.
| snvzz wrote:
| >when the incumbent has almost as good efficiency and
| performance.
|
| The incumbent is the only two companies -Intel and AMD-
| that can make x86 hardware.
|
| The alternative is the rest of the industry.
|
| Thus having a migration path should be plenty on its own.
|
| Intel and AMD can both join by making RISC-V or ARM
| hardware themselves. My take is that they will too,
| eventually, come around. Or they'll just disappear from
| relevance.
| dagmx wrote:
| The incumbent is not just x86 but now ARM as well.
|
| You have to think in network effects. You mention "the
| rest of the industry" yet ignore that it's mostly arm ,
| which would make arm the incumbent.
|
| x86 is the king for windows. But ARM has massive inroads
| with mobile, and now desktop with macOS, and servers with
| Amazon/Nvidia etc
|
| There's a lot better incentive to support ARM than RISC-V
| for software developers. It isn't one or the other , but
| it is a question of resources.
|
| Intel and AMD seem fine turning x86 around when
| threatened as can be seen by Lunar Lake and Stryx Point.
| Both have been good enough to steal QC's thunder. You
| don't think ARM manufacturers will do the same to RISC-V?
|
| TBH most of your arguments for RISC-V adoption seem to
| start from the position that it's inevitable AND that
| competing platforms won't also improve.
| MBCook wrote:
| Like everything else, it doesn't matter much. Windows ran
| on Itanium, Alpha, and as pointed out ARM for over a
| decade.
|
| Without the ISVs, it's a flop for consumers.
|
| MS has had an abysmal time getting them to join in on
| ARM, only starting to have a little success now. Saying
| "Ha ha, just kidding, it's RISC-V now" would be a
| _disaster_. That's the kind of rug pull that helped kill
| Windows Mobile.
|
| Emulators aren't good enough. They're a stop gap. Unless
| the new chip is so much better than the old it's faster
| with emulation then the old one was native no one will
| accept it long. Apple's been there, but that's not where
| MS sits today.
|
| And if your emulator is too good, what stops ISVs from
| saying "you did it for us, we don't have to care"? So
| once again they don't have to do it at all and you have
| no native software.
|
| MS can't drop their ARM push unless they want to drop all
| non-x86 initiatives for a long time.
| snvzz wrote:
| >And if your emulator is too good, what stops ISVs from
| saying "you did it for us, we don't have to care"? So
| once again they don't have to do it at all and you have
| no native software.
|
| x86 emulation enables adoption.
|
| Adoption means having an user base.
|
| Having an user base means developers will consider making
| the platform a target.
|
| >Saying "Ha ha, just kidding, it's RISC-V now" would be a
| disaster.
|
| Would it now? If anything, offering RISC-V support as
| well would further reinforce the idea that Windows is
| ISA-independent, and not tied to x86 anymore.
| MBCook wrote:
| > If anything, offering RISC-V support as well would
| further reinforce the idea that Windows is ISA-
| independent, and not tied to x86 anymore.
|
| Anymore? It's been independent since the 90s. It's only
| ISVs that have been an issue.
|
| And a rug pull is a fantastic way to scare all the ISVs
| far far away.
| snvzz wrote:
| Whose's rug would even be pulled?
| numpad0 wrote:
| Switching CPU architecture is not about changing a
| compilation option, it's about eliminating centuries old
| assembly codes, binaries, and third party components and
| re-engineering everything to be self hosted on-prem at
| the company. Commercial software companies are reckless
| and stupid lazy and unbelievably inept, so lots of them
| won't be able to do this, especially for the second time.
|
| In case this translation was needed at all. The point is
| the point is not a "-riscv" compilation option.
| dagmx wrote:
| So which of Microsoft's false starts would you take as
| them taking ARM seriously?
|
| Why do you think they'd take RISC-V any more seriously
| than their previous attempts at ARM?
|
| There are two fallacies to overcome here.
| numpad0 wrote:
| Just something I as a random person been thinking, how likely
| is next version of Windows _not_ going to be something Linux-
| based with WINE+Bochs preinstalled?
|
| Windows branding is now forever tied with x86/x64 Win32
| legacy compatibility, meanwhile WSL had captured back a lot
| of webdevs from Mac. Google continues to push Chrome, but
| Electron continues to grow side by side. Lots of stuff
| happening with AI on Linux too, with both Windows and Mac
| remaining to be consumer deployment targets. Phone CPUs are
| fast enough to run some games on WINE+Bochs.
|
| At this point, would it not make sense for MS to make its own
| ChromeOS and bolt-on an "LSW"?
| dagmx wrote:
| I think it's almost certain that Microsoft will not be
| changing their kernel to Linux.
|
| I think you're over estimating what percentage of users use
| WSL. They're an insignificant fraction of the user base.
|
| And with games, I think you're also overestimating how good
| the translation layers like Proton are, and how rapidly
| Microsoft advance DX as well.
| wmf wrote:
| https://archive.ph/FcXRW
| chriscappuccio wrote:
| https://archive.is/FcXRW
| wmf wrote:
| This "cancellation" is likely to be paused until the lawsuit is
| resolved so it's hard to say what this means. Presumably this is
| a part of the negotiations going on behind the scenes.
| MBCook wrote:
| Let's just assume this happens for a moment.
|
| What do Android OEMs do? They can't use Apple chips, or now
| Qualcomm chips. Switching to another architecture is a big deal.
|
| Would this basically hand the Android market to Samsung and their
| Exynos chips? Or does another short term viable competitor exist?
| magnio wrote:
| MediaTek is still available.
| plussed_reader wrote:
| I notice how 'viable' isn't an operative in your statement.
| Iwan-Zotow wrote:
| Dimensity 9400 looks good
| refulgentis wrote:
| They're pretty good. Just can't beat qualcomm / Apple
| flagship. So around Intel level ;)
| tacticus wrote:
| 300W in a phone chip is a bit toasty.
| smolder wrote:
| Intel's latest Arrow Lake stuff, about to go on sale, is
| said to have much better power efficiency, FWIW.
| Something like half the wattage for roughly equivalent
| benchmark results, according to them.
| imp0cat wrote:
| They've come a long way, Samsung is apparently considering
| Mediatek chips for their next flagship phone (S25).
| ThatPlayer wrote:
| Their flagship tablets line up, Galaxy Tab S10 plus and
| ultra, is entirely Mediatek too.
| numpad0 wrote:
| MediaTek was always viable, it was always GPU that made
| non-Qualcomm non-viable
| NelsonMinar wrote:
| Don't know about cell phones but their Chromebooks are pretty
| good.
| mappu wrote:
| Without (complete) kernel sources, they're already e-waste.
| nolist_policy wrote:
| No problem, as they are used in chromebooks:
|
| https://chromium.googlesource.com/chromiumos/third_party/ke
| r...
|
| https://chromium.googlesource.com/chromiumos/third_party/ke
| r...
| jjpprrrr wrote:
| There is MTK that offers the Dimensity series SoCs with Arm
| cores. Qcom can also go back to using Arm Cortex cores in the
| next Snapdragon SoC.
| jsheard wrote:
| This move doesn't stop Qualcomm from licensing ARMs reference
| cores, it only blocks them from designing their own in-house
| ARM cores like Apple does. The vast majority of Qualcomm chips
| currently on the market are built around reference cores, they
| only recently got back into the custom core game with their
| acquisition of Nuvia which also kicked off this dispute with
| ARM.
| dv_dt wrote:
| There are probably Risc-V companies eagerly anticipating an
| opportunity in that space, but I don't know if any are in the
| performance ballpark right now.
| Narishma wrote:
| Qualcomm itself is one such company.
| greesil wrote:
| Everyone's going to have to buy a Pixel phone, ahahahahaahahha.
| gruez wrote:
| Samsung phones are presumably firm as well. They recently
| switched to snapdragon (qualcomm) chips but before they were
| using exynos (samsung) chips.
| jsheard wrote:
| Samsung phones use both, in a very literal sense. Their
| flagship devices usually have both Snapdragon and Exynos
| variants for different regions, and their lower end devices
| are mostly Exynos across the board.
|
| The S23 line was an exception in using Snapdragon
| worldwide, but then the S24 line switched back to using
| Snapdragon in NA and Exynos everywhere else, except for the
| S24 Ultra which is still Snapdragon everywhere.
|
| Yes it's a confusing mess, and it's arguably misleading
| when the predominantly NA-based tech reviewers and
| influencers get the usually superior QCOM variant, and
| promote it to a global audience who may get a completely
| different SOC when they buy the "same" device.
| MBCook wrote:
| Is the Qualcomm chip still considered significantly
| better than the Exynos? I remember that was the case a
| few years ago.
| kijin wrote:
| Last time I checked, the latest Qualcomm Snapdragon was
| faster and more energy efficient than the latest Exynos.
| Especially the top-binned chips that Samsung gets.
|
| Still, the fact that Samsung can swap out the chip in
| their flagship product with virtually no change other
| than slightly different benchmark scores means that these
| chips are pretty much fungible. If either manufacturer
| runs into serious problems, the other one is ready to eat
| their market share for lunch.
| delfinom wrote:
| Yes, Exynos is still behind in performance and thermals.
| Exynos modems are also still garbage and plague Pixel
| phones with issues. Though slowly improving with each
| generation, it's awful that it's being troubleshot in
| public over years.
| devsda wrote:
| Samsung still uses qualcomm in US markets and exynos
| outside US even for their flagships.
| snvzz wrote:
| Bloomberg disappoints by failing to mention RISC-V at all in the
| entire article.
|
| They have to be doing this deliberately, as it's hard to explain
| otherwise.
| duxup wrote:
| If the comments in here are correct, RISC-V is really not an
| option at this time due to performance.
| snvzz wrote:
| >due to performance
|
| That would require pretending Ventana Veyron V2, Tenstorrent
| Ascalon/Alastor, SiFive P870, Akeana 5000-series and others
| do not exist or do not yet have any customers.
|
| Pretending, because they actually exist, have customers, and
| are thus bound to show up in actual products anytime now.
| duxup wrote:
| I don't feel like you addressed the performance issue.
|
| I don't think anyone said they don't exist.
| bhouston wrote:
| And Qualcomm is the only competitive ARM chip on the market
| besides Apple's. And now they are being taken out by ARM. Is it
| really that expensive to re-license things? This seems self-
| defeating.
| UltraSane wrote:
| AWS has the Graviton ARM CPU that is pretty competitive but you
| can only rent them.
| jsheard wrote:
| Ampere has Graviton-like chips that you can actually buy, but
| neither Graviton or Ampere are really in the same market
| segment as Qualcomm and Apple.
| hedora wrote:
| System76 recently released an ampere desktop. It starts at
| about half the price of a Mac Pro and seems to top out at
| many more cores.
|
| I'm not sure if the low end ampere is as slow as a high end
| mac though.
| bhouston wrote:
| I believe Graviton is competitive in the server market yes,
| but not in mobile or laptops.
| hajile wrote:
| Graviton4 is based on Neoverse V2 which is based on X3.
|
| Neoverse V3 was announced Feb of this year. It should have
| an 80-85% performance increase and should basically be
| based on something very close to x925.
| seabrookmx wrote:
| Graviton is just an ARM neoverse core no? It's not a bespoke
| design.
| bhouston wrote:
| I think so.
| hajile wrote:
| Now that the Nvidia deal has fallen through, SoftBank is trying
| to ramp up profitability while continuing to search for another
| buyer.
| zbshqoa wrote:
| Ah? ARM doesn't build chips but provides the architecture and
| license it to other companies.
|
| There are plenty of ARM chips designed by multiple companies
| and built by multiple foundries
| dagmx wrote:
| ARM licenses cores for both CPU and GPU, not just the
| architecture.
|
| There are not "plenty of ARM chips designed by multiple
| companies", almost all of them except for Apple (and now
| Qualcomm) use ARMs off the shelf design.
| HeuristicsCG wrote:
| Also NPU
| zbshqoa wrote:
| https://www.arm.com/markets/computing-
| infrastructure/cloud-c...
|
| > Annapurna Labs, Ampere Computing, NVIDIA, Intel, Marvell,
| Pensando Systems, and others use Arm Neoverse and Arm
| technologies to create cloud-optimized CPUs and DPUs.
|
| https://en.m.wikipedia.org/wiki/ARM_architecture_family
|
| > Companies that have designed cores that implement an ARM
| architecture include Apple, AppliedMicro (now: Ampere
| Computing), Broadcom, Cavium (now: Marvell), Digital
| Equipment Corporation, Intel, Nvidia, Qualcomm, Samsung
| Electronics, Fujitsu, and NUVIA Inc. (acquired by Qualcomm
| in 2021).
| dagmx wrote:
| The first list is basically what I said: they use
| licensed core designs and don't make their own.
|
| The second list is out of date. Intel has completely
| pulled out of ARM earlier this year and most of the
| others do not actually design their own ARM cores
| anymore. It's become a lot less common in the ARMv8+ era.
| bufferoverflow wrote:
| Samsung and MediaTek make pretty competitive ARM processors.
|
| MediaTek 9400 is literally the top-performing SoC on the
| market.
|
| Samsung Exynos 2400, 2400e
|
| MediaTek Dimensity 9400, 9300 Plus, 9300
|
| https://nanoreview.net/en/soc-list/rating
| bhouston wrote:
| The geekbench scores of Apple are highest and then Qualcomm
| according to this page. MediaTek's top chip is literally 25%
| slower according to his listing.
|
| The ordering in ranking is a little weird.
| HDThoreaun wrote:
| 25% slower than apple is more than enough for a mobile
| chip. The new apple chips are faster than desktop chips
| from a few years ago
| nashashmi wrote:
| I never thought I would hear MediaTek and top chip maker in
| the same line
| mdasen wrote:
| The issue is that Qualcomm wants to switch to ARM chips where
| they don't pay ARM much money.
|
| When you're making ARM chips, you can either license the
| instruction set or you can license whole core designs. Most
| people license whole core designs. You build a chip using an
| ARM Cortex X4 core, 3 Cortex A720 cores, and 4 Cortex A520
| cores and call it a day. But when you're using ARM's core
| designs, you have to pay them a lot to license those core
| designs. But when you're licensing the instruction set (and
| designing your own cores), you pay ARM a tiny licensing fee.
| This is what Apple does.
|
| In this case, the story goes:
|
| A startup called Nuvia wanted to create custom ARM cores for
| servers and negotiated a deal with ARM that was very favorable
| since ARM would like to grow its server marketshare. The
| agreement included a stipulation that they couldn't sell their
| IP to another company for that other company to build ARM cores
| built on Nuvia IP (according to ARM). Qualcomm argues that they
| have an instruction set license so they're allowed to build
| custom cores based off that license. ARM says that Nuvia's
| instruction set license means that Qualcomm can't.
|
| I don't know what the cost difference is between core licenses
| and instruction licenses, but some places seem to think it's
| around 5x. Qualcomm has around 35% of the ARM chip market, but
| crucially a huge portion of the more expensive (and profitable
| for ARM) flagship cores. It's possible that Qualcomm is half of
| ARM's business (maybe more). If Qualcomm shifts to their own
| core designs and starts paying ARM 20% of what they're paying
| now, that could wipe out 40% of ARM's revenue.
|
| If Qualcomm can shift from more expensive core licenses to
| cheaper instruction licenses, it would wipe out a huge portion
| of ARM's business. Worse, if those cores are better and become
| the de-facto flagship cores, it'd wipe out even more of ARM's
| business as companies like Samsung and Google might feel the
| need to buy Qualcomm chips (with better cores) rather than
| buying ARM's Cortex X cores for their flagship phones.
|
| Likewise, Qualcomm is unlikely to stop at smartphones. They're
| already moving into laptops which will make it harder for any
| company using ARM-designed cores to get a foothold there.
| Qualcomm could move into servers in the near future and offer
| something better than the ARM Neoverse cores that are used by
| AWS's Graviton, Google's Axion, and Ampere.
|
| So it's an enormous threat to ARM's business and ARM feels like
| it gave Nuvia a sweetheart deal because they were a small
| startup looking to enter a mostly new market rather than
| disrupting their current business - and they gave them a
| license with restrictions on it. Then Nuvia sold to Qualcomm
| who is using that IP to stop paying ARM - and ARM thinks that
| goes against the restrictions that Nuvia agreed to.
| Joel_Mckay wrote:
| Next week, Qualcomm will likely announce a 64 core RISC-V RVA23.
|
| ARM really shouldn't pursue an aggressive posture with lines
| outside iOS or Win11 ecosystems. The leverage won't hold a
| position already fractured off a legacy market. =3
| chx wrote:
| 1. I am fairly sure games and other performance sensitive apps
| are using the Android NDK which is not available for RISC-V.
|
| 2. I am fairly sure a competitive RISC-V CPU is not days or
| weeks but years away.
| svnt wrote:
| > 2. I am fairly sure a competitive RISC-V CPU is not days or
| weeks but years away.
|
| And chasing a moving target fueled by the largest technology
| companies on the planet.
| Joel_Mckay wrote:
| Tying products to Googles ecosystem is usually financially
| risky. Not a good long-term strategy for startups. =3
| Joel_Mckay wrote:
| I think it is more of a "chicken and egg" ordering problem.
|
| 1. The RISC-V design standard fragmentation issue has been
| addressed.
|
| 2. A reasonable mobile class level SoC will be available for
| integration after any large production run of the chips.
|
| If ARM forces #2 out of silliness, than it also accelerates
| #1 in the market.
|
| In general, there is plenty of use-cases even if a chip is
| not cutting edge. =3
| SG- wrote:
| you think they can just flip a RISC-V switch and keep all the
| performance instantly? I can't really understand the logic from
| some people here.
| Joel_Mckay wrote:
| "keep all the performance instantly"
|
| Depends what you mean by performance (most vendors ARM
| accelerated features are never used for compatibility
| reasons), as upping the core count with simpler architecture
| is a fair trade on wafer space.
|
| i.e. if ARM is using anti-trust tactics to extort more
| revenue, that budget is 100% fungible with extra resources.
| Note, silicon is usually much cheaper than IP licenses.
|
| One can ask polity to explain things without being rude to
| people. Have a wonderful day =3
| mrweasel wrote:
| People also seem to forget that everything needs to be
| ported. If you're an Android manufacturer, you're not going
| to stop shipping phones, waiting for the Android RISC-V to
| catch-up to ARM, or for RISC-V to get the speed and features
| of current ARM CPUs. You're going to buy ARM processors from
| another vendor.
|
| The Windows ARM port is going to take even longer, I doubt
| that Microsoft has that working at anything beyond research
| stage, if that.
|
| Getting the RISC-V ecosystem up to par with ARM is going to
| take years.
|
| If you want to spin this in RISC-Vs favor, then yes, forcing
| a company like Qualcomm to switch would speed things up, but
| it might also give them a bit of a stranglehold on the
| platform, in the sense that they'd be the dominant platform,
| with all of their own customisations.
| Joel_Mckay wrote:
| In theory, the Raspberry Pi foundation could easily move 3
| million 1.8GHz RVA23 in 1 quarter... with 64 cores + DSP
| ops it wouldn't necessarily need a GPU initially. =3
| mrweasel wrote:
| The Raspberry Pi community would probably jump on a
| RISC-V board, but that doesn't help Qualcomm or it's
| customers.
| Joel_Mckay wrote:
| Manufacturers adapt quickly to most architectural
| changes.
|
| If you are running in a posix environment, than porting a
| build is measured in days with a working bootstrap
| compiler. RISC-V already has the full gcc and OS
| available for deployment.
|
| We also purchase several vendors ARM products for
| deployment. Note, there was a time in history, when
| purchasing even a few million in chips would open custom
| silicon options.
|
| Given how glitched/proprietary/nondeterministic ARM ops
| are outside the core compatibility set, it is amazing it
| was as popular as the current market demonstrates.
|
| Engineers solve problems, and ARM corporation has made
| themselves a problem. =3
| kmeisthax wrote:
| Funnily enough Qualcomm tried to persuade RISC-V to let them
| drop compressed instructions. Presumably because they're trying
| to crowbar a RISC-V decoder onto the Nuvia design and
| compressed instructions are breaking it somehow.
| Joel_Mckay wrote:
| They should buy the intel alumni founded RISC-V startup, and
| pour resources into a RVA23 based chip with dual on-chip SDR
| asic sections (they have the IP).
|
| i.e. create a single open-chip solution for mid-tier mobile
| communication platforms.
|
| They won't do this due to their cellular chip line interests.
| However, even if it just ran a bare bones Linux OS... it
| would open up entire markets. =3
| delfinom wrote:
| With how poorly Intel is doing, not sure "Intel alumni" is
| a plus. Lmao.
| Joel_Mckay wrote:
| Indeed, the Intel installed base has enough market
| inertia to last a business cycle or two with AMD.
|
| Even with the recent silicon defects... People will
| tolerate the garbage as they want the NVIDIA+Intel
| performance.
|
| Architecturally speaking, there were better options
| available... just never the equivalent price over
| performance of consumer grade hardware. =)
| mushufasa wrote:
| Qualcomm is known for having a particularly aggressive &
| hardball-style legal department to enforce its patents on core
| telecom IP. I believe the most likely outcome is they just settle
| the dispute here. Arm fighting hardball with hardball.
|
| Which would not really affect the ecosystem of phones using
| Qualcomm arm chips, it would just change the margins / market cap
| of Qualcomm.
|
| Yes, longterm Q might invest in their own RISC implementations,
| but I don't see a viable business case for Qualcomm to just stop
| ARM development for the foreseeable future.
| chasil wrote:
| The phones haven't been custom ARM chips since 32-bit Krait,
| IIRC.
|
| This is about Nuvia.
|
| https://en.m.wikipedia.org/wiki/Krait_(processor)
| lizknope wrote:
| Snapdragon 805 had a 32-bit Krait designed by Qualcomm
|
| https://www.qualcomm.com/products/mobile/snapdragon/smartpho.
| ..
|
| 810 had a 64-bit core designed by ARM
|
| https://www.qualcomm.com/products/mobile/snapdragon/smartpho.
| ..
|
| 820/821 had a 64-bit Kryo custom core designed by Qualcomm
|
| https://www.qualcomm.com/products/mobile/snapdragon/smartpho.
| ..
|
| After that it was all cores from ARM. The custom CPU team
| worked on their server chip before getting cancelled and most
| of the team went to Microsoft
| chasil wrote:
| I need to have a closer look. Thanks.
| haerwu wrote:
| When you look at https://gpages.juszkiewicz.com.pl/arm-
| socs-table/arm-socs.ht... table then you can see that in
| Snapdragon 8xx series the first "ARM cores out of shelf"
| was 888 in 2020.
|
| 865 (2019) has Cortex-A77 + Kryo 4xx Silver 888 (2002) uses
| Cortex-X1 + Cortex-A78 + Cortex-A55 cores
| adrian_b wrote:
| Most of the cores branded "Kryo" have negligible
| differences from the original Arm cores. There might be
| some differences in the cache memories and in the
| interfaces between the cores and the rest of the Qualcomm
| SoC, but there are no differences in the inner CPU cores.
|
| Snapdragon 865 has standard Arm cores. The same is true
| for the older Snapdragon 855, Snapdragon 845 and
| Snapdragon 835, which I am using or I have used in my
| phones.
|
| The claim of Qualcomm that those cores have been "semi-
| custom", is mostly BS, because the changes made by
| Qualcomm to the cores licensed from Arm have been
| minimal.
| lizknope wrote:
| That table doesn't have the Snapdragon 810
|
| https://www.qualcomm.com/products/mobile/snapdragon/smart
| pho...
|
| I worked on it in 2014. The table does have 808 listed.
| That may have been a lower end version.
|
| Qualcomm got caught being late. They were continuing
| development of custom 32-bit cores and Apple came out
| with a 64-bit ARM core in the iPhone. The Chief Marketing
| Officer of Qualcomm called it a gimmick but Apple was a
| huge customer of Qualcomm's modems. Qualcomm shoved him
| off to the side for a while.
|
| https://www.cnet.com/tech/mobile/qualcomm-gambit-
| apple-64-bi...
|
| Because Q's custom 64-bit CPU was not ready the stop gap
| plan was to license a 64-bit RTL design from ARM and use
| that in the 810. It also had overheating problems but
| that's different issue. There were a lot of internal
| politics going on at Q over the custom cores and server
| chips that ended up in layoffs.
| hajile wrote:
| Qualcomm doesn't have nearly as much to lose as ARM does and
| they know it.
|
| Qualcomm is almost certainly ARM's biggest customer. If ARM
| loses, Qualcomm doesn't have to pay out. If ARM wins, Qualcomm
| moves to RISC-V and ARM loses even harder in the long-term.
|
| The most likely outcome is that Qualcomm agrees to pay a slight
| bit more than they are currently paying, but nowhere near what
| ARM is demanding and in the meantime, Qualcomm continues having
| a team work on a RISC-V frontend for Oryon.
| svnt wrote:
| You're suggesting that Snapdragon processors would switch to
| RISC-V and that would be no big deal? Presumably Qualcomm is
| committed to numerous multi-year supplier agreements for the
| arm chipsets.
| monocasa wrote:
| This affects their custom Nuvia derived cores. I'm sure
| Qualcomm will be able to keep using ARM designed cores to
| cover themselves while they ween off ARM in favor of RISC-V
| if they need to.
| hajile wrote:
| Qualcomm pitched Znew quite a while ago. It mostly ditched
| 16-bit instructions and added a bunch of instructions that
| were basically ripped straight from ARM64.
|
| The idea was obviously an attempt at making it as easy as
| possible to replace ARM with RISC-V without having to
| rework much of the core.
|
| https://lists.riscv.org/g/tech-
| profiles/attachment/332/0/cod...
| snvzz wrote:
| An attempt that failed miserably. (it was formally
| rejected a year ago)
|
| But, by now, it is expected that Qualcomm's RISC-V
| designs have been re-aligned to match the reality that
| Qualcomm does not control the standard.
| dwaite wrote:
| Actually, it was an attempt to reuse as much of the ARM
| design they got when they bought Nuvia moving to a
| different CPU architecture. They were worried about ASIC
| design not software code.
| nemothekid wrote:
| > _Qualcomm moves to RISC-V and ARM loses even harder in the
| long-term._
|
| I think long term is doing a lot of heavy lifting here. How
| long until:
|
| 1. Qualcomm develops a chip that competitive in performance
| to ARM
|
| 2. The entire software world is ready to recompile everything
| for RISC-V
|
| Unless you are Apple I see such a transition taking a decade
| easily.
| coder543 wrote:
| > 1. Qualcomm develops a chip that competitive in
| performance to ARM
|
| Virtually all high performance processors these days
| operate on their own internal "instructions". The
| instruction decoder at the very front of the pipeline that
| actually sees ARM or RISC-V or whatever is a relatively
| small piece of logic.
|
| If Qualcomm were motivated, I believe they could swap ISAs
| relatively easily on their flagship processors, and the
| rest of the core would be the same level of performance
| that everyone is used to from Qualcomm.
|
| This isn't the old days when the processor core was deeply
| tied to the ISA. Certainly, there are things you can
| optimize for the ISA to eke out a little better
| performance, but I don't think this is some major obstacle
| like you indicate it is.
|
| > 2. The entire software world is ready to recompile
| everything for RISC-V
|
| #2 is the _only_ sticking point. That is ARM's only moat as
| far as Qualcomm is concerned.
|
| Many Android apps don't depend directly on "native" code,
| and those could potentially work on day 1. With an ARM
| emulation layer, those with a native dependency could
| likely start working too, although a native RISC-V port
| would improve performance.
|
| If Qualcomm stopped making ARM processors, what
| alternatives are you proposing? Everyone is switching to
| Samsung or MediaTek processors?
|
| If Qualcomm were switching to RISC-V, that would be a sea
| change that would actually move the needle. Samsung and
| MediaTek would probably be eager to sign on! I doubt they
| love paying ARM licensing fees either.
|
| But, all of this is a very big "if". I think ARM is
| bluffing here. They _need_ Qualcomm.
| x0x0 wrote:
| > Virtually all high performance processors these days
| operate on their own internal "instructions". The
| instruction decoder at the very front of the pipeline
| that actually sees ARM or RISC-V or whatever is a
| relatively small piece of logic.
|
| If that's true, then what is arm licensing to Qualcomm?
| Just the instruction set or are they licensing full
| chips?
|
| Sorry for the dumb question / thanks in advance.
| coder543 wrote:
| Qualcomm has historically licensed both the instruction
| set and off the shelf core designs from ARM. Obviously,
| there is no chance the license for the off the shelf core
| designs would ever allow Qualcomm to use that IP with a
| competing instruction set.
|
| In the past, Qualcomm designed their own CPU cores
| (called Kryo) for smartphone processors, and just made
| sure they were fully compliant with ARM's instruction
| set, which requires an Architecture License, as opposed
| to the simpler Technology License for a predesigned off
| the shelf core. Over time, Kryo became "semi-custom",
| where they borrowed from the off the shelf designs, and
| made their own changes, instead of being fully custom.
|
| These days, their smartphone processors have been
| entirely based on off the shelf designs from ARM, but
| their new Snapdragon X Elite processors for laptops
| include fully custom Oryon ARM cores, which is the
| flagship IP that I was originally referencing. In the
| past day or two, they announced the Snapdragon 8 Elite,
| which will bring Oryon to smartphones.
| x0x0 wrote:
| thank you for explaining
| dmitrygr wrote:
| A well-designed (by apple [1], by analyzing millions of
| popular applications and what they do) instruction set.
| One, where there are reg+reg/reg+shifted_reg addressing
| modes, only one instruction length, and sane useful
| instructions like SBFX/UBFX, BFC, BFI, and TBZ. All of
| that is much better than promises of a magical core that
| can fuse 3-4 instructions into one magically.
|
| [1] https://news.ycombinator.com/item?id=31368681
| x0x0 wrote:
| 1 - thank you
|
| 2 - thank you again for sharing your eink hacking
| project!
| sgc wrote:
| Naively, it would seem like it would be as simple as
| updating android studio and recompiling your app, and you
| would be good to go? There must be less than 1 in 1000
| (probably less than 1 in 10,000) apps that do their own
| ARM specific optimizations.
| coder543 wrote:
| Without any ARM specific optimizations, most apps
| wouldn't even have to recompile and resubmit. Android
| apps are uploaded as bytecode, which is then AOT compiled
| by Google's cloud service for the different
| architectures, from what I understand. Google would just
| have to decide to support another target, and Google has
| already signaled their intent to support RISC-V with
| Android.
|
| https://opensource.googleblog.com/2023/10/android-and-
| risc-v...
| vel0city wrote:
| I remember when Intel was shipping x86 mobile CPUs for
| Android phones. I had one pretty soon after their
| release. The vast majority of Android apps I used at the
| time just worked without any issues. There were some apps
| that wouldn't appear in the store but the vast majority
| worked pretty much day one when those phones came out.
| coder543 wrote:
| Yep! I had the Zenfone with an Intel processor in it, and
| it worked well!
| iggldiggl wrote:
| I'm not sure how well it fits the timeline (i.e. x86
| images for the Android emulator becoming popular due to
| better performance than the ARM images vs. actual x86
| devices being available), but at least these days a lot
| of apps shipping native code probably maintain an x86/x64
| version purely for the emulator.
|
| Maybe that was the case back then, too, and helped with
| software availability?
| iggldiggl wrote:
| > Android apps are uploaded as bytecode, which is then
| AOT compiled by Google's cloud service for the different
| architectures, from what I understand.
|
| No, Android apps ship the original bytecode which then
| gets compiled (if at all) on the local device. Though
| that doesn't change the result re compatibility.
|
| However - a surprising number of apps _do_ ship native
| code, too. Of course especially games, but also any other
| media-related app (video players, music players, photo
| editors, even my e-book reading app) and miscellaneous
| other apps, too. There, only the original app developer
| can recompile the native code to a new CPU architecture.
| coder543 wrote:
| > No, Android apps ship the original bytecode which then
| gets compiled (if at all) on the local device.
|
| Google Play Cloud Profiles is what I was thinking of, but
| I see it only starts "working" a few days after the app
| starts being distributed. And maybe this is merely a
| default PGO profile, and not a form of AOT in the cloud.
| The document isn't clear to me.
|
| https://developer.android.com/topic/performance/baselinep
| rof...
| iggldiggl wrote:
| Yup, it's just a PGO profile (alternatively, developers
| can also create their own profile and ship that for their
| app).
| IshKebab wrote:
| 1. That doesn't mean you can just slap a RISC-V decoder
| on an ARM chip and it will magically work though. The
| semantics of the instructions and all the CSRs are
| different. It's going to be way more work than you're
| implying.
|
| But Qualcomm have already been working on RISC-V for ages
| so I wouldn't be too surprised if they already have high
| performance designs in progress.
| coder543 wrote:
| That is a good comment, and I agree things like CSR
| differences could be annoying, but compared to the
| engineering challenges of designing the Oryon cores from
| scratch... I still think the scope of work would be
| relatively small. I just don't think Qualcomm seriously
| wants to invest in RISC-V unless ARM forces them to.
| sarlalian wrote:
| The bigger question is how much of their existing cores
| utilize Arm IP... and how sure are they that they would
| find all of it?
| eigenform wrote:
| > I just don't think Qualcomm seriously wants to invest
| in RISC-V unless ARM forces them to.
|
| That makes a lot of sense. RISC-V is really not at all
| close to being at parity with ARM. ARM has existed for a
| long time, and we are only _now_ seeing it enter into the
| server space, and into the Microsoft ecosystem. These
| things take a lot of time.
|
| > I still think the scope of work would be relatively
| small
|
| I'm not so sure about this. Remember that an ISA is not
| just a set of instructions: it defines how virtual memory
| works, what the memory model is like, how security works,
| etc. Changes in those things percolate through the entire
| design.
|
| Also, I'm going to go out on a limb and claim that
| verification of a very high-powered RISC-V core that is
| going to be manufactured in high-volume is probably much
| more expensive and time-consuming than the case for an
| ARM design.
|
| edit: I also forgot about the case with Qualcomm's failed
| attempt to get code size extensions. Using RVC to
| approach parity on code density is _expensive_ , and
| you're going to make the front-end of the machine more
| complicated. Going out on another limb: this is probably
| not unrelated to the reason why THUMB is missing from
| AArch64.
| IshKebab wrote:
| > verification of a very high-powered RISC-V core that is
| going to be manufactured in high-volume is probably much
| more expensive and time-consuming than the case for an
| ARM design.
|
| Why do you say this?
| eigenform wrote:
| Presumably, when you have a relationship with ARM, you
| have access to things that make it somewhat less painful:
|
| - People who have been working with spec and technology
| for decades
|
| - People who have implemented ARM machines in fancy
| modern CMOS processes
|
| - Stable and well-defined specifications
|
| - Well-understood models, tools, strategies, wisdom
|
| I'm not sure how much of this exists for you in the
| RISC-V space: you're probably spending time and money
| building these things for yourself.
| gardaani wrote:
| > That doesn't mean you can just slap a RISC-V decoder on
| an ARM chip and it will magically work though.
|
| Raspberry Pi RP2350 already ships with ARM and RISC-V
| cores. https://www.raspberrypi.com/products/rp2350/
|
| It seems that the RISC-V cores don't take much space on
| the chip: https://news.ycombinator.com/item?id=41192341
|
| Of course, microcontrollers are a different from mobile
| CPUs, but it's doable.
| MindSpunk wrote:
| That's not really comparable. Raspberry Pi added entirely
| separate RISC-V cores to the chip, they didn't convert an
| ARM core design to run RISC-V instructions.
|
| What is being discussed is taking an ARM design and
| modifying it to run RISC-V, which is not the same thing
| as what Raspberry Pi has done and is not as simple as
| people are implying here.
| ajb wrote:
| Nevertheless, several companies that originally had MIPS
| implementations did exactly this, to implement ARM
| processors.
| The_Colonel wrote:
| > Everyone is switching to Samsung or MediaTek
| processors?
|
| Why not? MediaTek is very competitive these days.
|
| It would certainly perform better than a RISC-V decoder
| slapped onto a core designed for ARM having to run
| emulation for games (which is pretty much the main reason
| why you need a lot of performance on your phones).
|
| Adopting RISC-V is also a risk for the phone producers
| like Samsung. How much of their internal tooling (e.g.
| diagnostics, build pipelines, testing infrastructure) are
| built for ARM? How much will performance suffer, and how
| much will customers care? Why take that risk (in the
| short/medium term) instead of just using their own CPUs
| (they did it in some generations) or use MediaTek (many
| producers have experience with them already)?
|
| Phone producers will be happy to jump to RISC-V over the
| long term given the right incentives, but I seriously
| doubt they will be eager to transition quickly. All
| risks, no benefits.
| mazurnification wrote:
| I am fan of the Jeff Geerling Youtube series in which he
| is trying to make GPU (AMD/Nvidia) run on Raspbery Pi. It
| is not easy - and they have linux kernel source code
| available to modify. Now imagine all Qualcomm clients
| have to do similar stuff with their third party hardware,
| possibly with no access to source code of drivers. Then
| debug and fix for 3y all the bugs that pop up in the
| wild. What a nightmare.
|
| Apple at least have full control on hardware stack
| (Qualcomm do not as they only sells chips to others).
| coder543 wrote:
| Hardware drivers certainly can be annoying, but a
| hobbyist struggling to bring big GPUs' hardware drivers
| to a random platform is not at all indicative of how hard
| it would be for a company with teams of engineers. If
| NVidia wanted their GPUs to work on Raspberry Pi, then it
| would _already be done_. It wouldn't be an issue. But
| NVidia doesn't care, because that's not a real market for
| their GPUs.
|
| Most OEMs don't have much hardware secret sauce besides
| _maybe_ cameras these days. The biggest OEMs probably
| have more hardware secret sauce, but they also should
| have correspondingly more software engineers who know how
| to write hardware drivers.
|
| If Qualcomm moved their processors to RISC-V, then
| Qualcomm would certainly provide RISC-V drivers for their
| GPUs, their cellular modems, their image signal
| processors, etc. There would only be a little work
| required from Qualcomm's clients (the phone OEMs) like
| making sure their fingerprint sensor has a RISC-V driver.
| And again, if Qualcomm were moving... it would be a _sea
| change_. Those fingerprint sensor manufacturers would
| absolutely ensure that they have a RISC-V driver
| available to the OEMs.
|
| But, all of this is very hypothetical.
| wang_li wrote:
| > If NVidia wanted their GPUs to work on Raspberry Pi,
| then it would already be done. It wouldn't be an issue.
| But NVidia doesn't care, because that's not a real market
| for their GPUs.
|
| It's weird af that Geerling ignores nVidia. They have a
| line of ARM based SBCs with GPUs from Maxwell to Ampere.
| They have full software support for OpenGL, CUDA, and
| etc. For the price of an RPi 5 + discreet GPU, you can
| get a Jetson Orin Nano (8 GB RAM, 6 A78 ARM cores, 1024
| Ampere cores.) All in a much better form factor than a Pi
| + PCIe hat and graphics card.
|
| I get the fun of doing projects, but if what you're
| interested in is a working ARM based system with some
| level of GPU, it can be had right now without being "in
| the shop" twice a week with a science fair project.
| derstander wrote:
| > It's weird af that Geerling ignores nVidia.
|
| "With the PCI Express slot ready to go, you need to
| choose a card to go into it. After a few years of testing
| various cards, our little group has settled on Polaris
| generation AMD graphics cards.
|
| Why? Because they're new enough to use the open source
| amdgpu driver in the Linux kernel, and old enough the
| drivers and card details are pretty well known.
|
| We had some success with older cards using the radeon
| driver, but that driver is older and the hardware is a
| bit outdated for any practical use with a Pi.
|
| Nvidia hardware is right out, since outside of community
| nouveau drivers, Nvidia provides little in the way of
| open source code for the parts of their drivers we need
| to fix any quirks with the card on the Pi's PCI Express
| bus."
|
| Reference = https://www.jeffgeerling.com/blog/2024/use-
| external-gpu-on-r...
|
| I'm not in a position to evaluate his statement vs yours,
| but he's clearly thought about it.
| preisschild wrote:
| AFAIK the new SiFive dev board actually supports AMD
| discrete grsphics cards over PCIe
| shash wrote:
| > Virtually all high performance processors these days
| operate on their own internal "instructions". The
| instruction decoder at the very front of the pipeline
| that actually sees ARM or RISC-V or whatever is a
| relatively small piece of logic.
|
| You're talking essentially about microcode; this has been
| the case for decades, and isn't some new development.
| However, as others have pointed out, it's not _as_ simple
| as just swapping out the decoder (especially if you've
| mixed up a lot of decode logic with the rest of the
| pipeline). That said, it's happened before and isn't
| _impossible_.
|
| On a higher level, if you listen to Keller, he'll say
| that the ISA is not as interesting - it's just an
| interface. The more interesting things are the
| architecture, micro-architecture and as you say, the
| microcode.
|
| It's possible to build a core with comparable performance
| - it'll vary a bit here and there, but it's not that much
| more difficult than building an ARM core for that matter.
| But it takes _years_ of development to build an out-of-
| order core (even an in-order takes a few years).
|
| Currently, I'd say that in-order RISC-V cores have
| reached parity. Out of order is a work in progress at
| several companies and labs. But the chicken-and-egg issue
| here is that in-order RISC-V cores have ready-made
| markets (embedded, etc) and out of order ones (mostly
| used only in datacenters, desktop and mobile) are kind of
| locked in for the time being.
|
| > Many Android apps don't depend directly on "native"
| code, and those could potentially work on day 1.
|
| That's actually true, but porting Android is a nightmare
| (not because it's hard, but because the documentation on
| it sucks). Work has started, so let's see.
|
| > With an ARM emulation layer, those with a native
| dependency could likely start working too, although a
| native RISC-V port would improve performance.
|
| I wonder what the percentage here is... Again, I don't
| think recompiling for a new target is necessarily the
| worst problem here.
| cesarb wrote:
| > > Virtually all high performance processors these days
| operate on their own internal "instructions". The
| instruction decoder at the very front of the pipeline
| that actually sees ARM or RISC-V or whatever is a
| relatively small piece of logic.
|
| > You're talking essentially about microcode; this has
| been the case for decades, and isn't some new
| development.
|
| Microcode is much less used nowadays than in the past.
| For instance, several common desktop processors have only
| a single instruction decoder capable of running
| microcode, with the rest of the instruction decoders
| capable only of decoding simpler non-microcode
| instructions. Most instructions on typical programs are
| decoded directly, without going through the microcode.
|
| > However, as others have pointed out, it's not _as_
| simple as just swapping out the decoder
|
| Many details of an ISA extend beyond the instruction
| decoder. For instance, the RISC-V ISA mandates specific
| behavior for its integer division instruction, which has
| to return a specific value on division by zero, unlike
| most other ISAs which trap on division by zero; and the
| NaN-boxing scheme it uses for single-precision floating
| point in double-precision registers can be found AFAIK
| nowhere else. The x86 ISA is infamous for having a
| stronger memory ordering than other common ISAs. Many
| ISAs have a flags register, which can be set by most
| arithmetic (and some non-arithmetic) instructions. And
| that's all for the least-privileged mode; the supervisor
| or hypervisor modes expose many more details which differ
| greatly depending on the ISA.
| shash wrote:
| > Many details of an ISA extend beyond the instruction
| decoder. For instance, the RISC-V ISA mandates specific
| behavior for its integer division instruction, which has
| to return a specific value on division by zero, unlike
| most other ISAs which trap on division by zero; and the
| NaN-boxing scheme it uses for single-precision floating
| point in double-precision registers can be found AFAIK
| nowhere else. The x86 ISA is infamous for having a
| stronger memory ordering than other common ISAs. Many
| ISAs have a flags register, which can be set by most
| arithmetic (and some non-arithmetic) instructions. And
| that's all for the least-privileged mode; the supervisor
| or hypervisor modes expose many more details which differ
| greatly depending on the ISA.
|
| All quite true, and to that, add things like cache hints
| and other hairy bits in an actual processor.
| kernal wrote:
| >Many Android apps don't depend directly on "native"
| code, and those could potentially work on day 1. With an
| ARM emulation layer, those with a native dependency could
| likely start working too, although a native RISC-V port
| would improve performance.
|
| This is only true if the application is written purely in
| Java/Kotlin with no native code. Unfortunately, many apps
| do use native code. Microsoft identified that more than
| 70% of the top 100 apps on Google Play used native code
| at a CppCon talk.
|
| >I think ARM is bluffing here. They need Qualcomm.
|
| Qualcomm's survival is dependent on ARM. Qualcomm's
| entire revenue stream evaporates without ARM IP. They may
| still be able to license their modem IP to OEMs, but not
| if their modem also used ARM IP. It's only a matter of
| time before Qualcomm capitulates and signs a proper
| licensing agreement with ARM. The fact that Qualcomm's
| lawyers didn't do their due diligence to ensure that
| Nuvia's ARM Architecture licenses were transferable is
| negligent on their part.
| hajile wrote:
| ARM already did the hard work. Once you've ported your app
| to ARM, you've no doubt made sure all the ISA-specific bits
| are isolated while the rest is generic and portable. This
| means you already know where to go and what to change and
| hopefully already have testing in place to make sure your
| changes work correctly.
|
| Aside from the philosophy, lots of practical work has been
| done and is ongoing. On the systems level, there has
| already been massive ongoing work. Alibaba for example
| ported the entirety of Android to RISC-V then handed it off
| to Google. Lots of other big companies have tons of coders
| working on porting all kinds of libraries to RISC-V and
| progress has been quite rapid.
|
| And of course, it is worth pointing out that an
| overwhelming majority of day-to-day software is written in
| managed languages on runtimes that have already been ported
| to RISC-V.
| NavinF wrote:
| Interesting, does anyone know what percentage of top
| Android apps run on RISC-V? I'd expect a lot of apps like
| games to only have binaries for ARM
| Pet_Ant wrote:
| Aren't Android binaries in Dalvik so you only need to
| port that to get it to run on RISC-V?
| NavinF wrote:
| https://developer.android.com/ndk
| snvzz wrote:
| Aren't most applications NOT using the ndk?
| monocasa wrote:
| NDK usage is pretty high among applications that actually
| matter.
| saagarjha wrote:
| Most major apps use the NDK.
| pjmlp wrote:
| Everyone that doesn't want to write Java/Kotlin is using
| the NDK.
|
| Although from Google's point of view the NDK only purpose
| is for enabling writing native methods, reuse of C and
| C++ libraries, games and real time audio, from point of
| view of others, it is how they sneak Cordova, React
| Native, Flutter, Xamarin,.... into Android.
| canucker2016 wrote:
| Many games, multimedia apps (native FFMPEG libs), and
| other apps that require native C/C++ libs would require a
| recompile/translation for RISC-V.
| shash wrote:
| FFMPEG has a RISC-V port. We're yet to try it, but I did
| successfully compile it to target RISC-V vector
| extensions.
| ThatPlayer wrote:
| Not Android, but Box86 already works on RISC-V, even
| already running games on top of Wine and DXVK:
| https://youtu.be/qHLKB39xVkw
|
| It redirects calls to x86 libraries to native RISC-V
| versions of the library.
| anthk wrote:
| Most FLOSS libraries are already ported over thanks to
| GNU/Linux.
| KRAKRISMOTT wrote:
| The thing about RISC-V is that they indirectly have the
| R&D coffers of the Chinese government backing them for
| strategic reasons. They are the hardware equivalent of
| Uber's scale-first-make-money later strategy. This is not
| a competition that ARM can win purely relying on their
| existing market dominance.
| andyferris wrote:
| Keep in mind, Apple _did_ actually take a good decade from
| starting with ARM to leaving x86.
| fhdsgbbcaA wrote:
| With 100% control of the stack and an insanely good
| emulator in Rosetta.
| speed_spread wrote:
| Qualcomm's migration would be much easier than Apple's.
|
| Most of the Android ecosystem already runs on a VM,
| Dalvik or whatever it's called now. I'm sure Android
| RISC-V already runs somewhere and I don't see why it
| would run any worse than on ARM as long as CPUs have
| equal horsepower.
| saagarjha wrote:
| NDK exists.
| darksaints wrote:
| The companies with large relevant apps running on the NDK
| are well staffed and funded enough to recompile.
| immibis wrote:
| it's not about that, it's about running the apps whose
| makers are out of business or just find it easier to tell
| their customers to buy different phones
| saagarjha wrote:
| It's not about whether they can, it's whether they will.
| History has proven that well-resourced teams don't like
| doing this very much and will drag their feet if given
| the chance.
| toasterlovin wrote:
| Yeah, but Qualcomm doesn't control Android or any of the
| phone makers. It's hard for large corps to achieve the
| internal coordination necessary for a successful ISA
| change (something literally only Apple has ever
| accomplished), but trying to coordinate with multiple
| other large corps? Seems insane. You're betting your
| future on the fact that none of the careerists at Google
| or Samsung get cold feet and decide to just stick with
| what works.
| rangestransform wrote:
| Wouldn't coordination to change ISA between multiple
| companies receive heavy scrutiny in the Lina Khan era?
| godzillabrennus wrote:
| Is the transition fully over if the latest MacOS still
| runs an x86 emulator for old software?
| phkahler wrote:
| >> 1. Qualcomm develops a chip that competitive in
| performance to ARM
|
| Done. Qualcomm is currently gunning for Intel.
|
| 2. The entire software world is ready to recompile
| everything for RISC-V
|
| Android phones use a virtual machine which is largely
| ported already. Linux software is largely already ported.
| djbusby wrote:
| And with VM tech, and the power of modern devices even
| some emulator/thunking layer is not too crazy for apps
| that (somehow) couldn't cross compile.
| IshKebab wrote:
| 2. Except games...
|
| But ARM and RISC-V are relatively similar and it's easy
| to add custom instructions to RISC-V to make them even
| more similar if you want so you could definitely do
| something like Rosetta.
| fhdsgbbcaA wrote:
| I think windows-on-arm is fairly instructive as to how
| likely RISC-V would go.
| philistine wrote:
| That's what's magical about Apple. It was a decade-long
| transition. All the 32-bit code that was removed from macOS
| back in 2017 was all in preparation for the move in 2019.
| MBCook wrote:
| Apple has done it multiple times now and has it down to a
| science.
|
| 68k -> PPC -> x86 -> ARM, with the 64 bit transition you
| mixed in there for good measure (twice!).
|
| Has any other consumer company pulled a full architecture
| switch off? Companies pulled off leaving Alpha and Sparc
| but that was servers which has a different software
| landscape.
| hajile wrote:
| I don't believe any major company has done it. Even Intel
| failed numerous times to move away from x86 with iAPX432,
| i960, i860, and Itanium all failing to gain traction.
| MBCook wrote:
| For Apple it was do or die the first few times. Until
| x86, if they didn't move they'd just be left in the dust
| and their market would disappear.
|
| The ARM transition wasn't strictly necessary like the
| last ones. It had huge benefits for them, so it makes
| sense, but they also knew what they were doing by then.
|
| In your examples (which are great) Intel wasn't going to
| die. They had backups, and many of those seem guided more
| by business goals than a do-or-die situation.
|
| I wonder if that's part of why they failed.
| hnaccount_rng wrote:
| In a way that's also true for the x86->ARM transition,
| isn't it? I had an MacbookAir 2018. And.. "it was crap"
| is putting it very, very mildly. Yes it was still better
| than any Windows laptop I got since and much less of a
| hassle than any Linux laptop that I'm aware of in my
| circle. But the gap was really, really small and it cost
| twice as much.
|
| But the most important part for the working of the
| transition is probably that, in any of theses cases, the
| typical final user didn't even notice. Yes a lot of
| Hackernews-like people noticed as they had to recompile
| some of their programs. But most people :tm: didn't. They
| either use AppStore apps, which were fixed ~immediately
| or Rosetta made everything runnable, even if performance
| suffered.
|
| But that's pretty much the requirement you have: You need
| to be handle to transition ~all users to the new platform
| with ~no user work and even without most vendors doing
| anything. Intel never could provide that, not even aim
| for it. So they basically have to either a) rip their
| market in pieces or b) support the "deprecated" ISA
| forever.
| plorkyeran wrote:
| > Rosetta made everything runnable, even if performance
| suffered.
|
| I think a very important part was that even with the
| Rosetta overhead, most x86 programs were faster on the m1
| than on the machines which it would have been replacing.
| It wasn't just that you could continue using your
| existing software with a perf hit; your new laptop
| actually felt like a meaningful upgrade even before any
| of your third party software got updated.
| MBCook wrote:
| I don't think so. I've got a 2019 MBP and yeah, the heat
| issue is a big problem.
|
| But they weren't going to be left in the performance dust
| like the last times. Their chip supplier wasn't going to
| stop selling chips to them.
|
| They would have likely had to give up on how thin their
| laptops were, but they could have continued on just fine.
|
| I do think the ARM transition wasn't strictly good, it
| let them stay thin and quiet and cooler. They got
| economies of scale with their phone chips.
|
| But it wasn't necessary to the degree the previous ones
| were.
| MBCook wrote:
| > I do think the ARM transition wasn't strictly good
|
| That's a total typo I didn't catch in time. I'm not sure
| what I tried to type, but I thought the transition was
| good. They didn't have to but I'm glad they did.
| ajb wrote:
| IBM also did it, with mainframes. But otherwise, no.
| shash wrote:
| In a sense, Freescale/NXP did it from their old PowerPC
| to ARM.
| SoftTalker wrote:
| MacOS (as NeXTSTEP and/or OpenStep) also ran on SPARC and
| PA-RISC I believe.
| slashdave wrote:
| OpenStep was developed on SunOS, and was the primary GUI
| out of the box
| slashdave wrote:
| > Companies pulled off leaving Alpha and Sparc
|
| Considering the commercial failure of these efforts, I
| might disagree
| snvzz wrote:
| >2. The entire software world is ready to recompile
| everything for RISC-V
|
| This would suggest that RISC-V is starting from scratch.
|
| Yet in reality it is well underway; RISC-V is rapidly
| growing the strongest ecosystem.
| saagarjha wrote:
| > Qualcomm develops a chip that competitive in performance
| to ARM
|
| That's what Oryon is, in theory.
| Brian_K_White wrote:
| Switches like that are major, but get easier every year,
| and are easier today than they were yesterday, as everyones
| tools at all levels up and down both the hardware and
| software stacks get more powerful all the time.
|
| It's an investment with a cost and a payoff like any other
| investment.
| detourdog wrote:
| I think it takes Apple at least 9 years to prepare and 1
| year to implement.
| a-dub wrote:
| is risc-v anywhere near the same efficiency ballpark?
| monocasa wrote:
| RISC-V is very competitive with ARM when comparing similar
| PPA niches.
| msh wrote:
| High performance and low power laptop and phone SoC's, no
| way. There exists no competitive risc-v chip.
| wmf wrote:
| We're all assuming that Oryon-V is already being
| developed.
| Mindwipe wrote:
| "Developed" and "successfully shipped" are two enormously
| different things.
| starspangled wrote:
| Just the impact of making this move will have a chilling
| effect, regardless of the long term outome.
|
| ARM Ltd wants to position itself as _the_ ISA. It is highly
| proprietary of course, but the impression they want to give
| is that it is "open" and freely available, no lock-in, etc.
|
| This really brings the reality back into focus that ARM
| controls it with an iron fist, and they're not above playing
| political games and siding against you if you annoy their
| favored customers. Really horrible optics for them.
| t43562 wrote:
| Qualcomm is slightly bigger than ARM so it seems like a
| fair fight to me. Does Qualcomm police it's IP at all?
| starspangled wrote:
| > Qualcomm is slightly bigger than ARM so it seems like a
| fair fight to me.
|
| I'm not really sure what you're responding to. It's got
| nothing to do with size whether or not something is fair,
| it's what is in the contract. None of us know exactly
| what's there so if it becomes disputed then a court is
| going to have to decide what is fair.
|
| But that was entirely not the point of my comment though.
| I'm talking about how corporations looking to make chips
| or get into the ecosystem view ARM and its behavior with
| its architecture and licensing. ARM Ltd might well be in
| the right here by the letter of their contracts, but that
| canceling their customer's license (ostensibly if not
| actually siding with another customer who is in
| competition with the first) is just not a good look for
| positioning they are going for.
| t43562 wrote:
| You might be right, but they do perhaps also have to
| establish that their contracts are going to be
| defended/enforced. Otherwise they have nothing.
| michaelt wrote:
| According to Wikipedia,
|
| Qualcomm has 50,000 employees, $51 billion assets and $35
| billion revenue https://en.wikipedia.org/wiki/Qualcomm
|
| ARM Holdings has 7000 employees, $8 billion assets and $3
| billion revenue
| https://en.wikipedia.org/wiki/Arm_Holdings
|
| I think "slightly bigger" is an understatement.
| cduzz wrote:
| That's roughly the same size -- like swamp thing vs namor
| -- both are name brand, almost blue chip heros.
|
| Or put another way -- as they said in gawker[1] -- if
| you're in a lawsuit with a billionaire you better have a
| billionaire on your side or you're losing.
|
| In this case -- it's unlikely that qualcomm will have
| quite enough juice to just smoosh Arm, in the same way
| that they _would_ be able to just smoosh a company that
| 's 100th the size of arm (not just 1/10th), regardless of
| the merits of the case.
|
| [1]https://gawker.com/how-things-work-1785604699
| CamperBob2 wrote:
| _Does Qualcomm police it 's IP at all?_
|
| Traditionally they've been known as a tech company that
| employs more lawyers than engineers, if that tells you
| anything.
|
| I'd probably go up against IBM or Oracle before I tugged
| on Qualcomm's cape. Good luck to ARM, they'll need it.
| hajile wrote:
| Oracle v Qualcomm would be epic.
| aleph_minus_one wrote:
| The public will likely be the loser of such a battle. :-(
| Nemo_bis wrote:
| Not if they end up cancelling each other's patents. :)
| verditelabs wrote:
| I am an ex Qualcomm employee. We often called ourselves a
| law firm with a tech problem. QC doesn't actually have
| more lawyers than engineers, but I'd not be surprised if
| the legal department got paid more than all the engineers
| combined.
| markhahn wrote:
| "Chilling effect" implies that we should want ARM to
| succeed.
|
| IMO we need to question the premises of the current IP
| ecosystem. Obviously, the principles of open-source are
| quite the opposite to how ARM licenses IP. (Afaik, ARM also
| licenses ready-to-go cores, which is very different from
| what Q is getting.)
|
| It's easy to see how RISC-V avoids the conflict of interest
| between owning the ISA and licensing specific
| implementations.
| starspangled wrote:
| > "Chilling effect" implies that we should want ARM to
| succeed.
|
| It really doesn't.
|
| I agree an actual open ISA is far preferable, ARM is not
| much different than x86.
| h_tbob wrote:
| I don't understand how they can copyright just the ISA.
| Didn't a recent Supreme Court case in oracle v google Java
| issue decide that you can copy the api if you impelement it
| differently? So what exactl is arm pulling? Implementation
| hardware specs? I suspect Qualcomm can do that on its own
| TheFlyingFish wrote:
| I think it might actually be patents rather than
| copyright restrictions that are in play here.
| gonzo wrote:
| > Qualcomm is almost certainly ARM's biggest customer.
|
| You think Qualcomm is larger than Apple?
| javawizard wrote:
| Apple has (to a first approximation) a royalty-free license
| to ARM IP by virtue of the fact that they co-founded ARM -
| so yes, Qualcomm is most likely paying ARM more than Apple
| is.
| happymellon wrote:
| Just to clarify for those that don't know ARMs history,
| Acorn were building computers and designing CPUs before
| they spun out the CPU design portion.
|
| Apple did not help them design the CPU/Architecture, that
| was a decade of design and manufacturing already, they
| VC'ed the independence of the CPU. The staffing and
| knowledge came from Acorn.
| billti wrote:
| > Apple did not help them design the CPU/Architecture
|
| I believe they had a big hand in ARM64. Though best
| reference I can find right now is this very site:
| https://news.ycombinator.com/item?id=31368489
| happymellon wrote:
| Oh, I was just wanting to clarify the "Apple co-founded".
|
| They had the Newton project, found ARM did a better job
| than the other options, but there were a few missing
| pieces. They funded the spun out project so they could
| throw ARM a few new requirements for the CPU design.
|
| As a "cofounder" of ARM, they didn't contribute technical
| experience and the architecture did already exist.
| steeeeeve wrote:
| Sigh. Newton. So far ahead of it's time.
| hajile wrote:
| Absolutely.
|
| There are nearly 2B smartphones sold each year and only
| 200M laptops, so Apple's 20M laptop sales are basically a
| rounding error and not worth considering.
|
| As 15-16% of the smartphone market, Apple is generally
| selling around 300m phones. I've read that Qualcomm is
| usually around 25-35% of the smartphone market which would
| be 500-700M phones.
|
| But Qualcomm almost certainly includes ARM processors in
| their modems which bumps up those numbers dramatically.
| Qualcomm also sells ARM chips in the MCU/DSP markets IIRC.
| zjjsij wrote:
| Qualcomm's modems aren't ARM processors, they're Hexagon.
|
| https://en.wikipedia.org/wiki/Qualcomm_Hexagon
| yalogin wrote:
| Moving to a whole new architecture is really really hard, no?
| The operating systems and applications all need to be ported.
| Just because Qualcomm cannot be friends with arm, every
| single Qualcomm customer from google to some custom device
| manufacturer needs to invest years and millions to move to a
| new architecture? Unless I am fundamentally misunderstanding
| this, it seems like something they won't be able to achieve.
| dvdkon wrote:
| Android already supports RISC-V, so while migrating an SOC
| to it is not painless (third-party binaries, device-
| specific drivers...), the hard work of porting the
| operating system itself to the ISA is done.
| f1shy wrote:
| >>Qualcomm moves to RISC-V and ARM
|
| That is a HUGE cost!
| m463 wrote:
| > Qualcomm doesn't have nearly as much to lose as ARM does
| and they know it.
|
| question: isn't arm somewhat apple?
|
| _...Advanced RISC Machines Limited and structured as a joint
| venture between Acorn Computers, Apple, and VLSI Technology._
|
| https://en.wikipedia.org/wiki/Arm_Holdings#Founding
| objclxt wrote:
| > question: isn't arm somewhat apple?
|
| Not for decades. Apple sold its stake in ARM when Steve
| Jobs came back, they needed the money to keep the company
| going.
| biosboiii wrote:
| Thing is businesses don't work like side-projects do.
|
| Qualcomm is more or less a research company, the main cost of
| their business is paying engineers to build their
| modems/SoCs/processors/whatever.
|
| They have been working with ARM for the last, I dont know, 20
| years? Even if they manage to switch to RISC-V, and each
| employee has negative performance impact of like 15% for 2-3
| years this ends up in billions of dollars, because you have
| to hire more people or lose speed.
|
| If corporate would force me to work with idk Golang instead
| of TypeScript I could certainly manage to do so, but I would
| be slower for a while, and if you extrapolate that on an
| entire company this is big $$.
| nottorp wrote:
| > because you have to hire more people or lose speed
|
| Yes and 9 women can make a baby in 1 month :)
| asgeir wrote:
| In Norse mythology, Heimdallr was born of nine sisters.
| I'm not sure that it took any less time than usual, but I
| enjoy the story all the same.
| https://en.wikipedia.org/wiki/Nine_Mothers_of_Heimdallr
| type0 wrote:
| and Norse mythology has 9 world dimensions, so maybe it
| worked for them
| vollbrecht wrote:
| It's called pipelining, and the concept works well in all
| modern processors. Can also work with people, you only
| have a initial setup delay :)
| tsunamifury wrote:
| No but 9 women can have 9 babies in 9 months.
|
| Which is a 9x output.
|
| Production and development requires multiple parties.
| This mythical man month stuff is often poorly applied.
| Many parts of research and development need to be done in
| parallel.
| dzaima wrote:
| Just take a guess at how the baby will be like and get
| everyone to pretend it already exists for the 8 months
| (and throw away the experience if mispredicted
| afterwards) :)
| nasretdinov wrote:
| > If corporate would force me to work with idk Golang
| instead of TypeScript
|
| I think the most evil thing to do would be to switch
| places: TS for backend, Go for frontend. It can certainly
| work though!
| jkaplowitz wrote:
| Building a website that way would yield quite a popular
| Show HN post!
| worewood wrote:
| TS running under Node.js for the backend, I'd dare say,
| looks pretty standard.
|
| But I like to imagine the Web frontend made in Go,
| compiled to WASM. Would be a fun project, for sure.
| ahoka wrote:
| Try Java 1.8.
| mytailorisrich wrote:
| On modem side they can move to whatever they want without
| impacts. But on the apps side they need to run
| Linux/Android/Windows/etc so are dependent on Arm.
| tails4e wrote:
| The transition to RISC-V depends entirely on how much of the
| cpu core susbstem is from ARM. The ISA itself is one part,
| there are branch predictors, l1,l2 and 3 caches, MMUs,
| virtualization, vector extensions, the pipeline architecture,
| etc etc. So moving away from ARM means they need performant
| replacements for all that.
|
| I'm sure there are folks like SiFive that have much of this,
| but how is it competitively I don't know, and how the next
| snapdragon would compete if even one of those areas is
| lacking... Interesting times.
| torginus wrote:
| This is a bit off topic, but has anyone demonstrated it's
| possible to design a big RISC-V core, that's performance
| competitive with the fastest x86 and ARM designs?
| shash wrote:
| Well, Tenstorrent, Andes and others have their respective
| designs...
|
| On the in-order side, I can see on-par performance with the
| ARM A5x series quite easily.
| torginus wrote:
| After a bit of digging, I found that the SiFive P670 has
| performance equivalent to the Galaxy S21, or the desktop
| Ryzen 7 2700, which is not too bad and definitely usable
| in a smartphone/laptop form, so competitive with the 2021
| era designs. Definitely usable. It's not clear what's the
| power level is.
| shash wrote:
| The P670 is a core, not a chip, so you can't really get
| to power numbers (or indeed, raw performance as opposed
| to performance / watt or performance / GHz) without
| actually making a practical chip out of it in some given
| process node. You're better off comparing it to a core,
| such as the ARM Cortex series, rather than the S21.
|
| SiFive claims a SPECint2006 score of > 12/GHz, meaning
| that it'll get a performance of about 24 at 2 GHz or ~31
| at 2.6 GHz, making it on par with an A76 in terms of raw
| performance.
| tsunamifury wrote:
| Qualcomm's business strategy has become hold everyone at gun
| point then act surprised when everyone looks for alternative
| customers/partners/suppliers.
| Const-me wrote:
| > If ARM wins, Qualcomm moves to RISC-V
|
| Around 30-40% of Android apps published on play store include
| native binaries. Such apps need to be recompiled for RISC-V
| otherwise they won't run. Neither Qualcomm nor Google can do
| that because they don't have source codes for these apps.
|
| It's technically possible to emulate ARMv8 on top of RISC-V,
| however doing so while keeping the performance overhead
| reasonable is going to be insanely expensive in R&D costs.
| B1FF_PSUVM wrote:
| Binary-only translators exist, for instance Apple has
| https://en.wikipedia.org/wiki/Rosetta_(software)
| Const-me wrote:
| Apple gross revenue is 10x the Qualcomm, and the
| difference in net income is even larger. Apple could
| easily afford these R&D costs.
|
| Another obstacle, even if Qualcomm develops an awesome
| emulator / JIT compiler / translation layer, I'm not sure
| the company is in the position to ship that thing to
| market. Unlike Apple, Qualcomm doesn't own the OS. Such
| emulator would require extensive support in the Android
| OS. I'm not sure Google will be happy supporting huge
| piece of complicated third-party software as a part of
| their OS.
|
| P.S. And also there're phone vendors who actually buy
| chips from Qualcomm. They don't want end users to
| complain that their favorite "The Legendary Cabbage:
| Ultimate Loot Garden Saga" is lagging on their phone,
| while working great on a similar ARM-based Samsung.
| kernal wrote:
| >Qualcomm doesn't have nearly as much to lose as ARM does and
| they know it.
|
| Not even close. Android OEM's can easily switch to the
| MediaTek 9400 that delivers the same performance as the
| Qualcomm high-end mobile chip at a significantly reduced
| price or even the Samsung Exynos. Qualcomm, on the other
| hand, has everything to lose as most of their profits rely on
| the sales of high-end Snapdragon chips to Android OEM's.
|
| Qualcomm thought they were smart by trying to use the Nuvia
| ARM design license, which was not transferable, as part of
| their acquisition instead of doing the proper thing and
| negotiating a design license with ARM. Qualcomm is at the
| mercy of ARM as ARM has very many revenue streams and
| Qualcomm does not. It's only a matter of time before Qualcomm
| capitulates and does the right thing.
| jjtheblunt wrote:
| > Qualcomm is almost certainly ARM's biggest customer
|
| what about Apple?
| shmerl wrote:
| Not just telecom, they are just super aggressive in general as
| a bully with weapons pile. I remember they tried to threaten
| Opus codec with patents just becasue, when IETF proposed it for
| Internet standard. Luckily that failed, but it shows their
| nasty approach very clearly. So now they are getting the taste
| of their own medicine.
| chris_wot wrote:
| When do Qualcomm's patents run out?
| electronbeam wrote:
| Qualcomm should put a giant bid on SiFive tomorrow, to remind
| ARM that its not unassailable
| NewJazz wrote:
| They can design chips. What Qualcomm might not be able to do
| is deliver solid software support for their riscv64 hardware.
| Android decelerated their efforts toward support recently.
| kernal wrote:
| So a business that is entirely dependent on ARM IP and, for
| the most part, Android should "remind" the company they're
| dependent upon? Let's do a thought experiment - Qualcomm
| switches to RISC-V while the other Android SoC makers
| (MediaTek, Samsung, Google, Xiaomi, etc.) stay on ARM. Who
| buys the new Snapdragon RISC-V phone?
| hajile wrote:
| Intel supposedly put in a multi-billion dollar offer and got
| laughed out of the room.
| zoobab wrote:
| Qualcomm is a patent troll.
|
| No empathy for those trolls.
| delfinom wrote:
| >Yes, longterm Q might invest in their own RISC implementations
|
| Q is investing over $1billion into RISC-V.
|
| ARM is fucked long term. Sure Qualcomm themselves are no angel.
| But the absurdities of this case are basically making ARM toxic
| to any serious long term investment. Especially when ARM is in
| Apple's pocket and ARM isn't releasing any chip designs
| competitive with Apple's chips where they get free reign to do
| as they want. Basically a permanent handicap on ARM chip
| performance.
| kernal wrote:
| Since I don't see the Android or IOS app stores ever
| switching to RISC-V I think ARM will be fine.
| Tostino wrote:
| Why would you think that? The Play store already supports
| x86 binaries when necessary.
| fidotron wrote:
| The Qualcomm online defenders are something else too.
|
| Qualcomm have been acting badly for years, including attempting
| to turn RISC-V into Arm64 but without the restrictions. You
| cannot trust people that behave like this, where everything
| they do is important and everything you do is worthless.
|
| The funny thing is Qualcomm do have some wildly impressive tech
| which is kept secret despite being so ubiquitous, but they have
| had persistent execution failures at integrations which lead to
| them throwing their partners under the bus.
|
| Qualcomm have the same sort of corporate difficulty you see at
| Boeing, only in a less high profile sector.
| eqvinox wrote:
| > attempting to turn RISC-V into Arm64 but without the
| restrictions
|
| This flew past me, do you have a link?
| fidotron wrote:
| Brucehoult mentions it further down.
|
| > This time last year they were all over the RISC-V mailing
| lists, trying to convince everyone to drop the "C"
| extension from RVA23 because (basically confirmed by their
| employees) it was not easy to retrofit mildly variable
| length RISC-V instructions (2 bytes and 4 bytes) to the
| Aarch64 core they acquired from Nuvia. At the same time,
| Qualcomm proposed a new RISC-V extension that was pretty
| much ARMv8-lite.
|
| This is enough of a philosophy change to break existing
| RISC-V software, and so is purely motivated by a desire to
| clone IP they supposedly licensed as honest brokers.
| rangestransform wrote:
| Not a cpu designer, but aren't variable length
| instructions a big part of why x86 decoders take up so
| much area, and also increases branch predictor
| complexity?
| wbl wrote:
| So much is relative: on a giant OoO core it's barely
| noticeable. In the case of x86 the range of lengths is
| extreme: a simple two or four choice is much simpler.
| GeekyBear wrote:
| > throwing their partners under the bus
|
| I found it telling that every single smartphone vendor
| refused to license Qualcomm's proprietary tech for smartphone
| to satellite messaging.
|
| > In a statement given to CNBC, Qualcomm says smartphone
| makers "indicated a preference towards standards-based
| solutions" for satellite-to-phone connectivity
|
| https://arstechnica.com/gadgets/2023/11/qualcomm-kills-
| its-c...
| xg15 wrote:
| "We're disinclined to acquiesce to your request.
|
| Means 'no'."
| throwup238 wrote:
| Anyone only ever uses Qualcomm chips because they have a
| gun to their head.
|
| Usually that gun is the latest wireless standard like 4g or
| 5g.
| GeekyBear wrote:
| 4g and 5g are open standards.
|
| It was their now mostly irrelevant CDMA patents that
| Qualcomm used as a weapon against device makers.
|
| > Many carriers (such as AT&T, UScellular and Verizon)
| shut down 3G CDMA-based networks in 2022 and 2024,
| rendering handsets supporting only those protocols
| unusable for calls, even to 911.
|
| https://en.m.wikipedia.org/wiki/Code-
| division_multiple_acces...
|
| In my opinion, Qualcomm's abuse of their CDMA patents is
| the reason that zero device makers were willing to get on
| board with a new Qualcomm proprietary technology.
| Kirby64 wrote:
| They're open standards, sure, but there is almost no
| competition in the cellular modem space. Intel tried and
| failed spectacularly. Apple bought the scraps of the
| Intel modem business and still hasn't released their own
| modems after... 5 years? Cellular tech is hard and has a
| lot of esoteric requirements. If you want a cell modem
| for a smartphone, you essentially buy either the latest
| and greatest from Qualcomm or you buy something from one
| of the Chinese companies (Huawei, Mediatek) which has its
| own set of problems.
| GeekyBear wrote:
| Samsung, Huawei and MediaTek SOCs implement the same open
| 4g/5g standards.
|
| Apple's modem is said to be shipping this coming spring
| in the newest iPhone SE iteration.
|
| Google's Pixel phone lineup has used Samsung's modems for
| generations now.
| Kirby64 wrote:
| There's so many sub varieties of the standards. You're
| making a gross oversimplification that they're "the
| same". Compare intel vs Qualcomm modems that were
| released on iPhones. They were "the same" standard but
| the Qualcomm modems were notably faster in testing. Maybe
| they're all at parity these days, but it's pretty hard to
| do a fair comparison.
| SG- wrote:
| I guess they'll have to give ARM all that money they got from
| Apple over their modem dispute.
| fargle wrote:
| > If Arm follows through with the license termination, Qualcomm
| would be prevented from doing its own designs using Arm's
| instruction set
|
| i'm not sure this is true. certainly "chip" IP has been a real
| legal quagmire since, forever.
|
| but it was my understanding that you could neither patent nor
| copyright simply an "instruction set".
|
| presumably what you get from ARM with an architecture license
| would be patent licenses and the trademark. if so, what patents
| might be relevant or would be a problem if you were to make an
| "ARMv8-ish compatible" ISA/Architecture with a boring name? i
| haven't seen much about ARM that's _architecturally_ particularly
| unique or new, even if specific implementation details may be
| patent-able. you could always implement those differently to the
| same spec.
|
| to further poke at the issue, if it's patents, then how does a
| RISC-V CPU or other ISA help you? simply because it's a different
| ISA, doesn't mean its implementation doesn't trample on some ARM
| patents either.
|
| if it's something to do with the ISA itself, how does that affect
| emulators?
|
| what's ARM's IP really consist of when you build your own non-ARM
| IP CPU from scratch? anyone have examples of show-stopper
| patents?
| wmf wrote:
| You can patent something like "any possible hardware circuit
| that implements [the functionality of some weird yet mandatory
| ARM instruction]". The patent doesn't cover emulators because
| they're not hardware.
|
| Way back in the day there were some MIPS patents that only
| covered a few instructions so people would build not-quite-MIPS
| clone CPUs without paying any royalties.
| fargle wrote:
| thanks for the hint. i found https://www.probell.com/lexra/
|
| sheesh, patent
| https://patents.google.com/patent/US4814976A/en is a real
| "gem"
|
| but its probably a good example: faulty patent (later
| invalidated) to do something obvious
|
| MIPS sues a company that _doesn 't even implement_ the odd
| instructions because it traps them, allowing a _possibility_
| of emulation.
|
| _there 's literally no case here_
|
| just to sue them into oblivion and squish them with superior
| cash resources. and then to get squished by ARM because they
| weren't paying attention.
|
| it's like a dark fairy tale. i hate corporate lawyers.
| f1shy wrote:
| That is what was done with the THUMB instructions. IIRC
| prmoustache wrote:
| Are there remaining patents relative to arm architecture that
| haven't expired already?
| f1shy wrote:
| For ARM7TDMI probably no, but for the A, R and M cores, for
| sure there is. That is the name of the game.
| ddingus wrote:
| Damn!
|
| So what happens to the Raspberry Pi?
|
| Edit: OK, following the discussion now. Nothing in the short
| term, potentially longer term.
| lights0123 wrote:
| The Raspberry Pi uses Broadcom, not Qualcomm chips. It also
| uses cores designed by Arm, which are not affected by today's
| news.
| Crosseye_Jack wrote:
| Broadcom (The makers of the chips used on the pi) did have a
| bid to acquire Qualcomm back in 2017 [0] but the bid was
| withdrawn after Trump blocked the deal.
|
| So nothing will happen to the Pi (Arm also has a a minority
| stake in Raspberry Pi)
|
| [0] https://investors.broadcom.com/news-releases/news-release-
| de...
| sn0n wrote:
| What does all this have to do with Intel and AMD calling a truce?
| jocaal wrote:
| Since Qualcomm is using these custom cores to launch into the
| pc market and directly competing with x86
| mschuster91 wrote:
| Not much I'd say. Intel has its own _massive_ yield / fab
| issues to deal with, and AMD's GPU business is being eaten by
| NVIDIA while its CPU business never had much market share to
| begin with... it doesn't make sense for these two to fight each
| other, not when NVIDIA is knocking on both their doors.
| Night_Thastus wrote:
| AMD and Intel aren't 'calling a truce'. They've _always_ worked
| together on projects where the industry would benefit from
| standardization and having many experienced people put their 2c
| in. They still compete on products, just not standards - which
| is a good thing.
| szundi wrote:
| On mobile devices efficiency is so important, I don't see how
| Qualcomm would be able to live without ARM licences. RISC-V and
| other architectures like x86-64 are nice, actually I think the
| peripheral libraries, boot and stuff like that are bigger
| headache to replace for Qualcomm's clients given that they can
| just switch the gcc to a different arch - still if your code is
| 25% less efficient, that'll be quite noticable for the consumer -
| or in your battery and weight costs.
|
| What am I not seeing here? I think they'll just settle.
| notpushkin wrote:
| You're assuming there is something inherent to Arm specifically
| that makes it efficient. I'm not sure about that: it just
| evolved naturally as it was used in portable devices
| predominantly. Same thing can be done with RISC-V-based
| designs, but obviously it will take a lot of time.
| SushiHippie wrote:
| Because of all the discussions in the comments about ARM and
| RISC-V, could someone explain to me the difficulties of designing
| a chip for a new ISA?
|
| I'm wondering because to me as a layman it sounds like it's
| 'only' a different language, so why is it not that easy to take
| already existing designs and modify them to 'speak' that language
| and that's it?
|
| Or is an ISA more than just a different 'language'?
|
| Or is hardware not really the biggest problem, but rather
| Software like compilers, kernels, etc.?
| creshal wrote:
| > Or is an ISA more than just a different 'language'?
|
| It tends to be more like going from C89 to Haskell. You're not
| just switching the keywords around, but also fundamental
| architectural concepts. There's still some parts you can
| recycle and some skills that transfer, but less than you'd
| like.
|
| > Or is hardware not really the biggest problem, but rather
| Software like compilers, kernels, etc.?
|
| That's the next problem. Kernels, device drivers, support
| hardware, a lot of low level stuff needs to be adapted, and
| even a company the size of Qualcomm doesn't necessarily do
| everything inhouse, there will be lots of external IPs involved
| and all those partners need to also be willing to migrate over
| to a different ISA.
| dzaima wrote:
| I'd perhaps put ARM vs RISC-V closer to like C# vs Java (or
| maybe JS vs Python) - on a high level rather similar, but a
| majority of the specifics don't really line up (especially at
| the uop level requiring dumping a bunch of previous optimized
| cases, and adding a bunch of new ones).
| t43562 wrote:
| Your view even of human languages is simplistic. Forgive me, I
| don't mean to be rude, I'm just trying to explain.
|
| You might think that languages are just have different words
| for the same things.
|
| In reality the problems are where the same things don't exist.
| People don't view the world the same way and don't have an
| equivalent word. In Turkish it's very important whether your
| aunt is on your mother's side or your father's side so there
| are different words for each....but there's no words for "he"
| or "she" as they don't bother with gender in sentences.
|
| So for example every conversation converted from Turkish to
| English loses an important bit of meaning about relationships
| and the sex of a person has to be inferred from context which
| is not easy to do automatically.
|
| Similarly computer software....and there's a lot of it.
| numpad0 wrote:
| It's interesting that many with CS/CE background believes in
| irreversible death of Sapir-Whorf hypothesis and victory of
| the Universal Grammar Theory, while many from the exact same
| cohort are able to trivially explain how tightly coupled ISA
| and CPU implementation are and how mutually incompatible
| different ISAs can be.
|
| I mean, it's most likely overlaps and not actually the same
| set of people, but I find it ironic and funny.
| t43562 wrote:
| I suspect that it's an argument about nothing. e.g. I can
| think about my "mother's sister" but I don't care about it
| enough to invent a shortcut word for it like "teyze". To
| Turks I think it means something because in some families
| there's great emphasis on the connections with one or other
| side of the family. It's rather a brutal and dismissive
| attitude sometimes.
|
| So I personally think that groups of people have a common
| understanding and some commonly accepted attitude that make
| up their culture. The purpose of words is to reference
| those feelings. An outsider can understand to a degree
| because we are all human but they usually get the emphasis
| wrong and also tend to miss lots of implications.
|
| Of course you as an entrant to a culture (e.g. a kid) are
| going to get educated over time about what it all means and
| you're going to be discouraged from expressing alternate
| cultural values because overall not enough people feel like
| that to have invented convenient ways of expressing it.
|
| So language is going to affect you but as some idea becomes
| popular and needs expression people do invent new words. So
| you can affect it - if you can get enough people to pick up
| on your invention by adding a new idea to their mental
| model of life.
| adrian_b wrote:
| Designing a new clean and better ISA is easy. With the current
| existing experience that could be done in weeks or a few months
| at most, to allow for the simulation of how various variants
| run benchmarks, to determine the best variant.
|
| Nevertheless, designing the ISA is the only easy part. Then you
| have to write high-quality compilers, assemblers, linkers,
| debuggers and various other tools, and also good documentation
| for the ISA and all the tools.
|
| Developing such toolchains and convincing people to use them
| and educating them can take some years. Optimizing various
| libraries for which the performance is important for the new
| ISA can also take years.
|
| These things are what the incumbent ISAs like Aarch64, RISC-V
| or POWER provide.
| shash wrote:
| Interesting to see RISC-V described as an "incumbent" :D
| daeros wrote:
| I hope Qualcomm wins and wins its countersuits too.
| PhilippGille wrote:
| Most comments here seem to think that Qualcomm has to settle or
| switch to RISC-V. But from my understanding the article is only
| about their license to design custom chips with ARM IP, not about
| using ARM's designs.
|
| For example the Snapdragon 8 Gen 1 uses 1 ARM Cortex-X2, 3 ARM
| Cortex-A710 and 4 ARM Cortex-A510, which are ARM designs. Their
| latest announced chip though, Snapdragon 8 Elite, uses 8 Oryon
| cores, which Qualcomm designed themselves (after acquiring
| Nuvia).
|
| So is Qualcomm not still able to create chips like the former,
| and just prevented from creating chips like the latter? Or does
| "putting a chip together" (surely there is a bit more going into
| it) like the Snapdragon 8 Gen 1 still count as custom design?
| dagmx wrote:
| They're only losing their license to make custom cores. They're
| still free to use ARMs own cores.
|
| The reason being that ARM gave Nuvia a license to design cores
| at a specific rate, then Qualcomm bought them to use those
| cores. ARM claims that the license to design cores does not
| have a transferable rate to it.
| adrian_b wrote:
| Now Qualcomm does not want to continue to use any Arm cores,
| both because their own cores are better and because that
| would save them the cost for royalties.
|
| Obviously, Arm tries to prevent Qualcomm from using their own
| cores, because this time Arm would lose a major source of
| their revenue if Qualcomm stopped licensing cores.
|
| When Arm has given architectural licenses to Qualcomm and
| Nuvia, they were not worried about competition, because
| Qualcomm could not design good cores, while Nuvia had no
| perspective of selling so many cores for this to matter.
|
| The merging of Nuvia into Qualcomm has changed completely the
| possible effect of those architectural licenses, so Arm
| probably considers that giving them has been a big mistake
| and they now try to mend this by cancelling them, with the
| hope that they will convince justice that this is not
| illegal.
|
| For any non-Arm employee or shareholder, it is preferable for
| Arm to lose, unless the reduction in revenue for Arm would be
| so great as to affect their ability to continue to design
| improved cores for other companies and for other
| applications, but that is unlikely.
| dagmx wrote:
| There's a LOT of conjecture in your comment.
|
| Your very first line is one to begin with.
|
| ARM also doesn't seem to care if QC design their own cores.
| They just care that they renegotiate the royalty agreement.
| This is clear if you actually read their statements.
| adrian_b wrote:
| Because Arm wants to increase the royalties for the cores
| designed by Qualcomm, that is a pretty certain indication
| that these royalties have been smaller than for the cores
| licensed from Arm.
|
| Therefore Arm cares a lot if Qualcomm designs their own
| cores, because that would cause a smaller revenue for
| Arm.
|
| If Arm had not cared whether Qualcomm designs their own
| cores, they would have never sued Qualcomm.
|
| The official reason why Arm has sued Qualcomm, is not for
| increasing the royalties, because that has no legal
| basis.
|
| It is obvious that the lawsuit is just a blackmail
| instrument to force Qualcomm to pay higher royalties for
| the cores designed by them, but the official object of
| the lawsuit is to forbid Qualcomm to design their own
| cores, by claiming that the Oryon cores used in the new
| Qualcomm chipsets for laptops, smartphones and automotive
| applications have been designed by violating the
| conditions of the architectural licenses granted by Arm
| to Qualcomm and Nuvia, so Arm requests that Qualcomm must
| stop making any products with these Arm-compatible cores
| and they must destroy all their existing core designs.
| dagmx wrote:
| ARM want to raise the royalties for the cores designed by
| Nuvia, whose IP has now permeated all of Qualcomms IP.
|
| Again, your comments are pure conjecture not based on
| anything factual. I might as well just start saying how
| QC wants to rip off ARM IP and it would be as factually
| relevant as your comments.
| rickdeckard wrote:
| What is often overlooked on this topic is, that ARM also has a
| duty to protect its ecosystem.
|
| By using its dominant position in Smartphone chipsets, Qualcomm
| is in progress to establish a custom ARM-architecture as the new
| standard for several industries, fragmenting the ARM-ecosystem.
|
| For decades, ARM is carefully avoiding this to happen, by
| allowing selected partners to "explore" evolutions of the IP in
| an industry but with rules and methods to make sure they can't
| diverge too much from ARM's instruction set.
|
| Qualcomm acquired Nuvia and now executes the plan of using their
| restricted IP in a unrestricted fashion for several industries
| ("powering flagship smartphones, next-generation laptops, and
| digital cockpits, as well as Advanced Driver Assistance Systems,
| extended reality and infrastructure networking solutions").
|
| ARM has designed architectures which achieve comparable
| performance to Nuvia's IP (Blackhawk, Cortex-X), but Qualcomm's
| assumption is that they don't need it and that they can apply
| Nuvia's IP on top of their existing architecture without the need
| of licensing any new ARM design.
| neonsunset wrote:
| Last time I checked, Qualcomm did not introduce any custom
| instructions into the ISA. What damage are you speaking of?
| rickdeckard wrote:
| The merge of the Qualcomm architecture with the Nuvia IP they
| acquired, which was created under a far-reaching license ARM
| granted to Nuvia. Combining both creates a custom
| architecture different from ARMs consolidated and harmonized
| designs offered to licensees (i.e. Blackhawk or Cortex-X).
|
| The IP of Nuvia was not supposed to be used in all the use-
| cases that Qualcomm intends to deploy it in (and moreover
| there is still the ongoing legal dispute that Qualcomm is
| actually not allowed to use it)
| delfinom wrote:
| So when is ARM going after Apple for their custom
| architecture?
|
| Afai, Q hasn't diverged from the standard instruction set
| at all in the Oryon snapdragons.
| dehugger wrote:
| Presumably Apple didn't violate the terms of their own
| licensing agreement with ARM.
| acdha wrote:
| Apple was a founding partner of ARM back when Advanced
| RISC Machines was first created and owned almost half of
| the company when it was created.
| aragilar wrote:
| There's a missing word here (which otherwise makes the sentence
| nonsensical): "He's also expanding into new areas, most notably
| computing, where Arm is making its own push."
|
| I'm guessing _cloud_ computing, but guess you could add any
| buzzword in...
| Terretta wrote:
| Another odd word choice early in the piece:
|
| > _their_ so-called _architectural license agreement_
|
| Definition 2 is when this tends to be used:
| https://www.merriam-webster.com/dictionary/so-called
| runjake wrote:
| Wasn't/isn't Arm for sale?
|
| Is this just a ploy to strongarm Qualcomm into buying Arm?
| DidYaWipe wrote:
| Paywalled.
___________________________________________________________________
(page generated 2024-10-23 23:01 UTC)