Binaire vertaling: hoe software van het ene naar het andere processortype verhuist
Stel je voor dat je een cassettebandje hebt met een geweldig verhaal erop, maar je nieuwe apparaat speelt alleen digitale bestanden af. Het verhaal verandert niet, maar de vorm waarin het is vastgelegd moet worden omgezet voordat je nieuwe apparaat er iets mee kan. Binaire vertaling doet iets vergelijkbaars met computerprogramma's: het zet de machinetaal die voor de ene processor is geschreven, om naar de machinetaal van een andere processor, zodat dezelfde software op nieuwe hardware blijft werken.
Dit klinkt misschien als een obscuur technisch detail, maar binaire vertaling heeft grote overstappen in de computergeschiedenis mogelijk gemaakt. Toen Apple in 2020 overstapte van Intel-chips naar eigen ARM-chips, bleven miljoenen bestaande Mac-programma's gewoon werken dankzij deze techniek. Zonder binaire vertaling zouden gebruikers vaak moeten wachten tot ontwikkelaars hun software helemaal opnieuw compileren, of zelfs helemaal geen ondersteuning meer krijgen voor oudere programma's.
Wat is het precies?
Elke processor, of chip, begrijpt maar één taal: zijn eigen instructieset. Dat is een vaste verzameling simpele commando's, zoals 'tel deze twee getallen op' of 'kopieer dit stukje geheugen'. Een programma dat is gecompileerd (vertaald van programmeertaal naar machinetaal) voor een chip van het type x86, zoals gangbaar was in pc's van Intel en AMD, bevat instructies die een ARM-chip, zoals in veel smartphones en moderne Macs, helemaal niet begrijpt.
Binaire vertaling leest de instructies van het originele programma en zet ze om in instructies die de nieuwe processor wél begrijpt. Dat kan op twee manieren. Bij statische vertaling gebeurt dit vooraf: het hele programma wordt in één keer omgezet en opgeslagen als nieuw bestand, vergelijkbaar met het vooraf vertalen van een heel boek. Bij dynamische vertaling gebeurt de omzetting terwijl het programma draait, stukje voor stukje, en worden veelgebruikte stukjes code vaak in een geheugen bewaard (een cache) zodat ze niet steeds opnieuw vertaald hoeven te worden.
Dynamische vertaling is technisch lastiger, omdat de vertaler moet meekijken terwijl het programma actief is en toch weinig vertraging mag veroorzaken. Het voordeel is dat het flexibeler is: het werkt ook voor code die pas tijdens het draaien wordt gegenereerd, en het programma hoeft niet vooraf volledig geanalyseerd te worden. De meeste moderne systemen combineren beide technieken: vaak gebruikte code wordt na een tijdje alsnog statisch geoptimaliseerd, terwijl de rest dynamisch vertaald blijft.
Belangrijk om te beseffen: dit is iets anders dan emulatie in de klassieke zin, waarbij een programma instructie voor instructie wordt nagebootst zonder ze echt om te zetten. Binaire vertaling probeert juist zo veel mogelijk native (rechtstreeks uitvoerbare) code te produceren, wat meestal veel sneller is dan pure emulatie.
Wat wil men ermee bereiken?
Het hoofddoel is compatibiliteit zonder dat softwaremakers hun code opnieuw hoeven te schrijven. Een chipfabrikant of platformbouwer die overstapt naar een nieuwe architectuur staat voor een probleem: gebruikers hebben vaak duizenden bestaande programma's die ze niet willen missen. Binaire vertaling overbrugt die periode, zodat een nieuwe generatie hardware meteen bruikbaar is, terwijl ontwikkelaars op hun gemak hun software kunnen aanpassen voor de nieuwe chip.
Daarnaast speelt prestatie een grote rol. Pure emulatie is vaak traag, omdat elke instructie apart wordt geïnterpreteerd. Binaire vertaling probeert die snelheid te verbeteren door code direct om te zetten naar instructies die de processor native uitvoert, eventueel met optimalisaties die zelfs sneller kunnen zijn dan wat de programmeur oorspronkelijk schreef.
Een derde motivatie is onderzoek naar processorontwerp zelf. Sommige experimentele chips gebruiken juist een heel andere, efficiëntere interne architectuur en vertalen bekende softwaretalen zoals x86 'on the fly' naar hun eigen interne instructies. Zo kan een fabrikant profiteren van compatibiliteit met bestaande software én van een zuiniger of sneller intern ontwerp.
Voorbeelden uit de praktijk
Een van de vroegste bekende toepassingen was DEC FX!32, geïntroduceerd in 1996 door Digital Equipment Corporation. Dit systeem liet x86-programma's voor Windows NT draaien op de Alpha-processor, een snelle maar minder gangbare architectuur. FX!32 combineerde emulatie met achtergrondvertaling: veelgebruikte programma's werden na verloop van tijd omgezet naar native Alpha-code.
Apple gebruikte de techniek twee keer bij grote architectuurovergangen. In 2006 kwam Rosetta uit, waarmee PowerPC-programma's op de nieuwe Intel-Macs konden draaien tijdens Apples overstap naar Intel-chips. Veertien jaar later, in 2020, volgde Rosetta 2, dat de omgekeerde weg bewandelde: x86-programma's laten werken op de nieuwe, zelfontworpen Apple Silicon-chips (ARM-gebaseerd, te beginnen met de M1). Rosetta 2 vertaalt de meeste programma's vooraf bij installatie, en gebruikt dynamische vertaling voor code die pas tijdens het draaien ontstaat.
QEMU, een opensource-project gestart door de Franse programmeur Fabrice Bellard en voor het eerst uitgebracht in 2003, is een van de bekendste voorbeelden van dynamische binaire vertaling in de vrije software. QEMU kan besturingssystemen en programma's voor totaal andere processorarchitecturen laten draaien, bijvoorbeeld een ARM-systeem simuleren op een gewone x86-pc, en wordt veel gebruikt door ontwikkelaars en in virtualisatiesoftware.
Transmeta, een Amerikaans chipbedrijf, bracht in 2000 de Crusoe-processor uit. Deze chip had intern een heel andere, VLIW-achtige architectuur, maar gebruikte software genaamd 'Code Morphing' om x86-programma's dynamisch te vertalen naar de eigen interne instructies. Het doel was vooral energiezuinigheid voor laptops, al bleek de aanpak in de praktijk minder snel dan concurrerende Intel- en AMD-chips en verdween Transmeta uiteindelijk van de markt.
Microsoft paste de techniek toe voor Windows on ARM: sinds 2017 kunnen op ARM-gebaseerde Windows-apparaten bestaande 32-bits x86-programma's draaien via emulatie en vertaling, en met Windows 11 (vanaf 2021-2022) werd hier ook ondersteuning voor 64-bits x86-programma's (x64) aan toegevoegd.
Hoe ver is de techniek?
Binaire vertaling is inmiddels een volwassen en bewezen techniek, geen experimenteel idee meer. De grootste vooruitgang van de afgelopen decennia zit in snelheid: waar vroege systemen als FX!32 en de eerste Rosetta merkbare prestatievertraging gaven, presteert Rosetta 2 op veel taken bijna net zo goed als native code, en soms zelfs beter dankzij slimme optimalisaties tijdens het vertalen.
Toch blijven er beperkingen. Programma's die zeer nauw samenwerken met specifieke hardware-eigenschappen van de originele chip, zoals bepaalde grafische of virtualisatiefuncties, laten zich lastiger vertalen en vereisen soms uitzonderingen of blijven helemaal onondersteund. Ook kost binaire vertaling energie en rekenkracht: op mobiele apparaten met beperkte batterijduur is dat een reëel nadeel, wat verklaart waarom fabrikanten deze ondersteuning vaak na een aantal jaren weer afbouwen zodra ontwikkelaars hun software native hebben aangepast.
Een ander obstakel is complexiteit. Instructiesets als x86 zijn na decennia uitbreiding enorm ingewikkeld geworden, met veel speciale gevallen. Een vertaler moet al die eigenaardigheden correct afhandelen, wat het bouwen van betrouwbare, foutloze binaire vertalers tot een aanzienlijke technische opgave maakt. Onderzoek naar nieuwe, efficiëntere manieren van dynamische vertaling en optimalisatie loopt dan ook nog altijd door, onder meer in de context van energiezuinige chipontwerpen en veiligheidsonderzoek, waarbij vertalers ook gebruikt worden om kwetsbaarheden in code op te sporen.
Wie werken eraan?
Apple is met Rosetta en Rosetta 2 wellicht het bekendste hedendaagse voorbeeld en heeft de techniek ingezet bij twee grote architectuurovergangen. Microsoft ontwikkelt vergelijkbare technologie voor Windows on ARM. Historisch speelde Digital Equipment Corporation (DEC), later overgenomen door Compaq en vervolgens HP, een pioniersrol met FX!32. Transmeta was een opvallende, inmiddels verdwenen speler die de techniek combineerde met een eigen chipontwerp.
Op het gebied van open source is de QEMU-gemeenschap, met oprichter Fabrice Bellard, van groot belang; het project wordt onderhouden door vrijwilligers en bedrijven wereldwijd en vormt de basis voor veel virtualisatiesoftware, waaronder onderdelen van Linux-KVM. Ook chipfabrikanten als Intel hebben in het verleden geëxperimenteerd met binaire vertaling, bijvoorbeeld om oudere x86-software te laten draaien op de inmiddels gestaakte Itanium-architectuur. Academisch onderzoek naar dynamische vertaling en optimalisatie wordt onder meer gedaan aan Amerikaanse universiteiten en bij onderzoekslabs van grote techbedrijven, vaak in combinatie met vraagstukken over chipontwerp, energiezuinigheid en softwarebeveiliging.