OSDev

для всех
Текущее время: 21 ноя 2017, 22:36

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 36 ]  На страницу Пред.  1, 2, 3, 4
Автор Сообщение
 Заголовок сообщения: Re: язык программирования для ОС
СообщениеДобавлено: 27 июн 2015, 15:58 

Зарегистрирован: 31 окт 2011, 18:20
Сообщения: 230
Цитата:
Просто закладывай резерв времени на возню. На отладку же закладываешь? Хинт - код продумывается и пишется нормально и без компиляции.

Цитата:
Если кого то заставляют использовать такой подход, то видимо за это платят деньги?

Цитата:
должны существовать и системы сборки более продвинутые, которые прячут эту кухню от тех, кому не хочется разбираться

По-моему, тут подмена понятий. Что платят, что приходится закладывать на это время и что существуют костыли для обхода этой системы, я не спорю. Однако весь этот подход, поставленный в виде стандарта, создает больше проблем, чем приносит пользы. Я не говорю, что с этим невозможно работать, я говорю, что это неудобно и неэффективно, и могло быть гораздо лучше и логичнее. Человек должен заниматься тем, что машина сделать не может (придумывать алгоритм), а то, что она сама могла бы сделать без проблем, машине поручать и нужно.
А следуя логике, что "если бы все сразу учились на мейках, то не было бы воя на форумах о невнятных ошибках линковщика", можно пойти дальше - давайте все будем учиться забивать гвозди тапками, тогда ни у кого с молотком не будет никаких проблем. Если существует убогий инструмент, это значит, что надо придумать что-то лучше. Автосборку в VS и прочих интегрированных средах как раз не от хорошей жизни придумали, а потому, что поняли - это make-возня есть пустая трата времени в 95% случаев. Но иногда получаешь на доработку проект, который авторы компилировали через make, ибо очень религиозные были. И тогда никакие среды не помогут, потому что перетащить с одной системы сборки на другую крайне тяжело, и приходится копаться в этой фигне.
Да и интегрированные среды типа VS тратят на компиляцию куда больше времени, чем могли бы, отчасти из-за того, что их сборка является пачкой костылей над этой порочной системой.
Цитата:
Но предпочитаю более конструктивные обсуждения. Что предлагается взамен make? Если ничего конкретного, то make будет неплохой альтернативой.

Вот я и предлагаю, к примеру, такой вариант:
Компилятору на вход подается главный файл программы. Если хочется, он может состоять только из инклюдов других файлов-модулей, а может содержать и код. Причем модули подключаются напрямую, т.е. без всяких хедеров. Компилятор анализирует все эти инклюды, добавляет их в список того, что нужно скомпилировать.
Каждый файл разбирается, для него строится (и, если надо, сохраняется) бинарный формат с представлением, которое можно быстро превратить в асму. Может это дерево разбора кода, где каждое выражение представлено деревом, где узлы - операции, а ветви - аргументы, может что-то еще. Компилятор генерирует такие деревья для всех файлов, до которых он добрался на этапе компиляции, сохраняя связность (что где использовалось). Далее, начиная с главного файла, идти по всем модулям, которые к нему подключены, и в места вызовов функций из других модулей подставлять вызовы соответствующего разобранного кода. Таким образом компилятор строит граф потока управления для всей программы. Этот граф можно уже рассматривать как цельную программу, и применять соответствующие оптимизации.
При этом вывод компилятора может быть в точно такое же дерево, как и на отдельные файлы, но для всей программы целиком. Тогда этот код можно будет компилировать в составе других проектов, указав в исходнике, что используется такой-то модуль.
Получается, что каждый исходник генерирует кусочек дерева, эти кусочки собираются в большее дерево, эти деревья можно переиспользовать в других проектах. При этом гораздо меньше проблем с разрешением конфликтов (явно указывается модуль), не нужен весь этот make-геморрой (компилятор сам может найти все модули по их подключению в исходник и собрать в правильном порядке), и сохраняется возможность переиспользования готового кода в других проектах. Количество разных "объектных" файлов становится равно не количеству файлов с расширением .C, а количеству принципиально разных частей кода (из разных проектов или на разных языках), то есть в пределах десятка, а не нескольких тысяч.
Цитата:
Дельфи, например, этому требованию соответствует.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: язык программирования для ОС
СообщениеДобавлено: 27 июн 2015, 18:12 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Цитата:
подход, поставленный в виде стандарта, создает больше проблем, чем приносит пользы

Основная идея в том, что этот подход устарел. В мэйнстриме есть java, есть C#, там (вроде как) make не используется. Поэтому если кто то его навязывает, тогда да, это может быть проблемой, если make применён не к месту. Но называть это стандартом в 2015 году я бы не стал. Хотя тут может зависеть от предметной области (которая обозначена не была).

Цитата:
я говорю, что это неудобно и неэффективно

Не соглашусь. Зависит от многих факторов.

Цитата:
давайте все будем учиться забивать гвозди тапками

Не, я предлагаю всё таки освоить молоток для забивания гвоздей, а микроскоп оставить биологам, или кому он там нужен больше. Применительно к make, следует понимать его предназначение, его сильные и слабые стороны, граници применимости. Инструмент как инструмент.

Основная проблема, насколько я понял, заключается в том, что некоторые могут спутать make и модульную систему языка. Следует разделять эти понятия. Да, в си нет модульной системы, а в паскале она есть. Поэтому для паскаля применяется другой принцип сборки, нежели чем для си. Отсутствие модульности в си, в целом, является одним из его недостатков. Однако на систему сборки (инструмент make), я считаю, ошибочно распространять эту характеристику.

Цитата:
Если существует убогий инструмент

