В этой документации (перевод секции "C/C++ Run-Time Model and Environment" даташита [1]) описывается модель исполняемого кода C/C++ процессора Blackfin и его рабочее окружение (C/C++ run-time model, C/C++ run-time environment). Эта модель, которая применяется в сгенерированном компилятором коде, включает описание структуры стека, доступа к данным и последовательности вызова процедур/функций и входа в них. C/C++ run-time environment включает соглашения, которым должны следовать подпрограммы, функции, ISR и основной код, работающий на процессоре Blackfin. Подпрограммы/функции ассемблера, слинкованные с подпрограммами C/C++, должны следовать этим соглашениям.

Компания Analog Devices рекомендует программистам, пишущим код на ассемблере, соблюдать принятые соглашения по использованию стека. Это облегчит интеграцию кода ассемблера с кодом, написанным на C/C++.

На рис. 1-2 показан обзор вопросов run-time environment, которые должны учитываться при написании подпрограмм на ассемблере, которые должны ликоваться с подпрограммами/функциями C/C++, включая правила, описанные далее в разделе "C/C++ Run-Time Header и Startup Code".

Рис. 1-2. Обзор интерфейса языка ассемблера.

Вопросы, решаемые run-time environment, включают следующее:

• Соглашения по использованию памяти:
   Использование секций памяти [11].
   Использование нескольких куч [12].
   Использование форматов хранения данных [13].
• Соглашения по использованию регистров:
   Выделенные регистры.
   Регистры, сохраняемые при вызовах.
   Временные регистры (Scratch-регистры).
   Регистры стека.
• Соглашения по управлению выполнением программы:
   Управление стеком.
   Передача аргументов в функцию и возврат значения.

[C/C++ Run-Time Header и Startup Code]

Проекты, создаваемые для Blackfin на языках C/C++, должны подключать так называемый исполняемый заголовок C/C++ (C/C++ run-time header, сокращенно CRT header или просто CRT).

C/C++ run-time (CRT) это код, к выполнению которого процессор приступает в момент сброса / включения питания (код, куда переходит безусловный переход при запуске, start address). По этой причине CRT часто называют кодом запуска (код startup). CRT устанавливает машину в исходное, заранее известное  состояние, и вызывает функцию _main. Выполнение CRT автоматически гарантирует, что состояние процессора перез вызовом _main будет удовлетворять совместимости с двоичным интерфейсом прикладных программ ABI (Application Binary Interface). Интерфейс ABI обеспечивает переносимость программ между различными платформамит (процессорами).

Код CRT может быть подключен к проекту одним из следующих способов:

• Может использоваться Мастер создания проекта VisualDSP (окна диалогов Project Wizard), что автоматически сгенерирует настроенный CRT в проекте. Подробнее см. VisualDSP++ Help.
• Во время линковки может быть определен макрос USER_CRT, указывающий на определяемый пользователем объект CRT, подключаемый в сборку проекта.
• Объекты CRT по умолчанию, предоставляемые в run-time библиотеках для всех платформ (т. е. используемых процессоров), и они линкуются со всеми проектами C/C++, если не был определен во время линковки макрос USER_CRT.

Обзор CRT Header. CRT гарантирует, что когда выполнение входит в _main, состояние процессора подчиняется условиям двоичного интерфейса приложений языка C (C application binary interface, сокращенно ABI), и все глобальные данные, декларированные приложением, были инициализированы в соответствии с требованиями стандартов C/C++. CRT организует среду выполнения кода так, что _main выглядит просто как еще одна функция, вызываемая обычной процедурой вызова функции.

Не все приложения требуют для себя одинаковой конфигурации. Например, конструкторы C++ запускаются только для приложений, которые содержат код C++. Список опциональных элементов конфигурации может быть достаточно длинен, что иногда приводит к чрезмерно дорогому по времени запуску программы. По этой причине Project Wizard позволяет генерировать CRT, который включает минимальное количество необходимого кода, добавленного опциями выбора пользователя. Дополнительно предоставляется заранее собранные модули CRT в нескольких различных конфигурациях, которые можно указать во время линковки через макросы файла LDF [3].

CRT header используется для проектов, которые используют C, C++ и VDK [4]. Проекты на языке ассемблера не предоставляют run-time header по умолчанию; Вы сами должны предоставить свой.

Исходный код на языке ассемблера для заранее скомпилированных CRT находится в каталоге инсталляции системы программирования VisualDSP++, в файле basiccrt.s, находящийся в папке Blackfin/lib/src/libc/crt. Каждый из предварительно собранных объектов CRT был скомпилирован из этого исходного кода по умолчанию (default CRT source). Различные конфигурации предоставляются определением различных макросов.

Список операций, выполняемых кодом CRT (startup code) может включать следующее (не обязательно именно в таком порядке):

• Установка регистров и заранее известные / требуемые значения.
• Запрещает аппаратные циклы.
• Запрещает кольцевые буферы.
• Настраивает обработчики событий по умолчанию (default event handlers) и разрешает прерывания.
• Инициализирует указатель стека (регистр SP) и указатель фрейма (регистр FP).
• Разрешает счетчик циклов процессора.
• Конфигурирует порты памяти, используемые двумя генераторами адресов данных (Data Address Generator, DAG).
• Копирует данные из памяти FLASH в RAM.
• Инициализирует драйверы устройств [5].
• Настройка защиты памяти и кэшей.
• Изменение приоритетов прерываний процессора.
• Инициализация поддержки профайлинга.
• Запуск конструкторов C++.
• Запуск _main с предоставленными параметрами.
• Запуск _exit при завершении программы (при выходе из _main).

Что не делает CRT. CRT не инициализирует реальную аппаратуру памяти. Инициализация внешней памяти SDRAM оставляется на код загрузчика (boot loader), потому что может быть (и даже желательно), что сам CRT нуждается в переносе во внешнюю память перед своим выполнением.

short _install_default_handlers(short mask);

[Конструкторы и деструкторы глобальных экземпляров класса]

Во время запуска приложения (start-up) C/C++ run-time header запускает конструкторы глобальных экземпляров классов. Это обеспечивают следующие компоненты:

• Соответствующая область данных для каждого глобального экземпляра класса.
• Соответствующий конструктор класса (и деструктор, если он существует).
• Генерируемая компилятором подпрограмма "start".
• Генерируемая компилятором таблица таких подпрограмм "start".
• Конструируемый компилятором связанный список подпрограмм деструктора.
• Сам run-time header.

Эти компоненты взаимодействуют следующим образом.

Компилятор генерирует подпрограмму "start" для каждого модуля, содержащего глобальные инициализации экземпляров классов, которые нуждаются в конструировании или уничтожении. Должна быть как минимум одна подпрограмма "start" на модуль; она обрабатывает все глобальные экземпляры класса в этом модуле:

• Для каждого такого экземпляра класса запускается его конструктор. Это может быть прямой вызов, или может использоваться встраиваемый (inline) код, вставленный оптимизатором компилятора.
• Если экземпляр требует своего уничтожения, то подпрограмма "start" регистрирует этот факт позже путем добавления в связанный список экземпляра и ссылки на его деструктор.

Подпрограмма start именуется после первого попавшегося такого экземпляра, хотя нет гарантии конструирования или уничтожения экземпляров класса в каком-либо определенном порядке (с тем лишь исключением, что деструкторы вызываются в порядке, обратном порядку вызова конструкторов). Такие экземпляры не должны иметь зависимости от порядка вызова конструкторов; опция командной строки -check-init-order [10] полезна для проверки этого в процессе разработки, поскольку она вставляет дополнительный код для детектирования использования еще не сконструированных объектов во время инициализации.

Указатель на подпрограмму "start" помещается в секцию ctor генерируемого объектного файла. Когда происходит линковка приложения, все секции ctor отображаются на одну и ту же выходную секцию ctor, формируя таблицу указателей на подпрограммы "start". В конец этой таблицы добавляется дополнительный объект ctorl, он содержит терминирующий NULL-указатель.

Когда запускается run-time header, он вызывает функцию _ctor_loop(), которая обрабатывает таблицу секций ctor, вызывая по указателям каждую функцию "start", пока не дойдет до указателя NULL из ctorl. Таким способом run-time header вызывает конструктор каждого глобально создаваемого экземпляра класса, косвенно обращаясь к ним через указатели на функции "start".

Когда программа достигает exit(), либо путем прямого вызова, либо при возврате из main(), то подпрограмма exit() следует нормальному процессу обработки связанного списка функций, зарегистрированных через интерфейс atexit(). Это приводит к запуску деструкторов каждого созданного глобального объекта (в порядке, обратном вызову конструкторов).

Эта функция регистрируется с atexit() через _mark_dtors(); компилятор вставляет вызов этой функции в начало каждой функции main(), компилированной в режиме C++.

Функции, зарегистрированные с atexit(), могут не ссылаться на глобальные экземпляры класса, поскольку деструктор для экземпляра может быть вызван перед использованием ссылки.

Конструкторы, деструкторы и размещение в памяти. По умолчанию компилятор помещает код конструкторов и деструкторов в ту же самую секцию, что и любая другая функция кода. Это можно поменять либо указанием секции, специально предназначенной для конструктора или деструктора (см. описание директив "#pragma section/#pragma default_section" и ключевого слова section() в [11]), или путем изменения секции назначения по умолчанию для генерируемого кода (см. описание "#pragma section/#pragma default_section" в [11] описание опции -section в [10]).

Обычно генерируемый компилятором код помещается в область CODE, подпрограмма "start" помещается в область STI. Обе область CODE и STI по умолчанию соответствуют размещению в одной и той же секции, однако это можно раздельно поменять с использованием #pragma default_section или опцией командной строки -section switch (так как функция "start" это внутренняя функция, генерируемая компилятором, на её размещение не может повлиять директива #pragma section).

Указатель на подпрограмму "start" помещается в секцию ctor. Это не конфигурируется, поскольку процесс запуска этих подпрограмм основан на всех указателях "start", находящихся в одной и той же секции в процессе линковки, чтобы они могли сформировать таблицу. Важный момент, что все соответствующие секции ctor отображаются во время линковки; если секция ctor опущена, то связанный конструктор не будет запущен во время start-up, и поведение run-time будет некорректным.

Если нужны деструкторы, то компилятор генерирует структуры данных, указывающие на экземпляр класса и его деструктор. Эти структуры помещаются в секцию для переменных по умолчанию (область DATA).

[Использование секций памяти]

См. статью [11].

[Использование нескольких куч]

Вопросы определения кучи (heap) во время линковки и во время работы программы, советы по работе с кучами, стандартный интерфейс кучи, выделение отдельной кучи для объектов C++ STL, использование альтернативного интерфейса кучи - все это см. в статье [12].

[Выделенные регистры]

C/C++ run-time определяет набор регистров (Dedicated Registers, выделенные регистры), содержимое которых никогда не должно изменяться, кроме специально определенных обстоятельств. Если эти регистры изменяются, то их значения должны быть предварительно сохранены и после модификации восстановлены обратно. Значения выделенных регистров всегда должны быть достоверными для каждого вызова функции (особенно для библиотечных вызовов) и для любого возможного прерывания.

К выделенным регистрам относятся SP, FP и L0-L3.

• Имена/аббревиатуры SP и FP это соответственно указатель стека (stack pointer) и указатель фрейма (frame pointer). Компилятор требует, чтобы оба этих указателя указывали на достоверную ячейку памяти с выровненным на 4 байта адресом, находящуюся в пространстве памяти стека.
• Регистры L0-L3 определяют длины кольцевых буферов генераторов адреса DAG (это регистры Length). Компилятор использует регистры DAG в обоих режимах - линейная буферизация и кольцевая буферизация (linear buffering mode, circular buffering mode). Компилятор подразумевает, что регистры длины (Length) равны 0 как на входе в функции, так и на выходе из функции, и гарантирует это, когда генерирует вызовы функции и возвраты из них. Ваше приложение может изменять регистры Length и использовать кольцевые буферы, однако Вы должны гарантировать, что Length-регистры соответственно сбрасываются, когда вызываются скомпилированные функции, или когда происходит возврат из скомпилированных функций. ISR должны сохранять и восстанавливать регистры Length, если в них используются регистры DAG.

