intel/device-modeling-languageLinguaggio specifico di dominio per scrivere modelli di dispositivi funzionali veloci per piattaforme virtuali. Compila DML in C con chiamate API su misura per il simulatore Intel Simics, consentendo la simulazione hardware e i test di sicurezza.
Il Device Modeling Language (DML) è un linguaggio specifico di dominio per scrivere modelli di dispositivi funzionali o a livello di transazione veloci per piattaforme virtuali. DML fornisce astrazioni di alto livello adatte a modelli di dispositivi funzionali, inclusi costrutti come banchi di registri, registri, campi di bit, pubblicazione di eventi, interfacce tra modelli e logging. Il codice DML viene compilato dal compilatore DML (DMLC), producendo codice C con chiamate API personalizzate per un simulatore specifico.
Attualmente, il compilatore supporta la creazione di modelli per il simulatore Intel® Simics®, ma in futuro potrebbero essere aggiunti altri back-end.
Per compilare DMLC, è necessario disporre di un'installazione del simulatore Simics e di un progetto Simics configurato.
Se non si dispone già di un'installazione del simulatore Simics o di accesso al simulatore Simics tramite canali commerciali, installare la versione pubblica del simulatore Intel Simics e creare un progetto Simics (automatico nel flusso di installazione predefinito).
Nel tuo progetto Simics, estrai il repository DML nella directory modules/dmlc. Al livello superiore del progetto, esegui make dmlc (o bin\make dmlc su Windows).
Per eseguire i test unitari forniti con DMLC, esegui make test-dmlc o bin/test-runner --suite modules/dmlc/test dal livello superiore del progetto.
Le seguenti variabili d'ambiente sono utili durante lo sviluppo di DMLC. Se lavori regolarmente con un DMLC compilato localmente, considera di impostare le variabili DMLC_DIR, T126_JOBS, DMLC_PATHSUBST e PY_SYMLINKS nel tuo .bashrc. Le restanti variabili è meglio abilitarle solo quando necessario.
Dopo aver compilato DMLC, devi impostare DMLC_DIR su <your-project>/<hosttype>/bin nelle successive invocazioni di make per compilare i dispositivi con il compilatore locale. <hosttype> può essere linux64 o win64 a seconda del tipo di host.
Se impostata, il numero specificato di test viene eseguito in parallelo.
La build di DMLC copia alcuni file di libreria DML, ad esempio dml-builtins.dml, in <hosttype>/bin. Quando si verifica un errore di compilazione, i messaggi di errore punteranno normalmente a questa copia anziché al sorgente. Impostando DMLC_PATHSUBST su <hosttype>/bin/dml=modules/dmlc/lib, i messaggi di errore verranno riscritti per puntare al file sorgente. <hosttype> può essere linux64 o win64 a seconda del tipo di host.
Se impostata a 1, make dmlc creerà collegamenti simbolici ai file Python invece di copiarli. Questo ha due effetti: i traceback Python ti porteranno al file sorgente nel repository e non sarà necessario rieseguire make dopo aver modificato i file Python.
Se impostata a 1, le eccezioni impreviste nel compilatore vengono inviate a stderr. Il comportamento predefinito è nascondere i traceback in un file dmlc-error.log.
Sovrascrive il compilatore predefinito nei test unitari.
Se impostata, DMLC esegue l'auto-profilatura e scrive il profilo in un file .prof.
Se impostata, DMLC emette un archivio .tar.bz2 contenente tutti i file sorgente DML, confezionati in una forma che può essere compilata in modo autonomo. Questo è utile quando un problema DML si manifesta in un ambiente di compilazione complesso e si desidera riprodurre il problema in isolamento. Nell'archivio creato, tutti i file DML si trovano nella stessa directory (al livello superiore o in una serie di sottodirectory chiamate _), e gli import relativi vengono gestiti includendo anche collegamenti simbolici nell'archivio. Su Windows, DMLC a volte non riesce a risolvere correttamente questi collegamenti simbolici; per questo motivo, si consiglia di estrarre e compilare l'archivio solo su Linux.
Se impostata, DMLC emette un file che termina con -size-stats.json, che mostra statistiche di generazione del codice utili per ridurre la dimensione del codice generato e aumentare la velocità di compilazione. Il file elenca quanto codice C viene generato per ogni metodo DML. L'output è una lista di triple [tot_size, location, num], dove tot_size è il numero totale di byte di codice C generato da una dichiarazione di metodo, num è quante volte il codice C è stato generato da questa dichiarazione (perché è stata espansa da un template) e location è la posizione sorgente della dichiarazione.
Una voce con un tot_size grande e un num grande può essere ridotta dichiarando il metodo come shared; questo dovrebbe approssimativamente dividere la dimensione per num. Una voce con tot_size grande e num uguale a 1 di solito significa che il metodo è dominato da un costrutto come #foreach o #select, e può essere ridotta estraendo il corpo del ciclo in un metodo separato o rielaborando il ciclo in un altro costrutto come foreach.
Nota che le statistiche includono solo il codice generato direttamente dalle dichiarazioni di metodo; la dimensione totale del codice include molto di più. Un megabyte di codice generato dalle dichiarazioni di metodo di solito contribuisce con alcuni secondi di tempo di compilazione.
