Разработка метода автоматизации конструирования генераторов тестовых программ для микропроцессоров
Функциональная верификация микропроцессоров. Анализаторы формальных спецификаций. Генераторы кода и библиотеки моделирования. Техники генерации тестовых программ. Спецификации архитектуры, язык описания шаблонов. Размещение команд и данных в памяти.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | диссертация |
| Язык | русский |
| Дата добавления | 11.06.2018 |
| Размер файла | 2,7 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
2. На следующем этапе осуществляется построение кода тестовых примеров и встроенных проверок для них. Для того чтобы выбрать обрабатываемый блок, и привести эмулятор в необходимое начальное состояние, на эмуляторе запускается исполнение построенного ранее кода. Исполнение приостанавливается при достижении адреса конца одной из построенных ранее последовательностей команд, за которым отсутствует размещенный код. После этого выбирается блок, который следует за блоком, на основе которого была построена последняя исполняемая последовательность команд. В результате обработки этого блока строится одна или несколько последовательностей команд, которые сразу же размещаются в памяти эмулятора и исполняются. После исполнения каждой из последовательностей, на основе информации о состоянии эмулятора и описаний компараторов строятся встроенные проверки. После обработки блока, выбирается другой, следующий за ним блок. Если этот блок является секцией диспетчеризации, для которой уже был построен код, то этот код размещается в памяти эмулятора и исполняется. После этого выбирается блок, который следует за блоком, на котором остановилось исполнение и процесс повторяется заново.
3. Если моделируемый микропроцессор содержит несколько ядер, то исполнение кода запускается по очереди на разных ядрах. При этом синхронизация между ядрами осуществляется на уровне отдельных последовательностей. При обработке блока, выбирается то ядро, для которого исполнение достигло этого блока. Если таких ядер несколько, то выбирается первое из них.
4. После того, как исполнение дойдет до эпилога, генерация завершается. Если при этом некоторые блоки остались не обработанными, так как не были достигнуты в процессе исполнения, то они обрабатываются, используя текущее состояния эмулятора. При этом построенные последовательности не исполняются. После этого весь построенный код печатается в виде программы на языке ассемблера. Если в процессе исполнения построенного кода на эмуляторе произошли ошибки (зацикливания, переходы по невалидным адресам, нарушения инвариантов и т.д.), генерация прерывается с соответствующим сообщением об ошибке.
Обработка блоков заключается в построении последовательностей команд, которое включает в себя распределение регистров. После этого осуществляется обработка тестовых ситуаций, заданных для команд, в процессе которой генерируются тестовые данные и строится инициализирующий код, размещающий их в регистры и память.
3.2.4 Итератор последовательностей команд
Каждый блок внутреннего представления порождает одну или несколько последовательностей команд. Пролог, эпилог и секции диспетчеризации имеют фиксированную структуру и, поэтому, обрабатываются по упрощенной схеме. Построенные для них последовательности команд полностью соответствуют их описанию в шаблонах.
Блоки тестовых примеров могут порождать множество последовательностей в зависимости от их описания и выбранных стратегий построения последовательностей. За построение последовательностей команд отвечает компонент, называемый итератором последовательностей команд (sequence iterator).
Основная идея реализации этого компонента состоит в следующем. Каждый блок содержит список итераторов по последовательностям команд, описываемых при помощи его структурных элементов. Итератор последовательностей команд применяет к этому списку набор компонентов, при помощи которых на основе элементов списка строит новые последовательности команд. Команды, содержащиеся в блоке, эквивалентны итератору по одной последовательности из одного элемента. Для вложенных блоков строится отдельный итератор на основе их содержимого. Компоненты, применяемые для построения последовательностей, включают в себя: compositor, permutator, combinator, rearranger и obfuscator (описаны во второй главе). Для каждого компонента реализован набор стратегий (также описаны во второй главе), определяющих его поведение, который можно пополнять новыми реализациями. В примере 35 показано, как организована совместная работа перечисленных компонентов и как ним применяются стратегии, определяющие их поведение. Как можно увидеть, одни компоненты обрабатывают результаты работы других. При необходимости эта схема может быть расширена компонентами новых типов. Применяемые стратегии выбираются на основе атрибутов блока, соответствующих именам компонентов.
Пример 35. Код построения итератора последовательностей команд на основе списка итераторов
|
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: |
public Iterator<List<T>> newIterator(final List<Iterator<List<T>>> iterators) { if (isSequence) { return new GeneratorObfuscator<>( new GeneratorSequence<>(iterators), obfuscatorStrategy); } if (isIterate) { return new GeneratorObfuscator<>( new GeneratorRearranger<>(new GeneratorIterate<>(iterators), rearrangerStrategy), obfuscatorStrategy ); } return new GeneratorObfuscator<>( new GeneratorRearranger<>( new GeneratorCompositor<>( new CombinatorPermutator<>(combinatorStrategy, permutatorStrategy), compositorStrategy, iterators), rearrangerStrategy), obfuscatorStrategy ); } |
3.2.5 Распределитель регистров
Регистры, используемые командами построенных последовательностей, могут быть не зафиксированы (то есть их индексы помечены как неизвестные значения). Выбор регистров осуществляется в процессе обработки последовательности команд при помощи компонента, называемого распределителем регистров (register allocator). Этот компонент использует набор стратегий, которые реализуют конкретные способы выбора регистров и имеют следующий интерфейс:
Пример 36. Интерфейс стратегий выбора регистров
|
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: |
public interface AllocationStrategy { <T> T next( final Collection<T> domain, final Collection<T> exclude, final Collection<T> used, final Map<String, String> attributes); <T> T next( final Supplier<T> supplier, final Collection<T> exclude, final Collection<T> used, final Map<String, String> attributes); } |
Стратегии осуществляют выбор номеров регистров на основе следующей информации: (1) множество допустимый значений (domain); (2) множество значений, исключаемых из выбора (exclude); (3) множество значений, которые уже были выбраны (used); (4) набор атрибутов, задающих варианты работы для используемой стратегии (attributes).
Множество выбранных регистров включает в себя все жестко заданные регистры. Для того, чтобы они учитывались при выборе, обработка последовательности осуществляется в два этапа. На первом составляется множество жестко заданных регистров. А на втором на основе этой информации осуществляется выбор регистров, которые не были заданы жестко, путем применения соответствующих стратегий выбора.
Распределитель регистров поддерживает список стратегий, в который можно добавлять новые реализации.
3.2.6 Обработчик последовательностей команд
За генерацию входных данных и построение инициализирующего кода для последовательностей команд отвечает компонент, называемый обработчиком последовательностей команд (sequence processor).
Первая задача, которую он решает, состоит в построении ограничений для тестовых ситуаций, связанных с командами. Ограничения, используемые для описания тестовых ситуаций различного типа, имеют разный формат. Поэтому для обработки тестовых ситуаций каждого типа используется отдельный компонент, называемый генератором ограничений (constraint generator). Он просматривает последовательности команд и строит ограничения для связанных с ними тестовых ситуаций определенного типа. При этом для одной и той же тестовой ситуации может быть построено несколько вариантов ограничений. Перед обработкой генераторами ограничений последовательности команд разделяются: для каждого генератора выбираются команды определенного типа. В процессе обработки переданной ему последовательности генератор ограничений обращается к модели тестового покрытия. Результатом его работы являются последовательности команд, аннотированные ограничениями, построенными для заданных тестовых ситуаций. Каждая последовательность содержит уникальную комбинацию ограничений. На основе последовательностей, возвращаемых генераторами ограничений, строятся уточненные последовательности команд, которые описывают тестовые воздействия. Для этого при помощи комбинатора, заданного в шаблоне, строятся комбинации из исходных последовательностей, которые затем конкатенируются. Схема построения ограничений для последовательности команд показана на рисунке 24.
Рисунок 24. Схема построения ограничений для последовательности команд
На основе построенных ограничений осуществляется генерация входных данных для команд, на основе которых затем строится инициализирующий код. В процессе генерации осуществляется исполнение обрабатываемых команд на эмуляторе. Это необходимо, чтобы обеспечить обработку команд в соответствии с порядком их исполнения и использовать информацию о состоянии эмулятора при разрешении ограничений. За исполнение команд отвечает компонент, называемый исполнителем последовательностей команд (sequence executor). За генерацию данных и построение инициализирующего кода отвечает генератор данных (data generator). Эти компоненты подробно рассматриваются в следующих подразделах.
3.2.7 Исполнитель последовательностей команд
Эмулятор, реализованный моделью микропроцессора, предназначен для исполнения отдельных команд. Исполнением целых последовательностей команд управляет компонент, называемый исполнителем последовательностей команд (sequence executor). Он может работать в двух режимах: (1) исполнение последовательности команд с целью обновления состояния эмулятора и (2) исполнение последовательности команд с целью генерации для нее данных и построения инициализирующего кода. В первом случае используется постоянный контекст эмулятора, во втором - временный. Общая схема исполнения последовательности команд состоит из следующих шагов:
1. последовательность команд размещается в памяти эмулятора;
2. создается точка остановки (breakpoint), соответствующая конечному адресу последовательности;
3. в счетчик команд записывается начальный адрес последовательности;
4. из памяти эмулятора извлекается команда, соответствующая счетчику команд;
5. команда исполняется, обновляя значение счетчика команд;
6. если достигнута точка остановки, исполнение приостанавливается, в противном случае повторяется шаг 4.
В режиме генерации данных в эту схему добавляется дополнительный шаг. Перед исполнением команды (шаг 5) проверяется было ли обработано связанное с ней ограничение. Если оно еще не было обработано, то осуществляется генерации данных и построение инициализирующего кода. При этом построенный код размещается в память (следом за последовательностью) и исполняется. После этого счетчику команд присваивается адрес выбранной ранее команды и эта команда исполняется.
Исполняемые команды могут быть описаны при помощи шаблона в явном виде или они могут быть описаны в виде блока данных, на который передается управление. В первом случае для них строятся соответствующие исполняемые объекты, которые кэшируются и используются при каждом обращении. Во втором случае объект исполняемой команды строится при первом вызове команды при помощи декодера, встроенного в эмулятор.
3.2.8 Генератор данных
Обработка ограничений осуществляется при помощи компонента, называемого генератором данных (data generator). Он решет две следующих задачи:
· разрешения ограничения с целью генерации данных определенного вида;
· построения инициализирующего кода на основе этих данных.
Задача разрешения ограничений решается следующим образом. За разрешение каждого типа ограничений отвечает отдельный компонент, называемый решателем ограничений (constraint solver). Решатели ограничений регистрируется в специальном каталоге, реализованном системой TestBase (разработана в ИСП РАН) [96] . Данная система обрабатывает запросы на генерацию данных, выбирая подходящий решатель ограничений. Таким образом, реализация генератора данных не зависит от типов поддерживаемых им решателей ограничений. Запрос к системе TestBase содержит в себе: имя команды, список ее аргументов (фиксированных и неизвестных), имя используемого решателя и описание ограничения (идентификатор и дополнительные атрибуты). Список поддерживаемых типов ограничений включает в себя:
· ограничения на значения выходных аргументов (случайные значения из заданного диапазона, значения особого вида);
· ограничения на ситуации в работе операций арифметики с плавающей точкой;
· ограничения на пути исполнения команд (на основе nML-спецификаций);
· ограничения на сценарии обработки запросов к памяти (на основе mmuSL-спецификаций);
· ограничения на трассы исполнения в структуре переходов для команд ветвления.
Реализация решателя ограничений зависит от типа ограничения. Решатели ограничений, описанных при помощи модели тестового покрытия (на основе nML- и mmuSL-спецификаций), реализуют логику взаимодействия с соответствующими компонентами этой модели. Например, для решения ограничений на пути исполнения команд, описанных в виде SMT-формул, используются внешние SMT-решатели, такие как Z3 [97] и CVC4 [98]. Логика работа с этими решателями реализуется библиотекой Fortress [84], которая использует общий интерфейс для всех SMT-решателей, что делает компоненты генератора данных независимыми от внешних инструментов.
После того, как были сгенерированы данные, необходимо сгенерировать код, размещающий их в регистрах и памяти. Решение этой задачи возлагается на компоненты, называемые построителями инициализирующего кода (initializer maker). Они обеспечивают построение инициализирующего кода для данных определенного формата. Формат данных зависит от типа ограничения. При этом несколько разных решателей ограничений могут использовать один и тот же формат данных. При построении кода осуществляется поиск препаратора соответствующего типа, который должен быть объявлен в шаблоне. После этого по его образу и подобию строится код, который использует номера регистров, значения непосредственных аргументов, также блоки данных, соответствующие результатам решения ограничения.
3.2.9 Построитель встроенных проверок
За построение встроенных проверок для последовательностей команд, описывающих тестовые воздействия, отвечает компонент, называемый построителем встроенных проверок (self-check maker). Для решения этой задачи он использует информацию о состоянии микропроцессора, получаемую их эмулятора, и компараторы, описанные в шаблонах тестовых программ. Построитель встроенных проверок работает следующим образом. Он просматривает последовательность команд и составляет множество используемых ею регистров. После этого для каждого регистра создается код встроенной проверки, основанной на описании соответствующего компаратора, и эталонного значения, полученного из эмулятора.
3.3 Расширяемость инструмента MicroTESK
Под расширяемостью понимается возможность интегрировать в генератор тестовых программ компоненты, реализующие новые техники генерации. Техники генерации могут быть реализованы одним независимым компонентом или группой связанных компонентов, совместно решающих общую задачу. При помощи независимых компонентов решаются следующие задачи:
· построение последовательностей команд (комбинаторы, пермутаторы, композиторы, перегруппировщики и обфускаторы);
· выбор регистров (стратегии распределения регистров).
Также, при выполнении указанных условий, при помощи независимого компонента можно решить следующие задачи:
· построение ограничений (если для них могут использоваться существующие решатели);
· разрешение ограничений (если при этом не требуется дополнительная информация о тестовом покрытии и построители инициализирующего кода нового типа);
· построение инициализирующего кода (при условии использования существующих решателей ограничений и типов данных);
· построение кода встроенных проверок (на основе имеющейся информации о состоянии микропроцессора).
Разработка группы связанных компонентов требуется в случаях, когда необходимо добавить поддержку новых типов ограничений. Компоненты, которые необходимо будет разработать, включают в себя:
· транслятор формальных спецификаций или его компоненты, отвечающие за извлечение ограничений и построение модели покрытия на их основе;
· библиотеки для моделирования новых свойств архитектуры микропроцессора;
· генератор ограничений;
· решатель ограничений;
· построитель инициализирующего кода (включая средства расширения языка описания шаблонов).
Перечисленные компоненты объединяются в расширения. Там образом для решения задачи поддержки новых типов ограничений, необходимо разработать расширение, включающее набор перечисленных компонентов. Примером разработки такого набора компонентов является поддержка генерации тестов для подсистемы памяти, использующая формальные спецификации на языке mmuSL.
Выводы
Инструмент MicroTESK использует предложенный метод для конструирования генераторов тестовых программ с предложенной архитектурой, осуществляющих генерацию на основе шаблонов на предложенном языке. Данный инструмент позволяет применять расширяемый набор техник генерации к широкому спектру микропроцессорных архитектур. Расширение возможностей инструмента осуществляется путем разработки новых компонентов.
Глава 4. Результаты практического применения
В данной главе описывается опыт практического применения инструмента, реализующего предложенный метод автоматизации конструирования генераторов тестовых программ. Инструмент был применен для создания генераторов тестовых программ для архитектур MIPS64, ARMv8, PowerPC и RISC-V. На основе анализа полученного опыта делается вывод о соответствии полученных результатов поставленным целям.
4.1 Генератор тестовых программ для архитектуры MIPS64
При помощи инструмента, реализующего предложенный метод, был сконструирован генератор тестовых программ для архитектуры MIPS64 [47] и ее разновидности Комдив64 [100]. Созданный генератор применяется в НИИСИ РАН для тестирования микропроцессора Комдив64. Особенности архитектуры MIPS64 и опыт разработки ее формальных спецификаций подробно рассмотрены в следующих подразделах.
4.1.1 Архитектура MIPS64
MIPS - это микропроцессорная архитектура, основанная на концепции проектирования RISC (reduced instruction set computer - «компьютер с сокращённым набором команд»), которая была разработана компанией MIPS Technologies (принадлежит компании Imagination Technologies [101] с 2013 года). За последние десятилетия было разработано множество версий данной архитектуры включая MIPS I, MIPS II, MIPS III, MIPS IV, MIPS V, MIPS32 и MIPS64. В настоящее время актуальными являются MIPS32 (32-битная версия) и MIPS64 (64-битная версия). Архитектура MIPS получила широкое распространение на рынке встраиваемых систем (компьютерные сети, телекоммуникации, игровые приставки, принтеры, цифровые камеры, карманные персональные компьютеры, и т.п.). Среди производителей электроники, использующих данную архитектуру, NEC, Philips и Toshiba. Из отечественных компаний, микропроцессоры, основанные на архитектуре MIPS, разрабатываются в НИИСИ РАН, «ЭЛВИС» и «Байкал Электроникс». Эти микропроцессоры находят свое применение в военной и космической отраслях [100, 102].
4.1.2 Спецификации архитектуры MIPS64
Архитектура MIPS64 описывается в руководстве «MIPSTM Architecture For Programmers», включающем три тома [47, 103, 104], общий объем которых составляет примерно 1000 страниц. Система команд MIPS64 включает всего около 270 команд различного типа. Всю совокупность команд можно разбить на следующие группы:
· арифметико-логические операции (целочисленная арифметика, логические операции, сдвиги, пересылка данных, пустые команды);
· команды ветвления (условные и безусловные переходы);
· команды доступа к памяти (запись и чтение различных типов данных);
· операции с плавающей точкой (арифметика, пересылка данных, преобразование типов, ветвления).
· системные команды (исключения, пересылка данных системного сопроцессора CP0, обращения к буферам памяти, системные вызовы).
Команды имеют фиксированный размер 32-бита. Микропроцессоры MIPS64 используют слот задержки размером 4 байта. Архитектура MIPS64 определяет 32 64-битных регистра общего назначения (General Purpose Registers, GPRs), специальный 64-битный регистр для хранения значения счетчика команд (Program Counter, PC) и пару специальных регистров HI и LO для хранения результатов умножения и деления. Кроме того для модуля арифметики с плавающей точкой определены 32 регистра общего назначения (Floating Point General Purpose Registers, FPRs) размером 64-бит и 32 контрольных регистра (Floating Point Control Registers, FCRs) размером 32-бита для хранения флагов, выставляемых операциями с плавающей точкой. Помимо этого определены специальные регистры для сопроцессора CP0, предназначенные для хранения данных, используемых системными вызовами. Все регистры MIPS64 и около 90% команд были специфицированы на языке nML. В приведенном ниже примере демонстрируется описание регистров общего назначения, режима адресации для доступа к ним и команды целочисленного сложения.
Пример 37. Спецификация регистров общего назначения и команды ADD архитектуры 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: 26: |
// Тип данных для двойного слова type DWORD = card(64) // Регистры общего назначения (32 двойных слова) reg GPR [32, DWORD] // Временная переменная для хранения промежуточных результатов var temp33[card(33)] // Режим адресации для доступа к регистрам общего назначения mode R (i: card(5)) = GPR[i] syntax = format("r%d", i) image = format("%5s", i) // Команда сложения с переполнением 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; } |
Помимо спецификаций системы команд, была разработана формальная спецификация подсистему управления памятью на языке mmuSL. Данная спецификация включает в себя описание буферов трансляции адреса JTLB и DTLB, буферов кэш-памяти L1 и L2, сегментов kseg0, kseg1, xkphys и useg, а также логики обработки операций чтения и записи. В примере 38 показан фрагмент описания логики обработки операции чтения подсистемой памяти MIPS64.
Пример 38. Фрагмент описания логики обработки операции чтения подсистемой памяти MIPS64
|
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: |
mmu MMU (va: VA) = (data: DATA_SIZE) var pa: PA; var line: DATA_SIZE; var l1Entry: L1.entry; read = { pa = TranslateAddress(va); // Трансляция адреса if IsCached(pa.cca) == 1 then if L1(pa).hit then // Обращение к L1 l1Entry = L1(pa); line = l1Entry.DATA; else line = MEM(pa); l1Entry.TAG = pa.paddress<...>; // Обновление L1 l1Entry.DATA = line; L1(pa) = l1Entry; endif; else line = MEM(pa); endif; data = line; } write = { … } |
Трудоемкость специфицирования архитектуры MIPS64 составила около 4 человеко-месяцев. Всего было описано 235 команд и структура подсистемы памяти. Размер разработанных спецификаций составил 3999 строк для системы команд (nML) и около 267 строк для подсистемы памяти (mmuSL). В таблице 5 приведены сведения о специфицированных командах.
Таблица 5. Статистика по специфицированным командам MIPS64
|
Класс команд |
Число специфицированных команд |
|
|
Целочисленная арифметика |
48 |
|
|
Битовый сдвиг и поворот |
22 |
|
|
Логические операции |
11 |
|
|
Проверка условий |
6 |
|
|
Ветвления |
38 |
|
|
Перемещения данных |
10 |
|
|
Работа с памятью |
11 (из 26) |
|
|
Операции с плавающей точкой |
51 (из 65) |
|
|
Исключения |
14 |
|
|
Системные |
24 (из 30) |
|
|
Всего |
235 (из 270) |
4.1.3 Генерация тестовых программ для архитектуры MIPS64
Для генератора тестовых программ для архитектуры MIPS64 были разработаны шаблоны тестовых программ, демонстрирующие его возможности. Всего было разработано около 30 шаблонов. Тестовые сценарии, описанные при помощи этих шаблонов, включают в себя:
· детерминированные тесты для команд целочисленной арифметики;
· случайные тесты для команд целочисленной арифметики;
· комбинаторные тесты на различные ситуации в работе команд целочисленной арифметики, описанные при помощи ограничений;
· тесты со встроенными проверками для команд целочисленной арифметики;
· тесты для операций с плавающей точкой (комбинаторные и на основе ограничений);
· комбинаторные тесты на команды ветвления (перебор трасс исполнения);
· комбинаторные тесты для команд доступа к памяти (комбинации различных сценариев обработки запросов к памяти, построенных путем разрешения ограничений);
· комбинированные тесты на команды целочисленной арифметики и ветвления, основанные на разрешении ограничений.
Таким образом, можно сделать заключение, что построенный генератор позволяет комбинировать различные техники генерации и пригоден для использования в промышленных проектах.
4.2 Генератор тестовых программ для архитектуры ARMv8
При помощи инструмента, реализующего предложенный метод, был сконструирован генератор тестовых программ для архитектуры ARMv8. В настоящее время он успешно применяется в известной международной компании, разрабатывающей собственные микропроцессоры архитектуры ARMv8. Особенности данной архитектуры и опыт разработки ее формальных спецификаций подробно рассмотрены ниже.
4.2.1 Архитектура ARMv8
ARM (изначально Acorn RISC Machine, сейчас Advanced RISC Machine) это семейство микропроцессорных архитектур, разработанных в одноименной компании [105]. Микропроцессоры этого семейства чрезвычайно популярны: с 1990 года было выпущено более 86 миллиардов чипов [106]; 95% смартфонов базируются на ARM (данные за 2010 год) [107]; микросхемы ARM находят применение во встроенных системах и центрах обработки данных. Разработкой ARM-совместимых ядер занимается не только ARM, но и другие компании, включая Qualcomm, Apple, Samsung, NVIDIA и Huawei [108]; очевидно, что эффективная реализация микропроцессора есть важнейший инструмент конкурентной борьбы. Новая архитектура ARMv8(-A) отличается большим числом команд (около 1000) и сложной организацией виртуальной памяти (VMSA, Virtual Memory System Architecture) [109].
4.2.2 Спецификации архитектуры ARMv8
Архитектура ARMv8 описывается в руководстве «ARM Architecture Reference Manual» [109], объем которого составляет примерно 4000 страниц. Описание включает архитектурные особенности (уровни исключений и т.п.), систему команд (около 1000 команд разных типов) и организацию подсистемы памяти. Всю совокупность инструкций можно разбить на следующие группы:
· команды ветвления (условные и безусловные переходы, исключения, возврат из обработчика исключений);
· команды загрузки и сохранения данных (обычные загрузки/сохранения для различных типов данных, загрузки/сохранения с блокировками);
· вычислительные команды (инициализация регистров, целочисленная арифметика и арифметика с плавающей точкой);
· векторные команды (SIMD -- Single Instruction, Multiple Data),
· системные команды (работа с системными регистрами).
Состояние микропроцессора (точнее, одного его ядра) описывается набором значений регистров, соответствующих текущему уровню исполнения команд (EL -- Exception Level). Всего поддерживается четыре уровня, переключение между которыми осуществляется специальными системными командами:
· EL0 -- уровень пользовательских приложений (непривилегированное исполнение);
· EL1 -- уровень ядра операционной системы (привилегированное исполнение);
· EL2 -- уровень гипервизора;
· EL3 -- уровень защищенного монитора.
Архитектурой определены следующие регистры:
· R0-R30 -- 64-битные регистры общего назначения (с доступом ко всем 64 битам или только к младшим 32);
· SP -- указатель стека текущего EL;
· PC -- счетчик команд (недоступный программно);
· V0-V31 -- 128-битные регистры для хранения чисел с плавающей точкой (с поддержкой разных форматов и возможностью векторной интерпретации одного регистра);
· FPCR и FPSR -- контрольный и статусный регистры для операций над числами с плавающей точкой;
· несколько сотен системных регистров.
Ниже в качестве иллюстрации приведено описание команды MOVZ (Move Wide with Zero), перемещающей 16-битные данные в регистр и обнуляющей 48 оставшихся битов, на языке nML.
Пример 39. Спецификация команды MOVZ архитектуры ARMv8
|
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: 26: 27: 28: |
// Константы, соответствующие разным режимам перемещения let MoveWideOp_N = 0b00 // Перемещение с инверсией всех битов let MoveWideOp_Z = 0b10 // Перемещение с обнулением остальных битов let MoveWideOp_K = 0b11 // Перемещение без изменения остальных битов // Общая операция (функция) для команд перемещения 16-битных данных op MovWideImmGeneral (rd: REG, imm: HWORD, shift: card(2), opcode: card(2)) action = { // Учет режима перемещения (обнуление битов) if opcode != MoveWideOp_K then rd = 0; endif; // Выбор поля регистра для записи if shift == 0 then rd<15..0> = imm; elif shift == 1 then rd<31..16> = imm; elif shift == 2 then rd<47..32> = imm; elif shift == 3 then rd<63..48> = imm; endif; // Учет режима перемещения (инверсия битов) if opcode == MoveWideOp_N then rd = ~rd; endif; } // Команда перемещения 16-битных данных с обнулением остальных битов op movz (rd: REG, imm: HWORD, shift: card(2)) // Ассемблерный синтаксис syntax = format("movz %s, #0x%x, LSL #%d", rd.syntax, imm, coerce(BYTE, shift) * 16) // Двоичный формат image = format("%s10100101%2s%16s%5s", coerce(BIT, 1), shift, imm, rd.image) // Совершаемые командой действия action = { MovWideImmGeneral(rd, imm, shift, MoveWideOp_Z).action; } |
Описание виртуальной памяти ARMv8 (VMSAv8-64) занимает около 600 страниц. Значительная его часть посвящена механизму трансляции адресов. В VMSAv8-64 определены четыре режима трансляции: защищенный EL3, незащищенный EL2, EL1&0 в защищенном и незащищенном вариантах. Оба варианта режимов ELl&0 состоят в традиционном преобразовании виртуального адреса в физический. Режимы EL3 и EL2 включают два этапа: сначала виртуальный адрес преобразуется в промежуточный физический, а затем промежуточный физический адрес -- в физический. Каждое преобразование вызывает обход таблиц трансляции и может привести к четырем дополнительным обращениям к памяти. Для ускорения этого процесса таблицы трансляции кэшируются в ассоциативном буфере трансляции (TLB, Translation Lookaside Buffer).
Формальные спецификации подсистемы памяти были разработаны на языке mmuSL. Были специфицированы TLB, таблицы трансляции, двухуровневая кэш-памяти и логика обработки запросов к памяти во всех режимах. В приведенном ниже примере описывается тип виртуального адреса. Описание представляет собой структуру, содержащую адрес и дополнительные данные о запросе к памяти.
Пример 40. Описание типа адреса для архитектуры VMSAv8-64
|
01: 02: 03: 04: 05: 06: |
address VA ( // Виртуальный адрес addr : 64, // Дополнительные данные acctype: 4, iswrite: 1, wasaligned: 1, size: 6 ) |
Сегменты памяти задают отображение диапазона адресов некоторого типа на множество адресов другого типа. В следующем примере описан сегмент VA_LO_UNMAPPED, преобразующий виртуальные адреса в физические напрямую (без использования TLB и таблиц трансляции).
Пример 41. Описание типа адреса для архитектуры VMSAv8-64
|
01: 02: 03: 04: 05: |
segment VA_LO_UNMAPPED (va: VA) = (pa: PA) // Диапазон отображаемых виртуальных адресов range = (0x0000000000000000, 0x0000ffffFFFFffff) // Способ преобразования виртуальных адресов в физические read = { pa.addrdesc.paddress.physicaladdress = va.vaddress<47..0>; } |
Ниже приведен фрагмент спецификации буфера TLB. Данный буфер отображается на регистры и доступен из спецификаций системы команд.
Пример 42. Описание буфера TLB архитектуры VMSAv8-64
|
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: |
register buffer TLB (va: VA) // Ассоциативность ways = 64 // Число множеств sets = 1 // Формат записи entry = (addr: 36, nG: 1, contiguous: 1, level: 2, blocksize: 64, perms: Permissions, addrdesc: AddressDescriptor) // Предикат, проверяющий попадание в буфер match = (addr == va.addr<47..12> && addrdesc.fault.type == Fault_None) // Политика вытеснения данных policy = LRU |
Таблица трансляции описывается как буфер, отображаемый на память. Таким образом, обращения к ней вызывают «рекурсивный» доступ в память. Описание таблицы трансляции показано в приведенном ниже примере.
Пример 43. Описание таблицы трансляции VMSAv8-64
|
01: 02: 03: |
memory buffer TranslationTable(va: VA) entry = (IGNORED: 9, XN: 1, PXN: 1, Contiguous: 1, RES0: 4, pa: 36, nG: 1, AF: 1, SH: 2, AP: 2, NS: 1, AttrIndx: 3, page: 1, valid: 1) |
Логика загрузки и сохранения данных описывается запросами к сегментам и буферам. Ниже приведен фрагмент спецификации подсистемы памяти VMSAv8-64.
Пример 44. Фрагмент описания спецификации подсистемы памяти VMSAv8-64
|
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: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: |
// Управляющая логика подсистемы памяти mmu pmem (va: VA) = (data: 64) var pa: PA; var l1Entry: L1.entry; var line: 256; // Обработка запросов загрузки данных read = { if va.acctype != AccType_PTW then pa.addrdesc = AArch64TranslateAddress(va.vaddress, va.acctype, 0, 1, 8); else pa.addrdesc.paddress.physicaladdress = va.vaddress<47..0>; pa.size = va.size; pa.acctype = va.acctype; endif; if (va.acctype == AccType_AT) then update_PAR_EL1(pa); endif; if L1(pa).hit then l1Entry = L1(pa); line = l1Entry.DATA; else if va.acctype != AccType_PTW && va.acctype != AccType_AT then line = AArch64MemSingleRead(pa.addrdesc, 8, va.acctype, 1); else line = M(pa); endif; l1Entry.TAG = pa.addrdesc.paddress.physicaladdress<47..12>; l1Entry.DATA = line; L1(pa) = l1Entry; endif; data = get_word_from_line(va.vaddress<4..3>, line); if (va.acctype == AccType_IFETCH) then data<47..0> = pa.addrdesc.paddress.physicaladdress; data<63..48> = 0; endif; } // Обработка запросов сохранения данных write = {...} |
Трудоемкость разработки формальных спецификаций микропроцессора ARMv8 составила 30 человеко-месяцев. Всего были описаны 340 основных команд, 217 команд арифметики с плавающей точкой, 249 команд расширения ARMv8.1 и ARMv8.2, 209 команд векторной арифметики SIMD, а также подсистема памяти. В целом были специфицированы все уровни исключений EL0-EL3. Объем кода составил около 18178 строк для системы команд (nML) и около 2643 строк для подсистемы памяти (mmuSL). В таблице 6 приведены сведения о специфицированных командах.
Таблица 6. Статистика по специфицированным командам ARMv8
|
Класс команд |
Число специфицированных команд |
|
|
(1) Передача управления |
12 |
|
|
(2) Сохранение в память и загрузка из памяти |
85 |
|
|
(3) Арифметика с непосредственными операндами |
68 |
|
|
(4) Арифметика с регистровыми операндами |
121 |
|
|
(5) Расширенная арифметика |
22 |
|
|
(6) Арифметики с плавающей точкой |
217 |
|
|
(7) Команды SIMD |
209 (из 477) |
|
|
(8) Системные команды |
32 |
|
|
(a) Расширение v8.1, v8.2 |
249 |
|
|
Всего |
1015 (из 1283) |
4.2.3 Генерация тестовых программ для архитектуры ARMv8
Для генератора тестовых программ для архитектуры ARMv8 были разработаны шаблоны тестовых программ, демонстрирующие его возможности. Для них был разработан базовый Ruby-класс, описывающий все их общие свойства шаблонов для архитектуры ARMv8. В частности, в этот класс были добавлены дополнительные оберточные функции для доступа к регистрам и командам. Это позволило использовать в шаблонах нотацию, максимально приближенную к используемой языком ассемблера для ARMv8. Всего было разработано около 60 шаблонов. Разработанные шаблоны позволяют создавать тесты следующих типов:
· проверка базовой функциональности всех поддерживаемых команд (самые очевидные варианты использования);
· детерминированные тесты для команд целочисленной арифметики (реализации различных алгоритмов);
· случайные тесты для команд целочисленной арифметики (случайные регистры и случайные значения);
· комбинаторные тесты для команд целочисленной арифметики, покрывающие различные комбинации ситуаций в их работе, описанных при помощи ограничений;
· тесты со строенными проверками для команд целочисленной арифметики;
· тесты для операций с плавающей точкой;
· комбинаторные тесты на команды ветвления (перебор трасс исполнения);
· тесты для подсистемы памяти на основе ограничений;
· комбинаторные тесты для команд доступа к памяти (комбинации различных сценариев обработки запросов к памяти, построенных путем разрешения ограничений);
· тесты для команд целочисленной арифметики и доступа к памяти, исполняющие тестовые воздействия на нескольких ядрах микропроцессора;
· комбинированные тесты на команды целочисленной арифметики и ветвления, основанные на разрешении ограничений различных типов.
Как видим, данный генератор позволяет генерировать тестовые программы, предназначенные для тестирования разнообразной функциональности с применением различных техник генерации. Таким образом, можно сделать заключение, что сконструированный генератор удовлетворяет необходимым требованиям для использования его в промышленных проектах.
4.2.4 Проверка корректности генерируемых тестовых программ
При разработке формальных спецификаций архитектуры микропроцессора возможны ошибки. Подобные ошибки могут выражаться в некорректном ассемблерном формате команд или некорректных результатах их исполнения на эмуляторе, встроенном в генератор тестовых программ. Результатом будут тестовые программы, которые не компилируются, приводят к некорректным результатам и не достигают заданных в шаблонах свойств. Для того чтобы избежать подобных проблем, были приняты следующие меры.
В процессе генерации поостренные последовательности команд исполняются на встроенном в генератор эмуляторе, который создает трассы исполнения. Эти трассы фиксируют такие события как исполнение команды, запись в регистр и обращение к памяти. Построенные программы компилируются и исполняются на программном эмуляторе QEMU [110, 111], который создает аналогичные трассы. После этого трассы, созданные обоими эмуляторами, сравниваются. Необходимыми условиями корректности генерируемых программ является их компилируемость, исполнение на эмуляторе QEMU без ошибок и совпадение трасс (имеются в виду основные события).
4.3 Генератор тестовых программ для архитектуры PowerPC
Инструмент, реализующий предложенный метод, был применен для создания генератора тестовых программ для архитектуры PowerPC [112]. Разработанный генератор используется в исследованиях по верификации систем реального времени, использующих микропроцессоры этой архитектуры. Особенности архитектуры PowerPC и опыт разработки ее формальных спецификаций подробно рассмотрены ниже.
4.3.1 Архитектура PowerPC
PowerPC (Performance Optimization With Enhanced RISC - Performance Computing, иногда сокращается как PPC) - это микропроцессорная архитектура, основанная на концепции проектирования RISC, которая была разработана в 1991-м году альянсом компаний Apple, IBM и Motorola (известен как AIM). Микропроцессоры PowerPC использовались в персональных компьютерах компании Apple до конца 2000-х годов. В настоящее время одной из важнейших областей применения микропроцессоров PowerPC является авионика.
4.3.2 Спецификации архитектуры PowerPC
Архитектура PowerPC описывается в руководстве «PowerPC Architecture Book», включающем три тома [113, 114, 115], общий объем которых составляет 433 страницы. Микропроцессоры PowerPC могут работать в двух режимах: 32-битном и 64-битном. При этом поддерживается возможность динамического переключения между режимами. В 32-битном режиме 64-битный микропроцессор может исполнять 32-битный код.
Состояние микропроцессора PowerPC описывается при помощи 32-х регистров общего назначения (GPR0 - GPR31) и такого же количества регистров с плавающей точкой (FPR0 - FPR31). Оба типа регистров имеют размер 64 бита. Кроме этого поддерживаются специальные регистры CR (Condition Register), LR (Link Register), CTR (CounT Register), FPSCR (Floating-point Status and Control Register) и XER (fiXed-point Exception Register).
Команды, поддерживаемые микропроцессорами PowerPC, можно разделить на следующие категории:
· команды перемещения данных (в память, из памяти и между регистрами);
· вычислительные команды целочисленной арифметики (сложение, вычитание, умножение, деление, логические операции, битовые сдвигов и повороты);
· команды сравнения;
· команды ветвления;
· команды операций с плавающей точкой;
· системные команды.
На языке nML было описано небольшое подмножество системы команд PowerPC. Всего было описано 34 команды. Объем кода спецификаций составил 935 строк. Трудоемкость разработки спецификаций составила 1 человеко-месяц. Специфицированные команды включают в себя основные операции целочисленной арифметики, сравнения, ветвления и доступа к памяти.
4.3.3 Генерация тестовых программ для архитектуры PowerPC
Для архитектуры PowerPC были разработаны шаблоны тестовых программ, позволяющие продемонстрировать базовые возможности генератора. На основе созданных шаблонов строятся тесты для проверки базовой функциональности всех описанных команд и строятся случайные тесты со встроенными проверками на операции целочисленной арифметики.
Таким образом, проведенные эксперименты показали, что предложенный метод позволяет сконструировать работоспособный генератор тестовых программ для архитектуры PowerPC.
4.4 Генератор тестовых программ для архитектуры RISC-V
Инструмент, реализующий предложенный метод, был применен для создания генератора тестовых программ для архитектуры RISC-V [116]. Разработанный генератор используется в исследованиях по верификации микропроцессоров с этой архитектурой. Особенности архитектуры RISC-V и опыт разработки ее формальных спецификаций подробно рассмотрены ниже.
4.4.1 Архитектура RISC-V
RISC-V - это открытая микропроцессорная архитектура, основанная на концепции проектирования RISC. Она была создана Университетом Калифорнии в Беркли в 2010-м году, где она применялась в исследовательских и образовательных проектах. В настоящее время развитием данной архитектуры занимается консорциум код названием RISC-V Foundation [117]. Ключевые особенности этой архитектуры - открытость и возможность создания расширений. Создатели RISC-V позиционируют ее как архитектуру широкого спектра применения. Над созданием реализации архитектуры RISC-V работают такие компании как NVIDIA [118] и Samsung [119], а также совместные исследовании в этой области ведутся в Швейцарской высшей технической школе Цюриха и в Болонском университете [120].
4.4.2 Спецификации архитектуры RISC-V
Архитектура RISC-V описывается в руководстве «The RISC-V Instruction Set Manual», состоящем из двух томов [121, 122], общий объем которых составляет 236 страниц. Существует 32-битная и 64-битная версии архитектуры RISC-V, использующие идентичный набор команд. Разница между этими двумя версиями заключается в размере регистров общего назначения и в том, что в 64-битную версию добавляются дополнительные команды для поддержки 32-битных операций. Система команд состоит из базового набора команд и расширений, которые могут быть стандартными и пользовательскими. Различные реализации архитектуры могут поддерживать разные подмножества системы команд. Подмножества системы команд, описанные в руководстве, включают в себя:
· RV32I, базовый набор, который включает в себя общий для 32- и 64-битной версий архитектуры набор команд целочисленной арифметики, ветвления, доступа к памяти и системных вызовов;
· RV64I (дополнение к RV32I), базовый набор, который включает в себя дополнительные 32-битные команды целочисленной арифметики и доступа к памяти для 64-битной версии архитектуры;
· RV32M, стандартное расширение, которое включает в себя целочисленные операции умножения и деления общие для 32- и 64-битной версий архитектуры;
· RV64M (дополнение к RV32M), стандартное расширение, которое включает в себя дополнительные 32-битные команды умножения и деления для 64-битной версии архитектуры;
· RV32A, стандартное расширение, которое включает в себя команды атомарных операций целочисленной арифметики над данными из памяти для 32- и 64-битной версий архитектуры;
· RV64A (дополнение RV32A), стандартное расширение, которое включает в себя дополнительные команды атомарных операций целочисленной арифметики над 32-битными данными из памяти для 64-битной версии архитектуры;
· RV32F, стандартное расширение, которое включает в себя команды арифметики с плавающей точкой одинарной точности и команды конвертации в целочисленный формат общие для 32- и 64-битной версий архитектуры;
· RV64F (дополнение к RV32F), стандартное расширение, которое включает в себя дополнительные команды конвертации в 32-битный целочисленный формат для 64-битной версии архитектуры;
· RV32D, стандартное расширение, которое включает в себя команды арифметики с плавающей точкой двойной точности и команды конвертации в целочисленный формат общие для 32- и 64-битной версий;
· RV64D (дополнение к RV32D), стандартное расширение, которое включает в себя дополнительные команды конвертации в 32-битный целочисленный формат для 64-битной версии архитектуры;
· привилегированные системные команды.
Состояние микропроцессоров с архитектурой RISC-V описывается следующими регистрами: счетчик команд PC размером 32 или 64 бита; 32 регистра общего назначения x0 - x31 размером 32 или 64 бита (RV32I и RV64I); 32 регистра с плавающей точкой одинарной точности f0-f31 размером 32 бита (RV32F и RV64F); 32 регистра с плавающей точкой двойной точности f0-f31 размером 64 бита (RV32D и RV64D); управляющий регистр для операций с плавающей точкой FCSR (Floating-Point Control and Status Register) 32 или 64 бита (RV32F, RV64F, RV32D и RV64D); 12-битные управляющие системные регистры CSR (Control and Status Registers), отображаемые на память, в количестве до 4096.
На языке nML были описаны следующие подмножества системы команд RISC-V: RV32I (около 80%), RV64I, RV32M и RV64M. Тип архитектуры (32 или 65 бита) и задаются при помощи директив препроцессора в коде спецификаций. В приведенном ниже примере демонстрируется описание регистров общего назначения, режима адресации для доступа к ним и команды целочисленного сложения.
Пример 45. Спецификация регистров общего назначения и команды ADDI архитектуры RISC-V
|
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: |
// Тип данных для слова(зависит от конфигурации) #ifdef RV64I let XLEN = 64 #else let XLEN = 32 #endif type XWORD = card(XLEN) // Регистры общего назначения reg XREG [32, XWORD] // Режим адресации для доступа к регистрам общего назначения mode X (i: card(5)) = XREG [i] syntax = format("x%d", i) image = format("%5s", i) // Команда сложения с регистра и 12-битной константы op addi(rd: X, rs1: X, imm: card(12)) syntax = format("addi %s, %s, 0x%x", rd.syntax, rs1.syntax, imm) image = format("%12s%s000%s0010011", imm, rs1.image, rd.image) action = { rd = rs1 + sign_extend(XWORD, imm); } |
Трудоемкость разработки спецификаций составила 0.75 человеко-месяца. Объем кода спецификаций составил 816 строк. Всего было описано 62 команды. В таблице 7 приведены сведения о специфицированных командах.
...Подобные документы
Применение тестовых заданий на уроках информатики. Основные виды тестовых заданий. Подбор тестовых заданий по темам курса информатики. Программные продукты для разработки и создания тестовых заданий. Общие правила оформления компьютерных тестовых заданий.
курсовая работа [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
