I den andra delen av artikeln om simulatorer av datorsystem kommer jag att fortsÀtta att förklara pÄ ett enkelt och informativt sÀtt om datorsimulatorer, nÀmligen om fullplattformssimulation, som en vanlig anvÀndare oftast stöter pÄ, samt om taktsynkronisering och banor som Àr mer utbredda inom utvecklarkretsar.
I Jag har berÀttat om vad simulatorer Àr generellt sett, samt om nivÄerna av modellering. Nu, baserat pÄ denna kunskap, föreslÄr jag att vi dyker lite djupare och pratar om fullplattformssimulation, hur man bygger banor, vad man sedan ska göra med dem, samt om taktsynkroniserad mikroarkitektur-emulering.
Fullplattformssimulator (full platform simulator), eller "En ensam kÀmpe Àr ingen kÀmpe"
Om det Àr nödvÀndigt att undersöka funktionen hos en specifik enhet, som ett nÀtverkskort, eller att skriva firmware eller drivrutiner för denna enhet, kan enheten simuleras separat. Det Àr dock inte sÀrskilt praktiskt att anvÀnda den frikopplad frÄn den övriga infrastrukturen. För att kunna köra den relevanta drivrutinen krÀvs en centralprocessor, minne, tillgÄng till buss för datatransfer med mera. Dessutom behövs ett operativsystem (OS) och nÀtverksstack för att drivrutinen ska fungera. Utöver detta kan en separat paketgenerator och en svarserver behövas.
Fullplattformssimulatorn skapar en miljö för att köra hela programvarustacken, som inkluderar allt frÄn BIOS och bootloader till sjÀlva operativsystemet och dess olika delsystem, sÄsom nÀtverksstacken, drivrutinerna och anvÀndarapplikationer. För detta syfte implementeras programmodeller för de flesta enheterna i datorn: processor och minne, disk, in- och utmatningsenheter (tangentbord, mus, skÀrm), samt det samma nÀtverkskortet.
Nedan finns en blockschema över x58-chipsatsen frĂ„n Intel. I en fullskalig simulering av en dator baserad pĂ„ denna chipsats mĂ„ste de flesta av de angivna enheterna implementeras, inklusive de som finns inuti IOH (Input/Output Hub) och ICH (Input/Output Controller Hub), som inte detaljeras i blockschemat. Ăven om det i praktiken finns ganska mĂ„nga enheter som inte anvĂ€nds av den programvara vi planerar att köra. Modeller av sĂ„dana enheter behöver inte skapas.
Oftast implementeras fullskaliga simulatorer pĂ„ processorns instruktion nivĂ„ (ISA, se ). Detta gör att simulatorn kan skapas relativt snabbt och billigt. ISA-nivĂ„n Ă€r ocksĂ„ bra eftersom den förblir mer eller mindre konstant, till skillnad frĂ„n till exempel API/ABI-nivĂ„n, som förĂ€ndras oftare. Dessutom gör implementeringen pĂ„ instruktion nivĂ„ det möjligt att köra sĂ„ kallad oförĂ€ndrad binĂ€r programvara, det vill sĂ€ga att köra redan kompilerad kod utan nĂ„gra förĂ€ndringar, precis som den anvĂ€nds pĂ„ riktig hĂ„rdvara. Med andra ord kan man göra en kopia ("dump") av hĂ„rddisken, ange den som en avbild för modellen i den fullskaliga simulatorn och â voilĂ ! â OS och andra program startar i simulatorn utan nĂ„gra extra Ă„tgĂ€rder.
Prestanda hos simulatorer
Som nÀmnts ovan Àr sjÀlva simuleringsprocessen av hela systemet, det vill sÀga alla dess enheter, ganska lÄngsam. Om man dessutom implementerar allt detta pÄ en helt detaljerad nivÄ, till exempel mikroarkitektur eller logisk nivÄ, blir utförandet extremt lÄngsamt. Men instruktion nivÄ Àr ett lÀmpligt val och gör att OS och program kan köras med hastigheter som Àr tillrÀckliga för anvÀndaren för att interagera med dem bekvÀmt.
HÀr Àr det ocksÄ lÀmpligt att beröra Àmnet simulatorers prestanda. Vanligtvis mÀts den i IPS (instructions per second), nÀrmare bestÀmt i MIPS (miljoner IPS), det vill sÀga antalet processorinstruktioner som simulatorn utför pÄ en sekund. Samtidigt beror simuleringshastigheten ocksÄ pÄ prestandan hos systemet som simuleringsprocessen körs pÄ. DÀrför kan det vara mer korrekt att prata om "nedbromsning" (slowdown) av simulatorn jÀmfört med originalsistema.
De mest anvĂ€nda plattformssimulatorerna pĂ„ marknaden, som QEMU, VirtualBox eller VmWare Workstation, erbjuder bra prestanda. För anvĂ€ndaren kan det till och med vara osynligt att arbetet utförs i en simulator. Detta beror pĂ„ den speciella virtualiseringsmöjligheten i processorer, algoritmer för binĂ€r översĂ€ttning och andra intressanta saker. Detta Ă€r dock ett Ă€mne för en separat artikel, men för att sammanfatta, sĂ„ Ă€r virtualisering en hĂ„rdvarufunktion av moderna processorer som gör att simulatorer inte simulerar instruktioner, utan direkt kan överlĂ€mna dem för exekvering till den verkliga processorn, förutsatt att arkitekturerna för simulatorn och processorn liknar varandra. BinĂ€r översĂ€ttning innebĂ€r att översĂ€tta gĂ€standets maskinkod till vĂ€rdmaskinkod och dĂ€refter köra den pĂ„ den verkliga processorn. Resultatet Ă€r att simuleringen endast Ă€r nĂ„got lĂ„ngsammare, typ 5-10 gĂ„nger, och ofta fungerar med samma hastighet som det verkliga systemet. Ăven om mĂ„nga faktorer pĂ„verkar detta. Till exempel, om vi vill simulera ett system med flera dussin processorer, sĂ„ faller hastigheten direkt med dessa flera dussin gĂ„nger. Ă andra sidan stödjer simulatorer som Simics i de senaste versionerna multiprocessorhost-konstruktioner effektivt och parallelliserar de simulerade kĂ€rnorna pĂ„ de verkliga processorkĂ€rnorna.
NÀr det kommer till hastigheten av mikroarkitekturell simulering, Àr detta vanligtvis flera ordningar, ungefÀr 1000-10000 gÄnger, lÄngsammare Àn exekveringen pÄ en vanlig dator, utan simulering. Och implementationer pÄ nivÄ av logiska element Àr Ànnu lÄngsammare med flera ordningar. DÀrför anvÀnds FPGA som emulator pÄ denna nivÄ, vilket avsevÀrt ökar prestandan.
Diagrammet nedan visar den ungefÀrliga relationen mellan simuleringens hastighet och modellens detaljnivÄ.
Klockcykelsimulering
Trots den lĂ„ga hastigheten pĂ„ utförande Ă€r mikroarkitektur-simulatorer ganska vanliga. Modellering av interna processorblock Ă€r nödvĂ€ndig för att exakt simulera tiden för att utföra varje instruktion. HĂ€r kan det uppstĂ„ missförstĂ„nd â varför ska man inte bara programmera utförandetiden för varje instruktion? Men en sĂ„dan simulator skulle fungera mycket imprecist, eftersom tiden för att utföra samma instruktion kan variera mellan olika anrop.
Ett enkelt exempel Ă€r instruktionen för minnesĂ„tkomst. Om den begĂ€rda minnescellen finns i cache-minnet blir tiden för utförande minimal. Om denna information inte finns i cachen (cache miss) ökar tiden för att utföra instruktionen avsevĂ€rt. DĂ€rför behövs en cache-modell för noggrann simulering. Men det handlar inte bara om cache-modellen. Processorn kommer inte bara att vĂ€nta pĂ„ data frĂ„n minnet nĂ€r den inte finns i cachen. IstĂ€llet kommer den att börja utföra nĂ€sta instruktioner, vĂ€lja sĂ„dana som inte beror pĂ„ resultatet av lĂ€sningen frĂ„n minnet. Detta kallas âutanför ordningâ (OOO, out of order execution), vilket Ă€r nödvĂ€ndigt för att minimera processorstillestĂ„nd. Att ta hĂ€nsyn till allt detta nĂ€r man berĂ€knar tiden för att utföra instruktioner hjĂ€lper modelleringen av motsvarande processorblock. Bland dessa instruktioner som körs under tiden som man vĂ€ntar pĂ„ resultatet frĂ„n minneslĂ€sningen kan det finnas en villkorsstyrd hoppoperation. Om resultatet av villkoret Ă€r okĂ€nt för tillfĂ€llet stoppar inte processorn utförandet, utan gör en âgissningâ, utför det motsvarande hoppet och fortsĂ€tter proaktivt att utföra instruktioner frĂ„n hoppets plats. En sĂ„dan block, kallad branch predictor, mĂ„ste ocksĂ„ implementeras i mikroarkitektur-simulatorn.
Bilden nedan visar de grundlÀggande blocken i processorn, det Àr inte nödvÀndigt att kÀnna till dem, de Àr endast presenterade för att visa komplexiteten i mikroarkitekturella implementationer.
Arbetet av alla dessa block i en verklig processor synkroniseras av speciella klocksignaler, pÄ liknande sÀtt som det sker i modellen. En sÄdan mikroarkitektursimulator kallas cyklisk (cycle accurate). Dess huvudsakliga syfte Àr att noggrant förutsÀga prestandan hos den utvecklade processorn och/eller berÀkna exekveringstiden för ett specifikt program, till exempel ett benchmark. Om vÀrdena ligger under de nödvÀndiga, behöver algoritmer och processorblock justeras eller programmet optimeras.
Som nÀmnts ovan Àr cyklisk simulering mycket lÄngsam, dÀrför anvÀnds den endast vid undersökning av vissa aspekter av programmets arbete, dÀr det Àr nödvÀndigt att veta den verkliga hastigheten vid programexekvering och bedöma den framtida prestandan hos enheten vars prototyp simuleras.
För simuleringen av resten av programmets körning anvÀnds en funktionell simulator. Hur sker sÄdan kombinerad anvÀndning i verkligheten? Först startas den funktionella simulatorn, dÀr operativsystemet och allt som behövs för att köra det undersökta programmet laddas. Vi Àr inte intresserade av sjÀlva operativsystemet, eller de initierande stegen i programstarten, konfigurationen med mera. Men vi kan inte hoppa över dessa delar och gÄ direkt till att exekvera programmet frÄn mitten. DÀrför körs alla dessa preliminÀra steg pÄ den funktionella simulatorn. NÀr programmet har kört fram till den punkt som intresserar oss, finns det tvÄ alternativ. Man kan byta till den cykliska modellen och fortsÀtta exekveringen. Den simuleringslÀge dÀr den exekverbara koden anvÀnds (dvs. vanliga kompilera programfiler) kallas exekveringsdriven simulering (execution driven simulation). Detta Àr det mest förekommande alternativet för simulering. Det finns ocksÄ en annan metod - simulering baserad pÄ spÄr (trace driven simulation).
Simulering baserad pÄ spÄr
Den bestÄr av tvÄ steg. Med hjÀlp av en funktionell simulator eller pÄ ett verkligt system samlas och skrivs programmets ÄtgÀrder ner i en loggfil. Denna logg kallas spÄr (trace). Beroende pÄ vad som undersöks kan spÄret inkludera körbara instruktioner, minnesadresser, portnummer, information om avbrott.
NÀsta steg Àr "uppspelning" av spÄret, dÀr taktfrekvensimulatorn lÀser spÄret och utför alla instruktioner som Àr skrivna i det. I slutet fÄr vi tiden för att köra detta programsegment, samt olika egenskaper för denna process, sÄsom trÀffprocent pÄ cache.
En viktig aspekt av att arbeta med spÄr Àr determinism, det vill sÀga att genom att köra simuleringen pÄ det sÀtt som beskrivits ovan, Äterskapar vi samma sekvens av ÄtgÀrder gÄng pÄ gÄng. Detta ger möjlighet att, genom att Àndra modellparametrar (cachestorlekar, buffrar och köer) och anvÀnda olika interna algoritmer eller anpassa dem, undersöka hur en viss parameter pÄverkar systemets prestanda och vilket alternativ som ger bÀst resultat. Allt detta kan göras med prototypmodellen av en enhet innan en verklig hÄrdvarupr prototyp skapas.
Komplexiteten i detta tillvÀgagÄngssÀtt ligger i behovet av att förhandsköra applikationen och samla in spÄret, samt den enorma storleken pÄ spÄrfilen. Fördelarna inkluderar att det rÀcker att modellera endast den del av enheten eller plattformen som Àr av intresse, medan simulering av exekvering vanligtvis krÀver en komplett modell.
SÄ, i den hÀr artikeln har vi granskat egenskaperna hos plattformsövergripande simulering, diskuterat hastigheten för implementationer pÄ olika nivÄer, taktfrekvenssimulering och spÄr. I nÀsta artikel kommer jag att beskriva de viktigaste anvÀndningsscenarierna för simulatorer, bÄde för personliga ÀndamÄl och ur ett utvecklingsperspektiv i stora företag.
KĂ€lla: habr.com
