Vlákno názorů k článku Čtyřicet let existence architektury 386: revoluce přinesla Doom a Linux od cc - Podle mě dnes už nemá cenu mluvit o...
-
Podle mě dnes už nemá cenu mluvit o CISC vs RISC. Celé je to jen "frontend" a CPU si stejně všechno rozloží na uops. Co se týče rozšíření a různých extensions CPU jsou dnes prostě super komplexní - stačí porovnat instrukce x86 a třeba aarch64, když tomu přidáme SVE a SME tak se dostáváme na celkem srovnatelnou komplexitu. X86 má prostě nevýhodu v tom, že dekodér musí číst jednotlivé bajty - já bych to dnes označil za špatný design, ale v době vzniku nikdo nevěděl, že to bude problém za dalších 20 let nebo že ta architektura přežije 4 dekády.
-
Pavel TišnovskýZlatý podporovateljj dneska už se to v mainstreamu slévá (a ARM nikdy nebyl čistý ARM).
To kódování mělo význam v době, kdy byly krátké skoky, každý přechod přes hranici segmentu byl obecně problematický a lidi měli pár MB RAM. Zmenšovalo to velikost kódových sekcí (nechci teď psát segmentů, ať se to neplete). Někde se válí porovnání velikostí binárek pro různé platformy, zkusím to dohledat (z hlavy nedám, jestli to byla procenta nebo desítky procent, ale spíš to budou ty nižší desítky procent).
-
Mikrokodovana bola uz 8088 a dokonca aj nejake o dekadu starsie CISCove procesory. RISC vs CISC ani tak nie je o tom, ci je procesor mikrokodovany alebo nie. Skor ide o to, ako komplexny "frontend" ma.
Z toho sa potom odvodzuje, ako zlozity musi byt engine, ktory mikrokod interpretuje a vsetko sa stava nasobne zlozitejsie.
Tradicnym problemom je napr. podpora komplexnych adresovacich rezimov, ktore zvacsuju dlzku zvonku viditelnej pipeline a predlzuju latenciu instrukcie. RISCy spravidla inklinuju k load-store architekture, kde tento problem odpada. Vsetka komplexnost adresovacich rezimov sa sustredi na instrukcie load a store a zvysok instrukcnej sady pracuje cisto s registrami.
Takze, presnejsie rozdelenie by asi bolo nie CISC vs. RISC ale architektury s lubovolnym pristupom do pamate vs. LOAD/STORE architektury.
-
Rozlišovat to na load/store je sice zajímavé, ale taky to nemá moc smysl.
V případě x86 se jedná v podstatě jen o "kompresi" - store s nějakou operací jsou jen legacy instrukce (ADD, SUB, atd...), které se používají s lock prefixem pro atomické operace, a ostatní instrukce jsou operace + volicelný load - v případě x86 je to nutnost kvůli tomu, že počet registrů byl historicky hodně omezený, i v případě x86_64.
Atomické operace jsou v tomto kontextu zajímavé, protože rozbíjí ten koncept "load/store" architektury - jedná se vždicky o load, op, a store, a pokud architektura umožňuje implementaci lock/free algoritmů, tak potřebuje i pair operace popř něco jako cmpxchg16b, což tu architekturu dál komplikuje.
No a teď pojďme třeba na aarch64 a MOPS rozšíření, které v podstatě implementuje něco podobného jako REP MOVSB v x86 - prostě primitiva pro memcpy a memset, atd...
Takže, můj názor zůstává - toto rozdělování architektur dnes už nedává smysl. Moderní architektury konvergujou k nějakému designu a to jak jsou věci zakódované je hlavně problém frontendu. AArch64 je třeba značně omezený, ale jen proto, protože ty instrukce mají omezenou velikost. Ale taky umí třeba komplexní adresování [base + index * N] kvůli tomu, aby to byla praktická ISA.
-
Ten frontend má ale vliv na složitost dekodéru instrukcí. Aby uměl dekódovat více instrukcí za cykl, tak u RISC roste počet tranzistorů lineárně a u CISC exponenciálně. Proto Apple Silicon a Qualcomm Snapdragon X Elite dekódují 8 instrukcí za cykl a Intel a AMD se zasekly na 4 instrukcích (v inner loop je cachování napodobující 6 instr. / cykl).
-
Pavel TišnovskýZlatý podporovatel
Taky to v důsledku znamená, že se (při instrukcích s RISCovou strukturou) nemusí řešit výpadky stránky uprostřed instrukce (při jejím načítání), adresy skoků jsou o 1-2 bity kratší atd. Ty kratší adresy sice vypadají jako maličkost, ale v omezeném prostoru (32 bitů) pro instrukce to znamená, že skoky nemusí zabrat tolik prostoru (polovinu nebo čtvrtinu).
-
Ano, všechny tyhle věci zjednodušují omáčku okolo samotných výpočetních jednotek. Pro zajímavost, Qualcomm Snapdragon X Elite má poloviční plochu co odpovídající Intel pro laptopy (nicméně je na o trošku novější generaci u TSMC). A přitom i v emulaci x86 má o něco větší výkon jak tehdejší Intel (emulace je cca na 2/3 nativního výkonu; Intelu dost škodí/lo, že se v tenkém laptopu přehřívá a omezuje "turbo frekvenci"). Apple a AMD byly už tehdy výkonnější procesory (tj. stále existoval nějaký x86, který byl lepší než ARM) a Intel od té doby taky pokročil, nicméně Qualcomm nelení ("Qualcomm pro X2 Elite slibuje výkon 75 % nad konkurencí").
-
Intel bych za referenci, pokud jde o plochu čipu / jádra u AMD64 asi nebral. Už Jim Keller opatrně mluvil o tom, že mají problém se SW nástroji na design rozložení čipu + si Core nejspíš táhne balast z minulosti. Zen od AMD je v tomhle designovaný líp a ostatně i Atom mikroarchitektura od Intelu je efektivnější, pokud jde o vyžití plochy křemíku.
Jinak nejde jen o tenké laptopy. Nízká efektivita Core je problém i při implementaci AVX-512, kdy když kód chce provádět dané operace, zvedne se odběr a klesne frekvence. Člověk tak musí sakra benchmarkovat, jestli se mu AVX-512 v daném případě vyplatí. Zen má v tomhle bezproblémovější implementaci.
-
Ano, již v původním komentáři jsem uvedl, že přestože Qualcomm byl lehce výkonnější i v x86 operacích než Intel, tak AMD bylo i tak výkonnější, se všemi omezeními architektury x86. Určitě bylo méně efektivní než Qualcomm, ale ne o tolik, aby se nezvládlo uchladit a muselo omezovat výkon. Tedy stále jde udělat plně konkurenceschopný x86, i když nůžky podmínek pro to, aby to šlo, se budou dále rozevírat.
-
To je otázka. O neefektivitě x86 a lepších vlastnostech nativních load-store architektur, čtu v podstatě od doby, co jsem na netu. Mezitím x86 (respektive AMD64) zvládla téměř vytlačit RISCy z velkého železa a udržet si postavení v rámci PC světa. I kapitolka s Applem byla spíš dočasná věc (Apple typicky drží další architekturu v záloze, takže prokazatelně nejpozději v roce 2011 existovaly buildy macOS pro ARM, konkrétně tehdy A5).
Fakt si netroufám předvídat, kam až AMD64 půjde škálovat. x86 přežila svoji smrt tolikrát, že odmítám dělat predikce, neb budou zcela určitě špatně. :-D
-
Dlouho x86 těžilo z lepšího výrobního procesu v továrnách Intelu. Ten smazal problém s výkonem na počet tranzistorů i spotřebu. Taktéž se do x86 investovalo mnohem více peněz, i na straně aplikací, které pro něj optimalizovaly primárně (na ostatních arch. stačilo, že to běželo). Teď už je výrobní proces stejný (TSMC) a obdivuju AMD, že to stále zvládá. Intel to už vzdal, přišel i o "berličky" v podobě HT a AVX-512, které ve vybraných úlohách smažou negativa architektury a bottleneckem jsou samotné výpočetní jednotky a jejich výkon.
-
Jo, první implementace AVX-512 od Intelu byla katastrofa, ale Intel to velmi brzy vyřešil - už IceLake s tím nemá nějaký viditelný problém a všechno to co přišlo po IceLake tím netrpí. A vzhledem k tomu, že Intel díky jeho problémům opustil AVX-512 v consumer segmentu tak nějaké podtaktování při použití AVX-512 stejně nemá cenu řešit (na serverech to problém není a na desktopu lidi co používají Intel AVX-512 nemají, no a AMD tím netrpí).
AMD zase muselo ukázat Intelu, jak se to dělá :-D
7. 10. 2025, 22:11 editováno autorem komentáře
-
Tak Apple tam měl spíš investici, ne? Nebo nevím o tom, že by dodávali do ARM nějaké reálné R&D. Jestli k tomu něco máš, rád si přečtu. Ostatně i jejich polovodičová divize je vlastně P. A. Semi, co koupili, když se na ně vykašlal Intel, pokud šlo o SoC pro iPhone (přitom sám Intel se na vývoji ARMu též podílel, dokonce na StrongARM měl nějaké produkty pro routery, jestli si pamatuju dobře) a se Samsungem byl zase problém v koordinaci.
Dodnes si myslím, že rozhodnutí k nákupu P. A. Semi bylo nejlepší věcí, co Steve Jobs udělal. Jestli v něčem dneska Apple exceluje, je to právě návrh vlastních mikroarchitektur. Nejen, že mají vysokou efektivitu a vysoký výkon v single-core, ale velká cache + skutečně unifikovaná paměť umožňuje jet některé výpočty + inferenci ML velice efektivně i na relativně dostupných strojích.
-
AArch64 je jen pokračování ARM architektury - ze všech nesmyslů v původní architektuře se poučili a udělali celkem rozumnou architekturu, tedy až na ten 64-bit SIMD - to asi kvůli kompatibilitě s původním ARMem no, a zaneřádili si díky tomu hodně velký prostor, který by mohl být vhodný pro budoucí rozšíření. SVE nepovažuju za něco dobrého, je to spíš kompromis aby i AArch64 mohl mít 512-bit registry někdy v budoucnu.
-
Je to pokračování architektury, když s ní není kompatibilní? Jakmile v nových SoC zmizela malá 32/64bit jádra, tak už 32bit aplikaci nespustíte (velká jádra už delší dobu jsou 64bit only). Když to přeženu, tak RISC-V je pokračování MIPS architektury (sama firma MIPS to říká - nemá smysl pro ní vymýšlet novou major verzi MIPS, když tu máme RISC-V, a ten vychází z myšlenek MIPSu).
7. 10. 2025, 22:01 editováno autorem komentáře
-
Ano je - x86_64 je taky pokračování x86 architektury a není tam kompatibilita (x86_64 instrukce sice mají stejný základ, ale relativní adresování, REX prefix, atd... to jsou všechno novinky, které v 32-bit x86 nejsou a nikdy nebudou). Nové věci jako třeba AMX, APX, ty v 32-bit nejsou ani definované (neexistujou).
No a aarch64 je na tom stejně - předělali původní ARM tak, aby to dávalo smysl. Konvence, instrukce, atd... jsou inspirované původním ARMem, ale jsou tam i změny. Kdyby člověk porovnal ale třeba kódování, flagy, atd... je tam hodně věcí stejných, trochu posunutých, atd...
V případě x86 ta 32-bit kompatibilita byla tak nějak historická. U ARMu to je podle mě jedno a tu kompatibilitu prostě moc lidí nepotřebuje - mobily, Apple Silicon, atd... tam je prostě 32-bit už nedává smysl a je úspornější CPU navrhnout bez 32-bit režimu. Ale třeba na Raspberry PI je možné nainstalovat 64-bit OS (aarch64) a spustit na něm nativně ARM32 binárky, tak jak je to běžné u x86.
Co se týče RISC-V tak tam nesouhlasím - sice se inspirovali MIPSem, ale to kódování atd, to je nové a nevychází z něj. Třeba takový Loongarch má s MIPSem společného víc než RISC-V.
-
Souhlasím, že RISC-V se hodně od MIPSu liší a MIPS si spíš jen připisuje ne až tak oprávněné body. Na druhou stranu RISC-V vyvíjel Krste Asanović na Berkeley pod prof. Pattersonem, ale je blíže MIPSu od prof. Hennessyho, než RISC-I, II a SPARC, které v osmdesátých letech navrhl prof. Patterson se svými studenty. Takže v tom zase má MIPS pravdu, že dali tentokrát přednost jednoduchosti a nekomplikovali návrh registrovými okny a podobně.
-
Asi trochu hloupá otázka, ale když tak čtu diskuse o různých architekturách, tak existuje něco jako ideální CPU? Protože všechny musejí počítat minimálně logické operace, někdo po jednom a někdo třeba po 512 (a to nemluvím o FPGA), potom se řeší jestli má mít operace 1T nebo je to jedno (potom je tam ale více malých operací za sebou), paralelní zpracování instrukcí (HyperThreading) apod.
Není to nakonec jednak jedno, ale také hlavně o použití daného procesoru? Ono totiž nakonec si stačí koupit FPGA a syntetizovat tam masivně paralelně jednu funkci a můžu mít klidně 1024 vstupů a 1024 výstupů za konstantní čas bez ohledu na délku. Do toho různé signálové procesory a naopak pro mě je výhodné mít co nejvíce klidně pomalejších jader, protože mám dost souborů a je potřeba je zpracovat paralelně a tím získat celkový výkon.
Do toho samozřejmě bude vstupovat i cena, protože IBM dělal CPU s hromadou jader tím způsobem, jako dneska AMD, tedy malé levné chiplety, kterých byla na sběrnici hromada.
-
Pavel TišnovskýZlatý podporovatel
jj to se vracíme zpátky k pojmu RISC. Protože kdysi to označovalo CPU se stejně dlouhými instrukcemi, LOAD-STORE architekturu a velkým počtem pracovních registrů - tedy vlastně přesný opak 386ky :-). Už ani Thumb (16) do této kategorie nespadá, ale všechny první a druhé generace RISCů jsou v tomto ohledu prakticky totožné.
Takže kolega cc má pravdu, dneska je to takové fuzzy rozdělení.
-
Intel sa na styroch instrukciach za cyklus zasekol nie kvoli tomu, ze su tie instrukcie zlozite. Dekoder instrukcii je v idealnom pripade blba kombinacna logika. Problem Intelackeho formatu instrukcii je, ze je - kulantne a strucne povedane - strasne debilny. Je totiz variable length a dlzka instrukcie sa da zistit az po jej uplnom dekodovani. Ona totiz instrukcna sada 8086 nikdy nebola stavana na tak masivnu rozsiritelnost, aku zazila.
Napr. mozu mat instrukcie prefixy a skoro kazda instrukcia ma ako zdroj alebo ciel moznost zadat tzv. EA - effective address. To je vyraz variabilnej dlzky, ktory urcuje nepriame adresovanie operandu v pamati.
To sposobuje, ze moze mat instrukcia skrz ten operand roznu dlzku a zaroven este ma aj roznu latenciu pri vykonani. Typicky u Intelu je latencia instrukcii zapisovana ako X + LEA, kde X je konstantny pocet taktov procesora a LEA je vzorec, ktory urcuje dodatocne takty CPU podla toho, co je v operande pre pristup do pamate.
-
Ano, je to kombinace vice problemu. Jen doplnim, ze v SIMD operacich, zvlaste pak AVX-512, se protlaci "vice prace" skrz dekoder. Ale ne vsechno je vektorove/maticove. Napr. vykonani skriptu ve webove strance je obri balast skalarnich operaci. Dale v multithread (MT) je v AMD hyperthreading (HT), tedy 2 dekodery vedle sebe pro jedno jadro.
-
A zase tu máme RISC a CISC. ARM měl být RISC, ale co třeba ARM vs Thumb? 2 ISA v jedné architektuře? Jedna dokonce variable length? Je to RISC nebo CISC? A nebo to nemá cenu rozlišovat?
Třeba takový RISC-V, který to RISC má přímo v názvu může mít 16-bit i 32-bit instrukce, což opět komplikuje decoder, který bude asi složitější než takový decoder aarch64, který prostě vezme 32-bitů a může dekódovat. Je to RISC a nebo CISC?
Frontend je prostě frontend a pokud si CPU chce zachovat kompatibilitu (což většina chce), tak i ten frontend do budoucna nabobtná. X86 má prostě smůlu v tom, že to je byte-by-byte, což je úplně naprd. Ale to přece nemá nic společného s CISC vs RISC, je to jen debilně navržené kódování.
Kdyby teď někdo přišel s tím, že by navrhnul lepší kódování pro x86, co by mělo fixní instrukce třeba 32 bitů (nebo 32 a 64 bitů), tak by to pořád byla ta stejná architektura, jen by se vyměnil dekodér.
-
Pro zajímavost, ARM měl vedle Thumb ještě Javovou instrukční sadu. Používalo se to v tlačítkových mobilech, když byly aktuální. Ta mobilní Java pak běžela asi na 70 % nativního výkonu procesoru, což v dřevních dobách, kdy nebyl JIT a výkon na něj, bylo skvělý. Nicméně si za to ARM nechal platit tučnou licenci a mezitím vzniklo JIT, takže pak už to výrobci telefonů nelicencovali a ARM tu ISA vyhodil. Nějakou dobu licencoval ještě softwarovou emulaci té ISA, aby systémy využívající ji fungovaly na nových SoC bez ní. S JIT to běželo na 60 % nativního výkonu, takže skoro stejně a mezitím vzrostl i hrubý výkon CPU. Podobně Apple Silicon nemá Thumb, tedy má všechny instrukce stejně dlouhé.
-
Ona taka nejaka aktivita od Intelu relativne nedavno prisla. Volali to x86s alebo ako.
Malo to riesit ti najviac strasne legacy veci v x86tke, ako boot do realneho 16bitoveho rezimu a vyhadzanie niektorych velmi zriedkavo pouzivanych instrukcii (kto ste kedy pouzili AAA?).
Udajne za to z trhu dostali strasneho sprda.
-
Pavel TišnovskýZlatý podporovatel
Jj AAA a spol. zbytečně zasekaly poměrně velkou část prostoru pro kódy instrukcí a v praxi se to asi vůbec nepoužívalo (a ani si neuvědomuju, jak to napsat třeba v C, aby to překladač použil).
Boot v 16bitovém režimu (a asi i s A20 GATE - to je taky pěkná historičnost) s námi je až nechutně dlouho.
-
Nemyslim si, ze tieto instrukcie v C pouzit ide. Mozno nejaky velmi optimalizujuci prekladac by dokazal vycitit, ze tie bitove testy a modifikacie, ktore program robi su prave tieto instrukcie.
Vzhladom k tomu, ze je to ale niche vlastnost x86 si nemyslim, ze to akykolvek optimizer implementovane ma. Mozno tak starsie verzie MSVC to maju v backende. Tam si to vzhladom k jednostrannemu zameraniu na x86 a AMD64 mohli dovolit a jeho backend generoval uz davno celkom slusny vystup.
