Jump to content

    
Sign in to follow this  
porty

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

Recommended Posts

Добрый день.

 

Пишу для 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

 

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

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

 

Спасибо.

Share this post


Link to post
Share on other sites
отладка ?

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

 

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

Share this post


Link to post
Share on other sites
...

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

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

Share this post


Link to post
Share on other sites
А какие результаты будут с "-Os"?

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
при -Os всё норм,

 

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

 

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

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

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

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

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

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

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

 

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites
А есть ли проблема? Если памяти хватает, то и дёргаться не нужно.

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this