Home | Notifications | New Note | Local | Federated | Search | Logout
Reply to @whitequark@social.treehouse.systems David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-24 17:16:27) @whitequarkReply
RISC-V gained a lot of early adoption by replacing weird in-house ISAs that people were using for control-plane things. Most of these didn’t really have serious PPA requirements. They were a tiny fraction of a total chip so even doubling the area or power made a negligible impact on the total chip.
When I was at MS, I worked with a team to replace an Arm core with a RISC-V core. The core was around 1% of the total area of the subsystem, the subsystem was around 1% of the total area of the SoCs that it went in. The choices were:
Arm
Some bespoke in-house ISA.
Some other licensed core.
RISC-V
RISC-V won because we could get (or build) cores that we could integrate in the subsystem and license onwards (Arm would not allow us to sublicense one of their cores in the subsystem, their lawyers don’t like money unless they’re allowed to lick it first). Anything else came with toolchain-maintenance expenses which would easily be more than the cost of a core license.
The big win for RISC-V was that someone else paid for the toolchain and the licenses were lower than anything else where that was the case.
---Reply--- Tobias@krono@toot.berlin (2026-08-24 20:59:16) @david_chisnall @whitequark I read that OpenRISC and SPARC (and, eventually, POWER) were as open as RISC-V is now, but years prior. Do you happen to know why they did not not cut it?
---Replies---
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-24 21:38:21) @krono @whitequark
SPARC had an open ISA. Leon was a series of 32-bit SPARC backed by ESA. Sun also opened the UltraSPARC T1. Both were fairly low-end cores (the T1 was okay in aggregate but pretty slow per core).
SPARC had a bunch of interesting ideas. Register windows are one of those ideas that was good on simple cores, annoying on more complex ones, but I think would actually be nice on a very high-end core if you nicely integrate it with register rename and asynchronous spill, but not quite the way SPARC specifies it. SPARC had a simple SIMD extension, but it was roughly comparable to MMX, nothing newer.
SPARC at Sun / Oracle stagnated because the Rock team (building high-per-thread performance cores) and the Niagara team (building massively multithreaded systems) hated each other. To add anything new to the architecture required both to agree, but if one agreed the other would disagree on principle. So the architecture is quite a nice '90s design that hasn't evolved.
After the Oracle acquisition, everyone got quite nervous that Oracle probably had some patents on things that might be necessary for good SPARC implementations and would be very aggressive about enforcing them.
POWER is more fun. When I was at Microsoft, we had a choice for first-party cores for Azure (later cancelled in favour of first-party SoCs using Arm-licensed cores) of:
Buy AMD and do x86. AMD's market cap was $30 B, so easily affordable (Microsofts' was around $850 B), but probably impossible to get past the regulators. They were already tested at-scale in Azure and Xbox, not clear what would be useful differentiation.
An in-house ISA. We went a really long way along this and concluded that we could do 0-20% (depending on workload) better performance than AArch64 by learning from their experience. The cost of this would be huge for the software ecosystem and most customers weren't willing to pay for performance so the business case wasn't there.
AArch64 is a nice matur