Názory k článku
Procesory s architekturou RISC v pracovních stanicích a serverech

V cem se lisi scitani signed od scitani unsigned? Jeste bych to chapal u te konstanty (add by ji a nejprve znamenkove rozsiril na 32 bitu a pak teprv pricicetl), ale kdyz se scitaji registry tak je to (u 2jkoveho doplnku) totez.

Skutecnost ze MIPS 2000 nemel flagy a to zejmena carry asi dost komplikovala tvorbu rutin pro dlouhou aritmetiku.....

Jinak dik za clanek a uz se tesim na popis RISCOSu.

Zrovna nad tím carry jsem dumal taky. To se jako po sečtení kontrolovalo, zdali výsledek není menší než jeden ze sčítanců? Nebo je na to nějaký jiný fígl?

Pri preteceni se generuje Trap (interupt) - ve vsech aritmetickejch instrukcich je jeden bit (v ty casti na konci) kde se voli jestli se bude ignorovat, nebo se pouzije

Co se týče celočíselné aritmetiky, tak varianty bez U (add/addi) při přetečení znaménkové aritmetiky ve dvojkovém doplňku (výsled je mimo rozsah -0x80000000,+0­X7FFFFFFF) dojde k vyvolání výjimky. U instrukcí addu a addiu dochází k běžnému tichému přetečení/omezení modulo aritmetiky. Určitou kuriozitou je, že i pro addiu se přímý operand rozšiřuje znaménkově. Jména s U tedy jen vyjadřují vztah k výjimkám a přímo implementace s tímto používáním počítají.

Zajímavostí je, že se nakonec kvůli přenositelnosti kódu ani v C kompilátoru (GCC) na MIPSu i pro celočíselnou aritmetiku triktně používají variantu s U a zajímavá vlastnost architektury k odhalení runtime chyb s přetečením není využita. Dokonce i při volbě mips-elf-gcc -ftrapv GCC-4.4.4 nevygeneruje místo instrukce add volání __addvsi3, které provádí kontrolu a případně volá abort. Je to docela škoda.

Co se týče přetékaní ve znaménkové aritmetice, tak norma C přímo říká, že pro signed čísla není chování definované => výjimka by tedy nebyla problém.

Zajímavé informace o chybách (např. i mylnými předpoklady o přetékání znaménkové aritmetiky) v SW spůsobených v současné době agresivnějšími optimalizacemi v LLVM jsou v článku

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

Co se týče MIPSu, tak popis jak použít sice starý, ale pro pochopení myšlení autorů nedocenitelný, nástroj MipsIT najdete na stránkách k našemu předmětu

https://edux.feld.cvut.cz/courses/A0B36APO/tutorials/03/start

MipsIT je bohužel z Linuxu použitelný jen přes Wine, ale řetezce pro kompilaci kódu spustitelného v MipsIT jsme připravili i pro Linux.

Vím, že to tu není inzerce, ale kdyby chtěl někdo SGI Octane II. s 2x600MHz CPU a cca 2G RAM a 26" trinitronem je k mání a ZADARMO (tedy za podmínky, že si jej někdo snese z 2. patra a odveze z Pardubic).
Je na něm origo Irix a všechno bez problémů maká. Je mi ho chudáka líto, ale nemám na něj čas ani využití

Já se hlásím!

alex(zavináč) post (tečka) cz

S radostou si ho zoberiem: linker at inmail dot sk :)

ahoj, zatím jsme na dnes večer domluveni s Alexem. Když si pro něj nepřijde, tak dám zítra vědět.

Napis si me jako dalsiho do fronty, snad mnou najaty ostrelovac odvede dobrou praci a Octane bude muj! :-) jo email je vykook na gmailu a samozrejme com na konec ;-)

Tak octánek už má nového majitele. Jsem rád, že někomu poslouží

Panove, provozujeme jeden Onyx 2 u vojaku na leteckem simulatoru, nemaji penize na to aby se to vymenilo. Odesly nam tam nejake vetraky a SGI chce nechutne penize za vymenu. Octane II je vice mene to same, je tu nekdo kdo by byl ochotny tyto dily prodat? Jako bonus je mozna navsteva simulatoru u vojaku.

Kdybych uz 2 nemel, tak bych ho bral vsema deseti. To jsou paradni masiny. Kdyby se jo nikdo nenasel a fakt by se mel vyhodit, tak prosim napis na "vtech at volny d0t seezed".

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).