[Регистры, сохраняемые при вызовах]

C/C++ run-time задает набор регистров, содержимое которых должно сохраняться и восстанавливаться (call-preserved registers). Ваша функция на ассемблере должна сохранить эти регистры во время пролога (начала) функции, и восстанавливать во время эпилога (перед непосредственным возвратом) функции. Регистры call-preserved должны быть сохранены и восстановлены, если они модифицируются внутри функции ассемблера; если функция не меняет какой-то определенный регистр, то его соответственно не нужно сохранять и восстанавливать.

К регистрам call-preserved относятся регистры P3-P5, R4-R7.

[Временные регистры]

C/C++ run-time задает набор регистров, содержимое которых не нужно сохранять и восстанавливать (временные, scratch-регистры). Имейте в виду, что содержимое этих регистров не сохраняется между вызовами функций. В таблице 1-42 перечисляются scratch-регистры, и по некоторым из них даны соответствующие примечания.

Таблица 1-42. Временные регистры (Scratch Registers).

Счетчики прокруток цикла, оверлеи, и код DMA. Компилятор не гарантирует, что регистры счетчиков прокруток цикла (LC0 и LC1) равны 0 на входе или выходе из функции. Это обычно не приводит к проблемам, потому что точка выхода из аппаратного цикла уникальна в программе, и компилятор гарантирует только один путь выхода - через соответствующую инструкцию установки цикла.

Если используются оверлеи, или если код выполняет перемещение DMA в быструю память с целью ускорения выполнения, то это может быть уже не тот случай. Есть возможность для оверлея или функции DMA установить цикл, который завершается на адресе A, и затем для другого оверлея или функции DMA с другим кодом, занимающим адрес A в более поздний момент времени. Если аппаратный цикл все еще активен - LC0 или LC1 не равны 0 - в точке, когда инструкция достигла адреса A, то в результате может быть непредсказуемое поведение, когда аппаратный цикл перескочит в начало цикла.

Следовательно в таких случаях необходимо использовать менеджер оверлеев или менеджер DMA, чтобы сбросить счетчики аппаратных циклов для гарантии, что не осталось аппаратных циклов, которые могли бы повлиять на диапазон адресов, покрываемых вариантом кода.

[Регистры стека]

C/C++ run-time environment резервирует набор регистров, которые управляют стеком времени выполнения (run-time stack). Эти регистры могут быть модифицированы для управления стеком, однако должны быть сохранены и восстановлены. Эти регистры стека включают SP (stack pointer) и FP (frame pointer).

Управление стеком. C/C++ run-time environment использует run-time стек для сохранения автоматических переменных и адресов возврата. Стек управляется регистрами FP и SP, и растет в сторону уменьшения адреса в памяти, т. е. по мере проталкивания сохраняемых значений в стек адрес в регистрах FP (или SP) уменьшается.

Область фрейма стека (stack frame) это секция стека, используемая для хранения информации о текущем контексте программы C/C++. Информация в фрейме включает локальные переменные, временные ячейки компилятора и параметры для следующей функции.

Frame pointer работает как база для доступа к памяти в stack frame. Подпрограммы обращаются к локальным, временным переменным и параметрам по их смещению относительно frame pointer.

На рис. 1-3 показан пример секции run-time стека.

Рис. 1-3. Пример Run-Time Stack.

На рис. 1-3 выполняемая в настоящий момент подпрограмма Current() была вызвана подпрограммой Previous(), и Current() в свою очередь вызывает Next(). Состояние стека показано для момента, когда Current() только что протолкнула (push) аргументы для Next(), и готова вызывать подпрограмму Next().

Использование (расход) пространства стека для передачи любой или всех аргументов функции зависит от количества и типов параметров функции.

Поскольку Вы пишете код на ассемблере, имейте в виду, что операции по восстановлению указателей SP и FP находятся в зоне ответственности вызываемой функции.

Чтобы войти в функцию и запустить её на выполнение (пролог функции), следуйте последовательности шагов:

