Новая ветка ядра

Kernel architecture questions
  • Человек вам наметки 64-битного ядра выкладывает, а вы сразу в крик - язык не тот.
    Может лучше сначала исходники просмотреть, и высказаться по сути, а не по обертке?
    В конце концов, если дело стоящее - можно и на асм перевести, а если фуфло - оно и на асме фуфло.
  • Смесь языков неизбежна в принципе: есть вещи, которые на ЯВУ не сделаешь. Но в любом случае главной проблемой является не язык, а проект. Пока его не будет, можно сколько угодно обсуждать языки, дизайны, шрифты, текстовые редакторы и прочая -- но всё без толку. А проектировать большинству попросту неинтересно: это длительная и кропотливая "теоретическая" работа, которой конца-края не видно, да и практического результата тоже (ведь, чтобы его увидеть, надо закончить проектирование, а затем и реализовать приличную часть из спроектированного -- а на это не один год уйдёт, если делать действительно полноценную систему, а не, как кто-то здесь заметил, "хелло-ворлд-ОС"). Наверное, тут уж каждый должен сам определиться, готов он работать в таком ключе или нет.
  • art_zh
    Ну, дык в том тои дело что Серж сваял нечно и говорит "Давайте!" - а чего давать то? Проекта нету, а уже начинать сразу писать код - получится Менует64 (форк 2) вид сбоку... Те же ананасы под соевым соусом.
    Даже если и есть у человека видение похожее на проект - он не хочет или не может сформировать в связанном виде понятном для остальных на человеческом языке. Так можно начинать проект одного человека (Приятно познакомиться, Вилле... Вилле, Приятно познакомиться...), но никак не коллективный проект.
  • Mario,
    А мне послышалось, что он сказал не "давайте", а "смотрите".
    Я тоже считаю что новая х64-ОС должна быть на 100% асме, а АМД64 - могучий и очень гибкий ассемблер, возможности которого gcc не раскрывает и на треть.
    Но начать кто-то должен - на том, что у него быстрее заработает.
    И структуру нового ядра гораздо легче понимать и обсуждать, если оно написано на ЯВУ.
  • Mario

    Наверное я не ясно выразился. Я обещал выложить заготовку для любознательных Самоделкиных. Я её выложил. Невозбранно. Может кому-то надо курсовую сдавать. Если интересует адаптация под конкретные условия постараюсь помочь.

    Что касается разработки Системы то у меня очень скептическое отношение к перспективам такой разработки. В том числе и потому, что
    Я допускаю использование Си в отдельных случаях, когда это оправдано, но не поголовно
    я считаю ровно наоборот.
  • Ну, вот теперь я услышал четкое определение - "либо Си, либо ничего". Отлично, успехов и удачи в этом нелегком начинании. Может быть что-то и получится, а может быть получится и очень здорово, но это совсем не мое. По сей причине считаю эту конкретную тему для себя завершенной. Буду думать свою думу.
  • Вот интересно, почему подобные темы всегда скатываются к вопросу выбора языка, компилятора или ещё чего такого, прямо скажем, далеко не первой важности, в то время как реально важные вопросы игнорируются?
  • Потому что здесь ассемблерщики. Остальные пишут на С. И на счёт важности. История возникновения С намекает.
  • Ну, во-первых, не все пишут на Си/Си++ (например, я, как уже говорил, пишу в основном на Дельфях, т.е. Паскале, а Максимыч и вовсе только флудит :lol: ). А во-вторых, по моим наблюдениям, практически каждая такая тема скатывается именно ко всяким второстепенным (в лучшем случае) вопросам независимо от того, кто участвует в обсуждении. Си, Паскаль, Ада, ассемблер -- это совершенно третьестепенное дело, если речь идёт о создании ОС, потому что выбор языка способен лишь упростить/усложнить реализацию, но абсолютно не влияет на проектирование, которое в задачах такого уровня составляет, наверное, 90% сложности.

    Кстати, об ассемблерщиках. Я вот ассемблерщик или нет? Пока работал с PDP-11 и IBM System/370 (точнее, с советскими клонами, но не суть важно -- архитектура-то одинакова, разница только в реализации), я писал практически исключительно на ассемблере, хотя с Паскалем и Си познакомился именно на PDP-11, а на System/370 приходилось и на Коболе писать (когда спускали с системных высот на "экономическую" землю). А вот перейдя на ПК и зная к тому времени с дюжину ассемблеров, если не больше, практически полностью перешёл на Паскаль -- не в последнюю очередь из-за крайней неудачности архитектуры процессоров 8086 (например, после указанных "древностей" сама идея узкой специализации регистров "общего назначения" казалась дикостью -- а на 8086, как известно, именно так дело и обстоит), хотя свою роль сыграло и удобство Турбо Паскаля. Весь прошлый год по работе писал исключительно на ассемблере -- но только не для ПК, а для 8-разрядных микроконтроллеров. Сейчас вот начинаю писать под АРМ -- и перехожу на Аду, ибо объём предстоящей писанины слишком большой, да и вменяемого транслятора ассемблера для АРМа не попадалось (ГНУсный -- это ужас, а не ассемблер, даже макросредств своих нет -- опирается на препроцессор Си), ну а для АТмеги по-прежнему пишу на асме. Если б передо мной стояла задача написания оси для ПК, сначала бы долго и нудно проектировал-документировал (год, два, три?), и только потом бы стал писать -- вероятно, на Аде же (из-за доступности достаточно эффективного 32/64-разрядного компилятора -- в составе GCC), хотя я, в общем-то, сторонник создания ядра и прочих компонентов, от которых очень сильно зависит общая производительность, именно на ассемблере.
  • SII
    Если б передо мной стояла задача написания оси для ПК
    Вот в этом "если б" и причина. Потому что в теоретических рассуждениях об идеальной операционной системе действительно неважно на чём её писать (хотя Вы склонаетесь к Аде) потому что система идеально. Но когда спускаешься на грешную землю, понимаешь что система это не только ядро и пара драйверов, а ещё много-много софта который должны писать много-много разработчиков. А у разработчиков свои привычные им инструменты и API и впаривать им про "уникальный, не имеющий мировых аналогов формат исполняемых файлов" и другие эксклюзивные достоинства ядра бесполезно. Они на это не ведутся. В результате "вся такая уникальная из себя" система остается в стадии Hello World OS или эффектной технодемки.
  • Как Вы совершенно верно заметили, "у разработчиков свои привычные им инструменты и API". Но, если исходить из этого, тогда надо вообще обеспечивать полную совместимость на уровне API с Виндой или, на худой конец, с Линуксом -- ведь основная масса потенциальных разработчиков использует эти системы, и предложить "привычные им инструменты и API" можно только таким способом. Но для чего тогда вы здесь делаете КОС? Ведь эта система никаким боком-раком ни с Виндой, ни с Линухом не совместима и вряд ли это планируется даже в отдалённом будущем.

    Ну а вообще инструментарий, использованный для написания системы, вовсе не обязан совпадать с тем, что используется для программирования прикладных задач под эту систему. Особенно заметно это в случае Винды: помимо мелкомягкой Вижуал Студии (в которой, кстати, имеется несколько языков), там используется (или, по крайней мере, может использоваться) куча других инструментов, например, Дельфи и GCC. Win32 API в "бизнес"-задачах напрямую используется не так уж часто (а скорее -- откровенно редко), ну а о Native API многие "профессиональные" разработчики и вовсе слыхом не слыхивали. Столь же глубоко чужды им форматы загрузочных модулей и прочие вещи: они просто не сталкиваются с ними напрямую, и всё, что им нужно, -- это более-менее удобная среда разработки с набором библиотек. Для быстрой и эффективной разработки прикладного ПО такие средства действительно необходимы, но каким образом это влияет на выбор языка для разработки самой системы?

    P.S. Собственно, я не ратую за или против какого-либо языка, хотя, конечно, имею личные предпочтения. Я ратую за то, чтобы вы (коллектив разработчиков КОС) прекратили "кодировать", добавляя всё новые и новые костыли, а сели бы, подумали хорошенько и тщательно спроектировали бы систему, а уже потом бы занимались её практической реализацией -- иначе дальше "хелловорлда с виртуальной памятью" дело всё равно не пойдёт, потому что утонет в бесконечных костылях.
  • SII

    Да, языков в Visual Studio много, а платформа одна - Net. И раз уж пошла речь об Империи Зла стоит вспомнить о Singularity и Sing#. Архитектура и идеология этой системы тесно взимосвязаны с инструментом разработки. Но это Microsoft может позволить себе такие эксперименты. Небольшим коллективам разумнее изобретать велосипеды с круглыми колёсами.
  • Платформ там две, и первая -- это всё ж Win32, .NET появилась много-много позже.
  • Но для чего тогда вы здесь делаете КОС? Ведь эта система никаким боком-раком ни с Виндой, ни с Линухом не совместима и вряд ли это планируется даже в отдалённом будущем
    Лично мне нужна для вычислений. Численное моделирование - это для меня очень важно. При длительных расчётах в Win появляются "непредвиденные" глюки, к тому же она платна и не столь гибка, как мне нужно. Linux в этом плане не плох, но он всё таки большой в плане размера и сложности ядра операционной системы. И чтобы переделать его под свои нужды необходимо прочитать немало толстых книжек/мануалов. Kolibri из-за её относительной простоты и малых размеров я могу адаптировать под свои нужды. Если ещё будет драйвер ATI поддерживающий AMD Stream Computing , то для меня вообще будет вычислительный рай :mrgreen: .
    Кстати, отсутствие свопа в KolibriOS -это большой плюс для меня. А быстрое ядро - это уже почти RTOS для одного процесса. Для меня - это тоже важно.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Who is online

    Users browsing this forum: No registered users and 4 guests