VaStaNi

Завёлся. Точно.
Надоели пустые "давай..." Причём тот кто эти "давай" выдвигает сам ничего дать не может или не хочет.

>НЕ "новую ось" и ля-ля-ля... два джампа, а читаем выше "переосмысление, перерождение...." пройденного = УЖЕ ИЗУЧЕННОГО(!) и

А мы чем занимаемся ?
Сравни исходники 079 и последний SVN. Там уже совсем другое ядро.
Ты предлагаешь всё приостановить и заняться большим переписыванием ?
Пока травка подрастёт, лошадка с голоду помрёт.

Я пока не изучал подробно тему перехода на 64-битную архитектуру + многопроцессорность, но имхо тут нет особых проблем.

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

Многопроцессорность. Здесь нужно написать драйвер контроллера, позволяющего общаться с остальными процессорами. В любом случае ядро запуститься на каком-то одном процессоре и оттуда будет управлять всеми остальными задачами. Для каждого процессора будет создаваться свой список задач, и между ними будет происходить переключение. Возможно, потребуется запускать ядро на каждом процессоре, хотя это маловероятно и так нигде не делается. Есть ещё варианты, когда ядро работает на отдельном процессоре, а пользовательские задачи – на остальных процессорах (асимметричность). Здесь тоже ничего сложного нет. Главное - изначально писать код под n-процессорную систему, а не под 2- или 4-процессорную.
Единственная проблема - то, что при переходе на 64-битную архитектуру, старые компьютеры останутся за бортом (а ведь это те компьютеры, где КоОС очень даже полезна). Было бы неплохо содержать в ядре два менеджера памяти - старый и 64-битный, и использовать тот, который поддерживается процессором. Правда, я пока не слышал, чтобы кто-то сделал такую гибридную ОС.

Если я в чём-то неправ, то поправляйте.

Sаsh

В АМД-64 4Кб и 2Мб страницы памяти. Скрестить 32-х битный и 64-х битный код не получится. Потребуется переписывание. Главная проблема с SMP - синхронизация доступа к данным. Простой cli здесь не работает необходимы спинлоки и cоответственно опять переписывание кода

Serge
Наверное придется делить ядро на отдельные модули:
1) Универсальные
2) 32-х битные
3) 64-х битные
А при многопроцессорной точно придется перекроить все ядро.

Serge wrote: Ты предлагаешь всё приостановить и заняться большим переписыванием ?

Скажем так, именно и предлагал, призывал, кричал 2-3 года назад, убеждал, приводил логику, пытался сказать что за проблемы (особенно тупиковые!) будут если не... Но это в прошлом и жаль, что это сегодня нельзя перечитать вновь.
И некогда "вчера" я это бросил, сказав даже, как то Марату в своей эмоционально-философском, многословном монологе, что видимо каждому созреванию, прозреванию, восприятию... свое время и срок и ничего тут не поделать + взаимопоимание друг друга в RU общественности далеко не на высоте и не только в связи с разными уровнями познаний или возраста или гражданства..., а это большой "-" у НАС!
Сегодня я по большей мере везде, где бываю, скажем так, созерцаю, жду, ищу "собутыльников по разуму" , благодатную почву к применению и т.п. Конечно мало времени на "все", а этого "все" в жизни очень много приходится выгребать, а следовательно удельный вес каждой минуты..., значит тут вступают приоритеты, так сказать, "жизненных задач" и повысить приоритет некого "любимого теневого процесса" может хотябы % вероятности упешного вложения сил, времени, здоровья. Если он видится мною хотябы как 70-80% успеха, то приоритет выростает на порядки. Такая вот личностная многозадачность

Serge wrote:Потребуется переписывание. Главная проблема с SMP - синхронизация доступа к данным. Простой cli здесь не работает необходимы спинлоки и cоответственно опять переписывание кода

Mario79 wrote: Наверное придется делить ядро на отдельные модули:
1) Универсальные
2) 32-х битные
3) 64-х битные
А при многопроцессорной точно придется перекроить все ядро.

Итак "слышим" переписывание из разных уст, а теперь смотрю выше на счет

Serge wrote:Пока травка подрастёт, лошадка с голоду помрёт.

