Hoofdcategorieën
Device Settings

Transitive werkt aan supersnelle machinetaal-vertaler

Door Mark Timmer, woensdag 13 juni 2001 13:23
Bron: New Scientist, views: 690

Vertaalprogramma's voor machinetaal bestaan al een tijd, maar New Scientist schrijft dat het bedrijf Transitive Technologies nu met een revolutionair product op dit gebied bezig is. Het doel ervan is simpel: programma's die voor bijvoorbeeld een Macintosh geschreven zijn, werken niet zomaar meteen op een 'normale' x86-thuiscomputer. Beide chipsets gebruiken een andere machinetaal, waardoor het programma normaal gesproken slechts voor één van de twee gemaakt kan worden. Nu werkt het product, Dynamite, als volgt:

Dynamite
Het programma werkt dus als een soort tussenpersoon, die de taal van CPU A en van CPU B kan lezen en schrijven. Op die manier wordt kan een voor CPU A gemaakt programma omgezet worden zodat het op CPU B werkt, en andersom. Dit soort programma's bestaan al wel een tijd, maar Transitive claimt dat Dynamite een stuk sneller werkt.

Veelgebruikte commando's worden opgespoord voor snellere omzetting, via een technologie waar zo'n 10 jaar aan gewerkt is. Bovendien schijnt de engine eenvoudig aangepast te kunnen worden voor een andere machinetaal, zodat een breed publiek makkelijk te bereiken is. Het klinkt allemaal veelbelovend, dus ik denk dat we hier vast nog wel meer over gaan horen. Toekomstige tests zullen uitwijzen, of de techniek inderdaad zo goed werkt als men beweert.
Volgende 18:33 AMD Palomino 1,46GHz benchmark resultaten
Vorige 12:32 Windows XP zal toch geen MP3-encoder bevatten
Advertentie

Reacties

«  1  2  »

En hoe zit dat dan met de implementatie van instructies voor hardware die op de andere architectuur simpelweg niet bestaat?

emuleren, wort nu ook al gedaan bij directx, als je videokaart de functie niet ondersteunt dan vertaalt DX de instructies voor je cpu (wel performance drain ntuurlijk) ipv je videokaart, denk dat ze ook hier zoiets gaan gebruiken

Ik denk dat het sowieso niet de bedoeling is dat je een bak met ingewikkelde software in dit algoritme kunt gooien en dat er dan meteen prachtig werkende programmacode voor een ander platform uitkomt. Als je zo bijvoorbeeld je besturingssysteem zou laten vertalen, dan wil dat echt niet zeggen dat het resultaat dan op een MAC of een Alpha zou draaien. Dat kan ook niet, want beide computers zijn intern inderdaad heel verschillend en ik betwijfel of deze vertaler daar in eerste instantie rekening mee houdt. Ik denk dat de vertaler eerder is bedoeld voor bijvoorbeeld ingewikkelde algoritmes. Stel dat je de distributed.net client als invoer zou gebruiken, dan komt er in een mum van tijd een goed resultaat uit. Als je een heel operating system wilt vertalen, dan kun je die tool ook wel gebruiken, alleen zul je de code nog na moeten lopen.

Anders is dat bijvoorbeeld bij Transmeta. Zij staan in het artikel ook genoemd als een bedrijf wat aan dezelfde soort technologie doet:
Transmeta, a start-up silicon valley microchip maker, has created a layer of "code-morphing" software to allows software written for Intel's microchips to run at roughly the same speed on its own, low-power chips.
Zij kunnen die code voor hun eigen proc gewoon morphen, omdat de rest van het systeem niet fundamenteel anders is, dan waar de code voor bedoeld is.

Over het algemeen ben ik altijd sceptisch als ik dit soort berichten lees, maar Transitive Technologies is niet zomaar een bedrijf: als ik het goed heb is het een onderzoeksinstituut van de universiteit van Manchester. Dat zou toch wel eens kunnen betekenen dat ze behoorlijk ver zijn op het gebied van deze technologie en dat we, zeker in de toekomst, nog veel zouden kunnen verwachten van deze techniek. Als je die techniek bijvoorbeeld in elke computer zou implementeren, dan hoef je volgens mij ook geen x86 cpu te hebben om x86-programma's te draaien!

Klein detail :
Je zegt
"Als je een heel operating system wilt vertalen, dan kun je die tool ook wel gebruiken, alleen zul je de code nog na moeten lopen."

