Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Onderzoekers bouwen x86-emulator in Java

Onderzoekers van de Oxford University hebben een x86-emulator ontwikkeld die volledig is geschreven in Java. Hierdoor is het mogelijk om op elk apparaat waarop een Java Virtual Machine kan draaien, x86-programma's uit te voeren.

De nieuwe emulator, genaamd JPC, is momenteel alleen in bŔtaversie beschikbaar voor medewerkers van de Oxford University. Volgens de onderzoekers heeft de implementatie in Java diverse voordelen. Met name op het gebied van veiligheid en flexibiliteit zou JPC concurrerende producten overtreffen. Doordat alle code in pure Java is geschreven, draait alles binnen de virtuele machine die de Java-code uitvoert, waardoor veiligheidsproblemen geen risico vormen voor de rest van het computersysteem. Ook heeft het gebruik van Java automatisch tot gevolg dat de emulatiesoftware te gebruiken is onder Windows, Linux en Mac OS X, maar ook op minder gangbare hardwareplatformen zoals ARM- en Sparc-processors. Een van de mogelijkheden die de researchers benadrukken, is de mogelijkheid om JPC te draaien op draagbare apparatuur zoals mobiele telefoons en pda's.

Het emuleren van x86-processors in Java werd tot nu toe onrealistisch geacht vanwege de complexiteit van x86-rekeneenheden, waardoor geen werkbare emulatiesnelheid zou kunnen worden behaald. Er zijn al geruime tijd emulatoren geschreven in Java voor andere hardwareplatforms, waaronder Commodore 64, Atari ST en ZX Spectrum, maar die platformen zijn beduidend eenvoudiger dan de x86-architectuur. Met JPC tonen de onderzoekers aan dat het mogelijk is om ook x86 te emuleren in Java. Volgens de researchers die JPC hebben ontwikkeld is de snelheid van de emulatiesoftware zeer goed. JPC zou in staat zijn een snelheid te halen die gelijk is aan 10% van de native processorsnelheid van het systeem waarop de emulator draait, waarmee JPC tot de snelste emulatoren voor x86 zou horen, zo beweren de onderzoekers. Ze verwachten dat de snelheid op termijn nog zal verbeteren, aangezien in sommige gevallen JPC programma's sneller uitvoert dan wanneer ze native op een x86-systeem worden gedraaid. Dit laatste wordt veroorzaakt door de HotSpot JVM die optimalisaties uitvoert die een normale compiler niet beheerst. JPC is momenteel nog niet voor het algemene publiek beschikbaar; ook is niet duidelijk of de broncode onder een opensourcelicentie wordt vrijgegeven.

JPC op iMac

Door

Nieuwsposter

76 Linkedin Google+

Bron: JPC

Reacties (76)

Wijzig sortering
Dus het JPC programma leest de insstructies van het te emuleren programma. Deze worden vervolgens in java byte code instructies uitgevoerd welke op het host systeem weer door de JRE uitgevoerd worden als host instructies. Lijkt me een beetje dubbel op. Zolang ze iedere instructie appart uitvoeren zal het niet snel zijn. Als ze intelligent meerdere instructies tegelijk bundelen en die in een java instructie uitvoeren dan kan ik wel een kleine snelheidswinst verwachten. Maar denk niet dat ze ooit boven de 50% uit kunnen komen.

Het kan natuurlijk handig zijn als je met andere hardware zit en graag een x86 programma wilt draaien. :Y)
Dus het JPC programma leest de insstructies van het te emuleren programma. Deze worden vervolgens in java byte code instructies uitgevoerd welke op het host systeem weer door de JRE uitgevoerd worden als host instructies.
Er zijn een paar interessante mogelijkheden. Deze emulator kan als 'gewoon' Java programma ge´mplementeerd zijn. In dat geval zal de JVM JIT compiler alleen de instructies van de emulator zelf naar native gaan omzetten, maar niet de instructies van het programma wat geemuleerd wordt.

Deze laatste is voor de JVM namelijk gewoon "data'.

JPC kan echter ook gebruik maken van speciale mogelijkheden van de JVM en als het ware x86 een andere 'taal' laten zijn voor de JVM; het zet dan zelf de x86 code om in bytecode, en de JVM zal deze dan (op een gegeven moment) vertalen naar native instructies.

