porty 0 2 апреля, 2012 Опубликовано 2 апреля, 2012 · Жалоба Добрый день. Пишу для 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 Куда девается остальное? И почему это происходит? Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RCray 0 2 апреля, 2012 Опубликовано 2 апреля, 2012 · Жалоба 2 map файла сравните Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
unkier 0 3 апреля, 2012 Опубликовано 3 апреля, 2012 · Жалоба отладка ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
porty 0 4 апреля, 2012 Опубликовано 4 апреля, 2012 · Жалоба отладка ? нет, это не отладка, я смотрю размер bin файла для прошивки и внутри него нет отладочных таблиц, имён переменных и тд. И судя по мап файлу это не отладочные функции типа printf чере уарт как на кортекс М1 для фпга. Поглядел мап файл - оказалось что почему то на уровне оптимизации -О3 оптимизатор ряд вызовов функций делает как инлайновые особенно когда внутри одной функции вызывается десяток раз другая подфункция, он этот вызов разворачивает как inline и функция уже занимает не 100 инструкций а 2000...3000, внутри того файла в который вношу правки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 4 апреля, 2012 Опубликовано 4 апреля, 2012 · Жалоба ... Поглядел мап файл - оказалось что почему то на уровне оптимизации -О3 оптимизатор ряд вызовов функций делает как инлайновые особенно когда внутри одной функции вызывается десяток раз другая подфункция, он этот вызов разворачивает как inline и функция уже занимает не 100 инструкций а 2000...3000, внутри того файла в который вношу правки. А какие результаты будут с "-Os"? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
porty 0 4 апреля, 2012 Опубликовано 4 апреля, 2012 · Жалоба А какие результаты будут с "-Os"? при -Os всё норм, это только в -О3 постоянно творится и в -О2 нередко помню было, но тогда ещё не предавал значения. Но всё бы ничего, но фильтры не успевают в режиме реального времени на -Оs, на -О2 только если с бубном поплясать а на -О3 вообще всё отлично, можно алгоритмы не подвергать даже рефакторингу по скорости, тем самым сохраняя читаемость и понятность. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 4 апреля, 2012 Опубликовано 4 апреля, 2012 · Жалоба при -Os всё норм, это только в -О3 постоянно творится и в -О2 нередко помню было, но тогда ещё не предавал значения. Но всё бы ничего, но фильтры не успевают в режиме реального времени на -Оs, на -О2 только если с бубном поплясать а на -О3 вообще всё отлично, можно алгоритмы не подвергать даже рефакторингу по скорости, тем самым сохраняя читаемость и понятность. Надо понимать какие оптимизации входят в соответствующие "O" 0) O0 - без оптимизаций. Имеет смысл только для упрощения отладки (более очевидным образом в отладчике происходит переход от одной строчки кода к другой). 1) O1 - оптимизации, которые не сказываются ни на увеличении времени компиляции, ни на размере получаемого бинарного кода. 2) O2 - оптимизации, которые приводят к увеличению времени компиляции, но не на размере получаемого бинарного кода. 3) O3 - оптимизации, которые вдобавок приводят к увеличению размера получаемого кода. 4) Os - оптимизация по размеру кода. P.S. Если какую-нибудь оптимизацию из O2 разработчики компилятора ускорят (уменьшат время компиляции с данной оптимизацией), то это оптимизацию перенесут в O1. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 4 апреля, 2012 Опубликовано 4 апреля, 2012 · Жалоба Но всё бы ничего, но фильтры не успевают в режиме реального времени на -Оs, на -О2 только если с бубном поплясать а на -О3 вообще всё отлично, можно алгоритмы не подвергать даже рефакторингу по скорости, тем самым сохраняя читаемость и понятность. А есть ли проблема? Если памяти хватает, то и дёргаться не нужно. Опять же, можно разные исходники компилировать с разным уровнем оптимизации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
porty 0 4 апреля, 2012 Опубликовано 4 апреля, 2012 · Жалоба А есть ли проблема? Если памяти хватает, то и дёргаться не нужно. Опять же, можно разные исходники компилировать с разным уровнем оптимизации. извиняюсь, забыл сказать что: проблема как раз в том что уже около 60кбайт из 65кб максимума и оно в добавок при мелких правках подпрыгивает до 62 .. 63кб, и один раз просто не влезло в 65кб, вылечил обновлением gcc, но такая повадка осталась. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 4 апреля, 2012 Опубликовано 4 апреля, 2012 · Жалоба -fno-inline в параметрах указывали? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться