Lidt mere detaljeret info om, hvordan en emulator fungerer (krydskompilerende). Der er kopi af den oprindelige kode, så der altid er adgang til de oprindelige data.

Der er en layout map, der fylder det samme som den oprindelige kode. Det indeholder single-byte call indstruktioner der kalder en oversætter. Og så er der endeligt et område/områder med den krydsoversatte og optimerede kode til den nye processor.

Antager vi, at programmet f.eks. starter i adresse 0, så hopper vi til addresse 0 i vores layout map område. Her står en single-byte call til oversætteren, og oversætteren kaldes. Denne oversætter fra den oprindelige kode et stykke af programmet, typisk indtil en branch, man ikke kender retningen af, men den kan også oversætte mere.

Herefter udskifter den call-byten i layout map'en, med en jump til den oversatte kode. Nu kan vil et jump til vores addresse i kode layout map'en, medføre at vi udføre den oversatte kode. Vores kode layout map, har samme addresse layout som den CPU vi emulerer.

Stak problemer kan løses på flere måder, f.eks. ved at vi altid placerer call indstruktioner i kode layout map området. Her svarer addresserne til det originale program, og derfor gemmes de samme data på stakken, og der returneres til de samme addresser. Processorerne kan også være udstyret med features, så vi kan have call/returns der ikke står i dette område.

Når der returneres til en addresse fra stakken, så vil der i layout-map'en stå en hop addresse, til den oversatte kode efter vores call indstruktion.

Man kan forestille sig det sådan, at vi beholder de samme addresser i layout map'en, så der opnås kompatibilitet på addresse niveau. Men, vi gemmer vores oversatte kode et andet sted, så der er plads til udskejelser og tilpasninger.

Nu kan man tro at det tager masser af tid med sådan et ekstra lag bestående af en layoutmap, der primært består af call og jump indstruktioner. Det tager dog ikke ekstra tid - for processorer i dag arbejder med flere ting parallelt, og udførslen af selve indstruktionerne kører adskildt. Det at læse vores jumps og call, og håndtere stakken, foregår derfor parallelt med udførslen af kode, og tager ikke nogen tid. I dag bruges ingen tid på jumps, branches og call/return i processorer. Det er derfor ikke et problem hastighedsmæssigt med et lag der ikke indeholder andet.

Umiddelbart skulle man tro der bruges mere ram, da der både er det oprindelige lager, der er et layout map lager, og der er kode lager. Men, moderne processorer har slet ikke nogen ram. I stedet gemmes alt på harddisken. Når man ønsker et ram område, så sker det ved man åbner en fil på harddisken og bruger den. Når en fil åbnes på harddisken, så assoiceres den til et område i ram'en, og herefter kan man skrive og læse til harddisken, ved at accessere til rammen i det åbnede område. Imidlertid, så er der altid en stor ram cache, så det ikke føles som om det er harddisk, men som ram. Det betyder dog, at det er meget hurtigere at hente store programmer ind, da de ikke tager tid at hente til ram'en, for der sker intet andet end en assoicering med området. Først, når at en del af et program reelt udføres, så vil den hentes ind i ram'en. Dette opdages heller ikke, at det tager tid, for moderne processorer har en række prediction features, så den henter dataene ind før de reelt bruges, blandt andet ud fra analyse af kode. At der er reserveret mere lager til et program, medfører derfor ikke et større ram forbrug, da ram'en ikke reelt findes.

En emulering kan samtidigt optimere koden, og det er muligt at emulere en processor, så den kører ca. 10% hurtigere, på sig selv, hvis den kører ældre uoptimeret kode.

Emuleres den på konkurentens processor, kører den ofte hurtigere end original processoren, fordi at konkurenterne normalt placerer flere resourcer i CPU'en. Og, med software emulering, er muligt at opnå blandt andet parallelisering af sekventiel kode. Man har i mange år arbejdet med at automatisk parallelsiere sekventiel kode, for at kunne køre PC programmer optimalt på supercomputerne.

Oftest vil man udvikle moderne processorer med overvejelser om hvad der sker i en compiler drevet simulering i tankerne, da det er en typisk applikation. Som eksempel vil både emulering af x86 processorer, og andre konkurerende indstruktionssæt, ofte kunne udføres hurtigere, end producerenter der har oversættelse i hardwaren formår.

Det gennemprøvede valg til ARM hedder derfor Linux. Raspberry Pi er ARM baseret og langt det meste Desktop software til x86 kan også hentes til Raspberry Pi.

Re: Udfordring til Microsoft også</p>
<p>Det kræver en MMU som er i stand til at give et interrupt, når man kommer ud i indstruktioner der ikke er oversat - det er de fleste MMU'er i stand til</p>
<p>Er det ikke at gøre lige lovligt meget vold på et princip.</p>
<p>Det virker fint, hvis du forsøget at afvikle kode skrevet til en nyere processor på en gammel processor.</p>
<p>Men her er der jo tale om en helt anden familie. Altså ALLE instruktioner er ikke oversat. Det bliver et sandt interrupt helvede.</p>
<p>intet bliver hurtigere af at blive abstraheret.</p>
<p>Det betyder ikke så meget, så længe det der kan komme en optimizer på.

