C пространство памяти и #defines
Я провел большую часть прошлой недели при университетской отладке изучения библиотеки параллельного кода. Центральной проблемой является параллельный код, недетерминировано. Как правило, академическая отладка попала в один из трех лагерей здесь:
- Event-trace/replay. Это требует монитора события и затем рассмотрения событий, которые были отправлены. В платформе UT это включило бы вручную отправку событий как часть теста и затем выполнение посмертных обзоров.
- Scriptable. Это - то, где Вы взаимодействуете с рабочим кодом с рядом триггеров. "На x> нечто, baz ()". Это могло быть интерпретировано в платформу UT, где у Вас есть система во время выполнения, инициировавшая данный тест на определенном условии.
- Интерактивный. Это, очевидно, не будет работать в автоматической ситуации с тестированием.;)
Теперь, как выше комментаторов заметили, можно разработать параллельную систему в более детерминированное состояние. Однако, если Вы не делаете этого правильно, Вы просто вернулись к разработке последовательной системы снова.
Мое предложение состояло бы в том, чтобы сфокусироваться на наличии очень строгого протокола дизайна о том, что является поточным и что не становится потоковым. При ограничении интерфейса так, чтобы были минимальные зависимости между элементами, это намного легче.
Удача, и продолжают работать над проблемой.
4 ответа
Нет, #defines не занимают места, если они не используются - #defines работают как find / replace; всякий раз, когда компилятор видит левую половину, он заменяет ее правой половиной перед фактической компиляцией.
Итак, если у вас есть:
float f = SIGNAL1;
Компилятор буквально интерпретирует оператор:
float f = (float)0.03f;
Он будет никогда не видеть СИГНАЛ1, он не будет отображаться в отладчике и т. д.
Ну и да, и нет.
Нет, неиспользованные #defines не увеличивают размер результирующего двоичного файла.
Да, все #defines (используемые или неиспользованные) должны быть известны компилятору при построении двоичного файла.
По вашему вопросу немного неоднозначно, как вы используете компилятор, но почти кажется, что вы пытаетесь построить прямо на встроенном устройстве; вы пробовали кросс-компилятор? :)
unused #defines не занимает места в результирующем исполняемом файле. Они действительно занимают память в самом компиляторе при компиляции.
Обычно это исправляется путем ограничения количества определений типов и т. Д. это может занимать много места.
Кажется, вы несколько сбиты с толку, потому что typedef не занимает места во время выполнения. Это просто псевдонимы для типов данных. Теперь у вас могут быть экземпляры больших структур (typedef'd или иначе), но место занимает экземпляр, а не определение типа. Интересно, что «и т. Д.» Может охватывать этот оператор.
Экземпляры макросов заменяются в исходном коде их определениями, и код создается соответственно, неиспользованный макрос не приводит к созданию какого-либо сгенерированного кода.
Вещи, которые занимают место:
- Исполняемый код (функции / функции-члены)
- Создание экземпляров данных (включая экземпляры объектов C ++)
- Объем пространства выделяется стеку (или стекам в многопоточной системе).
То, что остается, обычно доступно для распределения динамической памяти (RAM) или не используется или предназначено для энергонезависимой памяти (Flash / EPROM).
] Уменьшение использования памяти в первую очередь связано с выбором / проектированием эффективных структур данных с использованием соответствующих типов данных, а также с эффективным дизайном кода и алгоритмов. Лучше всего нацеливаться на область, которая принесет наибольшую пользу. Чтобы увидеть размер объектов и кода в вашем приложении, попросите компоновщик сгенерировать файл карты. Это расскажет вам, какие функции являются самыми большими, а также размеры глобальных и статических объектов.
Длина текста исходного файла не является хорошим ориентиром для размера кода. Большой объем кода C является декларативным (обычно все файлы заголовков декларативны) и не генерирует код или данные, занимающие память.
Встроенная система не обязательно подразумевает небольшой объем памяти, поэтому вы должны указать. Я работал с системами с 64 Мб ОЗУ и 2 Мб флэш-памяти, и даже это скромно по сравнению со многими системами. Однако типичный микроконтроллер с ресурсами на кристалле, как правило, имеет намного меньше (особенно SRAM, которая занимает много места на кристалле). Также здесь имеет значение, является ли ваша система архитектурой Гарварда или архитектуры фон Неймана, поскольку в архитектуре Гарварда данные и пространства кода разделены, поэтому нам нужно знать, чего вам не хватает. Если фон Нейман, использование кода / данных по-прежнему актуально, если код выполняется из ПЗУ,