Эксперимент

[Vitamin]

Толком не пробовал, вызвала внутреннее отвращение, как и виндовз. Выжигать не из пзу, ведь уважаемая тобой линух не записана в пзу? Повторять ошибки синклера? Нет уж увольте... =)

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

Ду маешь я об оси сужу по стрелочкам и окошкам?

да нет, не думаю. просто так рьяно заявил "консоль только через мой труп!" что я аж испугался %))))

[Advertiser]

[Vitamin]

я несколько дезинформировал тебя и всех присутствующих, приношу свои извинения. аос - самостоятельная ось, не похожая ни на что другое. Хотя (судя по истории амиги) изначально вся аос планировалась наподобие никсов, тк один из кодеров до этого работал (точно не помню кто и что делал) над униксами.
А инфа какого плана тебя интересует? конкретно описания функционирования аос? могу выслать, как уже предлагал lvd, описание библиотек и на словах объяснить как оно работает=)

Есть еще огроменная фало по этому поводу, тож можно найти...

кинь линки на всю имеющуюся инфу. интересует архитектура, возможности, описания

[lvd]

человек советует юних и советует на нем не зацикливаться
а где можно взять инфу по этой ОС? а то заинтересовало

Наиболее полный источник - родные РКМы (ром кернель мануал то бишь) в амижных форматах (гипертекстовый amigaguide). Вот попробовал конвертнуть в хтмл (заранее сорри - автоматом всё бьётся в кучу мелких файлов). Ща буду сюда втыкать =)

[lvd]

Ещё - самое главное.
Файлы склеить в алфавитном порядке и раззипить как обычный зип.

Я не виноват - это всё хфорум - не позволяет 1 зип в 1.5 мега пихнуть, только таким извратом.


PS: читать начать можно с exec libraries - это основное (позволит составить представление о многозадачности на амми)

PPS: везде главный файл - MAIN.html

[lvd]

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

Для этого есть хороший аппаратный семафор - DI/EI (в момент доступа к глобальным таблицам). =)

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

Дык как ты себе представляешь форки без мму и без автоматического разделения данных (по мере надобности)?

[lvd]

а не стоит ли начать с глобального вопроса/опроса: зачем вам нужна ОС на спекке, какие задачи вы хотите возложить на ОС?

Этот вопрос можно обобщить: "зачем вам нужен спекк?"

[lvd]

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

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

(ух ты - моё 300-тое сообщение! осталось обогнать только cityace, dhau и chrv! =)

[Vitamin]

Для этого есть хороший аппаратный семафор - DI/EI (в момент доступа к глобальным таблицам). =)

в случае NMI DI/EI не помогут. вот плохо что команды типа SET 0,A,(IX+1) сначала меняют значение, а потом загружают. если б было наоборот, проблема семафоров решилась бы на ура. а так... надо думать

Дык как ты себе представляешь форки без мму и без автоматического разделения данных (по мере надобности)?

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

[Thenn]

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

[SfS]

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

Модульность - я обеими ногами-руками за ! Только начальные драйвера (винчестера, кллавы, экрана) - полюбому придется сразу в ядро пихать.

собсно да, но просто надо с осторожностью относиться к аппаратным доработкам

Почему ? Модульность позволяет и без особой осторожности. Есть поддержка нужной фичи на аппаратном уровне - грузим нужный модуль (или прописываем в настройках какогото модуля SuperFicha=On) и все. )

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

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

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

А с данными как ? Виртуализации памяти то нет. Так что либо - вся адресация в либах по базовому адресу+смещение, либо все данные для одной либы - в одинаковых адресах на разных страницах. Либо - копировать (о ужас!).

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

Согласен. Кроме того о чем я уже писал (драйвера винчестера, кллавы, экрана).