In die tweede deel van die artikel oor rekenaarstelselsimulators gaan ek voort om in 'n eenvoudige inleidende vorm oor rekenaarsimulators te praat, naamlik oor die volle-platform-simulasie, wat die gemiddelde gebruiker die meeste teëkom, asook oor die klok-by -klokmodel en spore, wat meer algemeen in ontwikkelaarkringe voorkom.
В Ek het gepraat oor wat simulators in die algemeen is, sowel as oor die vlakke van simulasie. Nou, gebaseer op daardie kennis, stel ek voor om 'n bietjie dieper te duik en te praat oor volplatform-simulasie, hoe om spore te versamel, wat om later daarmee te doen, sowel as oor klok-vir-klok mikroargitektoniese emulasie.
Volledige platformsimulator, of "Alleen in die veld is nie 'n vegter nie"
As jy die werking van een spesifieke toestel wil bestudeer, byvoorbeeld 'n netwerkkaart, of firmware of 'n drywer vir hierdie toestel wil skryf, dan kan so 'n toestel afsonderlik gesimuleer word. Dit is egter nie baie gerieflik om dit in isolasie van die res van die infrastruktuur te gebruik nie. Om die ooreenstemmende drywer te laat loop, benodig jy 'n sentrale verwerker, geheue, toegang tot 'n databus, ens. Daarbenewens benodig die bestuurder 'n bedryfstelsel (OS) en 'n netwerkstapel om te funksioneer. Daarbenewens kan 'n aparte pakkiegenerator en reaksiebediener vereis word.
'n Volplatform-simulator skep 'n omgewing om 'n volledige sagtewarestapel te laat loop, wat alles insluit van die BIOS en selflaaiprogram tot die bedryfstelsel self en sy verskeie substelsels, soos dieselfde netwerkstapel, drywers en gebruikersvlaktoepassings. Om dit te doen, implementeer dit sagtewaremodelle van die meeste rekenaartoestelle: verwerker en geheue, skyf, invoer-/uitvoertoestelle (sleutelbord, muis, skerm), sowel as dieselfde netwerkkaart.
Hieronder is 'n blokdiagram van die x58-skyfiestel van Intel. 'n Volplatform rekenaarsimulator op hierdie skyfiestel vereis die implementering van die meeste van die gelyste toestelle, insluitend dié binne die IOH (Input/Output Hub) en ICH (Input/Output Controller Hub), wat nie in detail op die blokdiagram uitgebeeld word nie. . Alhoewel, soos die praktyk toon, daar nie baie toestelle is wat nie gebruik word deur die sagteware wat ons gaan gebruik nie. Modelle van sulke toestelle hoef nie geskep te word nie.
Meestal word volplatform-simulators op die verwerkerinstruksievlak geïmplementeer (ISA, sien hieronder). ). Dit laat jou toe om die simulator self relatief vinnig en goedkoop te skep. Die ISA-vlak is ook goed omdat dit min of meer konstant bly, anders as byvoorbeeld die API/ABI-vlak, wat meer gereeld verander. Daarbenewens laat implementering op die instruksievlak jou toe om sogenaamde ongemodifiseerde binêre sagteware te laat loop, dit wil sê om reeds saamgestelde kode sonder enige veranderinge uit te voer, presies soos dit op regte hardeware gebruik word. Met ander woorde, jy kan 'n kopie ("dump") van jou hardeskyf maak, dit spesifiseer as 'n prent vir 'n model in 'n volplatform-simulator, en voila! - Die bedryfstelsel en ander programme word in die simulator gelaai sonder enige bykomende aksies.
Simulator prestasie
Soos net hierbo genoem, is die proses om die hele stelsel te simuleer, dit wil sê al sy toestelle, 'n taamlik stadige onderneming. As jy dit alles ook op 'n baie gedetailleerde vlak implementeer, byvoorbeeld mikroargitektonies of logies, sal uitvoering uiters stadig word. Maar die instruksievlak is 'n gepaste keuse en laat die bedryfstelsel en programme toe om teen 'n spoed uit te voer wat voldoende is vir die gebruiker om gemaklik daarmee te kommunikeer.
Hier sal dit gepas wees om die onderwerp van simulatorprestasie aan te raak. Dit word gewoonlik gemeet in IPS (instruksies per sekonde), meer presies in MIPS (miljoene IPS), dit wil sê die aantal verwerkerinstruksies wat deur die simulator in een sekonde uitgevoer word. Terselfdertyd hang die spoed van die simulasie ook af van die werkverrigting van die stelsel waarop die simulasie self loop. Daarom kan dit meer korrek wees om te praat oor die "vertraging" van die simulator in vergelyking met die oorspronklike stelsel.
Die mees algemene volplatform-simulators op die mark, soos QEMU, VirtualBox of VmWare Workstation, het goeie werkverrigting. Dit is dalk nie eens vir die gebruiker opmerklik dat daar in die simulator werk aan die gang is nie. Dit gebeur danksy die spesiale virtualiseringsvermoëns wat in verwerkers geïmplementeer is, binêre vertaalalgoritmes en ander interessante dinge. Dit is alles 'n onderwerp vir 'n aparte artikel, maar kortliks, virtualisering is 'n hardeware-eienskap van moderne verwerkers wat simulators in staat stel om nie instruksies te simuleer nie, maar om dit direk na 'n regte verwerker te stuur, as natuurlik die argitekture van die simulator en die verwerker is soortgelyk. Binêre vertaling is die vertaling van gasmasjienkode in gasheerkode en daaropvolgende uitvoering op 'n regte verwerker. Gevolglik is die simulasie net effens stadiger, 5-10 keer, en loop dikwels selfs teen dieselfde spoed as die werklike stelsel. Alhoewel dit deur baie faktore beïnvloed word. Byvoorbeeld, as ons 'n stelsel met 'n paar dosyn verwerkers wil simuleer, sal die spoed onmiddellik met hierdie 'n paar dosyn keer daal. Aan die ander kant ondersteun simulators soos Simics in die nuutste weergawes multiverwerker gasheer hardeware en paralleliseer effektief die gesimuleerde kerns op die kerns van 'n regte verwerker.
As ons praat oor die spoed van mikroargitektoniese simulasie, dan is dit gewoonlik verskeie ordes van grootte, ongeveer 1000-10000 keer stadiger as uitvoering op 'n gewone rekenaar, sonder simulasie. En implementering op die vlak van logiese elemente is stadiger met verskeie ordes van grootte. Daarom word 'n FPGA as 'n emulator op hierdie vlak gebruik, wat prestasie aansienlik kan verhoog.
Die grafiek hieronder toon 'n benaderde afhanklikheid van simulasiespoed op modeldetail.
Klop-vir-slag-simulasie
Ten spyte van hul lae uitvoeringspoed, is mikroargitektoniese simulators redelik algemeen. Simulasie van die interne blokke van die verwerker is nodig om die uitvoeringstyd van elke instruksie akkuraat te simuleer. Misverstande kan hier ontstaan - na alles, wil dit voorkom, waarom nie bloot die uitvoeringstyd vir elke instruksie programmeer nie. Maar so 'n simulator sal baie onakkuraat wees, aangesien die uitvoeringstyd van dieselfde instruksie van oproep tot oproep kan verskil.
Die eenvoudigste voorbeeld is 'n geheuetoegangsinstruksie. As die gevraagde geheue-ligging in die kas beskikbaar is, sal die uitvoeringstyd minimaal wees. As hierdie inligting nie in die kas is nie (“cache miss”), sal dit die uitvoeringstyd van die instruksie aansienlik verhoog. Dus, 'n kasmodel word benodig vir akkurate simulasie. Die saak is egter nie beperk tot die kasmodel nie. Die verwerker sal nie net wag dat data uit die geheue gehaal word wanneer dit nie in die kas is nie. In plaas daarvan sal dit die volgende instruksies begin uitvoer en dié kies wat nie afhang van die resultaat van die lees uit die geheue nie. Dit is die sogenaamde "buite orde" uitvoering (OOO, buite werking uitvoering), wat nodig is om verwerker se ledige tyd te minimaliseer. Modellering van die ooreenstemmende verwerkerblokke sal help om dit alles in ag te neem wanneer die uitvoeringstyd van instruksies bereken word. Onder hierdie instruksies, wat uitgevoer word terwyl die resultaat van die lees uit die geheue gewag word, kan 'n voorwaardelike sprongoperasie voorkom. As die resultaat van die toestand op die oomblik onbekend is, stop die verwerker weer nie uitvoering nie, maar maak 'n "raai", voer die toepaslike tak uit en gaan voort om proaktief instruksies uit te voer vanaf die punt van oorgang. So 'n blok, wat 'n takvoorspeller genoem word, moet ook in die mikroargitektoniese simulator geïmplementeer word.
Die prent hieronder toon die hoofblokke van die verwerker, dit is nie nodig om dit te weet nie, dit word slegs gewys om die kompleksiteit van die mikroargitektoniese implementering te wys.
Die werking van al hierdie blokke in 'n regte verwerker word gesinchroniseer deur spesiale klokseine, en dieselfde gebeur in die model. So 'n mikroargitektoniese simulator word siklus akkuraat genoem. Die hoofdoel daarvan is om die werkverrigting van die verwerker wat ontwikkel word akkuraat te voorspel en/of die uitvoeringstyd van 'n spesifieke program, byvoorbeeld 'n maatstaf, te bereken. As die waardes laer is as wat vereis word, sal dit nodig wees om die algoritmes en verwerkerblokke te verander of die program te optimaliseer.
Soos hierbo getoon, is klok-vir-klok simulasie baie stadig, dus word dit slegs gebruik wanneer sekere oomblikke van 'n program se werking bestudeer word, waar dit nodig is om die werklike spoed van programuitvoering uit te vind en die toekomstige werkverrigting van die toestel waarvan die prototipe word gesimuleer.
In hierdie geval word 'n funksionele simulator gebruik om die oorblywende looptyd van die program te simuleer. Hoe gebeur hierdie kombinasie van gebruik in werklikheid? Eerstens word die funksionele simulator geloods, waarop die bedryfstelsel en alles wat nodig is om die studieprogram uit te voer, gelaai word. Ons stel immers nie belang in die bedryfstelsel self nie, ook nie in die aanvanklike stadiums van die bekendstelling van die program, die konfigurasie daarvan, ens. Ons kan egter ook nie hierdie dele oorslaan en dadelik voortgaan om die program van die middel af uit te voer nie. Daarom word al hierdie voorlopige stappe op 'n funksionele simulator uitgevoer. Nadat die program uitgevoer is tot die oomblik wat vir ons van belang is, is twee opsies moontlik. Jy kan die model vervang met 'n klok-vir-siklus model en voortgaan met uitvoering. Die simulasiemodus wat uitvoerbare kode (dit wil sê gereeld saamgestelde programlêers) gebruik, word uitvoeringgedrewe simulasie genoem. Dit is die mees algemene simulasie opsie. 'n Ander benadering is ook moontlik - spoorgedrewe simulasie.
Spoor-gebaseerde simulasie
Dit bestaan uit twee stappe. Deur 'n funksionele simulator of op 'n werklike stelsel te gebruik, word 'n log van programaksies versamel en na 'n lêer geskryf. Hierdie log word 'n spoor genoem. Afhangende van wat ondersoek word, kan die spoor uitvoerbare instruksies, geheue-adresse, poortnommers en onderbrekingsinligting insluit.
Die volgende stap is om die spoor te "speel", wanneer die klok-vir-klok-simulator die spoor lees en al die instruksies wat daarin geskryf is, uitvoer. Aan die einde kry ons die uitvoeringstyd van hierdie stuk van die program, sowel as verskeie kenmerke van hierdie proses, byvoorbeeld die persentasie treffers in die kas.
'n Belangrike kenmerk van die werk met spore is determinisme, dit wil sê, deur die simulasie uit te voer op die wyse hierbo beskryf, herhaal ons oor en oor dieselfde volgorde van aksies. Dit maak dit moontlik om, deur modelparameters (kas-, buffer- en tougroottes) te verander en verskillende interne algoritmes te gebruik of dit in te stel, te bestudeer hoe 'n bepaalde parameter stelselwerkverrigting beïnvloed en watter opsie die beste resultate gee. Dit alles kan gedoen word met 'n prototipe toestelmodel voordat 'n werklike hardeware prototipe geskep word.
Die kompleksiteit van hierdie benadering lê in die behoefte om eers die toepassing te laat loop en die spoor te versamel, sowel as die groot grootte van die spoorlêer. Die voordele sluit in die feit dat dit genoeg is om slegs die deel van die toestel of platform van belang te simuleer, terwyl simulasie deur uitvoering gewoonlik 'n volledige model vereis.
Dus, in hierdie artikel het ons gekyk na die kenmerke van volle-platform-simulasie, gepraat oor die spoed van implementering op verskillende vlakke, klok-vir-siklus simulasie en spore. In die volgende artikel sal ek die hoofscenario's vir die gebruik van simulators beskryf, beide vir persoonlike doeleindes en vanuit 'n ontwikkelingsoogpunt in groot maatskappye.
Bron: will.com