Du skal forestille dig det sådan, at der oversættes et lille stykke kode, og efterhånden som programmet kører, så oversættes mere og mere, og er det oversat en gang, så oversættes ikke normalt igen, med mindre at koden er modificeret, så en genoversættelse er nødvendigt.

Det kræver en MMU som er i stand til at give et interrupt, når man kommer ud i indstruktioner der ikke er oversat - det er de fleste MMU'er i stand til

Det virker fint, hvis du forsøget at afvikle kode skrevet til en nyere processor på en gammel processor.

Men her er der jo tale om en helt anden familie. Altså ALLE instruktioner er ikke oversat. Det bliver et sandt interrupt helvede.

intet bliver hurtigere af at blive abstraheret.

Du må være software mand? Alle problemer løses med at lave et abstraktionslag mere?</p>
<p>(intet bliver hurtigere af at blive abstraheret. Men udvikling af kode bliver mere effektiv. Og det tæller langt mere hvis computeren allerede er 'hurtig nok')

Hvilken CPU man vælger, og dens indstruktionssæt, betyder intet. Er processoren lavet til det, så udføres indstruktionerne ligeså hurtigt, som hvis koden er direkte skrevet til CPU'en, og det gør at designerne af operativsystemet, ikke behøver at designe det til at fungere med CPU'ens kode, men de kan have deres egen CPU kode, eller køre f.eks. X86 kode, ARM kode, motorola kode, eller anden kode med samme hastighed, som det vil kunne køre på CPU'en.

Du må være software mand? Alle problemer løses med at lave et abstraktionslag mere?

(intet bliver hurtigere af at blive abstraheret. Men udvikling af kode bliver mere effektiv. Og det tæller langt mere hvis computeren allerede er 'hurtig nok')

ARM er i øvrigt klar til samme verden som andre mainstream CPUer ;-)

https://www.version2.dk/artikel/familie-med-spectre-meltdown-arm-cpuer-ramt-ny-saarbarhed-1090765

Synes ikke de nævnte problemstillinger i denne artikel belyser emnet nok.

Hvad angår performance, så har det vist sig at iPad Pro på visse områder har bedre performance en tilsvarende MacBook. Og ARM-processorerne er jo bare blevet hurtigere og hurtigere, så det er ikke svært for Apple at se hvornår Intel er overhalet.

Hvad angår overgangen for apps, så har Apple jo også meget mere styr på denne del. Apples primære udviklersprog er swift, som jo allerede kører på ARM. Men Mac'er afvikler også Obj-C, men API'erne (frameworks) har Apple styr på, så de har formentlig et overblik og en viden om porteringen af dem, således at en app blot skal re-kompileres for at kunne køre på ARM.

Hvis det bliver ligesom de tidligere overgange, så vil Xcode lave en FAT-binary version, hvor der er maskin-kode til begge processorer i samme fil, som formentlig relativt let vil kunne kompileres ud fra eksisterende kode.

Men det vil ikke appelere til alle, der er brugere, som jeg selv, som har behov for at afvilke Windows og andre systemer virtualiseret, og det vil være en noget andet oplevelse hvis processor-instruktionerne skal konverteres af VM-programmet.

Vil man gå helt low-tech i computer forståelse kan jeg anbefale:www.turingtumble.com

Hvis man ved lidt om talsystemer og boolsk logik, men ikke ved ret meget om hvordan CPU'er fungerer, kan jeg anbefale det her ingeniørspil, hvor man starter kun med NAND gates, og så laver mere og mere avancerede byggeklodser, for til sidst at have en simpel CPU</p>
<p><a href="https://nandgame.com/">https://nandgame.com/</a&gt;

Selvom Windows findes til ARM, så vil skiftet af processor også åbne for spørgsmålet om OS også skal skiftes. x86 programmer kan jo alligevel ikke afvikles på den nye arkitektur.

Det er muligt at designet processorer, som er meget egnet for simulering baseret på compiler teknologi. Altså, hvor at maskinkoden krydskompileres i softwaren. Så snart at man kommer ud i kode, der ikke er krydskompileret, så vil MMUen generere et interrupt til compileren, så der oversættes den nye kode. Processorer designet med den type teknologi, kører med optimal hastighed - og nogle gange bedre - end de oprindelige processorer, fordi der ved compileringen af gammelt indstruktionssæt til nyt laves optimeringer på kode. Det er specielt, hvis koden der køres er af lidt ældre dato, skrevet på gamle compilere, med dårligere teknologi end i dag, at der opnås fordele. Koden kompileres over til en cache med den nye CPU's indstruktionssæt, og der holdes styr på det, så det som allerede er oversat, ikke oversættes igen. Oversætteren oversætter et lille bid af gangen, som den kan overskue. Hoppes ud i indsruktioner, der er udenfor det oversatte område, så kalder MMU'en oversætteren, og der oversættes nyt kode. Til sidst, er hele programmet oversat. Er operativsystemet udviklet til det, så kan den gemme cachen fra sidst programmet kørte, så det ikke oversættes på ny ved ny udførsel af programmet. Det tager dog ikke meget lang tid at oversætte.