Nog een andere mogelijkheid is dat op een of andere manier de compiler API van JDK 6 wordt gebruikt. x86 zou dan omgezet kunnen worden naar Java code, die de JDK kan vertalen naar bytecode, en die de JVM dan weer naar native vertaald. Dit lijkt me iets minder voor de hand liggen, maar het kan wel zeker. Sommige andere (met name static binary translators) gebruiken nog wel eens de techniek om vreemde code eerst in C om te zetten, zodat ze de omzetting + optimalisatie naar native niet zelf hoeven te doen, maar daar de gewone compiler chain voor kunnen gebruiken.
Oftewel, zoals Vmware op verschillende OS-en draait en je een x86 emulatie geeft hebben ze dit nu nagebouwd in Java, maar dan met een complete java-runtime er tussen, zodat het nooit zo snel kan performen als een VmWare dat native code heeft gemaakt voor elke ondersteund OS.

Indien het aantal OS-en schier oneindig zou zijn, zou dit een oplossing zijn, maar welk toegevoegd nu heeft dit?
Vmware emuleert de processor niet maar onderschept geheugen- en io-transacties. Dat is beduidend minder werk(in cpu tijd) en daarom niet te vergelijken.

Met andere woorden, je moet een x86 processor hebben om een x86 besturingssysteem binnen vmware te kunnen draaien.
Vmware emuleert de processor niet maar onderschept geheugen- en io-transacties.
De gewone VMWare (dus niet de hypervisor versie) emuleert wel de protected mode instructies (geheel of gedeeltelijk). User mode instructies gaan 1:1 naar de host CPU.
maar welk toegevoegd nu heeft dit?
Dat je nu eindelijk fatsoenlijk msdos op je Apple kan draaien :+
Daar zeg je wat... veel portable media players hebben een ARM proc. Daar kan je dan dus DOS op installeren en allemaal lache games gaan spelen. :P

Alleen jammer dat mijne maar 200 Mhz is. Dat wordt dus 20 Mhz na emulatie.
Niet helemaal waar, de hoeveelheid megahertzen zegt niet alles over de snelheid. Kijk maar naar de aloude vergelijking Athlon XP <-> Pentium 4. Je kan ook niet zomaar je kloksnelheid door 10 delen, want sommige instructies zullen sneller uitgevoerd kunnen worden dan de andere.
@DataGhost

Natuurlijk zet je er eerst Linux op, de emulator moet immers ergens op draaien. ;) Maar ELF-progs compileren voor een andere architectuur dan de host is nog best lastig. Een java-based emulator is toch wat makkelijker, en je hebt meteen alle DOS-games tot je beschikking.
@DOT:

Cross architecture compileren is ook weer niet zo moeilijk, ik doe het regelmatig voor mijn GP2X.

Probleem is alleen dat je voordat je kunt compileren je de source moet hebben en dat is niet vaak, zeker niet met die leuke oude DOS games.
20 Mhz veel voor een DOS bak :?
En dan ook nog inzichtvol.
12-20 Mhz is de snelheid van een 286. Daar draaide we idd DOS op, maar dat deden we ook op onze 486-DX2-50 @ 50 Mhz
De Pentium kwam in '93 op de markt (op 60 Mhz), wat dus voor de tijd van Windows 95 (duh :P) was waardoor we dus nog steeds met DOS / Windows 3.x werkte.
of je zet er gewoon Linux op, wat je native kan compilen :+ Doom op je iPod \o/ :P
Wat vrij veel is voor een DOS bak ;)
Volgens mij is het onmogelijk om, laten we zeggen, op een PPC-platform onder VMware Windows te draaien.
VMware kan allerlei OS'en in een virtuele omgeving draaien op x86 hardware.

