Intel Research Day 2013 Intel will durch komprimierten Programmcode Platz auf dem Chip sparen

Ein Wafer im Testlabor
Passen bald mehr Chips auf einen Wafer? Eine On-the-Fly-Dekompression von Code verspricht real um ein Viertel kleinere Siliziumplättchen.

In Anlehung eines Konzeptes von IBM vor 15 Jahren haben die Intel-Labs beim diesjährigen Intel Research Day in San Francisco eine Code-Kompressions-Technologie vorgestellt, bei welcher der Prozessor das komprimierte Programm zur Laufzeit extrahiert. Intels Ziel ist es, durch Verringerung von On-Chip-Speicher Silizium-Kosten zu sparen.

Intel demonstrierte diese Technik auf seinem jährlichen Intel Research Day, auf dem einige laufende Projekte bei den Intel Labs auf der ganzen Welt gezeigt werden. Dieses Projekt läuft in den Intel Labs in St. Petersburg. Obwohl Intel die Technologie "direkte komprimierte Ausführung" nennt, wird das komprimierte Programm in der Realität vor der Ausführung On-the-fly dekomprimiert. Es unterscheidet sich von anderen Code-Kompressionsverfahren wie ARMs Thumb, das 32-Bit-Befehle durch 16-Bit-Opcodes ersetzt.

Anstelle der Verwendung eines modifizierten Befehlssatzes schreiben, kompilieren und linken Programmierer ihren Code wie gewohnt, dann wird ein besonderes Programm eingesetzt, um die Binär-Datei zu komprimieren. Intel hat zwar keine Details über die Kompression selbst bekanntgegeben, ist es jedoch mehr als wahrscheinlich, dass mittels Lempel-Ziv oder Huffman-Algorithmus häufig auftretende Bit-Muster durch kürzere Symbole ersetzt werden. Am Ende wird eine Symbol-Tabelle angehängt, welche eine verlustfreie Dekompression der gepackten Datei ermöglicht. Beliebte Programme wie WinZip verwenden diese Algorithmen ebenfalls.

Der wesentliche Unterschied zwischen den komprimierten Dateien Intels und einer ZIP-Datei ist, dass ein Prozessor mit einer speziellen Dekomprimierungsmaschine versehen wird und das Programm in komprimierter Fassung aufruft, ohne zuerst die Datei mit Dekompressions-Software zu entpacken. Die Dekompression geschieht im laufenden Betrieb in der Hardware. Die Engine entpackt den Befehlsstrom, bevor er den Cache erreicht, so dass der Rest der CPU keine Änderungen erfordert. Die Dekompression erfordert jedoch zusätzliche Taktzyklen.

Ein weiteres Problem ist, dass sich die Speicher-Adresse eines bestimmten Befehls in der komprimierten Datei sich von seiner Lage im Original-Code unterscheidet. Um dieses Problem zu lösen, fügt das Komprimierungsprogramm der gepackten Datei eine Sprung-Tabelle der relativen Speicheradressen hinzu, so dass die Dekomprimierungsmaschine diese zur Laufzeit auflösen kann.

Insgesamt generiert die Technologie vier Arten von Overhead: Die zusätzliche Logik für die Dekomprimierungsmaschine in der CPU, die zusätzlichen Latenzzeiten und Leistungsaufnahme der Run-Time-Dekompression sowie die zusätzlichen Daten für die Sprung-Tabelle. Intel sagt, die Dekomprimierungsmaschine belegt etwa 20.000 Gatter-ein relativ geringer Aufwand, der in einem aktuellen CMOS-Prozess viel weniger als 1,0 mm2 Siliziumfläche einnimmt. Die Run-time-Dekompression reduziert die Rechenleistung um etwa 5% und verbraucht laut Intels Tests mit den EEMBC-Benchmark-Suiten etwa 3,9 µW/MHz.

Im Gegenzug schrumpft die ausführbare Datei einschließlich der Sprung-Tabelle um mehr als 33%. Da der Code gepackt und On-the-Fly dekomprimiert und ausgeführt wird, statt vorher komplett in den Speicher entpackt zu werden, braucht der Prozessor viel weniger Speicher für den Code. Nur das Programm und seine eingebetteten Daten schrumpfen, die Daten, die zur Laufzeit erzeugt oder geladen werden, bleiben freilich gleich.

Das Hauptziel dieser Technologie sind Prozessoren mit On-Chip-Speicher, also im Wesentlichen Mikrocontroller. Theoretisch könnte ein Chip, der flächenmäßig zu 75% aus SRAM oder Flash-Speicher besteht, um 25% schrumpfen - eine signifikante Reduzierung der Herstellungskosten. Obwohl Intel keine MCUs herstellt, baut es SoCs mit Hardware-Beschleunigern, die einen embedded-Code-Speicher aufweisen.

Intels Experimente konzentrieren sich auf eine CPU-Architektur mit variabler Befehlssatz-Länge, nämlich x86. Die grundlegende Technologie funktioniert freilich mit jeder Architektur. Tatsächlich kündigte IBM ein nahezu identisches Vorgehen bereits im Jahr 1998 an. Die sogenannte Codepack-Technologie erschien das folgende Jahr in einem Embedded-Prozessor vom Typ PowerPC, dem 405GP. Aber Codepack scheiterte u.a. daran, dass IBM schließlich das Interesse an Embedded-Prozessoren verlor und diesen Geschäftsbereich an AppliedMicro verkaufte.

Bis vor kurzem hatte niemand diese Idee wiederbelebt, vielleicht, weil Alternativen wie ARMs Thumb den gleichen Grad der Kompression erreichen können. Diese Systeme erfordern jedoch 16-Bit-Befehlssatz-Erweiterungen und modifizierte Befehls-Decodierer in der Prozessor-Logik. Intels x86-Instruktionen mit variabler Länge haben bereits so in durchschnittlichem Code etwa 20 Bit pro Anweisung, so dass ein neuer 16-Bit-Befehlsatz die Mühe wahrscheinlich nicht wert ist. Durch Komprimieren des Codes während der Kompilierung und Dekomprimierung zur Laufzeit können die gleichen Ziele ohne weitere Komplikationen einer bereits komplexen Befehlssatz-Architektur erreicht werden.