OSDev

Упс... кажется от темы немного отошли. Ну а чтобы нам сделать свой софт для китайского железа, надо иметь под рукой эффективный инструмент, т.е. язык программирования и тулчейн для него. О чём собственно и тема. Т.е. если разработку ОС ещё можно как то обосновать, то разработку языка - ещё сложнее. Чтож, тогда будем считать разработку языка составной частью разработки ОС, и не выделять как отдельную задачу. Теперь пойди объясни это всё комерсам

Ладно, думаю можно этот кусок треда чикнуть (в отдельную тему или в nil).

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

Ни кто не подготовил. Хотя бы потому, что в этом нет ни какого смысла. Так же, как нет смысла составлять бизнес-план на производство и выпуск вечных двигателей. Всё дело в том, что инвестор смотрит на прецеденты, на похожие проекты, приносящие прибыль, а таких нет. Без этого вы никого не убедите, что этот бизнес-план стоит хотя бы ломанного гроша. Нужны альтернативные способы. Например, есть глобальный фонд СПО (FSF), он собирает пожертвования и финансирует проекты. Нужно или обращаться к нему, или создавать российский фонд.

Himik, если по поводу языка - тогда да, придумать бизнес план может быть сложновато. Но если по поводу ОС - то это вообще вещь тривиальная. Даже без мозгового штурма: microsoft с windows, google с android, много наших контор с линуксом. Что, они не делают бабки? Втроенные решения, если на ОС общего назначения сил не хватит. Что, никто из железячников не делает бабки? Линукс потеснить можно кое где. Просто сделать некоторую киллер фичу, позволяющую получить преимущество, преимущество измерить и перевести в деньги. Неужели это неочевидно? Весь бизнес план - это такой расчёт. И блин не надо сравнивать вечный двигатель с вполне практическими тулзами. Хватит тупых попыток манипуляции общественным мнением.

Идея о создании фонда, возможно, стоящая. Следует раскрыть подробнее, что под ней подразумевается.

http://www.fsf.org
Основная проблема в том, что весь проект должен быть англоязычным, иначе не поймут зачем это нужно.

Кац всегда предлагал сдаться. ©

Еще я хотел ответить на последнее сообщение в теме от Yoda, но вначале подожду, пока страсти улягутся.

А разве ещё не улеглись? Вроде ещё даже не особо поднимались, так то. Himik, меня вот интересовал вопрос создания некоего своего фонда, а не обращение в FSF. Вариант экспорта разработок как бы не интересует.

Кстати, ближе к теме именно технического аспекта, нашёл на компилер.су (по совету йоды посмотрел) интересную тему: двухстековая архитектура

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

Всё верно, однако тут наблюдается некий устоявшийся набор догм, кажущихся большинству незыблемыми. Перечислю некоторые из них:

• Разработка на компилируемом языке должна быть сложной, с запутанными скриптами сборки и ручным отслеживанием зависимостей. Хочешь простоты -- пиши на интерпретируемом языке (и теряй в скорости).
• Компилятор в составе RAD -- плохо оптимизирующий и с кучей других недоработок.
• Безопасное автоматическое управление памятью -- только как сборка мусора. Умные указатели в C++ -- единственное исключение.
• Управляемый код должен быть низкоуровневым и/или кодом стековой машины.
• ООП -- надстройка над процедурным программированием. Его нужно держать в чёрном теле и компоновать только с маскированием имен (name mangling), ибо формат объектных файлов -- священная корова.

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

Считаю, что прорыв возможен, только если отойти от догм, для чего потребуется создать не только язык, но и весь стек технологий, включая технологию разработки ПО -- более прогрессивную и более экономную. А в плену догм всё незнакомое кажется вечным двигателем.


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

Точно подмечено.


RAD - имеется ввиду Rapid Application Development? Если так, то я полагаю, что характеристики компилятора сейчас не сильно связаны со средой разработки. Связь компилятора со средой прошла ряд фаз. С одной стороны, качество компиляции раньше было ограничено скоростью работы машины, сейчас этот фактор уже не играет определяющей роли. С другой стороны, интеграция компилятора со средой могла вынуждать разработчиков делать раздельные средства компиляции для онлайн и оффлайн компиляции. Мне в старые ДОСовские времена очень нравилось в качестве интегрированной среды использовать связку MultiEdit с компиляторами командной строки. Такая связка обеспечивала единообразный интерфейс пользователя и отличное качество компиляции. Безусловно, это - заслуга MultiEdit, который целенаправленно разрабатывался не только как текстовый редактор общего назначения, но и как универсальная среда разработки. Сейчас также можно использовать универсальную интегрированную среду Eclipse с разными плагинами (правда мне он не нравится, т.к. жутко тормозной). Для кросс-платформенных разработок я по старинке использую обычный текстовый редактор и компиляцию батником с командной строки. В целом, приведённые примеры показывают, что вопрос качества компиляции вполне решаем.


Вот эта ситуация также иногда вводит меня в состояние ступора. Скачиваешь проект, - и не можешь его скомпилировать, - надо целиком ставить последнюю версию студии и импортировать туда проект. Или (для Linux-овых проектов) запускаешь конфигуратор, который ругается на кучу отсутствующих инструментов (всякие скриптовые интерпретаторы-генераторы), устанавливаешь инструменты, а результата всё равно нет по причинам, известным одному лишь Торвальдсу. Очень редко можно встретить проект, который очень просто можно скомпилировать в любых условиях (положительный пример - проект tcc).
Одна из причин такого безумия - величина проекта. При изменении одного байта целиком перекомпилировать большой проект действительно может быть неразумно. Но относительно небольшие проекты (до сотни тысяч строк) вполне можно перекомпилировать без использования сложных сторонних инструментов.
Вторая причина - интеграция. Она характерна для семейства продуктов MS VS. Изначально предполагалось, что студия просто возьмёт на себя рутинную работу - отслеживание зависимостей. Однако, это приводит к созданию кучи труднопереносимого мусора типа файлов проекта и рабочей среды, визардов, прекомпилированных заголовков и кучи другой мутотени, плохо совместимой между версиями проекта и занимающей в десятки раз больше места, чем сам полезный код. Т.е. изначально благой позыв приводит к ещё худшим результатам.
Третья причина - разнородность сред. Так, нельзя просто взять и скомпилировать проект под Linux, как минимум надо проверить, какой компилятор установлен и какие заголовки/библиотеки доступны.

Я думаю, что все эти проблемы решаемы.
1. Да, для больших проектов необходимо отслеживание зависимостей, но думаю, можно обойтись makefile.
2. Интеграция обязательно должна подразумевать возможность ручной правки созданных файлов (в идеале - только одного файла makefile) и в идеале должна рассматриваться только как вспомогательное средство, а не замена. Как только начинается подход "сюда не лезь!", создаётся куча непереносимого и неконтролируемого хлама.
3. Разнородность сред является результатом неконтролируемого и местами хаотичного развития языка и ОС на протяжении нескольких десятков лет. Я думаю, переход на новый язык на первое время решает проблему отсутствия стандартов, а дальше всё зависит от того, насколько хорошо язык был разработан изначально, ибо постоянная доработка языка напильником есть результат его начальной ущербности. Если язык хорош сразу, последующие доработки будут минимальны, а значит минимальна будет и головная боль "скриптописания конфигураторов".


Я однажды долго ломал голову, почему я не могу в NASM сделать битовые манипуляции (сдвиги и маскирование) над адресами. Оказалось, что из-за потенциальной возможности генерации объектного кода, который не подразумевает никаких изменений адресов, кроме их перемещения (прибавление/вычитание константы). И это даже несмотря на то, что я компилировал непосредственно в бинарный (даже не EXE) формат. Таким образом, мы будем ещё долго пожинать горькие плоды существования объектных форматов (иногда даже там, где самих форматов и нет).
К чему это я?
При разработке принято говорить о наборе инструментов (toolchain). Но давайте подумаем. Функции линкера настолько просты, что входят даже в ассемблер NASM. Функции ассемблера достаточно просты по сравнению с функциями компилятора ЯВУ, так что многие компиляторы имеют встроенный ассемблер. Так зачем нам тогда нужен toolchain? Я предполагаю, что всю цепочку было бы разумней реализовать в виде единого исполняемого файла (как сейчас и поступают вменяемые компиляторы). В таком случае можно легко избежать привязки к устаревшим объектным форматам.


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


