Реализация программного комплекса, моделирующего вычислительные комплексы с архитектурой sparc v9

Реализация программного комплекса, моделирующего вычислительные комплексы

с архитектурой SPARC V9

Мешков А.Н.

ОАО “ИНЭУМ”

Аннотация. В докладе рассматривается разрабатываемый применительно к архитектуре SPARC моделирующий комплекс. Его ключевыми особенностями являются как способность моделировать весь вычислительный комплекс, включая полный спектр периферийных устройств, так и широкие отладочные возможности. Обосновывается выбор объектно-ориентированного подхода к разработке и рассматриваются примеры оригинальных решений, а также сферы применения данного программного комплекса.

1. Введение.

Одним из основных методов исследования производительности различных компьютерных архитектур является их моделирование. Большинство средств моделирования можно охарактеризовать как симуляторы пользовательского уровня — они позволяют моделировать поведение пользовательских процессов, эмулируя системные вызовы исполняемые на целевой (моделируемой) системе средствами той системы, на которой запущен симулятор. В то же время, симуляторы вычислительного комплекса [1,2] практически полностью моделируют целевой компьютер со стадии загрузки, то есть позволяют исполнять системные приложения, такие как программа начальной загрузки и операционная система, как, впрочем, и пользовательские приложения, запущенные после загрузки операционной системы. Поскольку операционная система скрывает большинство подробностей архитектуры компьютерной системы, задача разработки симулятора машины является весьма сложной. С другой стороны, симулятор машины может использоваться для таких целей как анализ поведения задач, основанный на изменении поведения системы (например, сбор статистики по событиям, недоступный на реальной аппаратуре), возможность исполнения программного обеспечения в период, когда аппаратура еще не реализована, разработка и отладка операционных систем и системного программного обеспечения, анализ особенностей различных архитектурных решений и их вклада в изменение производительности системы.

2. Объектно-ориентированный подход к разработке моделирующего комплекса.

В реализации программной модели был широко использован объектно-ориентированный подход. Несмотря на его достоинства, это решение не является общепринятым при разработке симуляторов [1, 2]. Основной причиной авторы называют проигрыш в скорости моделирования по сравнению с программами, написанными с использованием процедурного программирования. Тем не менее, модульный подход очень удобен при проектировании симуляторов вычислительного комплекса, поскольку отдельные компоненты и устройства системы логично рассматривать как классы.

На рис 1 изображена упрощенная схема симулятора в объектном представлении. Верхним модулем является класс Simulator, отвечающий за разбор ресурсов и предоставление возможности трассировки всем дочерним классам. В зависимости от настроек конфигурации, может создаваться от 1 до 4 процессорных модулей, соответствующих «системе на кристалле». Каждый такой модуль содержит 4 процессорных ядра с архитектурой SPARC V9 [3], собственную физическую память и может иметь связь с южным мостом. Таким образом, в зависимости от конфигурации, возможно моделирование работы вычислительного комплекса с 16 процессорными ядрами. Каждое ядро также имеет модульную архитектуру, где в качестве блоков выступают основные устройства процессора — регистровый файл, устройство управления памятью (MMU), устройство работы операций с плавающей запятой (FPU), декодер и т.д. Устройства процессора также могут содержать собственные блоки там, где это необходимо. С функциональной точки зрения, процессорное ядро производит основной цикл выполнения, включающий такие действия как загрузка инструкции, декодирование, чтение операндов, исполнения и т.д. Далее рассмотрены некоторые из особенностей их реализации в модели.

Рис 1. Упрощенная схема моделирующего комплекса архитектуры SPARC V9

3. Декодирование инструкций.

Декодирование инструкций в системе команд SPARC V9 – это преобразование 32-битной инструкции в тип операции, непосредственные операнды или номера регистров, содержащих операнды, и результат. Декодирование является достаточно трудоемкой задачей, вместе с тем оно должно быть быстрым и точным. Традиционно декодеры производят разбор вплоть до кода операции (более 300) [2, 4], попутно заполняя структуры, хранящие значения операндов. Это приводит к появлению большого количества таблиц переходов и, как следствие, чрезмерному разрастанию декодера, снижению читабельности кода и понижению скорости. Вместо этого, в нашем симуляторе реализован упрощенный предекодер. Команда разбирается только до определения группы операций — совокупности схожих по исполнению инструкций. Такое разбиение определено на уровне системы команд, в описании инструкций они уже разделены на группы. Это позволяет существенно упростить декодер (групп операций насчитывается всего ~60) и отложить дальнейший разбор до момента исполнения.

4. Выполнение инструкций.

После декодирования, номер группы операции используется как индекс в таблице функций, осуществляющих исполнение инструкций. Каждая из функций соответствует определенной группе инструкций (например команды перехода с различными условиями или всевозможные варианты операций сдвига) и в ней происходит окончательное декодирование и исполнение операции. Такой способ организации позволяет заменить несколько сотен функций, многие из которых практически идентичны, несколькими десятками. При этом, в силу однородности операций в группе, различаются только действия над операндами, в то время как сами операнды декодируются едино для всей группы, то есть значительно упрощается и структурируется исходный код.

5. Обработка прерываний.

