A Big Week for RISC-V | Hacker News Reader

A Big Week for RISC-V

eetimes.com

103 pointsJoachimS112 comments

RISC-V is going to bite at the low end embedded market where pennies matter, but it'll be a while before it eats into ARM at the mid to high end. ARM is offering non-discriminatory licenses at unit prices that are largely an irrelevance on the retail cost of a mobile phone or laptop. So it's going to take a long time to convince manufacturers that they want a non-compatible chip versus a few cents extra to get the well known one with all the support.

You're missing the point. It's not the cost but the fact that it has to be purchased that becomes a barrier to development and experimentation. Having to negotiate a licence even before you get started on a project can kill it.

You have to compare it to open source. Why are so many open source projects so popular? It's not the cost, corporations don't mind paying. It's the freedom to go in whatever direction any person wants to go without restriction that produces innovative software.

The comparable model for RISC-V is Linux and Redhat (et al), and on that basis it will win like Linux won. That combined with a clean and simple design.

Could you quantify it a bit more precisely: how much of that $1000-per-phone goes to ARM?

Everything is confidential, but you can get an idea. Arm's revenue on a phone CPU likely pennies, or at the highest end a buck. They just make it up in volume. The interesting point is how.

First, you can see from a recent HN post that an electric toothbrush contains a 32-bit ARM CPU. If you've built any hardware you'll know that your BOM is king, and you try to squeeze that on the back of your OEMs. So Philips isn't paying much for that CPU and the CPU vendor (who could be Philips) would choose a different CPU if the royalty payment was too high.

By taking a tiny bite out of a huge number of parts ARM both spreads out its risk (the parts are ubiquitous) and starves the market of oxygen: there just isn't enough revenue for many or any competitors to get started. They'd have to lose money for years, or even decades, to get to the break even point.

And don't forget what ubiquity means: that phone doesn't have an ARM CPU: there is ARM logic in all sorts of devices inside the phone, from the baseband processor to probably integrated logic in the camera (even if the CPU has ISP logic) to USB PHYs to who knows what. With a few pennies or less on each one. Those headline CPUs may have the highest royalty rate for all we know.

The real question is why Apple uses ARM. Yes they have a longstanding history back to the founding of ARM but they are masters of cutting their BOM. They have an architectural license, and have their own microarchitecture. They make their own toolchain soup to nuts. They don't have to worry about compatibility with anyone outside their ecosystem. So why bother to pay anything to ARM?

I've been asking around and the best (and consensus) theory I've been able to get is patents. That architectural license would presumably contain rights to all of ARM's patents.

If that theory is correct, that's a huge threat to RISC V. I doubt ARM would ue, or even threaten to sue any RISC V user now: they'd look like Goliath beating up David. But once RISC V starts to get noticeable traction, and especially if ARM is a public company, patent licensing will start to matter. Their smartest strategy would be to pull a Microsoft and force companies to simply pay ARM a royalty for every RISC V they ship.

Note: I'm a fan of the RISC V and not particularly a fan of ARM. But I recognize that ARM has played the long game quite well.

This seems like a reasonable theory but I’m not sure the framing as ‘Arm pulling a Microsoft and forcing companies to pay for every RISC-V chip’ is quite right.

Apple has had access to all Arm’s IP - eg for example on big.LITTLE. Isn’t it right that Apple (market cap around $3tn) actually pays for that IP if they want to use it on another ISA?

Also maybe Apple has decided that Aarch64 is a better choice for their higher end CPUs and it’s worth the extra cost? That would surely outweigh any consideration in terms of cost given how small a part of the BOM this is.

> Apple has had access to all Arm’s IP - eg for example on big.LITTLE. Isn’t it right that Apple (market cap around $3tn) actually pays for that IP if they want to use it on another ISA?

Yes, this is my point: there’s little reason to change if you’d just have to keep paying the same.

> Also maybe Apple has decided that Aarch64 is a better choice…

Remember that Apple has a full architecture license and their microarchitecture is their own. Their parts don’t really look like anybody else’s except having mostly the same instruction set. I really don’t think the ISA itself would be anything they would spend any time thinking about either way — other factors dominate.