Если молотком нельзя закрутить шурп, он тоже убогий? Нет, просто каждый инструмент предназначен для своих целей. Так же и make. Обычный инструмент, созданный для вполне конкретных целей. Задачу свою выполняет, а значит вовсе не убогий.

Цитата:
интегрированные среды типа VS тратят на компиляцию куда больше времени, чем могли бы

Не согласен. Касаемо сишника тут основной фактор - особенность самого языка, и ни к IDE, ни к make не имеет никакого отношения. Его просто принципиально нельзя скомпилировать быстро.

Цитата:
Но иногда получаешь на доработку проект, который авторы компилировали через make, ибо очень религиозные были

Вот в этом вся соль. Почему нельзя в этом случае просто освоить новый инструмент и порадоваться за то, что твоя квалификация выросла? Да за это ещё и заплатили 8-)

Цитата:
надо придумать что-то лучше

Цитата:
Вот я и предлагаю, к примеру, такой вариант

По предложенной модели у меня оценки нет (вернее есть, положительная, как и ко всем новым идеям/предложениям), пусть freeman берёт на заметку, тут в одном абзаце и часть архитектуры компилятора и частично модульная система языка. Правда я не совсем уловил чем описанное отличается от delphi/java/C#/ES6 или любого другого современного языка программирования с модульной системой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: язык программирования для ОС
СообщениеДобавлено: 27 июн 2015, 19:22 

Зарегистрирован: 31 окт 2011, 18:20
Сообщения: 230
По поводу того, что я путаю систему сборки и модульность языка - есть немного. Но мешаю их в одну кашу потому, что использование обсуждаемой системы сборки вызвано именно отсутствием модульности в языке. То есть собрать C-шный код по-другому просто не представляется возможным (т.к. в коде нет прямых ссылок на другие модули), и приходится использовать что-то типа make. Другими словами, для современного Си любая система сборки будет построена нелогично. И make - частный случай. Но это не отменяет того факта, что make-система сборки, хоть и решает свою задачу, крайне не разумна. Лучшее из худшего не становится автоматически хорошим, даже когда другого не дано.
Теперь по делу.
Цитата:
чем описанное отличается от delphi/java/C#/ES6

Java компилируется в байткод на уровне отдельных class-файлов, все эти файлы помещаются в ZIP и распространяются с именем *.jar. При этом фактическое связывание этих файлов идет по именам классов при выполнении.
C# немного посложнее, но идея похожая: байткод и связывание по именам.
Про ES6 ничего не знаю, сказать не могу.
В делфи глубоко не копал и могу ошибаться. По моим знаниям, распространяемые пакеты делфи содержат уже скомпилированный код. Это близко к той модели, что я описал: единицей анализа является не один файл исходника, а несколько. Но все же на промежуточных этапах подключается много уже скомпилированных модулей.
Отличие подхода, который я описал, состоит в том, что ассемблерный код генерируется только на самой последней стадии, при сборке исполняемого файла программы. Все промежуточные этапы выполняются над деревом/графом, который гораздо более подробно описывает структуру программы, нежели байткод, и при этом легко поддается анализу, в отличие от машинного кода. Также этот граф предоставляет возможность встраивания в него других графов, и далее компиляции всего этого большого графа в ассемблер.
Преимущество перед системой java/C# - отсутствие байткода, перевод в который уменьшает количество полезной информации о потоке управления и типах, и наличие на этапе компиляции исчерпывающей информации о проекте. Промышленная система сборки даст возможность за меньшее время получить более качественный и оптимальный исполняемый код, нежели попытка собирать все на клиентской машине (чем java, к слову, особо и не занимается - jit включается для отдельных методов, а не для всей программы, и то, только после N-кратного их исполнения в режиме интерпретации).
Преимущество перед системой Delphi - отсутствие ассемблера, анализ которого с целью оптимизации и интеграции с другими участками кода очень сложен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: язык программирования для ОС
СообщениеДобавлено: 27 июн 2015, 21:53 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Я хотел только сказать, что как раз именно make - наиболее логичная система сборки для си. Сам язык модульность не поддерживает - запилили отдельной утилитой, не ломая язык. Шикарное решение как раз в духе компонентной архитектуры. И решает задачу именно что разумно. Да, возможно у make есть недостатки (правда я из дискуссии таковых для себя не вынес, поэтому до сих пор не понимаю, зачем на него бочку катить), да, другие языки могут не нуждаться в системе аналогичной make, однако ж работает, работает исправно. И для си чего то более логичного придумать сложно. А если не си, тогда мы видим, что никто в здравом уме в современные языки модульность на основе make не тащит.

По поводу графа структуры программы понятно. Осталось теперь только найти или написать язык, реализующий такой подход.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: язык программирования для ОС
СообщениеДобавлено: 29 июн 2015, 12:13 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Bargest писал(а):
Лучшее из худшего не становится автоматически хорошим, даже когда другого не дано.

Проблема еще в том, что в силу своей системной природы худшее является умолчательным, к которому нивелируются все остальные. Какой бы распрекрасный Rust, Go или GHC не был, фактическая сборка кода всё равно нивелируется к утилитам из мира Си, будь то GNU binutils или их аналог.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: язык программирования для ОС
СообщениеДобавлено: 01 июл 2015, 10:18 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Не худшее а простейшее и наименее связное.

Цитата:
Какой бы распрекрасный Rust, Go или GHC не был, фактическая сборка кода всё равно нивелируется к утилитам из мира Си, будь то GNU binutils или их аналог.

Даже если это и так, это не мешает им развиваться.

Неужели так сложно понять...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 36 ]  На страницу Пред.  1, 2, 3, 4

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB