46186 (762244), страница 3
Текст из файла (страница 3)
void SMUL_16_16(INT& res, INT a, INT b) {
UseResources();
res = a * b;
}
Заданная на C++ операция может быть оформлена в виде отдельной функции (см. примеры выше) или встраиваться непосредственно в тело функции поведения команды (см. примеры в 2.2.2.2).
2.2.2.2. Дескрипторы команд
Дескрипторы команд акселератора из IA задаются соответствующими функциями поведения команд. Функция поведения может принимать аргументы в виде параметров инструкции pi. Тем самым одна функция поведения может описывать набор дескрипторов (один дескриптор соответствует одному конкретному набору значений параметров). Тело функции поведения может описываться на языке C++. Отображение в операции для соответствующих значений состояния команды t неявно задается путем использования специальной функции FinishCycle(). Вызовы данной функции отделяют операции внутри функции поведения, относящиеся к последовательным тактам исполнения (значениям параметра t дескриптора команды). Для описания динамического характера выбора операций в зависимости от состояния акселератора (аргумент дескриптора s) в описании функции поведения команды допускается использование управляющих конструкций языка C, в частности циклов и ветвлений (см. пример 3 ниже). Вызов функции FinishCycle() означает окончание всех операций для текущего такта команды и соответствует управляющему действию next. Возврат из функции поведения команды соответствует управляющему действию end. Использо-вание такого решения позволяет эффективно описывать дескрипторы команд, тем самым определяя потактовое поведение команд акселератора.
Пример 1. Однотактовая команда перемещения между регистрами, содержащая единственную операцию, задаваемую конструкцией
GRF[greg] = LRF[lreg]:
ACC_FUNCTION Move_LREG_GREG(INT lreg, INT greg) {
GRF[greg] = LRF[lreg];
FinishCycle();
}
Пример 2. Двухтактовая команда перемножения и аккумуляции результата. На первом такте происходит перемножение операндов (операция SMUL_16_16 - см. пример 2 в 2.2.2.1), на втором аккумуляция результата (операция ADD_36_36 - см. пример 1 в 2.2.2.1):
ACC_FUNCTION MAC_LREG_GREG(INT grs, INT grt) {
SMUL_16_16 (mulres, GRF[grs], GRF[grt]);
FinishCycle();
ADD_36_36 (ACC, ACC, mulres);
FinishCycle();
}
Заметим, что две выдачи подряд этой команды процессором приведут к ситуации, когда одновременно будут исполняться две различные стадии этой функции (стадия умножения второй команды и стадия сложения первой команды). Такой эффект может быть использован для моделирования конвейера акселератора.
Пример 3. Команда свертки векторов, расположенных в памятях DM0 и TM0. Длительность команды зависит от данных (длина векторов задается регистром LOOPREG). Заметим, что в теле цикла за один такт выполняются несколько операций, использующих непересекающиеся ресурсы. Для синхронизации с процессором используется механизм прерывания:
ACC_FUNCTION CONV_ACC_DM0_TM0(INT dreg, INT treg) {
SMUL_16_16 (mulres, DM0[AR[dreg]++], TM0[AR[treg]++]);
FinishCycle();
while (LOOPREG>0) {
ADD_36_36 (ACC, ACC, mulres);
SMUL_16_16 (mulres,
DM0[AR[dreg]++], TM0[AR[dreg]++]);
LOOPREG--;
FinishCycle();
}
ADD_36_36 (ACC, ACC, mulres);
InterruptProcessor();
FinishCycle();
}
2.2.2.3. Функция декодирования
Функция декодирования dA задается описанием множества пар из формата машинного слова команды и ссылки на функцию поведения команды:
INSTRUCTION(, );
Формат машинного слова команды задается строкой в следующем алфавите:
Битовые символы: '0' и '1'
Параметрические символы: 'A-Z' и 'a-z'
Групповой символ: '*'
Разделительный символ: '-'
Символы из пунктов 1-3 называются значимыми символами. Заметим, что число значимых символов в строке формата команды должно быть равно разрядности машинного слова в системе.
Непрерывная цепочка параметрических символов задает операнд. Декодер акселератора выделит указанные биты и передаст полученное значение в функцию поведения команды в виде параметра pi. Различные операнды разделяются групповым или разделительным символом. Операнды нумеруются в порядке справа налево.
Битовые символы задают фиксированные значения в соответствующих позициях машинного слова. На месте параметрических и групповых символов в машинном коде команды может быть любое битовое значение. Разделительные символы используются для косметических целей, а также для отделения подряд идущих операндов.
Пример:
INSTRUCTION("11-**-0000-0000-0001-LREG-GREG", Move_LREG_GREG);
Функция поведения MoveLREG_GREG (см. пример 1 в 2.2.2.1) имеет два параметра по 4 бита каждый (LREG[4;7] и GREG[0;3]). Биты [20;21] могут принимать любые значения для данной команды (в данном примере эти биты относятся к коду акселератора и используются командой запуска акселератора основного процессора). Остальные биты фиксированы и составляют КОП инструкции аскелератора.
Заметим, что совокупность всех строк форматов машинного слова задает множество допустимых кодов инструкций данного акселератора (CA в 2.1.2).
Число управляющих слотов NS задается директивой SLOTS().
2.3. Ассемблерный синтаксис команд акселератора
Отдельная секция файла описания модели акселератора отвечает за опреде-ление синтаксиса ассемблера для системы команд этого акселератора. Более точно, эта секция определяет синтаксис для подмножества системы команд основного процессора, соответствующего командам запуска инструкций этого акселератора (см. 2.1.3.1). Это полезно для адекватного отра-жения на уровне ассемблера соответствующей семантики команд, так как одни и те же (в смысле машинных кодов) команды основного процессора (для запуска акселераторов) могут иметь разную семантику, в зависимости от конкретной конфигурации акселераторов в системе, специфичной для каждого заказчика. В дополнение к определению семантики команд акселераторов (см. 2.2), воз-можность настраивать синтаксис для этих команд является важной функцио-нальностью рассматриваемой системы, позволяющей легко получать готовую для производственного использования кросс-систему, адаптированную для специфичной конфигурации "процессор + акселераторы пользователя".
Описание ассемблерного синтаксиса системы команд состоит из трех секций:
Секция типов операндов и псевдонимов
Секция команд
Секция ограничений (constraints)
Детальное рассмотрение средств описания синтаксиса команд выходит за рамки данной статьи. Ниже приводится только краткий обзор основных возможностей.
2.3.1. Отображение ассемблерных команд в машинное слово
Общий шаблон допустимого ассемблерного синтаксиса для команд акселератора задается в виде:
command ::= mnemonic [parameter {, parameter}*]
{|| mnemonic [parameter {, parameter}*]}*
mnemonic ::= const_string
parameter ::= operand
{[const_string] [operand]}*
operand ::= const_string
const_string ::= любой текст без запятых и пробелов
Примеры возможных команд:
DMOVE ACR1.h, DM0(DA0--), ACR1.L, TM0(TA0++)
MOVE GRA, DM1(TA0+25) || ADD GR3, ACR2.H
На языке ассемблера команда состоит из мнемоники (нескольких мнемоник для параллельных команд) и набора параметров, разделенных запятой. Каждый параметр может содержать несколько частей - операндов, принадлежащих к каким-либо из описанных типов. В рамках одного параметра операнды должны отделяться непустыми строками константных символов. Комбинация мнемоник ассемблерного синтаксиса отображается в поле КОП соответс-твующей команды. Операнды (operand) отображаются на поля-операнды машинного слова. Возможно задание отображения на не непрерывные поля (когда биты поля перемежаются битами других полей).
Пример:
.types
grn [gr0:0] [gr1:1] [gr2:2] [gr3:3]
const6b $ -32 31
.mnemonics
MOVE {grn#0;2},{const6b#2;4#8;2} % 0xA8C0 0xFCC0
Описание задает команду MOVE с двумя операндами. Первый операнд типа grn является регистром общего назначения, код регистра размещается в 2х битах начиная с 0-го. Второй операнд является константой в диапазоне [-32; 31] и располагается в машинном слове в двух частях: в 4х битах, начиная со 2-го, и 2х битах, начиная с 8-го. КОП равен 1010-10XX-11XX-XXXX.
2.3.2. Ограничения
2.3.2.1. На отдельные операнды
Ограничения на отдельные операнды определяются соответствующим типом, к которому принадлежит операнд. Однако для наглядной генерации ошибок можно задать более широкий тип для операнда и воспользоваться механизмом общих ограничений (см. 2.3.2.2) для выделения допустимых значений.
2.3.2.2. На взаимосвязь операндов команды
Ограничения на взаимосвязь операндов команды задаются в виде набора логических высказываний относительно сравнений арифметических выражений, которые могут содержать значения любых использованных в команде операндов. Считается, что ограничения выполнены, если все логические высказывания для данной инструкции принимают значение "истина".
Выражения ограничений поддерживают следующие операции:
| Логические операции | &&, ||, ! |
| Операции сравнения | , =, ==, <> |
| Арифметические операции | +, -, *, /, % |
| Битовые операции | |, &, ^, ~ |
В выражениях могут быть использованы числовые константы и, собственно, ссылки на операнды. Если несколько операндов имеют одинаковый тип, то следует использовать псевдонимы типов для различения операндов в выражениях ограничений. Пример. Операнды 1 и 2 не должны быть равны:
ADD {GRs#8;4}, {GRt#4;4} % 0x796000 0xf9f000
(GRs <> GRt) % "Operands must be different for ADD"
Заметим, что с помощью описанного механизма также можно задавать ограничения на отдельные операнды. Таким образом, возможны две стратегии работы с ограничениями на значения операндов: с одной стороны можно создать систему общих типов и затем сужать множества значений с помощью логических высказываний, а с другой работать с большим количеством специфических типов. В первом случае можно достичь более конкретных сообщений об ошибках в операндах инструкции, во втором - упрощается описание системы команд. Пользователь может выбрать любую стратегию.
2.3.2.3. На комбинации команд
Каждой команде можно назначить некоторый набор свойств и задать для них значения и области активации. В качестве значения свойства может выступать либо константа, либо значение одного из операндов команды. Область активации задает диапазон соседних команд, на котором данное свойство активно. Область активации по умолчанию [1;1] затрагивает только текущую команду. Механизм описания свойств (дополненный предикатами совместимости - см. ниже) фактически является модифицированным описанием таблиц использования ресурсов (reservation tables).
Пример:
MAC {acr#14;1},{grs#4;4},{grt#0;4} % 0x6c2000 0xffb800
[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 (независимо от его значения).
2.3.3. Сообщения об ошибках
2.3.3.1. Ошибки симуляции
Число NS (см. 2.1.1.2) определяет максимальное количество параллельных команд в акселераторе. Симулятор генерирует ошибку, если процессор пытается выдать команду, когда нет свободных слотов.
Другой механизм обнаружения ошибок выполнения основывается на использовании ресурсов (см. 2.1.2). Если в пределах одного такта один и тот же ресурс используется разными параллельно выполняющимися командами, симулятор генерирует ошибку выполнения.
Для обеспечения CREW модели доступа к данным симулятор обнаруживает запись разными процессами в одну и ту же ячейку памяти и генерирует ошибку выполнения.
2.3.3.2. Ошибки ассемблирования
Для ограничений 2.3.2.2 и 2.3.2.3 пользователь может задавать специализированный текст сообщений об ошибке и критичность ошибки (warning или error). Существует возможность задавать как индивидуальные тексты для каждого ограничения, так и ссылаться на общую таблицу сообщений. Данный подход предоставляет пользователю возможность точной настройки диагностики ошибок ассемблирования с детализированными описаниями, что является необходимым условием промышленной эксплуатации кросс-системы.
3. Динамическая настройка кросс-системы
В данной главе приводится краткий обзор нашей технологии динамической настройки кросс-системы для работы с моделями акселераторов, заданных в соответствии с 2.2 и 2.3 в виде файлов описания акселераторов.















