Перейти к содержанию
    

Разбухание кода в STM32

Добрый день.

 

Пишу для STM32F100xxx

Использую стандартный GCC, codesourcery gcc arm toolchain

И Эклипс в качестве среды.

 

Встретился с непонятный поведением размера кода после компиляции.

Если добавить пару строк кода в любое место, например

 

было

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;
}

 

стало

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

 

Куда девается остальное?

И почему это происходит?

 

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

отладка ?

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

 

Поглядел мап файл - оказалось что почему то на уровне оптимизации -О3 оптимизатор ряд вызовов функций делает как инлайновые особенно когда внутри одной функции вызывается десяток раз другая подфункция, он этот вызов разворачивает как inline и функция уже занимает не 100 инструкций а 2000...3000, внутри того файла в который вношу правки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

...

Поглядел мап файл - оказалось что почему то на уровне оптимизации -О3 оптимизатор ряд вызовов функций делает как инлайновые особенно когда внутри одной функции вызывается десяток раз другая подфункция, он этот вызов разворачивает как inline и функция уже занимает не 100 инструкций а 2000...3000, внутри того файла в который вношу правки.

А какие результаты будут с "-Os"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А какие результаты будут с "-Os"?

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

Надо понимать какие оптимизации входят в соответствующие "O"

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

1) O1 - оптимизации, которые не сказываются ни на увеличении времени компиляции, ни на размере получаемого бинарного кода.

2) O2 - оптимизации, которые приводят к увеличению времени компиляции, но не на размере получаемого бинарного кода.

3) O3 - оптимизации, которые вдобавок приводят к увеличению размера получаемого кода.

4) Os - оптимизация по размеру кода.

 

P.S. Если какую-нибудь оптимизацию из O2 разработчики компилятора ускорят (уменьшат время компиляции с данной оптимизацией), то это оптимизацию перенесут в O1.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А есть ли проблема? Если памяти хватает, то и дёргаться не нужно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А есть ли проблема? Если памяти хватает, то и дёргаться не нужно.

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

извиняюсь, забыл сказать что: проблема как раз в том что уже около 60кбайт из 65кб максимума и оно в добавок при мелких правках подпрыгивает до 62 .. 63кб, и один раз просто не влезло в 65кб, вылечил обновлением gcc, но такая повадка осталась.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...