а как на счёт сроков переписывания с учетом растущего объёма переписывания, усложнения т.п.??? Не будет ли ото воспринято как большое падение проекта при этом раскладе и тогда лошадка точно помрет... А может тут справедливо высказывание типа "раньше сядешь - раньше..."? коль уж пораскинув видится БОЛЬШИЙ вред от промедления, затягивания... так ведь, по неосторожности, извините, удавочку на собственной шее зятянуть можно, особенно если приплюсовать еще некий печальный довесок фактов, как то: количество и качество участников и вклада в ядро, в радикальное новаторство, проектирование, путь хоть и скромное, но некое свое ноу-хау...
Как тут на весах "-" и "+" смотрятся, а? Ведь даже слепцу видно - объёмы ассемблерных работ растут хоть так, а хоть вот эдак и фактом остается незбежность: "чем дальше в лес - тем больше помидоров":(

VaStaNi
Сделай тему - давай начнем проектировать, главное чтобы кроме слов то, что надо бы сделать то-то - нужно начать уже говорить, как это сделать. Глядишь, люди втянутся. Можно ведь параллельно развивать и текущее ядро и альтернативное. Очень может быть, что и я поучаствую в меру моих физических и умственных способностей, поскольку в текущем ядре я уже не участсвую как системный программист и относительно свободен от обязательств по текущему ядру.

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

Я тоже готов принять участие в разработке нового ядра.

Давно пора. Я - за не чувствуется идеи в этой ОСи, точнее идея давно себя исчерпала - "сделать операционку на 1 дискетке, с похожими на винду окнами"...

VaStaNi

>а как на счёт сроков переписывания с учетом растущего объёма переписывания

Нечего переписывать. Надо всё заново писать.

Колибри/МеОС проект тупиковый. Виноват в этомм не столько Вилле сколько AMD-64 и Intel HT DP Duo Quadro. Он это первый понял и свалил, только вместо нормальной новой системы начал переписывать старую, сохранив всё её убожество.

Сделать одну систему для 32-х и 64-х бит с разными модулями не получится. Точнее не надо этого делать потому что ничего хорошего из этого не выйдет (см. МеОС64) Единственное что можно сделать это эмуляцию системных вызовов Колибри, чтобы старые программы могли работать в 64-х битной среде - KolibriBox. Так что общим у систем может быть только название.

Прочитал всю тему. Немного расстроился. Из-за того что я не программист и возраст у меня уже не тот, чтобы начать изучать ассемблер..
Но я уже предчувствую революцию (матрица)

Я тоже ЗА новое ядро, а значит и новую, отечественную свою ОСЬ..

Я бы, друзья, вам помог бы, но программировать не умею...
PS: хотя если вы проведете револцию и выскажете все свои идеи насчет будущего, то быть может народ и я потянусь к учебнику ассемблера..

PS2: кстати, я за 64-битность.. Потому что пока мы раскачаемся, 32-битность в массах исчезнет. Это факт (взгляните на 16-битные системы, они прожили не так много, как например 8-ми битники..А 32-битные появились давно и уже есть им замена, так что нельзя отставать..)

Вот читаю я сообщения и никак немогу понять, что понимается под фразой ,-"новое ядро".
Объясните пожалуйста.

Serge

>Нечего переписывать. Надо всё заново писать.
Колибри/МеОС проект тупиковый. Виноват в этомм не столько Вилле сколько AMD-64 и Intel HT DP Duo Quadro. Он это первый понял и свалил, только вместо нормальной новой системы начал переписывать старую, сохранив всё её убожество.

Вообще-то Колибри запускается и работает на 64 битных процессорах.Если имелось ввиду использование 64-х битности на всю катушку, то тогда действительно надо многое писать с нуля.

>Единственное что можно сделать это эмуляцию системных вызовов Колибри, чтобы старые программы могли работать в 64-х битной среде - KolibriBox. Так что общим у систем может быть только название.

А разве драйверы общими быть не могут ?
Понятно, что некоторые драйверы нужно адаптировать под 64 битные процессоры, но не писать же всё с нуля.

Это получается, что проект Колибри должен как бы разделиться на 2 части.Одни люди будут заниматься 32-х битной колибри, которая будет работать в диапазоне процессоров Pentium1(AMD-K5) .......самые последние версии 32-х битных процессоров от AMD и intel.Другие люди будут заниматься системой с названием Колибри, которая может эмулировать системные прерывания 32-х битной Колибри, но при этом будет иметь другое ядро.
Общим у систем будут названия и некоторые драйверы, а также программы.
При разработке обоих ядер будет происходить синхронизация в добавлении нового(новые драйверы и для Колибри32 и для Колибри64+SMP).И с софтом также.

Я правильно понял ?

У буддийских монахов есть традиция - долго и кропотливо писать большую икону при помощи цветного песка, а когда икона закончена, они без сожаления сметают ее метлой и принимаются ха новую. Ассемблер - это почти буддизм

А разве нельзя все прелести старой системы сохранить при написании новой: красивый графический интерфейс и компактность?

andrew_programmer

Ты всё понял совершенно верно.
Выше я писал о современной полнофункциональной ОС. Это моё представление, у каждого оно может быть своё. Можно пойти путем Вилле и адаптировать код под 64-х разрядность но ИМХО это приведёт в тупик. Общих драйверов не получится 64-х разрядной среде нужны родные драйверы, разумеется они могут быть похожи но не слишком.

>Это получается, что проект Колибри должен как бы разделиться на 2 части

Да. Если учесть объём работы и число разработчиков которые могут делать эту работу то шансы нулевые.

Вообще прежде чем заваривать новую кашу надо определится чего мы хотим. Должна быть в системе виртуальная память, SMP или нет ? И можем мы это сделать ?