Ik zie niet iemand Vista draaien op een RS-6000 met behulp van VMware...
Dat komt dus, doordat vmware geen emulator is, maar instructies van de vm's scheduled op de processor. RS6000's hebben geen X86 processor, dus kan je ook niet met behulp van vmware X86 code op draaien. Daarvoor heb je dus een emulator nodig.
Ehh... Vmware emuleert niet, maar virtualiseert.
Ben benieuwd hoe je precies het verschil tussen die twee gaat uitleggen (echt uit nieuwsgierigheid, ik gok dat een deel dit roept zonder het verschil uit te kunnen leggen of zich af te vragen of er een verschil is).
Heel simpel: emuleren is cpu nabootsen... virtualiseren is doorgeven naar de host processor, maar wel de geheugen gebieden van elkaar afschermen zodat VM a niet in het bereik van VM b kan kijken. Zeker sinds de hardware matige ondersteuning van Intel en AMD zie je dat deze technieken erg goed werken. Parallels verbruikt met het draaien van windows maar een paar % processor verbruik, omdat de deze alleen maar vraagt wat hij daadwerkelijk nodig heeft en niet (zoals de gemiddelde emulator) maar gewoon een x aantal CPU cycles opeist.
10% is netjes, maar zeker geen state of the art. Emulatoren als QEMU komen hoger, ook zonder hardwareacceleratie.
Dat is een krom voorbeeld wat je geeft. QEMU draait alleen op een x86 processor en wanneer je in QEMU een x86 systeem gaat "emuleren" ben je in feite aan het virtualiseren in plaats van emuleren. De x86 instructies hoeven dus niet vertaald te worden en kunnen dus bijna met native snelheid uitgevoerd worden.
VMWare is op de pc ook sneller dan onder een powermac G4/G5 omdat er onder de 2e daadwerkelijk geemuleerd moet worden.
Qemu draait niet alleen op x86, en emuleert ook niet alleen x86:
http://fabrice.bellard.free.fr/qemu/status.html

Het is wel zo dat Qemu alleen snel is met kqemu, en dat is x86 -> x86 only.
Nou je kan Qemu kernel module gebruiken voor wat meer snelheid. KVM in natuurlijk sneller. omdat dat de visualisatie van de nieuwe processoren gebruikt.

Meer On topic. Ik vind dit geen goede ontwikkeling. VM's zijn eigenlijk al een teken van zwakte. En een VM in een VM is dan een zeer groot zwakte bod.
Compileer gewoon de applicaties voor alle omgevingen!!!
Maar dan komt het er nog steeds op neer dat x86 op x86 geen emulatie is.
Compileer gewoon de applicaties voor alle omgevingen!!!
Haha grapje zeker...
Wat dacht je van antieke applicaties waarvan de source niet meer beschikbaar is? Wat denk je uit te geven aan dit soort grappen? Sowieso is het vaak niet mogelijk zonder processor/compiler-specifieke code een app te compileren voor alle mogelijke (!!!) omgevingen. Een hel dus.

Als zo'n emu-systeem dit werk overbodig kan maken is dat een zeer goede ontwikkeling.
De pc-emulatoren voor de Mac, toen van PowerPC naar x86, draaiden toch al ruim boven de 10% native snelheid ?
Alleen de grafische snelheid is bij dit soort emulatoren meestal traag...
Die zijn echter niet in Java geschreven. Een snelle emulator maken hoeft niet zo moeilijk te zijn, als je hem maar specifiek voor een bepaald platform ontwikkelt zodat je kunt optimaliseren voor die specifieke processor/architectuur.

Het laten draaien in Java betekent dat je veel van die technieken niet kunt gebruiken (al zal de Java VM die rol wel wat overnemen) en natuurlijk is Java normaal al niet de snelste.
ie gelijk is aan 10% van de native processorsnelheid van het systeem waarop de emulator draait, waarmee JPC tot de snelste emulatoren voor x86 zou horen, zo beweren de onderzoekers.

Dus ook sneller dan QEMU en QEMU/KVM....
Overigens tot mijn verbazing. Had het 'gevoel' dan QEMU/KVM wel sneller dan 10% zou draaien...
Met QEMU en KVM kan je geen applicaties op andere soorten processors draaien. Je kan hiermee een 2e besturingssysteem draaien.

Met deze emulator kan je dus een applicatie geschreven voor x86 draaien op bv een powerpc mac
Je kunt met QEMU prima x86-code op een PowerPC draaien, alleen de hardwareacceleratie (kqemu) is dan niet te gebruiken. Hoeft ook niet, want juist zonder die hardwareacceleratie kan je een eerlijke vergelijking maken.
10% van wat?
10% van een 8086 of 10% van een Quad Opteron?
"JPC zou in staat zijn een snelheid te halen die gelijk is aan 10% van de native processorsnelheid van het systeem waarop de emulator draait, waarmee JPC tot de snelste emulatoren voor x86 zou horen, zo beweren de onderzoekers."

Staat gewoon in het artikel ;)
Zou wel eens interresant kunnen worden in combinatie met een CPU die native Java-bytecode kan uitvoeren. Heb je ineens een processor die alle bestaande (en toekomstige) architecturen kan na-apen. ;)
soort van een cpu, die een java runtime environment nodig heeft.
maar een JRE vertaalt eigenlijk de bytecode naar de onderliggende architectuur, in ieder geval iets wat niet bytecode is. Dus we hebben een OS nodig.
dus jouw droombeeld van de perfecte cpu is eigenlijk een beetje onmogelijk, of heel mogelijk want eigenlijk hebben we dat nu gewoon op dit moment

maar 1 ding uit je verhaal: native en java gaan niet samen
@DLGandalf:

http://en.wikipedia.org/wiki/PicoJava

picoJava is a microprocessor specification dedicated to native execution of Java-based bytecode without the need for an interpreter or JIT compiler

:Y)

Hij bestaat niet echt, maar er zijn meerdere native Java CPU's voor zo ver ik weet, en als je er een wil maken dan kan dat dus mbv dit ontwerp, bijvoorbeeld in een FPGA.

Zie bijvoorbeeld ook deze CPU: http://www.jempower.com/ajile/content/view/20/27/
Ik meende dat ARM een platform had dat Java-bytecode direct kon uitvoeren.
Ik merk dat er veel mensen zijn die hier klagen dat het allemaal traag is en dat zij het vergelijken met VMWare.

Kijk nou naar het programma zoals het is. Je kan nu x86 draaien op elk platform dan ook waar Java op draait. Natuurlijk zit er Java tussen en wordt het trager maar het is gewoon heel mooi dat je nu bijvoorbeeld MS-DOS kan draaien onder Linux of op een Mac. Ik vind het een knappe prestatie.
Ik zal niet ontkennen dat er een (kleine) niche-markt is voor DOS emulatie op verschillende platformen, maar volgens mij wordt de bruikbaarheid en het nut van deze emulator toch echt behoorlijk overschat... Ik snap om te beginnen al niet helemaal waarom je nou juist zo graag x86 zou willen emuleren, terwijl zo'n beetje alle moderne CPU's dat als native instructieset gebruiken... Vooral gezien het feit dat x86 zo'n beetje de meest complexe instructieset is en dus per definitie moeilijk te emuleren op meer RISC-achtige systemen... :?

De enige toepassingen die ik kan verzinnen is het draaien van superoude meuk op niet-x86 platforms, waarmee je automatisch op ARM en MIPS uitkomt. Als dat het doel is, waarom dan niet gewoon een native implementatie die wel fatsoenlijke performance haalt? Voor bijvoorbeeld PPC zijn allang goede native x86 emulators beschikbaar die veel betere performance halen dus daar hoef je het niet voor te doen.

Met andere woorden, ik ben absoluut niet onder de indruk. Ik ben best redelijk goed geinformeerd op het gebied van emulators en hoe ze werken, en als ik toch zie dat er emulators bestaan die PSX, PS2, Gamecube, Saturn, Dreamcast etc. etc. kunnen emuleren op systemen met niet meer dan 3x of 4x de power van het geemuleerde systeem dan vind ik dit resultaat een beetje zonde van de tijd...
Emulators voor dat soort systemen zijn over het algemeen 'game-emulators'. Wat dat inhoud is dat ze spellen emuleren, en niet de hardware - het hoeft allemaal niet perfect te zijn. Neem eens een kijkje naar bsnes (en hier) voor een 'console-emulator'. Deze emuleert de SNES - en al bijna perfect - maar je hebt helaas wel een Core 2 Duo E6600 of iets van die trand nodig om het op volle snelheid te draaien. (het is in C++ geschreven dus assembly zou sneller zijn, maar gebruikt al wel interessante optimalisatietechnieken zoals 'libco' (zie website))
Je hebt inderdaad zogenaamde High Level Emulators. Deze emulators emuleren niet de hardware of de spellen, maar ze emuleren sofware-functies die het systeem te bieden heeft. Een aantal next-gen-game-emulators maakt inderdaad gebruik van deze techniek, maar een groot aantal ook niet.

De meest bekende SNES-emulators (ZSNES en SNES9X) werken niet volgens dit principe, maar emuleren gewoon de hardware. bsnes is bij mij niet bekend.

Theoretisch kunnen programma's geschreven in Assembly sneller zijn dan programma's geschreven in C++. In de praktijk blijkt dat C++-compilers vaak zo goed geoptimaliseerd zijn dat het heel moeilijk is om in Assembly een sneller programma te maken. Het is dan vaak verstandiger om je programma te schrijven in C of C++. Specifieke functies die veel snelheid vereisen zou je kunnen optimaliseren door inline Assembly te gebruiken.
Ze verwachten dat de snelheid op termijn nog zal verbeteren, aangezien in sommige gevallen JPC programma's sneller uitvoert dan wanneer ze native op een x86-systeem worden gedraaid. Dit laatste wordt veroorzaakt door de HotSpot JVM die optimalisaties uitvoert die een normale compiler niet beheerst.

Ah, het is de magische Java supercompiler die een emulator zoveel sneller kan maken dat de geemuleerde software nog sneller draait dan op de oorspronkelijke machine!

Dus in de toekomst kunnen we Windows booten, daar een JVM in starten, daarbinnen opnieuw Windows booten, en daarbinnen opnieuw een JVM starten zodat we dubbele speedup krijgen! En waarom zouden we daar stoppen? We kunnen telkens opnieuw JVM's en Windows sessies starten, en zo steeds meer performance uit onze hardware krijgen. To infinity, and beyond!

Java compilers: is er dan niets wat ze niet kunnen? :+
Vreemd, het enige wat Java niet kan wordt als logo gebruikt?
Dus het enige wat Windows niet kan is ramen wassen...
Ik weet het, het klinkt belachelijk. Praktisch gezien zul je dit ook niet vaak zien, maar theoretisch is het zeker mogelijk.

De HotSpot compiler gebruikt adaptieve optimalisatie waardoor deze snelheidswinst mogelijk is.
waarom niet?
het zal alleen een hoop overhead gaan kosten in de vorm van geheugen
dat is nl de eeuwige afweging tussen snelheid en geheugen
Jave compilers: is er dan niets wat ze niet kunnen? :+
[bijdehandmodus]
Ja, ik heb nog nooit iemand een kopje koffie zien compileren met java.[/bijdehandmodus]

[edit]Nijn was me voor... :S
Ok, ik geef toe, het is leuk.

Maar in principe zul je geen gek vinde die x86 onder Java wil draaien. Ik bedoel, op niet-native JavaVM's loopt Java al niet echt optimaal, en is niet bedoeld voor zware toepassingen. Laat staan als je dan ook nog een x86 moet gaan emuleren. Dat gaat een behoorlijk stukje geheugen en processorkracht verbruiken (lees: verspillen).

Wat ze zeggen is dat ze 10% van de native/host CPU rekenkracht kunnen halen. Ik zie in het stukje tekst alleen niet het percentage CPU rekenkracht van de host CPU wat daadwerkelijk gebruikt wordt. Dit zou 100% kunnen zijn waardoor je voor de rest niks kunt. Daarnaast, 10% van een gemiddelde GSM/telefoon CPU is nie zo veel...

Op native JavaVM gebied zou het in principe interessant kunnen zijn, maar native JavaVM kom je niet vaak tegen, en als je het tegenkomt kun je beter gewoon een embedded bordje met x86 proc zoeken, of gewoon native gaan programmeren...

Oftewel nutteloos, maar leuk voor ze dat het ze gelukt is. :Z
Ik bedoel, op niet-native JavaVM's loopt Java al niet echt optimaal, en is niet bedoeld voor zware toepassingen.
Ik denk dat als je kijkt op welk platform de meeste zware toepassingen draaien, dan zul je zien dat dit vooral legacy systemen zijn (zoals Cobol) en de rest vooral Java. MS probeert wat van deze markt af te snoepen met .NET, maar tot nu toe hebben ze daarmee vooral succes in het MKB segment.
Ik denk dat iedereen wel onderschat waar Java allemaal op draait.
Veel mobiele telefoons hebben java ondersteuning. Die zouden nu in theorie ook een normale software omgeving kunnen draaien.
Verder zijn er set-top boxen die java draaien. En vergeet niet de systemen met een java processor (als in: de processor is zelf de JVM).
Hiermee zou je veel meer kunnen.

