Эксперимент

[SfS]

народ восставал против NMI по той причине что не надо вмешиваться в аппаратуру. имхо модульная структура позволит использовать все что угодно.

NMI - это идеальный вариант. МОжно и стандартный INT - это не принципиально. Так что если "народ восставал" - то пусть юзают стандартный INT. Но тогда зависшую после DI программу - не снимешь без рестарта. Впрочем - можно написать поддержку и NMI и INTа - пусть кому что нравится юзают.

а с другой стороны практически полное отсутствие защиты от несанкционированной записи в ядро

Ну это уж не проблема. Кому очень захочится такой защиты - могут сделать порт блокировки записи в нижние 16к ОЗУ. Или лучше - порт, который позволяет блокировать запись в любую из 4х страниц. Большинству же это поровну. ИМХО, для большинства - прошить ПЗУ большая проблема, нежели мириться с отсутствием защиты.

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

Ну это кому как удобнее. Совершенно непринципиальный вопрос.

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

В иделае - да. Но надо начинать с минимума. ИМХО, минимум - это разделяемая память, стандартный интерфейс драйверов и менеджер задач. Если пытаться реализовать все сразу - то только мороки больше будет.

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

Сразу в стандарте POSIX мыслишь ? ))) МОжет форки и нити на чуть потом оставим ?)
Я и не собирался 16К на процесс выделять. В ядре хранится таблица свободных странц и для каждой страницы есть флаг - занята она целиком под процесс или частично. Если целиком - то все понятно. А если частично - то на странице присутствует структура, типа локальной кучи. Таким образом на странице может быть много процессов.

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

Тут подходов может быть несколько. Не на всех компах все сработают. Скажем там где можно щелкать не только последние 16К памяти - все упрощается. На 128й стандартной машине - вообще сложно сделать нормально по быстродействию. Моя точка зрения - надо делать все по минимуму. Тогда быстрее будет виден результат. А затем уже дополнять чего не хватает.

Короче так или иначе - надо ориентироваться на 128к - стандарт как минимум. Для навороченных машин типа ATM - другой менеджер памяти однозначно нужен.

[Advertiser]

[Vitamin]

NMI - это идеальный вариант. МОжно и стандартный INT - это не принципиально. Так что если "народ восставал" - то пусть юзают стандартный INT. Но тогда зависшую после DI программу - не снимешь без рестарта. Впрочем - можно написать поддержку и NMI и INTа - пусть кому что нравится юзают.

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

Ну это уж не проблема. Кому очень захочится такой защиты - могут сделать порт блокировки записи в нижние 16к ОЗУ. Или лучше - порт, который позволяет блокировать запись в любую из 4х страниц. Большинству же это поровну. ИМХО, для большинства - прошить ПЗУ большая проблема, нежели мириться с отсутствием защиты.

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

В иделае - да. Но надо начинать с минимума. ИМХО, минимум - это разделяемая память, стандартный интерфейс драйверов и менеджер задач. Если пытаться реализовать все сразу - то только мороки больше будет.

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

Сразу в стандарте POSIX мыслишь ? ))) МОжет форки и нити на чуть потом оставим ?)
Я и не собирался 16К на процесс выделять. В ядре хранится таблица свободных странц и для каждой страницы есть флаг - занята она целиком под процесс или частично. Если целиком - то все понятно. А если частично - то на странице присутствует структура, типа локальной кучи. Таким образом на странице может быть много процессов.

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

Тут подходов может быть несколько. Не на всех компах все сработают. Скажем там где можно щелкать не только последние 16К памяти - все упрощается. На 128й стандартной машине - вообще сложно сделать нормально по быстродействию. Моя точка зрения - надо делать все по минимуму. Тогда быстрее будет виден результат. А затем уже дополнять чего не хватает.

Короче так или иначе - надо ориентироваться на 128к - стандарт как минимум. Для навороченных машин типа ATM - другой менеджер памяти однозначно нужен.

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

[lvd]

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

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

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

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

[Vitamin]

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

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

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

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

[lvd]

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

Таки есть ex (sp),hl всё же - но это как минимум ДИ и ещё полдесятка команд.

...Собственно это к вопросу о НМИ. Ты возможно помнишь, в zx.spectrum тоже был кадр такой - Andrew ?. Mikheev - и он как-то тоже поднял разговор о своей поделке на z80 - где на интах висели только обработчики прерываний от устройств, а на нмях - только свичинг контекстов. И он мужественно боролся с тем, чтобы нми не переключал контекст, когда он прервал инт (и видимо с семафорами тоже боролся - раз DI/EI не канает). И при этом бия себя пяткой в грудь утверждал, что мол котлеты отдельно, и мухи - тоже отдельно. Можешь на groups.google.com поискать архивы.

[Vitamin]

Таки есть ex (sp),hl всё же - но это как минимум ДИ и ещё полдесятка команд.

...Собственно это к вопросу о НМИ. Ты возможно помнишь, в zx.spectrum тоже был кадр такой - Andrew ?. Mikheev - и он как-то тоже поднял разговор о своей поделке на z80 - где на интах висели только обработчики прерываний от устройств, а на нмях - только свичинг контекстов. И он мужественно боролся с тем, чтобы нми не переключал контекст, когда он прервал инт (и видимо с семафорами тоже боролся - раз DI/EI не канает). И при этом бия себя пяткой в грудь утверждал, что мол котлеты отдельно, и мухи - тоже отдельно. Можешь на groups.google.com поискать архивы.

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

[SfS]

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

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

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

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

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

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

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

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

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

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

[lvd]

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

Вообще-то да - для форка не только же данные копировать, а ещё и дескрипторы всех-всех-всех файлов, девайсов, хзчего ещё.

Более того - вот есть у проги кусок данных - а в этом куске абсолютные адреса. А отфорканной проге надо данные скопировать - по другим адресам. И кто будет править абсолютные адреса?

[CHRV]

Да ну вы тут понаписали блин!
Если реализуется хотя бы одна десятая этого всего да на спек-128 - можно памятник заказывать разработчику (Правда я не знаю куда софт потом помещаться будет).
А еще прикиньте клевая штука получится - своп файл на 5.25дисководе!

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

[Vitamin]

Вообще-то да - для форка не только же данные копировать, а ещё и дескрипторы всех-всех-всех файлов, девайсов, хзчего ещё.

Более того - вот есть у проги кусок данных - а в этом куске абсолютные адреса. А отфорканной проге надо данные скопировать - по другим адресам. И кто будет править абсолютные адреса?

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