Startseite > Hardware > Nvidias erste eigene CPU rasiert die Konkurrenz

Schneller als Apple und Qualcomm

Nvidias erste eigene CPU rasiert die Konkurrenz

22. August 2014, 11:16 Uhr | Lars Bube

Fortsetzung des Artikels von Teil 7

Auswirkungen der dynamischen Übersetzung

Die dynamische Befehls-Übersetzung hat eine lange Geschichte, aber es hat nie einen breiten Einsatz gegeben. Die Technik geht auf Forschung bei den Bell Labs und IBM in den frühen 1980er Jahren zurück. Einige VLIW-Unternehmen versuchten damit das Grundproblem, dass mehrere VLIW-Prozessor-Generationen nicht den gleichen kompilierten Code ausführen können, zu lösen. Transmeta-Produkte haben x86-Befehle in VLIW-Code umgesetzt, zum Teil um Patente von Intel bezüglich der x86-Dekodierung in Hardware zu umgehen. Die Technik ist ähnlich wie Just-in-time-Kompilierung (JIT), die für Java und anderen Sprachen verwendet wird, aber die dynamische Übersetzung nutzt als Input Assembler-Code und keine Hochsprache.

Die dynamische Übersetzung schafft auch einige interessante Möglichkeiten darübergehend hinaus, was Standard-CPUs erreichen. Obwohl Nvidia es ablehnt, irgendwelche Detail-Eigenschaften der Ausführungseinheiten zu veröffentlichen, könnte die native Mikroarchitektur Funktionen beinhalten, die der Standard-Architektur ARMv8 fehlen, wie z.B. verschmolze Operationen oder neue Adressierungsarten. Der Optimierer könnte diese Kombinationen nach der Analyse des Original-Codes und Gruppierung bestimmter Operationen einfach erstellen. Dieser Ansatz könnte das „Plus“ der von Nvidia sieben und mehr angegebenen Instruktionen pro Taktzyklus ausmachen.

Eine andere Möglichkeit ist, dass Nvidia eine Version der Java-JVM erstellen könnte, um direkt vom Dalvik-Format auf Mikrocode zu übersetzen. Dieser Ansatz würde den Aufwand für die Übersetzung in ARM-Code und dann neu zu übersetzen Mikrocode reduzieren. Darüber hinaus hat der Dalvik-Code mehr semantische Informationen als binärer ARM-Code, so dass größere Optimierungen möglich würden. Aufgrund von Denvers Sicherheitsmechanismen müsste sich diese JVM im Mikrocode-Format im Optimierungs-Cache befinden, wodurch Raum für optimierte Routinen genommen würde. Nvidia hat bislang keine Direkt-Übersetzungs-JVM entwickelt, könnte es aber in der Zukunft tun.

Man könnte weiterhin auch Tools für Software-Entwickler anbieten, um Denver-Mikrocode in ihre Middleware (z.B. Web-Browser) oder Apps zu integrieren. Dieser Ansatz verbessert die Rechenleistung durch Senkung des Übersetzungsaufwandes, wobei die Code-Erweiterung um Faktor 3 natürlich eine sehr selektive Nutzung erfordern würde. Vielleicht noch wichtiger, könnten solche Tools die Erzeugung und Verwendung von besonders komplexen Anweisungen, die nicht einfach so in ARM-Code abgebildet werden können, wie beispielsweise eine FFT, ermöglichen. Nach der Ankündigung des Tegra-3 erstellte Nvidia die „Tegra Zone“ um Apps zu fördern, die für seine Architektur optimiert sind. Den gleichen Ansatz könnte es zur Verbreitung von Mikro-Apps geben. Um dies zu tun, müsste allerdings das Mikrocode-Format veröffentlicht werden und das Problem eines möglichen Formatwechsels in zukünftigen Tegra-Produkten gelöst werden.

Die Übersetzung kann auf mehrere Befehlssätze angewendet werden. Nvidia hat an seiner ersten CPU lange Zeit gearbeitet (Chefarchitekt Darrell Boggs trat dem Unternehmen im Jahr 2006 bei, nachdem er als einer der Pentium-4-Architekten bei Intel gearbeitet hatte). Zwischenzeitlich wurde gemunkelt, Denver würde eine x86-CPU, später wurde ein Dual-Mode-Design für möglich gehalten. Denver könnte einfach x86-Code ausführen, indem eine andere Version des Optimierers eingesetzt würde. Da ein x86-Dekoder fehlt, müsste jedoch jede Routine vor der Ausführung übersetzt werden ähnlich wie bei dem Transmeta-Design. Diese Situation würde die Rechenleistung reduzieren. Wenn Nvidia Denver x86-Kompatibilität hinzufügen würde, könnte es Chips für Windows-8-Tablets oder Laptop-PCs zu bauen oder sogar versuchen, Intel aus Supercomputern zu verdrängen.