Эксперимент

[random]

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

а чем пример с WORMS не яркое опровержение тобой предсказуемых "тормозов"?

[Vitamin]

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

я имею в виду модульность на этапе компиляции, а не только на этапе выполнения. см. соответствующий тред в ветке про программирование

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

туда же. но надо чтобы был обеспечен какой-либо минимальный набор аппаратуры на которой бы все запустилось

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

дык одних алгоритмов синхронизации штуки 4 только %) (почему запомнил- слегка "поплавал" на них на экзамене %))

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

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

[Vitamin]

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

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

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

[Vitamin]

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

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

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

[Vitamin]

Cкидываю отредактированный файл в котором нарисована структура ОС, как я ее представляю. Критикуйте.

видно, человек проникся идеологией С/UNIX

VFS и таблицы драйверов с виртуальными (практически) функциями- самое то что надо.

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

[Vitamin]

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

посмотри на структуру любого нормального обработчика прерываний:

push all_registers
do_smth
pop all_registers
ei
ret

а теперь на структуру диспетчера задач при вытесняющей многозадачности:

push all_registers
change_sp_ptr
pop all_registers
ei
ret

похоже слегка, не так ли? %)

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

[CHRV]

Дело в тормозах не потомучто обработчик-распределитель долго работает, а потомучто фоном еще куча фигни не нужной выполняется.
Конечно есть задачи которые нужны, там типа часов, АУ плеера, так пусть они и вставляют свой вызов в обработку прерывания.
А например мне нужно простейшая задача: редактор+ассемблер+спрайтэ дитор, и я не хочу чтобы они в фоне еще там чего то квакали . Но переключаться мануально между ними я очень хочу!

[Corpsegrinder]

Да! серьёздно разраслась тема, и правда уже пора писать техзадание, даже на основе того, что здесь уже выложено.

Коментарии по ходу чтения:

1. Предложеная Vitamin'ом схема разделения памяти - хороша тем, что позволяет унифицировать все процессы - они хранятся в 16 кб страничках, как аласм. Кдинственное в ней в сегменте между #8000 и #c000 нужно давать возможность размещать как разделяемые несколькими потоками данные быстрого доступа, так и часть кода для быстрой обработки данных лежащих вне страницы с основным кодом (иначе я себе просто не представляю как делать те же текстовые редакторы или асемблер - они же тормозить будут)

2. Споры по поводу INT vs NMI считаю неконструктивным поскольку и то и другое можно реализовать и выбирать при помощи настроек системы. У кого есть MNI каждую милисекунду - настраивает на работу с NMI, у кого нет - на работу через INT. Что качается периода вызова, тоже не вижу проблем, можно так же настраивать период квантования для правильного учёта процессорного времени (для INT 1/50 секунды, для NMI - уж как реализована аппаратная часть). Разумеется при загрузке и инициализации сначала все работать должно на INT а то и вообще с запрещёнными прерываниями, а уж потом, если есть соответствующие настройки - включает через порты фишку с NMI раз в 1 милисекунду и разуется жизни форева. С INT будет вытесняющая многозадачность (di поставил и жрёшь ресурсы сколько влезет) а с NMI - вытесняющая, посколько прерывания немаскируемые.

3. По поводу Fork и разделяемого кода. Можно для библиотек ввести дескрипторы (2-4 байта - систему выдачи уникальных идентификаторов вроде GUID у мелкомягких), такие же дескрипторы использовать и для приложений, тогда можно будет при необходимости пользоваться чужим кодом вызываю его через дескрипторы. Так же, в случае fork, Vitamin верно предложил, по минимуму можно для нового потока, порождённого через fork, копировть только стек, ну ещё контексты (вроде DC в виндовз).

4. Замораживающая многозадачность уже реализована в QC и RC, а так же в ACE и Alasm но от этого никому легче не становиться, програм поддерживающих это практически нет, разве что выход в командер после прочтения текста в листалке, созданной с помощью TextMaker, да по всей видимости в продуктах AlCo.

Теперь по поводу необходимоси всего этого, если бы всё это было не нужно и неудобно, никто бы не заглядывался на писюки и амиги вот как там здорово можно несколько задач выполнять не делая сброс компьютера. Другое дело, что чтобы сделать дейстующий экземпляр чего-то такого придётся неплохо поломать голову и немало времени потратить на реализацию, особенно, если будет хорошо поддержана совместимость со старыми программами, хотябы под TR-DOS.
Без приложений ОС не нужна никому кроме как разработчиков, которые семореализовались, написав её. А запускать программы пользователю фиолетово, хоть через TR-DOS+boot/командер хоть через супер-пупер навороченую ОС с многозадачностями. С точки зрения программиста, в ОС для спека особенно важно, чтобы ограничений на оптимозацию работы программ под неё было минимум. Но и эта проблема, я думаю, не слишком тяжела, если всё правильно спроектировать и разработать механизм быстрого доступа к данным и коду, как собственной программы, так и ядра системы(один из вариантов решения этой задачи я уже предлагал в пункте 1).

[lvd]

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

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

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

Ну и отлично. 3 задачи висят в памяти. Работаешь с редактором - его экран показывается, сообщения от мыши и клавы идут ему. В это время спредитор или асм спят - их экран не активен и сообщений ему не идёт, шедулер их не запускает.

[lvd]

2. Споры по поводу INT vs NMI считаю неконструктивным поскольку и то и другое можно реализовать и выбирать при помощи настроек системы.
[skip]
С INT будет вытесняющая многозадачность (di поставил и жрёшь ресурсы сколько влезет) а с NMI - вытесняющая, посколько прерывания немаскируемые.

Вытесняющая многозадачность не имеет отношения к INT/NMI. Зато вот простейшие действия типа критических частей (в самих ф-циях оси, например!) вызывут кучу проблем при НМИ и всего лишь DI/EI при INT. А что касается железных доработок - уж лучше контроллер прерывания поставить, чем генератор НМИев каждуй миллисекунду (хм - а может каждые 100 тактов сразу?).