Tämä tarkoittaisi mm. kuoliniskua kaikelle vanhalle raudalle, jolle ei ole kirjoitettu 64-bittistä ajuria.
Kuten?
Ei 32-bittiset ajurit muutenkaan toimi 64-bittisissä käyttiksissä.
Jos taas se softa mitä kutsut "ajuriksi" ei ole oikea ajuri vaan usermode-softaa , se toimii x86s-prossulla 64-bittisen käyttiksen päällä aivan samalla tavalla kuin normaalilla x86-64-prossulla 64-bittisen käyttiksen päällä.
Ne koneet joissa ajetaan 32-bittistä käyttistä sen takia että jollekin raudalle ei löyty 64-bittistä ajuria on hyvin harvinaisia.
Ne UUDET/uuden prossun sisältävät koneet joissa ajetaan 32-bittistä käyttistä sen takia että jollekin koneen sisältämälle raudalle ei löyty 64-bittistä ajuria on vielä harvinaisempia.
Ainoat merkitykselliset ja potentiaalisesti yleiset yhteensopivuusongelmat mitä keksin on, että
1) BIOSin bootloader-koodi pitää muokata toimimaan kokonaan 64-bittisessä tilassa.
2) joissain koneissa BIOSin päivitys voi vaatia boottausta DOSiin, mutta tämäkin on melko harvinaista, ja tämä ei x86s-prossulla ole mahdollista. Että joku emolevyvalmistaja voi joutua koodaamaan firmwarenpäivityssoftansa uusiksi että saa emolevynsä yhteensopiviksi x86s-prossujen kanssa.
Molemmat on lähinnä että emolevyvalmistajille (kertaluontoisesti) vähän lisätyötä, mutta kun työ on tehty, mitään ongelmia ei näistä ole.
Samoin 16-bittisiä legacy-ohjelmia ei voisi enää ajaa edes virtuaalikoneella.
16-bittisiä legacy-ohjelmia on jo vuosikaudet ajettu Dosbox-softalla, joka on ihan täysi emulaattori, ei virtuaalikone.
Vanhojen tilojen ylläpito voi toki tuntua turhalta mutta kuluttaako ne oikeasti merkittävästi resursseja? Arkkitehtuuri toteutettiin pitkälti jo 80286:lla ja kokonaan 80386:lla (134k/275k transistoria kaikkeen toiminnallisuuteen).
Ei näiden ominaisuuksien tuen hintaa lasketa niinkään transistoreissa vaan piirin kehittämisen monimutkaisuudessa, tuotekehitysajassa, luotettavuudessa ja siinä, millainen suorituskyky siihen uuteen tuotteeseen saadaan.
Kun prossua kehitettäessä pitää huomioida se, että uudenkin ytimen pitää toistaa identtisesti 45 vuotta vanhan prossun muistinosoitusbugi, koska maailmassa on paljon softaa joka väärinkäyttää tätä bugia käyttääkseen suurempaa määrää muistia kuin mitä 45 vuotta vanhalla prossulla muuten voi muuten accessoida, sitä aikaa mikä tähän prossun kehittäjältä menee ei voida käyttää jonkun uuden suorituskykyä parantavan ominaisuuden kehittämiseen ja testaamiseen.
Ja kun sen bugin toistamisen takia ei voida osoitteenlaskentayksikössä käyttää optimaalista yhteenlaskuyksikköä vaan sen sisällä pitää vetää muutama linja hassusti ja tarvitaan niiden valintaan ylimääräinen mux, pahimmillaan tästä voi tulla vaikka kellojakso lisää viivettä joihinkin latausoperaatioihin (ei toki todennäköistä).
