Симулатори на компютърни системи: познатият симулатор на пълна платформа и неизвестните лента и следа

Във втората част на статията за симулаторите на компютърни системи ще продължа да говоря в проста уводна форма за компютърните симулатори, а именно за симулацията на пълна платформа, която средният потребител най-често среща, както и за часовника -часов модел и следи, които са по-често срещани в кръговете на разработчиците.

В първата част Говорих за това какво представляват симулаторите като цяло, както и за нивата на симулация. Сега, въз основа на това знание, предлагам да се гмурнем малко по-дълбоко и да говорим за симулация на пълна платформа, как да събираме следи, какво да правим с тях по-късно, както и за микроархитектурна емулация часовник по часовник.

Симулатор на пълна платформа или „Сам в полето не е войн“

Ако искате да проучите работата на едно конкретно устройство, например мрежова карта, или да напишете фърмуер или драйвер за това устройство, тогава такова устройство може да бъде симулирано отделно. Използването му изолирано от останалата инфраструктура обаче не е много удобно. За да стартирате съответния драйвер, ще ви трябва централен процесор, памет, достъп до шина за данни и др. Освен това драйверът изисква операционна система (ОС) и мрежов стек, за да функционира. Освен това може да са необходими отделен генератор на пакети и сървър за отговор.

Симулаторът на пълна платформа създава среда за изпълнение на пълен софтуерен стек, който включва всичко от BIOS и буутлоудъра до самата операционна система и нейните различни подсистеми, като един и същ мрежов стек, драйвери и приложения на потребителско ниво. За да направи това, той внедрява софтуерни модели на повечето компютърни устройства: процесор и памет, диск, входно-изходни устройства (клавиатура, мишка, дисплей), както и същата мрежова карта.

По-долу е блокова диаграма на чипсета x58 от Intel. Компютърен симулатор с пълна платформа на този чипсет изисква внедряването на повечето от изброените устройства, включително тези в IOH (Input/Output Hub) и ICH (Input/Output Controller Hub), които не са изобразени подробно на блоковата диаграма . Въпреки че, както показва практиката, няма много устройства, които не се използват от софтуера, който ще изпълняваме. Не е необходимо да се създават модели на такива устройства.

Най-често симулаторите на пълна платформа се изпълняват на ниво инструкции на процесора (ISA, вижте по-долу). предишна статия). Това ви позволява да създадете самия симулатор относително бързо и евтино. Нивото ISA също е добро, защото остава повече или по-малко постоянно, за разлика например от нивото API/ABI, което се променя по-често. В допълнение, изпълнението на ниво инструкция ви позволява да стартирате така наречения немодифициран двоичен софтуер, тоест да стартирате вече компилиран код без никакви промени, точно както се използва на реален хардуер. С други думи, можете да направите копие („изхвърляне“) на вашия твърд диск, да го посочите като изображение за модел в симулатор на пълна платформа и готово! – ОС и другите програми се зареждат в симулатора без допълнителни действия.

Изпълнение на симулатора

Както беше споменато по-горе, процесът на симулиране на цялата система, т.е. на всички нейни устройства, е доста бавен процес. Ако приложите всичко това на много подробно ниво, например микроархитектурно или логическо, тогава изпълнението ще стане изключително бавно. Но нивото на инструкции е подходящ избор и позволява на операционната система и програмите да се изпълняват със скорости, достатъчни за удобното взаимодействие на потребителя с тях.

Тук би било уместно да засегнем темата за производителността на симулатора. Обикновено се измерва в IPS (инструкции за секунда), по-точно в MIPS (милиони IPS), тоест броят инструкции на процесора, изпълнени от симулатора за една секунда. В същото време скоростта на симулацията зависи и от производителността на системата, върху която работи самата симулация. Следователно може да е по-правилно да се говори за „забавяне“ на симулатора в сравнение с оригиналната система.

Най-разпространените симулатори на пълна платформа на пазара, като QEMU, VirtualBox или VmWare Workstation, имат добра производителност. Може дори да не се забележи за потребителя, че в симулатора се извършва работа. Това се случва благодарение на специалните възможности за виртуализация, внедрени в процесорите, алгоритмите за бинарна транслация и други интересни неща. Всичко това е тема за отделна статия, но накратко, виртуализацията е хардуерна функция на съвременните процесори, която позволява на симулаторите да не симулират инструкции, а да ги изпращат за изпълнение директно към реален процесор, ако, разбира се, архитектурите на симулаторът и процесорът са подобни. Двоичната транслация е транслация на гост машинен код в хост код и последващо изпълнение на реален процесор. В резултат на това симулацията е само малко по-бавна, 5-10 пъти, и често дори работи със същата скорост като реалната система. Въпреки че това се влияе от много фактори. Например, ако искаме да симулираме система с няколко десетки процесори, тогава скоростта веднага ще падне с тези няколко десетки пъти. От друга страна, симулатори като Simics в най-новите версии поддържат многопроцесорен хост хардуер и ефективно паралелизират симулираните ядра върху ядрата на реален процесор.

Ако говорим за скоростта на микроархитектурната симулация, тогава тя обикновено е няколко порядъка, около 1000-10000 пъти по-бавна от изпълнението на обикновен компютър, без симулация. И имплементациите на ниво логически елементи са по-бавни с няколко порядъка. Следователно FPGA се използва като емулатор на това ниво, което може значително да увеличи производителността.

Графиката по-долу показва приблизителна зависимост на скоростта на симулацията от детайлите на модела.

Симулация на такт по такт

Въпреки ниската им скорост на изпълнение, микроархитектурните симулатори са доста разпространени. Симулацията на вътрешните блокове на процесора е необходима, за да се симулира точно времето за изпълнение на всяка инструкция. Тук може да възникне недоразумение - в крайна сметка, изглежда, защо просто не програмирате времето за изпълнение за всяка инструкция. Но такъв симулатор ще бъде много неточен, тъй като времето за изпълнение на една и съща инструкция може да се различава от повикване до повикване.

Най-простият пример е инструкция за достъп до паметта. Ако исканото място в паметта е налично в кеша, тогава времето за изпълнение ще бъде минимално. Ако тази информация не е в кеша ("кеш пропуск"), тогава това значително ще увеличи времето за изпълнение на инструкцията. По този начин е необходим кеш модел за точна симулация. Въпросът обаче не се ограничава до модела на кеша. Процесорът няма просто да чака данните да бъдат извлечени от паметта, когато те не са в кеша. Вместо това, той ще започне да изпълнява следващите инструкции, избирайки тези, които не зависят от резултата от четене от паметта. Това е така нареченото изпълнение „извън ред“ (ООО, изпълнение извън ред), необходимо за минимизиране на времето на престой на процесора. Моделирането на съответните процесорни блокове ще помогне да се вземе предвид всичко това при изчисляване на времето за изпълнение на инструкциите. Сред тези инструкции, изпълнени докато се чака резултатът от четене от паметта, може да възникне операция за условен преход. Ако резултатът от условието е неизвестен в момента, тогава отново процесорът не спира изпълнението, а прави „предположение“, извършва съответното разклоняване и продължава проактивно да изпълнява инструкции от точката на прехода. Такъв блок, наречен предиктор на разклонения, също трябва да бъде внедрен в микроархитектурния симулатор.

Картината по-долу показва основните блокове на процесора, не е необходимо да го познавате, показана е само за да покаже сложността на микроархитектурната реализация.

Работата на всички тези блокове в реалния процесор се синхронизира със специални тактови сигнали, като същото се случва и в модела. Такъв микроархитектурен симулатор се нарича циклично точен. Основната му цел е да предскаже точно производителността на разработвания процесор и/или да изчисли времето за изпълнение на конкретна програма, например бенчмарк. Ако стойностите са по-ниски от изискваните, тогава ще е необходимо да се модифицират алгоритмите и процесорните блокове или да се оптимизира програмата.

Както е показано по-горе, симулацията часовник по часовник е много бавна, така че се използва само при изучаване на определени моменти от работата на програмата, където е необходимо да се установи реалната скорост на изпълнение на програмата и да се оцени бъдещата производителност на устройството, чието прототипът се симулира.

В този случай се използва функционален симулатор за симулиране на оставащото време за изпълнение на програмата. Как се случва в действителност тази комбинация от употреба? Първо се стартира функционалният симулатор, на който се зарежда операционната система и всичко необходимо за изпълнение на изследваната програма. В крайна сметка не се интересуваме от самата операционна система, нито от началните етапи на стартиране на програмата, нейната конфигурация и т.н. Въпреки това, ние също не можем да пропуснем тези части и веднага да преминем към изпълнение на програмата от средата. Следователно всички тези предварителни стъпки се изпълняват на функционален симулатор. След като програмата е изпълнена до момента, който ни интересува, са възможни два варианта. Можете да замените модела с модел часовник по цикъл и да продължите изпълнението. Режимът на симулация, който използва изпълним код (т.е. редовно компилирани програмни файлове), се нарича симулация, управлявана от изпълнение. Това е най-често срещаният вариант за симулация. Възможен е и друг подход - симулация, управлявана от следи.

Симулация, базирана на следи

Състои се от две стъпки. С помощта на функционален симулатор или на реална система се събира регистър на действията на програмата и се записва във файл. Този дневник се нарича следа. В зависимост от това какво се изследва, проследяването може да включва изпълними инструкции, адреси на паметта, номера на портове и информация за прекъсване.

Следващата стъпка е да се „пусне“ проследяването, когато симулаторът часовник по часовник чете проследяването и изпълнява всички инструкции, записани в него. В крайна сметка получаваме времето за изпълнение на тази част от програмата, както и различни характеристики на този процес, например процентът на посещенията в кеша.

Важна характеристика на работата със следи е детерминизмът, тоест, изпълнявайки симулацията по описания по-горе начин, отново и отново възпроизвеждаме една и съща последователност от действия. Това прави възможно, чрез промяна на параметрите на модела (кеш, буфер и размери на опашка) и използване на различни вътрешни алгоритми или настройката им, да се изследва как конкретен параметър влияе върху производителността на системата и коя опция дава най-добри резултати. Всичко това може да се направи с прототип на модел на устройство, преди да се създаде действителен хардуерен прототип.

Сложността на този подход се крие в необходимостта първо да стартирате приложението и да съберете проследяването, както и в огромния размер на файла за проследяване. Предимствата включват факта, че е достатъчно да се симулира само частта от устройството или платформата, която представлява интерес, докато симулацията чрез изпълнение обикновено изисква пълен модел.

И така, в тази статия разгледахме характеристиките на симулацията на пълна платформа, говорихме за скоростта на внедрявания на различни нива, симулация часовник по цикъл и следи. В следващата статия ще опиша основните сценарии за използване на симулатори, както за лични цели, така и от гледна точка на развитие в големи компании.

Източник: www.habr.com