We're broadly in agreement - my concern was the implication that Apple can't switch because they'd be sued and therefore there is a wider concern for the broader RISC-V ecosystem.

Apple would deserve to be sued if they tried to take Arm's IP that they've had access to for years and apply it to another ISA for free. Doesn't have any read across for a RISC-V designer that doesn't have access to / isn't using that IP.

There are two questions here, not to be conflated:

1: given that apple has their own architecture that happens to implement some of the ARM ISAs, what are they really paying for with their license? The conjecture is: primarily patents. ARM supplies a lot of tooling but I doubt much of that is usable in Apple’s environment, except some of the most surface stuff (ISA conformance, perhaps). At this point I doubt there’s a lot of ARM IP in apple’s parts except for the copyrights on the ISA and patents, which anyone can read.

2: patents can apply to other MPU vendors/developers even if they don’t read them. In fact the “best” (i.e. most horrible) way to enforce them is to wait until vendor gets enough traction and then demand a license be purchased.

1. Maybe, although we don't really know and there is almost certainly stuff that Apple has access to which isn't patents - can they pick up the phone to someone at Arm to discuss and get help on an issue - very likely. Plus as I've said before those patents and associated IP might be integral to Apple's designs and they absolutely should pay for them.

2. Of course, that's just how patents work. But there is no evidence that Arm is doing this.

Overall, I don't agree with the sense that Arm is an overhead for Apple that if it weren't for those pesky patents they would cast aside and cut their costs. I think it's more complex than.

RISC-V has been specifically designed so that the ISA itself doesn't use anything that's recent enough to be possibly patent encumbered. There might be risk involved in some chip designs, but these can be seamlessly replaced if needed.

Indeed, I have assumed it's all in the implementation patents, but designing around them can be easier said than done.

>The real question is why Apple uses ARM.

The industry ( Smartphone ) uses ARM and that benefited Apple enormously. All the open source software that apple deploy and uses inside iOS as well as LLVM compiler tool chain. Apple benefited these R&D in value are being spent from Android as well. Instead of Apple being the sold owner and maintainer of its own ISA.

At the end of the day ISA doesn't really matter from Apple's POV. It make less sense now when Apple now has an array of their own ARM implementation to choose from. Since they dont need to pay per unit it makes very little sense to switch.

Unless you are into very specific usage.

Perhaps Apple chose arm because they wanted to own their processor now-with the plan being to move to a non-arm architecture in the coming years?

Apple has been an ARM licensee since they were a founding shareholder in ARM. They used it in the Newton, but now of course it's ubiquitous in their products.

The effort to design their own instruction set (including all the tooling) would not be trivial, but probably not enormous for them given their scale. And given their scale, their license must be cheaper than the cost of that activity, because you know Cook would pay it if it would save them enough down the road.

Apple has deep pockets, but using an existing ISA gives you a lot of OSS porting and optimization work for free. They could just use RISC-V if they wanted to and still have all the flexibility they want.

Given the amount of software they write from scratch, and that they have their own tool chains, the actual ISA is below Apple’s noise floor. I’m sure they spend more on optimizing for the quirks (cache size, instruction timing, etc) of each generation of chip.

Not easily as their terms are private, but you can tell it's not a huge slice. Fairly well every phone and all manner of other devices uses an ARM but I'm googling their royalty revenues at $1.3 billion dollars annually. So that's not much per device shipped. Stuff you hear suggests maybe they get 1% on the sale price of a CPU. Note that's the CPU price, not the phone. The CPU in a phone might cost e.g. $20 so they maybe get 20 cents off that. I expect they have other revenues from design assistance and support etc but those costs would apply to a RISC-V device also.

I remember few years back ARM's CEO was giving presentation at AMD conference, and he explained ARM's strategy as such: Rather that taking a bigger slice of a smaller pie, we take a smaller piece of a very large pie.

A high end Snapdragon CPU is maybe 70$. It's unlikely they're making more than a dollar or two on a 1000$ phone.

There are only really two drivers for RISC-V at this point - license fees and Arm's insistence that unless you are Apple, you have to comply with the ISA exactly.

