In a seconda parte di l'articulu nantu à i simulatori di u sistema di l'informatica, cuntinueraghju à parlà in una forma introduttiva simplice di i simulatori di l'informatica, vale à dì di a simulazione di a piattaforma completa, chì l'utilizatori mediu scontra più spessu, è ancu di u clock-by. -clock mudellu è tracce, chì sò più cumuni in circles sviluppatore.
В Aghju parlatu di ciò chì i simulatori sò in generale, è ancu di i livelli di simulazione. Avà, basatu annantu à quella cunniscenza, pruponu di immersione un pocu più profonda è di parlà di a simulazione full-platform, cumu per cullà tracce, chì fà cun elli dopu, è ancu di l'emulazione microarchitecturale clock-by-clock.
Simulatore di piattaforma cumpleta, o "Solu in u campu ùn hè micca un guerrieru"
Se vulete studià u funziunamentu di un dispositivu specificu, per esempiu, una carta di rete, o scrivite firmware o un driver per stu dispusitivu, allora un tali dispusitivu pò esse simulatu separatamente. In ogni casu, l'utilizanu in isolamentu da u restu di l'infrastruttura ùn hè micca assai cunvene. Per eseguisce u driver currispundente, avete bisognu di un processatore cintrali, memoria, accessu à un bus di dati, etc. Inoltre, u driver necessita un sistema operatore (OS) è una pila di rete per funziunà. Inoltre, un generatore di pacchetti separati è un servitore di risposta pò esse necessariu.
Un simulatore di piattaforma cumpleta crea un ambiente per eseguisce una pila di software cumpleta, chì include tuttu da u BIOS è u bootloader à u SO stessu è i so diversi sottosistemi, cum'è a stessa pila di rete, i drivers è l'applicazioni à u nivellu d'utilizatori. Per fà questu, implementa mudelli di software di a maiò parte di i dispositi di l'informatica: u processatore è a memoria, u discu, i dispositi di input / output (teclatura, mouse, display), è ancu a stessa carta di rete.
Quì sottu hè un diagramma di bloccu di u chipset x58 da Intel. Un simulatore di computer full-platform in questu chipset richiede l'implementazione di a maiò parte di i dispositi listati, cumpresi quelli chì sò in l'IOH (Input / Output Hub) è ICH (Input / Output Controller Hub), chì ùn sò micca raffigurati in dettagliu nantu à u diagramma di bloccu. . Ancu s'ellu, cum'è a pratica mostra, ùn sò micca assai dispusitivi chì ùn sò micca utilizati da u software chì andemu à eseguisce. Modelli di tali dispusitivi ùn deve esse creatu.
A maiò spessu, i simulatori full-platform sò implementati à u livellu di istruzzioni di u processatore (ISA, vede sottu). ). Questu permette di creà u simulatore stessu relativamente rapidamente è à pocu costu. U nivellu ISA hè ancu bonu perchè ferma più o menu constantu, à u cuntrariu, per esempiu, di u livellu API / ABI, chì cambia più spessu. Inoltre, l'implementazione à u livellu di l'istruzzioni permette di eseguisce u chjamatu software binariu micca mudificatu, vale à dì, eseguisce un codice digià compilatu senza cambiamenti, esattamente cum'è hè usatu in hardware reale. In altri palori, pudete fà una copia ("dump") di u vostru discu duru, specificà cum'è una maghjina per un mudellu in un simulatore full-platform, è voilà! - U SO è altri prugrammi sò caricati in u simulatore senza alcuna azzione supplementaria.
Prestazione di u simulatore
Cum'è l'annunziava appena sopra, u prucessu di simulazione di tuttu u sistema, vale à dì, tutti i so dispusitivi, hè una impresa piuttostu lenta. Sè ancu implementà tuttu questu à un livellu assai detallatu, per esempiu, microarchitectural o logicu, allora l'esekzione diventerà estremamente lenta. Ma u livellu d'istruzzioni hè una scelta approprita è permette à u SO è i prugrammi di eseguisce à una velocità abbastanza per l'utilizatore per interagisce cun elli cunfortu.
Quì saria apprupriatu toccu u tema di u funziunamentu di u simulatore. Hè generalmente misurata in IPS (istruzzioni per seconda), più precisamente in MIPS (milioni IPS), vale à dì, u numeru di struzzioni di u processatore eseguitu da u simulatore in una seconda. À u listessu tempu, a vitezza di a simulazione dipende ancu da u rendiment di u sistema nantu à quale a simulazione stessu corre. Dunque, pò esse più currettu per parlà di u "rallentamentu" di u simulatore cumparatu cù u sistema originale.
I simulatori full-platform più cumuni in u mercatu, cum'è QEMU, VirtualBox o VmWare Workstation, anu un bonu rendimentu. Ùn pò ancu esse nutatu à l'utilizatore chì u travagliu hè in corso in u simulatore. Questu succede grazia à e capacità di virtualizazione speciale implementate in processori, algoritmi di traduzzione binari è altre cose interessanti. Questu hè tuttu un tema per un articulu separatu, ma in breve, a virtualizazione hè una funzione hardware di i prucessori muderni chì permette à i simulatori micca di simule l'istruzzioni, ma di mandà per l'esekzione direttamente à un processatore veru, se, sicuru, l'architetture di u simulatore è u processatore sò simili. A traduzzione binaria hè a traduzzione di u codice di a macchina di l'ospiti in u codice di l'ospite è l'esekzione sussegwente nantu à un processatore veru. In u risultatu, a simulazione hè solu ligeramente più lenta, 5-10 volte, è spessu ancu corre à a listessa velocità di u sistema veru. Ancu s'ellu hè influinzatu da parechji fatturi. Per esempiu, se vulemu simulà un sistema cù parechje decine di prucessori, allora a vitezza scenderà immediatamente da queste parechje decine di volte. Per d 'altra banda, i simulatori cum'è Simics in l'ultime versioni supportanu l'hardware host multiprocessore è parallelizanu in modu efficace i nuclei simulati nantu à i nuclei di un veru processore.
Se parlemu di a vitezza di a simulazione microarchitecturale, allora hè di solitu parechji ordini di grandezza, circa 1000-10000 volte più lento di l'esekzione in un computer regulare, senza simulazione. E implementazioni à u livellu di l'elementi lògichi sò più lenti da parechji ordini di grandezza. Dunque, un FPGA hè utilizatu com'è emulatore à questu livellu, chì pò aumentà significativamente u rendiment.
U graficu sottu mostra una dependenza apprussimata di a velocità di simulazione nantu à i dettagli di u mudellu.
Simulazione beat-by-beat
Malgradu a so bassa velocità di esecuzione, i simulatori microarchitecturali sò abbastanza cumuni. A simulazione di i blocchi internu di u processatore hè necessariu per simule accuratamente u tempu d'esekzione di ogni struzzione. Un malintesi pò nasce quì - dopu tuttu, pare, perchè micca solu programà u tempu d'esekzione per ogni struzzione. Ma un tali simulatore serà assai imprecisu, postu chì u tempu d'esekzione di a listessa struzzione pò differisce da chjama à chjama.
L'esempiu più simplice hè una struzzione di accessu à a memoria. Se u locu di memoria dumandata hè dispunibule in a cache, u tempu d'esekzione serà minimu. Se sta informazione ùn hè micca in u cache ("cache miss"), allora questu aumenterà assai u tempu d'esekzione di l'istruzzioni. Cusì, un mudellu di cache hè necessariu per una simulazione precisa. Tuttavia, a materia ùn hè micca limitata à u mudellu di cache. U processatore ùn hà micca solu aspittà chì i dati per esse recuperati da a memoria quandu ùn hè micca in a cache. Invece, hà da cumincià à eseguisce e seguenti struzzioni, scegliendu quelli chì ùn dependenu micca di u risultatu di a lettura da a memoria. Questa hè l'esekzione chjamata "fora di ordine" (OOO, esecuzione fora di l'ordine), necessariu per minimizzà u tempu inattivu di u processatore. Mudificà i blocchi di u processatore currispundenti vi aiuterà à piglià tuttu questu in contu quandu calcule u tempu d'esekzione di l'istruzzioni. Frà queste struzzioni, eseguite mentre u risultatu di a lettura da a memoria hè aspittatu, pò accade una operazione di salto cundizionale. Se u risultatu di a cundizione hè scunnisciutu à u mumentu, allora di novu u processatore ùn ferma micca l'esekzione, ma face una "guess", esegue u ramu appropritatu è cuntinueghja à eseguisce in modu proattivu l'istruzzioni da u puntu di transizione. Un tali bloccu, chjamatu un predictore di ramu, deve ancu esse implementatu in u simulatore microarchitectural.
A stampa sottu mostra i blocchi principali di u processatore, ùn hè micca necessariu di sapè, hè mostratu solu per vede a cumplessità di l'implementazione microarchitectural.
U funziunamentu di tutti questi blocchi in un processatore veru hè sincronizatu da signali di clock spiciali, è u stessu passa in u mudellu. Un tali simulatore microarchitectural hè chjamatu cycle accurate. U so scopu principale hè di predice accuratamente a prestazione di u processatore chì hè sviluppatu è / o calculà u tempu d'esekzione di un prugramma specificu, per esempiu, un benchmark. Se i valori sò più bassi di ciò chì hè necessariu, allora serà necessariu mudificà l'algoritmi è i blocchi di processore o ottimisimu u prugramma.
Cum'è mostratu sopra, a simulazione clock-by-clock hè assai lenta, per quessa hè aduprata solu quandu studia certi mumenti di u funziunamentu di un prugramma, induve hè necessariu di scopre a vera velocità di l'esekzione di u prugramma è valutà u futuru rendimentu di u dispusitivu chì hà. prototipu hè esse simulatu.
In questu casu, un simulatore funziunale hè utilizatu per simule u tempu di esecuzione restante di u prugramma. Cumu sta cumminazione di usu accade in a realità? Prima, u simulatore funziunale hè lanciatu, nantu à quale u SO è tuttu ciò chì hè necessariu per eseguisce u prugramma in studiu sò caricati. Dopu tuttu, ùn avemu micca interessatu in u SO stessu, nè in i primi stadi di lanciazione di u prugramma, a so cunfigurazione, etc. Tuttavia, ùn pudemu ancu saltà queste parti è passà immediatamente à eseguisce u prugramma da u mità. Dunque, tutti sti passi preliminari sò eseguiti nantu à un simulatore funziunale. Dopu chì u prugramma hè statu eseguitu à u mumentu di interessu per noi, duie opzioni sò pussibuli. Pudete rimpiazzà u mudellu cù un mudellu clock-by-cycle è cuntinuà l'esekzione. U modu di simulazione chì usa codice eseguibile (vale à dì, schedarii di prugramma cumpilati regularmente) hè chjamatu simulazione guidata da esecuzione. Questa hè l'opzione di simulazione più cumuna. Un altru approcciu hè ancu pussibule - simulazione guidata da traccia.
Simulazione basata in traccia
Hè custituitu di dui passi. Utilizendu un simulatore funziunale o in un sistema reale, un logu di l'azzioni di u prugramma hè recullatu è scrittu in un schedariu. Stu logu hè chjamatu traccia. Sicondu ciò chì hè esaminatu, a traccia pò include struzzioni eseguibili, indirizzi di memoria, numeri di portu, è informazioni di interruzzione.
U prossimu passu hè di "giocà" a traccia, quandu u simulatore clock-by-clock leghje a traccia è eseguisce tutte l'istruzzioni scritte in questu. À a fine, avemu u tempu d'esekzione di stu pezzu di u prugramma, è ancu diverse caratteristiche di stu prucessu, per esempiu, u percentualità di hits in u cache.
Una funzione impurtante di travaglià cù e tracce hè u determinismu, vale à dì, eseguendu a simulazione in a manera descritta sopra, una volta è una volta riproducemu a listessa sequenza d'azzioni. Questu permette, cambiendu i paràmetri di mudelli (cache, buffer è taglia di fila) è utilizendu diversi algoritmi interni o tuning, per studià cumu un paràmetru particulari affetta u rendiment di u sistema è quale opzione dà i megliu risultati. Tuttu chistu pò esse fattu cù un mudellu di u dispusitivu prototipu prima di creà un prototipu di hardware propiu.
A cumplessità di questu approcciu si trova in a necessità di prima eseguisce l'applicazione è raccoglie a traccia, è ancu a dimensione enormosa di u schedariu di traccia. I vantaghji includenu u fattu chì hè abbastanza per simule solu a parte di u dispusitivu o di a piattaforma d'interessu, mentre chì a simulazione per l'esekzione generalmente richiede un mudellu cumpletu.
Allora, in questu articulu avemu vistu i funziunalità di a simulazione full-piattaforma, hà parlatu di a vitezza di implementazioni à diversi livelli, simulazione clock-by-cycle è tracce. In u prossimu articulu, descriveraghju i scenarii principali per l'usu di simulatori, sia per scopi persunali sia da u puntu di vista di u sviluppu in e grande cumpagnie.
Source: www.habr.com