Подсистема прерываний является одной из важнейших в процессоре. Система команд SPARC V9 имеет сравнительно сложную архитектуру, поддерживающую 5 уровней прерываний. В то же время, поведение системы несильно отличается от уровня к уровню (исключением является лишь последний отладочный уровень) [3]. Это, а также необходимость реализации только двух типов прерываний (точных и асинхронных, отложенные прерывания в реализации процессора не предусмотрены), позволяет создать достаточно компактный модуль обработки прерываний. Точные прерывания (исключения) обнаруживаются в момент выполнения инструкции и срабатывают в порядке приоритета. Обработка точных прерываний реализована с помощью класса exception стандартной библиотеки. Такой подход позволяет значительно упростить читабельность кода по сравнению с традиционным методом реализации через setjmp/longjmp [2,4] и избавиться от возможной потери производительности, связанной с использованием longjmp. Единственное требование — проверка точных прерываний должна производится в порядке их приоритетов. Однако, оно не является трудновыполнимым, так как приоритеты соответствуют степени обработки инструкции, то есть с продвижением инструкции по конвейеру они понижаются.

6. Отладочные возможности.

Перечислим основные возможности разрабатываемого моделирующего комплекса. В первую очередь, это возможности максимально подробной трассировки. К ним относятся: трассировка состояния симулятора, отображение декодированного кода и выполняемых в соответствии с ним действий, трассировка прерываний и исключений, трассировка изменения состояний регистров и памяти по заданному физическому адресу, печать общей информации о выполнении при выходе из программы. Также имеется возможность использовать дополнительные возможности трассировки: выборочная трассировка в заданном диапазоне адресов исполняемого кода или тактов.

Имеется возможность отладки любого из узлов симулятора благодаря трассировки каждого из устройств по отдельности. При этом возможна трассировка как отдельных узлов микропроцессора, таких как: устройство управления памятью (MMU), устройство трансляции адресов (TLB), кэши данных и команд 1-го уровня, кэш 2-го уровня и т.д., так и периферийных устройств.

Еще одним полезным инструментом отладки симулятора и приложений является поддержка работы с контрольными точками. Контрольная точка представляет собой точный «слепок» системы на момент ее съема. Таким образом, контрольная точка содержит состояния всех регистров процессора и периферийных устройств, содержимое всех занятых областей памяти и значения любых переменных, оказывающих влияние на поведение системы. Главное достоинство заключается в том, что имея готовую, заранее полученную контрольную точку, можно в любой момент продолжить выполнение прерванной задачи с того момента в который она была снята. Это значительно ускоряет анализ и исправление различного рода ошибок, возникших после длительного времени работы симулятора.

7. Применение.

Разработанный симулятор был задействован во множестве задач. Во-первых, это разработка и отладка направленных архитектурных тестов, проверяющих соответствие реализации процессора системе команд. При этом тесты и симулятор разрабатывались независимо, что позволило провести начальную отладку симулятора на тестовом пакете. К моменту написания статьи тестовый пакет насчитывал более 1200 направленных тестов, успешно выполняющихся на симуляторе. Во-вторых, это разработка генератора случайных тестов, предназначенного для повышения полноты тестирования и покрытия. В-третьих, это разработка программы начальной загрузки (boot), выполняющейся с момента старта вычислительного комплекса до передачи управления операционной системе. Одной из задач загрузчика является начальное тестирование и настройка аппаратуры и, как следствие, для корректной работы загрузчика на симуляторе требуется очень точное соответствие моделируемого железа реальному. Наконец, в-четвертых, это портирование операционной системы (linux) для работы на данной архитектуре. Загрузка операционной системы, как ничто другое, требует особой точности и корректности моделирования не только всех архитектурных особенностей, но и поддержки множества периферийных устройств.

8. Заключение.

Рассмотренный в статье программный моделирующий комплекс разработан для реализации функциональности ВК МЦСТ 4R с системой команд SPARC V9. Создание такого программного комплекса является трудоемкой задачей из-за сложности архитектуры и необходимости поддержки большого числа устройств. Однако, применение объектно-ориентированного подхода и описанных в статье решений позволило снизить трудозатраты на разработку самого симулятора и ускорить его работу. Необходимость моделирования новых аппаратных решений, примененных в вычислительном комплексе собственной разработки, обосновано как с точки зрения разработки программного обеспечения, так и с точки зрения отладки аппаратуры. Отладочные возможности, предоставляемые симулятором, позволяют упростить и ускорить осуществление вышеперечисленных задач. Следствием является снижение сроков разработки и повышение конечного качества как программного, так и аппаратного обеспечения.

Список литературы.

[1] Magnusson, P. S., Dahlgren, F., Grahn, H., Karlsson, M., Larsson, F., Lundholm, F., Moestedt, A., Nilsson, J., Stenstrvm, P., Werner, B. (1998), SimICS/sun4m: A Virtual Workstation, in `Usenix Annual Technical Conference'.

[2] Rosenblum, M., Herrod, S. A., Witchel, E., Gupta, A. (1995), Complete Computer System Simulation: The SimOS Approach, IEEE Parallel and Distributed Technology .

[3] Weaver, D., Germond, T., (1994), The SPARC Architecture Manual, Version 9, SPARC International, Inc.

[4] Zadarnowski, P. (2000), The design and implementation of an extendible instruction-set simulator, BE thesis, School of Computer Science and Engineering, University of New South Wales, Australia.