Both are something Arm can adjust at any point and is in the process of adjusting post-Nvidia-collapse. All it is going to take is for Arm to stand up a review process to deal with the problem gracefully.

There's a third one: ARM doesn't allow you to license your ARM cores (of your own design) to third parties. Only ARM can do that.

Just curious, where aren’t they complying with the ISA? I know they use a couple registers in specific ways, but IIRC, the way they use it was left to the implementer so they aren’t diverging from the architecture.

You can find more information here:

https://news.ycombinator.com/item?id=25801500

> It’s a tradeoff: With RISC-V you get innovation, you can create new extensions, but you lost software compatibility. And more importantly, you lose the guarantee of software compatibility,” he said. Arm’s founders made “that a key tenet, and that will serve us well going forward. I’m confident of that.”

How long does it take until we have server-side Ubuntu Linux and staple applications like PostgreSQL humming nicely on RISC-V? It does not matter if RISC-V has less ported software today, as long as there is clear roadmap when this advantage of ARM will be gone.

The Arm guy is talking nonsense as you'd expect. Fedora & the vast majority of packages have been ported to RISC-V since 2016/2017. Debian about a year later. I just started a PostgreSQL server on one of my (four) RISC-V machines here:

  ● postgresql.service - PostgreSQL database server
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vend>
     Active: active (running) since Sun 2022-02-13 06:56:50 EST; 1s ago
    Process: 1861715 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgres>
   Main PID: 1861722 (postmaster)
      Tasks: 8 (limit: 9510)
     Memory: 15.6M
        CPU: 262ms
     CGroup: /system.slice/postgresql.service
             ├─1861722 /usr/bin/postmaster -D /var/lib/pgsql/data
             ├─1861746 postgres: logger
             ├─1861752 postgres: checkpointer
             ├─1861753 postgres: background writer
             ├─1861754 postgres: walwriter
             ├─1861755 postgres: autovacuum launcher
             ├─1861756 postgres: stats collector
             └─1861757 postgres: logical replication launcher

  Feb 13 06:56:50 five systemd[1]: Starting PostgreSQL database >
  Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.>
  Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.>
  Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.>
  Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.>

The biggest problem I had was remembering the name of the Fedora PostgreSQL package and that I had to initdb before starting the service. If the Arm CEO really believes software compatibility/availability is Arm's moat then I'm afraid he's in for a big shock.

> Fedora & the vast majority of packages have been ported to RISC-V since 2016/2017. Debian about a year later.

Any idea whether distros are planning to move towards the upcoming RVA22 profile or are they going to remain on GC?

Had to look up RVA22: https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

Which RISC-V machines do you have?

While Intel is talking and investing the Chinese are already putting out chips and boards

https://www.cnx-software.com/2022/02/13/arm-or-risc-v-mangop...

https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-ris...

There are also the expensive dev boards from SiFive as well as the softcores from zepan. I think Alibaba and Rockchip will be available soon as well

Jean-Luc's website is great for tracking this space:

https://www.cnx-software.com/news/risc-v/

That's a cheap shot as the highend has long lead time, but the momentum hasn't died, it has only picked up. Personally I have more RISC-V embedded silicon than I have a count on, but of "application class" (= 64-bit with MMU that can run Linux), I have many boards that spans three completely distinct design origins and backing companies. And it's a multinational mix.

The growth of RISC-V will come from the innovation that the freedom allows. Literally anyone looking to design their own core from scratch will consider RISC-V and many have chosen it (Rivos, Tenstorrent, Esperanto Technologies, Alibaba, and many others I forgot).

EDIT: typos

Actually a lot more than 4, but only 4 working at present.

- 2 x HiFive Unleashed

- 2 x HiFive Unmatched

and on the shelf:

- Beagle V Beta (they decided not to proceed)

- PolarFire

- various FPGA-based RISC-V impls, notably a Lattice running PicoRV32

how long we have raspberry pi or equivalent priced SBU on risc-v?

my understanding is that would be a gamechanger because many people would be exposed to it. right?

It's unlikely to happen for a long time. The only reason the RPi exists is because they can divert some Broadcom chips which are produced in vast volumes for things like set-top boxes, get them for a few dollars, and package them as SBCs.