• Линковка фреймов стека - адрес возврата и FP вызывающего кода сохраняются в стеке, и FP устанавливается так, что указывает на начало нового (вызываемой функции) stack frame. SP декрементируется так, чтобы выделить пространство для локальных переменных и временных переменных компилятора.
• Сохранение регистров - любые регистры, которые функция должна сохранить, сохраняются в stack frame, и SP устанавливается на вершину stack frame.

По окончании функции (эпилог функции) должны быть выполнены следующие шаги:

• Восстановление регистров - любые регистры, которые были сохранены, восстанавливаются из stack frame, и SP устанавливается на вершину stack frame.
• Освобождение фрейма стека - FP восстанавливается из stack frame, чтобы у него было значение вызывающего кода, RETS восстанавливается из stack frame для адреса возврата, и SP устанавливается на вершину stack frame вызывающего кода.

Типичный пролог функции может быть таким:

      LINK 16;
      [--SP]=(R7:4);
      SP += -16;
      [FP+8]=R0; [FP+12]=R1; [FP+16]=R2;

Здесь LINK 16; это специальная инструкция линковки фрейма, которая сохранит адрес возврата и FP, и обновит SP так, чтобы выделить пространство из 16 байт для локальных переменных. Инструкция [--SP]=(R7:4); выделяет пространство в стеке и сохраняет регистры R7 .. R4 в соответствующей области сохранения. Инструкция SP += –16; выделяет пространство в стеке для исходящих аргументов. Всегда выделяйте как минимум 12 байт в стеке для исходящих аргументов, даже если вызываемая функция требует меньше. Инструкции [FP+8]=R0; [FP+12]=R1; [FP+16]=R2; сохраняют регистры аргументов в область аргументов.

Соответствующий эпилог функции:

      SP += 16;
      P0=[FP+4];
      (R7:4)=[SP++];
      UNLINK;
      JUMP (P0);

Здесь инструкция SP += 16; забирает обратно пространство стека, которое использовалось для исходящих аргументов. Инструкция P0=[FP+4]; загружает адрес возврата в регистр P0. Инструкция (R7:4)=[SP++]; восстанавливает регистры из области сохранения и забирает обратно эту область. UNLINK; это специальная инструкция, которая восстанавливает FP и SP. Инструкция JUMP (P0); возвращает управление в вызвавший функцию код.

int varying(char *fmt, ...) { /* ... */ }

_varying:
      [SP+0] = R0;
      [SP+4] = R1;
      [SP+8] = R2;

class fr
{

public:
   int v;

public:
   fr () {}
   fr (const fr& rc1) : v(rc1.v) {}
};

extern int fn(fr x);

fr Y;

int main()
{
   return fn (Y);
}

int test(int a, int b, int c)

char test(int a, char b, char c)

int test(int a)

int test(char a, char b,
         char c, char d,
         char e)

int test(struct *a, int b, int c)

struct s2a
{
   char ta;
   char ub;
   int vc;
}

int test(struct s2a x, int b, int c)

struct foo *test(int a, int b, int c)

void qsort(void *base,
           int nel, int width,
           int (*compare)(const void *,
                          const void *))

struct s2
{
   char t;
   char u;
   int v;
}

struct s2 test(int a, int b, int c)

struct s3
{
   char t;
   char u;
   int v;
   int w;
}

struct s3 test(int a, int b, int c)

[Использование форматов хранения данных]

См. статью [13].

[Ссылки]

1. VisualDSP++ 5.0 C/C++ Compiler and Library Manual for Blackfin® Processors site:analog.com.
2. VisualDSP: интерфейс C/C++ и ассемблера Blackfin.
3. Blackfin: руководство по файлам LDF.
4. Специфика использования VDK для процессоров Blackfin.
5. VDK: драйверы устройств и системные службы процессоров Blackfin.
6. Использование кэша в процессорах Blackfin.
7. VDK: менеджер прерываний.
8. Как происходит загрузка ADSP-BF533 Blackfin.
9. VisualDSP: ввод/вывод с использованием файлов (stdio).
10. Опции командной строки компилятора Blackfin.
11. VisualDSP: использование секций памяти.
12. VisualDSP: работа с динамически выделяемой памятью.
13. VisualDSP: использование форматов переменных.