Klasický RISC potrubí - Classic RISC pipeline

V historii počítačového hardwaru používaly některé rané redukované instrukční sady počítačových centrálních procesorových jednotek (RISC CPU) velmi podobné architektonické řešení, nyní nazývané klasický RISC pipeline . Těmi CPU byly: MIPS , SPARC , Motorola 88000 a později pomyslný CPU DLX vynalezený pro vzdělávání.

Každý z těchto klasických skalárních návrhů RISC se načte a pokusí se provést jednu instrukci za cyklus . Hlavním společným konceptem každého návrhu je pětistupňový kanál instrukcí provádění . Během provozu každý stupeň potrubí pracuje na jedné instrukci najednou. Každá z těchto fází se skládá ze sady klopných obvodů pro udržení stavu a kombinační logiky, která funguje na výstupech těchto klopných obvodů.

Klasický pětistupňový RISC potrubí

Základní pětistupňové potrubí ve stroji RISC (IF = Instruction Fetch , ID = Instruction Decode, EX = Execute, MEM = Memory access, WB = Register write back). Svislá osa je postupná instrukce; vodorovná osa je čas. Takže v zeleném sloupci je nejdříve instrukce ve fázi WB a nejnovější instrukce prochází načítáním instrukcí.

Načtení instrukcí

Pokyny jsou uloženy v paměti, jejíž čtení trvá jeden cyklus. Tato paměť může být vyhrazená SRAM nebo instrukční mezipaměť . Termín „latence“ se v informatice používá často a znamená čas od zahájení operace do jejího dokončení. Načtení instrukcí má tedy latenci jednoho hodinového cyklu (pokud používáte jeden cyklus SRAM nebo pokud byla instrukce v mezipaměti). Během fáze načítání instrukcí je tedy 32bitová instrukce načtena z instrukční paměti.

Program Counter , nebo PC, je registr, který obsahuje adresu, která je prezentována na paměti instrukcí. Na začátku cyklu se adresa zobrazí v paměti instrukcí. Poté se během cyklu instrukce načítá z instrukční paměti a současně se provádí výpočet pro určení dalšího PC. Výpočet dalšího PC se provádí zvýšením PC o 4 a výběrem, zda to vezme jako další PC, nebo alternativně, aby vzal výsledek výpočtu větve / skoku jako další PC. Všimněte si, že v klasickém RISC mají všechny instrukce stejnou délku. (To je jedna věc, která odděluje RISC od CISC). V původních návrzích RISC je velikost instrukce 4 bajty, takže vždy přidejte 4 na adresu instrukce, ale nepoužívejte PC + 4 pro případ převzaté větve, skoku nebo výjimky (viz zpožděné větve , níže ). (Všimněte si toho, že některé moderní stroje používají k uhádnutí adresy další instrukce složitější algoritmy ( predikce větve a predikce cíle větve ).)

Dekódování instrukcí

Další věc, která odděluje první stroje RISC od dřívějších strojů CISC, je, že RISC nemá žádný mikrokód . V případě mikrokódovaných instrukcí CISC, jakmile jsou načteny z mezipaměti instrukcí, jsou instrukční bity posunuty po potrubí, kde jednoduchá kombinační logika v každém stupni potrubí produkuje řídicí signály pro datovou cestu přímo z instrukčních bitů. V těchto návrzích CISC se velmi málo dekóduje ve fázi tradičně nazývané fáze dekódování. Důsledkem tohoto nedostatku dekódování je, že ke specifikaci toho, co instrukce dělá, musí být použito více instrukčních bitů. To ponechává méně bitů pro věci, jako jsou registrační indexy.

Všechny instrukce MIPS, SPARC a DLX mají nejvýše dva registrační vstupy. Během fáze dekódování jsou indexy těchto dvou registrů identifikovány v rámci instrukce a indexy jsou prezentovány do paměti registrů jako adresa. Dva jmenované registry jsou tedy načteny ze souboru registru . V návrhu MIPS měl soubor registru 32 položek.

Současně se čte soubor registru, logika vydávání instrukcí v této fázi určuje, zda je potrubí připraveno provést instrukci v této fázi. Pokud ne, logika problému způsobí, že se zastaví fáze instrukce načítání i fáze dekódování. V zastavovacím cyklu vstupní žabky nepřijímají nové bity, takže během tohoto cyklu neprobíhají žádné nové výpočty.

Pokud je dekódovaná instrukce větev nebo skok, cílová adresa větve nebo skoku se vypočítá souběžně se čtením souboru registru. Podmínka větve se vypočítá v následujícím cyklu (po načtení souboru registru) a pokud je větev převzata nebo je -li instrukce skokem, je počítači v první fázi přiřazen cíl větve, nikoli inkrementovaný počítač, který bylo vypočítáno. Některé architektury využívaly ve fázi Provedení aritmetickou logickou jednotku (ALU) za cenu mírně snížené propustnosti instrukcí.

Fáze dekódování skončila s poměrně velkým množstvím hardwaru: MIPS má možnost větvení, pokud jsou dva registry stejné, takže po přečtení souboru registru běží v řadě 32bitový strom AND a vytváří tak velmi dlouhou kritickou cestu. fáze (což znamená méně cyklů za sekundu). Také výpočet cílového větve obecně vyžadoval 16bitové přidání a 14bitový inkrementátor. Vyřešení větve ve fázi dekódování umožnilo pouze penalizaci chybné předpovědi větve s jedním cyklem. Vzhledem k tomu, že pobočky byly velmi často přijímány (a tedy špatně předpovídány), bylo velmi důležité udržet tento trest na nízké úrovni.

Vykonat

Ve fázi Execute dochází ke skutečnému výpočtu. Tato fáze se obvykle skládá z ALU a také bitového řadiče. Může také zahrnovat multiplikátor a dělič více cyklů.

ALU je zodpovědný za provádění booleovských operací (a, nebo ne, nand, nor, xor, xnor) a také za provádění celočíselného sčítání a odčítání. Kromě výsledku ALU obvykle poskytuje stavové bity, například zda byl výsledek 0, nebo zda došlo k přetečení.

Bitový řadič je zodpovědný za řazení a otáčení.

Pokyny k těmto jednoduchým strojům RISC lze rozdělit do tří tříd latence podle typu operace:

• Operace registrace a registrace (latence jednoho cyklu): Sčítání, odčítání, porovnávání a logické operace. Během fáze spuštění byly dva argumenty převedeny na jednoduchou ALU, která vygenerovala výsledek do konce fáze spuštění.
• Reference paměti (latence dvou cyklů). Všechna zatížení z paměti. Během fáze spuštění přidala ALU dva argumenty (registr a konstantní offset) k vytvoření virtuální adresy do konce cyklu.
• Vícecyklové pokyny (latence mnoha cyklů). Celočíselné násobení a dělení a všechny operace s plovoucí desetinnou čárkou . Během fáze provádění byly operandy těchto operací přiváděny do vícecyklové jednotky násobení/dělení. Zbytek potrubí mohl pokračovat v provádění, zatímco jednotka násobení/dělení odvedla svou práci. Aby se předešlo komplikování fáze zpětného zápisu a logiky vydání, vícecyklová instrukce zapisovala své výsledky do samostatné sady registrů.

Přístup do paměti

Pokud je třeba přistupovat k datové paměti, je to provedeno v této fázi.

Během této fáze mají pokyny pro latenci jednoho cyklu jednoduše předány výsledky do další fáze. Toto předávání zajišťuje, že instrukce jednoho i dvou cyklů vždy zapisují své výsledky ve stejné fázi kanálu, takže lze použít pouze jeden port pro zápis do souboru registru a je vždy k dispozici.

Pro přímé ukládání mapovaných a virtuálně označených dat do mezipaměti, což je zdaleka nejjednodušší z mnoha organizací mezipaměti dat , se používají dvě paměti SRAM , jedna pro ukládání dat a druhá pro ukládání značek.

Odepsat

Během této fáze zapisují výsledky jednoho cyklu i dva cykly své výsledky do souboru registru. Všimněte si toho, že k souboru registru přistupují dvě různé fáze současně - fáze dekódování čte dva zdrojové registry, zároveň že fáze zpětného zápisu zapisuje cílový registr předchozí instrukce. Na skutečném křemíku to může představovat nebezpečí (více o nebezpečích viz níže). Důvodem je, že jeden ze zdrojových registrů, které se čtou v dekódování, může být stejný jako cílový registr zapsaný v zpětném zápisu. Když k tomu dojde, pak se stejné paměťové buňky v souboru registru načítají i zapisují současně. Na křemíku mnoho implementací paměťových buněk nebude správně fungovat, když budou čteny a zapisovány současně.

Nebezpečí

Hennessy a Patterson vytvořili termín nebezpečí pro situace, kde by pokyny v potrubí vedly k nesprávným odpovědím.

Strukturální nebezpečí

Strukturální rizika nastávají, když se dva pokyny mohou pokusit použít stejné zdroje současně. Klasické kanály RISC se těmto nebezpečím vyhnuly replikací hardwaru. Zejména instrukce větve mohly použít ALU k výpočtu cílové adresy větve. Pokud by k tomuto účelu byla ve fázi dekódování použita ALU, instrukce ALU následovaná větví by viděla, jak se oba instrukce pokoušejí používat ALU současně. Tento konflikt je jednoduché vyřešit navržením specializovaného sčítače cílové větve do fáze dekódování.

Data ohrožení

K datovým rizikům dochází, když se instrukce naplánovaná naslepo pokusí použít data dříve, než jsou data k dispozici v souboru registru.

V klasickém kanálu RISC se nebezpečí dat vyhýbá jedním ze dvou způsobů:

Řešení A. Vynechání

Vynechání je také známé jako předávání operandů .

Předpokládejme, že CPU spouští následující část kódu:

SUB r3,r4 -> r10     ; Writes r3 - r4 to r10
AND r10,r3 -> r11    ; Writes r10 & r3 to r11

Fáze načítání a dekódování instrukcí odesílají druhou instrukci jeden cyklus po prvním. Protékají potrubím, jak ukazuje tento diagram:

V naivním potrubí , bez ohledu na nebezpečí, probíhá ohrožení dat následujícím způsobem:

V cyklu 3 SUBinstrukce vypočítá novou hodnotu pro r10. Ve stejném cyklu je ANDoperace dekódována a hodnota souboru r10je načtena ze souboru registru. Nicméně SUBinstrukce ještě neuvedl její výsledek r10. K tomuto zpětnému zápisu obvykle dochází v cyklu 5 (zelené pole). Proto je hodnota načtená ze souboru registru a předaná do ALU (ve fázi provedení ANDoperace, červené pole) nesprávná.

Místo toho musíme data, která byla vypočítána SUBzpět, předat fázi Execute (tj. Do červeného kruhu v diagramu) ANDoperace, než se normálně zapíší zpět. Řešením tohoto problému je dvojice obtokových multiplexorů. Tyto multiplexery jsou na konci dekódovací fáze a jejich flopované výstupy jsou vstupy do ALU. Každý multiplexer vybírá mezi:

1. Port pro čtení souboru registru (tj. Výstup fáze dekódování, jako v naivním kanálu): červená šipka
2. Aktuální registrační kanál ALU (obejít o jeden stupeň): modrá šipka
3. Aktuální kanál registru přístupové fáze (což je buď načtená hodnota, nebo předaný výsledek ALU, což umožňuje obejití dvou fází): fialová šipka. Všimněte si toho, že to vyžaduje, aby byla data předána zpět v čase o jeden cyklus. Pokud k tomu dojde, musí být vložena bublina, která zastaví ANDprovoz, dokud nebudou data připravena.

