Yn it twadde diel fan it artikel oer kompjûtersysteemsimulators sil ik yn in ienfâldige ynliedende foarm fierder prate oer kompjûtersimulators, nammentlik oer de folsleine-platfoarmsimulaasje, dy't de gemiddelde brûker it meast tsjinkomt, en ek oer de klok-by -klokmodel en spoaren, dy't faker binne yn ûntwikkeldersirkels.
В Ik spruts oer wat simulators yn 't algemien binne, lykas ek oer de nivo's fan simulaasje. No, op grûn fan dy kennis, stel ik foar om in bytsje djipper te dûken en te praten oer simulaasje op folslein platfoarm, hoe't jo spoaren sammelje, wat se letter mei te dwaan, en ek oer klok-foar-klok mikroarsjitektueremulaasje.
Folsleine platfoarmsimulator, as "Allinne yn it fjild is gjin strider"
As jo wolle studearje de wurking fan ien spesifyk apparaat, bygelyks, in netwurk kaart, of skriuwe firmware of stjoerprogramma foar dit apparaat, sa'n apparaat kin wurde simulearre apart. It gebrûk fan it yn isolemint fan 'e rest fan' e ynfrastruktuer is lykwols net heul handich. Om de oerienkommende bestjoerder út te fieren, sille jo in sintrale prosessor, ûnthâld, tagong ta in gegevensbus, ensfh. Derneist fereasket de bestjoerder in bestjoeringssysteem (OS) en in netwurkstapel om te funksjonearjen. Derneist kin in aparte pakketgenerator en antwurdtsjinner nedich wêze.
In simulator foar folslein platfoarm makket in omjouwing foar it útfieren fan in folsleine softwarestapel, dy't alles omfettet fan 'e BIOS en bootloader oant it OS sels en har ferskate subsystemen, lykas deselde netwurkstapel, bestjoerders en applikaasjes op brûkersnivo. Om dit te dwaan, ymplemintearret it softwaremodellen fan de measte kompjûterapparaten: prosessor en ûnthâld, skiif, ynfier-/útfierapparaten (toetseboerd, mûs, display), lykas deselde netwurkkaart.
Hjirûnder is in blokdiagram fan 'e x58-chipset fan Intel. In kompjûtersimulator foar folslein platfoarm op dizze chipset fereasket de ymplemintaasje fan de measte fan 'e neamde apparaten, ynklusyf dy binnen de IOH (Input/Output Hub) en ICH (Input/Output Controller Hub), dy't net yn detail ôfbylde binne op it blokdiagram . Hoewol, lykas de praktyk lit sjen, binne d'r net in protte apparaten dy't net wurde brûkt troch de software dy't wy sille útfiere. Modellen fan sokke apparaten hoege net te meitsjen.
Meastentiids wurde simulators foar folslein platfoarm útfierd op it nivo fan prosessorynstruksjes (ISA, sjoch hjirûnder). ). Hjirmei kinne jo de simulator sels relatyf fluch en goedkeap meitsje. It ISA-nivo is ek goed omdat it min of mear konstant bliuwt, oars as bygelyks it API/ABI-nivo, dat faker feroaret. Dêrnjonken kinne ymplemintaasje op it ynstruksjenivo jo saneamde unmodified binêre software útfiere, dat is, al kompilearre koade útfiere sûnder feroaringen, krekt sa't it wurdt brûkt op echte hardware. Mei oare wurden, jo kinne in kopy ("dump") meitsje fan jo hurde skiif, spesifisearje as in ôfbylding foar in model yn in folslein platfoarm simulator, en voila! - It OS en oare programma's wurde yn 'e simulator laden sûnder ekstra aksjes.
Simulator prestaasjes
Lykas hjirboppe neamde, is it proses fan it simulearjen fan it hiele systeem, dat wol sizze al syn apparaten, in nochal trage ûndernimming. As jo dit alles ek op in heul detaillearre nivo ymplementearje, bygelyks mikroarchitectural of logysk, dan sil de útfiering ekstreem stadich wurde. Mar it ynstruksjenivo is in passende kar en lit it OS en programma's útfiere mei snelheden dy't genôch binne foar de brûker om komfortabel mei har te ynteraksje.
Hjir soe it passend wêze om it ûnderwerp fan simulatorprestaasjes oan te pakken. It wurdt meastentiids metten yn IPS (ynstruksjes per sekonde), krekter yn MIPS (miljoenen IPS), dat is it oantal prosessorynstruksjes útfierd troch de simulator yn ien sekonde. Tagelyk hinget de snelheid fan 'e simulaasje ek ôf fan' e prestaasjes fan it systeem wêrop de simulaasje sels rint. Dêrom kin it krekter wêze om te praten oer de "fertraging" fan 'e simulator yn ferliking mei it orizjinele systeem.
De meast foarkommende simulators foar folslein platfoarm op 'e merke, lykas QEMU, VirtualBox of VmWare Workstation, hawwe goede prestaasjes. It kin net iens opfalle foar de brûker dat it wurk oan 'e gong is yn' e simulator. Dit bart troch de spesjale virtualisaasjemooglikheden dy't ymplementearre binne yn processors, binêre oersettingsalgoritmen en oare nijsgjirrige dingen. Dit is allegear in ûnderwerp foar in apart artikel, mar koartsein, virtualisaasje is in hardwarefunksje fan moderne processors wêrtroch simulators gjin ynstruksjes kinne simulearje, mar direkt nei in echte prosessor stjoere foar útfiering, as, fansels, de arsjitektueren fan de simulator en de prosessor binne ferlykber. Binêre oersetting is de oersetting fan gastmasjinekoade yn hostkoade en dêropfolgjende útfiering op in echte prosessor. As gefolch, de simulaasje is mar wat stadiger, 5-10 kear, en faak sels rint op deselde snelheid as it echte systeem. Hoewol dit wurdt beynfloede troch in protte faktoaren. Bygelyks, as wy in systeem wolle simulearje mei ferskate tsientallen processors, dan sil de snelheid fuortendaliks troch dizze ferskate tsientallen kearen sakje. Oan 'e oare kant stypje simulators lykas Simics yn' e lêste ferzjes multiprocessor host-hardware en effektyf parallelisearje de simulearre kearnen op 'e kearnen fan in echte prosessor.
As wy prate oer de snelheid fan microarchitectural simulaasje, dan is it meastentiids ferskate oarders fan grutte, oer 1000-10000 kear stadiger as útfiering op in gewoane kompjûter, sûnder simulaasje. En ymplemintaasjes op it nivo fan logyske eleminten binne trager troch ferskate oarders fan grutte. Dêrom wurdt in FPGA brûkt as emulator op dit nivo, wat de prestaasjes signifikant kin ferheegje.
De grafyk hjirûnder toant in ûngefear ôfhinklikens fan simulaasje snelheid op model detail.
Beat-by-beat-simulaasje
Nettsjinsteande har lege útfieringssnelheid binne mikroarchitecturale simulators frij gewoan. Simulaasje fan 'e ynterne blokken fan' e prosessor is nedich om de útfieringstiid fan elke ynstruksje sekuer te simulearjen. Hjir kin misbegryp ûntstean - ommers, it liket derop, wêrom net gewoan de útfieringstiid foar elke ynstruksje programmearje. Mar sa'n simulator sil wêze hiel unakkuraat, sûnt de útfiering tiid fan deselde ynstruksje kin ferskille fan oprop ta oprop.
De ienfâldichste foarbyld is in ûnthâld tagong ynstruksje. As de frege ûnthâldlokaasje beskikber is yn 'e cache, dan sil de útfieringstiid minimaal wêze. As dizze ynformaasje net yn 'e cache is ("cache miss"), dan sil dit de útfieringstiid fan 'e ynstruksje sterk ferheegje. Sa is in cachemodel nedich foar krekte simulaasje. De saak is lykwols net beheind ta it cachemodel. De prosessor sil net gewoan wachtsje op gegevens dy't wurde ophelle út it ûnthâld as it net yn 'e cache is. Ynstee sil it begjinne mei it útfieren fan de folgjende ynstruksjes, kieze dyjingen dy't net ôfhinklik binne fan it resultaat fan lêzen út it ûnthâld. Dit is de saneamde "out of order" útfiering (OOO, out of order útfiering), nedich om prosessor idle tiid te minimalisearjen. Modellearjen fan de oerienkommende prosessorblokken sil helpe om dit alles yn rekken te hâlden by it berekkenjen fan de útfieringstiid fan ynstruksjes. Under dizze ynstruksjes, útfierd wylst it resultaat fan it lêzen út it ûnthâld wurdt wachte, kin in betingst sprong operaasje foarkomme. As it resultaat fan 'e betingst op it stuit ûnbekend is, dan stopet de prosessor wer de útfiering net, mar makket in "riedsel", fiert de passende tûke út en bliuwt proaktyf ynstruksjes út it punt fan oergong. Sa'n blok, neamd in branch foarsizzer, moat ek wurde ymplementearre yn de microarchitectural simulator.
De foto hjirûnder lit de haadblokken fan 'e prosessor sjen, it is net nedich om it te witten, it wurdt allinich toand om de kompleksiteit fan' e mikroarsjitektoanyske ymplemintaasje te sjen.
De wurking fan al dizze blokken yn in echte prosessor wurdt syngronisearre troch spesjale klok sinjalen, en itselde bart yn it model. Sa'n microarchitectural simulator wurdt neamd syklus akkuraat. It haaddoel dêrfan is om de prestaasjes fan 'e ûntwikkele prosessor sekuer te foarsizzen en / of de útfieringstiid fan in spesifyk programma te berekkenjen, bygelyks in benchmark. As de wearden leger binne dan fereaske, dan sil it nedich wêze om de algoritmen en prosessorblokken te feroarjen of it programma te optimalisearjen.
Lykas hjirboppe toand, is klok-foar-klok simulaasje heul stadich, dus it wurdt allinich brûkt by it bestudearjen fan bepaalde mominten fan 'e operaasje fan in programma, wêr't it nedich is om de echte snelheid fan programma-útfiering út te finen en de takomstige prestaasjes fan it apparaat te evaluearjen. prototype wurdt simulearre.
Yn dit gefal wurdt in funksjonele simulator brûkt om de oerbleaune rinnende tiid fan it programma te simulearjen. Hoe komt dizze kombinaasje fan gebrûk yn 'e realiteit? Earst wurdt de funksjonele simulator lansearre, wêrop it OS en alles wat nedich is om it programma ûnder stúdzje út te fieren wurde laden. Wy binne ommers net ynteressearre yn it OS sels, noch yn 'e earste fazen fan it starten fan it programma, syn konfiguraasje, ensfh. Wy kinne dizze dielen lykwols ek net oerslaan en fuortdaliks trochgean mei it útfieren fan it programma fanôf it midden. Dêrom wurde al dizze foarriedige stappen útfierd op in funksjonele simulator. Neidat it programma is útfierd oant it momint fan belang foar ús, twa opsjes binne mooglik. Jo kinne ferfange it model mei in klok-by-syklus model en fierder útfiering. De simulaasje modus dy't brûkt útfierbere koade (dat is, gewoane kompilearre programma triemmen) hjit útfiering oandreaune simulaasje. Dit is de meast foarkommende simulaasje-opsje. In oare oanpak is ek mooglik - trace oandreaune simulaasje.
Trace-basearre simulaasje
It bestiet út twa stappen. Mei in funksjonele simulator of op in echt systeem wurdt in log fan programma-aksjes sammele en skreaun nei in bestân. Dit log wurdt in spoar neamd. Ofhinklik fan wat wurdt ûndersocht, kin it spoar útfierbere ynstruksjes, ûnthâldadressen, poartenûmers en ûnderbrekkingsynformaasje befetsje.
De folgjende stap is om it spoar te "spieljen", as de klok-foar-klok-simulator it spoar lêst en alle ynstruksjes útfiert dy't dêryn skreaun binne. Oan 'e ein krije wy de útfieringstiid fan dit stik fan it programma, lykas ferskate skaaimerken fan dit proses, bygelyks it persintaazje hits yn' e cache.
In wichtich skaaimerk fan it wurkjen mei spoaren is determinisme, dat is, troch it útfieren fan de simulaasje op 'e hjirboppe beskreaune manier, oer en wer reprodusearje wy deselde folchoarder fan aksjes. Dit makket it mooglik, troch in feroaring model parameters (cache, buffer en wachtrige grutte) en mei help fan ferskate ynterne algoritmen of tuning se, in stúdzje hoe't in bepaalde parameter beynfloedet systeem prestaasje en hokker opsje jout de bêste resultaten. Dit alles kin dien wurde mei in prototype apparaatmodel foardat jo in eigentlik hardwareprototype meitsje.
De kompleksiteit fan dizze oanpak leit yn 'e needsaak om earst de applikaasje út te fieren en it spoar te sammeljen, lykas ek de enoarme grutte fan it spoarbestân. De foardielen omfetsje it feit dat it genôch is om allinich it diel fan it apparaat of platfoarm fan belang te simulearjen, wylst simulaasje troch útfiering normaal in folslein model fereasket.
Dat, yn dit artikel hawwe wy sjoen nei de funksjes fan simulaasje op folslein platfoarm, praat oer de snelheid fan ymplemintaasjes op ferskate nivo's, klok-foar-syklus-simulaasje en spoaren. Yn it folgjende artikel sil ik de wichtichste senario's beskriuwe foar it brûken fan simulators, sawol foar persoanlike doelen as út in ûntwikkelingspunt yn grutte bedriuwen.
Boarne: www.habr.com
