intel/device-modeling-languageLangage spécifique au domaine pour écrire des modèles de dispositifs fonctionnels rapides pour les plates-formes virtuelles. Compile le DML en C avec des appels API adaptés au simulateur Intel Simics, permettant la simulation matérielle et les tests de sécurité.
Le Langage de Modélisation de Périphériques (DML) est un langage dédié (domain-specific language) pour écrire des modèles de périphériques fonctionnels ou au niveau transaction (transaction-level) rapides pour les plates-formes virtuelles. DML fournit des abstractions de haut niveau adaptées aux modèles de périphériques fonctionnels, incluant des constructions telles que les bancs de registres, les registres, les champs de bits, le postage d'événements, les interfaces entre modèles, et la journalisation. Le code DML est compilé par le compilateur DML (DMLC), produisant du code C avec des appels API adaptés à un simulateur particulier.
Actuellement, le compilateur prend en charge la construction de modèles pour le simulateur Intel® Simics®, mais d'autres back-ends pourraient être ajoutés à l'avenir.
Pour construire DMLC, vous devez disposer d'une installation du simulateur Simics et d'un projet Simics configuré.
Si vous ne disposez pas déjà d'une installation du simulateur Simics ou d'un accès au simulateur Simics par des canaux commerciaux, installez la version publique du simulateur Intel Simics et créez un projet Simics (automatique dans le flux d'installation par défaut).
Dans votre projet Simics, extrayez le dépôt DML dans le répertoire modules/dmlc. À la racine du projet, exécutez make dmlc (ou bin\make dmlc sous Windows).
Pour exécuter les tests unitaires fournis avec DMLC, exécutez make test-dmlc ou bin/test-runner --suite modules/dmlc/test depuis la racine du projet.
Les variables d'environnement suivantes sont pratiques lors du développement de DMLC. Si vous travaillez régulièrement avec un DMLC construit localement, envisagez de définir les variables DMLC_DIR, T126_JOBS, DMLC_PATHSUBST et PY_SYMLINKS dans votre .bashrc. Les variables restantes sont mieux à n'activer que lorsque nécessaire.
Après avoir construit DMLC, vous devez définir DMLC_DIR sur <your-project>/<hosttype>/bin dans les invocations ultérieures de make afin de construire les périphériques avec le compilateur construit localement. <hosttype> est soit linux64 soit win64 selon votre type d'hôte.
Lorsqu'elle est définie, le nombre donné de tests est exécuté en parallèle.
La construction de DMLC copie quelques fichiers de bibliothèque DML, par exemple dml-builtins.dml, dans <hosttype>/bin. Lorsqu'une erreur de compilation se produit, les messages d'erreur pointent normalement vers cette copie plutôt que vers la source. En définissant DMLC_PATHSUBST sur <hosttype>/bin/dml=modules/dmlc/lib, les messages d'erreur seront réécrits pour pointer vers le fichier source à la place. <hosttype> est soit linux64 soit win64 selon votre type d'hôte.
Lorsqu'elle est définie à 1, make dmlc créera des liens symboliques vers les fichiers Python au lieu de les copier. Cela a deux effets : les tracebacks Python vous mèneront au fichier source dans le dépôt, et vous n'aurez pas besoin de relancer make après avoir modifié les fichiers Python.
Lorsqu'elle est définie à 1, les exceptions inattendues dans le compilateur sont affichées sur stderr. Par défaut, les tracebacks sont cachés dans un fichier dmlc-error.log.
Remplace le compilateur par défaut dans les tests unitaires.
Lorsqu'elle est définie, DMLC effectue un auto-profilage et écrit le profil dans un fichier .prof.
Lorsqu'elle est définie, DMLC émet une archive .tar.bz2 contenant tous les fichiers source DML, conditionnée sous une forme pouvant être compilée de manière autonome. Ceci est utile lorsqu'un problème DML apparaît dans un environnement de construction complexe et que vous souhaitez reproduire le problème de manière isolée. Dans l'archive créée, tous les fichiers DML sont situés dans le même répertoire (soit à la racine, soit sous une série de sous-répertoires appelés _), et les importations relatives sont gérées en incluant également des liens symboliques dans l'archive. Sous Windows, DMLC est parfois incapable de résoudre correctement ces liens symboliques ; pour cette raison, il est recommandé que l'archive ne soit extraite et compilée que sous Linux.
Lorsqu'elle est définie, DMLC produit un fichier se terminant par -size-stats.json, qui affiche des statistiques de génération de code utiles pour réduire la taille du code généré et augmenter la vitesse de compilation. Le fichier indique la quantité de code C générée pour chaque méthode DML. La sortie est une liste de triplets [tot_size, location, num], où tot_size est le nombre total d'octets de code C générés à partir d'une déclaration de méthode, num est le nombre de fois que le code C a été généré à partir de cette déclaration (parce qu'elle a été étendue par un template), et location est l'emplacement source de la déclaration.
Une entrée avec un grand tot_size et un grand num peut être réduite en déclarant la méthode comme shared ; cela devrait approximativement diviser la taille par num. Une entrée avec un grand tot_size avec num égal à 1 signifie généralement que la méthode est dominée par une construction comme #foreach ou #select, et peut être réduite en extrayant le corps de la boucle dans une méthode séparée, ou en remaniant la boucle d'une autre manière dans une autre construction comme foreach.
Notez que les statistiques n'incluent que le code directement généré à partir des déclarations de méthode ; la taille totale du code inclut bien plus. Un mégaoctet de taille de code provenant des déclarations de méthode contribue généralement à quelques secondes de temps de compilation.
