Аннотация.
В статье рассматривается интегрированная среда MetaDSP для описания системы команд встраиваемых процессоров. Такое описание включает спецификацию синтаксиса и поведения команд процессора и позволяет автоматически настроить набор кросс-инструментария разработки (ассемблер, дисассемблер, симулятор, отладчик), а также сгенерировать документацию прикладного программиста для целевого процессора. Эти возможности позволяют использовать MetaDSP и соответствующий настраиваемый кросс-инструментарий на этапе дизайна аппаратуры для прототипирования встраиваемых процессоров.
Архитектура системы MetaDSP
Система MetaDSP предназначена для автоматизации описания системы команд встраиваемых процессоров с целью обеспечения последующей автоматической настройки ассемблера, дисассемблера, симулятора, отладчика и генерации документации прикладного программиста. При таком подходе вся необходимая информация содержится в одном месте, а именно в файле описания MetaDSP, что позволяет поддерживать целостность и согласованность этого описания для использования в процессе настройки соответствующих кросс-инструментов. При этом уменьшается количество ошибок, ускоряется процесс внесения изменений и повышается наглядность описания. Эти характеристики очень важны для использования рассматриваемой системы в процессе прототипирования встраиваемых процессоров.
Общая схема форматов описания MetaDSP и их использование для настройки соответствующих кросс-инструментов показаны на рис. 1.
Рис 1. Форматы описаний в системе MetaDSP и их использование
Из файла описания MetaDSP генерируется файл спецификации синтаксиса команд и бинарного кодирования на языке ISE [], который используется для настройки ассемблера, дисассемблера и отладчика, а также декодера симулятора. Основная часть симулятора процессора генерируется из файлов на языке ISE-Exec, в которых определяется поведение каждой инструкции. Документация прикладного программиста для целевой системы команд генерируется из описания MetaDSP в виде документа MS Word.
Таким образом, для различных целей (настройки различных инструментов и генерации документации) требуется свое подмножество общего описания системы команд; при этом эти подмножества имеют различные пересечения. Например, информация о бинарном кодировании команд используется для настройки всех инструментов и для генерации документации. Информация о поведении команд используется только для настройки симулятора и профилировщика, а информация об ассемблерном синтаксисе инструкций - для настройки ассемблера, дисассемблера, отладчика и генерации документации. Использование среды MetaDSP позволяет согласованно вносить изменения в различные части описания системы команд и корректно учитывать эти изменения при настройке всех инструментов.
Ассемблерный синтаксис инструкции
Синтаксис команды задается строковым шаблоном, в котором можно использовать комбинацию статических символов и ссылок на операнды, заключенных в фигурные скобки. Ссылки на операнды должны быть разделены статическим текстом, пробелы не являются значимыми:
IF {cond} XOR {GRs}, {GRt}
Здесь IF, XOR и запятые задают статическую часть синтаксиса команды, а cond, GRs и GRt являются ссылками на операнды. Синтаксис операндов определяется их типом, который задается отдельно для каждого операнда.
Бинарное кодирование инструкции
Бинарное кодирование команды (формат) задается в виде строки вида:
00YY-0000-SSAA-XXXX
Дефисы в этой строке не являются значимыми и используются для косметического разграничения групп битов. Символы 0 и 1 ставятся на местах, которые вместе образуют так называемый код операции (КОП). Символ X означает, что данная битовая позиция не используется (может быть как 0, так и 1). Другие символы обозначают, что на данных местах располагаются коды операндов (в данном примере заданы операнды YY, SS и AA).
Дополнительная информация об инструкции
Дополнительно для каждой команды можно указать:
идентификатор команды; текстовое описание на естественном языке; указание на то, что инструкция состоит из нескольких параллельно выполняющихся частей; различные метрики инструкции, такие как количество тактов, которое занимает выполнение данной инструкции, энергия, потребляемая процессором при выполнении данной инструкции, и т.п. Эти данные используются профилировщиком.
Иерархичность описания команд в системе MetaDSP
В среде MetaDSP система команд описывается иерархично в виде дерева. Листьями дерева являются команды, промежуточные узлы соответствуют группам команд (группы могут быть вложенными). Например, инструкции пересылки можно разместить в одной группе дерева, арифметические в другой, инструкции управления в третьей. При этом инструкции пересылки можно далее дробить на более мелкие группы: пересылки память-память, регистр-память и т. д.
Иерархичность описания системы команд позволяет использовать наследование определенных свойств от родительских групп. Наследование возможно для следующих элементов: код операции (КОП), отдельные операнды и поведение. Наследование этих свойств может выполняться независимо и позволяет автоматизировать изменение групп инструкций, так как изменения у родителя вызывают аналогичные изменения у всех его потомков.
Img5b.shtml
Рис. 5. Задание ограничений в окне Instruction Properties.
Интегрированная среда описания системы команд встраиваемых процессоров
В.В. Рубанов, А.С. Михеев,
Труды Института системного программирования РАН
Интерфейс системы MetaDSP
Визуальная часть среды MetaDSP реализована на С++ с использованием графического интерфейса Windows и элементов управления библиотеки Codejock Xtreme Toolkit. Программа использует многооконный интерфейс с плавающими окнами (рис. 2).
Рис. 2. Графический интерфейс системы MetaDSP.
Основные окна программы:
Instruction Set - это окно (рис. 3) отображает дерево инструкций и является основным элементом навигации. При выделении определенного узла дерева информация об этом узле автоматически отображается в других окнах. Узлы дерева имеют контекстное меню, позволяющее удалять, копировать и добавлять новые узлы:
Рис. 3. Окно Instruction Set.
Instruction Properties - это окно (рис. 4, 5) отображает и позволяет редактировать свойства узлов, в частности бинарное кодирование, синтаксис, операнды и ограничения:
Рис. 4. Задание шаблона бинарного кодирования в окне Instruction Properties.
Рис. 5. Задание ограничений в окне Instruction Properties.
Simulator Description - в этом окне (рис. 6) описывается поведение команды. Окно разделено на две части, каждая из которых разделяется на собственную зону и зону, унаследованную от родителя (темный фон). Текст в унаследованных зонах заблокирован для редактирования (он задается в родителе - см. ):
Рис. 6. Окно поведения команды.
Operand Types - в этом окне (рис. 7) описываются глобальные типы операндов, которые потом используются при задании операндов в командах:
Рис. 7. Окно типов операндов.
Добавление, удаление и изменение типов осуществляется с помощью контекстного меню (рис. 8).
Рис. 8. Диалог редактирования типов операндов.
Additional Information - в этом окне задается дополнительная информация для системы команд в целом: описание межкомандных конфликтов, список свойств команд, список сообщений об ошибках. Свойства команд и сообщения об ошибках используются при задании ограничений (как внутрикомандных, так и межкомандных). Output - в это окно выводятся сообщения об ошибках или предупреждениях при автоматической верификации описаний, а также выводятся результаты аналитических запросов (в частности, статистика об использовании бинарного пространства и свободных кодах).
Литература
| 1. | Hiroyuki Tomiyama, Ashok Halambi, Peter Grun. Architecture Description Languages for Systems-on-Chip Design. Center for Embedded Computer Systems, Univertsity of California. 2000. |
| 2. | Wei Qin, Sharad Malik. Architecture Description Languages for Retargetable Compilation. The Compiler Design Handbook, CRC Press, 2003. |
| 3. | Clifford Liem, Pierre G. Paulin, Ahmed A.Jerraya. Retargetable Compilers for Embedded Core Processors. Kluwer Academic Publishers, 1997. |
| 4. | Rainer Leupers. Retargetable Code Generation for Digital Signal Processors. Kluwer Academic Publishers, 1997. |
| 5. | Lin Yung-Chia. Hardware/Software Co-design with Architecture Description Language. Programming Language Lab. NTHU. 2003. |
| 6. | A. Fauth, J. Van Praet, M. Freericks. Describing Instruction Set Processors Using nML. Proc European Design and Test Conf., Paris, March 1995. |
| 7. | Mark R. Hartoog, James A. Rowson, Prakash D. Reddy. Generation of Software Tools from Processor Descriptions for Hardware/Software Codesign. Alta Group of Cadence Design Systems, Inc. DAC 1997. |
| 8. | |
| 9. | G. Hadjiyiannis, S. Hanono, and S. Devadas. ISDL: An Instruction Set Description Language for Retargetability. In Proceedings of the 34 th DesignAutomation Conference,pages 299--302, June 1997. http://citeseer.ist.psu.edu/hadjiyiannis97isdl.html |
| 10. | George Hadjiyannis, Silvina Hanono. ISDL: An Instruction Set Description Language for Retargetability. Srinivas Devadas. Department of EECS, MIT. DAC 1997. |
| 11. | |
| 12. | Ashok Halambi, Peter Grun, Vijay Ganesh, Asheesh Khare, Nikil Dutt and Alex Nicolau. EXPRESSION: A Language for Architecture Exploration through Compiler/Simulator Retargetability, DATE 99. |
| 13. | Prabhat Mishra, Frederic Rousseau, Nikil Dutt, Alex Nicolau. Architecture Description Language Driven Design Space Exploration in the Presence of Coprocessors. SASIMI 2001. |
| 14. | В.В. Рубанов, Д.А. Марковцев, А.И. Гриневич. Динамическая поддержка расширений процессора в кросс системе. Труды ИСП РАН, том 5, 2004. |
Межкомандные конфликты
Каждой команде можно назначить некоторый набор свойств и задать для них значения и области активации. В качестве значения свойства может выступать либо константа, либо значение одного из операндов команды. Область активации задает диапазон соседних команд, на котором данное свойство активно. По умолчанию [1;1] область активации затрагивает только текущую команду.
Пример:
MAC {acr},{grs},{grt} [read_grn:grs, read_grn:grt, write_acr:acr:2;2]
Данная команда обладает следующими свойствами:
read_grn - двойное свойство со значениями, равными значениям операндов grs и grt. Область активации по умолчанию затрагивает только текущую команду (здесь это означает, что значения регистров, заданных операндами grs и grt, читаются на первом такте). write_acr - значение свойства равно значению операнда acr. Область активации [2;2] затрагивает следующую команду (здесь это означает, что значение acr будет записано на втором такте).
На механизме описания свойств базируется способ задания ограничений на использование ресурсов. Задается список предикатов совместимости свойств. В предикате совместимости свойств в квадратных скобках указывается набор пар свойств (пары разделяются запятыми, свойства в паре - знаком «=»). Предикат истинен для пары команд, когда выполняются следующие условия: первая команда обладает всеми свойствами из левых частей пар, вторая обладает всеми свойствами из правых частей пар; при этом для каждой пары значения свойств совпадают на пересечении их областей активации. Предикаты совместимости оцениваются ассемблером для всех пар команд при ассемблировании программы - так обнаруживаются конфликтующие команды. Заметим, что оценки работают гарантированно корректно только на линейных участках.
Пример:
[write_acr=read_acr] % warning: "WAR conflict for ACRs"
Данный предикат будет верен, если у пары команд значение свойства write_acr первой команды совпадет со значением свойства read_acr второй команды на пересечении областей активации этих свойств. В данном примере это отражает конфликт по данным (по аккумуляторным регистрам) типа WRITE AFTER READ.
Зарезервировано специальное свойство «any», которым по умолчанию обладает любая инструкция. [any=X] дает истинный предикат, если вторая инструкция обладает свойством X (независимо от его значения).
Микрооперации в описании поведения
При описании поведения инструкции, помимо стандартных операций С++, можно использовать описываемые дополнительно микрооперации (например REVERSEBITS(REG)). Стандартные микрооперации входят в библиотеку поддержки; разработчик общей части симулятора может определить свои микрооперации.
Наследование кода операции
Под наследованием кода операции (КОП) подразумевается наследование битовых полей, установленных в бинарном коде инструкции в фиксированные значения - '0' или '1'. Например, пусть есть две инструкции:
MOVE GRs, GRt с кодом 0111-0011-GGGG-RRRR
и
MOVE ARs, GRt с кодом 0011-0011-AAAA-RRRR.
Видно, что в этих двух инструкциях общим КОПом является:
0X11-0011-XXXX-XXXX
В таких случаях в системе MetaDSP обычной практикой является вынесение описания общего КОП в родительский узел. При этом для каждого потомка этого узла можно указать, наследует ли он КОП родителя или нет (по умолчанию - да). Для узлов, наследующих КОП родителя, изменение значения зафиксированных в родителе битовых позиций запрещено, то есть в потомке можно определять только те позиции шаблона, в которых в родителе стоит X. Наследование КОП может быть многоуровневым в соответствии с организацией дерева системы команд.
При добавлении новых потомков к родителю унаследованные биты КОП автоматически проставляются в потомке. Это ускоряет добавление новых инструкций.
Наследование операндов
Под наследованием операндов подразумевается использование в инструкции родительских операндов. При этом изменение таких операндов возможно только на уровне родителя. В качестве примера возьмем те же инструкции, что и рассмотренные при описании наследования кода операции:
MOVE GRs, GRt с кодом 0111-0011-GGGG-RRRR,
где операнды GRs, GRt кодируются битами, помеченными в бинарном коде инструкции буквами GGGG и RRRR соответственно, и
MOVE ARs, GRt с кодом 0011-0011-AAAA-RRRR,
где операнды ARs, GRt кодируются битами, помеченными в бинарном коде инструкции соответственно буквами AAAA и RRRR.
Видно, что вторые операнды этих двух инструкций GRt имеют одинаковый тип и одинаковое положение в бинарном коде. Таким образом, если в дереве инструкций добавить родительский узел с определенным в нем операндом:
| Имя: | GRt |
| Тип: | General Purpose Register |
| Кодирование: | XXXX-XXXX-XXXX-RRRR, |
а затем добавить к этому родительскому узлу двух потомков: MOVE GRs, GRt с операндами:
| Имя: | GRs |
| Унаследован: | нет |
| Тип: | General Purpose Register |
| Кодирование: | XXXX-XXXX-GGGG-XXXX, |
| Имя: | GRt |
| Унаследован: | да |
и MOVE ARs, GRt с операндами:
| Имя: | ARs |
| Унаследован: | нет |
| Тип: | Address Register |
| Кодирование: | XXXX-XXXX-AAAA-XXXX, |
| Имя: | GRt |
| Унаследован: | да |
то эти потомки будут содержать унаследованный операнд GRt. При изменении каких либо свойств этого операнда в родительском узле соответствующие изменения автоматически применятся к потомкам. Опыт авторов показывает, что в условиях должной организации дерева команд при добавлении новой инструкции большая часть операндов наследуется от родительского узла.
Наследовать можно любое количество операндов, по-разному расположенных в бинарном коде родителя, в том числе и с перекрытием. При удалении операнда у родителя соответствующий унаследованный операнд удаляется у всех потомков.
Наследование поведения инструкций
Поведение инструкции задается в виде кода на языке ISE-Exec, описанном в разделе . Под наследованием поведения подразумевается использование в описании поведения команды определенных частей родительского описания. Важность этого механизма обусловлена тем, что при описании поведения часто возникают ситуации, когда у нескольких дочерних инструкций описания очень похожи между собой. Чаще всего похожи начала или концы этих описаний (например, загрузка и выгрузка данных), а в середине они различны (обработка данных, специфичная для каждой команды). Поэтому в системе MetaDSP существует возможность определить общие части поведения в родительском узле и наследовать их в потомках.
Описание поведения у каждого узла дерева системы команд разделяется на две части: начало и конец. При этом в описании, принадлежащем данному узлу, можно использовать операнды, видимые на уровне этого узла. Дочерние узлы могут наследовать начало и конец описания родителя, то есть начало описания дочернего узла является конкатенацией начала описания родителя и своего начала, а конец описания дочернего узла является конкатенацией своего конца и конца описания родителя (матрешка).
При таком подходе общий код в потомках большей частью может быть вынесен на уровень родителя, что обеспечивает более удобное и быстрое внесение изменений, а также уменьшает количество ошибок.
Обращение к операндам и битовым полям
При описании поведения инструкции необходимо знать конкретные значения операндов инструкции. В рассматриваемом языке эти значения можно получить двумя путями.
Путем использования просто имени операнда, как обычной переменной. Такая ссылка автоматически преобразуется в необходимый код, который извлечет нужное значение из машинного кода команды в процессе симуляции. Путем непосредственного обращения к именованным битовым полям машинного слова. Это осуществляется с помощью использования синтаксиса:
#[+]LLLL
Здесь символ + является необязательным; если он есть, то закодированное число нужно трактовать как знаковое. На месте LLLL может быть любое количество подряд идущих букв в бинарном коде инструкции. При задании этих букв нужно следить, чтобы их положение в бинарном шаблоне команды определялось однозначно (см. ).
Вот простой пример обращения к битовым полям инструкции: MOVE {XM0}({YAv} + {offset}), {GRs}
с кодом:
00DX-0100-01AA-RRRR-MMMM-MMMM
Данная инструкция осуществляет пересылку в память с именем XM0 (это может быть память данных DM0 или TM0) регистра общего назначения GRs (в качестве GRs может выступать один из регистров общего назначения GR0,GR1,…, GRF). Адрес является суммой явно заданной константы offset и значения адресного регистра YAv (это может быть один из адресных регистров DA0 или TA0).
Здесь кодирование соответствует операндам следующим образом:
| D | : Destination memory field (XM0) |
| AA | : Destination address pointer field (YAv): |
| RRRR | : General register field (GRs): |
| MMMMMMMM | : offset field constant [-128;127] |
При описании поведения возможны следующие выражения:
GRs, #RRRR, YAv + #+MMMMMMMM
Обращение к состоянию процессора и системы
Состояние процессора и системы задается значением регистров и всех памятей системы. Обращение к этим ресурсам происходит следующим образом.
Обращения к памяти осуществляются с помощью макроса:
MEM(memory_name, address)
Здесь memory_name обозначает индекс памяти, а address - адрес, по которому идет обращение.
Обращение к регистрам производится путем использования макросов вида:
<register_type>(register_name)
Здесь register_type - тип регистра, а register_name - имя или код регистра этого типа.
Например, для описанной выше инструкции MOVE XM0(YAv + offset), GRs поведение можно задать так:
MEM(XM0, ARN(YAv)+offset) := GRN(GRs);
Здесь YAv - адресный регистр типа ARN, а GRs - регистр общего назначения типа GRN.
Стоит обратить внимание на операцию «:=», использованную в данном примере. Эта операция необходима, если в левой или правой части присваивания используется ресурс системы (регистр или память). При этом обращение транслируется в соответствующие функции доступа (set/get), которые, кроме собственно чтения/записи значения, обеспечивают сбор необходимых статистик для профилировки.
Допустимые типы памятей и регистров, их разрядность и размер задаются разработчиком общей части симулятора.
Ограничения на значения и связи операндов
В ряде случаев для данной инструкции допустимыми являются не все возможные значения операнда данного типа. Например, если в данной инструкции в качестве операнда GRt могут использоваться только регистры общего назначения GR0, GR1, GR2, GR3, а не все 16 регистров, имеющиеся в процессоре, то необходимо отдельно описать ограничения на такой операнд. Ограничения можно задать в виде предикатов. Если предикат ложный, то ограничение не выполнено, и ассемблер выдаст сообщение об ошибке. Например, для операнда GRt ограничение можно задать так:
Predicate : GRt <= 4 Message : Only GR0 - GR3 can be used for this operand
В предикатах можно использовать логические и арифметические операции над одним или несколькими операндами. Например, (GRt/4+1)*2-GRt >=GRt*2 представляет собой пример допустимого предиката. Использование предикатов над несколькими операндами позволяет задать ограничения на связи операндов, например, GRs=GRt обозначает тождественность операндов в синтаксисе.
Операнды инструкции
Для каждой команды описывается ноль или более операндов. При этом для каждого операнда задаются следующие параметры:
Имя операнда, определяющее ссылку на операнд в строке синтаксиса команды (например, GRs); Тип операнда (например, регистр общего назначения, адресный регистр, 8-битная константа и так далее). Типы операндов задаются отдельно и определяют семантику в виде ссылки на объект в состоянии симулятора, синтаксис, разрядность и кодирование в виде перечисления пар значений - {синтаксис=код}. Например, {{GR0=00}, {GR1=01}}. Заметим, что тип операнда не определяет место кодирования операнда в машинном слове; Место кодирования операнда в бинарном коде инструкции в виде строки, в которой буквы, отличные от X, определяют положение кода операнда (наиболее значимый бит слева). Например, ХХХХ-XXXX-XXXX-XXAA определяет положение двухбитового операнда AA в двух младших битах машинного кода команды. Коды различных операндов в принципе могут перекрываться, если это не вызывает конфликта, кроме того, код операнда может иметь разрывы, например, четырехбитный операнд AAAA может кодироваться, как ХХХХ-XXXX-XAXA-XXAA - такие возможности очень важны для описания нерегулярных систем команд;
Описание поведения команд
В этом разделе рассматриваются средства системы MetaDSP для описания поведения инструкций. Для этой цели используется язык ISE-Exec, являющийся расширением C++. Описание на этом языке проходит через генератор, который преобразует его в чистый С++. Цель разработки этого языка состоит в том, чтобы повысить уровень абстракции для учета специфических потребностей и более удобного описания поведения команд процессора.
Описание синтаксиса и бинарного кодирования команд
В этом разделе описываются возможности системы MetaDSP для спецификации бинарного кодирования инструкции, ее ассемблерного синтаксиса, статических свойств и ограничений, а также правил определения межкомандных конфликтов.
Временные переменные в описании поведения
При описании поведения инструкции можно использовать любое число временных переменных. При этом для удобства эти переменные можно не объявлять, а можно просто написать имя переменной в левой части операции '='. После обработки генератором все определения переменных будут сгенерированы автоматически.