Logika dekódovacího stupně porovnává registry zapsané instrukcemi ve vykonávacích a přístupových fázích kanálu s registry přečtenými instrukcemi ve fázi dekódování a způsobí, že multiplexory vyberou nejnovější data. Tyto obtokové multiplexory umožňují potrubí provádět jednoduché pokyny pouze s latencí ALU, multiplexeru a klopného obvodu. Bez multiplexorů by do latence těchto pokynů musela být zahrnuta latence zápisu a následného čtení souboru registru.

Všimněte si, že data mohou být předány pouze dopředu v čase - data není možné obejít se zády k dřívějším stadiu, pokud dosud nebyl zpracován. Ve výše uvedeném případě jsou data předávána dopředu (v době, kdy ANDje připravena pro registr v ALU, SUBji již vypočítal).

Řešení B. Blokování potrubí

Zvažte však následující pokyny:

LD  adr    -> r10
AND r10,r3 -> r11

Data načtená z adresy adrnejsou v mezipaměti dat k dispozici až po fázi LDinstrukce Přístup do paměti . Do této doby je ANDinstrukce již prostřednictvím ALU. Chcete -li to vyřešit, bude nutné data z paměti předat zpět v čase na vstup do ALU. Toto není možné. Řešením je zdržení ANDinstrukce o jeden cyklus. Ve fázi dekódování je detekováno ohrožení dat a fáze načítání a dekódování jsou zastaveny - je jim zabráněno propadávat vstupy, a tak zůstávají ve stejném stavu po celý cyklus. Fáze spouštění, přístupu a zpětného zápisu po proudu viz další instrukce bez operace (NOP) vložená mezi instrukce LDa AND.

Tento NOP se nazývá bublina potrubí, protože se vznáší v potrubí, jako vzduchová bublina ve vodovodním potrubí, zabírá zdroje, ale nepřináší užitečné výsledky. Hardware, který detekuje nebezpečí dat a zastaví potrubí, dokud není nebezpečí odstraněno, se nazývá blokování potrubí .

Obcházení zpět v čase	Problém vyřešen pomocí bubliny

Propojení potrubí však nemusí být použito s žádným přesměrováním dat. První příklad SUBnásledovaného ANDa druhý příklad LDnásledovaný ANDmůže být vyřešen zastavením prvního stupně o tři cykly, dokud není dosaženo zpětného zápisu, a data v souboru registru jsou správná, což způsobí načtení správné hodnoty registru ve ANDfázi Decode. To způsobuje docela velký zásah do výkonu, protože procesor tráví spoustu času zpracováním ničeho, ale rychlosti hodin lze zvýšit, protože na čekání je méně logiky předávání.

Toto nebezpečí dat lze snadno zjistit, když strojový kód programu napíše kompilátor. Stanford MIPS Stroj se spoléhal na kompilátoru přidat instrukce NOP v tomto případě, spíše než mít obvody pro detekci a (více taxingly) oddalovat první dvě pipeline. Odtud název MIPS: mikroprocesor bez propojených fází potrubí. Ukázalo se, že další instrukce NOP přidané kompilátorem rozšířily binární soubory programu natolik, že se snížila rychlost zásahu do mezipaměti instrukcí. Hardwarový stánek, přestože byl drahý, byl vrácen zpět do pozdějších návrhů, aby se zlepšila rychlost zásahu do mezipaměti instrukcí. V tomto okamžiku již zkratka nedávala smysl.

Rizika ovládání

Rizika kontroly jsou způsobena podmíněným a bezpodmínečným rozvětvením. Klasický kanál RISC řeší větve ve fázi dekódování, což znamená, že opakování rozlišení větví je dlouhé dva cykly. Existují tři důsledky:

• Opakování rozlišení větví prochází docela dost obvodů: čtení instrukční mezipaměti, čtení registrových souborů, výpočet podmínek větve (což zahrnuje 32bitové srovnání na procesorech MIPS) a multiplexer adresy další instrukce.
• Protože cíle větví a skoků se počítají souběžně se čtením registru, ISA RISC obvykle nemají instrukce, které se větví na adresu registr+offset. Přejít na registraci je podporováno.
• Na každé přijaté větvi je instrukce bezprostředně po větvi vždy načtena z mezipaměti instrukcí. Pokud je tato instrukce ignorována, existuje jeden cyklus za odebraný trest IPC pobočky , který je dostatečně velký.

Existují čtyři schémata k vyřešení tohoto problému s výkonem s větvemi:

• Předpověď nepřijata: Vždy načtěte instrukci za větev z mezipaměti instrukcí, ale proveďte ji pouze v případě, že větev není převzata. Pokud není větev odebrána, zůstane potrubí plné. Pokud je větev převzata, instrukce je vyprázdněna (označena jako NOP) a příležitost jednoho cyklu dokončit instrukci je ztracena.
• Pravděpodobná větev: Vždy načtěte instrukci po větvi z mezipaměti instrukcí, ale proveďte ji pouze v případě, že byla větev odebrána. Kompilátor může na takové větvi vždy zaplnit slot zpoždění větve, a protože větve jsou přijímány častěji než ne, mají takové větve menší trest IPC než předchozí druh.
• Slot pro zpoždění větve : Vždy načtěte instrukci po větvi z mezipaměti instrukcí a vždy ji proveďte, i když je větev převzata. Místo toho, aby byly brány IPC za část zlomků buď přijaty (možná 60%), nebo nebyly přijaty (možná 40%), sloty pro zpoždění větví berou penalizaci IPC pro ty větve, do kterých kompilátor nemohl naplánovat slot zpoždění větve. Návrháři SPARC, MIPS a MC88K navrhli do svých ISA slot pro zpoždění větví.
• Předpověď větve : Souběžně s načítáním každé instrukce hádejte, jestli je instrukce větev nebo skok, a pokud ano, uhádněte cíl. V cyklu po větvi nebo skoku přiveďte instrukci na uhádnutý cíl. Pokud je odhad špatný, spláchněte nesprávně načtený cíl.

Zpožděné větve byly kontroverzní, zaprvé proto, že jejich sémantika je komplikovaná. Zpožděná větev určuje, že ke skoku na nové místo dojde po další instrukci. Další instrukce je ta, kterou nevyhnutelně načte mezipaměť instrukcí za větví.

Zpožděné větve byly kritizovány jako špatná krátkodobá volba v designu ISA:

• Kompilátory mají obvykle určité potíže s nalezením logicky nezávislých instrukcí, které mají být umístěny za větev (instrukce za větví se nazývá zpožďovací slot), takže musí vložit NOP do zpožďovacích slotů.
• Superskalární procesory, které načítají více instrukcí za cyklus a musí mít nějakou formu předpovědi větví, nemají ze zpožděných větví prospěch. Alpha ISA vynechal odložených větve, protože byla určena pro superskalární procesory.
• Nejzávažnější nevýhodou zpožděných větví je dodatečná složitost ovládání, kterou s sebou nesou. Pokud instrukce zpožďovacího slotu bere výjimku, musí být procesor restartován na větvi, nikoli v další instrukci. Výjimky pak mají v zásadě dvě adresy, adresu výjimky a adresu restartu, a generování a správné rozlišování mezi těmito dvěma ve všech případech bylo zdrojem chyb pro pozdější návrhy.

Výjimky

Předpokládejme, že 32bitový RISC zpracovává instrukci ADD, která sčítá dvě velká čísla, a výsledek se nevejde do 32 bitů.

Nejjednodušší řešení, které poskytuje většina architektur, je obtékání aritmetiky. Čísla větší než maximální možná kódovaná hodnota mají své nejvýznamnější bity useknuté, dokud se nevejdou. V obvyklém systému celých čísel 3000000000+3000000000 = 6000000000. S nepodepsanou 32bitovou aritmetikou zalamování, 3000000000+3000000000 = 1705032704 (6000000000 mod 2^32). To se nemusí zdát strašně užitečné. Největší výhodou balící aritmetiky je, že každá operace má dobře definovaný výsledek.

