Собеседование шло уже второй час. Мы наконец-то закончили тягучее и вязкое обсуждение моей скромной персоны, и фокус внимания плавно переполз на предлагаемый мне проект. Самый бойкий из трех моих собеседников со знанием дела и без лишних деталей принялся за его описание. Говорил он быстро и уверенно – явно повторяет весь этот рассказ уже не первый раз. По его словам, работа велась над неким чрезвычайно малым, но очень важным устройством на базе STM32L4. Потребление энергии должно быть сведено к минимуму... USART... SPI... ничего необычного, уже неоднократно слышал подобное. После нескольких убаюкивающих фраз собеседник внезапно подался чуть вперед и, перехватив мой сонный взгляд, не без гордости произнес:
— А firmware мы пишем на C++! – мой будущий коллега заулыбался и откинулся в кресле, ожидая моей реакции на свою провокативную эскападу.
Я попытался причудливо изогнуть бровь, иллюстрируя мое удивление, но, видимо, перестарался. Скромно сидевший слева болезненного вида молодой человек, очевидно, принял это за гримасу ужаса и отвращения.
— У вас есть какие-то опасения? – поспешил спросить он с искренней озабоченностью в голосе.
Опасения у меня всегда имеются в избытке. Я с ностальгическим умилением вспомнил, как писал первую прошивку на MbedOS для одной из демонстрационных плат. Память тогда закончилась быстрее, чем я успел моргнуть светодиодом второй раз. Эх, опыт, сын ошибок... Надо все же признать, что страшные темные времена, когда о прошивке на «плюсах» никто и не заикался, давно прошли. Все разумные возражения в настоящее время рассыпались в труху и превратились в мифы. Вроде бы...
— Ну, вы знаете… ничего такого, я вообще толерантный… – я замялся, не желая никого обижать. - Но на плюсах легко сделать что-нибудь этакое, и прошивка в один миг опухает, как мой мозг при прочтении произведений Германа Гессе.
— Да, такая опасность есть, но каждый в нашей команде невероятно квалифицирован, – пробасил молчавший до этого момента будущий коллега справа и высоко поднял указательный палец, акцентируя внимание на этом фантастическом факте.
— И у нас есть код ревью! – встрепенувшись, поспешили добавить хором двое других невероятно квалифицированных члена команды.
Да, я согласился участвовать в проекте. Но кто бы смел отказаться, придавленный столь весомыми аргументами?
IAR
Так уж получилось, что мы впервые встретились на этом проекте. "Ну, это же специальный компилятор для железок", – наивно думал я, – "сработаемся". Не скажу, что я жестоко ошибся и проклял тот день, но использование именно этого компилятора доставляет определенный дискомфорт. Дело в том, что в проекте уже начали внедрение относительно нового стандарта С++17. Я уже потирал потные ладошки, представляя, как перепишу вон то и вот это, как станет невероятно красиво, но IAR может охладить пыл не хуже, чем вид нововоронежской Аленушки.Новый стандарт реализован для нашего любимого коммерческого компилятора лишь частично, несмотря на все заверения о поддержке всех возможностей новейших стандартов. Например, structured binding declaration совсем не работает, сколько не уговаривай упрямца. Еще IAR весьма нежен и хрупок, какая-нибудь относительно сложная конструкция может довести его до истерики: компиляция рухнет из-за некой внутренней ошибки. Это самое неприятное, поскольку нет никаких подсказок, по какой причине все так неприятно обернулось. Такие провалы огорчают даже сильнее финала «Игры престолов».
Можно справедливо заметить, что всему виной сложные шаблонные конструкции. Да, но у GCC с пониманием аналогичных шаблонов никогда не было проблем.
SIL
Для некоторых классов устройств существует такое понятие, как стандарты SIL. Safety integrity level – уровень полноты безопасности, способность системы обеспечивать функциональную безопасность.Проще говоря, если от вашего устройства зависят жизни людей, то при его разработке нужно придерживаться определенных правил. Одно из них – это отсутствие динамического распределения памяти, по крайней мере, после вызова функции main. Думаю, все знают, что в no-OS устройствах динамические аллокации чреваты проблемами, вроде фрагментации памяти и т.п.
Одно только это правило привело ко всем последующим значительным изменениям в коде, о которых речь пойдет ниже.
std::exception
Несмотря на утверждение Герба Саттера, что без исключений C++ уже перестает быть тем языком, который мы знаем и любим, они были беспощадно выпилены. Немудрено, ведь обычный механизм исключений использует динамическое выделение памяти, что недопустимо в нашем проекте.Не будем вдаваться в подробности, как именно обрабатываются исключения в С++, полагаю, это всем известно и так. Если разложить процесс на элементарные функции, то можно найти среди них такую:
__cxa_allocate_exception
Название у нее уже какое-то нехорошее, и действительно, выделяет память для объекта исключения и делает это весьма неприятным образом прямо в куче. Вполне возможно эту функцию подменить на собственную реализацию и работать со статическим буфером. Если не ошибаюсь, то в руководстве для разработчиков autosar для с++14 так и предлагают делать. Но есть нюансы. Для разных компиляторов реализация может отличаться, нужно точно знать, что делает оригинальная функция, прежде чем грубо вмешиваться в механизм обработки. Проще и безопаснее от исключений отказаться вовсе. Что и было сделано, и соответствующий флаг гордо реет теперь над компилятором! Только вот стандартную библиотеку нужно будет использовать вдвойне осторожнее, поскольку пересобрать ее с нужными опциями под IAR возможности нет.
std::vector
Те же самые требования безопасности ограничивает и использование векторов. Не секрет, что этот контейнер из стандартной библиотеки активно использует динамическое выделение памяти. Сам процесс может незначительно отличаться в зависимости от компилятора, но аллокация есть, факт.Все вектора подлежали замене на std::array, но были особо сложные случаи, которые использовали возможности векторов по полной и были очень хитро вплетены в код. Для таких случаев можно написать простой аллокатор, который позволит изобразить вектор из стандартного массива.
template <class T, std::size_t Size>
class StaticArray {
using ssize_t = int;
public:
using value_type = T;
template <class U>
struct rebind {
using other = StaticArray<U, Size>;
};
StaticArray() = default;
~StaticArray() = default;
template <class U, std::size_t S>
StaticArray(const StaticArray<U, S>&);
auto allocate(std::size_t n) -> value_type*;
auto deallocate(value_type* p, std::size_t n) -> void;
auto max_size() const -> std::size_t;
};
Ключевые функции, конечно, allocate и deallocate. Передаваемый им параметр n – это не размер в байтах, а размер в попугаях, которые хранятся в векторе. Функция max_size используется при проверке вместимости аллокатора и возвращает максимально возможное теоретически число, которое можно передать в функцию allocate.
Тут очевиднейший пример использования аллокатора
std::shared_ptr
Умные указатели, безусловно, хорошая вещь, но нужная ли в bare metal? Требование безопасности, запрещающее динамическую аллокацию памяти, делает использование умных указателей в этой области крайне сомнительным мероприятием.Конечно, контролировать управление памятью путем использования кастомных аллокаторов вполне возможно. В стандартной библиотеке есть замечательная функция std::allocate_shared, которая создаст разделяемый объект именно там, где мы укажем. Указать же можно самолепным аллокатором примерно такого вида:
template <class Element,
std::size_t Size,
class SharedWrapper = Element>
class StaticSharedAllocator {
public:
static constexpr std::size_t kSize = Size;
using value_type = SharedWrapper;
using pool_type = StaticPool<Element, kSize>;
pool_type &pool_;
using ElementPlaceHolder = pool_type::value_type;
template <class U>
struct rebind {
using other = StaticSharedAllocator<Element, kSize, U>;
};
StaticSharedAllocator(pool_type &pool) : pool_{pool} {}
~StaticSharedAllocator() = default;
template <class Other, std::size_t OtherSize>
StaticSharedAllocator(const StaticSharedAllocator<Other, OtherSize> &other)
: pool_{other.pool_} {}
auto allocate(std::size_t n) -> value_type * {
static_assert(sizeof(value_type) <= sizeof(ElementPlaceHolder));
static_assert(alignof(value_type) <= alignof(ElementPlaceHolder));
static_assert((alignof(ElementPlaceHolder) % alignof(value_type)) == 0u);
return reinterpret_cast<value_type *>(pool_.allocate
);}
auto deallocate(value_type *p, std::size_t n) -> void {
pool_.deallocate(reinterpret_cast<value_type *>(p), n);
}
};
Очевидно, Element – тип целевого объекта, который и должен храниться как разделяемый объект. Size – максимальное число объектов данного типа, которое можно создать через аллокатор. SharedWrapper – это тип объектов, которые будут храниться в контейнере на самом деле!
Конечно, вы знаете, что для работы shared_ptr необходима некоторая дополнительная информация, которую нужно где-то хранить, лучше прямо с целевым объектом вместе. Поэтому для этого аллокатора очень важна структура rebuild. Она используется в недрах стандартной библиотеки, где-то в районе alloc_traits.h, чтобы привести аллокатор к виду, который необходим для работы разделяемого указателя:
using type = typename _Tp::template rebind<_Up>:
ther;где _Tp это StaticSharedAllocator<Element, Size>,
_Up это std::_Sp_counted_ptr_inplace<Object, StaticSharedAllocator<Element, Size>, __gnu_cxx::_S_atomic>
К сожалению, это верно только для GCC, в IAR тип будет немного другой, но общий принцип неизменен: нам нужно сохранить немного больше информации, чем содержится в Element. Для простоты тип целевого объекта и расширенный тип должны быть сохранены в шаблонных параметрах. Как вы уже догадались, SharedWrapper и будет расширенным типом, с которым непосредственно работает shared_ptr.
Лично я не нашел ничего лучше, чем просто резервировать немного больше места в хранилище или пулле объектов. Размер дополнительного пространства подобран эмпирически, ибо разным компиляторам нужен разный объем дополнительной памяти.
Само хранилище создается отдельно и передается в конструктор аллокатора именно потому, что allocate_shared работает не напрямую с переданным аллокатором, а с его копией. Поскольку этой функции нужен аллокатор, работающий с расширенным типом. Шаблонный конструктор копий тоже задействован, а пул объектов должен работать с любым из этих аллокаторов.
Еще немного кода для иллюстрации
Все эти изуверства позволили избежать динамического выделения памяти и здесь. Хотя, мне кажется, лучше реорганизовать код так, чтоб не было необходимости использовать shared_ptr вообще. К сожалению, не всегда рефакторинг можно сделать быстро и безболезненно.
std::function
Универсальная полиморфная обертка над функциями или функциональными объектами. Очень удобная штука. Точно была бы полезна в embedded проекте, хотя бы для каких-нибудь функций обратного вызова (callbacks).Чем мы платим за универсальность?
Во-первых, std::function может использовать динамическую аллокацию памяти.
Небольшой и несколько искусственный пример:
int x[] = {1, 2, 3, 4, 5};
auto sum = [=] () -> int {
int sum = x[0];
for (size_t i = 1u; i < sizeof(x) / sizeof(int); i++) {
sum += x;
}
return sum;
};
std::function<int()> callback = sum;
Когда элементов массива 5, то размер функции – 20 байт. В этом случае, когда мы присваиваем переменной callback экземпляр нашей лямбда-функции, будет использована динамическая аллокация.
Дело в том, что в классе нашей универсальной обертки содержится небольшой участок памяти (place holder), где может быть определена содержащаяся функция.
Любая функция в С++ может быть определена с помощью двух указателей максимум. Для свободных функций или функторов достаточно одного указателя, если нужно вызвать метод класса, то нужен указатель на объект и смещение внутри класса. Собственно, у нас есть небольшое укромное местечко для пары указателей. Конечно, небольшие функциональные объекты можно хранить прямо на месте этих указателей! Если размер лямбды, например, не позволяет целиком запихать ее туда, то на помощь снова придет динамическая аллокация.
Для GCC
Опции -specs=nano.specs уже не будет хватать для std::function.Сразу появится сообщения подобного вида:
Правильно, ведь пустая функция должна бросать исключение.abort.c
signalr.c
signalr.c
Нужна другая опция -specs=nosys.specs, где включены все необходимые заглушки для всяких системных функций.
Соберем небольшую прошивку, чтоб проверить как повлияет включение std::function на потребление памяти различных видов. Прошивка – стандартный пример от ST для подмигивающего светодиода. Изменения в размере секций файла-прошивки в таблице:
| Δtext | Δdata | Δbss |
| 67 880 | 2 496 | 144 |
Внутри std::function явно вызываются исключения, которые внутри себя используют demangling для имен функций, и это дорогое удовольствие. Нужно ли это в небольших устройствах? Скорее всего, любоваться красивыми именами не придется.
Если заглянуть в получившийся elf-файл, то можно увидеть много новых символов. Отсортируем их по размеру и посмотрим на самые жирные.
00000440 cplus_demangle_operators
0000049e __gxx_personality_v0
000004c4 d_encoding
000004fe d_exprlist
00000574 _malloc_r
0000060c d_print_mod
000007f0 d_type
00000eec _dtoa_r
00001b36 _svfprintf_r
0000306c d_print_comp
Много функций с префиксом d_* – функции из файла cp-demangle.c библиотеки libiberty, которая, как я понимаю, встроена в gcc, и не так просто выставить ее за дверь.
Также имеются функции для обработки исключений (bad_function_call, std::unexpected, std::terminate)
_sbrk, malloc, free – функции для работы с динамическим выделением памяти.
Результат ожидаемый – флаги -fno-exceptions и -fno-rtti не спасают.
Внедрим второй подобный функциональный объект в другой единице трансляции:
| Δtext | Δdata | Δbss |
| 67992 | 2504 | 144 |
Показательно также то, сколько объектных файлов и из каких библиотек мы используем для этих случаев.
Для случая без std::function список короткийДля случая с std::function список гораздо длиннее
А что IAR?
Все устроено немного иначе. Он не требует явного указания спецификации nano или nosys, ему не нужны никакие заглушки. Этот компилятор все знает и сделает все в лучшем виде, не нужно ему мешать.| Δtext | Δro data | Δrw data |
| 2 958 | 38 | 548 |
Добавились символы из двух новых объектных файлов:
Конечно же, появились функции и данные для работы с динамической памятью, как в случае GCC.
Естественно, никаких выделений в куче нет, но IAR приготовился: видно, что он создал структуру gm (global malloc: a malloc_state holds all of the bookkeeping for a space) и некоторые функции для работы с этой структурой.
Объектный файл того юнита, в котором была добавлена функция, тоже ощутимо располнел:
до
после
Файл прибавил более 1Кб. Появилась std::function, ее сопряжение с лямбдой, аллокаторы.
Добавление второго такого функционального объекта в другую единицу трансляции дает нам очередной прирост:
| Δtext | Δro data | Δrw data |
| 3 998 | 82 | 600 |
Убедившись, что моя примитивная реализация function работает и не требует много памяти, перенес ее в проект, заменив все std::function, до которых смог дотянуться. С чувством выполненного долга я отправился на набережную любоваться закатом.
Дома меня поджидало письмо от коллеги, преисполненное благодарности. Он писал, что благодаря отказу от богомерзких std::function проект сильно схуднул, мы все молодцы! Сочившееся из меня самодовольство брызнуло во все стороны. Прилагался также классический рекламно-наглядный график до-после, вопивший об уменьшении размера отладочной версии прошивки аж на 30 процентов. В абсолютных величинах цифра была еще страшнее, это, на минуточку, целых 150 килобайт! Что-о-о-о? Улыбка довольного кота медленно отделилась от лица и стремительным домкратом полетела вниз, пробивая перекрытия. В коде просто нет столько колбэков, чтоб хоть как-то можно было оправдать этот странный феномен. В чем дело?
Смотря на сонное спокойствие темной улицы, раскинувшейся внизу, я твердо решил, что не сомкну глаз, пока не отыщу ответ. Проснувшись утром, в первую очередь сравнил два разных elf-файла: до и после замены std::function. Тут все стало очевидно!
В одном забытом богом и кем-то из разработчиков заголовочном файле были такие строчки:
using Handler = std::function<void()>;
static auto global_handlers = std:
air<Handler, Handler> {};И это в заголовочном файле. Насколько я смог понять, эти функции использовались для создания бледного подобия shared_ptr, увеличивая и уменьшая счетчик ссылок на ресурс в конструкторе и деструкторе соответственно. В некотором роде такой подход даже работал, только для каждой единицы трансляции отдельно. Впрочем, это почти нигде уже не использовалось, но за каждое включение заголовочного файла приходилось платить примерно одним килобайтом памяти. А включений было предостаточно. Да, в релизной версии почти все вырезалось, но в отладочной оптимизация выключена и компилятор честно создавал все эти бесполезные объекты.
Понятно, чего хотел добиться неизвестный мне автор, и это вполне могло получиться. Начиная с 17-го стандарта, в заголовочном файле можно разместить некие глобальные объекты, которые будут видны и в других единицах трансляции. Достаточно вместо static написать inline. Это работает даже для IAR. Впрочем, я не стал изменять себе и просто все убрал.
Вот тут я все же не удержатся от объяснения очевидных вещей
Вывод будет весьма банален: нужно понимать, что делаешь... и соответствовать стандартам SIL!
С++ может быть прекрасным языком, если не подпускать к нему посредственных разработчиков. Поэтому я сейчас со статьей заканчиваю, а то пол в офисе не успею домыть.
Всем спасибо, всем удачи!
Источник статьи: https://habr.com/ru/company/auriga/blog/539760/