Odpověď na názor

1) ALU = Arithmetic Logic Unit
Aritmetická .... protože dělá výpočty
Logická .......... protože rozhoduje podmíněné skoky-větvení

Zastaralé procesory od 8088 až po Intel Raptor Cove mají univerzální ALU (Raptor třeba 5x ALU, kde dvě z nich umí i vyhodnocovat větvení (branch). Stejně to má i Zen 2, který má 4x ALU a dvě z nich umí větvení).

Takže větvení se mezi ALU funkce odjakživa počítá (jinak by to historicky nedávali na ALU jednotky a nijak to v názvu nerozlišovali). To že to ve schématech označují jako "Branch Unit", není proto že by to nebyla ALU funkce, ale protože to nějak musí od ALU odlišit, když je to jednoúčelová jednotka. Navíc některé z těch INT jednotek nastavují flag jestli výsledek odčítání (instrukce CMP) byl menší/větší/roven nule, takže pracují v úzké spolupráci s Branch unit (resp ji krmí svými výsledky, protože v C++ se IF/FOR/WHILE se přeloží do assembleru jako dvojce instrukcí CMP + JMPGT třeba, CMP provede rozdíl dvou čísel a nastaví flag, JMPGT pak skočí tam podle toho co je v GT flagu).

Každopádně hlavní myšlenka je taková, že 4x ALU + 1x Branch v Zen 4 je ekvivalent 5x ALU v Raptor Cove. IPC záleží na součtu ALU + Branch, nikoliv jen na ALU. A taky IPC Zen 4 i Raptoru je od sebe jen pár procent. Branch instrukcí je nějakých 20% takže u Intelu stejně ta pátá ALU je vytížena výhraně Branch instrukcemi. V Applu a ARMu na to přišli dávno že je dobré to mít zvlášť, v AMD to Keller navrhnul hybridně, že 4. ALU taky umí Branch a vypomůže když ta dedikovaná Branch jednotka nestíhá. ARM místo hybridní ALU/Branch jednotky radši dal 2x Branch ikdyž ta jedna byla vytížená jen částečně.

Já to označuji jako INT + branch = ALU, protože je to pro inženýry logičtější, než poněkud zmatené ALU + Branch = ALU. Ale whatever, jde o princip a ne o zkratky.

.
.
.
2) Prediktory:

Jo jasně, ale já se nebavil o prediktorech větvení programu, ale o prediktorech uvnitř dekodéru, což je úplně něco jiného a vůbec to spolu nesouvisí. Prostě 2. instrukce x86 může začínat na 2. bajtu nebo až na 16. bajtu a aby dekodér nemusel brute force prohledávat všechny možnosti (což nelze dělat sériově, takže by musel mít 15 paralelních dekodérů místo toho druhého, celkově 16), tak se využije faktu že existují různá komba instrukcí (typicky zrovna CMP + JMP) a při detekci CMP na prvním dekoderu se predikuje JMP instrukce na druhém, tedy se ušetří brute force prohledávání.

Jak spolehlivá ta predikce je netuším, ale nikdy nebude 100% to je jisté. Jinak by AMD a Intel nemuseli mít brutálně velké microOP buffery, kde si syslí velmi draze dekodované x86 instrukce.

Navíc bych řekl, a to je čistě můj logický úsudek, že čím víc instrukcí je potřeba dekodovat paralelně, tím je těžší takové komba predikovat úspěšně. U dvojtého dekoderu úspěšné předpovězené kombo CMP + JMP znamená 100% úspěšnost predikce. U dekoderu pro 6 instrukcí jako má Raptor tyto dvě instrukce pokryjí jen 33% instrukcí a zbývajících 66% bude velký problém odhadovat, protože tam může být cokoliv. Respektive bude potřeba lepší a objemější prediktory zatímco RISCový ARM na tohle nemusí utratit ani jeden tranzistor a vyplýtvat jedinou minutu času inženýra. CISC je prostě slepá cesta.

AMD svého času používala překlad z x86 do RISC86, uměla to tuším jejich K6 jakožto vynález zděděný koupí NexGenu. Ale byly to vnitřní instrukce, ikdyž to ještě nebyly mOP. Ostatně K5 byla RISCový AMD AM29000 kam připlácli x86 dekodér. Škoda že AMD neudělao RISC86-64 (místo CISC AMD64) to by totiž mohlo fungovat velice dobře.Ikdyž pořád by to byl uzavřený duopol.