Er x86 kompabiliteten mikrokode-emuleret så vi kan få en processor der virkelig kan køre noget andet kode og slippe for bindingen til den gamle x86 arkitektur?.....
Den underliggende arkitektur betyder lidt for strømforbruget, fordi den gamle kode oversættes til intern risc kode. Men Internt, har Intel for længst opgivet den gamle kode og arkitektur. Et nyt design, kan derfor godt have ny indstruktionssæt, uden vi kan se det som bruger. Intel kan holde det interne indstruktionsæt hemmeligt, om de vil.
Hastighedsmæssigt, betyder derfor ikke stort med kompatibilitet. Derimod, kræver oversættelsen lidt. Imidlertid, sker oversættelsen, inden koden lægges i de interne cacher, og øges cacherne, kan oversættelsesforbruget mindskes.
Hvis vi skal bruge nyt indstruktionssæt, skal vi bort fra Windows. Vi skal have et nyt operativsystem, der tillader en CPU-driver, der tilpasser operativsystemet til CPU'en, og derved tillader at det kan køre på en vilkårlig CPU. Det er relativt let at lave operativsystemer, og programmer, til et deffineret indstruktionssæt, og dette kan gøres mere kompakt og ideelt, end x86 kode, samt mere genneralt for oversættelse til fremtidens større bitbredder. Den binære kode, vil ideelt set, ikke rumme nogen information fra hardware niveauet, eller konstanter såsom "32" fra dette niveau, men deffinere opgaven. Operativsystemet er også skrevet i denne kode, og kun CPU driveren oversætter til CPU arkitekturen. Det kan gøres utroligt ideelt, hvis bit-koden er lavet for det. Idéen er, at operativsystemer, kan bruge vilkårlig CPU og akitektur, og du undgår oversætterdelen. Leverandøren af CPU'en, lægger bare en driver til operativssystemet ind på motherboarded. Herefter er alle CPU'er ens.
På nuværende tidspunkt er ikke økonomisk begrundelse for, at lave en så god og fleksibel struktur. Den økonomiske videnskab argumenterer for, at CPU'en låses fast, til nogle få leverandører, der er i USA, og som man kan få nogle aftaler med.
Et operativsystem, med CPU driver, vil ofte være mere ideelt end nuværende system. I dag, sker faktisk flere oversættelser. Først, oversættes et højniveausprog til en "fiktiv" gammel kode, der intet har med CPU'en at gøre. Og denne kode, kører operativsystemet under. Herefter, oversættes denne så real-time af hardware, til en ny kode, som CPU'en bruger. Dette er ikke effektivt med hensyn til effektforbrug.
Skrives applikationer, og operativsystem, i højniveausprog, vil denne kode altid kunne oversættes til en bitkode, der er mere platforms og CPU afhængig, end højniveausproget, uden der går noget tabt, ved denne oversættelse. Dette bit niveau sprog, kan af CPU driveren, oversættes effektivt (mindst ligeså effektivt som hvis højniveau sproget var oversat direkte da der ikke går noget tabt, som er nødvendigt), og denne oversættelse sker direkte til CPU'ens akitektur. Det betyder, at det er ligeså effektivt - eller mere effektivt - som hvis compilerne direkte oversatte til hardwaren.
Vi kan tage et simpelt eksempel. Forestiller vi os, at vi har behov for en 256 bits "integer", og oversætter denne til Intel kode, så må vi omskrive den til f.eks. 32 bit integers, og bruge flere indstruktioner. Dette kan gøres på talrige måder, og en compiler vil miste overblikket og forståelsen af, at det reelt er en 256 bit integer. Man kan gå fra 256 bit til 32, men ikke retur. Derfor, skal programmeringssproget ikke være "bit begrænset", og visse typer, såsom addressepointere, skal have principielt uendelig bitbredde i sproget. Det giver også anledning til fornuften, i integers, der reelt har uendelig bitbredde. Et sådant niveau, kan af en god kompiler, evt. real-time, eller dynamisk compiler, oversættes til CPU'en effektiv, og dens fulde akitektur kan bruges. Selvom det er bit-niveau, må altså ikke ske hardware implementering, i compileren, der oversætter til bit niveauet. Oversættelsen til hardware skal alene være i CPU driver, og evt. CPU.
Et sådant koncept, vil i nogle tilfælde kunne spare strøm.
Samtidigt, kan et "bit-sprog" laves så godt, at det ikke er grund til nye sprog. Dels, vil man kunne udvide operativsystemet og holde bagud kompatibilitet, hvis nyt skal tilføjes, og det vil kun kræve ny CPU driver. Men det vil ikke kræve udvidelser, med mindre der kommer nye højniveau sprog, der har en helt anden måde at fungere, som ikke kan specificeres abstrakt og præcis i bit koden. Med abstrakt menes hardwareuafhængig. Med andre ord, er næsten usandsynligt at der er behov for ny bitkode. Operativsystemet, vil kunne køre på såvel Intels CPU'er, som SUN's, og egenudviklede højhastigheds CPU'er, hvis der udvikles et sådant operativsystem.
Java byte-kode, er tæt på - men ikke tæt nok. Det er ikke abstrakt nok, og rummer dele der arver "konstante" fra den virtuelle maskine. Det er ulovligt, hvis det skal kunne oversættes ordentligt. Reelt indfører Javas bytekode, derfor blot endnu et niveau af kompilering, hvilket kun kan gøre oversættelsen mere besværligt, og mindske effektiviteten. Det svarer lidt til, at hvis du har 256 bits integer, så skal den først oversættes til bytes, og herefter tilbage til 32 bit ord, hvilket er umuligt.
