Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Разбухание кода в STM32
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Porty
Добрый день.

Пишу для STM32F100xxx
Использую стандартный GCC, codesourcery gcc arm toolchain
И Эклипс в качестве среды.

Встретился с непонятный поведением размера кода после компиляции.
Если добавить пару строк кода в любое место, например

было
CODE

char *rs_tx_command;
char rs_tx_command_crc=0;
void rs_tx_command_add(char v)
{
rs_tx_command[rs_tx_command_count++]=v;
rs_tx_command_crc+=v;
}


стало
CODE

char *rs_tx_command;
char rs_tx_command_crc=0;
void rs_tx_command_add(char v)
{
if (rs_tx_command_count == 2)
{
rs_tx_command[rs_tx_command_count++] = RS_COMMANDS_EXTENDER; //RS_COMMANDS_EXTENDER = 0xFF
rs_tx_command_crc += RS_COMMANDS_EXTENDER;
}
rs_tx_command[rs_tx_command_count++]=v;
rs_tx_command_crc+=v;
}


то размер кода увеличивается на 2 килобайта, хотя по асм-листингу добавляется 10-20 команд всего.
Хотя если вносить изменения в других местах проекта не связанных с кодом а данными добавляемыми в флешь (как константы), например поменять константу с 8 битной на 32 битную или 64 битную то увеличивается размер кода на 4 или 8 байт.

Настройки:
командная строка компилятора
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Wall -ffunction-sections -O3 -fdata-sections -g

линковщика
arm-none-eabi-gcc -O3 -nostartfiles -Map=one_chanel.map -mcpu=cortex-m3 -mthumb -L${linkdir} -T${linkdir}\link.ld --gc-sections

Куда девается остальное?
И почему это происходит?

Спасибо.
RCray
2 map файла сравните
unkier
отладка ?
Porty
Цитата(unkier @ Apr 3 2012, 15:55) *
отладка ?

нет, это не отладка, я смотрю размер bin файла для прошивки и внутри него нет отладочных таблиц, имён переменных и тд. И судя по мап файлу это не отладочные функции типа printf чере уарт как на кортекс М1 для фпга.

Поглядел мап файл - оказалось что почему то на уровне оптимизации -О3 оптимизатор ряд вызовов функций делает как инлайновые особенно когда внутри одной функции вызывается десяток раз другая подфункция, он этот вызов разворачивает как inline и функция уже занимает не 100 инструкций а 2000...3000, внутри того файла в который вношу правки.
Petka
Цитата(Porty @ Apr 4 2012, 09:54) *
...
Поглядел мап файл - оказалось что почему то на уровне оптимизации -О3 оптимизатор ряд вызовов функций делает как инлайновые особенно когда внутри одной функции вызывается десяток раз другая подфункция, он этот вызов разворачивает как inline и функция уже занимает не 100 инструкций а 2000...3000, внутри того файла в который вношу правки.

А какие результаты будут с "-Os"?
Porty
Цитата(Petka @ Apr 4 2012, 11:26) *
А какие результаты будут с "-Os"?


при -Os всё норм,

это только в -О3 постоянно творится и в -О2 нередко помню было, но тогда ещё не предавал значения.

Но всё бы ничего, но фильтры не успевают в режиме реального времени на -Оs, на -О2 только если с бубном поплясать а на -О3 вообще всё отлично, можно алгоритмы не подвергать даже рефакторингу по скорости, тем самым сохраняя читаемость и понятность.
Petka
Цитата(Porty @ Apr 4 2012, 12:28) *
при -Os всё норм,

это только в -О3 постоянно творится и в -О2 нередко помню было, но тогда ещё не предавал значения.

Но всё бы ничего, но фильтры не успевают в режиме реального времени на -Оs, на -О2 только если с бубном поплясать а на -О3 вообще всё отлично, можно алгоритмы не подвергать даже рефакторингу по скорости, тем самым сохраняя читаемость и понятность.

Надо понимать какие оптимизации входят в соответствующие "O"
0) O0 - без оптимизаций. Имеет смысл только для упрощения отладки (более очевидным образом в отладчике происходит переход от одной строчки кода к другой).
1) O1 - оптимизации, которые не сказываются ни на увеличении времени компиляции, ни на размере получаемого бинарного кода.
2) O2 - оптимизации, которые приводят к увеличению времени компиляции, но не на размере получаемого бинарного кода.
3) O3 - оптимизации, которые вдобавок приводят к увеличению размера получаемого кода.
4) Os - оптимизация по размеру кода.

P.S. Если какую-нибудь оптимизацию из O2 разработчики компилятора ускорят (уменьшат время компиляции с данной оптимизацией), то это оптимизацию перенесут в O1.
scifi
Цитата(Porty @ Apr 4 2012, 12:28) *
Но всё бы ничего, но фильтры не успевают в режиме реального времени на -Оs, на -О2 только если с бубном поплясать а на -О3 вообще всё отлично, можно алгоритмы не подвергать даже рефакторингу по скорости, тем самым сохраняя читаемость и понятность.

А есть ли проблема? Если памяти хватает, то и дёргаться не нужно.
Опять же, можно разные исходники компилировать с разным уровнем оптимизации.
Porty
Цитата(scifi @ Apr 4 2012, 13:03) *
А есть ли проблема? Если памяти хватает, то и дёргаться не нужно.
Опять же, можно разные исходники компилировать с разным уровнем оптимизации.

извиняюсь, забыл сказать что: проблема как раз в том что уже около 60кбайт из 65кб максимума и оно в добавок при мелких правках подпрыгивает до 62 .. 63кб, и один раз просто не влезло в 65кб, вылечил обновлением gcc, но такая повадка осталась.
_Pasha
-fno-inline в параметрах указывали?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.