"Умная линковка" в компиляторах

[Q-Master]

Всем этим "аццким гемороем" занимается одна-единственная утилита smartlib и делает всё автоматически. Программисту остаётся только указать "линии разреза" между функциями, помещаемыми в библиотеку отдельно.

Притом она, эта утилита, очень полезна не только для SDCC, но и для tcc, DJGPP для Windows и т.д. Кстати, по методу Макса Феоктистова можно собирать сверхмаленькие EXE и DLL размером от 1 кб. Т.е. они в принципе получаются небольшими, без специальных ухищрений.

См. ниже. Утилита в целом-то не особенно и нужна.

Во-2, вы лично не адаптировали ни одной библиотеки для SDCC и рассуждаете чисто теоретически?

В чем состоит "адаптирование"?
Нечитаемость заключается в том, что в 1 гигантском файле находится огромное количество функций, которые представляют из себя кашу с совершенно разным функционалом никак не разделенную. В результате понять где что находится и как работает - то еще приключение.
Я говорю это все не голословно, а исключительно с точки зрения большого опыта.

Называю нехорошим словом то, что мне не нравится, да?

А как еще назвать то, во что превращается банальная компиляция 1 исходника? Реально получается мегапомойка из кучи *.c файлов с кучей ненужных инклюдов и прочего.

К слову, да, собирает дольше. Ну а как иначе. Но дольше не из-за разбивки, она происходит мгновенно. Дольше из-за того, что каждый кусок при сборке тянет свои хидеры, компилятору их надо заново парсить, это требует времени, в т.ч. и в случае варианта 1 от Sergey.

См. ниже. Проблема решается красивше, но не лучше.

Да чушь вы говорите. Разрабатываю библиотеки уже годами, ноль проблем. А вот пока не изобрёл такой способ - здесь некоторые товарищи бухтели про то, что "этот долбанный SDCC ещё и всё из библиотек тянет, оказывается, ай-яй-яй какой он нехороший".

Вы изобрели велосипед, причем с квадратными колесами и без педалей. Куда раньше велосипед изобрели писатели libtool.

Поясните.

Поясняю. Все элементарно и давно придумано в libtool. Решение простое и не требует никаких лишних "линий разреза" и утилит и решается исключительно компилятором (точнее пре-процессором).
Идея следущая:
в начале xxx.h подключается config.h в котором на каждую используемую ф-цию добавлена 1 строчка #define USE_XXXX 1 либо #undef USE_XXXX
в самом xxx.h и в xxx.c перед каждым определением и реализацией ф-ции стоит #ifdef USE_XXXX и в конце #endif. Полностью убирает проблему с резьбой мегафайла на кучу мелких и жутких тормозов компиляции. Не решает проблему гигантского сорца.

[Advertiser]

[Oleg N. Cher]

См. ниже. Утилита в целом-то не особенно и нужна.

Вам - конечно не особенно нужна, потому что вы не делаете библиотек для SDCC.

В чем состоит "адаптирование"?

В том, чтобы это собиралось и работало. И могло быть вызвано из сишного кода.

И когда мы говорим об адаптировании библиотек к SDCC, мы имеем ввиду что нам не тычут в носик асмовский исходник, а причёсывают его, переводят в синтаксис sdasz80, снабжают высокоуровневым интерфейсом, возможно, адаптируют передачу параметров, оптимизируют и, наконец, отлаживают. А если по канонам ZXDev, то ещё можно и соединить несколько сходных функций в одну с конфигуратором, за счёт чего достигается гибкость разработки. Подробнее здесь.

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

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

Во-вторых ясно, что сцеплять надо сходные функции, чтобы был цельный взгляд на библиотеку. Посмотрите внимательнее. Есть библиотека Basic, которая содержит реализацию операторов ZX-Basic. Это гигантская помойка не связанных между собой функций? Далее, Laser - функции Laser Basic, и т.д.

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

В результате понять где что находится и как работает - то еще приключение.

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

А как еще назвать то, во что превращается банальная компиляция 1 исходника? Реально получается мегапомойка из кучи *.c файлов с кучей ненужных инклюдов и прочего.

Я как раз критикую кучу *.c файлов. А знаете чем отличается куча файлов z88dk или, например, библиотек Сергея от моих? А ничем. Только у меня они имеют другие имена:

Basic_001.c
Basic_002.c
Basic_003.c
...

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

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

Я вот чего не пойму. Вы критикуете "большую кучу файлов" и способ z88dk и Сергея или мой и smartlib? Если последнее, то я не хочу и не собираюсь пихать каждую функцию в отдельный файл. Это антиоберонский путь. И античеловеческий.

Но, кстати, я сам связываю несколько обероновских модулей в одну библиотеку, это возможно. Притом без бубна, достаточно доброй воли и утилиты smarlib. Но и её я никому не навязываю, просто предлагаю кому нужно. Не вам, Q-Master. Я уже понял, что библиотек для SDCC вы делать не будете.

Идея следущая:
в начале xxx.h подключается config.h в котором на каждую используемую ф-цию добавлена 1 строчка #define USE_XXXX 1 либо #undef USE_XXXX
в самом xxx.h и в xxx.c перед каждым определением и реализацией ф-ции стоит #ifdef USE_XXXX и в конце #endif. Полностью убирает проблему с резьбой мегафайла на кучу мелких и жутких тормозов компиляции. Не решает проблему гигантского сорца.

Ну вот. Вы предложили "разрезание без разрезания", фактически то же самое, что и я, только более сложным способом. И потом, зачем мне вражеская libtool вместо моей крохотной smartlib, к которой Ofront я уже адаптировал.

Видите ли, в чём ещё проблема, Q-Master. Я компиляю сишные исходники, сгенерированные автоматически Ofront'ом. Поэтому вариант допихивать в них потом ручками #ifdef'ы выглядит абсолютно искусственно. Но это ещё полбеды, у варианта с libtool хватает и других недостатков.

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

[Q-Master]

Ну вот. Вы предложили "разрезание без разрезания", фактически то же самое, что и я, только более сложным способом. И потом, зачем мне вражеская libtool вместо моей крохотной smartlib, к которой Ofront я уже адаптировал.

Специально повторяюсь, поскольку заметил что Вы просто НЕ ЧИТАЕТЕ то что я пишу. Я сказал КАК в libtool, но не сказал что надо использовать libtool.
И мой (точнее стандартный) способ лишен тех проблем про которые говорит Витамин.
Более того, такой способ полностью убирает необходимость чего-либо куда-либо резать и компиляция происходит значительно оптимальнее. Если есть желание, то я могу написать утилиту, которая Вашу нарезку переводит в #ifdef #endif.

Видите ли, в чём ещё проблема, Q-Master. Я компиляю сишные исходники, сгенерированные автоматически Ofront'ом. Поэтому вариант допихивать в них потом ручками #ifdef'ы выглядит абсолютно искусственно. Но это ещё полбеды, у варианта с libtool хватает и других недостатков.

Думаю что доработать Ofront проблем вообще никаких нет.

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

Тогда я не понимаю проблемы с линковкой вообще. Ее просто нет. Более того, изначальный вопрос о вариантах после Ваших-же слов становится как-то бессмысленен. Если Вас все устраивает и Вы полностью отвергаете все предложения, то какой смысл был вообще что-то спрашивать?

PS: Я за свою жизнь понаписал столько всего и на стольких языках, что говорю, обычно, не "для галочки".

[NovaStorm]

>gcc
>есть в нем оптимизация или нет
LTO до сих пор скорее нет, чем есть.

[Vitamin]

LTO до сих пор скорее нет, чем есть.

На работу связки data-section/function-section/gc-sections это как-то влияет?

[Oleg N. Cher]

Sergey, спасибо. Это и правда может ускорить сборку библиотек. Будем экспериментировать.

Dear Alcoholics Anonymous,

In many ways you are right, and in many ways I agree with you. The difference between the two approaches is only in conceptual terms of thinking. So I think:

Many functions = One module = One source file (.h and .c) => One library

And you think:

One function = One module = One source file
Many functions = Many modules = Many source files => One library

I affirm in the dispute with Q-Master, that the first approach is more typical for Pascal/Oberon-world, and the second is typical for C-world.

So our discussion around this topic will be a dispute over paradigms and approaches: what assume a module? what assume a library? In general, I'm also against the spliting a C-source to pieces, but while SDCC has not support the feature, I need to have Pascal/Oberon point of view to this problem.

Also I see no obstacles to develop object-oriented libraries for XDev in Oberon-2 (with help of "smartlib" too, of course).

[Vitamin]

Наверное ты не заметил, что я говорил про старые компиляторы вообще, и про те, с которыми я работал, в частности. Перечитай пост, если от тебя это какбэ ускользнуло.

Ну а Q-Master говорил про основные используемые компиляторы (сиречь, более-менее современные). Перечитай пост, если от тебя это какбэ ускользнуло.

А ещё ты наверно не обратил внимание, что я говорил про DJGPP для Windows, и я не знаю, слышал ли ты вообще про такую доработку данного компилятора от Макса Феоктистова. Я говорил не про DJGPP для DOS32, и мы можем очень продуктивно обсудить данный вопрос, только ты в этой специфической области будешь какбэ некомпетентен. Уточню, речь идёт про наличие возможности пихать в статическую библиотеку код с одного сишного файла-исходника таким образом, чтобы при линковке из библиотеки брались только используемые сущности.

Я использовал djgpp для винды. ЕМНИП, оригинальный. В чем суть доработки?

P.S. Вот меня умиляет дикое количество здешних воинствующих сишников, не сделавших/адаптировавших ни одной библиотеки для Спека. А если я неправ, то ГДЕ ССЫЛКИ НА ЭТИ БИБЛИОТЕКИ?

Я делал библиотеки для спека на ассемблере.
Делал библиотеки для встроенных систем на С.
Делал библиотеки для довольно широкого спектра оборудования на С++.
Я воинствующий сишник?

[Oleg N. Cher]

Ну а Q-Master говорил про основные используемые компиляторы (сиречь, более-менее современные).

А зачем в контексте обозначения части компиляторов, в которых эта проблема не решена, говорить про компиляторы, где она решается? Я какбэ не настаиваю на использовании утилиты smartlib во всех случаях, но только там, где это будет уместно.

Я использовал djgpp для винды. ЕМНИП, оригинальный. В чем суть доработки?

Не знаю никакого DJGPP для винды, кроме MINGW. Ну и кроме патча Макса Феоктистова. Суть доработки в том, что оно - изначальное для DOS32 - заточено для генерации Win32 PE.

Я воинствующий сишник?

Не знаю куда ты себя относишь, но мне лично бы хотелось чтобы люди вибрировали на частоте конструктивности и творчества, а не придирались к формулировкам, отстаивая собственную важность, даже если эти формулировки не очень точные.

Нас с Сергеем смущает, что нас идут учить делать библиотеки люди, которые ни одной не сделали (имеются ввиду библиотеки для SDCC + ZX). Причём аргументируют тем, что какбэ, скорее всего, эта оптимизация в SDCC есть, они так думают - ну не может её не быть. Что грустно, потому что вопрос мною обнажён предельно, ибо обсуждался с Филиппом Краузе лично.

Поскольку здесь нет уточнения, то подразумеваются ВСЕ компиляторы, вне зависимости от года выпуска и целевой платформы. А это весьма снижает правдивость заявления, на что и указал Q-Master, не забыв привести критерий для рассматриваемого им круга компиляторов.

Цитирую.

Ни один из основных используемых компиляторов на не8-битках при линковании исполняемого файла со статическими библиотеками не тянет все поголовно ф-ции, если они не используются. Не надо проецировать Борландовские поделия на все остальные компиляторы.