There was a run of ~ 5 million AllWinner chips and Beagle packaged one into a board which I have, which would have sold for sub $200, but they decided not to pursue the idea.

This was the case at first, but they are so big today that there are dedicated RPi chip runs (in fact, I believe they are the only thing using the RPi 4 processor).

Closer to pi zero than pi 4 but you can order it right now

https://aliexpress.com/item/1005003741287162.html

> How long does it take until we have server-side Ubuntu Linux

Debian is almost entirely ported to RISC-V and it's been the biggest early adopter.

96% of the packages are ported: https://wiki.debian.org/RISC-V#Progress

What is missing is powerful and inexpensive CPUs. (Easier said than done)

If everyone implements their own custom extensions, you would have to compile your software for each RISC-V device. To be able to do that, the compiler needs to support those extensions. I think that is what was meant with "you lost software compatibility".

Edit: I am mistaken, thanks everyone for educating me.

Intel CPUs have plenty of optional extensions. Basically you're building two versions of machine code and choose correct one at runtime.

How would that work if you have a hundred custom extensions?

Apparently it works fine:

  flags  : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

Forgive my ignorance if there’s an answer, but for x86, those extensions don’t overlap (mainly because Intel and AMD avoid stepping on each other). RISC-V doesn’t have a guarantee of non-overlapping vendor extensions, no?

There's no way to prevent overlapping extensions. One could easily make an x86 extension that overlaps with some existing one. There's just as much an incentive to not do that for x86 as there is for RISC-V.

See AMD's SSE5 vs Intel's SSE4 conflict in x86 - both have instructions that the other doesn't have, and some that both have, and, from what I understand, even the instruction formats conflict.

> One could easily make an x86 extension

One cannot easily make an x86 extension because there are approximately ~3 entities on the planet allowed to make x86 extensions.

Not really, China also added their own crypto extensions to x86 chips, though under AMD/VIA's license.

I wouldn't be surprised if Sony/Microsoft did too for their consoles.

It's doable if you have enough money to get AMD or VIA to make you a one-off.

Here's my random x86 extension: the byte sequence 0xc5,0xfd,0xd4,0x00 sorts the 64-bit floats in ymm0. It conflicts with AVX2. :)

You’ll have trouble shipping that extension. Not because it conflicts with AVX2, but because Intel will sue you for your comparability with the rest of x86.

I wasn't aware that we already have so many extensions. But doesn't the binary get more bloated the more extensions you have?

In practice, at least C compilers don't automatically generate code for multiple extensions, so you get the performance of the base ISA by default. This does indeed mean that every C program for x86-64 that isn't compiled with a specific target architecture just won't ever use AVX/AVX2/AVX-512/any other extension.

There is the idea of profiles, i.e. a single nice name for a group of extensions so that there's something one could provide a precompiled binary for, but I don't know what, if any, are RISC-V's plans for that.

>but I don't know what, if any, are RISC-V's plans for that.

Profiles. See RVA22.

With x86 there are common extensions that form a baseline (eg. you need SSE2 for any program to run at all). And there are more specialized extensions, eg. for high performance mathematical work. The specialized extensions can usually be confined to a library, and the library can work out at runtime what the hardware supports and swap in optimized functions.

It'll likely work much the same way for RISC-V, eg. in Fedora we require that the C (compressed) extension is supported, otherwise the distro won't boot, and things like the vector extension will probably be used only by specialized math libraries and the like.

You can choose which extensions to support at compile time and whether this extension is optional. E.g. many binaries don't use AVX at all, while binaries compiled with -march=native may assume that AVX is supported (and emit SIGILL if not).

Open Source software will not adopt 100s of costume extensions. If something becomes a standard it will likely move into a reserved place.

Isn't it the same with some ARM vendors ? Of course, a random foundry can't, but what's preventing Apple from including specific instructions on their core (not that it would make sense) or a specific coprocessor that may or may not be integrated ?

Apple does ship custom instructions on their code but does not expose it to third parties: their external compilers will not generate those instructions, and they remain in the kernel and system libraries where they can be hidden behind APIs without being directly exposed.

I find it hard to believe there is no way to probe for extensions and provide a fallback

