Vlákno názorů k článku Mikroprocesory s architekturou RISC I od kvr kvr - Kdysi dávno jsem četl v článku o Sparc,...
-
Kdysi dávno jsem četl v článku o Sparc, že ty register windows, ač zprvu zajímavý nápad, jim později nadělal víc starostí než užitku (bylo to v 90. letech, takže předpokládám, že problémy mohly souviset s vylepšováním pipelining nebo out-of-order execution, ale nepamatuju si to).
Máte někdo přesnější informace, jak bylo implementováno přetečení register stacku? Předpokládám, že se vyvolal nějaký interrupt, který uložil všechny registry na stack a jelo se dál. Ale zase očekávám něco aspoň trochu inteligentního, aby funkce, která se dostala na hranu stacku, neukládala/neobnovovala komplet registry při každém volání podfunkce. Nebo se ukládala třeba jen polovina a druhá přesunula (to by mi zase tři stack frames přišly docela málo) ...?
-
ded kenedy (neregistrovaný)
nevim jak to bylo na starsich sparcich, ale myslim, ze specifikace dneska ani nerika kolik tech registru (resp. registrovych oken) je k dispozici a typicky jsou to stovky registru, takze k tomu preteceni nedochazi zase tak casto.
pokud dojde k vycerpani dostupnych registru, tak se vyvola vyjimka (,,window spil'' *), ktera se postara o presun registru na zasobnik. AFAIK, jak je to udelane, zalezi na OS. jinak prekladace jeste delaji optimalizace tak, aby funkce, ktere nevolaji dalsi funkci, nemusely vytvaret nove registrove okno.
nekde jsem cetl, ze pocet registru a oken byl dany podle nejakych simulaci, ktere se pozdeji ukazaly jako chybne. kazdopadne pouziti registroveho okna vypada jako vcelku dobry napad.
*) sice by se to melo psat se dvema ll, ale ten dementni spam-filtr to vyhodnoti jako spam
-
klusacek (neregistrovaný)
Aha. To ale znamena ze nekde musi byt dalsi registry ktere resi kdo vlastni ktere okno, nebo aspon vyhrazena oblast RAM do ktere proces zapise svuj PID vzdy kdyz alokuje nove okno. Jinak by to nefungovalo kdyby se provedlo nekolik rychlych context switchu po sobe a registry pak patrily ruznym procesum.
-
Pave Píša (neregistrovaný)
Přímo jeden z registrů příslušných danému oknu zastává roli klasického Frame Pointeru R30 (ve vstupní části - %i6)/Stack Pointeru R14 (v roli ve výstupní části %i6), takže se ví, na kterou virtuální adresu v adresním prostoru se má okno uložit. Ono se stejně jako u klasického volání se zásobníkem se právě %sp musí nastavit tak, aby bylo na zásobníku dostatek místa na registry okna (16 slov) + lokální proměnné a argumenty, které se nevešly do okna. Registrová okna jsou v podstatě v případě SPARCu jen specializovaným/omezeným případem cache.
Při přepínání threadů opravdu možná lze s využitím trochy přemýšlení flush všech registrů někdy obejít. V případě přepnutí paměťového kontextu ale ne. Adresy do zásobníku by pro opožděný zápis oken v jiném paměťovém kontextu směřovaly na úplně jiné "fyzické" (není přesné, mělo by se mluvit o FPN arámcích backing store/swapu) paměťové pozice.
-
V puvodni zprave o RISCu-I se pise, ze plocha cipu uvolnena diky trivialnimu radici se cela pouzila pro implementaci registru a skutecne tam jsou nejake simulace zmineny, ale ne nejaka hlubsi studie.
Ja bych si to naivne predstavoval tak, ze by se simulatoru zadal pocet registru/pocet oken, nechal se prelozit program optimalizujicim prekladacem a potom se teprve program spustil a z vysledneho 2D grafu by vyslo nejake optimalni cislo ;-)
K tomu ale jeste pristupuje multitasking a to je tak trosku zlo, jak pro RISC, tak i pro CISC :-)
-
Jeste mozna pridam jednu studii porovnavajici RISC-I a VAX. Slo o klasicky QuickSort, kdy sice u RISCu doslo pro urcite pole k 64 pretecenim registroveho okna, ale celkove se presunulo mezi mem a registry jen 4k slov, kdezto u VAXu to bylo 696k slov.
Vlastne je to logicke, protoze sice presun celeho okna do pameti je zdlouhavy, na druhou stranu se pri zapisu parametru na zasobnik vlastne kazdy parametr nekolikrat presune z a do mem, takze to ve vysledku muze byt horsi.
-
O register window se v te dobe hodne diskutovalo a jak vime, tak se nakonec pouzivaly obe moznosti, tj. jak MIPS s obecne jednou sadou registru, kde se o ne staral prekladac a potom RISC-like procesory s registrovymi okny, ktere vlastne pomahaly prekladaci vytvaret "zasobnikove ramce".
A jinak ano - v RISC I se pri preteceni/podteceni vyvolal HW trap a v handleru se provedlo uklizeni okna do pameti. Vzhledem k tomu, ze presuny memory-registry byly provadeny relativne malo, tak to uklizeni okna ve skutecnosti nebyla takova tragedie, jak to muze na prvni pohled vypadat.
-
Pavel Píša (neregistrovaný)
Díky za pěkný článek a pár připomínek.
Použití registrových oken mělo zásadní význam pro CPU s relativně rychlým řadičem a pomalým přístupem k paměti. Přitom při prozkoumání callgrafu většiny programů se ukáže, že ušetřením přístupů do paměti v nejvnitřnějších dvou úrovních volání/smyček často celkové počty přesunů sníží řádově.
V okamžiku, kdy byly CPU doplněny datovou pamětí cache tak tento specifický mechanizmus vyrovnávací paměti pouze pro stack ztratil (téměř zcela) smysl. Ve smyčkách přesunů a zpracování dat jde většinou více o rychlé přístupy k paměti než o volání funkce na každou položku a tak byl vyladěn raději obecný mechanizmus datové cache tak, aby dával data k dispozici s minimálním zpožděním (téměř jako registry). Pro pipelining a superscalár je pak přidaná analýza přístupu k shodné adrese a forwarding. Tím se výhody oken stírají.
Přesto určitá myšlenka odvozená od nápadu oken zůstává. Posunutí ukládání návratové adresy o jednu úroveň díky využití link registru => menší leaf-node funkce s počtem parametrů, který se vejde do registrů nepotřebují žádný přístup do paměti. Podobný princip jako registrová okna má uchovávání/predikce návratových adres v omezeném paralelním hardwarovém zásobníku například použitém i po přechodu x86 na superskalární návrhy s u(r)ops. Kvůli udržení souběhu tohoto HW "stacku" pak bylo nutné na nešťastné x86 v 32-bit režimu, který neumí jednoduše načíst PC do registru/data adresovat relativně k PC, předělat implementaci PIC knihoven
původní kód
call next
next:pop %ebxpredikci návratů rozhodil. Teď kompilátor emituje pomocné funkce
mov (%esp),%ebx
retJinak SPARC má specifikovaný přípustný počet registrových oken - minimum je 2, pak kvůli překryvu každé volání způsobuje výjimku. Maximum je 32, protože CWP registr/field je jen 5-bitový.
ČLÁNKY DO MAILU