X86 behøver således ikke at være et problem, men jeg mener ikke at ARM processorerne som standard er designet til at være gode til det. Det betyder, at man reelt er ligeså fastlåst som på X86 strukturen. Vælges derimod en processor type der kører optimalt med kryds kompiileringsteknologi, er man helt uafhængigt af CPU'ens indstruktionssæt, og kan køre alle CPU'ers kode i optimal tid. Man kan også vælge sin helt egen processorkode til operativsystemet og programmerne. Det muliggør, at der kan vælges mere kompakte indstruktioner, og det er muligt at udføre CISC indstruktioner, selvom processoren er RISC type. Hvilken CPU man vælger, og dens indstruktionssæt, betyder intet. Er processoren lavet til det, så udføres indstruktionerne ligeså hurtigt, som hvis koden er direkte skrevet til CPU'en, og det gør at designerne af operativsystemet, ikke behøver at designe det til at fungere med CPU'ens kode, men de kan have deres egen CPU kode, eller køre f.eks. X86 kode, ARM kode, motorola kode, eller anden kode med samme hastighed, som det vil kunne køre på CPU'en.

Mac OS er baseret på en free bsd...

Selvom Windows findes til ARM, så vil skiftet af processor også åbne for spørgsmålet om OS også skal skiftes. x86 programmer kan jo alligevel ikke afvikles på den nye arkitektur.

Det gennemprøvede valg til ARM hedder derfor Linux. Raspberry Pi er ARM baseret og langt det meste Desktop software til x86 kan også hentes til Raspberry Pi.

Så hvis en producent vælger at lave en billig ARM baseret PC, hvorfor så ikke tage skridtet fuldt ud og gå rent Open Source.

Hvis man ved lidt om talsystemer og boolsk logik, men ikke ved ret meget om hvordan CPU'er fungerer, kan jeg anbefale det her ingeniørspil, hvor man starter kun med NAND gates, og så laver mere og mere avancerede byggeklodser, for til sidst at have en simpel CPU</p>
<p><a href="https://nandgame.com/">https://nandgame.com/</a&gt;

Min matematiklærer i folkeskolen kom med et godt eksempel: En studerende var sat til at lave en lommeregner, og begyndte at lave diagrammet ciffer for ciffer. Hurtigt kom han til, at der ikke var plads nok. Det var simpelt hen beviseligt, at lommeregnere ikke kunne lade sig gøre... En chip kunne dengang ikke indeholde transistorer nok i 70'erne. Så kom en erfaren ingeniør og foreslog at den samme logik blev genbrugt og skrevet i kode. Dette eksempel viser fint, hvordan man kan opnå store besparelser i hardware ved at anvende en struktur styret af en rom eller ram. Hastigheden bliver dog mindre.

Når man laver FPGA'er gør man det samme. Ofte indeholder VHDL koden masser af små CPU'er, der kan være skrædersyet til bestemte opgaver. Derved genbruges komponenterne mest muligt. Alle opgaver, der ikke skal køre med største hastighed lægges i programmerbare strukturer, typisk CPU'er, hvor der laves decideret hardware til opgaverne, eller styres af små sekvens maskiner eller mikroprogrammerede maskiner, til helt små opgaver. Kun det, som skal køre med største hastighed laves som reelt hardware. Det er ikke ualmindeligt, at selv tællere programmeres ind i en CPU, og kun de øverste bits er i hardware. Dette fylder mindre og muliggør pladsen kan bruges fornuftigt. I dag indeholder de fleste FPGA'er derudover en større CPU, der kan bruges til tungere opgaver - men til mange mindre opgaver, er små CPU'er sagen, og der kan nemt programmeres flere hundrede soft-CPU'er i en moderne FPGA, der hver kører med flere hundrede megahertz. En soft CPU er en CPU der er programmeret i VHDL og ikke anvender den indbyggede ARM cpu - men ARM CPU'en kontrolerer normalt de forskellige CPU'er og er i stand til at kunne debugge dem.

Hvordan kan det være en revolution? Der findes allerede arm baserede Windows 10 enheder,?

Hvis man ved lidt om talsystemer og boolsk logik, men ikke ved ret meget om hvordan CPU'er fungerer, kan jeg anbefale det her ingeniørspil, hvor man starter kun med NAND gates, og så laver mere og mere avancerede byggeklodser, for til sidst at have en simpel CPU

https://nandgame.com/