Vlákno názorů k článku RISCová architektura PowerPC od klokan - Díky, zajímavý článek jako vždycky od Pavla. Jenom...

No ono to je s x86-64 složitější. Architektura je to jasně CISCová, ale její implementace od AMD i Intelu jsou vnitřně RISCové a těmto RISCovým jádrům je předřazen dekodér instrukcí, který x86-64 kód převádí pro to RISCové CPU uvnitř. U AMD by to mělo být už od K5 procesor AMD 29000 pokud mě paměť neklame. U Intelu to je tuším od Pentium Pro, ale nevím co to je uvnitř zač a ani nevím, jestli se to dá někde dočíst.

A to já bych zase nepřikládal takovou váhu tomu, jestli jde o RISC nebo CISC, protože to se ve finále na designu projeví jenom velikostí programu a rychlostí, mimo ASM to člověk nevidí av C to většinou schová kompilátor.

Zásadnější dělení vidím mezi von Neumannem a Harvardem. A to proto, že:
1. Harvard má často jinou šířku datové a instrukční sběrnice a je potřeba v SW zohlednit alignment. Prosákne to celou aplikací i Cčkem (PIC, AVR,...).
2. Harvard většinou nedokáže běžet z RAMky, to je potřeba vědět třeba při návrhu bootloaderu, dynamicky natahovaných rutin z vnější paměti (nutnost interpreteru) apod.
3. U harvardu je třeba explicitně volit, jestli konstanty budou ve FLASH s programem, nebo někde v datové oblasti. V prvním případě se můžou objevit dvě verze jedné rutiny s jinou třídou pointeru v argumentu, ale nachlup stejný, v to druhým... Zkusili jste takto zobrazovat na displeji hlášky celkové velikosti 8kB jednočipu s 4kB RAM?

Takže tyhle rozdíly jsou z pohledu aplikace o hodně zásadnější a dotýkají se architektury celýho systému podstatně víc, než RISC/CISC.

Pokud se nemýlím, DSP M56000 byl Harvard, ne? Když jsem si jako kluk zkoušel hrát s assemblerem na Atari Falconu, nemohl jsem tehdy pochopit, proč to udělali tak "blbě", že DSP měl svou vlastní malou paměť, místo aby pracoval rovnou v RAM :D

Když je řeč o instrukční sadě neboli externí architektuře, tak mám za to, že amd64 je jednoznačně CISC, MIPS je čirý RISC, moderní ARM tak něco mezi a POWER je... prostě IBM :) Z hlediska aplikací (tj. hustota kódu, LOAD/STORE nebo operace rovnou z/do paměti atd...) se tyhle procesory prostě tak jeví, celkem bez ohledu na to, co je uvnitř.

Jinak je pravda, že K5 byl ve skutečnosti AMD29K schovaný za dekodérem instrukcí. U Intelu je to tak od PPro, ale cosi podobného, byť v mnohem primitivnější prodobě, bylo už u 486. Vzpomínám si, že v manuálu ho vychvalovali jako "RISC Processor" (RISC byl tehdy buzzword).

Ale zdaleka to není specifika Intel/AMD. Stejný princip už drahnou dobu používá POWER a dneska i Cortexy od ARM, takže na otázce RISC/CISC se tím nic nemění (tedy pokud na tom vůbec záleží). Absolutně netuším, jak ta jádra vypadají, je to ostatně dost zajímavé téma, ale u ARM bych čekal pravděpodobně nějaký hodně jednoduchý RISC a u procesorů z hyperthreadingem, tj. Intel, AMD a POWER, bych to viděl spíš na něco typu VLIW. Představuju si, že dekodér/překladač instrukcí čte instrukce paralelně ze dvou nebo osmi vláken a přeložené je pak láduje do odpovídajících instrukčních slotů VLIW kódu... ale možná se pletu a ve skutečnosti to třeba funguje úplně jinak.

Když se to tak vezme, nebylo by vlastně vůbec nelogické, aby Xeon a Itanic měli uvnitř stejné nebo velmi podobné jádro.

VLIW se ukázalo jako neprůchozí tam, kde je nutné generovat kód staticky (tj. překladačem), protože ani ten nejlepší kompiler nemůže provádět optimalizace, které by se v důsledku rovnaly problému zastavení Turingova stroje. Něco jiného je ale, pokud se má kód generovat dynamicky z několika nezávislých paralelních instrukčních toků a s průběžnými informacemi o stavu jednotlivých pipelinů. Tady nevidím důvod, proč by to v zásadě nešlo. Tím nechci říct, že to tak nutně je v případě existujícího hyperthreadingu, ale jako princip mi to připadá rozumné.

Vícero elementárních jednotek má každý superskalární procesor. Mě by zajímalo, jestli je v případě hyperthreadingu dekodér dokáže současně krmit instrukcemi z různých paralelních vláken.

Jinak VLIW byl propadák u staticky generovaného kódu (až se divím, že to někomu připadalo jako dobrý nápad) ale u dynamického výstupu z dekodéru, což je v podstatě zadrátovaný JIT, se to tak zle nejeví. Aby bylo jasno: netvrdím, že to tak funguje, ani, že by to tak bylo nutně dobře. Jenom mi to přišlo jako jeden možný přístup.

Kromě DSP VLIW ještě používá pár mikrokontrolérů a GPU. Tuším, že některé radeony jsou nebo byly VLIW. No a samozřejmě tu pořád ještě máme Itanium. Dlouho jsem si myslel, že není nic horšího, než staré x86 v reálném režimu, až jsem jednou měl tu "čest" psát pár rutin v assembleru IA64...

Což o to, Itanic se potápí už hezkou dobu. Pokud si pamatuji, tahle přezdívka se objevila sotva pár dní poté, co HP a Intel slavnostně oznámili značku Itanium - což mimochodem mluví samo za sebe... Enterprise distra ho už opustili (RHEL od verze 6, Ubuntu server už před tím, jinak nevím), ale nejsou samy, MS zařízl podporu ve Windows Server 2012 a i Oracle před lety oznámil, že se s ním už nebude zdržovat, za čež pak musel Intelu zaplatit odškodné... Jinak na něm fungovalo ještě OpenVMS (to pro změnu zase nefungovalo na ničem jiném), ale i tomu už je odzvoněno.

Ta idea je přesně tak, RISC nebo CISC kód v několika threadech, konkrétně dvou (Intel) nebo osmi (POWER). Dekodér ho přeloží a odešle do front, odkud se pak jednotlivé instrukce nacpou do příslušných slotů VLIW kódu, např. 2xALU + 1xMEM, podle toho, v kterých pipelinech je volno a jaké instrukce jsou zrovna připravené k běhu. Přejmenování registrů se v každém případě děje tak jako tak pokud má CPU umět spekulativní exekuci nebo exekuci mimo pořadí. Např. Intel ho používá už od Pentium Pro (ten má konkrétně 128 fyzických registrů, různě namapovaných na osm logických registrů architektury x86, u každé instrukce jinak).