En la dua parto de la artikolo pri komputilaj simuliloj mi daŭre parolos en simpla enkonduka formo pri komputilaj simuliloj, nome pri la plenplatforma simulado, kiun plej ofte renkontas la averaĝa uzanto, kaj ankaŭ pri la horloĝo. -horloĝo modelo kaj spuroj, kiuj estas pli oftaj en programisto rondoj.
В Mi parolis pri tio, kio estas simuliloj ĝenerale, kaj ankaŭ pri la niveloj de simulado. Nun, surbaze de tiu scio, mi proponas plonĝi iom pli profunden kaj paroli pri plenplatforma simulado, kiel kolekti spurojn, kion fari kun ili poste, kaj ankaŭ pri horloĝo-post-horloĝa mikroarkitektura emulado.
Plena platforma simulilo, aŭ "Sole sur la kampo ne estas militisto"
Se vi volas studi la funkciadon de unu specifa aparato, ekzemple retkarto, aŭ skribi firmware aŭ ŝoforon por ĉi tiu aparato, tiam tia aparato povas esti simulita aparte. Tamen uzi ĝin izolite de la resto de la infrastrukturo ne estas tre oportuna. Por ruli la respondan ŝoforon, vi bezonos centran procesoron, memoron, aliron al datumbuso, ktp. Krome, la ŝoforo postulas operaciumon (OS) kaj retan stakon por funkcii. Krome, aparta pakaĵgeneratoro kaj respondservilo povas esti postulataj.
Plenplatforma simulilo kreas medion por ruli kompletan programaron, kiu inkluzivas ĉion de la BIOS kaj ekŝargilo ĝis la OS mem kaj ĝiaj diversaj subsistemoj, kiel la sama reto stako, ŝoforoj kaj uzantnivelaj aplikoj. Por fari tion, ĝi efektivigas programajn modelojn de la plej multaj komputilaj aparatoj: procesoro kaj memoro, disko, enigo/eligo-aparatoj (klavaro, muso, ekrano), same kiel la sama retkarto.
Malsupre estas blokdiagramo de la pecetaro x58 de Intel. Plenplatforma komputila simulilo sur ĉi tiu pecetaro postulas la efektivigon de la plej multaj el la listigitaj aparatoj, inkluzive de tiuj ene de la IOH (Enigo/Eliga Nabo) kaj ICH (Enigo/Eligo-Regilo-Nabo), kiuj ne estas detale prezentitaj sur la blokdiagramo. . Kvankam, kiel praktiko montras, ne estas multaj aparatoj, kiuj ne estas uzataj de la programaro, kiun ni funkcios. Modeloj de tiaj aparatoj ne bezonas esti kreitaj.
Plej ofte, plen-platformaj simuliloj estas efektivigitaj sur la procesora instrukcinivelo (ISA, vidu malsupre). ). Ĉi tio permesas vin krei la simulilon mem relative rapide kaj malmultekoste. La ISA-nivelo ankaŭ estas bona ĉar ĝi restas pli-malpli konstanta, male al, ekzemple, la API/ABI-nivelo, kiu ŝanĝiĝas pli ofte. Krome, efektivigo ĉe la instruknivelo permesas ruli tiel nomatan nemodifitan binaran programaron, tio estas, ruli jam kompilitan kodon sen ajnaj ŝanĝoj, ekzakte kiel ĝi estas uzata sur reala aparataro. Alivorte, vi povas fari kopion ("dump") de via malmola disko, specifi ĝin kiel bildon por modelo en plenplatforma simulilo, kaj voila! - La OS kaj aliaj programoj estas ŝarĝitaj en la simulilo sen aldonaj agoj.
Agado de simulilo
Kiel estis menciita ĵus supre, la procezo de simulado de la tuta sistemo, tio estas, ĉiuj ĝiaj aparatoj, estas sufiĉe malrapida entrepreno. Se vi ankaŭ efektivigas ĉion ĉi je tre detala nivelo, ekzemple, mikroarkitektura aŭ logika, tiam ekzekuto fariĝos ekstreme malrapida. Sed la instruknivelo estas taŭga elekto kaj permesas al la OS kaj programoj ekzekuti kun rapideco sufiĉa por la uzanto komforte interagi kun ili.
Ĉi tie taŭgus tuŝi la temon de simulila agado. Ĝi estas kutime mezurita en IPS (instrukcioj por sekundo), pli precize en MIPS (milionoj IPS), tio estas, la nombro da procesoraj instrukcioj ekzekutitaj de la simulilo en unu sekundo. Samtempe, la rapideco de la simulado ankaŭ dependas de la agado de la sistemo, sur kiu la simulado mem funkcias. Tial, eble pli ĝuste paroli pri la "malrapidiĝo" de la simulilo kompare kun la originala sistemo.
La plej oftaj plenplatformaj simuliloj sur la merkato, kiel QEMU, VirtualBox aŭ VmWare Workstation, havas bonan rendimenton. Eble eĉ ne rimarkeblas al la uzanto, ke laboro okazas en la simulilo. Ĉi tio okazas danke al la specialaj virtualaj kapabloj efektivigitaj en procesoroj, binaraj tradukaj algoritmoj kaj aliaj interesaj aferoj. Ĉio ĉi estas temo por aparta artikolo, sed mallonge, virtualigo estas aparatara trajto de modernaj procesoroj, kiu permesas al simuliloj ne simuli instrukciojn, sed sendi ilin por ekzekuto rekte al vera procesoro, se, kompreneble, la arkitekturoj de la simulilo kaj la procesoro estas similaj. Binara tradukado estas la traduko de gastmaŝino kodo en gastigan kodon kaj posta ekzekuto sur reala procesoro. Kiel rezulto, la simulado estas nur iomete pli malrapida, 5-10 fojojn, kaj ofte eĉ funkcias kun la sama rapideco kiel la reala sistemo. Kvankam ĉi tio estas influita de multaj faktoroj. Ekzemple, se ni volas simuli sistemon kun pluraj dekduoj da procesoroj, tiam la rapideco tuj falos je ĉi tiuj kelkdek fojojn. Aliflanke, simuliloj kiel Simics en la plej novaj versioj subtenas multprocesoran gastigan aparataron kaj efike paraleligas la simulitajn kernojn al la kernoj de reala procesoro.
Se ni parolas pri la rapideco de mikroarkitektura simulado, tiam ĝi estas kutime pluraj grandordoj, proksimume 1000-10000 fojojn pli malrapida ol ekzekuto sur regula komputilo, sen simulado. Kaj efektivigoj je la nivelo de logikaj elementoj estas pli malrapidaj je pluraj grandordoj. Tial, FPGA estas uzata kiel emulilo sur ĉi tiu nivelo, kiu povas signife pliigi rendimenton.
La grafikaĵo malsupre montras proksimuman dependecon de simuladrapideco de modeldetalo.
Takto-post-takto simulado
Malgraŭ ilia malalta ekzekutrapideco, mikroarkitekturaj simuliloj estas sufiĉe oftaj. Simulado de la internaj blokoj de la procesoro estas necesa por precize simuli la ekzekuttempon de ĉiu instrukcio. Ĉi tie povas ekesti miskompreno - finfine, ŝajnas, kial ne simple programi la ekzekuttempon por ĉiu instrukcio. Sed tia simulilo estos tre malpreciza, ĉar la ekzekuttempo de la sama instrukcio povas diferenci de voko al voko.
La plej simpla ekzemplo estas memoralira instrukcio. Se la petita memorloko disponeblas en la kaŝmemoro, tiam la ekzekuttempo estos minimuma. Se ĉi tiu informo ne estas en la kaŝmemoro ("cache miss"), tiam tio multe pliigos la ekzekuttempon de la instrukcio. Tiel, kaŝmemormodelo estas postulata por preciza simulado. Tamen, la afero ne estas limigita al la kaŝmemormodelo. La procesoro ne simple atendos datumojn por esti prenitaj el memoro kiam ĝi ne estas en la kaŝmemoro. Anstataŭe, ĝi komencos ekzekuti la sekvajn instrukciojn, elektante tiujn, kiuj ne dependas de la rezulto de legado el memoro. Ĉi tio estas la tiel nomata "senorda" ekzekuto (OOO, eksterorda ekzekuto), necesa por minimumigi la senfunkcian tempon de procesoro. Modeligi la respondajn procesorajn blokojn helpos konsideri ĉion ĉi dum kalkulado de la ekzekuttempo de instrukcioj. Inter ĉi tiuj instrukcioj, efektivigitaj dum la rezulto de legado el memoro estas atendata, povas okazi kondiĉa saltoperacio. Se la rezulto de la kondiĉo estas nekonata nuntempe, tiam denove la procesoro ne ĉesas ekzekuton, sed faras "konjekton", plenumas la taŭgan branĉon kaj daŭre proaktive plenumas instrukciojn de la punkto de transiro. Tia bloko, nomita branĉprognozilo, ankaŭ devas esti efektivigita en la mikroarkitektura simulilo.
La suba bildo montras la ĉefajn blokojn de la procesoro, ne necesas koni ĝin, ĝi montriĝas nur por montri la kompleksecon de la mikroarkitektura efektivigo.
La funkciado de ĉiuj ĉi tiuj blokoj en reala procesoro estas sinkronigita per specialaj horloĝaj signaloj, kaj same okazas en la modelo. Tia mikroarkitektura simulilo estas nomita ciklo preciza. Ĝia ĉefa celo estas precize antaŭdiri la agadon de la evoluiga procesoro kaj/aŭ kalkuli la ekzekuttempon de specifa programo, ekzemple, komparnormo. Se la valoroj estas pli malaltaj ol postulataj, tiam necesos modifi la algoritmojn kaj procesorajn blokojn aŭ optimumigi la programon.
Kiel montrite supre, horloĝ-post-horloĝa simulado estas tre malrapida, do ĝi estas uzata nur kiam oni studas iujn momentojn de funkciado de programo, kie necesas ekscii la realan rapidon de la ekzekuto de la programo kaj taksi la estontan agadon de la aparato, kies funkcio estas. prototipo estas simulata.
En ĉi tiu kazo, funkcia simulilo estas uzata por simuli la restantan rultempon de la programo. Kiel ĉi tiu kombinaĵo de uzo okazas en realeco? Unue, la funkcia simulilo estas lanĉita, sur kiu estas ŝarĝitaj la OS kaj ĉio necesa por ruli la studatan programon. Post ĉio, ni ne interesiĝas pri la OS mem, nek pri la komencaj etapoj de lanĉo de la programo, ĝia agordo ktp. Tamen ni ankaŭ ne povas preterlasi ĉi tiujn partojn kaj tuj pluiri al ekzekuti la programon de la mezo. Tial, ĉiuj ĉi tiuj preparaj paŝoj estas rulitaj sur funkcia simulilo. Post kiam la programo estis ekzekutita ĝis la momento de intereso por ni, du opcioj estas eblaj. Vi povas anstataŭigi la modelon per horloĝa modelo kaj daŭrigi la ekzekuton. La simuladreĝimo kiu uzas plenumeblan kodon (tio estas, regulaj kompilitaj programdosieroj) estas nomita ekzekutmovita simulado. Ĉi tiu estas la plej ofta simulada opcio. Alia aliro ankaŭ estas ebla - spurmovita simulado.
Spur-bazita simulado
Ĝi konsistas el du paŝoj. Uzante funkcian simulilon aŭ sur reala sistemo, protokolo de programaj agoj estas kolektita kaj skribita al dosiero. Ĉi tiu protokolo nomiĝas spuro. Depende de kio estas ekzamenita, la spuro povas inkluzivi ruleblajn instrukciojn, memoradresojn, havennumerojn kaj interrompinformojn.
La sekva paŝo estas "ludi" la spuron, kiam la horloĝ-post-horloĝa simulilo legas la spuron kaj plenumas ĉiujn instrukciojn skribitajn en ĝi. Al la fino, ni ricevas la ekzekuttempon de ĉi tiu peco de la programo, same kiel diversajn karakterizaĵojn de ĉi tiu procezo, ekzemple, la procento de sukcesoj en la kaŝmemoro.
Grava trajto de labori kun spuroj estas determinismo, tio estas, rulante la simuladon en la maniero priskribita supre, denove kaj denove ni reproduktas la saman sekvencon de agoj. Ĉi tio ebligas, ŝanĝante modelajn parametrojn (kaŝmemoro, bufro kaj vostograndecoj) kaj uzante malsamajn internajn algoritmojn aŭ agordante ilin, studi kiel aparta parametro influas sisteman rendimenton kaj kiu opcio donas la plej bonajn rezultojn. Ĉio ĉi povas esti farita per prototipa aparato modelo antaŭ kreado de reala aparataro prototipo.
La komplekseco de ĉi tiu aliro kuŝas en la bezono unue ruli la aplikaĵon kaj kolekti la spuron, same kiel la grandegan grandecon de la spurdosiero. La avantaĝoj inkluzivas la fakton, ke sufiĉas simuli nur la parton de la aparato aŭ platformo de intereso, dum simulado per ekzekuto kutime postulas kompletan modelon.
Do, en ĉi tiu artikolo ni rigardis la funkciojn de plenplatforma simulado, parolis pri la rapideco de efektivigoj je malsamaj niveloj, horloĝ-post-cikla simulado kaj spuroj. En la sekva artikolo mi priskribos la ĉefajn scenarojn por uzi simulilojn, kaj por personaj celoj kaj el evolua vidpunkto en grandaj kompanioj.
fonto: www.habr.com