Omdat deze vertaler machinetaal leest en machinetaal schrijft, denk ik dat het haast onmogelijk is om de code nog te overlopen. Voor Operating Systems lijkt het me ook niet echt nuttig omdat indien een bedrijf zijn Operating System op een andere processor wil doen werken, gewoon de originele source code in C ofzo zal gebruiken en deze met een compiler voor het andere systeem compileren. Dan kan hij wel de code eerst aanpassen voor dit systeem.

Dit lijkt me inderdaad eerder nuttig om programma's op processors met andere/nieuwere infrastructuur te doen werken. (Misschien de oplossing om over te stappen naar 64-bit processoren, ipv in de 64bit processor een deel te steken om 32-bit te emuleren)

Ehhhh, gaat dit op het mobo?
Of moet ik toch meer denken aan PCI-kaart waar de processoren op komen. :?

Verder is het wel interresant, zo'n dedicated emulator. :)

Volgens mij is het een software oplossing... :?

er staat
Het programma werkt dus als een soort tussenpersoon

Dit is eigenlijk dus gewoon een uitgebreide emulator. En zoiezo kan het nooit goed tussen alle architecturen werken.. zo gebruiken sommige interrupt based i/o en andere weer memory mapped i/o.. dan word het dus heel traag of heel beperkt.
Voor cross-platform developement hebben we al Java, waarom nu nog een keer zoiets maken?

Ruik ik hier MacOS X op X86?? :o


wat heeft DAT er nu weer mee te maken :? :?

Eigenlijk kan dit gewoon geen nut hebben. Je hebt 2 soorten software, Open en Closed source.

Open Source software kun je net zo goed opnieuw compilen voor het andere platform, dus dan is zoiets als dit niet nodig.
Voor Closed Source software zou het wel handig zijn, maar ik kan me niet voorstellen dat het zomaar zondermeer bij elk programma werkt, dus dan moet je weer medewerking van de fabrikant hebben om bepaalde aanpassingen te doen en de kans dat je die krijgt is vrij klein.

Nou, open source zo maar even opnieuw compilen voor een ander platform gaat denk ik niet zomaar, dat is het probleem met de verschillende architectuur/ instructies.


Je hebt daar dan toch een soort compiler als dynamite nodig, die beide instructiesets kent.


Closed source software is precie hetzelfde verhaal, je hebt toch de source nodig voor die dynamite compiler.

edit: ff die vage tags weggehaald

De meeste Open Source software is zo goed geprogrammeerd dat je het onder een heleboel platformen kunt compileren, zowel hardwarematig als softwarematig. Gnome werkt bijvoorbeeld net zo goed op Solaris op een UltraSPARC's als op Windows op een x86. maar vrijwel alle apps kunnen dat wel.
Het voordeel aan Open Source is dat je het zelf kunt gaan compileren als de fabriekant er geen zin in heeft.

Ik zie niet in waarom software die niet specifiek is voor bepaalde hardware (en eigenlijk zijn alleen de drivers specifiek, scanners kunnen b.v. via twain worden benaderd,netwerken via tcp/ip drivers, etc.) niet zou kunnen worden vertaald.
Als je software alleen maar geschreven is voor bijvoorbeeld windows dan is het helemaal een makkie, dan hoef je alleen maar te zorgen dat er een vertaalslag is voor windows interfacing naar ...interfacing (kylix van borland is een voorbeeld dat dat makkelijk kan tussen windows en linux) omdat je helemaal niets hoeft te doen voor hardwarespecifieke muis, toesenbord, beeldscherm, etc. aansturing, dat zit al in het OS van dat systeem.

Misschien dat cd-r software niet zal werken, maar je overige code zou best vertaald kunnen worden. Java is eigenlijk een perfect voorbeeld. Hier wordt code gecompileerd naar machine code voor een "java virtual machine" en wordt op het systeem van de gebruiker die code vertaald naar machinecode voor dat systeem. Ik geloof dat WordPerfect ook in java-versie bestaat, dus het is ook best mogelijk om complexe programma's te vertalen.

Ben benieuwd wat ze doen met code die specifiek geoptimalliseerd is voor een bepaald platform.
Dat zal toch inzekere mate het succes van deze engine bepalen.

is dit en antwoord op je vraag??
Bovendien schijnt de engine eenvoudig aangepast te kunnen worden voor een andere machinetaal, zodat een breed publiek makkelijk te bereiken is

Tijd terug stond er een uitstekend stuk op www.ars-technica.com . Over code morphing door HP voor hun eigen processors. Daarbij emuleerde ze hun eigen instructieset op hun eigen instructieset.
Waardoor het wonderbaarlijk sneller werd!
Echt super goed stuk, zie hier: http://www.arstechnica.com/reviews/1q00/dynamo/dynam o-1.html

