Разработка метода автоматизации конструирования генераторов тестовых программ для микропроцессоров
Функциональная верификация микропроцессоров. Анализаторы формальных спецификаций. Генераторы кода и библиотеки моделирования. Техники генерации тестовых программ. Спецификации архитектуры, язык описания шаблонов. Размещение команд и данных в памяти.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | диссертация |
| Язык | русский |
| Дата добавления | 11.06.2018 |
| Размер файла | 2,7 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Генерация тестовых программ включает следующие стадии: (1) построение последовательностей команд; (2) решение ограничений (или генерация случайных значений) для каждой из команд; (3) исполнение команд на эталонной модели. В случае если не удается решить ограничения, инструмент может вносить коррективы в последовательность команд (добавлять дополнительные команд, повторно генерировать предыдущие команд).
Инструмент Genesys-Pro позволяет достичь достаточно высокого уровня нацеленности. Степень случайности тестов задается тестовыми шаблонами, которые разрабатываются в соответствии с планом верификации. Решение относительно полноты набора тестовых шаблонов принимается на основе метрик покрытия, основанных на реализации и функциональных требованиях.
К недостаткам Genesys-Pro можно отнести ограничения среды моделирования, которые требуют использования дополнительных средств для моделирования инструкций арифметики с плавающей точкой и доступа к памяти. Другим слабым местом является использование внешней эталонной модели для эмуляции исполнения команд. Это требует дополнительных трудозатрат на интеграцию и поддержку данной модели. Также непонятно насколько расширяемым является инструмент (возможность добавления новых техник генерации).
Инструмент FPGen
Для верификации модулей арифметики с плавающей точкой IBM Research был разработан инструмент FPGen [58]. Этот инструмент расширяет Genesys-Pro средствами генерации тестовых данных для покрытия всевозможных ситуаций в работе операций с плавающей точкой [59] (требования определены в стандарте IEEE 754 [60]).
Инструмент FPGen генерирует значения входных аргументов команд, разрешая специализированные ограничения. Ограничения определяют значения отдельных входных аргументов, отношения между значениями входных аргументов, результат промежуточных вычислений или конечный результат выполнения команды. Для описания ограничений используется язык XML. Генератор FPGen не привязан к какой-либо конкретной архитектуре, он генерирует наборы данных, которые сохраняются в специальном формате [60]. Эти данные используются Genesys-Pro при генерации тестовых программ, использующих операции арифметики с плавающей точкой. В процессе генерации Genesys-Pro комбинирует результаты решения ограничений, которые он разрешает самостоятельно и которые он разрешает при помощи FPGen.
Инструмент DeepTrans
Еще одно известное расширение Genesys-Pro - это инструмент DeepTrans [62], предназначенный для тестирования механизмов трансляции адресов. Этот инструмент использует спецификации подсистемы памяти, разработанные на специализированном языке моделирования. Данный язык позволяет представить процесс преобразования адреса в виде ориентированного ациклического графа, вершины которого соответствуют стадиям процесса, а дуги -- переходам между стадиями. Множество путей от истока до стока задает конкретные варианты преобразования адреса и соответствует тестовым ситуациям. Тестовые ситуации представляются в виде ограничений, на которые можно ссылаться из тестовых шаблонов. За обработку шаблонов отвечает инструмент Genesys-Pro, который разрешает ограничения и трансформирует результаты в последовательности команд. К достоинствам DeepTrans следует отнести развитый язык моделирования механизмов трансляции. Он позволяет достаточно быстро осуществить настройку инструмента для тестирования механизмов трансляции адресов произвольного микропроцессора. Известный недостаток состоит в том, что не поддерживается автоматическое извлечение зависимостей между командами (конфликтов использования устройств); их приходится дополнительно указывать в тестовых шаблонах.
1.4.4 Разработки ИСП РАН
Исследования в области генерации тестовых программ для микропроцессоров ведутся в ИСП РАН с середины 2000-х годов [41]. В рамках этих исследований был разработан прототип инструмента MicroTESK (Microprocessor TEsting and Specification Tool Kit) версии 1.0. Данный инструмент использует модели микропроцессора и тестовые шаблоны, разработанные на языке Java, и позволяет сгенерировать тесты для широкого спектра микропроцессорных архитектур при помощи случайных и комбинаторных техник генерации, а также техник, основанных на разрешении ограничений. Модель микропроцессора включает в себя программный эмулятор, который позволяет отслеживать состояние микропроцессора в процессе генерации.
Модель микропроцессора задает семантику команд и структуру подсистемы управления памятью. Тестовые шаблоны позволяют описывать сценарии в терминах тестовых ситуаций, связанных с работой отдельных команд. При этом в тестовом шаблоне задаются используемые команды, их порядок и связанные с ними ситуации. Также инструмент позволяет строить тесты для тестирования работы модуля предсказания переходов (BPU, branch prediction unit) путем перебора возможных трасс выполнения в структуре переходов, заданной шаблоном [43]. Тесты для подсистемы управления памятью (MMU, memory management unit) описаются в виде коротких последовательностей команд (2-3 команды), для которых строятся комбинации возможных сценариев обработки обращений к памяти с учетом зависимостей (допустимых вариантов совместного использования буферов памяти) [63].
К достоинствам инструмента можно отнести: (1) возможность поддержки различных архитектур, (2) отсутствие зависимостей от внешних эмуляторов, (3) поддержку генерации нацеленных тестов для BPU и MMU. Главным недостатком инструмента является использование языка Java для моделирования и описания тестовых шаблонов. Это усложняет конфигурирование инструмента, т.к. требует знания языка Java и деталей реализации библиотек MicroTESK. При этом эмулятор и модель покрытия необходимо описывать отдельно. Также отсутствует возможность автоматического извлечения информации из описаний - все свойства микропроцессора приходится задавать в явном виде. Таким образом, разработка модели является трудноосуществимой задачей без тесного взаимодействия с разработчиками инструмента. Еще одна проблема, связанная с использованием языка Java, - это то, что обновления библиотек, которые неизбежны в процессе эволюции инструмента, могут повлечь за собой изменения в уже созданных моделях и шаблонах. Другой недостаток заключается в том, что в инструмент не заложена возможность интеграции новых методов генерации и их совместного использования. Например, нет возможности сгенерировать тестовую программу, решающую задачи тестирования BPU и MMU, на основе единого тестового шаблона.
1.4.5 Другие разработки
Среда RDG
В компании Samsung разработана среда RDG (Random Diagnostics Generator) [64], предназначенная для случайной генерации тестовых программ для реконфигурируемых микропроцессоров (Samsung Reconfigurable Processor, SRP). Эта среда использует в качестве входных данных описание синтаксиса команд тестируемого микропроцессора и тестовые шаблоны на языке С++. Тестовые шаблоны задают, какие команды будут использованы в тестовой программе, и описывают ограничения, накладываемые на входные значения этих команд. Среда RDG не владеет информацией о семантике команд и не осуществляет исполнение тестовых программ с целью предсказания результатов. Такой подход был выбран из-за особенностей тестирования реконфигурируемых микропроцессоров (система команд зависит от конфигурации и их реализация может отличаться). Кроме того это позволяет с минимальными усилиями добавлять поддержку новых команд и обеспечить высокую скорость генерации. Недостаток такого подхода в том, что для генерации нацеленных тестов требуется описывать ограничения вручную и отсутствует возможность отслеживать состояние микропроцессора. Стоит сказать, что инструмент RDG позволяет эффективно решать задачу тестирования реконфигурируемых микропроцессоров Samsung, но он не является универсальным. Поддержка новых микропроцессорных архитектур и техник генерации в него не заложена.
Генератор MA2TG
Исследования в области генерации тестовых программ для функциональной верификации микропроцессоров проводились в Оборонном научно-техническом университете Китая (National University of Defense Technology) [65]. В рамках этих исследований был разработан прототип генератора тестовых программ MA2TG. Данный генератор применим для различных архитектур и поддерживает случайную генерацию и генерацию на основе ограничений. В качестве входных данных для генератора MA2TG используются спецификации на языке EXPRESSION [66], описывающие архитектуру тестируемого микропроцессора, и шаблоны на специализированном языке, формулирующие задачи генерации. Инструмент транслирует входные в файлы в программу-генератор на языке С++, которая генерирует тесты. В процессе генерации исполнения построенных последовательностей команд не осуществляется.
Спецификации на языке EXPRESSION содержат информацию о структуре и поведенческих свойствах микропроцессора, а также о связи между ними. Для генерации тестовых программ в первую очередь необходима информация о поддерживаемых командах, которая включает текстовый и бинарный формат команд, списки их операндов и семантику команд (условия возникновения тестовых ситуаций). MA2TG строит на основе спецификаций библиотеку шаблонов команд (Instruction Template Library, ITL), которая используется при генерации. Каждая команда описывается классом на языке C++, который содержит методы для ее печати, получения списка аргументов и доступа к ассоциированным с ней ограничениям. Использование формальных спецификаций позволяет относительно просто сконфигурировать инструмент для тестирования микропроцессора с новой архитектурой. Однако подход MA2TG имеет некоторые недостатки. Информация о структуре микропроцессора, которая описывается в спецификациях на языке EXPRESSION, чаще всего не требуется для генерации тестовых программ. Эта информация может быть достаточно объемной, и ее специфицирование требует дополнительных трудозатрат. Кроме того она может быть недоступна на ранних стадиях работы над проектом. А в случаях, когда требуется тестирование микропроцессоров, по-разному реализующих одну и ту же архитектуру, она может препятствовать повторному использованию спецификаций. Все это увеличивает трудоемкость разработки и поддержки спецификаций. Использование более простого языка, описывающего только поведенческие свойства, могло бы упростить эту задачу. Также, следует заметить, что MA2TG не строит эталонный эмулятор на основе спецификаций, хотя язык EXPRESSION предоставляет для этого достаточное количество информации. Эталонный эмулятор был бы полезен для проверки корректности построенных программ, создания встроенных проверок и разрешения ограничений.
Задачи генерации описываются на специализированном языке. Такие описания называют ограничениями (constraints), хотя, по сути, они являются вариантом тестовых шаблонов. На их основе MA2TG создает программы на языке C++, которые при помощи ITL и внешних библиотек разрешения ограничений, генерируют тесты. Язык описания тестовых шаблонов позволяет задавать следующие параметры: (1) используемые команды, их количество, порядок и вероятность появления; (2) ограничения на значения операндов команд; (3) зависимости по операндам между командами. Данный язык ориентирован на случайную выборку команд и разрешения ограничений для выбранных команд. Это позволяет быстро создавать большое количество небольших тестов для верификации определенных команд. Однако он не позволяет описывать сценарии со сложной структурой переходов. Также не предоставляется возможностей для описания многопоточных сценариев. Т.к. инструмент не осуществляет исполнение команд на эталонной модели, не поддерживается создание встроенных проверок. Кроме того отсутствие информации о состоянии микропроцессора усложняет решение ограничений. Из описания инструмента неясно, какие типы ограничений он поддерживает и насколько сложно в него добавить поддержку новых типов.
Инструмент MA2TG реализован в виде прототипа. Несмотря на то, что его подход имеет ряд преимуществ, его функциональные возможности ограничены. Остается непонятно насколько он соответствует требованиям, предъявляемым инструментам, используемым в промышленных проектах. Из очевидных недостатков можно перечислить излишне детальные спецификации, отсутствие контроля состояния микропроцессора в процессе генерации, ограниченные возможности языка тестовых шаблонов и ограниченный набор поддерживаемых техник генерации.
Исследования Университета Флориды и Калифорнийского университета в Ирвайне
В Университете Флориды (UFL) и Калифорнийском университет в Ирвайне (UCI) был разработан метод генерации тестовых программ, нацеленных на проверку корректности работы конвейера команд микропроцессора [37]. Данный метод использует спецификации на языке EXPRESSION [66], на основе которых строится модель, описывающая архитектуру микропроцессора в виде графа. Кроме этого разрабатывается модель ошибок, которая описывает типичные ошибки проектирования. На основе модели ошибок для модели микропроцессора строятся формулы, которые задают условия возникновения конкретных ошибок для данного микропроцессора. Для этих формул при помощи инструмента SMV (Symbolic Model Verifier) [66], который использует метод проверки моделей, стоятся тестовые примеры (контрпримеры для отрицания формул), на основе которых генерируются тестовые программы. По мнению авторов, метод не масштабируется на сложные микропроцессоры, поэтому предлагается дополнительно использовать тестовые шаблоны. Они создаются вручную и содержат описания цепочек команд, которые вызывают определенные ситуации в поведении микропроцессора (прежде всего, конвейерные конфликты). К достоинствам данного метода можно отнести то, что он применим для различных типов микропроцессоров и позволяет обеспечить покрытие ситуаций в работе конвейера команд, используя минимальное количество тестов. Главный недостаток метода - сложность разработки детальных спецификаций и модели ошибок. Следует также отметить, что данные исследования носили академический характер и на их основе не были разработаны инструменты, которые могли бы использоваться в промышленных проектах.
Инструмент GP
Исследователями Туринского политехнического университета (Politecnico di Torino) был предложен интересный подход к генерации тестовых программ, основанный на использовании генетических алгоритмов [68, 69, 70]. Данный подход был реализован в прототипе инструмента GP. Основная идея подхода состоит в следующем. Для генератора тестовых программ создается библиотека инструкций, которая описывает синтаксис языка ассемблера целевого микропроцессора. Задачи генерации описываются в виде ациклического графа, который описывает поток выполнения тестовой программы. Каждая вершина графа содержит ссылку на описание команды в библиотеке команд и значения ее операндов. Библиотека команд и задачи генерации описываются на языке XML. Генерация тестовых программ осуществляется путем мутации структуры графа и значений операндов команд внутри отдельных вершин. Генератор пытается построить тестовую программу, которое обеспечит наилучшее покрытие для заданной метрики. Значение метрики получается путем выполнения построенных программ на программном эмуляторе RTL-модели.
Достоинством данного подхода является его гибкость и универсальность. Он позволяет достичь высокого уровня тестового покрытия для различных типов микропроцессоров, используя различные метрики покрытия. Главный недостаток - высокая вычислительная сложность, из-за которой скорость генерации получается достаточно низкой. Инструмент GP реализует только один метод генерации и не предусматривает поддержку новых методов. Еще один возможный недостаток - это то, что входные форматы конфигурационных файлов не являются интуитивно понятными.
Выводы
Для всех рассмотренных в этой главе инструментов, независимо от поддерживаемых ими техник, можно выделить два свойства: (1) реконфигурируемость и (2) расширяемость. Оба этих свойства показывают, какое количество усилий требуется для адаптации инструмента к решению новых задач. Под реконфигурируемость понимается возможность поддержки новых микропроцессорных архитектур, а под расширяемостью - возможность интеграции компонентов, реализующих различные техники генерации.
Другим важным свойством является контролируемость генерации, возможность отслеживать текущее состояние микропроцессора в процессе генерации путем исполнения генерируемых последовательностей команд на эталонной модели, в качестве которой выступает программный эмулятор. Это позволяет гарантировать корректность построенных программ, создавать тесты со встроенными проверками и применять техники генерации, использующие информацию о текущем состоянии микропроцессора. Эталонные модели разрабатываются отдельно от инструмента генерации и интегрируются в него при помощи специальных библиотек. Однако, по сути, они являются частью конфигурации инструмента т.к. используют знание о синтаксисе и семантике команд для их интерпретации.
Основным свойством, характеризующим техники генерации, является целенаправленность тестирования. Техники, основанные на случайной генерации, не позволяют систематическим образом обеспечить покрытие функциональных требований. Современные микропроцессоры с конвейерной архитектурой и сложной организацией памяти имеют огромное пространство возможных состояний, которые с малой вероятностью будут достигнуты при использовании случайных тестов. Поэтому для создания тестовых программ, нацеленных на проверку конкретных ситуаций или классов ситуаций, требуются специализированные техники, основанные на разрешении ограничений и проверке моделей.
Еще одним важным свойством современных инструментов верификации является возможность построения тестовых программ для многоядерных микропроцессоров. На базовом уровне она присутствует практически во всех инструментах, т.к. для этого достаточно включить в построенные программы команды, обеспечивающие разветвление потока выполнения на несколько ядер. Однако техники нацеленной генерации, использующие информацию о текущем состоянии микропроцессора, должны учитывать тот факт, что каждое из ядер имеет свое состояние. Кроме того, инструменты должны обеспечивать покрытие ситуаций, связанных с параллельным выполнением программ.
Таблица 4 сравнивает функциональные возможности рассмотренных ранее инструментов по перечисленным критериям.
Таблица 4. Сравнение возможностей рассмотренных инструментов генерации
|
Инструмент |
Реконфигурируемость |
Расширяемость |
Контролируемость генерации |
Целенаправленность тестирования |
Поддержка многоядерности |
|
|
MicroTESK 1.0 |
Да |
Нет |
Да |
Высокая |
Нет |
|
|
INTEG |
Нет |
Нет |
Нет |
Средняя |
Нет |
|
|
RIS |
Нет |
Нет |
Нет |
Средняя |
Да |
|
|
RAVEN |
Да |
Нет |
Да |
Средняя |
Да |
|
|
Genesys-Pro, FPGen, DeepTrans |
Да |
Да (частично) |
Да |
Высокая |
Да |
|
|
RDG |
Да |
Нет |
Нет |
Низкая |
Нет |
|
|
MA2TG |
Да |
Нет |
Нет |
Высокая |
Нет |
|
|
UFL/UCI |
Да |
Нет |
Нет |
Высокая |
Нет |
|
|
GP |
Да |
Нет |
Нет |
Средняя |
Нет |
Как можно заметить, большинство инструментов предназначено для решения конкретных задач и не предполагают расширяемость. Это объясняется тем, что коммерческие компании занимаются верификацией выпускаемых ими микропроцессоров и создают инструменты для решения текущих задач верификации, а исследовательские институты изобретают новые техники верификации и создают инструменты для их апробации. При этом задача интеграции техник, которые не используются в данный момент, не ставится.
Ситуация с реконфигурируемостью несколько сложнее. Несмотря на то, что некоторые инструменты позволяют конфигурирование под различные архитектуры, интеграция внешней эталонной модели сопряжена с трудностями. Большинство из перечисленных реконфигурируемых инструментов не используют эталонные модели и не осуществляют контроль корректности построенных программ. Однако даже без необходимости интеграции эталонной модели создание пользовательских конфигураций может иметь значительную трудоемкость.
Целенаправленность тестирования и поддержка многоядерности характеризуют техники генерации и зависят от области применения инструмента. При этом они в той или иной степени связаны с расширяемостью и реконфигурируемость: более гибкие инструменты реализуют большее количество техник генерации и предоставляют больше возможностей.
Т.к. применимость отдельных инструментов ограничена, актуальной задачей является создание инструмента, который позволил бы объединить различные методы генерации, и был бы применим для различных типов микропроцессоров. Подобный инструмент должен сочетать все перечисленные выше свойства. Его характеристики могут быть сформулированы следующим образом.
Реконфигурируемость предполагает описание архитектуры тестируемого микропроцессора в простом, удобном и понятном инженеру-верификатору формате. Расширяемость предполагает, что описания, созданные для одних техник генерации, могут быть использованы другими техниками. Т.к. техники генерации требуют разное количество информации, то для более сложных техник будут требоваться описания, которые дополнят информацию, представленную в описаниях, используемых более простыми. Информацию об архитектуре микропроцессора, используемую рассмотренными инструментами, можно разделить на четыре уровня: (1) формат команд (текстовый и бинарный), (2) семантика команд, (3) организация подсистемы памяти и (4) организация конвейера команд. Один из возможных способов представления этой информации - применение формальных спецификаций. Это позволит использовать единое описание для извлечения ограничений, построения формальных моделей и эталонных эмуляторов. Для решения данной задачи требуется формальный язык, на котором можно в зависимости от потребности описывать различные аспекты архитектуры микропроцессора. Другой вариант решения - использование нескольких языков, расширяющих возможности друг друга.
Еще одна важная характеристика - удобство описания тестовых сценариев. Используемый язык должен быть понятен инженерам-верификаторам. Желательно, чтобы он использовал абстракции цифровой аппаратуры. Он должен позволять описывать сложные тестовые сценарии, использующие комбинации различных техник генерации. Также требования реконфигурируемости и расширяемости предполагают адаптацию к новым архитектурам и добавление новых конструкций. Таким образом, язык должен позволять динамическое добавление и изменение поддерживаемых конструкций.
Глава 2. Автоматизация конструирования генераторов тестовых программ
В данной главе описывается предлагаемый метод автоматизации конструирования генераторов тестовых программ для микропроцессоров. Он предполагает использование формальных спецификаций в качестве источника информации об архитектуре тестируемого микропроцессора. Генерация тестовых программ будет осуществляться на основе шаблонов, разработанных на специальном языке, позволяющем описывать свойства программ в терминах формальных спецификаций и техник генерации, применяемых для удовлетворения заданных свойств. Расширяемая архитектура генераторов позволит интегрировать разные техники генерации. Схема использования инструмента конструирования генераторов тестовых программ, реализующего предлагаемый метод, и генераторов, построенных с его помощью, показана на рисунке 4.
Рисунок 4. Инструмент, реализующий предлагаемый метод, и результат его работы
Глава организована следующим образом. В первом разделе описывается метод автоматизации конструирования генераторов тестовых программ на основе формальных спецификаций. Второй раздел посвящен языку описания шаблонов тестовых программ. В третьем разделе описывается архитектура конструируемых генераторов тестовых программ.
2.1 Метод автоматизации конструирования генераторов тестовых программ
Генераторы тестовых программ используют информацию трех типов: (1) описание архитектуры тестируемого микропроцессора; (2) свойства генерируемых тестовых программ; (3) знание о техниках генерации, применяемых для удовлетворения этих свойств. Для создания генератора, который поддерживал бы любые микропроцессорные архитектуры и позволял бы интегрировать в себе разные техники генерации, необходимо разделение между данными типами информации. При этом архитектура микропроцессора и техники генерации должны быть полностью независимыми друг от друга, а свойства тестовых программ формулироваться на их основе. В таком случае для поддержки новой архитектуры достаточно разработать ее описание, на основе которого можно будет автоматически сконструировать генератор тестовых программ.
Конструируемые генераторы тестовых программ будут состоять из двух частей: (1) модели, содержащей информацию об архитектуре микропроцессора, и (2) ядра, интегрирующего в себе архитектурно-независимые компоненты, реализующие различные техники генерации. При этом ядро является общим для всех конструируемых генераторов. Генерация будет осуществляться на основе шаблонов тестовых программ, задающих их свойства в терминах элементов архитектуры, описываемых моделью, и техник генерации, реализуемых ядром. Обработка тестовых шаблонов осуществляется ядром и состоит в применении той или иной техники генерации для удовлетворения того или иного свойства.
2.1.1 Использование формальных спецификаций
Для конструирования модели микропроцессора необходимо описание его архитектуры. Разработка подобных описаний будет осуществляться инженерами-верификаторами и не должна требовать знания языков программирования и понимания особенностей реализации конструируемых генераторов тестовых программ. Формат описаний должен быть интуитивно понятен и построен на абстракциях цифровой аппаратуры. Так как полная информация об архитектуре микропроцессора содержится в руководстве по микропроцессору и другой проектной документации, логичным видится использование формальных спецификаций, основанных на этой документации.
Различные техники генерации требуют информацию об архитектуре микропроцессора разного уровня детализации. Практически всем техникам необходима информация о системе команд (их синтаксис и семантика). Кроме этого техникам, ориентированным на создание нацеленных тестов для проверки определенных аспектов функциональности, требуется знание об особенностях микроархитектуры (организация подсистемы памяти и конвейера команд). Т.к. информация об особенностях микроархитектуры используется лишь некоторыми техниками, для каждой из которых она может иметь свой формат, основная роль отводится спецификациям системы команд. Спецификации микроархитектуры будут служить в качестве дополнительного источника знания. При этом они не должны дублировать уже имеющиеся описания.
2.1.2 Описание архитектуры микропроцессора на языке nML
Для создания формальных спецификаций хорошо подходят языки описания архитектуры (ADL-языки) [29, 71]. Они позволяют описывать поведенческие и структурные свойства микропроцессора, абстрагируясь от деталей реализации. Эти языки часто используются для моделирования в процессе проектирования микропроцессора. В этом случае созданные описания могут быть повторно использованы для конструирования генераторов тестовых программ.
По характеру описываемых свойств ADL-языки принято разделять на две группы: структурные и поведенческие. Языки первой группы ориентированы на специфицирование микроархитектуры (примером такого языка является MIMOLA). Вторая группа концентрируется на описании системы команд микропроцессора (к этой категории можно отнести ISDL и nML). Кроме того, существуют смешанные языки, сочетающие возможности языков обеих групп (например, LISA и EXPRESSION). Для спецификации архитектуры наиболее подходят поведенческие ADL-языки, позволяющие явно описывать синтаксис и семантику команд. Из нескольких поведенческих и смешанных ADL-языков, таких как LISA, EXPRESSION, ISDL и nML, был выбран последний. Данный язык обладает интуитивно понятным синтаксисом, имеет доступную документацию и используется в нескольких зарубежных университетах и коммерческих компаниях.
Язык nML [72] был разработан в начале 1990-х гг. в Берлинском техническом университете (Technische Universitдt Berlin) и изначально предназначался для создания ассемблеров, дизассемблеров, программных эмуляторов и настраиваемых компиляторов. В середине 1990-х гг. в компании Cadence проводились исследования по созданию на основе nML-спецификаций программного инструментария, включавшего все перечисленные средства, для совместной разработки программного и аппаратного обеспечения [73]. С конца 1990-х гг. nML активно используется Target Compiler Technologies [74] для решения таких задач, как конструирование эмуляторов, компиляторов и RTL-моделей. Эта компания расширила язык nML средствами моделирования конвейера [29]. Другая версия языка nML была разработана в Индийском технологическом институте Канпур (Indian Institute of Technology Kanpur) и получила название Sim-nML [75]. В язык были добавлены средства описания ресурсов (модулей) микропроцессора и модели их использования при выполнении инструкций. В Исследовательском институте информатики в Тулузе (Institut de Recherche en Informatique de Toulouse) для создания эмуляторов микропроцессоров применяется язык nMP, основанный на Sim-nML [76, 77].
С целью упрощения создания спецификаций было решено использовать первоначальную редакцию языка nML, возможности которой ограничиваются описанием синтаксиса и семантики команд. Для специфицирования микроархитектуры предполагается использование дополнительных формальных языков.
Рассмотрим более подробно возможности языка nML. Данный язык основан на атрибутной грамматике и позволяет описать «программистскую» модель системы команд микропроцессора. Спецификации на nML включают описания следующих сущностей: типы данных, константы, регистры, режимы адресации, команды, память и временные переменные.
Типы данных позволяют описывать знаковые и беззнаковые целые числа произвольной длины и числа с плавающей точкой в формате, описанном в стандарте IEEE 754 [60]. В примере 1 приведены объявления типов данных из спецификации архитектуры MIPS64 [47].
Пример 1. Типы данных MIPS64
|
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: |
type BIT = card(1) type BYTE = card(8) type HWORD = card(16) type WORD = card(32) type DWORD = card(64) type QWORD = card(128) type SHORT = int(16) type INT = int(32) type LONG = int(64) type FLOAT32 = float(23, 8) type FLOAT64 = float(52, 11) |
Беззнаковые целочисленные типы размером 1, 8, 16, 32, 64 и 128 бит Знаковые целочисленные типы размером 16, 32 и 64 бита Типы с плавающей точкой одинарной и двойной точности |
Константы задаются как целые числа неопределенного размера, которые приводятся к нужному типу в зависимости от контекста.
Регистровые файлы описываются в виде массивов переменных, доступ к которым осуществляется при помощи режимов адресации. Это специальные абстракции, которые инкапсулируют логику обращения к элементам массива, а также задают ассемблерный (атрибут syntax) и двоичный (атрибут image) форматы регистров. Например, регистры общего назначения микропроцессора MIPS64 и режим адресации для доступа к ним можно описать следующим образом:
Пример 2. Регистры общего назначения MIPS64
|
01: 02: 03: 04: |
reg GPR [32, WORD] mode R (i: card(5)) = GPR[i] syntax = format("$%d", i) image = format("%5b", i) |
Регистровый файл Режим адресации Ассемблерный формат Двоичный формат |
Физическая память микропроцессора описывается так же, как и регистры, в виде массива. В приведенном ниже фрагменте спецификации массив M интерпретируется как физическая память, состоящая из 230 32-битных слов (или 232 байт). nML не предоставляет средств описания механизмов виртуальной памяти, таких как трансляция адресов и кэширование. При обращении к памяти предполагается, что физический адрес равен виртуальному адресу.
Пример 3. Массив физической памяти
|
01: |
mem M [2 ** 30, WORD] |
Физическая память |
Помимо регистров и памяти, в nML можно объявлять временные переменные для хранения промежуточных результатов вычислений. Например, ниже объявлена переменная 33-битная целочисленная temp33, используемая для хранения результатов арифметических операций, при которых возможно переполнение.
Пример 4. Временная переменная
|
01: |
var temp33[int(33)] |
Временная переменная |
Команды специфицируются в виде иерархической структуры операций, описывающих отдельные части логики. Логика, общая для всех команд (например, обновление значения счетчика команд), помещается в корневой узел. Операции, уникально характеризующие отдельные команды, помещаются в терминальных узлах. Эти операции принимают в качестве параметров режимы адресации, которые описывают входные и выходные параметры команды. Операции содержат три атрибута: action, syntax и image. Первый описывает логику работы команд в терминах присваивания значений регистров, а остальные два задают ассемблерный и двоичный форматы соответственно. Например, спецификация команды ADD микропроцессора MIPS64 выглядит следующим образом:
Пример 5. Спецификация команды ADD архитектуры MIPS64 на языке nML
|
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: |
op add (rd: R, rs: R, rt: R) syntax = format("add %s, %s, %s", rd.syntax, rs.syntax, rt.syntax) image = format("000000%5s%5s%5s00000100000", rs.image, rt.image, rd.image) action = { if sign_extend(WORD, rs<31>) != rs<63..32> || sign_extend(WORD, rt<31>) != rt<63..32> then unpredicted; endif; temp33 = rs<31>::rs<31..0> + rt<31>::rt<31..0>; if temp33<32> != temp33<31> then exception("IntegerOverflow"); else rd = sign_extend(DWORD, temp33<31..0>); endif; } |
Данная спецификация разработана на основе описания команды в руководстве по микропроцессору MIPS64 [47], которое имеет следующий вид:
Пример 6. Описание семантики команды ADD из руководства по архитектуре MIPS64
|
01: 02: 03: 04: 05: 06: 07: 08: 09: |
if NotWordValue(GPR[rs]) or NotWordValue(GPR[rt]) then UNPREDICTABLE endif temp < (GPR[rs]31||GPR[rs]31..0) + (GPR[rt]31||GPR[rt]31..0) if temp32 ? temp31 then SignalException(IntegerOverflow) else GPR[rd] < sign_extend(temp31..0) endif |
nML позволяет объединять режимы адресации и операции в группы. Использование группы в объявлении означает, что в этом месте применим любой из ее элементов. В примере 7 показаны группы арифметических операций над 32-битными числами из системы команд MIPS64.
Пример 7. Группы арифметических операций над 32-битными числами системы команд MIPS64
|
01: 02: 03: 04: 05: |
op Mips32ArithmeticRR = clo | clz | div | divu | madd | maddu | multu | mult | msub | msubu op Mips32ArithmeticRRR = add | addu | div_reg | mod_reg | divu_reg | modu_reg | sub | subu | mul | mul_reg | muh_reg | muhu_reg | mulu_reg op Mips32ArithmeticRRI = addi | addiu | aui op Mips32ArithmeticOp = Mips32ArithmeticRRR | Mips32ArithmeticRR | Mips32ArithmeticRRI |
Логика обновления счетчика команд, общая для всех команд, описывается как отдельная операция, параметризованная группой, которая включает в себя операции, описывающие логику отдельных команд. В примере 8 показана спецификация операции instruction, которая описывает логику управления счетчиком команд микропроцессора MIPS64 со слотом задержки, и используемых ею переменных.
Пример 8. Описание логики обновления счетчика команд, общей для всех команд архитектуры MIPS64
|
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: |
let PC = "CIA" reg CIA [DWORD] mem BRANCH [BIT] mem NEXTPC [DWORD] var is_delay_slot [BIT] var jump_address [DWORD] op instruction (operation: Op) syntax = operation.syntax image = operation.image action = { is_delay_slot = BRANCH; jump_address = NEXTPC; BRANCH = 0; NEXTPC = 0; operation.action; if is_delay_slot == 1 then CIA = jump_address; else CIA = CIA + 4; endif; } |
Регистр CIA помечен как счетчик команд Регистр, используемый как счетчик команд Переменные слота задержки Временные переменные Группа Op включает все команды MIPS64 Ассемблерный формат наследуется Бинарный формат наследуется Обновление значений переменных Исполнение команды Обновление счетчика команд Переход на произвольный адрес Переход на следующую команду |
Как можно увидеть, операции, реализующие логику отдельных команд, вызываются общей частью. После этого происходит обновление счетчика команд. Счетчик команд или инкрементируется или, если команда осуществляет переход, ему присваивается новый адрес. Адрес перехода передается через глобальную переменную. В примере 9 показана спецификация команды условного перехода BEQ системы команд MIPS64.
Пример 9. Спецификация команды BEQ архитектуры MIPS64 на языке nML
|
01: 02: 03: 04: 05: 06: 07: 08: 09: |
op beq (rs: R, rt: R, offset: SHORT) syntax = format("beq %s, %s, %d", rs.syntax, rt.syntax, offset) image = format("000100%5s%5s%16s", rs.image, rt.image, offset) action = { if rs == rt then BRANCH = 1; NEXTPC = CIA + (sign_extend(DWORD, offset) << 2); endif; } |
Отдельного внимания заслуживают команды доступа к памяти. На языке nML обращения к памяти описываются как доступ к элементам массива физической памяти. При этом физический адрес считается равным виртуальному адресу. В примере 10 показана спецификация команды LD системы команд MIPS64.
Пример 10. Спецификация команды LD архитектуры MIPS64 на языке nML
|
01: 02: 03: 04: 05: 06: 07: 08: |
var temp_address[DWORD] op ld (rt: R, offset: SHORT, base: R) syntax = format("ld %s, %d(%s)", rt.syntax, offset, base.syntax) image = format("110111%5s%5s%16s", base.image, rt.image, offset) action = { temp_address = base + sign_extend(DWORD, offset); rt = MEM[temp_address_load >> 3]; } |
2.1.3 Расширение возможностей языка nML
Для построения тестовых программ, нацеленных на проверку работы подсистемы управления памятью (MMU, memory management unit) микропроцессора, генератору информация о данной подсистеме. Для описания ее конфигурации был предложен специальный язык, получивший название mmuSL [2, 7]. Спецификации подсистемы MMU на данном языке включают в себя описания типов адресов, сегментов памяти, буферов памяти и управляющей логики обработки операций чтения и записи. Подробное описание языка mmuSL и техник генерации тестовых программ для подсистемы MMU на основе формальных спецификаций выходит за рамки данной работы. Однако необходимо пояснить каким образом описание системы команд на языке nML может быть дополнено описанием подсистемы MMU. Как показано в примере 10, на языке nML обращения к памяти специфицируются как доступ к массиву, описывающему физическую память (в данном примере он называется MEM). При этом физический адрес считается равным виртуальному адресу. Для расширения данной схемы можно разработать дополнительные спецификации на языке mmuSL, описывающие механизмы трансляции адресов и кэширования данных. Эти спецификации включают в себя описания логики обработки операций чтения и записи. Данные операции соответствуют операциям чтения и записи в массив памяти, объявленный в nML-спецификациях. Другими словами, при чтении или записи в массив MEM по виртуальному адресу будет задействована соответствующая логика, описанная в mmuSL-спецификациях, которая выполнит трансляцию адреса в физический и осуществит доступ к физической памяти через иерархию буферов.
2.1.4 Архитектура модели микропроцессора
Модель микропроцессора, построенная на основе формальных спецификаций, должна содержать в себе всю информацию, необходимую для генерации тестовых программ для данной архитектуры. При этом доступ к этой информации должен осуществляться независимо от моделируемой архитектуры. Информация об архитектуре микропроцессора требуется генератору тестовых программ для решения следующих задач:
· анализа шаблонов тестовых программ;
· генерации входных данных для команд, вызывающих определенные ситуации в их работе;
· исполнения команд на эталонном эмуляторе;
· печати команд в ассемблерном формате.
Таким образом, конструируемая модель будет включать в себя следующие части: (1) метаданные, описывающие сигнатуры поддерживаемых команд; (2) эмулятор, позволяющий исполнять и печатать команды микропроцессора; (3) модель тестового покрытия, содержащая каталог ситуаций, связанных с командами, и условия их возникновения. Метаданные будут использоваться ядром генератора при анализе шаблонов тестовых программ для распознавания описываемых команд. Запросы к модели на исполнение, печать и получение информации о связанных с командами ситуациях будут также описываться в терминах метаданных. Это позволит организовать ядро генератора в виде набора компонентов, реализующих архитектурно-независимые техники генерации.
Метаданные представляют собой таблицы из поддерживаемых моделью команд, режимов адресации и регистровых файлов. Команды характеризуются именем, списком операндов, набором атрибутов, описывающих их поведенческие свойства и списком связанных с ними тестовых ситуаций. Режима адресации имеют имя, список аргументов и набор поведенческих свойств. Регистровые файлы характеризуются именем, типом данных и количеством элементов.
Эмулятор включает в себя элементы хранения данных (регистры и память) и команды, доступ к которым предоставляется через архитектурно-независимые интерфейсы. Эмулятор позволяет поддерживать несколько копий элементов хранения данных. Это необходимо для моделирования работы многоядерных микропроцессоров и для создания временных контекстов исполнения (для случаев, когда необходимо вернуться к некоторому начальному состоянию). Эмулятор может расширяться компонентом, отвечающим за моделирования работы подсистемы памяти. Исполнение команд на эмуляторе осуществляется пошагово. В любой момент времени можно получить доступ к информации о его текущем состоянии. Схема работы с эмулятором выглядит следующим образом:
· на основе запросов в терминах метаданных, создаются объекты, описывающие вызовы конкретных команд;
· эти команды можно исполнять на одном из ядер эмулятора или печатать в ассемблерном формате;
· команды можно поместить в память эмулятора и считать оттуда;
· эмулятор предоставляет доступ к регистрам на чтение и запись (соответствующие запросы описываются в терминах метаданных);
· для исполнения команд нужно поместить их в память и записать стартовый адрес в регистр, хранящий счетчик команд;
· после этого можно извлекать команды по одной, исполнять их и при этом контролировать состояние регистров и памяти;
· исполнение команд можно осуществлять на разных ядрах и использовать при этом постоянный или временный контексты.
Модель покрытия включает в себя описания тестовых ситуаций в различных форматах. Ситуации, связанные с системой команд, описываются в виде ограничений, выраженных в виде формул, где в качестве переменных выступают аргументы команд. Ситуации, связанные с подсистемой управления памятью, задаются в виде путей на графе, описывающем логику ее работы. Ситуации различных типов не зависят друг от друга и обрабатываются различными компонентами генератора тестовых программ.
2.2 Язык описания шаблонов тестовых программ
Генерация тестовых программ осуществляется на основе шаблонов, которые задают их свойства в абстрактном виде. Для описания шаблонов предложен специализированный язык, который позволяет создавать шаблоны для любых микропроцессорных архитектур и применять расширяемый набор техник генерации для достижения данных свойств. Далее концепции тестовых программ и шаблонов тестовых программ рассмотрены более подробно.
2.2.1 Структура тестовых программ
Тестовая программа представляет собой набор тестовых воздействий, предназначенных для проверки определенных аспектов функциональности микропроцессора. Каждое тестовое воздействие задается в виде последовательности команд, выполнение которых приводит к возникновению некоторых событий в работе микропроцессора, называемых тестовыми ситуациями. Как правило, для этого требуется, чтобы микропроцессор находился в определенном начальном состоянии. Поэтому тестовые воздействия предваряются инициализирующим кодом, который содержит команды, записывающие необходимые значения в регистры и память. После выполнения тестового воздействия может осуществляться проверка корректности полученных результатов. Для этого используются встроенные проверки (self-checks), последовательности команд, сравнивающие значения в регистрах и памяти с эталонными. Тестовое воздействие вместе с инициализирующим кодом и встроенными проверками называют тестовым примером (test case). В простейшем случае тестовые примеры не зависят друг от друга и выполняются последовательно. Однако для решения более сложных задач тестирования может потребоваться выполнение тестовых примеров в произвольном порядке, циклическое выполнение или выполнение на разных ядрах микропроцессора. Для этого в тестовые программы добавляется код диспетчеризации (dispatching code), который содержит команды, осуществляющие переход в другие части программы. При этом тестовые примеры остаются самодостаточными и имеют единственную точку входа, а переход осуществляется между секциями диспетчеризации. Помимо описанных сущностей, каждая тестовая программа включает в себя пролог, который осуществляет начальную инициализацию микропроцессора, и эпилог, который завершает работу программы. Таким образом, структуру тестовых программ можно описать формулой
= start {dispatch start, xi, stop}i=1,n stop
где: start - пролог тестовой программы;
· dispatch - код диспетчеризации;
· start, xi, stop - тестовый пример, включающий в себя:
o start - инициализирующий код;
o xi - тестовое воздействие;
o stop - встроенные проверки;
· stop - эпилог тестовой программы;
· n - число тестовых примеров в программе.
2.2.2 Описываемые свойства тестовых программ
Шаблоны тестовых программ представляют собой абстрактные описания их свойств. При этом на основе одного шаблона может быть построено множество тестовых программ, удовлетворяющих описанным свойствам. Это позволяет обеспечить покрытие всевозможных комбинаций ситуаций в работе микропроцессора.
Свойства тестовых программ, описываемые шаблонами, можно разделить на два типа: (1) структурные и (2) поведенческие. Первые задают способы построения последовательностей команд, составляющих тестовые воздействия, а вторые - ситуации, которые должны возникнуть в процессе их исполнения. Также к структурным свойствам относятся описания пролога, эпилога и кода диспетчеризации. Эти части программ описываются в виде фиксированных последовательностей команд, так как выполняемые ими действия заранее определены.
Рассмотрим более подробно свойства тестовых примеров. Они представляют собой последовательности команд, которые должны обеспечивать покрытие определенных ситуаций в работе микропроцессора. Ситуации могут быть связаны как с отдельными командами, так и с последовательностью в целом. Для достижения целевых ситуаций может потребоваться одновременное выполнение нескольких условий различного типа. Это связано с наличием зависимостей между командами, которые возникают при совместном использовании регистров, памяти и конвейера команд. Для удовлетворения необходимых условий последовательности команд должны быть построены определенным образом. Важно заметить, что гарантировать выполнение всех необходимых условий часто не представляется возможным ввиду сложности реализации и высоких вычислительных затрат. Кроме того т.к. часто физически невозможно предусмотреть все возможные зависимости, существует риск, что некоторые важные тестовые ситуации будут пропущены. Поэтому применяется подход, при котором тестовые воздействия описываются путем комбинирования последовательностей команд, нацеленных на выполнение отдельных условий. При этом создается большое количество тестовых примеров, некоторые из которых не соответствуют требуемым условиям или избыточны, но в целом это дает более достаточно высокое качество покрытия при приемлемой вычислительно сложности. Кроме того такой подход позволяет обеспечить покрытие многих ситуаций в работе микропроцессора, которые трудно предусмотреть и формализовать.
Таким образом, описания тестовых примеров в шаблонах тестовых программ должны задавать свойства следующих типов для генерируемых последовательностей команд:
· способы построения последовательностей команд;
· способы выбора регистров, используемых командами;
· способы комбинирования тестовых ситуаций;
· способы генерации входных данных для команд;
· способы построения инициализирующего кода;
· способы построения встроенных проверок.
Для удовлетворения данных свойств применяются разнообразные техники генерации, реализуемые генератором.
2.2.3 Концепция языка описания шаблонов тестовых программ
Для создания тестовых шаблонов необходим специализированный предметно-ориентированный язык (domain-specific language). Он должен удовлетворять следующим основным требованиям: (1) быть простым и понятным инженерам-верификаторам; (2) быть применим для любых микропроцессорных архитектур; (3) позволять использовать расширяемый набор техник генерации; (4) быть пригодным для использования в промышленных проектах. На основе данных требований и анализа подходов, применяемых на практике, сформулированы следующие требования к реализации такого языка:
...Подобные документы
Применение тестовых заданий на уроках информатики. Основные виды тестовых заданий. Подбор тестовых заданий по темам курса информатики. Программные продукты для разработки и создания тестовых заданий. Общие правила оформления компьютерных тестовых заданий.
курсовая работа [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