Ale programátor, zvláště pokud programuje v jazyce podporujícím velká celá čísla (např. Lisp nebo Scheme ), možná nechce balit aritmetiku. Některé architektury (např. MIPS) definují speciální operace sčítání, které se rozdělují na speciální místa při přetečení, místo aby zabalily výsledek. Za vyřešení problému je zodpovědný software v cílovém umístění. Tato speciální větev se nazývá výjimka. Výjimky se liší od běžných větví v tom, že cílová adresa není specifikována samotnou instrukcí a rozhodnutí o pobočce závisí na výsledku instrukce.

Nejběžnějším druhem softwarově viditelné výjimky na jednom z klasických strojů RISC je TLB miss .

Výjimky se liší od větví a skoků, protože tyto další změny toku řízení jsou vyřešeny ve fázi dekódování. Výjimky jsou vyřešeny ve fázi zpětného zápisu. Když je detekována výjimka, následující pokyny (dříve v kanálu) jsou označeny jako neplatné a jak proudí na konec potrubí, jejich výsledky se zahodí. Čítač programu je nastaven na adresu obsluhy speciální výjimky a zapisují se speciální registry s umístěním a příčinou výjimky.

Aby bylo možné software snadno (a rychle) vyřešit problém a restartovat program, procesor musí mít přesnou výjimku. Přesná výjimka znamená, že všechny instrukce až na výjimku byly provedeny a výjimka a vše poté nebylo provedeno.

Abychom získali přesné výjimky, CPU musí potvrdit změny stavu viditelného softwaru v pořadí programů. K tomuto příkazu v pořadí dochází velmi přirozeně v klasickém kanálu RISC. Většina instrukcí zapisuje své výsledky do registrového souboru ve fázi zpětného zápisu, a tak k těmto zápisům dochází automaticky v pořadí programu. Pokyny pro ukládání však zapisujte jejich výsledky do fronty dat úložiště v přístupové fázi. Pokud instrukce úložiště má výjimku, záznam Store Data Queue se zneplatní, takže nebude později zapsán do SRAM dat mezipaměti.

Zpracování chybné mezipaměti

Občas datová nebo instrukční mezipaměť neobsahuje požadovaný datum nebo instrukci. V těchto případech musí CPU pozastavit provoz, dokud nelze mezipaměť naplnit potřebnými daty, a poté musí pokračovat v provádění. Problém naplnění mezipaměti požadovanými daty (a potenciální zápis zpět do paměti vypuzené mezipaměti) není specifický pro organizaci potrubí a není zde diskutován.

Existují dvě strategie, jak vyřešit problém s pozastavením/obnovením. První je globální signál stání. Tento signál, když je aktivován, brání pokynům postupovat dolů po potrubí, obvykle tím, že na začátku každé fáze odepne hodiny od žabek. Nevýhodou této strategie je, že existuje velké množství klopných obvodů, takže šíření signálu globálního zastavení trvá dlouho. Protože se stroj obecně musí zastavit ve stejném cyklu, ve kterém identifikuje stav vyžadující zastavení, signál stání se stane kritickou cestou omezující rychlost.

Další strategií, jak zvládnout pozastavení/obnovení, je znovu použít logiku výjimek. Stroj přijímá výjimku z nevhodného pokynu a všechny další pokyny jsou neplatné. Když byla mezipaměť naplněna potřebnými údaji, restartuje se instrukce, která způsobila vynechání mezipaměti. Aby se urychlilo vynechání zpracování mezipaměti dat, lze instrukci restartovat tak, aby k jejímu přístupovému cyklu došlo jeden cyklus po naplnění mezipaměti dat.

Viz také

• Železný zákon o výkonu procesoru

Reference