caxapa.ru :: Потому что за относительные адреса отвечает уже сборщик, компилятор не знает по какому адресу что будет лежать!

Zikon (29.06.2026 16:29, просмотров: 97) ответил Cкpипaч на Что-то я не понял, а почему этим линкер занимается, а не компилятор? Самая тема использовать его, как на старых интелях, как регистр сегмента данных (и тасовать в хвост и гриву, переставляя то туда, то сюда). Нет?

Потому что за относительные адреса отвечает уже сборщик, компилятор не знает по какому адресу что будет лежать!

Ответить

- Схера вдруг. На х86 - знал. Особенно на 8086. - Cкpипaч(29.06.2026 16:30)
  - Сейчас уже много изменилось и на линкер возложены функции не только по сборке, но и оптимизации - Zikon(29.06.2026 17:28)
  - вы наверно и про LTO не знаете ? - Zikon(29.06.2026 16:36)
    - LTO обычно не сильно меняет распределение ОЗУ - AlexBi(29.06.2026 19:50)
    - Не знаю, и пожалуй даже рад этому. Cкpипaч(68 знак., 29.06.2026 16:45)
      - LTO даёт 20..30%, бывает до 50% по размеру и по скорости. А работа с $gp - это штатное использование ABI (двоичного интерфейса приложений) для архитектуры RISC-V, хотя для косвенной адресации может быть использован любой другой регистр. Но именно этот регистр, по соглашению ABI, назначен глобальным указателем - для ускорения и уменьшения количества инструкций доступа к памяти и периферии. Nikolay_Po(91 знак., 29.06.2026 16:58)
        
        у меня lto в среднем 30% дает пожатия. чем больше и сложнее код - тем больше эффект. - klen(05.07.2026 10:38)
        
        А я заметил, что по ходу отладки и доводки, чем логичнее код, даже если количество его функций растёт, тем он меньше после LTO. Пишешь, добавляешь функционал, попутно делая код более стройным - и с каждой добавленной функцией, размер падает. Парадокс. - Nikolay_Po(05.07.2026 10:47)
        
        тут одно из двух на ум приходит - либо ты умеешь пишешь таколй охуэнный код что оптимазеру жало некуда воткнут, либо .... настолько хуевый что он моск себе ломает и плачет :) будем считать что имеем первое :) - klen(06.07.2026 12:26)
        
        Главное в гитхаб не выкладывать, а то разработчики AI, использующие материалы гитхаб для обучения, негодуют :-) reZident(1 знак., 06.07.2026 16:12, картинка)
        
        Типа такого: Nikolay_Po(702 знак., 06.07.2026 15:29)
        
        ...а системы автоматики Siemens дают 30...35% экономии теплоносителя. И то, и другое правда. Но почему-то раньше линкеры выбрасывали неиспользуемые сегменты кода/данных без LTO, а теперь - нет. - Cкpипaч(29.06.2026 17:02)
        
        Вы чего-то путаетесь. И без LTO, неиспользуемые секции выбрасываются. Удавалось заставить компилятор не выбрасывать только изменяя дефолтные настройки среды разработки. Уже более 5 лет использую LTO во всех проектах, где работает GCC или основанные на нём компиляторы. Не уверен, но, вроде, даже в Arduino IDE, LTE включено по-умолчанию, хотя в первой версии среды приходилось включать вручную, правкой файла конфигурации. - Nikolay_Po(29.06.2026 17:07)
        
        Сейчас - без LTO грусть. Раньше, неиспользуемые секции выбрасывались линкером без LTO. Cкpипaч(1273 знак., 29.06.2026 17:42)
        
        Сказали же - LTO это не про секции и функции. Это и так без LTO делается. LTO это когда, код даже выкидывается, например если в main запускаются 1-2 раза какие-то другие процедуры - то код просто встраивается и склеивается (нет вызовов этих процедур) (но это упрощённо). Может вообще System_Init и main склеить и код соптимизировать сразу. И это только одна из оптимизаций. - Zikon(29.06.2026 20:40)
        
        Выкидывание пролога/эпилога приносит 30% экономии?! Звездёж. - Cкpипaч(29.06.2026 20:42 - 20:45)
        
        Это же только одна из оптимизаций (выкидывание пролога/эпилога) после этого он ещё оптимизирует сам код, и многое другое делает ! - Zikon(29.06.2026 20:57)
        
        в Keil и GCC при ключах -Os или -Oz - LTO уменьшил код на 7-11% в тесте CoreMark, (Cortex-M0+ Cortex-M4), но код там небольшой. - Zikon(29.06.2026 20:53)
        
        Зачастую дофига приносит. Меня бы 30% не удивило в отдельных случаях. От кода же зависит, бывают перекосы в разные стороны. - SciFi(29.06.2026 20:45)
        
        ...и это только межмодульные вызовы, только то что компилятор постиснялся заинлайнить? Звездёж! - Cкpипaч(29.06.2026 20:48)
        
        Суть в том, что компилятор как бы видит все исходные файлы одновременно и может, например, посчитать на этапе компиляции выражения, содержащие переменные и вызовы функций из разных файлов. Там много возможностей открывается. Ну и в дизассемблере потом всё перепутано, отлаживать почти невозможно. - SciFi(29.06.2026 20:56)
        
        Отлаживать почти невозможно, тихо повторило эхо. - Cкpипaч(29.06.2026 22:16)
        
        И в режиме LTO вы листнги модулей не получите (нечитаемые). Там всё закодировано для линкера. - Zikon(29.06.2026 20:44)
        
        Грусть тоска. Люблю листинги. Особенно на бумаге с перфорированными полями. Таких уже не делают... - Cкpипaч(29.06.2026 20:46)
        
        Да какие проблемы? Выбираешь оптимизацию -Og (для отладки) - и листинг вполне нормально читается, дизассемблер вполне себе отлаживается. Nikolay_Po(515 знак., 30.06.2026 00:21)
        
        Речь вообще не об этом была. В эпоху 8086 регистры CS,DS спокойно загружал компилятор. Сколько раз нужно, столько и загружал. А тут какие-то танцы с бубном и нелепые отмазки. - Cкpипaч(30.06.2026 07:41)
        
        Если этот регистр gp постоянно перезагружать, пропадет вся экономия. Тут вся радость в том, что gp загружается один раз, а потом постоянно используется как база для индекса. Индекс достаточно большой, в 8086 такого большого смещения (+-2048) не было. - AlexBi(30.06.2026 09:52)
        
        Там только итоговый листинг сделать можно уже из elf файла. И там - да - хрен разберёш где какая функция - всё соптимизировано ! - Zikon(29.06.2026 20:59)

ARM, RISC-V контроллеры