intel/device-modeling-languageDomänenspezifische Sprache zum Schreiben schneller funktionaler Gerätemodelle für virtuelle Plattformen. Kompiliert DML zu C mit für den Intel Simics Simulator maßgeschneiderten API-Aufrufen und ermöglicht so Hardwaresimulation und Sicherheitstests.
Die Device Modeling Language (DML) ist eine domänenspezifische Sprache zum Schreiben schneller funktionaler oder transaktionsorientierter Gerätemodelle für virtuelle Plattformen. DML bietet High-Level-Abstraktionen, die für funktionale Gerätemodelle geeignet sind, einschließlich Konstrukten wie Registerbänken, Registern, Bitfeldern, Ereignisauslösung, Schnittstellen zwischen Modellen und Protokollierung. DML-Code wird vom DML Compiler (DMLC) kompiliert, wodurch C-Code mit API-Aufrufen erzeugt wird, die auf einen bestimmten Simulator zugeschnitten sind.
Derzeit unterstützt der Compiler die Erstellung von Modellen für den Intel® Simics® Simulator, aber in Zukunft können weitere Backends hinzugefügt werden.
Um DMLC zu erstellen, benötigen Sie eine Simics-Simulator-Installation und ein eingerichtetes Simics-Projekt.
Falls Sie noch keine Simics-Simulator-Installation haben oder keinen Zugang zum Simics-Simulator über kommerzielle Kanäle haben, installieren Sie die Public Release of the Intel Simics simulator und erstellen Sie ein Simics-Projekt (automatisch im Standard-Installationsablauf).
Checken Sie in Ihrem Simics-Projekt das DML-Repository in das Verzeichnis
modules/dmlc aus. Führen Sie auf der obersten Ebene des Projekts make dmlc
(oder bin\make dmlc unter Windows) aus.
Um die mit DMLC bereitgestellten Komponententests auszuführen, führen Sie
make test-dmlc oder bin/test-runner --suite modules/dmlc/test von der
obersten Ebene des Projekts aus.
Die folgenden Umgebungsvariablen sind bei der Entwicklung von DMLC nützlich. Wenn Sie
regelmäßig mit einem lokal erstellten DMLC arbeiten, sollten Sie die Variablen
DMLC_DIR T126_JOBS, DMLC_PATHSUBST und PY_SYMLINKS in Ihrer
.bashrc setzen. Die übrigen Variablen sollten Sie besser nur bei Bedarf aktivieren.
Nach dem Erstellen von DMLC müssen Sie bei nachfolgenden Aufrufen von make
DMLC_DIR auf <your-project>/<hosttype>/bin setzen, um Geräte mit dem lokal
erstellten Compiler zu bauen. <hosttype> ist entweder linux64 oder win64,
abhängig von Ihrem Host-Typ.
Wenn diese Variable gesetzt ist, wird die angegebene Anzahl von Tests parallel ausgeführt.
Der DMLC-Build kopiert einige DML-Bibliotheksdateien, z.B. dml-builtins.dml, in
<hosttype>/bin. Wenn ein Kompilierungsfehler auftritt, verweisen
Fehlermeldungen normalerweise auf diese Kopie und nicht auf die Quelle. Durch
Setzen von DMLC_PATHSUBST auf <hosttype>/bin/dml=modules/dmlc/lib werden
Fehlermeldungen umgeschrieben, um stattdessen auf die Quelldatei zu verweisen.
<hosttype> ist entweder linux64 oder win64, abhängig von Ihrem Host-Typ.
Wenn auf 1 gesetzt, erstellt make dmlc symbolische Links für Python-Dateien
anstatt sie zu kopieren. Dies hat zwei Auswirkungen: Python-Tracebacks führen
zur Quelldatei im Repository, und Sie müssen make nach dem Bearbeiten von
Python-Dateien nicht erneut ausführen.
Wenn auf 1 gesetzt, werden unerwartete Ausnahmen im Compiler nach stderr
ausgegeben. Standardmäßig werden Tracebacks in einer Datei dmlc-error.log
versteckt.
Überschreibt den Standard-Compiler in Komponententests.
Wenn gesetzt, führt DMLC ein Selbst-Profiling durch und schreibt das Profil in eine .prof-Datei.
Wenn gesetzt, gibt DMLC ein .tar.bz2-Archiv aus, das alle DML-Quelldateien
enthält, verpackt in einer Form, die eigenständig kompiliert werden kann. Dies
ist nützlich, wenn ein DML-Problem in einer komplexen Build-Umgebung auftritt,
und Sie das Problem isoliert reproduzieren möchten. Im erstellten Archiv
befinden sich alle DML-Dateien im selben Verzeichnis (entweder auf oberster
Ebene oder unter einer Reihe von Unterverzeichnissen mit dem Namen _), und
relative Importe werden durch die Einbeziehung von symbolischen Links im Archiv
behandelt. Unter Windows kann DMLC diese symbolischen Links manchmal nicht
korrekt auflösen; aus diesem Grund wird empfohlen, das Archiv nur unter Linux
zu extrahieren und zu kompilieren.
Wenn gesetzt, gibt DMLC eine Datei aus, die auf -size-stats.json endet, und
Codegenerierungsstatistiken anzeigt, die nützlich sind, um die Größe des
generierten Codes zu reduzieren und die Kompilierungsgeschwindigkeit zu
erhöhen. Die Datei listet auf, wie viel C-Code für jede DML-Methode generiert
wird. Die Ausgabe ist eine Liste von Tripeln [tot_size, location, num], wobei
tot_size die Gesamtzahl der Bytes des aus einer Methodendeklaration
generierten C-Codes ist, num angibt, wie oft C-Code aus dieser Deklaration
generiert wurde (weil sie von einer Vorlage erweitert wurde), und location
die Quellposition der Deklaration ist.
Ein Eintrag mit einem großen tot_size und einem großen num kann reduziert
werden, indem die Methode als shared deklariert wird; dies sollte die Größe
in etwa durch num teilen. Ein Eintrag mit großem tot_size mit num gleich
1 bedeutet normalerweise, dass die Methode von einem Konstrukt wie #foreach
oder #select dominiert wird, und kann reduziert werden, indem der
Schleifenkörper in eine separate Methode ausgelagert wird, oder indem die
Schleife anderweitig in ein anderes Konstrukt wie foreach umgearbeitet wird.
Beachten Sie, dass die Statistik nur den direkt aus Methodendeklarationen generierten Code umfasst; die gesamte Codegröße umfasst viel mehr. Ein Megabyte Codegröße aus Methodendeklarationen trägt normalerweise mit einigen Sekunden Kompilierungszeit bei.
