I dataarkitektur utgjør registervinduer en teknikk for å forbedre ytelsen til funksjonsanrop . De ble først brukt i Berkeleys RISC- prosessorer , som er kilden til SPARC- , AMD 29000- og Intel i960- arkitekturen .
De fleste prosessorer har et lite antall veldig raske minner som kalles registre . Prosessorer bruker registre for å midlertidig lagre verdier under gjennomføring av instruksjonspakker. Å øke antall registre i den opprinnelige prosessorutformingen kan resultere i veldig store ytelsesgevinster.
Mens registre er en ytelsesfaktor, har de også ulemper. Ulike deler av et dataprogram bruker hver sine midlertidige verdier, og vil derfor alle bruke registre. Siden det er veldig vanskelig å forstå strømmen av en programutførelse, er det ingen enkel måte å la utvikleren vite på forhånd hvor mange registre hver del av et program skal bruke. Vanligvis blir hensyn som dette rett og slett ignorert: utviklere og enda mer sannsynlig at kompilatorene de bruker prøver å bruke alle synlige registre. Dette er også den eneste riktige måten å fortsette hvis prosessoren som brukes, har få registre.
Dette er hvor registervinduene spiller inn. Siden hver del av programmet vil ha registre for seg selv, er det tilstrekkelig å gi flere separate sett med registre til de forskjellige delene av programmet. Problemet er at hvis alle registrene er synlige, vil en part bruke registre som ikke er en del av settet med registre som de har fått tildelt. Trikset er derfor å gjøre alle registerene usynlige for det som ikke tilhører dets sett med registre.
Således, i utformingen av Berkeley RISC, ser programmene bare 8 registre av totalt 64. Hele settet med registre utgjør en registrebank , og hver delmengde på 8 registrerer et vindu . På denne måten kan det være opptil 8 funksjonsanrop som har sitt eget sett med 8 register hver. Hvis programmet ikke presenterer noen nestede funksjonsanrop med en dybde som overstiger 8, trenger ikke prosessoren å laste ut registerene, det vil si å lagre dem i hovedminnet eller i hurtigbufferen, minner hvis tilgangstider er ekstremt langsomme sammenlignet med det av registre. Legg også merke til at statistiske studier av programmer som operativsystemer eller virkelige applikasjoner har vist at maksimal dybde for nestede samtaler er i gjennomsnitt 8, og at større dybde bare oppstår i 1%.