Vlákno názorů k článku Navrhujeme a vyrábíme vlastní CPU: architektura instrukční sady od Pavel Píša - Celkově se mi přístup k návrhu ISA pro...

Celkově se mi přístup k návrhu ISA pro malý jedno-cyklový CPU líbí. PC v GP registru dává smysl pro jednoduché PC relativní adresování a třeba na 32-bit ARMu i ke kombinaci ovnovení registrů a návratu z podprogramů jednou LDM instrukcí. Ale pro jakýkoliv návrh, který má vést k výkonnějšímu procesoru je speciální chování běžných ALU instrukcí po volbě cíle do PC zabiják. Predikce skoků a další se stává velkým problémem. Je to také vidět na odchodu ARMu u AArch64 k samostatnému PC registru. Přitom i LDM/STM se stalo přítěží a tak dovolují jen LDP/STP aby byly omezené počty závislostí k jedné instrukci na rozumný počet. Jinak se stává uložení dataflow závislostí k jedné pozici v reorder bufferu nebo rezervační stanici se závislou instrukcí noční můrou.

Nenašel jsem instrukci pro plnění registru konstantou, určitě nechceme 16 bitů, ale osm bitů posunutých o osm doleva jen se specifikací jednoho cílového registru by se mohlo hodit. Pak druhá instrukce pro přičtení osmi znaménkově rozšířených bitů, kde by třeba zdroj a cíl byl shodný registr. Předpokládám, že autor využije k témuž LDIS dstr, PC, ale opět pro malý design bez pipeline je to použitelné, pro jen nepatrně větší s pipeline ne. Přitom pipeline třeba i jen se třemi stupni extrémně pomůže.

Pro sběrnice na FPGA se mi zdá, že omezit šířku na 8 bitů pro 16-bit CPU jako komplikace a zvětšení návrhu. Pokud chci na 16-bit CPU 8-bit/byte granularitu adresace, tak je nejvýhodnější paměť připojit 16-bitově, nejnižší bit pro čtení nezapojit, požadovat 16-hodnoty zarovnané na sudé adresy a pro čtení 8-bit přidat multiplexor řízený A0. Pro zápis po byte pak hodnotu zopakovat na D8 až 15 a podle A0 povolovat byte-enable signály. Pokud se mají podporovat nezarovnané 16-bit přístupy, tak to situaci celkem komplikuje. Je nutné přidat FSM a některé přístupy budou trvat dva cykly.

Pokud je však datová sběrnice opravdu jen 8-bivá, tak každé čtení instrukce a ST a LD na data začne vyžadovat sekvenční přístup, dvoustavovou FSM, a tím se návrh komplikuje.

jednodušší je pak Harward uspořádání pamětí. Ale pro obecnou programovatelnost a nahrávání kódu chcete spíš von Neumanna. Takže u malého výukového návrhu bez cache bych sáhl k řešení, kdy datový přístup k paměti vždy pozastaví fetch...

Ale obecně oceňuji návrh podle vlastní invence a odvahu se poté s důsledky poprat a ještě více sepsat dobré a třeba i špatné zkušenosti pro druhé. Kdybych měl čas, zkusím jen pro zajímavost návrhu poslat do iCE40 na ice-v Wireless... Myslím, že by se tam měl vejít... Jejich RISC-V ve Verilogu se tam vejde, RVapo od pana Gruncla již spíš ne. Single cycle s tím že cycle se roztáhne na více kvůli společné sběrnici na data a idata a dalším problémům, se tam podařilo pustit. Ale je to jen obskurita na test. Na 5 stage pipeline, nezarovnané přístupy a násobní potřebuje již výrazně větší FPGA.

Ale pro jakýkoliv návrh, který má vést k výkonnějšímu procesoru je speciální chování běžných ALU instrukcí po volbě cíle do PC zabiják.

Nedávno jsem na toto téma někde (už si nepamatuju odkaz) četl článek, který to pěkně vysvětloval. V hrubých obrysech důvody chápu, detaily jsem zatím nestudoval, ale mým cílem bylo zbytečně si nekomplikovat návrh a implementaci procesoru a taky assembleru. Celý tento projekt byla pro mě nová neprobádaná oblast a na začátku jsem neměl moc odhad náročnosti a toho, jestli vůbec dojdu do cíle. Optimalizace, pipelining, apod. jsem vůbec neřešil. Možná někdy příště...

Nenašel jsem instrukci pro plnění registru konstantou, ... Předpokládám, že autor využije k témuž LDIS dstr, PC

Odpověděl jste si sám. Používám LDIS, v assembleru k tomu mám i makro set REG, EXPR, které dovolí na jednom řádku zapsat i konstantu (a vynechat jméno registru PC). Zároveň LDIS používám jako POP při práci se zásobníkem, k tomu mám duální instrukci DDSTO fungující jako PUSH. Motivace byla opět zredukovat instrukční sadu a tím i složitost řadiče CPU a assembleru.

Pro sběrnice na FPGA se mi zdá, že omezit šířku na 8 bitů pro 16-bit CPU jako komplikace a zvětšení návrhu.

Chtěl jsem si vyzkoušet, jaké důsledky bude mít, když nebudu omezovat nezarovnané přístupy do paměti a použiju interně 16bitový procesor s externí 8bitovou sběrnicí. Souhlasím, že Vaše navrhované řešení s 16bitovou sběrnicí je lepší. V porovnání s mou implementací jsou docela dobře vidět důvody, proč procesory vyžadují zarovnané adresy pro vícebajtové operace s pamětí, nebo proč jsou nezarovnané přístupy pomalejší.

Uznávám, že některé věci dělám neoptimálně nebo "divně". Důvody jsou buď snaha o jednoduchost, nebo cílené pokusy udělat některé věci jinak, prakticky si vyzkoušet následky a pochopit některé vlastnosti běžně používaných procesorů, jejichž smysl není jasný, dokud se je člověk nepokusí implementovat nebo aspoň pochopit, jak implementace v hardwaru funguje. Také jsem dost věcí vymýšlel sám s cílem co nejrychleji mít nějak fungující výsledek, místo abych se zdržoval hledáním známých/správných řešení v literatuře (což by byl lepší, ale časově náročnější postup).