Dat is exact hetzelfde wat de Spintel kaart software doet. Die past on-the-fly brakke 80386 code geoptimaliseerd aan voor de Pentium III.

Een transmeta processor doet dit ook intern. Daardoor is hij heel makkelijk aan te passen. Heel raar eigenlijk, maar wel heel goed bedacht!

Ziet er erg leuk uit, maar ik denk dat er een paar serieuze muren moeten overklommen worden;

Een simpel voorbeeld in C: (unsigned int = 32bit)
{
unsigned char tabel[6];
unsigned int temp1, temp2;

temp1 = *(unsigned int*) (tabel);
temp2 = *(unsigned int*) (tabel + 2);

temp1>>=6;
temp2>>=6;

*(unsigned int*) (tabel+2) = temp2;
*(unsigned int*) (tabel) = temp1;
}

(het programma verschuift een array van 6 bytes 6 bits naar rechts)

Als je dit compileert voor een motorola CPU (big endian), dan werkt dit zalig.
Op een x86 CPU is dit dik bagger door zijn little endian 32-bit laden.

Als dat programma zo'n conversies vlekkeloos kan uitvoeren : knap!, maar ik ben er bang voor.

Er zijn legioenen verdronken (of alleszins hun haren uitgetrokken) met little-endian <-> big-endian problemen. (8>

dit programma doet toch niks met de c source.. het doet iets met de x86 machinecode en zet die om naar bijvoorbeeld powerPC machinecode..

of dit precieze probleem dus toevallig zal werken of niet ligt niet op het niveau van C, maar meer of dit probleem op machinecode kan worden opgelost, zo nee.. dan moet het programma gaan emuleren, tegen een performance prijs.

(kan me trouwens voorstellen dat als je die array van 6 bytes ergens in een register hebt staan op een x86 dat je die met 6 klokslagen al gemoved hebt, en een paar meer als je de stack overflow aan de andere kant er weer in schuift, en de richting maakt dan niet zoveel uit)

Wat Nutfreak gewoon bedoelt is dat als je een bitshift doet en je gaat van Big naar Little endian of andersom dat je dan een probleem gaat hebben.

Een bitshift is gewoon een machinetaal instructie.

Zo kan ik nog meer problemen verzinnen zoals wat als er op de ene processor 4 registers zijn en de andere 8.

4-> 8 no prob maar andersom moet je toch echt een ander prog gaan schrijven. Ik heb het artikel niet gelezen maar ik kan me voorstellen dat er nogal wat restricities aan zitten.

Nog een voorbeeld je gaat code van x86 vertalen naar een C64.

bevoorbeeld het programma dat 4x2 berekent.
Oh O de C64 kan niet vermenigvuldigen, althans de proc kan het niet direct .. maar dit is meer een emulatie probleem zoals gezegd

ik snap het niet

x86 heeft toch ook een bitshift instructie die correct werkt? bitshift is bitshift

En inderdaad, de emulator moet wel degelijk rekening houden met de indiaan, maar ik denk dat dit waarschijnlijk een van hun mindere problemen is hoor. Ik vrees dat de verschillen in architectuur nog steeds een flinke brok emulatie gaan vragen.

En wat met de verschillende timings van instructies per CPU? Wat met optimaliseren van code? Lijkt mij behoorlijk sterk als ze dit alles klaarspelen.

Er zijn er al zoveel voor geweest ...

Dit laat me denken aan FX32!, 'n programma dat het mogelijk maakte om x86 programma's op 'n Alpha te draaien. De princiepes waren in feite bijna gelijk.

FX32! emuleerde in eerste instantie de code, maar deed ook de vertaalde code opslaan. Hierdoor liepen programma's die al eerder waren geemuleerd sneller omdat ze al vertaald waren...
Het idee is echter nooit echt aangeslagen.

Ja dat fx!32 is lachen. Voor programma's werkt het best okay. Totdat je een keer een muisdriver oid installeert. Dat gaat dus niet. Hangt je machine en kan je opnieuw NT gaan installeren. |:(

Is niet zo vreemd dat het niet aanslaat dus...

Dus binnenkort window op een c64 of msx? :*)
edit:
Overbodig? Is humor tegenwoordig overbodig? :(
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 18:33 AMD Palomino 1,46GHz benchmark resultaten
Vorige 12:32 Windows XP zal toch geen MP3-encoder bevatten
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011