Разработка метода автоматизации конструирования генераторов тестовых программ для микропроцессоров
Функциональная верификация микропроцессоров. Анализаторы формальных спецификаций. Генераторы кода и библиотеки моделирования. Техники генерации тестовых программ. Спецификации архитектуры, язык описания шаблонов. Размещение команд и данных в памяти.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | диссертация |
| Язык | русский |
| Дата добавления | 11.06.2018 |
| Размер файла | 2,7 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
|
#1 |
|
Рисунок 8. Вариант комбинации, возвращаемой комбинатором random
Пермутаторы
Пермутатор - это компонент, модифицирующий комбинации, возвращаемые комбинатором путем перестановки некоторых последовательностей. Он принимает на выход итератор комбинаций последовательностей и отдает на выход итератор модифицированных комбинаций последовательностей. Поддерживаются следующие пермутаторы (возможные значения permutator-name): (1) trivial (используется по умолчанию); (2) random.
Пермутатор trivial оставляет каждую комбинацию без изменений. Т.е. пара из комбинатора product и пермутатора trivial возвратит в точности такие же комбинации, что и просто комбинатор product.
Пермутатор random меняет порядок последовательностей в комбинации случайным образом. На рисунке 9 показаны комбинации, которые может возвратить пара из комбинатора product и пермутатора random.
|
#1 |
#2 |
#3 |
#4 |
#5 |
#6 |
|
Рисунок 9. Комбинации, возвращаемой комбинатором product и пермутатором random
Композиторы
Композитор - это компонент, объединяющий (мультиплексирующий) последовательности, входящие в комбинацию, в одну последовательность (с сохранением порядка инструкций внутри каждой последовательности). Он принимает на вход комбинацию последовательностей и выдает на выход объединенную последовательность. Поддерживаются следующие композиторы (возможные значения compositor-name): (1) catenation (используется по умолчанию); (2) rotation; (3) random.
Композитор catenation объединяет последовательности, располагая их одна за другой.
Композитор rotation объединяет последовательности, используя круговую дисциплину (round robin): в результирующую последовательность по кругу, начиная с первой последовательности, добавляется очередная инструкция очередной последовательности. Если последовательность себя исчерпала, она исключается из рассмотрения. На рисунке 10 показан результат работы композитора rotation.
Рисунок 10. Результат работы композитора rotation
Композитор random объединяет последовательности случайным образом (но с сохранением порядка инструкций внутри каждой последовательности). На рисунке 11 показан результат работы композитора random.
Рисунок 11. Результат работы композитора random
Перегруппировщики
Перегруппировщик - это компонент, перегруппирующий последовательности, построенные композитором. Он принимает на вход набор последовательностей и отдает на выход модифицированный набор последовательностей. Поддерживаются следующие перегруппировщики (возможные значения rearranger-name): (1) trivial (используется по умолчанию); (2) expand.
Перегруппировщик trivial оставляет набор последовательностей без изменений.
Перегруппировщик expand объединяет набор последовательностей в одну единственную последовательность путем их конкатенации. На рисунке 12 показан результат работы перегруппировщика expand.
|
(1) |
|||
Рисунок 12. Результат работы перегруппировщика expand
Обфускаторы
Обфускатор - это компонент, модифицирующий последовательности, возвращаемые перегруппировщиком (путем перестановки некоторых инструкций). Он принимает на вход последовательность и отдает на выход модифицированную последовательность. Поддерживаются следующие обфускаторы (возможные значения obfuscator-name): (1) trivial (используется по умолчанию); (2) random.
Обфускатор trivial оставляет последовательность без изменений.
Обфускатор random меняет порядок инструкций в последовательности случайным образом. Результат его работы показан на рисунке 13.
Рисунок 13. Результат работы обфускатора random
В настоящее время на использование блоков в шаблонах тестовых программ накладываются следующие ограничения: (1) блоки sequence и atomic не содержат вложенных блоков; (2) блоки sequence и atomic поддерживают только параметр obfuscator; (3) блоки iterate поддерживают только параметры rearranger и obfuscator.
|
Комбинатор diagonal |
Пермутатор random |
Композитор catenation |
Перегруппировщик trivial |
Обфускатор trivial |
|
|
Инициализируются итераторы последовательностей вложенных блоков A, B и С. Составляется комбинация из очередных последовательностей блоков A(1), B(1) и C(1). |
Строится случайная перестановка последова-тельностей |
Последова-тельности комбинации конкатенируются |
Набор последовательностей не изменяется |
Последова-тельность не изменяется |
|
|
Итератор блока C исчерпан; он переинициализируется. Составляется комбинация из очередных последовательностей блоков A(2), B(2) и C(1). |
Строится случайная перестановка последова-тельностей |
Последова-тельности комбинации конкатенируются |
Набор последовательностей не изменяется |
Последова-тельность не изменяется |
|
|
Итераторы блоков B и C исчерпаны; они переинициализируются. Составляется комбинация из очередных последовательностей блоков A(3), B(1) и C(1). |
Строится случайная перестановка последова-тельностей |
Последова-тельности комбинации конкатенируются |
Набор последовательностей не изменяется |
Последова-тельность не изменяется |
Рисунок 14. Пример построения последовательности
Таким образом, применяя различные типы блоков, использующие различные стратегии построения последовательностей, возможно описывать сложные тестовые примеры путем комбинирования уже имеющихся описаний. Рисунок 14 иллюстрирует построение последовательностей инструкций для следующих значений параметров: (1) комбинатор - diagonal; (2) пермутатор - random; (3) композитор - catenation; (4) перегруппировщик - trivial; (5) обфускатор - trivial.
2.3.4 Обработчик последовательностей команд
В построенных абстрактных последовательностях могут быть не определены используемые регистры и входные данные для команд. Задача обработчика последовательностей команд (sequence processor) - фиксация всех не определенных в тестовых шаблонах параметров для достижения заданных поведенческих свойств. Обработка последовательностей включает в себя следующие стадии:
1. выбор регистров, используемых командами;
2. построение ограничений для тестовых ситуаций, связанных с командами;
3. генерация входных данных для команд путем разрешения ограничений;
4. построение кода, помещающего данные в регистры и память.
Выбор регистров
Если номер используемого командой регистра не задан жестко, то он помечается как неизвестный. Неизвестные номера регистров снабжаются набором атрибутов, задающих способ их выбора. Выбор номеров регистров осуществляется при помощи компонентов ядра, называемых стратегиями выбора регистров. Общая схема выбора регистров выглядит следующим образом. Просматриваются все команды и составляется множество используемых известных регистров. Оно используется некоторыми стратегиями выбора регистров. После этого все команды просматриваются заново и для каждого неизвестного регистра осуществляется выбор номера при помощи стратегии, которая выбирается в соответствии с заданными атрибутами. При выборе номера регистра множество используемых известных регистров обновляется. Кроме этого обновление множества происходит, если при просмотре последовательности команд встречаются служебные инструкции генератора, влияющие на выбор регистров (резервация номеров регистров, сброс зарезервированных регистров и т.д.).
Построение ограничений
Входные данные для команд генерируются в соответствии с тестовыми ситуациями, заданными для них в шаблоне. Условия достижения тестовых ситуаций задаются при помощи ограничений различного вида. При этом тестовые ситуации для отдельных команд могут быть заданы как множество ситуаций одного класса. Между командами одной последовательности существуют зависимости, связанные с совместным использованием конвейера команд и памяти. Поэтому для достижения максимальной полноты тестирования необходимо обеспечить покрытие всевозможных комбинаций ситуаций, связанных с отдельными командами.
Задача комбинирования тестовых ситуаций может решаться различными способами. Важно понимать, что декартово произведение будет избыточно, а случайная композиция не сможет обеспечить должный уровень покрытия. Поэтому необходимо учитывать природу комбинируемых тестовых ситуаций и использовать для каждого класса ситуаций свои стратегии построения комбинаций. Таким образом, будет использоваться подход, при котором комбинации тестовых ситуаций строятся для команд определенных классов и затем объединяются по заданным правилам в последовательности, описывающие тестовые воздействия. При этом при обработке одной абстрактной последовательности будет порождаться несколько тестовых воздействий, состоящих из тех же команд, но использующих разные комбинации ситуаций и аннотированных различными ограничениями.
Компоненты, отвечающие за комбинирования тестовых ситуаций определенных типов и построение соответствующих ограничений, называются генераторами ограничений. Они выбирают из обрабатываемой абстрактной последовательности интересующие их команды и строят для них комбинации тестовых ситуаций. Способ комбинирования определяется техникой комбинирования, реализованной компонентом, и атрибутами, заданными в шаблоне. Затем для каждой ситуации строится ограничение. В результате на выходе получается множество последовательностей, состоящих из одних и тех же команд, но аннотированными разными ограничениями. В некоторых случаях генераторы ограничений могут при этом вставлять в эти последовательности дополнительные команды для вспомогательных целей.
Последовательности команд, получаемые на выходе разных генераторов ограничений, объединяются в последовательности, описывающие тестовые воздействия. При этом строятся всевозможные их комбинации. Для комбинирования используется один из поддерживаемых ядром комбинатор. Используемый комбинатор задается в шаблоне при помощи соответствующего атрибута блока.
Ограничения, которыми аннотируются команды, берутся из модели покрытия или реализуются ядром.
Генерация данных
Генерация входных данных для команд осуществляется путем разрешения ограничений. Ограничения разрешаются в порядке исполнения команд, чтобы учесть зависимости между ними. Для разрешения ограничений каждого типа используются отдельный компонент, называемый решателем. Для сгенерированных в результате решения ограничения данных строится инициализирующий код, который добавляется в качестве пролога коду тестового воздействия.
Чтобы обеспечить разрешение ограничений в правильном порядке, код тестового воздействия исполняется на эмуляторе. Для этого используется временный контекст эмулятора, который потом сбрасывается. Это делается потому, что к этому моменту размер инициализирующего кода неизвестен и, следовательно, нет возможности разместить код тестового воздействия по правильному адресу. Таким образом, процесс генерации данных выглядит следующим образом:
· запускается исполнение последовательности на эмуляторе;
· перед первым исполнением каждой команды для нее разрешается ограничение;
· для решения ограничения используется информация о текущем состоянии регистров и памяти, предоставляемая эмулятором;
· для сгенерированных в результате решения ограничения данных строится инициализирующий код и исполняется;
· если обрабатываемая команда использует непосредственные аргументы, для которых были сгенерированы значения, то она обновляется в эмуляторе;
· при следующем исполнении команды генерация данных не происходит;
· переходы потока управления за пределы последовательности игнорируются.
В результате получается конкретная последовательность команд с фиксированными значениями операндов и включающая в себя необходимый инициализирующий код. Вопросы построения инициализирующего кода рассмотрены ниже.
Построение инициализирующего кода
Данные, генерируемые в результате решения ограничений различного типа, могут использоваться по-разному. Это могут быть значения регистров, данные, помещаемые в память, адреса, таблицы трансляции адресов и т.д., для которых требуется создавать инициализирующий код различного вида. Поэтому в шаблонах для каждого типа ограничений задается соответствующий препаратор. Препараторы описываются в виде абстрактных последовательностей, в которые подставляются нужные данные и номера регистров. Для каждого препаратора разрабатывается Rubу-модуль, описывающий используемую языковую конструкцию, классы внутреннего представления и фабрика, позволяющая на основе внутреннего представления и входных данных построить инициализирующий код.
2.3.5 Расширяемость генератора тестовых программ
Описанная архитектура генератора тестовых программ допускает расширение его функциональности пользовательскими реализациями компонентов, решающих следующие задачи:
· построение последовательностей команд (комбинаторы, композиторы, перестановщики, перегруппировщики, обфускаторы);
· выбор регистров (стратегии выбора);
· комбинирование тестовых ситуаций и построение ограничений (генераторы ограничений);
· разрешение ограничений определенного типа (решатели ограничений);
· построение инициализирующего кода определенного вида (препараторы).
Компоненты, отвечающие за обработку тестовых ситуаций определенного типа, объединяются в расширения. Для поддержки возможности обработки тестовых ситуаций нового типа, разрабатывается соответствующее расширение и регистрируется в ядре генератора.
Выводы
В данной главе был предложен метод конструирования генераторов тестовых программ для микропроцессоров на основе формальных спецификаций их архитектуры. Метод позволяет создавать расширяемые генераторы тестовых программ для широкого спектра микропроцессорных архитектур. Генерация тестовых программ осуществляется на основе шаблонов, описывающих их структурные и поведенческие свойства в абстрактном виде, разработанных на предметно-ориентированном языке, основанном на Ruby. Архитектура генераторов позволяет использовать различные техники генерации, набор которых может быть расширен пользовательскими реализациями.
Глава 3. Реализация предложенного метода
В данной главе приводится описание реализации метода автоматизации конструирования генераторов тестовых программ, предложенного в предыдущей главе. Метод нашел свое воплощение в инструменте с открытым исходным кодом MicroTESK (Microprocessor TEsting and Specification Kit) версии 2.0 [82], разработанном на языке Java. Инструмент MicroTESK осуществляет конструирование генераторов тестовых программ для микропроцессоров на основе формальных спецификаций их архитектуры. Сконструированные генераторы состоят из архитектурно-независимого ядра, являющего частью инструмента, и модели микропроцессора, конструируемой на основе формальных спецификаций.
Инструмент MicroTESK разделен на две основные части: (1) среду моделирования, которая отвечает за конструирование модели микропроцессора, и (2) среду тестирования, которая отвечает за генерацию тестовых программ и включает в себя реализацию архитектурно-независимого ядра. Структура инструмента MicroTESK изображена на рисунке 15.
Рисунок 15. Архитектура инструмента MicroTESK
В общих словах, сценарий использования инструмента MicroTESK следующий. Пользователь разрабатывает формальные спецификации, описывающие архитектуру тестируемого микропроцессора. Эти спецификации анализируются средой моделирования, которая осуществляет построение модели микропроцессора. Затем пользователь разрабатывает шаблоны тестовых программ, которые задают их свойства в терминах модели микропроцессора и техник генерации, поддерживаемых ядром. После этого среда тестирования осуществляет построение тестовых программ на основе шаблонов и модели микропроцессора.
Подробное описание среды моделирования, среды тестирования, а также их компонентов и механизмов их взаимодействия приводятся в последующих разделах.
3.1 Среда моделирования
Задача среды моделирования состоит в построении модели микропроцессора на основе формальных спецификаций. Модель содержит всю необходимую информацию для генерации тестовых программ для данного микропроцессора. Эта информация извлекается из формальных спецификаций при помощи набора анализаторов, каждый их которых отвечает за получение информации определенного типа. Т.к. архитектура микропроцессора может описываться при помощи формальных спецификаций различного типа, анализаторы объединяются в группы. Для поддержки новых типов спецификаций необходимо реализовать соответствующую группу анализаторов при помощи специальных библиотек, которые значительно упрощают эту задачу. Анализаторам спецификаций соответствуют генераторы кода, которые отвечают за построение отдельных компонентов модели на основе специальных библиотек моделирования. Компоненты модели содержат точки соединения (connection point), которые обеспечивают интеграцию между компонентами различного типа.
3.1.1 Модель микропроцессора
Модель микропроцессора включает в себя три основных части: (1) метаданные, хранящие информацию о командах, регистрах и памяти микропроцессора; (2) эмулятор, позволяющий программно эмулировать исполнение команд и получать информацию о состоянии микропроцессора; (3) модель тестового покрытия, содержащая информацию о возможных путях исполнения команд.
Метаданные
Задача метаданных - предоставить информацию о модели микропроцессора среде генерации, для которой она является «черным ящиком». Эта информация необходима для конфигурирования языка тестовых шаблонов под заданную архитектуру и для выполнения различных запросов к модели. Метаданные описывают следующие сущности:
· регистры и память (имя, количество элементов, тип данных);
· команды и режимы адресации (имя, параметры, атрибуты).
Регистры и память хранят информацию о текущем состоянии микропроцессора. Поэтому их описание необходимо для получения доступа к информации о состоянии микропроцессора.
Команды являются интерфейсом взаимодействия с микропроцессором (и его моделью). По этой причине их описание являются ключевым элементом метаданных. Оно необходимо для печати и исполнения команд, а также для построения тестов, предполагающих выбор команд, удовлетворяющих тем или иным требованиям. Рассмотрим более подробно структуру метаописаний команд.
Спецификации на языке nML описывают команды в виде иерархической структуры операций. При этом отдельные команды представлены путями из узлов, описывающих общие для всех команд свойства, к терминальным узлам, описывающим свойства уникальные для данных команд. Операции могут объединяться в группы для задания отношений «один ко многим». Параметрами операций являются режимы адресации или непосредственные значения (immediate values). Метаданные повторяют эту структуру, т.к. это необходимо для описания вызовов команды, состоящих из нескольких операций (характерно для архитектур семейства VLIW). Однако описание команд в виде путей в графе являются избыточными для более простых семейств архитектур таких, как RISC. В таких архитектурах команды уникально идентифицируется операциями, расположенными в терминальных узлах. Например, в спецификации системы команд MIPS, структура которой показана на рисунке 16, команды ADD описывается путем из операции instruction к операции add (другими словами операция instruction параметризована операцией add), которая входит в группы Op и ALU. При этом операция add уникально идентифицирует команду ADD, а остальные операции, составляющие данную инструкцию, выводятся из контекста. Таким образом, вызов команды ADD можно описывать как вызов операции add. Для этого в метаданные вводится сущность, именуемая как сокращенный вызов (shortcut), которая позволяет в зависимости от контекста описывать вызов команды (или некоторой ее части) как вызов операции, уникально идентифицирующей соответствующий путь в графе операций. Для одной операции может существовать несколько вариантов сокращенно вызова: в зависимости от контекста она может использоваться для обозначения всего пути или его части, заканчивающейся в этой операции.
Рисунок 16. Структура системы команд MIPS и описание команды ADD
Метаданные содержат список операций, режимов адресации и их групп. Группы представляют собой коллекции имен входящих в них элементов. Операции и режимы адресации характеризуются следующими атрибутами: (1) имя, (2) параметры, (3) сокращенные вызовы и (3) свойства.
Параметры описываются следующими атрибутами: (1) имя; (2) тип сущности (операция, режим адресации или непосредственный аргумент); (3) имя сущности (для операций и режимов адресации); (4) тип данных (для режимов адресации и непосредственных аргументов) и (5) тип доступа (чтение, запись).
Сокращенные вызовы характеризуются контекстом, в котором они используются, и списком параметров. Последний может отличаться от списка параметров вызываемой операции, т.к. другие операции на данном пути в графе могут иметь дополнительные параметры, которые необходимо им передавать. Все эти параметры помещаются в сигнатуру сокращенного вызова.
Операции и режимы адресации обладают списком свойств, которые характеризуют некоторые аспекты их поведения и которые могут быть использованы при построении тестов. Эти свойства синтезируются путем анализа спецификаций, и их набор может быть расширен. Набор свойств включает в себя:
· isBranch - показывает осуществляется ли переход (только для операций);
· isConditionalBranch - показывает осуществляется ли условный переход (только для операций);
· canThrowException - показывает может ли быть сгенерировано исключение;
· isMemoryReference - показывает осуществляется ли доступ к памяти (для режимов адресации);
· isLoad - показывает осуществляется ли чтение из памяти;
· isStore - показывает осуществляется ли запись в память;
· getBlockSize - размер блока данных, читаемого или записываемого в память.
Таким образом, метаданные предоставляют среде генерации всю информацию, необходимую для построения тестовых программ для моделируемой архитектуры.
Эмулятор
Эмулятор системы команд (instruction set simulator, ISS), являющейся частью модели, служит в качестве эталонной модели (reference model), на которой выполняются генерируемые последовательности команд с целью контроля состояния микропроцессора. Кроме этого он отвечает за печать команд. Эмулятор инкапсулирует в себе всю информацию о синтаксисе и семантике команд, и взаимодействие с ним осуществляется через набор обобщенных интерфейсов. Это позволяет сделать среду генерации полностью независимой от архитектуры тестируемого микропроцессора.
Эмулятор имеет следующие ограничения: (1) он не является потактово-точным, (2) выполнение отдельных команд считается атомарным, (3) параллельное выполнение команд не поддерживается. Эти допущения позволяют упростить реализацию и не оказывают существенного влияния на качество сгенерированных тестов. В тех случаях, когда требуется исполнение многопоточных программ, выполнение команд осуществляется последовательно, но используя разные контексты.
Список задач, решаемых эмулятором, включает в себя:
· печать команд в ассемблерном формате;
· кодирование команд в двоичный формат;
· декодирование команд;
· исполнение команд;
· построение трасс выполнения команд;
· управление контекстами;
· доступ к информации о текущем состоянии регистров и памяти.
Выполнение этих задач осуществляется при помощи набора абстракций. Две основные сущности, определяемые эмулятором: (1) элементы хранения данных (включающие регистры, физическую память и временные переменные), и (2) команды (состоящие из операций, режимов адресации и непосредственных значений). Все из перечисленных выше задач решаются при помощи манипуляций над этими сущностями. Кроме этого определены дополнительные абстракции, которые управляют доступом к этим сущностям. Далее они будут рассмотрены более подробно.
К элементам хранения данных относятся регистры, физическая память и внутренние временные переменные. Они задаются в виде массивов, где каждый элемент является битовым вектором фиксированной длины. Регистры и физической памяти определяют текущее состояние микропроцессора, которое также называют контекстом исполнения. В процессе работы эмулятора может поддерживаться несколько копий контекстов. Во-первых, это необходимо для эмуляции работы многоядерных микропроцессоров, где каждый поток манипулирует собственным набором регистров. Во-вторых, для решения некоторых задач требуется исполнение команд во временном контексте с последующей отменой изменений. У этих двух случаев есть следующие важные отличия. В первом случае для каждого ядра на протяжении всего сеанса работы эмулятора поддерживается отдельный контекст. При этом некоторые элементы контекста, такие как память, могут разделяться между ядрами. Во втором случае временный контекст создается как копия текущего контекста отдельного ядра и существует в течение ограниченного периода. При этом эта копия является уникальной, и все изменения являются временными и не видны другим ядрам. Управление контекстами осуществляется при помощи абстракции, называемой менеджером контекстов. Он позволяет задавать количество поддерживаемых контекстов и выбирать текущий контекст (как постоянный или как временный). К текущему контексту предоставляется внешний доступ для осуществления следующих действий: (1) размещение данных в памяти и (2) чтение и запись значений заданных регистров (например, счетчика команд) и ячеек памяти. За решение этих задач отвечают сущности, именуемые менеджер размещения данных и провайдер состояния.
Память заслуживает отдельного внимания. Т.к. спецификации на языке nML не позволяют описать механизмы управления памятью (включая трансляцию адресов), построенный на их основе эмулятор использует упрощенную схему работы с памятью. Эта схема предполагает, что виртуальные адреса равны физическим и доступ осуществляется напрямую к физической памяти. Однако среда может быть расширена дополнительными средствами моделирования, которые используют язык mmuSL [7] для создания модели подсистемы управления памятью. Эта модель включает в себя отдельный эмулятор, который должен быть интегрирован в эмулятор системы команд. Интеграция осуществляется следующим образом. Эмулятор системы команд имеет точку соединения, которая позволяет зарегистрировать внешний обработчик запросов к памяти, который вызывается при каждом обращении к массиву физической памяти. Обработчик переадресует все запросы к эмулятору подсистемы управления памятью, который осуществляет трансляцию виртуальных адресов, кэширование данных и доступ к массиву физической памяти по физическим адресам. Как и эмулятор системы команд, эмулятор подсистемы памяти позволяет поддерживать несколько контекстов, управление которыми осуществляется совместно для обоих эмуляторов.
На рисунке 17 показаны основные компоненты, организующие работу с элементами хранения данных, и связи между ними.
Рисунок 17. Компоненты эмулятора, организующие работу с элементами хранения данных
Команды, как уже было сказано, являются композитными объектами, состоящими из операций, режимов адресации и непосредственных значений, для обозначения которых используется общий термин примитив. Конкретный вызов команды создается путем комбинирования примитивов по правилам, заданным в спецификациях и описанных метаданными. Поддерживается два способа создания этих объектов: (1) на основе запросов, составленных из метаданных, и (2) путем декодирования данных в бинарном формате. Эти задачи возложены на компоненты, известные как конфигуратор вызовов и декодер соответственно. При исполнении команды взаимодействуют с текущим контекстом, предоставляемым им менеджером контекстов, читая и записывая данные. Кроме этого они вносят информацию о событиях, которые произошли во время их выполнения, в журнал событий. Поддерживаемые события включают: исполнение команды, запись в регистры и доступ к памяти. Помимо этого каждая инструкция может быть сохранена в текстовом и бинарном формате. Компоненты эмулятора, организующие работу с командами, и их взаимодействие показаны на рисунке 18.
Рисунок 18. Компоненты эмулятора, организующие работу с командами
Необходимо заметить, что эмулятор отвечает только за доступ к элементам хранения данных и выполнение отдельных инструкций. Задача управления эмуляцией (переключение контекстов и выбор команд для выполнения) является независимой от конфигурации микропроцессора и ее решение возложено на компоненты среды генерации, о которых будет рассказано далее.
Модель тестового покрытия
Модель тестового покрытия содержит информацию, необходимую для покрытия различных путей выполнения команд, которую также называют тестовым знанием. Это знание является специфичным для конкретного микропроцессора и синтезируется на основе анализа формальных спецификаций. Тестовое знание представлено в виде таблицы тестовых ситуаций, соответствующих конкретным командам. Каждая тестовая ситуация ассоциируется с одним из возможных путей исполнения данной команды и описывается в виде ограничения на значения ее входных аргументов, которое должно быть удовлетворено для покрытия данного пути.
Ограничения описываются при помощи библиотеки Fortress [84], разработанной автором. Эта библиотека позволяет задавать ограничения в виде формул, представленных в форме синтаксических деревьев, и вызывать внешние решатели. Ограничения сохраняются в формате XML и загружаются по требованию. Кроме того поддерживается возможность сохранять ограничения в виде файлов на языке SMT-LIB (Satisfiability Modulo Theories Library) [85], который используется в качестве основного средства взаимодействия с внешними решателями ограничений.
В основе представления ограничений лежит форма статического единственного присваивания (Static Single Assignment, SSA) [86], построенная на основе nML-спецификаций. Т.к. команды не являются монолитными, а состоят из операций и режимов адресации, SSA форма разбита на части, соответствующие отдельным примитивам. Таким образом, ограничения собираются путем объединения SSA-форм примитивов, составляющих команды. При этом так как ограничению соответствует один из множества возможных путей в графе потока управления, ц-функции сводятся к единственному варианту, а неиспользуемые блоки кода исключаются.
Интерфейс, используемый для доступа к модели тестового покрытия, устроен следующим образом. Он позволяет запрашивать доступ к объектам, описывающим ограничения, по идентификатору команды и идентификатору ограничения. Имена ограничений соответствуют меткам в коде формальных спецификаций. Кроме этого существуют предопределенные идентификаторы, обозначающие некоторые классы тестовых ситуаций (например, выполнение без исключений или выполнение с исключением определенного типа).
Для расширенных вариантов формальных спецификаций, таких как спецификации подсистемы управления памятью, строятся отдельные модели тестового покрытия. Они могут использовать ограничения других типов и другие форматы их представления. Интеграция в общую модель осуществляется следующим образом. Модель тестового покрытия нового типа регистрируется через точку соединения в модели микропроцессора как отдельная сущность. Эта сущность затем используется компонентами среды генерации, реализующими техники построения тестов на основе данного типа знания.
3.1.2 Анализаторы формальных спецификаций
Модель строится на основе формальных спецификаций. Необходимая для этого информация собирается при помощи анализаторов формальных спецификаций. Они реализованы в виде компилятора переднего плана (front-end compiler) [87, 88], состоящего из набора применяемых последовательно компонентов. Этот набор включается в себя:
1. лексический анализатор;
2. синтаксический анализатор;
3. семантический анализатор;
4. анализаторы внутреннего представления.
Лексический анализатор преобразует последовательности символов, считанные из файлов формальных спецификаций, в последовательности лексем. Затем синтаксический анализатор строит из этих лексем дерево разбора. После этого дерево разбора обрабатывается семантическим анализатором, который строит внутреннее представление (internal representation), представляющее собой абстрактное синтаксическое дерево. Внутреннее представление обрабатывается набором анализаторов внутреннего представления, которые извлекают из него всю интересующую информацию. Эта информация может быть представлена в отдельном специальном формате или добавлена в объекты внутреннего представления в качестве атрибутов. Обновленное внутреннее представление и другие результаты работы анализаторов передаются генератором кода модели, о которых будет рассказано в следующем подразделе. Схема взаимодействия перечисленных компонентов показана на рисунке 19.
Рисунок 19. Компоненты анализатора формальных спецификаций и их взаимодействие
Перечисленный набор компонентов разрабатывается для каждого из поддерживаемых языков формальных спецификаций, используя общую методологию и набор специальных библиотек. Отдельного внимания заслуживают анализаторы внутреннего представления. Они предназначены для извлечения информации об определенных свойствах сущностей, описанных при помощи спецификаций. По мере расширения набора исследуемых свойств, множество анализаторов данного типа может пополняться пользовательскими компонентами.
Т.к. спецификации системы команд, созданные при помощи языка nML, являются основным источником информации об архитектуре тестируемого микропроцессора, анализатор nML-спецификаций является ключевым компонентом среды моделирования. Его устройство будет подробно рассмотрено далее. Дополнительные анализаторы, такие как анализатор спецификаций подсистемы управления памятью на языке mmuSL, реализованы аналогичным образом, используя аналогичные компоненты. Эти анализаторы запускаются после анализатора nML-спецификаций и имеют доступ к результатам его работы. Дополнительные анализаторы реализованы в виде расширений (plug-in) среды и используют входные файлы определенного типа. Внутренние представления, полученные в результате их работы, дополняют друг друга и интегрируются в единый объект. На рисунке 20 показана схема совместной работы нескольких анализаторов формальных спецификаций.
Рисунок 20. Схема совместной работы нескольких анализаторов формальных спецификаций
Анализаторы формальных спецификаций разработаны при помощи инструмента ANTLR [89, 90, 91], который позволяет сгенерировать лексический, синтаксический и семантический анализаторы на основе описаний грамматики языка. Данный инструмент был выбран т.к. он разработан на языке Java и является открытым. Для упрощения разработки анализаторов MicroTESK предоставляет набор библиотек, которые реализуют логику работы препроцессора, обработки ошибок, управления таблицей символов, а также служат строительными блоками для внутреннего представления.
Лексический анализатор построен на основе грамматики ANTLR, которая описывает правила разбиения потока символов на лексемы. Данная грамматика включает правила обработки директив препроцессора, которые позволяют включить или исключить из обработки отдельные фрагменты кода или файлы. Результатом работы данного анализатора является поток лексем. Грамматика лексического анализатора разделена на две части: (1) базовую и (2) специфическую для nML. Первая содержит описания лексем, общие для многих языков, и правила обработки директив препроцессора. Вторая содержит описания лексем, используемых языком nML. При создании лексических анализаторов для новых языков базовая часть используется повторно и дополняется описаниями лексем, специфичными для данного языка.
Синтаксический анализатор построен на основе грамматики ANTLR, описывающей правила построения дерева разбора. Кроме этого данные правила осуществляют регистрацию идентификаторов в таблице символов и связанные с этим проверки (отсутствие переопределений, применимость идентификаторов определенного типа в данном контексте). Логика управления таблицей символов и правила грамматики, общие для многих языков, такие как правила разбора инструкций (statements) и выражений (expressions), помещаются в отдельные компоненты, которые могут быть повторно использованы при создании синтаксических анализаторов для новых языков.
Семантический анализатор построен на основе грамматики ANTLR, которая описывает правила обхода дерева разбора, построенного на предыдущем этапе. Данные правила обращаются к фабрикам внутреннего представления, которые осуществляют необходимые семантические проверки и конструируют объекты внутреннего представления.
Внутреннее представление включает в себя набор таблиц, которые хранят описания следующих сущностей: (1) константы, (2) типы данных, (3) элементы хранения данных, (4) режимы адресации и (5) операции. Отдельного внимания заслуживают режимы адресации и операции. Они содержат ссылки на другие примитивы (операции, режимы адресации), описывающие типы их аргументов. Каждый примитив имеет набор атрибутов, которые описывают их функции и представлены в виде абстрактных синтаксических деревьев. Тело атрибута может содержать вызовы атрибутов примитивов, переданных текущему примитиву в качестве аргументов. Описание вызова содержит в себе ссылку на вызываемый атрибут и содержащий его примитив. Таким образом, примитивы образуют ориентированный ациклический граф (directed acyclic graph), истоком которого является операция instruction.
Набор сущностей внутреннего представления, построенного семантическим анализатором, в точности соответствует набору сущностей, описанных nML-спецификациями. Однако для построения модели требуется дополнительная информация, которая синтезируется в результате анализа внутреннего представления. Для решения этой задачи разработан набор анализаторов, которые осуществляют обход внутреннего представления и извлекают необходимую информацию. В настоящее время набор включает в себя анализаторы, которые решают следующие задачи:
1. синтез правил построения сокращенных вызовов операций;
2. определение типов аргументов (входной или выходной);
3. определение операций, порождающих исключения;
4. определение операций, осуществляющих передачу управления;
5. определение операций, осуществляющих доступ к памяти;
6. определение формата бинарного представления примитивов;
7. построение набора ограничений для каждого примитивов.
Набор анализаторов может быть расширен пользовательскими анализаторами. Все анализаторы имею общую архитектуру. Общие части вынесены в повторно используемые компоненты. Анализаторы включают в себя два основных компонента: (1) обходчик (walker) и (2) посетитель (visitor). Обходчик осуществляет обход внутреннего представления, вызывая методы посетителя для каждого объекта. Посетитель анализирует переданные ему объекты и накапливает информацию об их свойствах, которую сохраняет в атрибутах примитивов и или в дополнительных структурах (например, создает SSA-форму).
3.1.3 Генераторы кода и библиотеки моделирования
На основе внутреннего представления и извлеченной из него дополнительной информации осуществляется конструирование модели, которая представляет собой набор Java-классов, построенных на основе специальных библиотек моделирования. За конструирования модели отвечают генераторы кода, которые аналогично анализатором внутреннего представления осуществляют его обход и генерирует на основе полученной информации Java-код. Каждый генератор отвечает за построение отдельной части модели. Поддерживаются следующие генераторы:
1. генератор внешнего интерфейса модели;
2. генератор метаданных;
3. генератор эмулятора;
4. генератор декодера;
5. генератор модели покрытия.
Набор генераторов может быть расширен в случае необходимости. Генераторы реализованы на основе библиотеки StringTemplate [92], которая осуществляет генерацию кода по шаблонам. Логика обхода внутреннего представления реализована так же, как в анализаторах внутреннего представления, и использует те же компоненты.
Рассмотрим более подробно библиотеки, используемые для конструирования модели. Набор библиотек включает в себя:
· Библиотеки описания данных и операций над ними. Данные представлены в виде битовых векторов, для хранения которых используются классы библиотеки Fortress [84]. Операции целочисленной арифметики также реализованы в этой библиотеке. Для описания операций над числами с плавающей точкой используется библиотека Java SoftFloat [93], разработанная в ИСП РАН. Данная библиотека была разработана как Java-версия библиотеки Berkeley SoftFloat [94], реализующей стандарт IEEE 754 [60].
· Библиотека описания элементов хранения данных. Включает в себя классы для описания регистров и физической памяти. Данные классы позволяют регистрировать обработчики запросов, которые могут быть использованы для интеграции расширений и регистрации событий.
· Библиотека описания исполняемых команд. Служит основанной для эмулятора системы команд. Позволяет описывать режимы адресации и операции, а также фабрики, отвечающие на создание их экземпляров и конструирование на их основе вызовов команд. Логика работы команд описывается при помощи двух описанных выше библиотек.
· Библиотека компонентов декодера. Позволяет построить компоненты, обеспечивающие построение вызовов команд на основе их бинарного представления.
· Библиотека описания метаданных. Содержит классы, описывающие свойства всех сущностей системы команд.
· Библиотека описания ограничений, основанная на библиотеке Fortress [84]. Позволяет описывать ограничения в виде SMT-формул.
· Библиотека внешнего интерфейса модели. Обеспечивает доступ ко всем частям модели.
· Библиотеки описания эмулятора подсистемы памяти и ее модели покрытия.
Библиотеки могут эволюционировать, и их набор может расширяться по мере необходимости. При этом данные изменения не затронут пользователей инструмента.
3.2 Среда тестирования
Среда тестирования отвечает за построение тестовых программ на основе модели микропроцессора и шаблонов тестовых программ. Она состоит из анализатора (template analyzer) и обработчика (template processor) шаблонов. Первый строит внутреннее представление шаблонов, а второй генерирует на его основе тестовые программы. Обработка внутреннего представления осуществляется на уровне отдельных блоков. Для каждого из них строятся последовательности команд, которые затем исполняются на программном эмуляторе, предоставляемым моделью микропроцессора. Это позволяет отслеживать состояние микропроцессора и учитывать его в процессе генерации. Основные компоненты, участвующие в построении последовательностей команд включают в себя:
· итератор последовательностей команд (sequence iterator);
· распределитель регистров (register allocator);
· обработчик последовательностей команд (sequence processor);
· исполнитель последовательностей команд (sequence executor);
· генератор данных (data generator);
· построитель встроенных проверок (self-check maker);
Перечисленные компоненты будут подробно рассмотрены в следующих подразделах.
3.2.1 Анализатор шаблонов тестовых программ
Анализатор тестовых (template analyzer) шаблонов интерпретирует код тестовых шаблонов и строит для них внутреннее представление. Для этого используется интерпретатор JRuby [95], который интегрирован в анализатор. Этот интерпретатор разработан на языке Java и позволяет в процессе исполнения Ruby-кода загружать Java-компоненты и вызывать их методы. Схема анализатора шаблонов тестовых программ показана на рисунке 21.
Рисунок 21. Схема анализатора шаблонов тестовых программ
Анализатор шаблонов включает в себя следующие компоненты:
· интерпретатор JRuby;
· загрузчик шаблонов (разработан на Ruby);
· библиотеки для описания конструкций языка (разработаны на Ruby);
· классы внутреннего представления (разработаны на Java);
· фабрики внутреннего представления (разработаны на Java).
Анализ шаблонов тестовых программ осуществляется следующим образом. При запуске анализатора интерпретатор исполняет загрузчик шаблонов, который загружает класс анализируемого шаблона. В процессе загрузки класса шаблона, загрузчик на основе метаданных из модели микропроцессора создает для него методы, отвечающие за конструирование архитектурно-зависимых объектов внутреннего представления (команды, режимы адресации и т.п.). После этого загрузчик вызывает методы класса шаблона, описывающие отдельные части тестовой программы (пролог, эпилог и тестовые примеры). Эти методы, используя различные конструкций языка описания шаблонов, реализованные в Ruby-библиотеках, обращаются к фабрикам внутреннего представления для конструирования соответствующих объектов. После этого внутреннее представление передается для дальнейшей обработки.
Подход, при котором сначала строится внутреннее представление, а затем осуществляется его обработка, позволяет сделать реализацию генератора тестовых программ независимой от языка описания шаблонов. То есть для поддержки нового языка описания шаблонов, при условии наличия для него аналогичного интерпретатора, достаточно разработать загрузчик шаблонов и библиотеку языковых конструкций. Например, можно создать реализацию, в которой шаблоны будут разрабатываться на языке Python [79], а для их анализа будет использоваться интерпретатор Jython. При этом реализация остальных частей генератора тестовых программ не изменится.
3.2.2 Внутреннее представление шаблонов тестовых программ
Внутреннее представление, полученное в результате анализа шаблона, представляет собой набор объектов, описывающих свойства отдельных частей тестовых программ (пролога, эпилога, тестовых примеров и секций диспетчеризации). Каждая из этих частей представлена в виде блока, который описывает способ построения ее кода. Блоки снабжены набором атрибутов (пары ключ-значение), которые задают техники, применяемые для обработки содержимого этих блоков. Блоки содержат в себе список из структурных элементов, на основе которых будет построен код соответствующих частей тестовой программы. В качестве структурных элементов выступают вложенные блоки, команды и элементы специального назначения. Вложенные блоки обрабатываются рекурсивно.
Команды состоят из примитивов, описывающих их составные части (операции и режимы адресации). Структура связей между частями соответствует структуре, описанной метаданными. Примитивы снабжены следующими атрибутами: имя, список передаваемых им аргументов и объект метаданных, описывающий их свойства. В качестве аргументов выступают примитивы или непосредственные значения (immediate value). Они могут быть жестко определены или помечены как неопределенные. В последнем случае для них используется специальный объект-заглушка, который заменяется на конкретный объект в процессе дальнейшей обработки. Помимо этого для команды может быть задана связанная с ней тестовая ситуация. Тестовые ситуации содержат набор атрибутов, задающие настройки, которые будут использоваться при ее обработке.
К элементам случайного назначения относятся сущности следующих типов: секции данных; метки; директивы ассемблера (смещения, выравнивания); текст; служебные инструкции генератора и т.д. Они помещаются в один объект вместе со следующей за ними командой, чтобы обеспечить фиксацию их местоположения относительно этой команды. При этом возможно также создавать структурные элементы, содержащие только перечисленные сущности. На рисунке 22 показан структурный элемент, описывающий команду ADDI архитектуры MIPS с неизвестными регистрами и непосредственным аргументом, а также связанные с ней метку и директиву задания смещения.
Рисунок 22. Объекты внутреннего представления, описывающие команду
Кроме блоков, которые были описаны выше, внутреннее представление содержит объекты, описывающие различные препараторы и компараторы. Они также из структурных элементов такого же вида. При этом команды могут использовать неизвестные значения и режимы адресации. В процессе построения кода для препараторов и компараторов они будут заменены на объекты, описывающие конкретные значения или примитивы (например, режим адресации, описывающий инициализируемый регистр, и записываемое в него значение).
3.2.3 Обработчик внутреннего представления
Построенное анализатором шаблонов внутреннее представление передается обработчику внутреннего представления (template processor), который осуществляет на его основе построение тестовых программ.
Тестовая программа представляет собой список последовательностей команд, описывающих ее отдельные части (пролог, эпилог, тестовые примеры, секции диспетчеризации). Последовательности команд строятся в результате обработки блоков внутреннего представления, описывающих соответствующие части программы. Построенные последовательности команд исполняются на программном эмуляторе модели микропроцессора. Информация о состоянии эмулятора используется при построении тестовых примеров и встроенных проверок для них. Поэтому, чтобы обеспечить правильность состояния эмулятора в момент построения конкретного тестового примера, построение кода для отдельных частей осуществляется в порядке их исполнения.
Рисунок 23 иллюстрирует разбиение шаблона тестовой программы на блоки. При помощи стрелок показана структура переходов управления между частями программы, описываемыми блоками. На рисунке заштрихованы блоки, для которых структура кода фиксирована и при его построении не используется информация о состоянии эмулятора. Двойная штриховка обозначает, что адреса, по которым будет располагаться код, заранее определены. Блоки, которые остались не заштрихованными, соответствуют описаниям тестовых примеров.
Рисунок 23. Схема разбиения шаблона на блоки и структура переходом между ними
Схема обработки блоков внутреннего представления выглядит следующим образом:
1. Сначала обрабатываются блоки, при построении кода для которых не используется информация о состоянии эмулятора. К таким блокам относятся пролог, эпилог и секции диспетчеризации. Последние содержат переходы друг в друга, поэтому перед началом исполнения их код должен быть построен и размешен в памяти эмулятора. Важным моментом является то, что адрес размещения кода в памяти должен быть заранее известен. Это возможно только, если последовательность команд начинается с директивы, задающей ее смещение (обычно это директива .org), или последовательность размещается следом за другой последовательностью с известным смещением. Для эпилога и некоторых секций диспетчеризации, смещение которых зависит от размера кода тестовых примеров, за которыми они следуют, не может быть определено на этой стадии. Поэтому построенные для них последовательности команд не размещается в эмуляторе, а помечаются как ожидающие размещения.
...Подобные документы
Применение тестовых заданий на уроках информатики. Основные виды тестовых заданий. Подбор тестовых заданий по темам курса информатики. Программные продукты для разработки и создания тестовых заданий. Общие правила оформления компьютерных тестовых заданий.
курсовая работа [2,2 M], добавлен 28.09.2011Методика разработки внешних спецификаций программ, основанных на использовании HIPO-технологии проектирования программ. Приобретение практических навыков определения и оформления внешних спецификаций программ. Схема состава разложения и IPO-диаграммы.
лабораторная работа [45,6 K], добавлен 15.03.2009Формирование требований к подсистеме генерации тестовых заданий в открытой системе дистанционного образования, проектирование подсистемы генерации тестовых заданий в открытой системе дистанционного обучения, реализация пользовательского интерфейса.
курсовая работа [3,3 M], добавлен 28.08.2012Логические функции и структура микропроцессоров, их классификация. История создания архитектуры микропроцессоров x86 компании AMD. Описание К10, система обозначений процессоров AMD. Особенности четырёхъядерных процессоров с микроархитектурой К10 и К10.5.
курсовая работа [28,9 K], добавлен 17.06.2011Технологии производства микропроцессоров: основные этапы производства. Выращивание диоксида кремния и создание проводящих областей и тестирование. Особенности производства микропроцессоров. Производство подложек, легирование, диффузия, фотолитография.
курсовая работа [4,7 M], добавлен 26.03.2009Программа как совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств. Этапы создания программ: каскад, инкремент, эволюция. Порядок написания исходного кода и его компиляция. Сборка статической библиотеки.
презентация [119,4 K], добавлен 05.01.2014Автоматизация учета закупки лекарственных препаратов в аптеке. Разработка базы данных и прикладных программ для работы с ней. Анализ предметной области и формирование требований пользователей. Выбор архитектуры программно-технологической реализации.
курсовая работа [4,1 M], добавлен 10.09.2015Унифицированный язык моделирования UML. Проектирование и документирование программных систем. Листинги кода проектируемой программы, сгенерированные RationalRose. Модель информационной подсистемы для управления, учета, контроля и ведения библиотеки.
курсовая работа [1,3 M], добавлен 22.06.2011Исследование и оценка возможностей работы со следующими разделами библиотеки приложения Simulink пакета программ Matlab: Source, Sinks, Continuous, Math Operation. Функции по представлению полученных в результате моделирования данных в графическом виде.
лабораторная работа [438,9 K], добавлен 23.09.2022Степень переносимости исходного кода между различными платформами. Первый язык программирования высокого уровня, имеющий транслятор. Программа Fortran, ее версии, отличия от других программ. Составление программ на языке программирования Fortran.
курсовая работа [45,5 K], добавлен 04.06.2014Анализ существующих систем автоматизации документооборота. Выбор шаблона проектирования. Microsoft SQL Server как комплексная высокопроизводительная платформа баз данных. Язык программирования C#. Разработка интерфейса и иллюстрация работы системы.
дипломная работа [2,5 M], добавлен 19.07.2014Основные характеристики микропроцессоров: тактовая частота, кэш память, дополнительные инструкции, разрядность, архитектура, количество ядер. История развития микропроцессоров, главные фирмы-производители. Разработка программы работы с массивом.
курсовая работа [139,4 K], добавлен 24.06.2011Понятие, виды и функции тестов, компьютерное тестирование. Государственные стандарты создания компьютерных тестов и практическая реализация комплекса генерации тестов: СУБД и язык программирования, пользовательский интерфейс, экономическая эффективность.
дипломная работа [2,1 M], добавлен 29.06.2012Основные составляющие компьютерной системы. История развития, особенности применения микропроцессоров. Устройство и работа D-триггера. Принципиальная электрическая схема, директивы, операторы и описание программы для микропроцессоров, виды отладчиков.
методичка [2,9 M], добавлен 27.11.2011Объем двухпортовой памяти, расположенной на кристалле, для хранения программ и данных в процессорах ADSP-2106x. Метод двойного доступа к памяти. Кэш-команды и конфликты при обращении к данным по шине памяти. Пространство памяти многопроцессорной системы.
реферат [28,1 K], добавлен 13.11.2009Изучение понятия архивации, сжатия файлов с целью экономии памяти и размещения сжатых данных в одном архивном файле. Описания программ, выполняющих сжатие и восстановление сжатых файлов в первоначальном виде. Основные преимущества программ-упаковщиков.
контрольная работа [534,7 K], добавлен 11.01.2015Нахождение наибольшего элемента массива, расположенного во внутренней памяти, сохранение его значения в стеке. Описание используемых команд: запись из внутренней памяти в аккумулятор данных, безусловный переход по метке. Составление кода программы.
лабораторная работа [41,4 K], добавлен 18.11.2014Язык Паскаль - процедурно-ориентированный язык высокого уровня, его основные достоинства. Разработка программ для решения задач. Выбор метода обработки информации. Форма представления исходных данных. Разработка алгоритма, его описание, листинг программы.
курсовая работа [3,6 M], добавлен 17.02.2013Семь поколений процессоров. Технология производства микропроцессоров. Сравнительные характеристики процессоров AMD и Intel на ядре Clarkdale. Квазимеханические решения на основе нанотрубок. Одновременная работа с Firefox и Windows Media Encoder.
дипломная работа [2,2 M], добавлен 11.06.2012Понятия и принцип работы процессора. Устройство центрального процессора. Типы архитектур микропроцессоров. Однокристальные микроконтроллеры. Секционные микропроцессоры. Процессоры цифровой обработки сигналов. Эволюция развития микропроцессоров Intel.
реферат [158,8 K], добавлен 25.06.2015
