проект "полёт валькирии"

Собственно проект посвящённый созданию экзоядра. Только стартует. Сечас я думаю об создании нового языка/компилятора или о не необходимости его создания!=)

Идеи есть, но вот людей с которыми их можно обсудить пока нет...=(

Проект является полностью открытым, так что все могут принять участее в разработке.=))

____________________________

сейчас пишется движок для сайта codenull.net(временно не работает). так что по окончании написания я думаю проект полностью переместится туда. Ну а пока кроме как на wasm.ru тему размещать не хотелось.

____________________________

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

 

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

 

если ты про тему "пишем ОС", дык там похоже всё развалилось...

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

 

eXod

Мне хотелось бы узнать, чем особенным будет отличаться этот язык? Чего в нем будет такого, чего нет в других. Ну и т.п.

 

2 Avalonec.

OK! сейчас распишу!=))

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

Вторая. собственно последний язык, который создавался для написания ОС - С. а в 70-е годы компутеры были совершенно другими. Т.е. в новый язык можно ввести спец команды(макросы) ориентированные на современный процессоры.

Третья. Скорость исполнения кода. Разные компьютеры, разная аппаратура, разное железо. А вот код часто один, что называется унисекс.(хотя не спорю, что есть компиляторы от интел, которые оптимизируют под конкретный проц, но ведь только под проц!). Идея такая - один раз написать код, а потом просто перекомпилировать с разными подключёнными библиотеками. Т.е. код собирается исполнятся на Р3, подключаем библиотеки для Р3 и компили! Код для АМД-64, так же подключаем библиотеки АМД-64 и компилим!=) Можно развить вплоть до того, что под каждый конкретный монитор=)) код будет оптимизироваться. Так же экономиться куча времини. Один раз написали, а потом заботимся только о библиотеках. Плюсы - во многих случаях не понадобятся драйвера, код и так уже будет оптимизирован под работу именно с этим устройством!=) А значит очень большой выигрыш в скорости! Минусы - тяжело реализовать такой уровень абстракции. И ещё наверняка есть подводные камни. Но конфетка сладка.=))

Хотя может надо писать на смеси С и асма. Так что первый вопрос, который надо решить для проекта - это необходим ли новый язык?

 

eXod

Гм.... Есть ещё проектировщики в наших селеньях!



Ну если на то пошло (я про перекомпилирование кода), то тогда для чего де были созданы DLL?

 

То есть о драйверах? Или ты предлагаешь некоторую другую модель?



Я так понял - это идёт на уровне самого ЯВУ?

 

Как хочешь реализовать?

 

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



ИМЕННО скриптинг, а не макро.



Макросы - этого не дают.



Если твой Движок XЯву - будет сделан таким - как ты говоришь, то значить на нём можно создавать для каждого устройства мини-скрипт, который будет отражать его работу, и при этом будет - ПЕРЕНОСИМ.



Тогда код, транслирующийся в ASM - будет максимально эффективен.

 

Про последнее пожалуйста попобробнее!=))) Оччччень интересно развить твою идею=))))

Ну у длл и свои минусы... есть желание пойти по новому пути=))

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

теперь про библиотеки.

наверно название не очень удачное, но и принцип сам я до конца ещё не вижу...

грубо говоря...(очень грубо=))) )

каждой команде сответствует файлик(=)) ) в котором написано как её транслировать. ну и соответственно для каждого проца(там где это необходимо) файлик этот свой.

Это очень грубо конечно, но зато отражает основную суть=))

 

Нууу, дык - развей

Вот те и XASM )

) Ну пройдёт 4 годика - может увидишь...

 

2 Edmond,

можешь поподробнее рассказать про скриптофилософию?

 

eXod

Поищите в инете топики по философии JavaScript, VBScript или юниксовые шелл-скрипты. Одно НО - эти скрипты интерпретируются, но никогда не компилируются. AFAIK, самая близкая к идее Edmond'а концепция - это компилятор JIT для Java.

 

Quantum

Твоя не правда - совсем не близкая.

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



далее думай сам.

 

хм... тогда наверно язык/компилятор будет руководствоваться скриптомакрофилософией!=))

 

eXod

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



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



офтопик.

Дурацкий вопрос сколько, какие кросс платформенных ОС вы знаете кроме, Unix и Win?



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

 

2 Pavia,

соглачен, что трудно и это один из основных минусов и, с другой стороны, один из плюсов - "толкает" вперёд.=)

Доступ конечно будет к чистому асму, а иначе как без него?=) По началу весь код будет транслироваться в асм(естественно кроме асм вставок=) ). и перед финальной компиляцие можно будет что-то подредактировать.

хотя асм вставки как-то не очень подходит... ибо весь язык задумывается как надстройка над асмом(хотя по сути все языки и так надстройка=) ). Хм... тяжело обьяснать человеческим языком многие вещи... попробую нарисовать блок-схему алгоритма работы компилятора.

Если тебе не жалко, то можешь поделиться опытом в разработке языка?

оффтоп.

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

По поводу библиотек. Может я до конца не понимаю... Но вроде примерно так и сделано в современных ОС. Хотя может я понимаю "библиотеки" немного не так. Тогда с радостью выслушаю твои мысли!

Мне конечно видится немного по другому решение этой проблемы... Но ведь в споре рождается истина!=))

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

 

eXod



Ладно. Ландно. Подолью ещё маслица в костёрчик.



Вот пример того, про что я говорю.



Допустим мы пишем работу с диском.

Как бы её можно было бы представить?



Вот я бы например представил в виде такого скрипта.

Слева - находится адресация - цилидр, номер головки, сектор.



Запись данных выглядела бы так:



2:4:1::=<=::$data1;

2:4:2::=<=::$data2;

2:4:3::=<=::$data3;

2:4:4::=<=::$data4;

2:4:5::=<=::$data5;



Ну а добавив понятие цикла, это можно было бы отразить по иному.

 

кхм... спасибо за маслице!=))))

постораемся гореть ярко!=)))

Обшую идею вроде начинаю понимать... и мне она даже нравиЦа!

_______________

офф

скрипты - это хорошо, пока дело не доходит до интерпретируемого кода, где они в скорости проигрывают. так что скриптофилософия, но исполняемая!=)

 

eXod



Будем считать - что скрипт - это обрезанный ЯВУ.



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



Скрипт интерпретируется НО компилятором В некотором смысле этого слова.



Вообщем я и так уже тут много наговорил лишнего..