Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @david_chisnall@infosec.exchange
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---
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.

---Replies---

Sun Microdevil Pte Ltd@koakuma@uwu.social (2026-08-26 01:19:13)
@david_chisnall @krono @whitequark Oh yeah doing it in-hardware would definitely help, but I was thinking more in the terms of this kinda semantics, e.g. in the average SPARC function:

```
SAVE

! %l0 is non-volatile, which means that
! if the spill handler ever runs then it will be
! stored in to the spill area and loaded back
! when the fill handler runs
add foo, bar, %l0

! lots of other things here,
! possibly containing calls to other places
[...]

RESTORE
```

By the time you reach RESTORE then the system "knows" for sure that %l0 is dead, so - in the lucky case that the spill handler is never invoked - it won't ever attempt to write it to memory

Though, if you're doing spill/fill in-hardware then this is something that comes for free?