Другими словами, умный транслятор Оберона в C не может на выходе дать много маленьких файлов по одной функции или хотя бы файлов с cut-линиями, а дружное сообщество динамично развивающегося кросс-платформенного Оберона не собирается модифицировать транслятор для возможности сборки компакнтых программ под ретро-платформы?Сообщение от Oleg N. Cher
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Просто сопоставил два твои высказывания и нашёл в них одни придирки и самовыпячивание.
Но зато знает где это посмотреть. И уверен, что другие знают. Кому надо. А кому не надо - тому и не надо. И нечего ради таких напрягаться.
---------- Post added at 22:52 ---------- Previous post was at 22:51 ----------
Alex Rider, даже чуть не так. Умный транслятор Оберона в C силами одного дружного чела, динамично развивающего оный транслятор научился давать на выходе файлы с cut-линиями, но дело оказалось мудрёным, а сборка компактных программ под ретро-платформы - мало востребованной, посему подход и не получил должного развития. Хотя всё возможно.
Это означает: не включаем в хедеры то, что там не нужно, не включаем в файлы исходного кода то что там ненужно. Не показываем конечному юзеру те ф-ции которые ему не нужны (скрываем реализацию служебных структур и частей кода).
Я и Витамин уже 100500 раз это писали.
Я не нашел ни слова документации в репозитории как это собрать. Все бинарники находящиеся там на моем powerpc G5 не запускаются т.к. собраны под и386.
Вопрос без которого нельзя на вот то что ты написал ответить: ты каждый раз переписываешь библиотеки которые юзаются у тебя в zxdev? в смысле они каждый раз экспортируются по-новой в С-исходники и каждый раз собираются?
Если так то мой подход неверный. Если нет - не вижу проблемы доработать после экспорта напильником то что получилось для:
1) удобочитаемости и нормальной структурированности
2) исключению необходимости резать это все каждый раз каждую сборку.
3) скрытию системных и внутренних структур и ф-ций от конечного пользователя.
4) ускорению сборки в силу пп 2 и 3.
PS: Ответь мне, ты сам-то что пересмотрел в своих привычках за время треда?
А то, я смотрю, вместо ответа на простой вопрос ты начинаешь метать во всех подряд какашки и пытаться найти где там тебя и твой обожаемый мертвый язык так оскорбили и обидели...
Ага. Значит я, по-твоему, включаю в хедеры то, что мне не нужно и не включаю то, что нужно. Надо же. Сам понял чего сказал?
Но вообще хедеры генерируются автоматически с обероновских интерфейсов, так что я их даже не пишу ручками. Просто некоторые иногда дополнительно редактирую.
Всё правильно, ненужное скрываем. Это есть инкапсуляция.
Вы не сказали ничего дельного по этому вопросу. Даже язык Си не требует помещения каждой функции в отдельный исходник. Ты же напираешь на необходимость это обязательно делать. Да, с SDCC по-другому пока и не сладить, но лучше бы ты задумался над тем как лучше сформулировать feature request разработчикам SDCC.
Ну что конкретно ты предлагаешь? И не дури мозг. Вовсе не "невключать то что ненужно включать то что нужно", а "помещать каждую функцию в отдельный файл". Ну хорошо. Будет в папке Lib не 44 файла, а 544. Легче кому от этого станет? Придётся имена всей этой тучи файлов хранить в мейк-файле (и постоянно его редактировать, дополняя новыми именами). Это что - удобно настолько, чтобы к этому стремиться? Нет, батенька. Это просто для тебя привычней. Ещё какие достоинства будут?
Угу, угу. Витамин тоже в глаза никогда не видел ни винды, ни i386, представляясь линухойдом. Пока не прокололся, приаттачив презентацию ppt.
Не могу рассматривать такой ответ иначе как дешёвую рисовку.
Да.
Но с некоторыми "но".
Библиотека, написанная на Обероне, собирается именно так, как ты сказал. Разрезание тоже работает, но с некоторыми ограничениями.
Поэтому исключительно для того чтобы юзать "умную линковку" используется полу-автоматическая генерация. Т.е. то, что нагенерил Ofront, ручками переносится в сишный исходник и редактируется для добавления "линий разреза". Иногда используется сишный препроцессор. Это для шика. Например, чтобы без перекомпиляции использовать разные опции работы библиотеки. С некоторыми ограничениями это можно юзать и из Оберона.
Наконец, чисто сишные библиотеки. Ну какой смысл резать их на сто кусочков? Чтобы подсластить жизнь утилите. Проклинаемый тобой оверхед - у тебя в голове, я уже писал, что авторазрезание даже на сто кусков занимает меньше секунды.
Ну и асмовые библиотеки. В сишной обёртке. Тоже нет никакого резона иметь каждую функцию в отдельном файле. Ну нету смысла в этом. Так делают, я снова повторюсь, только для того чтобы угодить плохому компилятору.
Для этого у нас есть интерфейсы. Ты давно заглядывал в промежуточный код, сгенеренный любимым FreePascal?
Я ещё раз повторюсь. Интерфейсы генерируются автоматически. Чтобы у нас были доп. фишки (например, связанные с макропроцессором) - мы можем доработать напильником. Я так и делаю. Но не для всех библиотек, а только для некоторых.
Пользователь не пересобирает библиотек. Как правило, это делает разработчик библиотек. Даже если пользователь пересобирает библиотеку - он делает это одним нажатием кнопки. Голова не болит. Разве что батничек подправить. Но в нём нету ста имён кусков файлов исходника.
Я повторюсь. Пользователь оперирует даже не хедерами. Интерфейсами. В них нет ничего лишнего. Но может быть много полезного, вплоть до комментариев, созданных с помощью автодокументирования (как в Javadoc).
Т.е. из-за неприемлемости потратить полсекунды на работу утилиты разрезания ты предлагаешь вместо этого удесятерить количество файлов и усложнить процесс их сборки вынужденной необходимостью постоянно править имена в мейк-файле?
Слушай, у меня ужасное подозрение. Это твоя идея фикс. Грамотный разработчик зрит в корень. И уж точно усмотрит более приоритетные направления разработки. А их сотни. А что предлагаешь ты? Чепуху, вобщем.
Ещё более укрепился в своём почитании библейского принципа "око за око, зуб за зуб", и знаешь, правило верное - не подводит.
А ты сталкивался с тем, что кто-то, рьяно рвущийся дать тебе совет, не вполне понимает что именно ты делаешь? А, соответственно, и не заслуживает более достойного ответа. А другие на меня и не в обиде. За это я спокоен. И благодарен за хорошие советы. С этим всё в порядке.
Я с этими скриптами и разбиением вожусь уже не один год. А, по-твоему, адекватный человек будет давать советы по усовершенствованию продукта, который он не то что юзает ежедневно, а вообще даже не смотрел?
Так, риторика.
Поставлю в подпись.
Alex Rider, чтобы ты понял как хреново обстоят дела с "умной линковкой" в сишном мире, нужно сказать, что в таком развивающемся компиляторе как Tiny C (tcc) её нету вообще. И разработчики не хотят добавлять эту фичу. Вообще не считая это чем-то важным. Более того, я не уверен, что она есть даже в MINGW. По крайней мере, люди пишут об этом. http://forum.ixbt.com/post.cgi?id=print:26:42363. В качестве эксперимента предлагаю это проверить. Я проверял. Правда, на старой версии MINGW. И действительно - fdata-sections, -ffunction-sections увеличивают размер библиотеки, а ключик --gc-sections не работает должным образом. И с fdata-sections, -ffunction-sections бинарь получается ещё жирнее, чем без них. И меня это не удивляет - килобайты давно уже никто не считает.
Так что это есть серьёзная проблема сразу для целой кучки сишных компиляторов, а вовсе не для одного. И пусть Q-Maйster не лезет сюда со своей вижл студией последней версии, а витамин со своим Clang. Мимо. Я говорю про MINGW, где ключики не срабатывают. Идите туда оба и пробейте эту фичу. Потом сделайте то же самое для SDCC. Тогда я вас похвалю. Может быть.
Мне кажется, самой большой проблемой здесь есть помещение static функций в библиотеку. Т.е. они должны видеться извне для подключения их к тем функциям, которые имеют на это право, но не должны видеться для других функций.
И я, разумеется, могу повлиять на эту ситуацию только очень ограниченным образом. Думаю, такой feature request будут отпинывать ногами куда подальше. Я говорю это не голословно, ибо уже делал такие реквесты.
Так что SDCC просто поддерживает старые добрые сишные традиции. "Режьте, братцы, режьте". Исходник на кусочки. Но спасибо хоть так, могло быть вообще никак.
---------- Post added at 01:38 ---------- Previous post was at 01:28 ----------
То есть получается, Alex, что ты заставляешь (или просишь) меня делать то, что не могут (или не хотят) сделать сообщества разработчиков сишных компиляторов, состоящие из десятка и более человек. Ну и где твоя гуманность? Хоть помощь предложи для приличия.
Впрочем, а как именно ты предлагаешь сделать "умную линковку"? Просто чтобы транслятор выдавал сразу кусочки, т.е. дублировал функциональность моей утилиты-резалки? А смысл в этом какой-то есть, кроме удовлетворения эго ку-майстера? Который даже не будет пользоваться этим, ибо у него powerpc G5.
Огорчу тебя еще раз. Я не юзаю вижуал студию и не юзал ни разу в жизни. Под твоим любимым мингв стандартно юзается gcc, а не tcc чего-бы ты ни говорил. В гцц такой проблемы практически нет. Заюзай таки самую новую версию мингв и скачай новый gcc под него. Насколько я вижу это 4.8.1. Там все есть.
А ты собери мне под debian linux для powerpc процессоров и я попробую это. То что я даже вменяемой документации по сборке этого всего не нашел это уже как-бы показывает дружественность проекта.
PS: поскольку ты собираешь все каждый раз по-новой, то мой подход не катит. Хотя я и не очень понимаю в чем смысл пересборки и пересоздания сишных исходников каждый раз.
PPS: поскольку "дружественность" твоего восприятия любого совета просто ужасна - я не буду более тут ничего писать. надеюсь что проект с такой "поддержкой" таки выплывет.
Юзаю 4.8.1 с http://sourceforge.net/projects/mingwbuilds/ - там эта опция влияет только на размер .pdb
Если дебужную инфу хранить в бинаре, то да, размер уменьшится.
А я не уверен, что там есть умная линковка для винды. Пробовать специально не буду, разве что когда-нибудь по какой-то оказии.
Его нельзя собрать для линукса. Это чисто виндоуз-проект. Что касается дружественности - я не господь бог и не могу сделать всё для всех, и чтобы всем понравилось. Это невозможно по определению.
А ты понимаешь смысл трансляции одного языка в другой?
Какие советы и какой тон - такая и реакция.
Из здешних форумчан я благодарен Eltaron'у. Благодаря его совету в ZXDev появилась возможность передавать константные параметры внутрь функций в регистрах. И хотя такой возможности нет в SDCC - мы достигли этого с помощью препроцессора.
Ещё я благодарен Reobne. Благодаря его совету появилась возможность юзать inline-ассемблер прямо из Оберон-исходника. Причём без переделки транслятора - тоже с помощью макропроцессора.
Это хорошие советы. Твой же совет держать каждую функцию в отдельном файле - он, как бы помягче сказать, не очень. Ну да, твоя помойка будет принципиально отличаться от моей только удесятерённым количеством файлов. Причём ты даже не рискнёшь сказать, что это идеологически правильно и в духе Си. Просто сложил их так, чтобы не резать каждый раз.
Занимаясь Обероном я кое-что понял. А именно то, что проблему нужно решать в месте её возникновения. Любой другой подход будет навесным. А значит - нужно внедрять умную линковку в Си-компиляторы. Это самое правильное решение, которому не видится никакой другой разумной альтернативы. Ну будет выдавать Ofront кучу исходников. Т.е. будет делать то же самое, что и утилита. Смысл? Жизнь станет легче, что ли?
Если внедрить смартлинковку в Си-компилятор по каким-то причинам невозможно или затруднительно - иначе как утилитой, которая переформатирует исходник и приведёт его в вид, потребный для линковки, вопроса не решить. Да, моя утилита примитивна. Но что же делать? Давайте напишем вместе более умную утилиту. Давайте сформируем feature request в сообщество SDCC. Я не возражаю. Давайте что-нибудь сделаем в этом направлении.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