Поясняю. Человек даже не совсем понимает специфику разговора, поскольку обсуждается возможность умной линковки библиотеки с одного исходника, а библиотеки в упомянутых им компиляторах построены на модулях из кусочков: одна функция = один исходник.

Там я упоминал, что имею ввиду только добрую половину тех старых компиляторов, с которыми работал. И сюда не входят ни clang, ни Watcom. А откуда я могу знать, как дела обстоят там, если не видел.

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

[Vitamin]

А зачем в контексте обозначения части компиляторов, в которых эта проблема не решена, говорить про компиляторы, где она решается? Я какбэ не настаиваю на использовании утилиты smartlib во всех случаях, но только там, где это будет уместно.

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

Не знаю никакого DJGPP для винды, кроме MINGW. Ну и кроме патча Макса Феоктистова. Суть доработки в том, что оно - изначальное для DOS32 - заточено для генерации Win32 PE.

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

Нас с Сергеем смущает, что нас идут учить делать библиотеки люди, которые ни одной не сделали (имеются ввиду библиотеки для SDCC + ZX). Причём аргументируют тем, что какбэ, скорее всего, эта оптимизация в SDCC есть, они так думают - ну не может её не быть. Что грустно, потому что вопрос мною обнажён предельно, ибо обсуждался с Филиппом Краузе лично.

1) приведи примеры попыток "учить делать" (хотя бы от меня)
2) приведи цитату, где утверждается (или хотя бы предполагается), что в SDCC такая оптимизация есть

библиотеки в упомянутых им компиляторах построены на модулях из кусочков: одна функция = один исходник.

Это тебе кто сказал? Или ты исходником называешь секцию объектного файла?

[Oleg N. Cher]

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

Неконструктивный сыр-бор, заметь. Он не был бы таким, если бы кто-нибудь составил список компилеров, которые соответствуют обозначенному критерию "умной линковки библиотеки с одного исходника".

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

Но ты ведь не будешь отрицать, что можно говорить "для винды" и в контексте таргет-платформы?

А чем, собственно, mingw хуже пропатченного djgpp?

Патч для DJGPP просто раньше появился, ещё до MINGW. А для меня он привлекателен по нескольким причинам, не касающимся данного топика.

1) приведи примеры попыток "учить делать" (хотя бы от меня)

Привожу.

Второй вариант во-1 очень трудно поддерживаем, т.к. требует не статической либы с кучей скомпилированных .o файлов внутри, а какого-то адского гемороя по указыванию какие куски откуда надо выкусить и куда собрать ( с этим вполне справляется компилятор без необходимости в программисте). Во-2, такой вариант нечитаем. В-3, сборка проекта будет увеличена ровно на время разбиения мегасорца на куски и последущей компиляции этой помойки. В-4, ошибки при таком разбиении практически гарантированы и вызывают п.3 в полный рост КАЖДЫЙ раз. Могу предложить еще 3й вариант как компромисс между 1м и 2м:
config.h с куче #define где указывается какие ф-ции надо компилировать из исходников, а какие нет. Вариант имеет часть недостатков 2го метода, ибо требует пересборки при каждом изменении в количестве используемых ф-ций.

( притом так и не пояснил, наверное потому, что это вызовет такую критику, что ой, притом не только от меня. )

2) приведи цитату, где утверждается (или хотя бы предполагается), что в SDCC такая оптимизация есть

Привожу.

Как ведет себя в этом случае сдцц я не в курсе, но подозреваю что такой примитивный вариант оптимизации там осилили.

Это тебе кто сказал? Или ты исходником называешь секцию объектного файла?

В SDCC так и есть: один исходник = секция = атомарная единица линковки. А ты прочёл сообщение от Alcoholics Anonymous и понял, какой именно способ представления библиотеки он отстаивает?

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

Да я озвучивал, притом в нескольких сообщениях. Перечитай, раз запамятовал.