Artikli teises osas, mis käsitleb arvutisüsteemide simulaatoreid, jätkan arvutisimulaatorite, sealhulgas täisplatvormilise simulaatori lihtsa ülevaate andmist, millega tavakasutaja kõige sagedamini kokku puutub, samuti takti mudelit ja radu, mis on rohkem levinud arendajate seas.
V Rääkisin, mis on simulaatorid üldiselt, ning mudelihierarhiatest. Nüüd, tuginedes sellele teadlikkusele, kutsun teid sügavamale laskuma ja rääkima täisplatvormilisest simulaatorist, kuidas rajad kokku panna, mida nendega hiljem teha ja taktikalise mikroarhitektuuri emulatsioonist.
Täisplatvormiline simulaator (full platform simulator), või "Üks lahingus ei ole sõdalane".
Kui on vajalik uurida konkreetse seadme, näiteks võrgukaardi tööd või kirjutada sellele seadmele püsivara või draiver, saab sellist seadet simuleerida eraldi. Siiski on selle kasutamine eraldi ülejäänud infrastruktuurist üsna ebamugav. Vastava draiveri käitamiseks on vajalik keskpink, mälu, juurdepääs andmeedastuse bussile ja muu. Lisaks vajab draiveri toimimiseks operatsioonisüsteemi (OS) ja võrguprotokolli. Sellele võib lisanduda eraldi pakettide generaator ja vastuste vastuvõtu server.
Täisplatvormiline simulaator loob keskkonna kogu tarkvarakihi käitamiseks, mis hõlmab kõike alates BIOS-ist ja laadimisprogrammist kuni operatsioonisüsteemi ja erinevate alamüsteemideni, nagu samuti võrguprotokoll, draiverid, ja kasutajataseme rakendused. Selleks on selles rakendatud enamik arvuti seadmete tarkvaramudeleid: protsessor ja mälu, ketas, sisend-väljund seadmed (klaviatuur, hiir, ekraan) ning see sama võrkaart.
Allpool on Intel x58 kiibi plokk-diagramm. Täisplatvormi arvutisimulaatoris sellel kiibil on vajalik enamik loetletud seadmete rakendusi, sealhulgas neid, mis asuvad IOH (sisendi/väljaande keskuses) ja ICH (sisendi/väljaande juhtimiskeskuses), mis pole plokk-diagrammil detailidena joonistatud. Kuigi praktika näitab, et paljusid seadmeid ei kasutata tarkvara, mida plaanime käivitada. Selliste seadmete mudeleid võib mitte luua.
Tavaliselt rakendatakse täisplatvormi simulaatoreid protsessori käsu tasemel (ISA, vt. ). See, it's quite fast and inexpensive to create the simulator itself. The ISA level is also good because it remains more or less constant, unlike the API/ABI level, which changes more frequently. Moreover, the instruction-level implementation allows for the execution of so-called unmodified binary software, meaning that already compiled code can be run without any alterations, just as it is used on real hardware. In other words, it's possible to create a copy (a dump) of the hard drive, specify it as an image for the model in a full-platform simulator, and voilà! – the OS and other programs load in the simulator without any additional actions.
Simulaatorite jõudlus
Nagu eespool mainitud, on kogu süsteemi, sealhulgas kõigi selle seadmete simuleerimise protsess üsna aeglane. Kui seda teostatakse veel väga detailsel tasemel, näiteks mikroarhitektuurses või loogilises, siis täitmine muutub äärmiselt aeglaseks. Küll aga on käsutuste tase sobiv valik ja võimaldab operatsioonisüsteemil ja programmide käivitamisel töötada kiirusel, mis on piisav kasutajale mugavaks suhtlemiseks nendega.
Siin on paslik puudutada simulaatorite toimivuse teemat. Tavaliselt mõõdetakse seda IPS-is (instructions per second), täpsemalt MIPS-is (millions IPS), mis tähistab protsessori poolt simulaatori poolt ühe sekundi jooksul täidetud käskude arvu. Samuti sõltub simuleerimise kiirus süsteemi jõudlusest, millel simuleerimine toimub. Seetõttu on võib-olla õigem rääkida simulaatori 'aeglustumisest' (slowdown) võrreldes originaalsüsteemiga.
Turul turul olevad täislahendusega simulaatorid, nagu QEMU, VirtualBox või VmWare Workstation, pakuvad head jõudlust. Kasutaja ei pruugi isegi märgata, et töö toimub simulaatoris. See juhtub tänu protsessorites rakendatud virtualiseerimisele, binaarsele tõlkele ja teistele huvitavatele elementidele. See on kõik teema eraldi artiklile, kuid lühidalt öeldes, virtualiseerimine on kaasaegsete protsessorite riistvaraline võimalus, mis võimaldab simulaatoritel mitte simuleerida käske, vaid edastada need otse reaalsesse protsessorisse, kui simulaatori ja protsessori arhitektuur on sarnased. Binaarne tõlge on külalistemüürikoodi tõlkimine host-koodi ja selle järgnevalt sooritamine reaalses protsessoris. Tulemuseks on, et simuleerimine on vaid veidi aeglasem, 5–10 korda, ja tihti töötab see üldse sama kiiresti kui reaalne süsteem. Kuigi sellele mõjutab palju tegureid. Näiteks, kui soovime simuleerida süsteemi, millel on mõned tosinad protsessorit, siis kiirus kukub kohe mitmekümne korra võrra. Teiselt poolt toetavad Simicsi tüüpi simulaatorid viimastes versioonides mitme protsessoriga host-seadmeid ja tõhusalt jaotavad simuleeritud tuumad uute protsessori tuumadele.
Kui rääkida mikroarhitektuuri simuleerimise kiirusest, siis on see tavaliselt mitme järgu võrra, umbes 1000–10000 korda, aeglasem kui tavalise arvuti töötlemine ilma simulatsioonita. Ja rakendused, mis toimivad loogikasüsteemide tasemel, on veel aeglasemad. Seetõttu kasutatakse sellel tasemel emulaatorina FPGA-sid, mis võimaldab oluliselt suurendada jõudlust.
Allolev graafik illustreerib simulatsiooni kiiruse sõltuvust mudeli detailsusest.
Südametoonide simulatsioon
Hoolimata madalast töötlemise kiirusest on mikroarhitektuuri simulaatorid üsna levinud. Protsessori sisemiste plokkide modelleerimine on vajalik, et täpselt simuleerida iga käsu täitmise aega. Siin võib tekkida arusaamatus – miks mitte võtta ja programmeerida iga käsu täitmise aeg? Kuid selline simulaator töötaks väga ebatäpselt, kuna ühe ja sama käsu täitmise aeg võib varieeruda sõltuvalt kutsest.
Lihtne näide – mälu päringu juhend. Kui küsitud mälurakk on vahemälus saadaval, siis täitmise aeg on minimaalne. Kui selles vahemälus ei ole vajalikku teavet ("vahemälu tabamine", cache miss), siis see oluliselt pikendab käskluse täitmise aega. Seetõttu on täpseks simuleerimiseks vajalik vahemälu mudel. Siiski ei piirdu asi vaid vahemälu mudeliga. Protsessor ei hakka lihtsalt ootama andmete saamist mälust, kui need pole vahemälus saadaval. Selle asemel alustab ta järgmiste käskluste täitmist, valides need, mis ei sõltu mälu lugemise tulemusest. See on nii-öelda „järjestusest kõrvalekaldumine” (Out Of Order Execution, OOO), mis on vajalik protsessori seiskamisaja minimeerimiseks. Kõigi nende aspektide arvestamine käskluste täitmise aja arvutamisel aitab simuleerida vastavaid protsessoriblokke. Nende käskluste seas, mis täidetakse, kuni oodatakse mälu lugemise tulemust, võib esineda tingimusliku hüppe operatsioon. Kui tingimuse täitmise tulemus ei ole hetkel teada, siis protsessor ei peatu täitmist, vaid teeb „eeldamise”, aitab vastavat hüpet ja jätkab ennetavalt käskluste täitmist hüppe asukohast. Selline plokk, mida nimetatakse haruhalduriks (branch predictor), peab samuti olema mikroarhitektuurisimulaatoris rakendatud.
Allpool näidatud pilt näitab protsessori põhibloke, mille tundmine pole hädavajalik; see on esitatud ainult mikroarhitektuurilise teostuse keerukuse näitamiseks.
Tõelise protsessori kõigi nende blokki töö sünkroniseeritakse spetsiaalsete taktsignaalidega, nagu toimub ka mudelis. Sellist mikroarhitektuurilist simulaatorit nimetatakse taktsimulaatoriks (cycle accurate). Selle peamine eesmärk on täpselt prognoosida arendatava protsessori jõudlust ja/või arvutada konkreetse programmi, näiteks mingisuguse testprogrammi, täitmise aega. Kui väärtused on madalamad kui vajalikud, tuleb töötada välja algoritme ja protsessori bloke või optimeerida programmi.
Nagu ülal näidatud, on taktsimuleerimine väga aeglane, seetõttu kasutatakse seda ainult teatud programmide töö uurimiseks, kus on vajalik teada programmide tegelikku täitmise kiirus ja hinnata seadme tulevast jõudlust, mille prototüüp on simuleeritud.
Samuti kasutatakse programmide töötamise ülejäänud aja simuleerimiseks funktsionaalset simulaatorit. Kuidas selline kombineeritud kasutamine tegelikult toimub? Esiteks käivitatakse funktsionaalne simulaator, kus laaditakse operatsioonisüsteem ja kõik vajalik uuritava programmi käivitamiseks. Meid ei huvita ei operatsioonisüsteem ise, ei programmi käivitamise algstaadiumid, selle seadistamine jne. Kuid me ei saa need osad vahele jätta ja kohe programmi täitmise keskele minna. Seega kõik need eelnevad etapid läbivad funktsionaalset simulaatorit. Pärast seda, kui programm on täidetud meie huvipakkuva hetkeni, on kaks võimalust. Saame mudeli asendada taktisüsteemiga ja jätkata täitmist. Täitmisrežiimi, kus kasutatakse täidetavat koodi (st tavalisi kompileeritud programmifaile), nimetatakse täitmisjuhtimise simuleerimiseks (execution driven simulation). See on kõige levinum simuleerimise variant. Samuti on võimalik teine lähenemisviis – jälgede põhine simuleerimine (trace driven simulation).
Jälgede põhine simuleerimine
See koosneb kahest sammust. Funktsionaalse simulaatori abil või reaalsetes süsteemides kogutakse ja salvestatakse programmitegevuse logi faili. Sellist logi nimetatakse jäljendiks (trace). Sõltuvalt uuritavast sisust võib jäljend sisaldada teostatavaid instruktsioone, mäluaadresse, portide numbreid ja katkestuste teavet.
Järgmine samm on jäljendi «mängimine», kui taktsimulaator loeb jäljendi ja täidab kõik seal kirja pandud instruktsioonid. Lõpuks saame selle programmi tükikese töötamise aja ning erinevaid selle protsessi omadusi, näiteks vahemälu tabamuse protsendi.
Tähtis aspekt jälgimise juures on determinismi olemasolu, see tähendab, et käivitades simulatsiooni eelpool kirjeldatud viisil, kulgeb iga kord sama sündmuste jada. See võimaldab mudeli parameetreid (vahemälu, puhver ja järjekorrad) muutuvaid ja kasutades erinevaid sisemisi algoritme või neid kohandades uurida, kuidas teatud parameeter mõjutab süsteemi jõudlust ning milline variant annab parimaid tulemusi. Kõike seda saab teha seadme prototüübi mudeliga enne reaalse riistvara prototüübi loomist.
Selle lähenemise keerukus seisneb rakenduse eelneva läbimise ja jälje kogumise vajaduses ning jälje faili tohutu suuruses. Plusside seas on see, et piisab vaid huvipakkuva osa modelleerimisest seadmest või platvormist, samas kui täitmise simulatsioon nõuab tavaliselt kogu mudelit.
Nii, selles artiklis arutame põhjalikult platvormipõhise simulatsiooni omadusi, räägime erinevatel tasanditel jõudluse kiirusest, takti simulatsioonist ja radadest. Järgmises artiklis kirjeldan peamisi kasutusvõimalusi simulaatorite jaoks, olgu need isiklikuks otstarbeks või suurte ettevõtete arendustegevuses.
Allikas: habr.com
