From: user5857@newsgrouper.org.invalid
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> Robert Finch writes:
> >Skimming through the SPARC architecture manual I am wondering how they
> >handle register renaming with a windowed register file. If the register
> >window file is deep there must be a ginormous number of registers for
> >renaming. Would it need to keep track of the renames for all the
> >registers? How does it dump the rename state to memory?
I don't remember SPARC ever getting OoO. The windowed register file
is but one cause.
> There is no need to dump the rename state to memory, not for SPARC nor
> for anything else. It's only microarchitectural.
It does need to be checkpointed if/when going OoO.
> The large number of architected registers may have been a reason why
> they needed so long to implement OoO execution.
>
> I think that the cost is typically a register allocation table RAT per
> branch (for maybe 50 branches or potential traps that you want to
> predict, i.e., 50 RATs).
50 RAT entries not 50 RATs.
> With 32 architected registers and 257-512
> physical registers that's 32*9 bits = 288 bits per RAT; with the 136
> architected registers of SPARC, and again <=512 physical registers,
> that would be 1224 bits per RAT.
Register files with more than 128 entries become big and especially SLOW.
Even 128 register entries is pushing your luck.
> There are probably other options that using a RAT, but I have
> forgotten them.
Physical register file where reads are done by {cam,valid} and writes
are done by decoder. the valid bits are recorded in a history table
for mispredict recovery between decode cycles.
There is also the Value-free reservation station model, where the RF
is not read until the station fires its entry.
> - anton
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
