Windows kompatibilitet betyder intet, hvis de kan tilbyde væsentligt bedre performance til den rigtige pris.
Windows kompatibilitet - eller måske rettere X86 kompatibilitet betyder en del. Der findes masser af software til platformen, trods den er låst fast til en enkelt producents CPU.
Den bedste løsning, tror jeg, er at enten lave en emulator således standard PC software kan indstalleres på det medfølgende operativsystem, eller lave en "wine" emulator, der kan emulere windows software, og lade et OS med en sådan emulator medfølge operativsystemet. Den underliggende CPU behøver ikke at have X86 indstruktionssæt, men bare et indstruktionssæt der kan emuleres ved dynamisk compilering, i software.
Når man laver en emulator der anvender dynamisk compilering, så "flytter" man reelt en stor del af den advancerede hardware over i software, og det betyder, at der kan anvendes endnu mere advancerede algorithmer, og at oversat software kan opbevares på harddisk.
Intels pentium 4 indeholder en emulator i hardware - de kan ikke selv køre eget indstruktionssæt. Ulempen ved en sådan hardware emulator, er at den bruger masser af strøm, ikke kan være så kompleks som en i software, og ofte lægger sig ind i flaskehalse i processoren. Således må Intel, så vidt jeg ved, lave ekstra tabelopslag, der formentligt kunne være undgået, hvis den var lagt i software. I nogle tilfælde, er det dog nødvendigt med disse tabelopslag, og i så fald er bedst at de håndteres af hardware, og at hardwaren derfor har faciliteten indbygget, og kun bruger den når det er nødvendigt. På den måde undgås ekstra tidskrævende indstruktioner, i de kritiske dele af udførslen. En stor del, af den dynamiske pipeline, kan også lægges i software, ved at udføre pipeliningen når programmet analyseres og oversættes til maskinkode. Dette muliggør en mere kompliceret analyse, og derfor at programmet bedre kan mappes ned i hardwaren. Specielt, når der er mange ALU'er, bliver det for komplekst for hardwaren.
En af grundende til, at Intel kun har så få ALU'er i deres CPU, er helt sikker den skal "emulere" X86 indstruktionssæt. Uanset, alle de features den er forsynet med, så er det for kompliceret at få krydsoversætteren til at køre, hvis den skulle bruge tusinder af ALUer. Det kan løses, ved at direkte genoversætte programmet til brug på mange processorer, og udføre denne del dynamisk i en kombineret hardware og software del. Typisk, vil det blive gjort i software, men der vil blive indlagt hardware faciliteter, som gør processoren egnet til at håndtere problemerne. Dette giver også mulighed for, at andre CPU'er kan emuleres, og processoren bliver ikke fastlåst til CPU'ens indstruktionssæt.
Det er meget kompliceret, at lave en effektiv analyse af software hvis den skal lægges ud på mange ALU'er, og brede VLIW strukturer, og i praksis vil den skulle gemmes på harddisk, så de oversatte dele kan genbruges til senere udførsler af softwaren.
Ikke mindst, bliver udgifterne mindre, ved efterfølgende processorer, da softwaren der en gang er udviklet, kan genbruges, eller modificeres, selvom processoren ændres lidt. En stor del af hardwareudviklingen forsvinder derved.
Ved en hardware baseret analyse, gemmes softwaren ikke på harddisk, og hellerikke i ram, men oversættelsen sker "on the fly". Ved en dynamisk oversættelse, sker oversættelsen første gang softwaren udføres, og gemmes herefter på harddisk. Dette giver mulighed for langt længere tid, og bedre algorithmer bruges. Det væsentlige er, hvor lang tid det tager, i forhold til at hente det pågældende program fra harddisk. Da oversættelsen kun foretages éen gang, så koster det ikke meget i tid, men det er muligt at få processorens pris i bund, samtidigt med at hastigheden stiger, på grund af den langt bedre analyse. Ved hardware baseret analyse, har man typisk to addresserum, således man holder på X86 addresserne - ved software baseret genoversættelse, findes dette også, men ikke i selve koden. Såvel jumps, som branches, kan være optimeret bort, og koden kan være optimeret, til flere ALU'er, og flere VLIW processorer.
Det bedste er naturligvis, at gøre det på højniveausprogs niveauet, da man her nemmere kan "opdage" hvordan ram'en bruges. Gøres det i software, skal man opdage om to dele kan bruges concurrent, og det er ganske svær. Her hjælper det, hvis der bruges højniveau sprog, der har range check på, da rangecheck så hjælper en underliggende compiler, med at få overblik over ram brugen. Den vil gøre det tydeligt, fordi range check på index, vil få den til at gå udenfor et bestemt område, og til samme programafsnit, og få den underliggende compiler, til at kunne dele programmet op i tråde, såfremt det er anvendt særskildte dele af ram'en, f.eks. flere arrays, der hver har array check på.
