Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @krono@toot.berlin
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
---Reply---
Sun Microdevil Pte Ltd@koakuma@uwu.social (2026-08-26 00:53:34)
@david_chisnall @krono @whitequark
> 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.
I really really like the idea of generalizing the concept of register windows into "let the CPU know about the lifetimes of things in the stack" but otherwise I have no idea on how it would look like in reality...
Reply
---Replies---
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-26 01:02:45)
@koakuma @krono @whitequark
The first thing I'd want to do with SPARC register windows is make the spilling fully asynchronous with explicit serialisation. Define the spill region in memory as part of the state. Whenever the load-store unit has spare cycles, push out older windows and also reload newer ones.
Now, when you add register rename, you have a bunch of rename registers that you can discard because they are stored in memory. Keep the spill fully asynchronous. As soon as a function call exits speculation, push the values in the newly left window out to memory. When you run out of rename registers, discard the ones associated with the oldest still-in-rename-registers window and reuse them immediately. When you have more than a threshold number of available rename registers, load ones from the nearest frame.
Now you've got an architecture that should (no actual experiments were done to validate this, someone really should do them) scale nicely to systems with register rename. Fewer explicit load / store instructions for register spills and reloads and explicit information about when to speculatively reload values.