Názory k článku Ryze 64bitová x86 architektura Intel X86-S, podpora MIDI 2.0
-
> Intel X86-S
Vida jsem spíš čekal, že to udělá AMD jako trolling ještě před tím než mu vypršely patenty na K8 (x86-64). Ty výpočty fyzické adresy přes všechno to MMU a/nebo segmentování v 16bit musí zabírat v mikrokódu strašně místa. Nechat x86-64 a starší emulovat přes qemu-i386 se naskýtá :).Doufám, že první implementace nedopadne jako Intel 80376, kde to zkoušeli s 32bit only "386" (ale velmi "chytře" tam nenechali MMU).
Blbý je, že instrukční kód bude i pak dost guláš. Třeba takový in/out instrukce vůbec nejsou potřeba a mmio by to krásně nahradilo.
-
Nn IN/OUT zůstane, ale bude fungovat jen v ring 0. Userspace si prostě bude muset říct kernelu, aby za něj poslal data. Co se zruší kompletně bude INS/OUTS (v dokumentu je něco ve smyslu: použijte IN/OUT ve smyčce).
Ono asi bude chvíli trvat než by se nahradily opravdu všechny využití portů (koneckonců PCIe je pořád podporuje).
Docela by mě zajímalo za jak dlouho použijou uvolněný pozice pro nové instrukce (třeba outsb je jen jeden bajt: 0x6e , kdežto třeba cmpxchg8b musí mít ten rozšiřující prefix 0x0f, protože nebylo volné místo v ISA).
-
Zrovna PCIe podporuje IO transakce jen kvuli kompatibilite s X86 PC svetem, a jinak to je deprecated. Treba ARM host je nemusi podporovat a pak nastava problem, kdyz pouzijete kartu s BARem typu IO, na ktery se ten ARM uz nedovola :-)
Premapovani opcodu podle me nenastane, to uz by mohli udelat zcela nove binarni mapovani, ktere by melo vyhody u dekodovani jako aarch64.
-
BARy typu IO se na většině RISC a ne jen tam, řeší namapováním do k tomu určeného fyzického adresního rozsahu, ve kterém LDR, STR (LW, SW nebo jak je přístup do paměti na dané architektuře řešený) přemapují na PCI/PCIe I/O transakce... Nebývá to problém. Alespoň když jsem to naposled v Linux kernelu před několika lety hledal... Jinak kompletní vyhození I/O prostoru věci zjednodušuje....
-
Itanium slo do kytek predevsim kvuli nekompatabilite, to byla primarni pricina. Nefungovaly na tom aplikace. Intel se to snazil resi SW emulaci, ktera jednak nefungovala a druhak byla tragicka vykonostne.
Presne proto vyhralo amd64, protoze amdcko proste vzalo existujici a primlasklo k tomu stejny instrukce rozsireny na 64bit.
Tohle bude zakonite exaktne totez. Intel mozna doufa, ze 64bit aplikaci je dost, a starsi nikdo nepouziva, ale realitou je opak.
-
Mě spíš zaráží, že chcou pokračovat tady s tou architekturou. Jasně, tím že odstraní 16-bit a 32-bit support zahodí celou podporu segmentace a dalších historických reliktů, ale proč nesáhnou na to kódování těch instrukcí? Kdyby vytvořili nové efektivnější kódování, tak se může napsat runtime translator, který by hezky pustil staré binárky tak jak to dělá třeba Apple. Nejvíc relevantní by to stejně bylo pro Windows.
Podle mě ta instrukční sada je OK, jen to kódování je na prd, a to množství GP registrů by taky chtělo rozšířit na 32.
-
Problém Itanium byl, že kompilátory nedokázaly využít dlouhého instrukčního slova kvůli explicitní paralelizaci. Tedy možná ani ne tak kompilátory jako samotný kód. Klasický CPU, který podporuje out of order, se ukázal flexibilnější, mohl si čekat na přístup k operandům i jednotkám podle potřeby atd.
Jinak souhlasím s předřečníky - IMHO tohle nic nevyřeší. Možná Intel získá pár nových prefixů, ale to bude všechno. Plus zahodit ten historický bordel s paměťovou adresací ušetří nějaký křemík, ale asi ne mnoho - stránkování je defakto nejkomplexnější a to tam logicky zůstat musí.
Intel bude muset celý ten historický blob x86 zahodit a začít znovu, stejně jako to udělal Arm s aarch64. Na druhé straně nic lepšího než aarch64 v této chvíli nemáme (možná RISC-V, ale tam jsou pořád trochu pesimista), takže bude těžko přesvědčovat potenciální zákazníky o změně.
Jinak proti tomu původnímu rozhodnutí nic - x86_32 a x86_16 zbytečné jsou...
-
Itanium byla úplně nová architektura, pro kterou neexistoval dobrý compiler.
Já mluvím o tom, že by Intel zachoval úplně všechno kromě kódování instrukcí, takže by se na novou architekturu dal přeložit i existující kód v assembleru a všechno co používá Intel intrinsics v C/C++, atd... Jen by se zněnilo kódování těch instrukcí. A místo toho, aby emulaci dělal hardware, tak by se napsal software translator tak jak to udělal Apple. To by bylo v podstatě 1:1 přeložit existující binární kód pro tu novou architekturu.
-
Tady je trochu rozdíl, že Apple má svůj appstore přes který všechno tlačí. Díky tomu má kontrolu nad softwarem, který běží na jeho hardwaru. Takže může zatrnhnout třeba samomodifikující se kód a podobná zvěrstva, která se automaticky převádějí fakt blbě.
Ve windows světě se každá aplikace instaluje a aktualizuje po svém. Microsoft sice přišel s nějakým appstorem, ale nejdou přes něj ani jeho věci, takže na něj samozřejmě kašlou i ostatní.
Killer featura windows+intel je právě zpětná kompatibilita, která umožňuje spouštět nenahraditelné a neopravitelné binární bloby. Takže Intel tenhle krok nemůže udělat, protože ani nemá jak odhadnout, co by tím rozbil.
-
Původně měl ale jít i do PC (postupné zvládnutí zlevnění technologie). Akorát AMD vydal amd64, který nešlo překonat, tak Itanium zůstalo pouze v serverech.
EDIT: Konkrétně HP a pár dalších se právě že zbavilo svých procesorů ve prospěch Itania. Takže to se Intelu podařilo.
29. 5. 2023, 16:44 editováno autorem komentáře
