Vlákno názorů k článku Procesory s architekturou RISC v pracovních stanicích a serverech od Ales Hakl - Reseni hazardu nad klasickou MIPSovou pipeline je ve...

Reseni hazardu nad klasickou MIPSovou pipeline je ve skutecnosti prekvapive jednoduche (odhadem 5 vyrazu ve VHDL, tak 100 hradel) a vcelku bych se primlouval za to, aby se tohoto tematu nektery z dalsich dilu doknul, protoze v existujicich textech se toto obvykle prechazi s tim, ze je to "prilis slozite" pripadne "nezajimave", z toho reseni hazardu mimochodem vyplyvaji dalsi dva podstatne duvody existence registru "zadratovaneho na nulu" (cteni z r0 nikdy neni RAW hazard a zapis do r0 je rychly zpusob jak vyrobit nop).

Druha podstatna vlastnost in-order RISCove pipeline je, ze ty flagy vlastne nevadi. Je to registr, ktery po vetsinou zajima jenom EX-stage a tak muze byt primo v ni. Budto do tohoto registru probiha zapis pri prechodu instrukce EX->MA nebo cteni pri ID->EX, kopirovani flagu do/z registru jsou vlastne jenom specialni pripady tehoz postupu. Cemu flagy docela podstatne vadi je snaha o out-of-order implementaci, kde je opravdu potreba zavislosti vyvolane flagy podchycovat, to je koneckoncu duvod proc takova Alpha flagy nema (a duvod proc ma dva rezimy hlaseni aritmetickych/FP vyjimek).

Podmětné postřehy, ale o příznakovém registru bych i u in-order implementací docela podiskutoval. Potíž je, že skoky zavádí závislost počátku IF(i+1) na dokončení EX(i). To je přes několik stage. MIPS si pomáhá dvěma kličkami. Zaprvé delay slotem posouvá závislost až na spuštění IF(i+2) a zadruhé povolením pouze porovnání na rovnost nezatěžuje hloubku kombinační logiky pro skoky o výpočet (třeba i zrychleného) řetězce přenosů sčitání do vyšších bitů. Díky tomu se vyhodnocení rovnosti dostává u klasické implementace do ID(i). Přitom její max propagaci signálů do max času ALU nenatáhne, protože komparace na rovnost je jen 32 paralelních XORů a 8-vstupů NOR.

Jinak ta logika forwardingu hodnot v MIPSu zase není tak levná, přidává několika stage po více 32-bit multiplexerech - ty jsou minimálně dvě vrstvy AND/OR hradel a násobeno 32. Jen pro EX stage jsou potřeba dva třívstupé multiplexery - 2*(32*(3+1)) což je 256 hradel. Na skoky a řízení to začne ještě narůstat. Ale obecně je pravda, že to zase není až tak strašné.

Primarne jsem narazel na to, ze mnoho lidi (a podle me i autoru "popularnich" textu o architekturach CPU) si mysli, ze detekce zavislosti mezi instrukcemi v pipeline se musi implementovat nejakou komplikovanou logikou, ktera je malem samostatne CPU, uvedomeni si, ze na tom MIPSu je to v podstate par komparatoru je pomerne velke prozreni.

Samotne reseni tech hazardu je mozne provest mnoha zpusoby, kdy prakticky pouzivana reseni nejsou z obvodove nejjednodussich, napriklad kvuli zminenemu forwardingu, pripadne vami zminene zavislosti IF(i+1) na EX(i). Na druhou stranu je realne implementovat procesor, ktery forwarding nebude provadet (a misto toho bude do pipeline vzdy vkladat bubliny) na coz jsou misto tech zminenych multiplexeru potreba hradla OR/AND v ceste dekodovane instrukce (a jina realizace registru instrukce mezi jednotlivymi stage, ale to je zajimavy rozdil spise jenom na RTL urovni, CMOS hardware bude obdobny). Ty skoky se daji resit obdobne za predpokladu, ze neni pouzito strankovani pripadne nevadi ze IF muze vyvolat vypadek stranky, ze ktere se ve skutecnosti zadny kod provadet nebude (u nejakeho procesoru jsem videl pozadavek, ze branch nesmi byt posledni instrukce ve strance, uz si bohuzel nepamatuji jakeho, u MIPSu je tento pozadavek jasne dany temi delay sloty).

Jinak CMOS multiplexer typicky nejsou AND/OR hradla (12+2 tranzistoru pro dva vstupy), ale transfer gaty + invertor (4+2).