Нет, объём кода здесь ни при чём. Два подхода отличаются по самой своей сути, по логике мышления. Вот они:
Императивный: "У нас что-то есть. Что мы из этого можем получить?"
Функциональный: "Нам что-то нужно. Что нам нужно, чтобы это получить?"
Эта принципиальная разница порождает множество следствий, как хороших, так и плохих (для каждого подхода), я чуть ниже поясню некоторые из них.


Нет, оно не умерло и никогда не умрёт (ниже поясню, почему).


Эти две концепции неизбежно привели к появлению мощнейших надстроек, органично вытекающих из них (существование "переменных" в ИП, лямбда-функции в ФП и множество других). Естественно, между двумя концепциями идёт священная война. По этой причине каждая сторона пытается вобрать в себя лучшие черты своих "врагов" и избавиться от недостатков, т.е. война идёт на пользу обеим сторонам. Однако, ИП и ФП по прежнему хорошо отличимы по своей сути (выраженной выше).

Теперь мои комментарии.
Выше вы пишете, что "ИП умерло с массовым распространением многоядерных процессоров". Это как раз миф, тщательно пропагандируемый адептами ФП. Дело в том, что ФП по своей сути безопасно, т.к. (в идеальном случае) никогда ни на что не опирается и никогда ничего не меняет. Поэтому функциональщики считают, что ФП идеально годится для многопроцессорных систем. И это действительно так, но только в том случае, когда нам не требуется обмен данными между вычислительными узлами. Идеальное ФП предполагает, что переменных не существует (мы ничего не сохраняем, мы всегда получаем то, что нам требуется), а значит не может существовать никаких побочных эффектов. Т.е. ФП в идеальном виде безопасно по своей сути. Однако, программа, которая не имеет побочных эффектов, бесполезна ((с) не помню кто), без "побочных эффектов" невозможен никакой ввод-вывод. Поэтому реальное ФП вынуждено добавлять средства ИП, чтобы не быть бесполезным.

Есть один очень простой пример, наглядно демонстрирующий всю разницу между ИП и ФП. Это расчёт чисел Фибоначчи.

ИП.
1. У нас есть первые два члена последовательности, оба равные 1.
2. Мы можем получить следующий член, сложив предыдущие. Но нам нет нужды хранить всю последовательность, поэтому первый член выбрасываем и храним только два последних.
3. Выполняем пункт 2 до тех пор, пока не получим нужный нам член последовательности.

ФП.
1. Если требуемый член N меньше или равен двум, возвращаем результат 1. Иначе, возвращаем сумму членов N-1 и N-2.

Путь ИП сложней в формулировке. ФП проще и полностью соответствует математической формулировке ряда Фибоначчи (за что математики особенно любят ФП ).
В ИП нам нужно хранить промежуточные результаты, легко допустить ошибку, храня какие-то данные совместно (например, хранение в глобальных переменных исключает возможность многопоточности). В ФП нет понятия "хранения" и "изменения", значит нет никаких опасностей, связанных со случайной записью данных "не туда" и ограничений, связанных с количеством потоков.
А теперь обильно посыплю соль на раны ФП. Достаточно запустить расчёт числа с номером 100. Код ИП выдаст результат мгновенно. А код ФП в том виде, в котором приведён, приведёт к "зависанию" компьютера. Правда, это зависание будет обусловлено не бесконечным циклом, а экспоненциальным ростом сложности расчётов. Для члена N нам требуется член N-2, но для члена N-1 нам также требуется член N-2, в результате он будет рассчитан дважды. Член N-3 будет рассчитан три раза, N-4 - пять раз (очевидная последовательность ), далее очень быстрый рост. Всего же функция расчёта очередного члена будет вызвана 5.73e20 раз, что подвесит даже суперкомпьютер! Есть два способа вернуть эффективность расчёту ряда. Первый - делать умный компилятор, у которого хватит ума сообразить, что одни и те же расчёты затребованы многократно и скеширует результат. Однако, это нереальный путь. Второй - менять логику кода, либо самостоятельно кешируя результаты, либо ухудшая понимание программы (обычно и то, и другое сразу). Первый путь идёт вразрез с концепцией ФП, второй путь лишает её красоты.
Надо заметить, что путь ФП, будучи полностью отвязанным от реальной машины и математичным по своей сути, изобилует подобными подводными камнями, поэтому нуждается в постоянной проверке на эффективность. Я не утверждаю, что он всегда неэффективен, но его эффективность практически никогда не превышает эффективность ИП кода.

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>