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

2 minutes ago, jcxz said:

Если Симулинк Матлаба для Вас - античная программа, то... :unknw:

"Чушь" лежит у меня в столе. Называется - "сдохший в прошлом году Intel SSD 540s". То что Вам на голову никогда не падал кирпич, совсем не говорит о том, что каски на стройках не нужны.

Ничто не вечно, у меня такой два года работает. У них был небольшой косяк с прошивкой, достаточно ее было обновить.

И бэкапы никто не отменяет. Это - святое, во все времена.

 

2 minutes ago, jcxz said:

 Расскажите лучше чем она поможет в случае компиляции проекта, в котором нет лишнего мусора, натасканного из чужих исходников, в которых не понимаешь что к чему?

Эта галочка не влияет на компиляцию и оптимизацию кода, а лишь помогаем линкеру потом убрать из исходной прошивки неиспользуемые объекты. Вот и все что она делает.

 

2 minutes ago, jcxz said:

Ну так и таскателю чужих исходников, который даже не может разобраться что к чему и какие функции нужны - ему никуда без галки "one section per function"?

И не только ему. 

Впрочем, никто ж не заставляет ставить эту галочку - это сугубо добровольное мероприятие )

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


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

43 минуты назад, Forger сказал:

Эта галочка не влияет на компиляцию и оптимизацию кода, а лишь помогаем линкеру потом убрать из исходной прошивки неиспользуемые объекты. Вот и все что она делает.

Ну как же "не влияет" если она не позволяет выполнять некоторые между-функциевые оптимизации (или ухудшает их)? Влияет.

Если функции (да и переменные/константы - тоже) находятся в одной секции .obj, то компилятор может выполнить оптимизации, зависимые от расстояния между адресами этих функций/переменных. Если в разных - не может.

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


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

4 minutes ago, jcxz said:

Ну ка же "не влияет" если она не позволяет выполнять некоторые между-функциевые оптимизации (или ухудшает их)? Влияет.

Если функции (да и переменные/константы - тоже) находятся в одной секции .obj, то компилятор может выполнить оптимизации, зависимые от расстояния между адресами этих функций/переменных. Если в разных - не может.

Я сравнивал у себя в проектах: если разница и была, то настолько незначительная, что даже не имело смысла заморачиваться. А вот код на выходе выходил заметно объемнее. 

Впрочем, в keil-е можно выборочно настроить настройки компиляции хоть на каждый файл индивидуально, хоть на группу файлов.

Для критичных файлом можно настроить наилютейшую оптимизацию без этой галки.

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


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

19 minutes ago, jcxz said:

Если функции (да и переменные/константы - тоже) находятся в одной секции .obj, то компилятор может выполнить оптимизации, зависимые от расстояния между адресами этих функций/переменных. Если в разных - не может.

Это делает не компилятор, а линкер, и называется это link-time optimazation. Хорошо работает для голых C библиотек и т. п. проектов.

На плюсах вообще никакой пользы не приносит. По крайней мере я не заметил чего-то выдающегося.

Впрочем у меня и проекты не шибко требовательные к размеру и скорости кода. Всего с большим запасом.

 

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


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

39 минут назад, Forger сказал:

Это делает не компилятор, а линкер, и называется это link-time optimazation. Хорошо работает для голых C библиотек и т. п. проектов.

Т.е. - Вы думаете, что линкёр Кейла изменяет команды CPU в коде?? :wacko2: А зачем тогда ему вообще компилятор? :wink:

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


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

12 minutes ago, jcxz said:

Т.е. - Вы думаете, что линкёр Кейла изменяет команды CPU в коде?? :wacko2: А зачем тогда ему вообще компилятор? :wink:

link-time optimization это лишь дополнение к возможностям линкера.

Линкер скажем так: корректирует команды CPU при линковке на базе работы после компилятора, ведь адреса объектов определяет именно линкер.

 

По-ходу мы не поняли друг друга, или я запутал народ:

размещение функций в РАЗНЫХ elf-секциях, дает возможность линкеру очень просто от них избавиться. Именно для этого и создана эта галочка.

Т. е. это НЕ ТО ЖЕ самое, что делать для каждого функции свой obj-файл.

 

 

 

 

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


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

Just now, jcxz said:

Т.е. - Вы думаете, что линкёр Кейла изменяет команды CPU в коде?? :wacko2: А зачем тогда ему вообще компилятор? :wink:

