Hoofdcategorieën

[RSS] Index » Nieuws » Core » Software » Onderzoekers bouwen x86-emulator in Java

Onderzoekers bouwen x86-emulator in Java

Door Martin Sturm, zaterdag 24 maart 2007 12:23
Bron: JPC, views: 26.524

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

Volgende 14:53
Vorige 11:50

Categorieën

Gerelateerde artikelen

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 76 reacties zichtbaar760 Neutraal: 76 reacties zichtbaar76+1 Meerwaarde: 39 reacties zichtbaar39+2 Verplicht leesvoer: 7 reacties zichtbaar7
«  1  2  3  »

Door dmantione, zaterdag 24 maart 2007 12:27

Score: 0
10% is netjes, maar zeker geen state of the art. Emulatoren als QEMU komen hoger, ook zonder hardwareacceleratie.

Door Tha Lord, zaterdag 24 maart 2007 14:24

Score: 2
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.

Door DOT, zaterdag 24 maart 2007 14:36

Score: 2
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.

Door daft_dutch, zondag 25 maart 2007 13:04

Score: 1
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!!!

Door Tha Lord, zondag 25 maart 2007 19:00

Score: 0
Maar dan komt het er nog steeds op neer dat x86 op x86 geen emulatie is.

Door bavanandel, dinsdag 27 maart 2007 12:03

Score: 1
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.

Door Bigben, zaterdag 24 maart 2007 19:37

Score: 0
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...

Door _ep, zaterdag 24 maart 2007 22:25

Score: 1
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.

Door MyKel, zaterdag 24 maart 2007 14:45

Score: 0
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...

Door Site.to.Make, zaterdag 24 maart 2007 14:56

Score: 1
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

Door dmantione, zaterdag 24 maart 2007 17:42

Score: 0
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.

Door ]Byte[, zondag 25 maart 2007 12:53

Score: 0
10% van wat?
10% van een 8086 of 10% van een Quad Opteron?

Door Demoniac, zondag 25 maart 2007 13:59

Score: 1
"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 ;)

Door Tukk, zaterdag 24 maart 2007 12:30

Score: 0
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?

Door Tubbie, zaterdag 24 maart 2007 12:32

Score: 2
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.

Door flowerp, zaterdag 24 maart 2007 18:02

Score: 1
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.

Door Gepetto, zaterdag 24 maart 2007 12:33

Score: 0
maar welk toegevoegd nu heeft dit?
Dat je nu eindelijk fatsoenlijk msdos op je Apple kan draaien :+

Door DOT, zaterdag 24 maart 2007 12:40

Score: 2
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.

Door DataGhost, zaterdag 24 maart 2007 12:49

Score: 0
of je zet er gewoon Linux op, wat je native kan compilen :+ Doom op je iPod \o/ :P

Door AtleX, zaterdag 24 maart 2007 12:50

Score: 1
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.

Door deathz0rz, zaterdag 24 maart 2007 12:56

Score: 0
Wat vrij veel is voor een DOS bak ;)

Door DOT, zaterdag 24 maart 2007 12:57

Score: 1
@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.

Door TRRoads, zaterdag 24 maart 2007 13:31

Score: 1
@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.

Door Koffie, zaterdag 24 maart 2007 21:35

Score: 0
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.

Door ymmv, zaterdag 24 maart 2007 12:34

Score: 1
Ehh... Vmware emuleert niet, maar virtualiseert.

Door J.J.J. Bokma, zaterdag 24 maart 2007 18:43

Score: 0
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).

Door EvilB2k, zondag 25 maart 2007 13:16

Score: 1
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.

Door The Jester, zaterdag 24 maart 2007 12:36

Score: 0
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...

Door Mark Lavrijsen, zaterdag 24 maart 2007 14:54

Score: 1
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.

Door martun, zaterdag 24 maart 2007 12:38

Score: 0
@Martin Sturm
...ze native op een x86-systeem worden gedraait.
Gedraaid is met een d.


edit: snel gewijzigd :)

Door drZymo, zaterdag 24 maart 2007 12:43

Score: 1
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)

Door flowerp, zaterdag 24 maart 2007 18:00

Score: 2
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.

Door JoenieWil, zaterdag 24 maart 2007 12:49

Score: 0
yeeeeeah! Commander Keen : Here I come B-)

Door Mister_B, zaterdag 24 maart 2007 12:51

Score: 0
een droom die werkelijkheid wordt, Keen op OS X. :9~

Door mashell, zaterdag 24 maart 2007 12:59

Score: 0
In mijn perceptie is emulatie per definitie traag en dat zelfde geldt voor java. Een emulatie in java schrijven zou dus traag2 moeten zijn, wat 10% native performance natuurlijk eigenlijk ook is.

Door bazkie_botsauto, zaterdag 24 maart 2007 14:55

Score: 0
hehe ja, wat een idioot idee uberhaupt.

je gaat toch ook geen c++ compiler schrijven in gwbasic :P

Door Neko Koneko, zaterdag 24 maart 2007 13:00

Score: 0
Wat een nieuws. Als ik Dos spul wil draaien pak ik DosBox wel ;)

Door TRRoads, zaterdag 24 maart 2007 13:29

Score: 0
Mooi plaatje.

Al dat werk en wat doe je daar dan mee? Precies oude DOS games spelen op een Mac :Y)

Door falcon4ever, zaterdag 24 maart 2007 13:33

Score: 0
kan je beter gewoon dosbox gebruiken ... die is al in zoveel smaken beschikbaar dus dan heb je dit niet nodig :)

Door VTOLfreak, zaterdag 24 maart 2007 13:30

Score: 1
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. ;)

Door DLGandalf, zaterdag 24 maart 2007 15:10

Score: 0
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

Door TRRoads, zaterdag 24 maart 2007 18:45

Score: 2
@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/

Door JeromeB, zaterdag 24 maart 2007 18:44

Score: 0
Ik meende dat ARM een platform had dat Java-bytecode direct kon uitvoeren.

Door cybergen007, zaterdag 24 maart 2007 13:58

Score: 1
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.

Door johnbetonschaar, zaterdag 24 maart 2007 14:46

Score: 1
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...

Door Mitsuko, zaterdag 24 maart 2007 16:38

Score: 1
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))

Door JeromeB, zaterdag 24 maart 2007 18:39

Score: 2
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.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 14:53
Vorige 11:50
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: