azért várható volt, hogy ugyanarra a sorsra fog jutni, mint az Itanium, részben ugyanazért (= az inkompatibilitás miatt).Igen, olyasmi. Bár az x86S jobb esélyekkel indult, de benézte az Intel azt, hogy mivel járna átállni rá (itt nem fordítókra gondolok, hanem hogy mennyire bele van vasalva a real mode - prot mode - long mode az alacsonyabb rétegekbe, BIOS ROM-ok, APIC inicializiáció, stb.) Az meg, hogy bukott volna vele a 32-bites library és app támogatás (legacy mode) hab a tortán, a Microsoft biztos fúrta miatta. Valószínűleg a RedHat / Oracle / stb. sem lelkesedett az ötletért, bár Linux alatt könnyebb kibekkelni, ha nincs lib32. Az Itanium egyébként durva cucc volt, mert nyilvánosan konfigurálható volt az ISA-ja. Ha valaki akarta, akkor mondjuk az egyik core-ból csinálhatott M68K-t. Érdekesség, hogy ez a technológia továbbra is megvan x86-on, de már nem nyilvános, és csak arra használják, hogy az x86-os ISA-t toldozzák-foltozzák vele (microcode update). Pedig lehetne más ISA-t is betöltetni vele akár, mint az Ithaniumon. RISC-en szoftveresen emulált CISC az x86, furcsa egy jószág, na, lenne mit karcsúsítani rajta. Mindettől függetlenül szerintem lett volna létjogosultsága az x96S-nek egy bizonyos rétegben, kb. mint az Intel Atom-nak. Egy ratyi, sose lett mainstream, de ha x86-os programokat kell futtatni olyan környezetben, ahol nagyon fontos az alacsony fogyasztás, arra kifejezetten jó (mondjuk másra nem). Hasonlóan egy csak 64 bites x86-nak is lett volna helye, szvsz.
Minden kernel- / hypervisor- / firmware-szintű kódban továbbra is szüntelen hajtépés a CPU módok váltásaHát nem triviális, az biztos. Ráadásul a mai modern fordítók nem is kezelik már helyesen. Például itt egy durva hákolással tudtam csak megoldani, hogy a fordító olyan prot mode utasítást fordítson, amit majd futás közben helyesen real mode-ban hajt végre a CPU... Egyszerűen nem lehetett olyan valós módú utasítást megadni, ami a módváltáshoz szükséges, mert már nem tudja azt a fordító inline assemblere...