Čistě jenom pro pobavení jsem namaloval (a mobilem vyfotil) obrázek "své představy" procesoru z minulého povídání
Takže jestli jste přestali slzet smíchem tak jenom dodávám, že ten zamračený profesor s nečitelným popiskem nahoře je "Instruction Decoder". Takže jenom pro informaci - buldozer občas nazývaný "bus interface unit" skrývající se pod assemblerovou instrukcí LOAD - hrne zelí na pás, kde roboti - fukční jednotky - jej postutpně zpracovávají na konzervy se segedínským gulášem, který "bus interface unit" - tentokrát reprezentovaná instrukcí STORE - ukládá zpátky do skladiště (paměti) - jak se mají "roboti" hýbat určuje loutkář "instrukční dekodér", který tahá za drátky.
Možná se budete divit, ale ta představa zase není tak absurdní jak se zdá, protože mezi instrukčním dekodérem a výkonnými jednotkami jsou v procesorech opravdu sběrnice s desítkami signálů a spolupráce instruční dekodér - aritmetická jednotka se nápadně podobá výpočtům na kalkulačce, která má taky klidně 60 tlačítek.
Přestavíme - li si že z instrukčního dekodéru vychází taky 60 signálů pak množství kombinací které může dekodér vygenerovat je 2^60. Vzhledem k tomu, že žádá procesorová architektura nemá tolik instrukcí je jasné, že při konstrukci procesoru se postupuje takto :
- Všechny signály nutné pro řízení aritmetických jenotek se vyvedou na nějakou sběrnici (to je těch 60)
- pak se z nich vyberou smysluplné kombinace - které odpovídají použitelným instrukcím
- smysluplné kombinace se očíslují (to jsou kódy instrukcí v paměti)
- čísla instrukcí jsou zároveň adresou paměti instrukčního dekodéru - kde každé slovo má 60 bitů a obsahuje kombinaci signálů nutných pro vykonání dané instrukce
Jasné ? V dnešní RISCové době je to tak jednoduché - v době klasických procesoů CISC to bylo ještě poněkud komplikovanější, protože číslo instrukce bylo vlastně startovací adresou "mikroporgramu" skládajícího se s vnitřních "mikroinstrukcí" které se vykonávaly často mnoho taktů než byla instrukce hotova.
Místo mikroprogramů mají dnes CISC procesory typu 8086 hardwarový překladač, který dělá de - facto to samé, ale "před vraty továrny" takže "za vraty" už je jenom jenotaktový dekodér vnitřních RISC instrukcí - jak jsem popsal. Výhodou "dělání RISC kódu" ještě před instrukčním dekodérem, je to, že pak se dají RISC (mikro) instrukce různě párovat, kombinovat a vysílat do různých funkčních jednotek ALU, CPU, které pracují všechny paralelně a daleko rychleji než CISC procesor s mikrokódem.
Proč mě tak fascinuje ARM - protože u něho ten bod s "očíslováním smysluplných kombinací signálů" neproběhl a tudíž ARM ač RISC tedy Reduced Instruction Set Computer - má tolik kobminací instrukcí, že snad žádná architektura nemá v tak (relativně) skromném hardwaru takové možnosti.
Proč je to důležité - jestli je instrukční kód jednoduchý nebo složitý ?
Pokud máte 35 jednoznačně definovaných instrukcí - psát dobrý program v assmebleru dokáže i programátor blbec nebo kompilátor blbec. Tudíž i programátor kompilátoru - blbec - bude se svým výsledkem produkovat alespoň "standardní" kvalitu kompilovaného kódu.
Naopak pokud máte velice komplexní assembler , kde jedna instrukce dělá tolik operací jako malý podprográmek na jiné architektuře. Viz už zmmiňovaný BICEQ R2, R3, ASL #3 - je otázka generování optimálního kódu velice složitá - a osobně si o programech pro ARM myslím, že krom nějakých intenzivně probádaných procedur u si u ARM assembleru nikdy nemůžete být jisti jestli neexistuje ještě lepší způsob jak danou věc naprogramovat - což platí jak pro lidi tak pro kompilátory. Asi na tom něco bude, protože podle různých informací se rycholost i velikost kódu pro ARM výrazně liší podle kompilátoru nebo dokonce podle verze kompilátoru.
Dnes už opět končíme, zbývá opět jenom tradiční rada pro blondýny : Muži mají jenom dvě emoce - buď jsou nadržení, nebo hladoví, takže pokud ten váš nemá erekci - vařte večeři.
Angelina Jolie
Není naprosto důležité, jestli je jednoduchá nebo složitá sada instrukcí.
Krásně je to vidět na tom ARMu, kde napsat optimální program je velice těžké.
Věci jsou obvykle složitější, než se zdají. Jedno jestli u lidí, nebo v technice. A roli hrají stovky faktorů.
Třeba ten ARM. ARM nedokáže zapsat do registru ani všechny 32bitové konstanty. ARM nedokáže paměťový offset nad určitou hodnotu. Atd. Takže některá čísla se dají zapsat jen nepřímo přes uloženou hodnotu v paměti, jiná přímo. Skok na blízké adresy je efektivnější než na vzdálené, atd. To nemluvím o ptákovinách typu, že adresa instrukce je jiná, než je v instrukčním čítači.
Najít optimální program v ARMu – to snad nedokáže ani bůh, nebo jenom bůh.
Najít optimální program je možné matematickými metodami pro ortogonální instrukční sady. Jestli jde o RISC/CICS nehraje příliš roli.
Jako člověk, který intenzivně psal pro několik procesorů, tak říkám, že pro ARM je snaha psát optimálně hrůza. Dokonce mám odjem, že i Linux několikrát změnil volací konvenci na ARMu, protože najít optimální je téměř nemožné. Zato třeba na CISC x86 procesorech se píše daleko luxusněji a lépe.
---
Nicméně nejejednoušší cesty nejsou vždy nejvýhodnější. Kdyby RISC bylo tak supervýhodný, tak už je CISC dávno zadupán do země, jak se kdysi predikovalo. Ale to se nestalo, namísto toho CISCové procesory drtí RISCové. Jen na zamyšlení, že závěry v článku nejsou moc platné.