В старые добрые времена это выглядело так:

Quote

The feedback option produces a text file containing a list of unused functions, and functions that
have been inlined by the linker. This information can be fed back to the compiler, which can
rebuild the objects, placing these functions in their own sections. These sections can then be
removed by the linker during usual unused section elimination.

Таки да, изменяет команды CPU в коде!!!!111

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


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

3 часа назад, Forger сказал:

Линкер скажем так: корректирует команды CPU при линковке на базе работы после компилятора, ведь адреса объектов определяет именно линкер.

Я говорю не про адреса, а именно про код команд. Адреса понятно что линкер меняет на этапе линковки. Поэтому внешние ссылки (ведущие за пределы секции линковки) обычно длинные (32-битные). И линкер их просто корректирует. Я же говорил о следующем случае:

void Func1()
{
  ...
  if (...) {
    Func2()
    return;
  }
  ...
}

void Func2() {...}

В этом случае, если Func1() и Func2() - обе в пределах одной секции, то вполне возможно, что хватит 16-битного варианта команды условного или безусловного перехода и компилятор поставит её (в точке вызова Func2()).

Но если Func1() и Func2() разнести в разные секции, то как компилятору определить - хватит ли короткого варианта перехода или нет? Ему придётся использовать длинный вариант (с диапазоном -16777216...+16777214).

А что значит "корректирует команды"? Думаете линкер, меняет команду перехода на более длинную (или короткую), а затем и весь остальной код (который после этого сдвинется), корректирует? А если вдруг в результате этого действия, какая-то из команд перестала дотягиваться до своих данных или целевой точки перехода, то и эти команды на другие - тоже меняет? 

Есл линкер это делает, то это собственно полная переделка всего кода, произведённого компилятором. Зачем тогда компилятор? :unknw:

Цитата

размещение функций в РАЗНЫХ elf-секциях, дает возможность линкеру очень просто от них избавиться. Именно для этого и создана эта галочка.

Понятно, что оно для этого. Только полезно это (имхо) главным образом для библиотек.

3 часа назад, aaarrr сказал:

В старые добрые времена это выглядело так:

Таки да, изменяет команды CPU в коде!!!!111

Ну так это не сам линкер меняет, а "он сообщает обратно компилятору, который всё переделывает". В принципе возможно и так конечно.

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


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

8 minutes ago, jcxz said:

Только полезно это (имхо) главным образом для библиотек.

В проектах выигрыш по объему прошивки есть и сильно зависит от внешних применяемых библиотек.

Что дает положительного отказ от этого? Да ничего

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


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

11 минут назад, Forger сказал:

В проектах выигрыш по объему прошивки есть и сильно зависит от внешних применяемых библиотек.

Выигрыш если эта галка была установлена при сборке этих библотек. Не надо путать. Галка в самом проекте никак не влияет на внешнюю библиотеку.

Цитата

Что дает положительного отказ от этого? Да ничего

Да вроде уже подробно всё разжевал... :unknw:

Впрочем - если у вас Кейл генерит код исключительно только с длинными переходами, то конечно никакого увеличения кода от установки галки не заметите - он и так максимально большой :biggrin:

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


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

Нашёл в своём проекте кусок кода, иллюстрирующий мои слова:

Скрытый текст

   \                                 In section .text, align 2, keep-with-next
     84          u64 JsonInput::IParseString(JsonInput *o, u8 const *si, u8 const *sie)
     85          {
   \                     _ZN9JsonInput12IParseStringEPS_PKhS2_: (+1)
   \   00000000   0xB5F8             PUSH     {R3-R7,LR}
   \   00000002   0x460C             MOV      R4,R1
...
   \   00000014   0x4294             CMP      R4,R2
   \   00000016   0xD102             BNE.N    ??IParseString_3
   \   00000018   0x8081             STRH     R1,[R0, #+4]
   \   0000001A   0x80C3             STRH     R3,[R0, #+6]
   \   0000001C   0x....             B.N      ?Subroutine2  //Смотрим сюда! Использовано 12-битное смещение перехода к ?Subroutine2!
   \                     ??IParseString_3: (+1)
   \   0000001E   0x7825             LDRB     R5,[R4, #+0]
   \   00000020   0xF1B5 0x0680      SUBS     R6,R5,#+128
...
   \                     ??IParseString_27: (+1)
   \   00000154                      REQUIRE ?Subroutine0
...
...     
   \                                 In section .text, align 2, keep-with-next
   \                     ?Subroutine2: (+1)
   \   00000000   0x4621             MOV      R1,R4
   \   00000002   0x2400             MOVS     R4,#+0
   \   00000004   0xF044 0x000D      ORR      R0,R4,#0xD
   \   00000008   0xBDF4             POP      {R2,R4-R7,PC}
...
...  
   \                                 In section .text, align 2, keep-with-next
    343          u64 JsonInput::IParseCommon(JsonInput *o, u8 const *si, u8 const *sie)
    344          {
   \                     _ZN9JsonInput12IParseCommonEPS_PKhS2_: (+1)
   \   00000000   0xB5F8             PUSH     {R3-R7,LR}
   \   00000002   0x4605             MOV      R5,R0
   \   00000004   0x460C             MOV      R4,R1
...
   \                     ??IParseCommon_0: (+1)
   \   00000028   0x42B4             CMP      R4,R6
   \   0000002A   0xD1F1             BNE.N    ??IParseCommon_1
   \   0000002C   0x7029             STRB     R1,[R5, #+0]
   \   0000002E   0x....             B.N      ?Subroutine2    //И смотрим сюда! Опять использовано 12-битное смещение перехода к ?Subroutine2!
    357              if (j == SI_BEGIN) {
   \                     ??IParseCommon_2: (+1)
   \   00000030   0x2904             CMP      R1,#+4
   \   00000032   0xD104             BNE.N    ??IParseCommon_5
...

 

Как видно - компилятор (IAR) использовал короткие (2-байтные) инструкции переходов для вызова ?Subroutine2.

А если-б ему нужно было выделять ?Subroutine2 в отдельную секцию объектного файла, то ему видимо пришлось бы в двух точках, где делается B.N ?Subroutine2, ставить длинный вариант команды безусловного перехода (который дотягивается до -16777216...+16777214). Так как он не знал бы как линкер расположит эти секции одна относительно другой в выходном образе прошивки. И результирующий образ получился бы на 4 байта больше. :unknw:

 

PS: Хотя - наличие точек в коде инструкции перехода наводит на мысль, что и их длина зачем-то (и кем-то) вычисляется на каком-то этапе.... :umnik2:

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


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

1 hour ago, jcxz said:

Выигрыш если эта галка была установлена при сборке этих библотек. Не надо путать. Галка в самом проекте никак не влияет на внешнюю библиотеку.

Если галка была установлена ТАКЖЕ на применяемых в проекте библиотеках, то выигрыш будет еще БОЛЬШЕ. Но будет в любом случае.

 

Quote

Впрочем - если у вас Кейл генерит код исключительно только с длинными переходами, то конечно никакого увеличения кода от установки галки не заметите - он и так максимально большой :biggrin:

Никто никому не запрещает придумывать небылицы ))

Сам Keil не генерит НИКАКОГО кода. Это делает компилятор и линковщик, причем оба непосредственно от ARM. Платные.

https://developer.arm.com/tools-and-software/embedded/arm-compiler/downloads/version-6

 

43 minutes ago, jcxz said:

PS: Хотя - наличие точек в коде инструкции перехода наводит на мысль, что и их длина зачем-то (и кем-то) вычисляется на каком-то этапе.... :umnik2:

Вот вот. Понимание приходит не сразу )))

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


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

2 hours ago, jcxz said:

Ну так это не сам линкер меняет, а "он сообщает обратно компилятору, который всё переделывает". В принципе возможно и так конечно.

По-мелочи меняет:

5 hours ago, aaarrr said:

The feedback option produces a text file containing a list of unused functions, and functions that
have been inlined by the linker.

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


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

14 hours ago, Forger said:

у него как я понял нет гипертрединга, т.е. всего 6 потоков

Да, это так) В иаре тоже компилить быстро стал. 6 файлов зарас. И cppcheck шустро себя ведёт.

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


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

6 hours ago, aaarrr said:

По-мелочи меняет:

Как я понимаю, он удаляет неиспользуемые функции и вставляет (мелкие по размеру?) вместо вызовов. И сообщает об этом компилятору.

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


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

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

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

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

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

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

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

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

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

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