Názor k článku Čtyřicet let existence oslavované i nenáviděné platformy PC od kvr kvr - To by si příliš nepomohli. Bez ohledu na...

To by si příliš nepomohli. Bez ohledu na to, že je dneska už k ničemu, tak ta podpora pro real mode až tak moc nezabírá, pro 32-bit to nejspíš taky nebude takový rozdíl, vzhledem k omezenému počtu registrů i instrukcí a v zásadě poměrně obsáhlé dopředné kompatibilitě k dnešní x86_64. To, že se část instrukcí nepoužívá, část má nejspíš nějaký překryv a část se dá zakódovat kratší variantou s nějakými registry než jinými, nemá asi větší význam, kromě toho, že to mírně komplikuje kompilátor a dekódování v procesoru. 32-bit určitě neběží výrazně pomaleji než 64-bit, tak instrukční sada je v zásadě stejná (respektive jen rozšířená). U 16-bit si nejsem jistý, ale i kdyby se to emulovalo software, tak se asi nic tragického nestane (ostatně, svého času se musely opravovat knihovny pro Turbo Pascal, protože v době vývoje se nečekalo, že by procesor mohl běžet tak rychle).

Nicméně, ukončit by to asi šlo. Jak ukázal Apple a Rosetta 2, s rozumnou architekturou a defakto JIT se dá emulace udělat poměrně dobře udělat softwarově, s nepříliš výraznou ztrátou výkonu (i kdyby byla poloviční, tak to u zastaralých 32-bit aplikací nikoho nebude extra dráždit).

Problém x86 (a x86_64) je ale ta zpětná kompatibilita, která se stále drží na úrovni ISA. Když to navrhli na začátku, tak to nějak dávalo smysl, s omezeními, které byly dány dobou a cenou (i když, jak ukazují jiné příklady, šlo to určitě udělat líp). S osmi registry (spíše s bídou s šesti) a malou cache ten CISC dával v zásadě smysl, bo většina operací vyžadovala práci s pamětí. Měli slušnou code density, nízkou cenu atd. Dokonce bych jim ani nevyčítal ty segmenty - postupem to sice bylo peklo, ale původně asi počítali s tím, že všechny objekty budou v rámci 16-bitového prostoru a segmenty tak umožňovaly jednoduchou adresaci při omezení designu na 16-bitové registry. Jenže, časem se rozšiřovalo a ISA se hackovala, až do 64 bitů, kde velká část instrukcí vyžaduje nějaký prefix či dokonce víc, aby fungovala se správnými operandy. To celkem fungovalo u jednoduchého procesoru před 40-ti lety, ale u dnešních superscalar to už značně komplikuje instruction decoder. Ten sice opět nezabírá velkou část procesoru, ale schopnost číst instrukce paralelně v podstatě plýtvá energií, brzdí zbytek pipeline a dekódovat víc než několik kusů najednou je pro CPU sázka do loterie. Podobně je to s code density - většina původně designovaných instrukcí se defakto nepoužívá, bo CPU už má dost registrů, takže většina instrukcí je defakto v kategorii RISC. Navíc jsou zbytečně delší, protože velkou část ISA prostoru zabírají ty, které už nejsou využívané. Jako obvykle platí, že čím vyšší aplikační vrstva, tím lepší znalost má o tom, čeho chce dosáhnout a jaké jsou následky a vztahy s okolními komponentami, takže jsme zpátky v době, kdy je lepší optimalizaci udělat na softwarové úrovni než dělat šílené hacky a kontroly na úrovni CPU. V tomto směru byla Transmeta zcela slepá ulička .

Takže, x86 či x86_64 už nic nezachrání. Intel a AMD to držely dlouho kvůli know-how a patentům, které nikdo neměl, a samozřejmě obrovským investicím, které si mohli dovolit kvůli množství zákazníků. Ale jak to obvykle bývá, svět se časem srovná s tím, jak se technologie a postupy stanou dostupnější - teď máme ARM a dvě open-source architektury, které vznikly s minimem prostředků na univerzitách. Těžko soudit, možná se ARM a RISC-V dostanou časem do podobné situace, až jim třeba dojde prostor v jejich ISA a budou potřebovat rozšiřovat. V té chvíli možná bude opět dobré celou ISA zahodit a vytvořit zcela novou, na základě aktuálních požadavků (spíš si myslím, že se tak v dohledné době nestane, vzhledem k tomu, že ty požadavky jsou do velké míry dány možnostmi napsat na to software a tam se drasticky neposunujeme, s výjimkou různých masivně paralelních architektur apod). V každém případě jsme dneska už v jiné době a jsme schopni to řešit velice efektivně - ať už formou software emulace (respektive kombinace emulace a kompilace) nebo tím, že většina aplikačního SW běží na nějaké VM a nativní kód je obvykle open-source nebo dobře udržovaný a dostupný closed-source (pokud ne, tak je stále možná ta první varianta emulace, ale větší problém je stejně v nebezpečnosti toho software jako takového).

Paradoxně, odhaduju, že x86 (x86_64) definitivně pohřbí Intel. Ta architektura je za zenitem a na limitu, Intel je v ní v této chvíli pozadu a dostat se v ní zpátky na špičku by stálo extrémní peníze, navíc by to bylo Pyrrhovo vítězství, vzhledem k tomu, že ta špička x86_64 je pořád za současnými ARM CPU. IMHO současné plány Intelu (a nejspíš i AMD) směřují buď k ARM nebo spíš RISC-V (bo licence, ale zároveň je taky modernější), které nemají ty nesmyslné 40 let staré omezení a jsou tak lepší k rozvoji. Teoreticky by mohli navrhnout novou vlastní ISA, ale to by bylo obrovské riziko z hlediska podpory kompilátorů, OS, hardware vendorů atd. Se svým know-how budou schopni dotáhnout tu architekturu dál než aktuální svět a můžou pokračovat ve své nadvládě ve světě CPU. Nemají moc na výběr - buď se přizpůsobí evoluci nebo vymřou jako dinosauři. Navíc můžou zkusit využít nějaké své patenty a architekturu nadále vylepšit a blokovat zbytek světa. Což je špatná zpráva, ale z obchodního hlediska dává smysl...