A számítógépes rendszerszimulátorokról szóló cikk második részében egy egyszerű bevezető formában továbbra is a számítógépes szimulátorokról fogok beszélni, mégpedig a teljes platform szimulációról, amellyel az átlagfelhasználó leggyakrabban találkozik, valamint az órajelről. -óramodell és nyomok, amelyek fejlesztői körökben gyakoribbak.
В Beszéltem arról, hogy mik a szimulátorok általában, valamint a szimuláció szintjeiről. Most, ezen ismeretek alapján, azt javaslom, hogy merüljünk el egy kicsit mélyebben, és beszéljünk a teljes platform szimulációról, a nyomok gyűjtéséről, a későbbi teendőkről, valamint az órajelenkénti mikroarchitektúra emulációról.
Teljes platform szimulátor, vagy „Egyedül a terepen nem harcos”
Ha egy adott eszköz, például egy hálózati kártya működését szeretné tanulmányozni, vagy firmware-t vagy illesztőprogramot szeretne írni ehhez az eszközhöz, akkor egy ilyen eszköz külön szimulálható. Azonban az infrastruktúra többi részétől elkülönítve használni nem túl kényelmes. A megfelelő illesztőprogram futtatásához központi processzorra, memóriára, adatbuszhoz való hozzáférésre stb. Ezenkívül az illesztőprogram működéséhez operációs rendszerre (OS) és hálózati veremre van szükség. Ezenkívül külön csomaggenerátorra és válaszkiszolgálóra is szükség lehet.
A teljes platformra kiterjedő szimulátor környezetet hoz létre egy komplett szoftververem futtatásához, amely magában foglal mindent a BIOS-tól és a rendszerbetöltőtől egészen az operációs rendszerig és annak különböző alrendszereiig, mint például ugyanaz a hálózati verem, illesztőprogramok és felhasználói szintű alkalmazások. Ehhez a legtöbb számítógépes eszköz szoftvermodelljét valósítja meg: processzor és memória, lemez, beviteli/kimeneti eszközök (billentyűzet, egér, kijelző), valamint ugyanaz a hálózati kártya.
Az alábbiakban az Intel x58 lapkakészletének blokkdiagramja látható. Egy teljes platform számítógépes szimulátor ezen a lapkakészleten a felsorolt eszközök többségének megvalósítását igényli, beleértve az IOH-n (Input/Output Hub) és az ICH-n (Input/Output Controller Hub) belülieket is, amelyek nincsenek részletesen ábrázolva a blokkdiagramon. . Bár a gyakorlat azt mutatja, hogy nem sok olyan eszköz van, amelyet ne használna a futtatni kívánt szoftver. Az ilyen eszközök modelljeit nem kell létrehozni.
Leggyakrabban a teljes platform szimulátorokat a processzor utasítások szintjén valósítják meg (ISA, lásd alább). ). Ez lehetővé teszi magának a szimulátornak a viszonylag gyors és olcsó létrehozását. Az ISA szint azért is jó, mert többé-kevésbé állandó marad, ellentétben például a gyakrabban változó API/ABI szinttel. Emellett az utasítás szintű megvalósítás lehetővé teszi az úgynevezett módosítatlan bináris szoftverek futtatását, vagyis a már lefordított kód futtatását változtatás nélkül, pontosan úgy, ahogy azt valódi hardveren használják. Más szóval, másolatot készíthet ("kiírat") a merevlemezéről, megadhatja képként egy modellhez egy teljes platformos szimulátorban, és íme! – Az operációs rendszer és a többi program minden további művelet nélkül betöltődik a szimulátorba.
Szimulátor teljesítménye
Ahogy fentebb említettük, a teljes rendszer, vagyis az összes eszköz szimulálása meglehetősen lassú vállalkozás. Ha mindezt nagyon részletesen, például mikroarchitektúrában vagy logikai szinten is megvalósítja, akkor a végrehajtás rendkívül lassú lesz. De az utasítás szintje megfelelő választás, és lehetővé teszi, hogy az operációs rendszer és a programok olyan sebességgel fussanak, amely elegendő ahhoz, hogy a felhasználó kényelmesen kommunikálhasson velük.
Itt érdemes a szimulátor teljesítményének témáját érinteni. Általában IPS-ben (utasítások másodpercenként), pontosabban MIPS-ben (millió IPS) mérik, vagyis a szimulátor által egy másodperc alatt végrehajtott processzorutasítások számát. Ugyanakkor a szimuláció sebessége annak a rendszernek a teljesítményétől is függ, amelyen maga a szimuláció fut. Ezért helyesebb lehet a szimulátor „lassulásáról” beszélni az eredeti rendszerhez képest.
A piacon legelterjedtebb full-platform szimulátorok, mint például a QEMU, a VirtualBox vagy a VmWare Workstation jó teljesítményt nyújtanak. Lehet, hogy a felhasználó számára észre sem veszi, hogy a szimulátorban munka folyik. Ez a processzorokban megvalósított speciális virtualizációs képességeknek, bináris fordítási algoritmusoknak és más érdekességeknek köszönhető. Ez mind egy külön cikk témája, de röviden a virtualizáció a modern processzorok hardveres funkciója, amely lehetővé teszi a szimulátoroknak, hogy ne szimulálják az utasításokat, hanem közvetlenül küldjék el őket végrehajtásra egy valódi processzorhoz, ha természetesen a a szimulátor és a processzor hasonló. A bináris fordítás a vendég gépi kód lefordítása gazdakódba, majd az ezt követő végrehajtás egy valós processzoron. Emiatt a szimuláció csak valamivel lassabb, 5-10-szeres, sőt gyakran a valós rendszerrel megegyező sebességgel is fut. Bár ezt számos tényező befolyásolja. Például, ha egy több tucat processzoros rendszert akarunk szimulálni, akkor a sebesség azonnal több tucatszorosára csökken. Másrészt a Simicshez hasonló szimulátorok a legújabb verziókban támogatják a többprocesszoros hoszt hardvert, és hatékonyan párhuzamosítják a szimulált magokat egy valódi processzor magjaival.
Ha a mikroarchitektúra szimuláció sebességéről beszélünk, akkor ez általában több nagyságrenddel, körülbelül 1000-10000 XNUMX-szer lassabb, mint egy hagyományos számítógépen, szimuláció nélkül. A logikai elemek szintjén történő megvalósítások pedig több nagyságrenddel lassabbak. Ezért ezen a szinten egy FPGA-t használnak emulátorként, ami jelentősen növelheti a teljesítményt.
Az alábbi grafikon a szimulációs sebesség hozzávetőleges függését mutatja a modell részleteitől.
Ütésről ütemre szimuláció
Alacsony végrehajtási sebességük ellenére a mikroarchitektúra-szimulátorok meglehetősen gyakoriak. A processzor belső blokkjainak szimulációja szükséges az egyes utasítások végrehajtási idejének pontos szimulálásához. Itt félreértés adódhat – elvégre úgy tűnik, miért nem programozzuk be egyszerűen az egyes utasítások végrehajtási idejét. De egy ilyen szimulátor nagyon pontatlan lesz, mivel ugyanazon utasítás végrehajtási ideje hívásonként eltérő lehet.
A legegyszerűbb példa egy memóriaelérési utasítás. Ha a kért memóriahely elérhető a gyorsítótárban, akkor a végrehajtási idő minimális lesz. Ha ez az információ nincs a gyorsítótárban („cache miss”), akkor ez nagymértékben megnöveli az utasítás végrehajtási idejét. Így a pontos szimulációhoz gyorsítótár-modell szükséges. A probléma azonban nem korlátozódik a gyorsítótár-modellre. A processzor nem egyszerűen csak arra vár, hogy az adatokat lekérjék a memóriából, amikor azok nincsenek a gyorsítótárban. Ehelyett elkezdi végrehajtani a következő utasításokat, és kiválasztja azokat, amelyek nem függnek a memóriából történő olvasás eredményétől. Ez az úgynevezett „soron kívüli” végrehajtás (OOO, out of order execution), amely a processzor üresjárati idejének minimalizálásához szükséges. A megfelelő processzorblokkok modellezése segít mindezt figyelembe venni az utasítások végrehajtási idejének számításakor. Ezen utasítások között, amelyek a memóriából történő kiolvasás eredményének várakozása közben hajtódnak végre, előfordulhat egy feltételes ugrás. Ha a feltétel eredménye pillanatnyilag ismeretlen, akkor a processzor ismét nem állítja le a végrehajtást, hanem „talál”, végrehajtja a megfelelő elágazást, és az átmenet pontjától kezdve proaktívan hajtja végre az utasításokat. Egy ilyen blokkot, úgynevezett elágazás-előrejelzőt, a mikroarchitektúra-szimulátorban is meg kell valósítani.
Az alábbi kép a processzor főbb blokkjait mutatja, nem szükséges ismerni, csak a mikroarchitektúra megvalósításának bonyolultsága miatt látható.
Mindezen blokkok működését egy valós processzorban speciális órajelek szinkronizálják, és ugyanez történik a modellben is. Az ilyen mikroarchitektúra szimulátort cikluspontosnak nevezzük. Fő célja a fejlesztés alatt álló processzor teljesítményének pontos előrejelzése és/vagy egy adott program, például egy benchmark végrehajtási idejének kiszámítása. Ha az értékek alacsonyabbak a szükségesnél, akkor módosítani kell az algoritmusokat és a processzorblokkokat, vagy optimalizálni kell a programot.
Mint fentebb látható, az órajel szimuláció nagyon lassú, ezért csak a program működésének bizonyos mozzanatainak tanulmányozásakor alkalmazzák, ahol meg kell találni a program végrehajtásának valós sebességét, és értékelni kell annak az eszköznek a jövőbeli teljesítményét, prototípus szimulációja folyik.
Ebben az esetben egy funkcionális szimulátort használnak a program hátralévő futási idejének szimulálására. Hogyan valósul meg ez a kombináció a valóságban? Először elindul a funkcionális szimulátor, amelyre betöltődik az operációs rendszer és minden, ami a vizsgált program futtatásához szükséges. Végül is nem érdekel minket maga az operációs rendszer, sem a program indításának kezdeti szakaszai, konfigurációja stb. Azonban ezeket a részeket sem hagyhatjuk ki, és azonnal folytathatjuk a program végrehajtását a közepétől. Ezért ezek az előzetes lépések egy funkcionális szimulátoron futnak. Miután a program a számunkra érdekes pillanatig lefutott, két lehetőség közül választhatunk. Lecserélheti a modellt egy órajel-modellre, és folytathatja a végrehajtást. A futtatható kódot (vagyis szabályos lefordított programfájlokat) használó szimulációs módot végrehajtásvezérelt szimulációnak nevezzük. Ez a leggyakoribb szimulációs lehetőség. Egy másik megközelítés is lehetséges - a nyomkövetés által vezérelt szimuláció.
Nyomkövetés alapú szimuláció
Két lépésből áll. Funkcionális szimulátor használatával vagy valós rendszeren a programműveletek naplóját összegyűjtik és fájlba írják. Ezt a naplót nyomkövetésnek nevezik. Attól függően, hogy mit vizsgálunk, a nyomkövetés tartalmazhat végrehajtható utasításokat, memóriacímeket, portszámokat és megszakítási információkat.
A következő lépés a nyomkövetés „lejátszása”, amikor is az órajel-szimulátor beolvassa a nyomkövetést és végrehajtja az abban írt utasításokat. A végén megkapjuk a program ezen részének végrehajtási idejét, valamint a folyamat különféle jellemzőit, például a gyorsítótárban lévő találatok százalékos arányát.
A nyomokkal való munka egyik fontos jellemzője a determinizmus, vagyis a szimuláció fent leírt módon történő futtatásával újra és újra ugyanazt a műveletsort reprodukáljuk. Ez lehetővé teszi a modellparaméterek (gyorsítótár, puffer és sorméret) megváltoztatásával, valamint különböző belső algoritmusok használatával vagy azok hangolásával annak tanulmányozását, hogy egy adott paraméter hogyan befolyásolja a rendszer teljesítményét, és melyik opció adja a legjobb eredményt. Mindez megtehető egy prototípus eszközmodellel, mielőtt létrehozna egy tényleges hardver prototípust.
Ennek a megközelítésnek a bonyolultsága abban rejlik, hogy először le kell futtatni az alkalmazást és össze kell gyűjteni a nyomkövetést, valamint a nyomkövetési fájl hatalmas mérete. Az előnyök közé tartozik, hogy az eszköznek vagy platformnak csak a kívánt részét szimulálni elég, míg a végrehajtással történő szimuláció általában komplett modellt igényel.
Tehát ebben a cikkben megvizsgáltuk a teljes platform szimuláció jellemzőit, beszéltünk a különböző szintű megvalósítások sebességéről, az órajel-ciklus szimulációról és a nyomkövetésről. A következő cikkben leírom a szimulátorok használatának főbb forgatókönyveit, mind személyes célokra, mind fejlesztési szempontból nagyvállalatoknál.
Forrás: will.com