Порядок компиляции файлов Опции

[sergey sva]

Для компиляции исходников используется маке файл в gcc, Во время написания маке файла возник
вопрос, в каком порядке лучше компилировать файлы?, попробовал очередность поменял ошибок нет,
в сети поискал, не чего нужного не нашел, может есть какие рекомендации ?

[zltigo]

Во время написания маке файла возник
вопрос, в каком порядке лучше компилировать файлы?,

Ну...., если-бы Вы до начала "написания" ознакомились с основополагающим принципом работы makе ( и про компиляторы-линкеры-библиотекари надо почитать, естественно в первую очередь ), то и вопрос не мог возникнуть в принципе

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

АБСОЛЮТНО безразлично.

[ARV]

АБСОЛЮТНО безразлично.

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

[MrYuran]

или компоновщик более интеллектуальный и тасует секции (если можно, конечно) уже после компиляции сам?
вообще, есть смысл в моих размышлениях или они надуманы?

есть такая опция -shared, которая позволяет видеть компилятору все исходники одновременно, что позволяет максимально оптимизировать код.
По-моему, так.

[msalov]

или компоновщик более интеллектуальный и тасует секции (если можно, конечно) уже после компиляции сам?

Секции располагаются согласно порядку указанному в скрипте линкера, если вас что-то не устраивает или есть сомнения - штудируйте мануалы и правьте скрипты.

[ARV]

есть такая опция -shared, которая позволяет видеть компилятору все исходники одновременно, что позволяет максимально оптимизировать код.
По-моему, так.

а по-моему, совсем не так. и использовать -shared для AVR по-моему смысла не имеет.... кстати, это опция компоновщика, а не компилятора.

Секции располагаются согласно порядку указанному в скрипте линкера, если вас что-то не устраивает или есть сомнения - штудируйте мануалы и правьте скрипты.

ладно, если вы прочли все мануалы, прошу вас ответить: а функции из модулей компонуются в секцию .text в порядке обработки модулей или как-то иначе? и на каком этапе выполняется замена дальних вызовов короткими - до компоновки всех функций всех файлов в одну секцию или после компоновки функций каждого файла?

[zltigo]

а позволю себе вопрос: вот у компоновщика есть опция relax - когда он ..

Позволю себе заменить, что вопрос был о "компиляторе", а не о "линкере", хотя, возможно, автор их просто не отличает . Линкеры по нынешним временам, тоже стали навороченными и линкуют, бывает, не из классических "объектиков" из неких промежуточных представлений, но по любому даже, если речь идет о линкере оказать разумную помощь подсовывая ему объекты линковки в "оптимальном" порядке не светит.

[ARV]

Позволю себе заменить, что вопрос был о "компиляторе", а не о "линкере", хотя, возможно, автор их просто не отличает . Линкеры по нынешним временам, тоже стали навороченными и линкуют, бывает, не из классических "объектиков" из неких промежуточных представлений, но по любому даже, если речь идет о линкере оказать разумную помощь подсовывая ему объекты линковки в "оптимальном" порядке не светит.

логично.
мой вопрос был продиктован тем, что где-то я встречал крик души (по-моему, даже на этом форуме), что от перестановки порядка функций в файле менялся размер итогового файла, дескать, это позволяло оптимизатору находить нечто общее в них... вот и предположил, что и изменение порядка сборки может создать подобные прецеденты...

P.S. C учетом того, что по идеологии GCC весь процесс компиляции и сборки может заключаться во вводе единственной командной строки для (как там правильно?) front-end компилятора, не удивительно, что многие начинают не различать компиляцию и компноновку

[Сергей Борщ]

ладно, если вы прочли все мануалы, прошу вас ответить: а функции из модулей компонуются в секцию .text в порядке обработки модулей или как-то иначе?

Предлагаете пересказать вам документацию? Линкер обрабатывает файлы в том порядке, в каком они указаны в его командной строке. Входные секции раскладываются в выходные в том порядке, который указан в скрипте линкера. А вариантов там предусмотрено множество - от поименного указания каждого файла или группы файлов до сортировки их по нескольким критериям. Т.е. это означает, что если в скрипте указана сортировка по именам и в командной строке указаны файлы a.o, c.o, b.o, то при добавлении секции text из b.o она будет вставлена между a.text и c.text. А если в скрипте не указана сортировка - то будет добавлена вслед за c.text

Но порядок компиляции не влияет ни на что.

во вводе единственной командной строки для (как там правильно?) front-end компилятора,