It's a problem that already exists right now.

If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash?

I had a fun bug once running ARM code that had some NEON in it and it would crashed on Scaleway's VPS bc their servers ran chips that didn't have NEON implemented

This is the standard FUD spread around by Arm apologists. Of course you can detect RISC-V extensions at both compile and run time. In fact it's the first widespread ISA that was designed with extension in mind (so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension). This is in stark contrast to x86 where extensions are basically hacks piled on hacks.

> so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension

This doesn’t make sense, though. If you have something in your instruction stream that you don’t understand, it would be insane to do anything but fault immediately, unless the instruction is some sort of optional feature such as a hint or security mechanism where there is no real behavior associated with it. I mean ARM has this “capability” too by virtue of a fixed length instruction set but it doesn’t do anything with this like you’re describing.

It will be useful for disassemblers, among other things.

Sure, it’s helpful but not really a requirement by any means. Normal x86 code tends to be self-synchronizing, for example.

Sorry, my post was not intended to be FUD. I tried to follow the original claim but apparently placed too much merit in it.

> If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash?

Yes. Or it leaves them unused on the machine with avx.

For short runs of instructions, the overhead of fallback selection is larger than the overhead of using the least common denominator. For large functions, fallback selection is done by selecting specific functions after benchmarking.

Plenty of open source packages probe for extensions when built for either X86_64 or ARM, then call fallback code if the extension isn't there.

Things like OpenJDK, pixman, nss, ffmpeg.

Something something gentoo is eating the world.

Maybe this is naive - but why is software compatibility so important for servers (that mostly run open source software, like psql)? I assume none of it is written in ARM/x86 assembly language and all of it in higher level languages like c/c++/python/java/js/etc that can be compiled/run on RISC-V?

When rpi was a new thing writing Python in it was a pain in the ass. You had to compile a lot of stuff from source, which was a huge time sink.

To this day writing ARM lambdas on AWS has its own gotchas.

Idk, I think their CEO has a point, it's just that it might be a short lived one given how much money Chinese companies are throwing at risc V.

Old timers remember when "compiling open source C code to this other platform" was a real chore. Ever run the old school GNU configure and watched the giant stream of compatibility tests for weird architectures that go by? It's for a reason, one nearly forgotten in our current amd64 monoculture.

The good news is even if the CPU is weird the C compiler is likely to be clang and the OS is likely to be some Linux/glibc variant. A lot of the old porting challenges had to do with OS and compiler differences.

ARM also has a good chunk of compatibility issues... There are plenty of times I've had ARM7 vs NEON vs thumb vs big endian/little endian issues...

Even today, getting random debian packages running on a raspberry pi, I've hit issues of SIGILL due to packages being compiled with the wrong compiler for my CPU...

This is just the peak of irony from the guys that couldn't be bothered to copy ACPI for 30 years plus requiring anything running on ARM to set up a bespoke firmware build. That's before you get into all the hard/soft-float, thumb, non-thumb mess and toolchains targeting ARMv6jwzufgka.

You could say the same with ARM wrt intel.

Not Linux, but riscv64 FreeBSD works quite well.

OpenBSD has some support with 7.0:

* https://www.openbsd.org/riscv64.html

* https://wiki.freebsd.org/riscv

* https://papers.freebsd.org/2019/fosdem/bennett-riscv_llvm/

So does the RISC-V Haiku port.

I honestly done understand they hype around RISC-V, it’s seems like reinventing the wheel. Sure it’s open, but so is OpenPower; and that’s a lot more mature with better software support. I’m sure it’s not the only one either. Everything new is old I guess.

Edit: Tesla lies in their marketing, the industry is sexist, Rust is overhyped, Wayland still isn't very usable. If I'm gonna get downvotes, I might as well go big.

I mean you're right, but OpenPower showed up late to the game, after the RISC-V hype train was already going, almost as if IBM wanted to derail it. (More likely IBM saw RISC-V prove that it was viable and wanted people to be using Power instead. (So not so much derail it as derail it and put me on the rails instead))

SPARC has been open for decades:

* https://sparc.org

There have been non-Sun/Oracle CPUs available since the 1990s. Fujitsu sells entire product lines on them (and there's a Top 500 cluster built around SPARC.)

This also included the 'BIOS' (IEEE 1275-1994):

* https://en.wikipedia.org/wiki/Open_Firmware

And accessory bus (IEEE 1496-1993):

* https://en.wikipedia.org/wiki/SBus

I dont think SPARC is a very good ISA. Before RISC-V there was also OpenRISC, which early on had some of the same traction as RISC-V in the open source community. But both SPARC and OpenRISC has branch delay slots, which was, if I remember correctly, one of the things the designers of RISC-V wanted to avoid to have a more scalable ISA. Branch delay slots are supposedly a big issue when designing high end superscalar cores.

RISC-V is very well thought out when it comes to scaling from the smaller MCU cores to the largest supercomputer CPUs. With a coming revision the code density with the compressed extension is even better than ARM Thumb, while being better designed than Thumb (no mode switching)

> With a coming revision the code density with the compressed extension is even better than ARM Thumb

I'd love to read about this revision and understand how it achieves that improvement. Do you have a link handy?

https://github.com/riscv/riscv-code-size-reduction is the place to check.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-...

Does SPARC still have rotating register windows that are extremely hard to use effectively?

If anything, it's a clean slate design and that makes it way simpler than the legacy ISA's. To the point that a single, easy to target base ISA can be used for anything from bare-metal embedded devices to high-end supercomputers and hyperscale server hardware. That's quite unprecedented.

Also, it's very simple but cleverly designed to allow cheap and power-efficient CPUs.

Vectoring being one of the best features.

OpenPower was not 'open'. They were fake open for marketing reasons. You could not simply build an OpenPower chip and sell it.

Actually only long after RISC-V both OpenPower and MIPS opened up more.

The only thing that was actually open was SPARCv8 and that had a number of limitations that the creates of RISC-V didn't want. And Oracle had closed it up again after that.

OpenRISC was more a chip, not really an ISA design. And it wasn't 64 Bit when RISC-V started either.

And RISC-V also does a number of new things and removes some other things.

All of this has been extensively written about by the creators of RISC-V, you could just go read it.

The chinese want it. The open crowd thought they are in charge. And given the broken patent process when it will be invoked. It will run for awhile before what the reality is biting. Still early stage.

But just playing architecture game is hard. You need some reasons like lower power … for it to play.

> Tesla lies in their marketing, the industry is sexist, Rust is overhyped, Wayland still isn't very usable

I agree with everything else but RV is actually a big improvement over OpenPower and many other ISAs.

You could say that about most open source software. How did that turn out?

> Not unexpectedly, Nvidia this week pulled the plug on its bid to buy RISC-V competitor Arm after the $66 million deal was scuppered by regulators in multiple jurisdictions.

Million, really? Off by a factor of 1,000?

"RISC-V competitor"

At this moment, the relevant information about Arm is that it competes with x86. RISC-V is no more relevant than Elbrus, though obviously that's going to change.

This statement doesn't appear grounded in facts. Arm was clearly concerned with RISC-V _years_ ago and the competition from RISC-V is far more severe today. I don't claim that Arm will go away anytime soon, but RISC-V is a viable alternative especially in the embedded realm and that will be used for pricing pressure. Long-term, I suspect economics will play out as they always do in the tech sector.

RISC-V will win because there will be intense competition to be the best cpu core IP for any given market segment. Whereas ARM & x86 each have only a couple of companies competing with each other once you're fully committed to using them.

There are 15 firms with Arm architecture licenses almost all designing 64 bit cores - seems quite competitive to me.

>seems quite competitive to me.

Not very competitive when the only company that can license ARM cores to third parties is ARM itself.

The real money is in SoCs or end user devices not processor IP. Thus that’s where the resources to build the best cores will tend to go.

If you had a second Arm selling licensed cores against Arm v1 would competition result in better cores? Maybe but it’s equally likely that it would make it harder for either company to compete for talent against Apple and Qualcomm.

The problem with that is that RISC-V exists, which has such open market of cores.

And is there a RISC-V core that is competitive with the leading Apple Arm cores?

>And is there a RISC-V core that is competitive with the leading Apple Arm cores?

How does that even matter? You cannot license Apple's leading ARM cores.

You're trying to argue that the 'open market' in licensed designs results in better cores. I'm pointing out that the best cores today (and likely in the future) come from those with deep pockets - SoC / device manufacturers.

Maybe there will be a better / cheaper RISC-V equivalent of an A75 say but I'm honestly not that bothered.

>You're trying to argue that the 'open market' in licensed designs results in better cores.

No. There, you are wrong. Maybe this is something that you are worried about?

What I was "trying to say" is that a company that needs a core now has at least these two options: License an ARM chip from ARM, license a RISC-V chip from somebody else.

Somebody else there means the tens of vendors that are licensing their cores. A RISC-V core there would be one among the hundreds available. These numbers are growing every month.

Picking ARM means you're stuck with ARM. Maybe you already are using ARM, and remaining there while keeping an eye on the market is your choice for now.

Picking RISC-V means you're free to pick from a variety of vendors, and switch vendors anytime you wish. Some cores are even OSHW licensed, which means free as long as you don't need something better/not at your own risk. The point is not being stuck, thanks to RISC-V compliance.

It is not surprising ARM is worried about this. They're doing PR trying to present their advantages and throw in FUD against RISC-V.

Sometimes, I wonder, what if Jim Keller decided to take on RISC-V and delivered an open source implementation, which is as good as current x86 or ARM hardware. People / companies would move swiftly I guess.

Jim Keller is building RISC-V Ascalon processor at Tenstorrent right now.

https://youtu.be/KOHQQyAKY14

If I recall correctly, some things were planned to be open sourced.

It's a 6-issue design supposedly, so it should be about as wide as the ARM X1/X2 chips. If they open source this design, it could be very interesting for ARM moving forward.

I hope this not an "embrace, extend and extinguish" strategy. If the ARM and Nvidia deal had gone through, it would have been a major headache for Intel. Now that is off, Intel has less things to worry about on the architecture front apart from RISC-V.

The ISA is moving toward being a commodity and nothing is going to stop that.

Intel has more money to put into chip design. They already have all the IP and patents for the non-RISCV parts of the chip and chipset. They could literally design a drop-in replacement in their current motherboards and go straight to market years before all this stuff gets tested and shipped by the competition.

Just as important, they have the business connections and reputation of delivering. Those may be less tangible, but the best chip in the world doesn't mean anything if you can't move it to customers.

They seem very strongly positioned even if they never have any input into the ISA itself.

They have an even stronger position in x86, where they are the dominant player in a duopoly, with new entrants denied access.

So yes, they might be interested in helping RISC-V in order to hurt Arm on the low end, but I'm sure they're not looking forward to RV eating a chunk of the x86 market.

They are getting stomped by ARM on the high-end too.

X2 is quite a bit faster per clock than every x86 (except maybe golden cove).

It's only a matter of time before these start flowing into the high-end market and disrupt. Jim Keller is currently overseeing a 6-issue RISC-V core (same width as Intel's latest/greatest golden cove chip) that will allegedly be open-sourced too.

This is a very dangerous situation for them.

It seems better to milk x86 for all it's worth while leveraging RISC-V for all it's worth. If they can offer custom x86 compatibility with their RISC-V designs, that's just one more way to ensure they cut out the rest of the market and keep their lead.

It should be clear what is happening here. Intel sees Arm as a competitive threat in its high margin desktop and server cpu business. Supporting RISC-V as an Arm competitor at the low end weakens Arm and lessens that competitive threat.

Is it better to poke or not to poke a bear? I guess it depends on the bear being awake and what you poke it with.

A move like that could just as easily push ARM to go all in on servers and desktops and harm Intel even more.

More like the bear poking a sheep in this case!

Seriously though the key issue now is does Arm have resources to invest in better designs - weaken cashflow and that’s in doubt.

Well, it ARM is harmless, than Intel has no reason to fear them and place them explicitly on their strategy.

I think the key enabler for architecture diversity will be a jit-based OS kernel. Interpreters are an N-to-N problem, and build systems often fail. IR distributions seem most robust.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Reply on news.ycombinator.com