Názor k článku Modlitba pro Intel: trápící se gigant a jeho radikální řez od Pavel Píša - Spíš si myslím, že "self-correcting UTF-8" je plýtváním...

Spíš si myslím, že "self-correcting UTF-8" je plýtváním codespace. Pokud vezmu třeba 32 byte pro 8 dekodérů, tak za podmínky, že vím, na které šestnáctici bitů začínám (ukazuje PC) potřebuji 16 určit jestli jsou u každé 16-tice nejnižší dva bity nula a pak mít logiku, která těch 16 signálů zpracuje a podle ní přeřadí správně 16 nebo 32 bitů na osm dekodérů. Ano, je to komplikovanější než jednoznačná korespondence u AArch64, ale proti nutnosti posouvat bloky po bytech o libovolné délky je to o řády méně muxů. Zatím 48-bitové kódování nebudu počítat.

Thumb i Thum2 u AArch32 je mnohem méně mocný, neboť procesor se musí do režimu přepnout skokem a pak na dekódování 32-instrukcí opět přepnout skokem, komplikace s nejnižším bytem skokové adresy atd. tedy přepnutí je tak dlouhé, že se na jednotlivé instrukce nevyplatí. Přitom Thumb pak vede na jen dvouoperandové instrukce a snadno přístupný jen subset registrů. Na RISC-V pak může kompilátor instrukci od instrukce zvažovat, jestli raději 3 operandy a trochu delší kód nebo kratší kdy jeden vstup bude změněný. Na výkonné procesory to není u AArch64 takový problém, ale trochu se plýtvá cache, pokud je v původním kódování instrukcí. Na embeded kde stále růst kapacity Flash odpovídá ceně spíš lineárně než u velkých systému, kde je závislost SDRAM spíše logaritmická, tak menší hustota kódu AArch64 vyřazuje a musím používat jinou architekturu Cortex-M. RISC-V obsáhne vše. Ano, compressed dekodér je určitá komplexita, není povinný a celkově se to podle me vyplatí.

Co se týče immediate a post/pre inkrementů atd, tak flexible second operand na ARM 32 kódování měl velký přínos, ale pro komplexitu ho z AArch64 vypustili a je tam jen 12 bitů a méně immediate a jen s možností lsl 12 nebo o velikost operandu. Takže se komplexnosti vzdali, krátce zmíněno v mé přehledové přednášce pro prváky PDF/Video.

Jinak pokud Intel nepřijde s něčím v kódování výrazně chytřejším než RISC-V, tak by se mu měla komunita vzbouřit. Času promarněného na souboje se segment offset, protected bez stránkování. PAE, příšerné kódování atd. již promrhal příliš mnoho. AMD to trochu zkorigovalo při přechodu na x86_64, ale zase se na to lepilo a REX2 je již zoufalost. Moc jsem při zavedení AMD64 doufal, že po letech AMD řekne a teď zapněte tento bit v CRx a nebo použijte tento mikrokód a máte k dispozici i od prvního našeho 64-bit čipu alternativní kódování instrukcí, které nepotřebuje REX a prefixy. Třeba něco jako Am29000, který měli vyvinutý již v roce 1985. Ale asi to tam opravdu neměli. Na správu jsem si představoval, že by to nabízelo třeba něco jako PAL od DEC Alpha. Případně by to bylo přímo v těch microcode instrukcích...

Jinak si představuji, jak v AMD museli ti s představivostí skřípat zuby, když místo svých elegantních architektur, na které ale běžní uživatelé přejít nechtěli, museli dělat na x86 prasárně.