Odpověď na názor

Musím souhlasit s Jojioo, že x86 určitě není "funkční a cenově příjemná", ověřená možná je.
x86 je CISC - složitá instrukční sada se stovkami instrukcí. ARM (a např. i MIPS) jsou RISC - redukovaná instrukční sada co obsahuje pouze rozumné minimum instrukcí (tzn. je nenáročná na HW (počet tranzistorů) a tudíž levná a s nízkou spotřebou) a dané instrukce provádí co nejrychleji. RISC tudíž zvládne rychleji zpracovat základní instrukce, ale pak příjde jedna CISCová instrukce a RISC jádro musí stejnou práci rozložit na např. 100 instrukcí.

To rozumné minimum počtu instrukcí je zrovna u ARMu a MIPSu (obojí 32 bitové varianty) tuším okolo 30-40 instrukcí. x86 za ty dlouhé roky povyskočila na několik TISÍC instrukcí.
Už teď je jasné, kde je hlavní problém x86 - obrovský počet (zbytečných, duplicitních i archaických) instrukcí šíleně komplikuje decode stage => tuna zbytečně spotřebované energie a tuna zabraného prostoru.
Ale to není vše. x86 podporuje jakoukoliv délku instrukcí od 1-15B (ale vždy musí být délka násobek Bytů, nemůže mít délku 10 bitů). Takže když dekodér dékóduje instrukci, musí v prvním Bytu přečíst určité bity a z nich zjistit, jak dlouhá je instrukce - ale dekodér nezjistí finální délku, zjistí pouze jestli je délka 1B, 2B nebo 3B+ (tohle je jen příklad, ve skutečnosti to je jinak). Takže dekodér pak musí skočit do 3B a zjistit jak dlouhá ta instrukce je. To opakuje dokud se nedočká finální délky. Hurá, konečně (teprve) jsme zjistili délku instrukce. Teď může dekodér konečně začít zjišťovat délku druhé instrukce a zároveň musí dekódovat tu první - zjistit co to vlastně je za instrukci z těch několika tisíc. Např. jádro Zen je dělané na 6 instrukcí za takt. Teď si vemte, jak šíleně komplikovaný musí být decode stage, aby během každého cyklu zvládli dekódovat 6 instrukcí. A navíc to nejde ani paralelizovat - nelze dekódovat druhou instrukci dokud se nezná délka první. To samé třetí a čtvrtá instrukce.

Instrukce ARM a MIPS jsou dlouhé 32b. Všechny. Tudíž jde dekódování jednoduše paralelizovat, protože předem známe délku všech instrukcí. Ale ona ta paralelizace není ani zas tak potřeba, když je nutné vybrat jen z 30-40 instrukcí.

A tohle je jen jeden z mnoha problémů 50 let staré (!!!) x86. AMD a Intel (a VIA a Cyrix) kolikrát přidávají/li úplně zbytečné nebo duplicitní instrukce, Intel několikrát přidal instrukce se stejnou opcode jako používala už konkurence pro jinou instrukci - konkurence pak musela implementovat speciální módy, kdy při módu x daná opcode znamená instrukci A a při módu y je to instrukce B. Celá ta instrukční sada je roztříštěná, je v ní doslova bordel a má kořeny v 50 let starém procesoru.

Kdyby se vytvořila nová instrukční sada, která by byla správně regulovaná (tj. všechny nové instrukce by byly zhodnoceny odbornou porotou/komunitou a až pak přidány /zavrhnuty) povyskočil by výkon minimálně na dvojnásobek oproti dnešním x86 CPU. O něco takové se snaží Forwardcom.

Tudíž se určitě nedá říct, že by x86 byla funkční a levná. Je drahá, protože jen decode stage může být 10x (i mnohem víc krát) větší než u RISCU (nebo normálního nezpackaného CISCU).