программа gcc (gcc.exe) - драйвер. Она вызывает остальные программы (препроцессор, компилятор, ассемблер, линкер). Это легко увидеть, запустив компиляцию с ключем -v. front-end переводит текст с языка высокого уровня во внутреннее представление, back-end генерит из внутреннего представления ассемблерный текст для целевого процессора. Подробности тут.

[ARV]

Предлагаете пересказать вам документацию?

не то чтобы предлагаю... а так, ненавязчиво намекаю если вы по каким-либо причинам ее освоили полностью - вам не сильно это трудно, а вот так взять и (даже просто бегло) прочитать всю документацию на GCC - это лично для меня просто непосильный труд! кое-что вычитываю, конечно, но чтобы все...

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

это было изначально ясно (мне). но вопрос - влияет ли на результат компоновки порядок поступления функций - остался открытым...

Но порядок компиляции не влияет ни на что.

изначально ясно в квадрате

программа gcc (gcc.exe) - драйвер.

спасибо, с терминами бывают накладочки...

[Сергей Борщ]

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

Если в скрипте не указана сортировка - то влияет. Секции будут уклыдываться в том порядке, в котором поступают на вход линкера. Т.е. в том порядке, в котором передаются объектные файлы, а внутри каждого файла - в том порядке, в котором генерились из исходника.

если вы по каким-либо причинам ее освоили полностью

До этого еще далеко, но кое-что почитываем на досуге.

[ARV]

Если в скрипте не указана сортировка - то влияет.

вот! и это важно! спасибо.

[ReAl]

есть такая опция -shared, которая позволяет видеть компилятору все исходники одновременно, что позволяет максимально оптимизировать код. По-моему, так.

--combine --whole-program
combine для того, чтобы все перечисленные в командной строе исходники собрать в один объектник (сначала объединив в один исходник) а whole-program - чтобы рассматривал это как уже законченную программу. Благодаря этому неиспользуемые функции выбрасываются ещё не доходя до --gc-sections, мелкие функции "из другого файла" инлайнятся по месту и их отдельное тело выбрасывается (раз это уже вся программа, значит снаружи никто не вызовет) и т.д.
Вот только некоторые проблемы возникают, если в проекте есть асм-файл и он вызывет что-то из С-файла. С точки зрения собранных в кучу С-файлов та функция не вызывается вообще, поэтому она выбрасывается из файла а_тут_собраны_все_с.o и не находится при линковке.
Должно лечиться атрибутами used и externally_visible для той С-функции, которая вызывается из асм-файла, но пока не проверял, не очень зудит таким путём пытаться ещё уменьшить размер бинарника.

Да, аналогичная беда должна возникать при миксе С и С++, лучше и чисто-С-шные вещи тоже обрабатывать как С++, чтобы пошло на вход одного компилятора.

[ARV]

--combine --whole-program
combine для того, чтобы все перечисленные в командной строе исходники собрать в один объектник (сначала объединив в один исходник) а whole-program - чтобы рассматривал это как уже законченную программу.

не знаю, как на счет выбрасывания лишних функций (нет у меня пока таких), но вот инлайнинг функций из разных файлов не прокатывает с этими опциями... специально вынес содержимое главного цикла main() в другой файл в виде функции: увы, rcall как был, так и остался...

или я чего-то недопонял и недоделал?

[_Pasha]

но вот инлайнинг функций из разных файлов не прокатывает с этими опциями...

Так его и не будет. Из разных модулей проинлайнить что-либо невозможно.

[ReAl]

не знаю, как на счет выбрасывания лишних функций (нет у меня пока таких), но вот инлайнинг функций из разных файлов не прокатывает с этими опциями... специально вынес содержимое главного цикла main() в другой файл в виде функции: увы, rcall как был, так и остался...

или я чего-то недопонял и недоделал?

Возможно, та функция была слишком большая для его понятий об инлайне? Хотя однократно вызываемую могло бы и проинлайнтить.
1.c

Код

#include <avr/io.h>
#include "2.h"

void main()
{
    uint16_t start = get_tcnt1();
    for(;;) {
        uint16_t current;
        do current = get_tcnt1(); while( (uint16_t)(current - start) < 0x1234 );
        start = current;
        PORTB ^= 0x01;
    }
}

2.h

Код

uint16_t get_tcnt1();

2.c

Код

#include <avr/io.h>
#include "3.h"

uint16_t get_tcnt1()
{
    uint8_t srg = irg_save_and_disable();
    uint16_t tmp = TCNT1;
    irq_restore(srg);
    return tmp;
}

3.h

Код

uint8_t irg_save_and_disable();
void irq_restore(uint8_t srg);

3.c

Код

#include <avr/io.h>
#include <avr/interrupt.h>

uint8_t irg_save_and_disable()
{
    uint8_t temp = SREG;
    cli();
    return temp;
}

void irq_restore(uint8_t srg)
{
    SREG = srg;
}

do.bat

Код

set avrgcc=c:\WinAVR-20081205\bin
%avrgcc%\avr-gcc -Wall -Wextra --version  2>&1
%avrgcc%\avr-gcc -Wall -Wextra -Os --combine --whole-program -mmcu=atmega8 -Wno-main 1.c 2.c 3.c  2>&1
%avrgcc%\avr-objdump -d -S a.out >a.dump

c:\WinAVR-20081205

Код

0000005e <main>:
  5e:    8f b7           in    r24, 0x3f; 63
  60:    f8 94           cli
  62:    4c b5           in    r20, 0x2c; 44
  64:    5d b5           in    r21, 0x2d; 45
  66:    8f bf           out    0x3f, r24; 63
  68:    61 e0           ldi    r22, 0x01; 1
  6a:    8f b7           in    r24, 0x3f; 63
  6c:    f8 94           cli
  6e:    2c b5           in    r18, 0x2c; 44
  70:    3d b5           in    r19, 0x2d; 45
  72:    8f bf           out    0x3f, r24; 63
  74:    c9 01           movw    r24, r18
  76:    84 1b           sub    r24, r20
  78:    95 0b           sbc    r25, r21
  7a:    84 53           subi    r24, 0x34; 52
  7c:    92 41           sbci    r25, 0x12; 18
  7e:    a8 f3           brcs    .-22    ; 0x6a <main+0xc>
  80:    88 b3           in    r24, 0x18; 24
  82:    86 27           eor    r24, r22
  84:    88 bb           out    0x18, r24; 24
  86:    a9 01           movw    r20, r18
  88:    f0 cf           rjmp    .-32    ; 0x6a <main+0xc>
0000008a <_exit>:
  8a:    f8 94           cli
0000008c <__stop_program>:
  8c:    ff cf           rjmp    .-2     ; 0x8c <__stop_program>

c:\WinAVR-20071221

Код

0000005e <main>:
  5e:    8f b7           in    r24, 0x3f; 63
  60:    f8 94           cli
  62:    4c b5           in    r20, 0x2c; 44
  64:    5d b5           in    r21, 0x2d; 45
  66:    8f bf           out    0x3f, r24; 63
  68:    8f b7           in    r24, 0x3f; 63
  6a:    f8 94           cli
  6c:    2c b5           in    r18, 0x2c; 44
  6e:    3d b5           in    r19, 0x2d; 45
  70:    8f bf           out    0x3f, r24; 63
  72:    c9 01           movw    r24, r18
  74:    84 1b           sub    r24, r20
  76:    95 0b           sbc    r25, r21
  78:    84 53           subi    r24, 0x34; 52
  7a:    92 41           sbci    r25, 0x12; 18
  7c:    a8 f3           brcs    .-22    ; 0x68 <main+0xa>
  7e:    88 b3           in    r24, 0x18; 24
  80:    91 e0           ldi    r25, 0x01; 1
  82:    89 27           eor    r24, r25
  84:    88 bb           out    0x18, r24; 24
  86:    a9 01           movw    r20, r18
  88:    ef cf           rjmp    .-34    ; 0x68 <main+0xa>
0000008a <_exit>:
  8a:    ff cf           rjmp    .-2     ; 0x8a <_exit>

c:\WinAVR-20021209
UPD: Ой, наврал, у него не получается

Так его и не будет. Из разных модулей проинлайнить что-либо невозможно.

С этими опциями - на раз (не забыв указать в командной строке драйвера gcc все файлы проекта).
Причём даже с даже с переупорядочиванием кусков.

UPD2:Это хозяйство работает (из установленного у меня) начиная с avr-gcc 4.1.2 (WinAVR-20070525), для 3.4.6 (WinAVR-20060421) и более ранних - не работает, у них просто ключей таких нет.

[ARV]

ReAl, я делал практически точно так же, даже проще - функции у меня были много проще, разница лишь в том, что опцию я прописал в настройках компиляции Eclipse... возможно, где-то ошибся, проверю еще раз...

[ReAl]

опцию я прописал в настройках компиляции Eclipse... возможно, где-то ошибся, проверю еще раз...

Надо ведь ещё за один заход подсунуть gcc все C-исходники. Вероятнее всего, эклипс "как обычно" передал все .c отдельно на компиляцию в отдельные же .o