Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Oct 26, 2021 6:35 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 70 posts ]  Go to page Previous 1 2 3 4 5 Next
Author Message
 Post subject:
PostPosted: Wed Mar 14, 2007 9:33 am 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 431
что то Serge я просто не узнаю, извини, но похоже ты "завёлся" и даже не замечаешь, что ты сам пишешь сплошные "перегибы" и даже противоречивые вещи...
Было сказано мною выше, что виллис внес большой вклад, а именно УБУЧИЛ (а не как ты говоришь учитесь), помог, вдохновил к обучению..... надо честно сказать, МНОГИХ ассемблерщиков своей....
Это раз.
А два, НЕ "новую ось" и ля-ля-ля... два джампа, а читаем выше "переосмысление, перерождение...." пройденного = УЖЕ ИЗУЧЕННОГО(!) и
"оптимизация, модернизация, мутация.... В ПОЛОЖИТЕЛЬНУЮ СТОРОНУ именно БЛАГОДАРЯ САМОСТОЯТЕЛЬНОМУ ИЗУЧЕННОМУ МАТЕРИАЛУ:...... и вилли тут отдыхает в тени.
Что тут не так? Если человек УЖЕ вырос из пеленок и памперсов и соски, зачем ему ЭТО? По-моему незачем ему ностальгировать по памперсам, если он уже и сам шагает и кушает ложкой... Вполне логично, а так думаю.
По поводу разрядности процов согласен с Phantom-84 и не зачем кивать и перегибать по поводу 8 и 16 и т.п.... Опять же я упомынул выше - это отдельная тема. Она у Вас тут кстати есть, как опрос. И этото же информация к размышлению.


Top
   
 Post subject:
PostPosted: Wed Mar 14, 2007 6:46 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
VaStaNi

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

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

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


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 7:14 am 
Offline

Joined: Sat Jan 14, 2006 12:00 am
Posts: 25
Я пока не изучал подробно тему перехода на 64-битную архитектуру + многопроцессорность, но имхо тут нет особых проблем.

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

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

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


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 8:04 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Sаsh

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


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 8:15 am 
Serge
Наверное придется делить ядро на отдельные модули:
1) Универсальные
2) 32-х битные
3) 64-х битные
А при многопроцессорной точно придется перекроить все ядро.


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 10:29 am 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 431
Serge wrote:
Ты предлагаешь всё приостановить и заняться большим переписыванием ?

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

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

Итак "слышим" переписывание из разных уст, а теперь смотрю выше на счет
Serge wrote:
Пока травка подрастёт, лошадка с голоду помрёт.

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


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 10:45 am 
VaStaNi
Сделай тему - давай начнем проектировать, главное чтобы кроме слов то, что надо бы сделать то-то - нужно начать уже говорить, как это сделать. Глядишь, люди втянутся. Можно ведь параллельно развивать и текущее ядро и альтернативное. Очень может быть, что и я поучаствую в меру моих физических и умственных способностей, поскольку в текущем ядре я уже не участсвую как системный программист и относительно свободен от обязательств по текущему ядру.


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 11:24 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Я согласен, с тем, что чем дальше огород сейчас городить, на фундаменте, который, был построен не очень качественно, глупо. Я полностью согласен, что через некоторое время, всплывет вопрос о том, что нышешний код не может отвечать потребностям, и придется начинать всю работу с начала. Я готов принять участие, в меру своих возможностей. и времени в разработке нового ядра.


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 12:16 pm 
Offline

Joined: Wed Jul 05, 2006 9:00 am
Posts: 81
Я тоже готов принять участие в разработке нового ядра.


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 3:29 pm 
Давно пора. Я - за :) не чувствуется идеи в этой ОСи, точнее идея давно себя исчерпала - "сделать операционку на 1 дискетке, с похожими на винду окнами"...


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 5:51 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
VaStaNi

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

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

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

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


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 5:58 pm 
Offline

Joined: Mon Aug 07, 2006 11:31 pm
Posts: 59
Прочитал всю тему. Немного расстроился. Из-за того что я не программист и возраст у меня уже не тот, чтобы начать изучать ассемблер..
Но я уже предчувствую революцию (матрица)

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

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

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


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 6:24 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Вот читаю я сообщения и никак немогу понять, что понимается под фразой ,-"новое ядро".
Объясните пожалуйста.

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).И с софтом также.

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


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 6:34 pm 
Offline
User avatar

Joined: Thu Oct 13, 2005 12:00 pm
Posts: 298
Quote:
У буддийских монахов есть традиция - долго и кропотливо писать большую икону при помощи цветного песка, а когда икона закончена, они без сожаления сметают ее метлой и принимаются ха новую. Ассемблер - это почти буддизм :)

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


Top
   
 Post subject:
PostPosted: Thu Mar 15, 2007 7:53 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
andrew_programmer

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

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

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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 70 posts ]  Go to page Previous 1 2 3 4 5 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited