Vlákno názorů k článku Ryze 64bitová x86 architektura Intel X86-S, podpora MIDI 2.0 od pc2005 - > Intel X86-S Vida jsem spíš čekal, že to...
-
> 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....
