Vlákno názorů k článku Nové vlastnosti čipů 80386: stránkování a virtuální režim 8086 od atarist - Tak si říkám, jestli by nestačilo jen to...

Tak v x86_64 režimu, tedy v tom pročištění architektury a rozšířením na 64-bitů, se kterým přišlo AMD, když tušili že licenci na Itanium nedostanou , tak jsou režimy jen dva a žádné nesmysly se selektory/segmenty. Vše se řeší přes stránkování, user a system mode a pár specializovaných registrů. Segmenty FS GS se zachovaly jako ofsetová adresace pro thread local storage. Ale jinak je to vyčištěné.

Na rozumných architekturách, jako m68k, nikdy taková zvěrstva nebyla a vývojáři v IBM museli hodně brečet, když měli PC naplánované na m68k a pak jim vedení přikázalo kvůli dohodě o licencích s Intelem jít do pravěku na 8088. Pak všechny podtrhl Microsoft s tím, že neudělal DOS pro 386 a tak se tisíckrát více něž bys tálo přepsání té FAT FS knihovny (nazývané DOS) v mnoha firmách nainvestovalo do DPMI a pak i Microsoft, když uznal 386 musel řešit na stále 16-bit Windows 3.x systém VxD aby těch několik paralelně spuštěných DOS, vlastně spíš bare metal, aplikací mohl přepínat.

Když ty články čtu, tak se mi z toho promrhání potenciálu a prostředků mnoha o řád technicky schopnějších firem než byl Microsoft zase dělá špatně.

Je pro info, v roce 1987 a 88 jsem pracoval s malým Unixem s m68k a stránkováním, byl to embargovaný vývojový systém Philips PMDS-85 na vývoj a HW ladění od 8080 až po m68k vlastní návrhy...

Zpět k x86, i v těch 64-bitech zůstává hrůza SMM a tak často BIOS dělá motheboardy nepoužitelné pro RT nasazení. Později pak přibyl Virtual monitor, často značený ring -1 pro HW virtualizaci.

Ale doufám, že ta x86 hrůza již postupně přestane strašit.

Když třeba na Alze u notebooků nastavím procesor na Apple Silicon (733), MediaTek (5), Qualcomm (114) tak nabídka již začíná být zajímavá a za pár let to třeba dožene i RISC-V a na x86 si již nikdo kromě sběratelů nevzpomene. Intelu bych přál ať přežije, ale doporučuji, ať sám architekturu již nikdy nevymýšlí. I když před lety nějakým omylem vymysleli 8x196 to snad nezkazili a létá v letadlech bezpečně dodnes. 8008 a 8080 by se také daly vzhledem k době odpustit. Sami věděli, jaká je x86 katastrofa, ale i432, 860 i Itanium vedené snahou to změnit byly ještě horší. A opět se hromada lidí kvůli šílené architektuře x86 učí jak s ní žít. Advanced Performance Extensions s REX2 je další berle místo vymetení smetí.

Na druhou stranu obdivuji, jak dobré měají v Intelu a AMD implmentátory, kteří s tou hrůzou dokázali být desetiletí výkonově kokurenceschopní a někdy i na špici, po tom co většina lepších alternativ obchodně nevyšla. Ale teď je spotřeba na laptopech vyřazuje, na mobilech byl poslední záchvěv před u Intelu tak 10 lety.

U intelu me spis vadi, ze tlaci nesmysly proti vuli uzivatelum a co nezapada do jejich linek, tak vas poslou do haje.

Projekty ktere jsme nerealizovali, protoze to Intel nechtel dat:

- software defined camera - uplne nas vyghostovali Broadwell CPU ktere meli eDRAM L4 cache .. vznikli 2 modely a cache nebyla riditelna - asi ukojeni investoru jako s prvnima 10nm o dekadu pozdeji. Navic OpenCL nikdy intel nedodelal do pouzitelneho a free stavu u svych iGPU.

- thunderbolt 2,3,4 - ne, nemuzete udelat reusable modul, muzeme vam schvalit pouze end user produkt a musite jich prodat miliony... asi ne jako, kdyz je ten produkt high end jako zlaceny opticky kabel

- movidius DSP - sice to je genericky DSP a lze to volne programovat, tak Intelova predstava byla to bundlovat s firmwarem ktery je "hw akcelerator pro AI", tj je to omezeno na inferenci (data vuci modelu), ktery dodate ovladaci mezivrstve. Ale kdyz ja chci delat kompresni kodeky, tak jako ne. Vemte milion na AI a pak vam mozna dame SDK.. wtf. Blbci.

- intel quark x1000 - je to x86 pentium soc, obdoba dnesniho RPico MCU. Ale koupit to slo jen jako demo devkit s cilem konkurovat Ardiumu ... a pak to taky zarizli kdyz to nenaplnilo ocekavani. Ale dovolit jinym udelat neco lepsiho - ani nahodou.

V podstate je dnes temer nemozne udelat revolucni produkt, protoze si vyrobci vsech soucastek narokuji se drzet strikne jejich vytvorenych koleji.. se nas asi boji, mekkousi :D

A tyka se to i obyc komponent.. treba vicefazove VRM jako mate na kazde druhe grafice pro stovky amper.. neni sance sehnat. Vsichni cekaj ze to pujde do spotrebky nebo superpocitaci v milionovem mnozstvi. Meh.

Souhlas. Zase na druhou stranu, Intel se snažil prosazovat další architektury. Intel 432 (no to nebyla sláva), Intel 860, 960, Xscale (ok, to bylo v rámci license s ARMem AFAIK).

Ale svět chtěl Wintel platformu :(, tak prostě investovali do tohoto segmentu. On i Microsoft se chytil do stejné pasti, a těžko říct, jak z ní vycouvá (ale je v lepší pozici než Intel).

No a potom Intel začal jednat z pozice síly - tlačení nových slotů/socketů ne kvůli tomu, že by to bylo technicky lepší, atd. V té době se ukázala síla trhu, kde je rozumná konkurence (Athlon a vlastně i Duron).

8. 1. 2025, 10:00 editováno autorem komentáře

Microsoft teď hodně maká na ARMu, aby měl záložní architekturu a s těmi zkušenostmi pak mohl přidat i další, podle potřeby. Servery už standardizoval, jako předtím zvládl PC, např. UEFI BIOS a inicializační kód PCIe karet bajtkód vykonávaný tím UEFI BIOSem, takže stejná karta funguje v obou typech serverů (není potřeba flashovat BIOS jako na PowerPC Macách nebo emulovat x86 jako na Amize). Naportoval na ARM jádro Chromu (tak vznikl Edge Chromium, když se Google na portaci neměl), naportoval starý .NET (Framework) i nový (založený na Core), naportoval i Javu...

Ty ROM s inicializací na PCIe kartách by měly být vyřešené již od příchodu ACPI, od kdy karty měly mít inicializaci v bytekódu pro interpreter. S tím a formátem ELF přišel Intel, když chtěl utéct z x86 na Itanium.

I když když nyní koukám na 14.4.2 PCI Option ROMs
v Unified Extensible Firmware Interface (UEFI) Specification,
tak to zase vypadá pěkně divoce

• Legacy Option ROM image
• IA-32 UEFI driver
• x64 UEFI driver
• AArch32 UEFI driver
• AArch64 UEFI driver
• Legacy Option ROM image + x64 UEFI driver
• Legacy Option ROM image + x64 UEFI driver + AArch64 UEFI driver
• x64 UEFI driver + AArch64 UEFI driver
• Itanium Processor Family UEFI driver
• EBC Driver

Ten EFI Byte Code (EBC) Virtual Machine je asi jediný přenositelný, ale ten tam, podle mě měl být již od ACPI a Itania a přitom tenkrát se tomu , myslím UEFI neříkalo...

Specifikace formátu zde

https://uefi.org/specs/UEFI/2.11/22_EFI_Byte_Code_Virtual_Machine.html

Na druhou stranu obdivuji, jak dobré měají v Intelu a AMD implmentátory, kteří s tou hrůzou dokázali být desetiletí výkonově kokurenceschopní a někdy i na špici, po tom co většina lepších alternativ obchodně nevyšla.

O tomhle bych si rád přečetl něco víc do hloubky, protože kritiku x86 architektury čtu roky, ale nikdy né nějak uceleně a vlastně všechny ty informace dohromady si trochu odporují / nepodporují se.

Co mám na mysli. Třeba i od vás jsem tu četl kritiku, že maximální počet dekódovaných instrukcí (x86) za takt je cca 6 a že arm umí víc. No ok. Potom vidím přednášku (C/C++) třeba od Fedora Pikuse (Siemens), kde říká, že stejně ani v benchmarku není možné využít všechny jednotky (cca 7).

Tak fajn, vezmu si kalkulačku, vezmu konzervativní jádro s počtem integer jednotek v jádře, tedy 4 (tohle je tak rok 2002, jestli si správně pamatuju kolegu studenta na univerzitě) a počítám: 4GHz*8B*4*2 = 238GB/s per jádro. (4GHz je takt mého cpu (Ryzen 7 5800), 8B je 64b, 4 integer jednotky a dvě hodnoty na operaci). DDR4 3200MT/s dává cca 25.6GB/s. Dva kanály to máme cca 50GB/s. Takže jedno jádro moderního x86 CPU je limitováno pamětí. Těch jader máme fyzických 8, takže cca 2TB/s. Na to bychom nepotřebovali ani DDR5 ale rovnou HBM a to ještě budoucí verze. (A to ještě navíc nikam neukládám ty spočítané hodnoty.) A ano, zjednodušil jsem to na 1T operace. Kdybychom chtěli třeba dělit, tak nám i ta rychlost paměti zatím trochu stačí.

Tak zatím to x86 nahání frekvencí (na úkor spotřeby). Frekvence ale už skončila, takže je jen otázka času, kdy se rozdíl prohloubí.

Tak zatím to x86 nahání frekvencí (na úkor spotřeby). Frekvence ale už skončila, takže je jen otázka času, kdy se rozdíl prohloubí.

Frekvence je limit pro všechny architektury stejný. Jestli mám x86_64 nebo aarch64 na 4GHz je jedno. Jestli jeden procesor někde vyloženě neplýtvá časem (a na to se vlastně ptám), tak oba budou jednak stejně rychlí ve stejných výpočtech a potom stejně narazí na rychlost pamětí / sběrnic. A zatím to vypadá tak, že tam kde naráží 8jádrový x86, tak tam je potřeba 128jádrový arm. Kde je navíc potřeba, aby se progs naučili programovat multithreading (čemuž fandím cca od roku 2006 :-D - ve skutečnosti tak 2000, protože kámoš měl dvou cpu desktop (Abit BP6)).

Ano, limit frekvence je nezávislý na CPU architektuře. Ale RISCový dekodér může dekódovat, kolik instrukcí za cykl chce (jednoduché paralelizovat, když instrukce mají stejnou délku), podobně je jednodušší zvětšovat out-of-order buffer, cache a v případě vlastních procesorů si můžete taky udělat, kolik linek RAM budete chtít. Vyšší modely Apple Silicon mají brutálně širokou sběrnici do RAM a přenosovou rychlost. Podobný princip jako SGI workstation z 90tek, co mám doma. To jen na x86 PC je málo linek do RAM.

jednoduché paralelizovat, když instrukce mají stejnou délku

Tohle přece univerzálně neplatí, ne? Už jsem viděl i přednášky (ARM), kde sice někdo napřed chválil stejnou délku instrukcí, ale ve druhé hodině si na to zase stěžoval, protože paměť má jen nějakou rychlost a ty instrukce by mohly být kratší (THUMB). Proto bych rád diskusi nechal na úrovni porovnání architektury a nikoliv toho, kdo co má jak velké, protože:

To jen na x86 PC je málo linek do RAM.

Což se dá snadno navýšit a proto třeba EPYC má 12 kanálů. Ostatně každý serverový procesor jich má tak nějak víc.

Apple Silicon, Qualcomm Snapdragon X Elite apod. neumí THUMB, vyřešeno. Kanálů do RAM mají kolik chtějí, tohle není legacy x86, takže taky vyřešeno. Taky je ta RAM přilepená k CPU, takže běží na skoro dvojnásobných taktech. Na EPYC stejně člověk nemá peníze.

To je ale extrémní případ, většina těch operací využije cache.

Tak sám vím, že znalosti mám také celkem omezené. Když si ale představím, jak je komplikované jen najít konce instrukcí a správně je napasovat na na dekodéry a kolik vrstev multiplexerů je k tomu potřeba, tak tam vidím hromadu zbytečných taktů v pipeline, aby se to stihlo rychle. Pokud vím, tak již dlouho si x86 udržují v instrukční cache hinty k tomu, aby opakovaně šlo nalezení hranic rychleji. Další problém jsou skoky, proto pak platí různá pravidla, že víc jak dva skoky myslím že na 16 byte vedou k úplné ztrátě predikcí. Aby to alespoň trochu šlo s granularitou na byte, tak je to udělané tak, že se do branch prediktorů indexuje bity od 4. výše. Dříve to bylo jen nějak do 12-tého bez plhodnotného tagu a pak byly ty specre a meltdown útoky. Ale aby mohly být ty dva skoky v 16-tici, tak jsou tam nějak 2x a drží ze k nim ty offsety... Dekódovat to musí být peklo. Ale již se nějak na 6 a možná i 7 dostanou. Aplí ARM v pohodě 8 a těď již u M4 snad i 9. Ale ta logika na x86 je nepoměr. Aby to mělo šanci, tak se používá branch trace cache, pokus vlastně přeložit vše u NetBurstu (Pentium 4) nevyšel, ono tam asi vzhledem k těm problémům s mapováním 1 byte až 14 byte instrukce na jednu nebo nějakou kombinaci přeložených nemohl indexováním vyjít. Trace cache má výhodu, že se přeložené cílové instrukce ukládají jako řetízek indexovaný adresu skokové instrukce. Chytá to lag v překladu po skoku, ale nejlépe to bude chodit pro krátké cykly, kdy se tam vejde vše a již se na původní instrukce nesahá vůbec.

Obecně si myslím, že ARM Aarch64 (32-bit conditional nejde) a RISC-V v té vlastní výkonné části na tom jsou mnohem lépe. Ale Intel vždy uměl float a implementace operací (f0 bug byla smůla, ale jinak je opravdu dobrý) a asi i u SSE a tak nabízí dobré věci, například shuffle s automatickým doplněním nul na záporné indexy atd...

Ale stále si smyslím, že je ten celek špatně a Alpha, PowerPC, Aarch, RISC-V by ho měly na úrovni vlastního core válcovat. jenže pak je to uncore a napojení na paměťové ringy, home directory, memory controlery atd, a tam asi opravdu Intelu a AMD umí něco navíc. Jinak když si představíme ty výpočty na propustnost, tak kontinuální protahování dat větších než je cache zahubí vše. Wikipedia uvádí DDR5 32.0–70.4 GB/s pro 64 bits šířku. Lze to navýšit 2x nebo i 3x více nezávislými kanály/řadiči, když jedou prokládaně. Jenže to je teorie, realita je, že latence je 14 ns, jsou tam možnosti otvárat různé skupiny bank naráz (třeba tažení dat do dvou vláken/jader operujících v jiné části adresního prostoru). Ale stále je to o tom dostat data do cache a udržet výpočet v ní. AMD Infinity Fabric má má bandwidth až 512 GB/s, tedy jádra, nebo spíš L2 a L1 cache ukrmí, když jsou data v někré části L3, třeba i na jiném socketu.

Na druhou stranu Nvidia NV Link má až 1.8TB/s a HBM 4 až 1.6TB/s. Ale stále to ty 4 ALU nebo třeba i SVE s šířkou 512 bitů (64 byte) na 3 GHz neukrmí... Takže je opravdu potřeba dostat výpočty do L1 cache, která často umí v jednom taktu třeba i šest přístupů. Ale ono se tan objeví lagy/bubliny na skocích a pak ty obrovské, když se musí do vnější paměti... To se pak částečně kryje hyperhreadingem když již i ten data flow limit (out of order limit) okolo 600 instrukcí nenajde nic, co by mohl řešit když se nějaká instrukce blokuje...
h diskutovat s

Určitě by bylo zajímavé o těchto věcech diskutovat s těmi, co to přímo pro Intel, AMD a další navrhují, ale asi tam bude dost NDA.

V rámci předmětu B4M35PAP nyní jeden student podle mnou odpřednášených a přežvýkanách principů třeba z knihy Shen, J.P., and Lipasti, M.H.: Modern Processor Design : Fundamentals of Superscalar Processors, First Edition, New York, McGraw-Hill Inc., 2004 , zkouší navrhnou 4 wide out of order se dvěma ALU, jednou jednotkou skoků a jednou na paměť. Tak nad tím debatujeme a již toto vede na hromadu komplikací. V zásadě je potřeba řídicí část rezervačních stanic a další věci jet minimálně o cyklus dříve, než vlastní přepínání a forwarding dat. A v reálu se to jede asi spíš o dva takty dříve, aby pipelining v rozhodovacích cestách umožnil na plné frekvenci naplánovat dopředu pipelining, reorder, register rename a forwarding v datových cestách. I když ty muliplexery v datových cestách jsou také děsivé, několikrát třeba i stovka bitů třeba z osmi zdrojů... Ale ta řídicí část potřebuje zatřiďovací prioritní fronty atd... Když se to udělá jednoduše, tak se pak předběhne s instrukcí, která není potřeba a naopak tak, která blokuje další se dostane pozdě a tím se zahltí dispatch a decode a je to pomalejší než in order jednoduchá pipeline...

Je to celkem zajímavé a v zásadě asi i ta nejlepší reálná řešení jsou jen aproximace a kompromis, aby se ta řídící část nakonec nebyla tak složitá, že poběží na 1 MHz nebo bude desítky cyklů prohledávat, co dělat dále.

Tak to jsou nějaké z rukávu sypané úvahy. V jednodušší formě bez toho obrazu ve velkém, jen po částech a základních principech to pak máme v těch odkazovaných přednáškách z B4M35PAP.

Nedávno jsem celkem zajímavě zpracované úvahy o těch reorder bufferech a jak na architectural state a rename a dalších našel v kurzu Australian National Univerzity

https://comp.anu.edu.au/courses/comp3710-uarch/

https://comp.anu.edu.au/courses/comp3710-uarch/lectures/

Jsou tam zajímavé úvahy.

@Pavel Píša

Díky moc!

Ringy 1 a 2 ztratily využití, ale k úrovním oprávnění přibyl Hypervisor pro virtualizaci, SMM a Management Engine.

Present flag se právě používal na demand-load, kdy se segment načetl z disku, až se na něj poprvé sáhlo.

Běžně se používal discardable segment na kód, který se použil jen jednou při inicializaci a pak už nebyl nikdy potřeba, nebo na read-only data na jedno použití jako jsou relokace.

Segmenty měly jen accessed flag, ale neměly dirty flag, swapování zapisovatelných segmentů bylo neefektivní.