Niettemin is dit natuurlijk ook weer een pluspunt voor Java (en indirect Sun) en zal de taal meer aandacht krijgen. :)
Ik denk dat dergelijke projecten meer de honger naar technologie van de onderzoekers stillen dat dat het daadwerkelijk nuttig wordt om te gebruiken. Het is veel te theoretisch. Helemaal tegenwoordig waar code goed portable is zal een bedrijf uit economisch oogpunt snelheid boven veiligheid stellen.
Het is zeker niet zo dat deze emulatie langzamer is dan een emulator in C, zoals de onderzoekers zelf ook al benadrukken. Het voordeel van een emulator in Java is dat je hem kunt draaien zodra je een jvm hebt, dat is bij een in C geschreven emulator niet het geval, daar zul je toch diverse libraries moeten hebben en minimaal een C-compiler met voldoende features. Voor mobiele telefoons is er tegenwoordig wel een jvm, maar zeker niet alle libraries voor c.
Het is zeker niet zo dat deze emulatie langzamer is dan een emulator in C, zoals de onderzoekers zelf ook al benadrukken
Ah ja, het eeuwige argument dat een java app in theorie sneller kan zijn dan z'n native tegenhanger. Hoewel dat idd waar kan zijn aangezien de JVM tijdens het runnen van de app meer info over die app en de host CPU heeft dan tijdens het native compilen van zo'n app, moet ik de eerste compiler (jvm of native) nog zien die van normale programmacode machinecode genereert die optimaal gebruik maken van host instructieset, en dan denk ik met name aan SIMD instructies. Imperatieve code is namelijk lastig geautomatiseerd te paralleliseren. Een C++ applicatie dat door middel van compiler intrinsics geoptimaliseerd is om floatingpoint berekeningen in SSE te doen kan nooit op eenzelfde manier in Java geimplementeerd worden. En de generieke implementatie, waarbij gebruik wordt gemaakt van de standaard scalars (floats), compileren weer niet naar SSE code (zowel niet in C++ als in Java).

En in dit specifieke geval, een x86 emulator, emuleert dus ook SSE code. Nou ga ik me toch sterk afvragen hoe ie die code in hemelsnaam efficient moet gaan emuleren in Java, waar het hele concept SIMD niet bekend is (terwijl alle hedendaagse high performance CPUs het wel kennen). Ik denk dat Java er wat dat betreft goed aan doet om een dergelijk concept voor het platform te introduceren. Het is namelijk een stuk makkelijker om SIMD operaties af te vangen met reguliere SISD operaties (dus gaat het niet tegen het WORE principe van Java in), dan om SISD code om te zetten naar SIMD :)
En in dit specifieke geval, een x86 emulator, emuleert dus ook SSE code
Ik betwijfel of ze al zover zijn, aangezien ik nergen heb gelezen welke generatie x86 ze volledig kunnen emuleren en de SSE instructies pas in de Pentium III is ge´ntroduceerd.

Zeker als je ziet dat ze het vergelijken met de C64 e.d. lijkt het me dat ze hier eerder de instructieset van de 286 of wellicht tot de 386 volledig ondersteunen
net zoals mijn voorgangers: leuk, knappe prestatie.. maar wat moet je d'r mee ?

Kan iemand mij uitleggen waarom ze java hiervoor gekozen hebben ?
Hadden ze dit niet beter in C (oid) kunnen schrijven, er zijn toch C compilers voor elk platform ?

Komt die 90% performance loss door hun emulator code of door het gebruik van java hiervoor ?
Wij tweakers hoeven er niks mee, behalve ontzag te hebben voor de geesten die dit hebben bedacht ;)

Die Oxfordianen schieten er wel een heel stuk mee op. Als ze ergens solliciteren en ze vertellen tussen neus en lippen door dat ze laatst een x86 emulator hebben gebouwd in Java, dan is de baan binnen. Er zijn wel meer hele moeilijke dingen waar je niet zo veel mee opschiet.

Ze hebben voor Java gekozen zodat ze de code konden omzetten naar Java bytecode. Zo hoef je niet voor elk specifiek platform een andere emulator te bouwen, dat heeft Sun al gedaan. (voor een deel iig)
(ik bedoel: ze zetten de x86 instructies niet om naar C om het daarna te compileren, maar ze zetten het indirect meteen om naar andere machine instructies.)

Ik denk dat de performance loss vooral komt door emulator code. Je kan je nauwelijks voorstellen hoeveel instructies het kost om 1 instructie om te zetten naar de andere. Als C was gebruikt dan was er misschien een aantal procenten winst geweest qua snelheid, maar was het ontwikkeltraject een heel stuk langer geworden.

De Java interpreter is ideaal voor dit soort academische situaties.
...maar dit betekent nog niet dat de geŰmuleerde applicatie ook de libraries krijgt die het anders op een x86-based systeem ter beschikking zou hebben. Denk maar aan de win32 api, of linux' libs of gewoon de DOS calls. Die kun je vergeten, lijkt me.
Natuurlijk kun je die vergeten, om de heel simpele reden dat je bij het simuleren van een processor helemaal niks met libraries te maken hebt. Het enige waar je mee te maken hebt is de x86 instructie set. Niks meer, niks minder.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*