To EXTEND a registr T mě dostalo :-) Jsme RISC, ale pššt děláme to stejně jako CISC :-)
btw: Co se týká konfliktů a závislosti instrukcí na sobě kvůli příznakům v kapitole 10., tak už jsem to vysvětloval 2x že zde problém není. Spíše to vypadá na nechuť tvůrců zavádět extra registr a k němu extra instrukce. Některé RISC to bez problémů mají odjakživa: http://www.atmel.com/images/atmel-0856-avr-instruction-set-manual.pdf
Na jednu stranu máš pravdu v tom, že se ty "komprimované" ISA už podobají některým jednodušším CISC, ale zrovna ten registr T mi připadne jako dobré řešení, protože už as neměli dost bitů na zakódování výsledků operace, tak tam prostě natvrdo dali nějaký registr, který "čirou náhodou" :D dostal jméno T.
Ony stejně hádky RISC/CISC nemají moc význam dneska, kdy každý CPU je stejně nějaký hybrid. CISCy si z RISCů vzaly hodně (branch predictory například), RISCy z CISCů samozřejmě taky, pár firem vyrábějících CPU zbohatlo, tu kvůli náhodě, tu kvůli kvalitě výrobků, většinou ale kvůli něčemu jinému (Intel and IBM, to kvůli interním pravidlům velké modré, ne proto, že 8088 je dobrej čip, to není a nikdy nebyl).
No já si docela živě představuju, že když dělali RISC-I a pak MIPS, tak začínali skutečně od nuly a přidávali do CPU jen skutečně ty nutné věci. Takže nakonec na příznaky nedošlo, protože minimálně MIPS I/II má pouze porovnání obsahu dvou registrů + skok při rovnosti či nerovnosti (toto porovnání je jednodušší a čistě teoreticky i rychlejší než CMP alias SUB -> R0, prakticky je to asi jedno, protože jediné CPU, které počítají s kratším cyklem, než má ALU, dělal jen Chuck Moore). No a potom už si s tím +- vystačili.
U ARM začali z jiné strany, tam naopak příznaky mají velký význam, minimálně v původní ARM ISA. Dnes se provádění prakticky libovolné instrukce na základě příznaků až tak nepoužívá, ale když ARM začínal, tak to bylo hodně úspěšné (ostatně i autorka ARM nám říkala, že v minulosti to byl skvělej nápad, ale dneska jsme někde jinde, proto taky Thumb-2 a AArch64 je v některých ohledech taky trošku CISCovej :-)
Jinak jeste Vam tam chybi TriCore :), ktery se od cca roku 2010 pouziva v automotive i jinde v prumyslu.
V automotive to bylo tak, ze treba u rizeni benzinovych motoru delal Bosch jednotky nejprve s i8051 nebo i196 (M1.x, M5.x, apod.), nasledovaly ME7.x, ty mely Siemens/Infineon C166. Potom ME9 s PowerPC (Freescale MPC5xxx). Dnes se pouzivaji ME(V/D) 17 s TriCore. Jak to slo po letech se da vycist napr na http://obdtester.com/cz/bimcom-eculist/bmw/7
Je zvlastni, jak to rizeni motoru v automotive neni vubec dotceno ARMy.
Diky za zajimavy clanek. Mam otazku:
Pokud EXTEND pouziva zachytny registr v dekoderu instrukci, co se stane kdyz mezi EXTEND a nasledujici instrukci prijde preruseni v jehoz kodu se tez nachazi instrukce EXTEND?
Prijde mi ze by EXTEND melo zakazovat preruseni pred dalsi instrukci, nebo by musel ten zachytny registr byt soucasti kontextu CPU.
Jeste mi prijdou zajimave instrukce SAVE a RESTORE. Skoda ze nejsou trochu vic rozvedene... Ukladaji vsechny registry, nebo jen ty pristupne v 16bit modu, nebo si muzu nejak vybrat ktere z nich se ulozi?