Transitive werkt aan supersnelle machinetaal-vertaler

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:

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.

Reacties (34)

[Verwijderd]

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.

[mullah]

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)

[it0]

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

[dnf]

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 ...

[Verwijderd]

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

[korenwolf]

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!

[Adion]

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)

[Helox-in-a-box]

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

[Macros]

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

[Verwijderd]

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

[RG]

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

[Roland684]

Ik heb op een computerbeurs (waarschijnlijk de HCC) ooit een een apparaatje gezien dat je PC zou versnellen. Dit ding plugde je in een PCI-slot en klaar, alles veel sneller.
Wat deed het programma namelijk? Het spoorde code op die niet zo efficient was geschreven en herschreef deze met efficientere algoritmen. (en geloof mij, als je als programmeur 1GHz processorkracht tot je beschikking hebt neem je nog maar zelden de moeite om nog naar de efficiëntie te kijken, dus er is een hoop code die beter kan)
Helaas was het apparaat net zo duur als een upgrade naar een snellere proc, maar mocht je al aan de top zitten dan kan dit een leuke extra tweak zijn. In 3dmark zette het een leuke score neer en word werd er ook vet sneller van.

Waarom vertel ik dit?
Nou, stel nou eens dat je met die vertaler van Transitive x86 code laat vertalen naar x86 (of specifieke athlon) -code, dan bestaat de kans dat de terugvertaalde x86 code efficienter is dan de originele code, zeker bij de wat oudere programmatuur.
Ik zie het al helemaal voor me:
-"this program is automatically optimized for [your cpu]"
- doom geoptimaliseerd voor een dual athlon of P4 en gebruikmakend van de programmeerbare gpu van de geforce3
- super

[Verwijderd]

Spintel card heet dat ISA! kaartje. De PCI (Spintel Cheeta) is er nog niet.

[baldido]

Mwah.. laat ze maar een programma maken die de eerste keer dat ie een binary inlaad die bedoeld is voor een andere CPU, omzet naar de binary die de huidige CPU aankan. Dan hoef je niet alles on-the-fly te vertalen. En gaat het vast al een stuk sneller. Zouden ze voor java ook moeten doen

Op zich zouden alle emulatoren moeten kunnen werken. Alleen krijg je probleempjes als een programma bijvoorbeeld een CRC check op zijn eigen binary doet (anti-crack beveiliging). Als je namelijk je nieuwe binary zou maken klopt je CRC check niet meer . En zo zijn er nog meer van die dingen die een emulator niet kan vertalen. Tenzij die AI artificially intelligenve heeft natuurlijk .

[Verwijderd]

Volgens mij heeft dit toch een zekere kans op slagen, ongeacht de grote verschillen tussen cpu's (zoals eerder aangehaald)

Als je dit probleem nu ideaal zou benaderen, en je beeld je in dat je een programma schrijft dat voor elke intel instructie een alpha instructie (of reeks) neerzet die identiek hetzelfde doet. Dan is de kous al af want dan heb je een perfecte vertaler !

Praktisch gezien is dit natuurlijk vrij onmogelijk om voor elke instructie die een intel heeft zomaar ff alpha intstructies te gebruiken die dan hetzelfde doen, maar met wat research (zoals hier duidelijk aan vooraf gegaan is) en met wat ai kan je volgens mij behoorlijk dicht in de buurt komen

[0rbit]

Het probleem is nu juist dat de korrelatie tussen sommige instructies ervoor zorgt dat je een taak vele malen sneller met andere instructies kunt doen. Dit verschilt ook nog eens per type CPU.

Simpelweg de instructies vertalen werkt dus wel, maar om de code ook nog snel te laten zijn moet zeer ingewikkelde interpretatie plaats vinden van wat er nou eigenlijk moet gebeuren.

[Bigs]

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.

[joca]

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

[RG]

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.

[Roland684]

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.

[Ralph Smeets]

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.

[iceblink]

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...

[Bobco]

Klinkt heel erg leuk, maar volgens mij is dit toch meer gericht op de embedded markt dan iets anders. Denk maar eens goed na over de problemen die je moet overwinnen als je een kopietje van, ik noem maar wat, Excel voor een IBM RS/6000 zou willen maken. Behalve Excel zelf zul je dan ook alle mogelijke DLL's die er gebruikt worden mee moeten nemen. Lijkt me niet erg praktisch.....

Voor kleine, echte stand-alone programmatuur die geen gebruik maakt van uitgebreide libraries is dit natuurlijk wel een uitkomst. Het enige dat ik tot nu toe in de reacties mis is de vergelijking met Java.

[Verwijderd]

Het lijkt me dat dit absoluut geen nut heeft voor alle applicaties die draaien op een (modern) besturingssysteem. Deze programma's maken immers allemaal gebruik van de functies die het OS biedt (API), en deze functionaliteit wordt niet mee vertaald!

Vage shit....