OSDev

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

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

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

Почему же не реализовать? У меня одна из приоритетных задач - реализация POSIX-подсистемы, т.е. поддержки POSIX поверх собственных сервисов системы. Это позволит запускать POSIX-совместимый софт, т.е. большую часть софта для unix-подобных систем. Собственное API системы достаточно мощное и позволяет эффективно реализовать специфические вызовы вроде fork или execve в режиме пользователя.

Есть ли он этот POSIX-совместимый софт, я не знаю, но опять же для этого софта нужны все API функции системы, под которую этот софт писался, т.е. придётся доказать, что ваша ОС выполняет эти функции лучше имеющихся, так же если та система где этот софт работает популярности не имеет, то и вашу систему ждёт такая же учесть, причём вы утоните в бесконечной поддержке этого софта.
Реализация системы с хорошей параллельностью, использующую все спеки открытые от интел, ртл былобы самой лучшей системой, но опять же без ПО. Но эта задача легче первой.
Нужно понимать, что при создании хорошей параллельность, воспользоваться ей можно будет только из нового ПО, которое собственно будет пользоваться этой параллельностью.
Например редактор текста должен будет создавать символы в виде тех же пакетов один раз, для отправки на экран сто раз одной ссылкой на пакет, иначе опять затраты на постоянную конвертацию.

Если бы ОС была статичной и не нужно было думать о её развитии - асм вне конкуренции. А ОС для общего применения - это поиск между "быть лучше здесь и сейчас" и "время всё расставит по местам". Выбор языка очень сильно определяет что получится.

Но, каким бы языком не пользовались, в итоге получим машинный код и алгоритм. Алгоритм работы с устройствами один для всех, а работы с данными много. Данные можно сразу подготовить а не конвертировать их постоянно и т.д.
Если сравнивать АСМ и ЯВУ, то понятно, что забивать сразу машинный код работающий с устройствами даёт приемущества перед забиванием алгоритма на языке ЯВА которые пользуются библиотеками работающими с устройствами, тем что возможно нужных библиотек то не будет.

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



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



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

Это собственно задача только создателя ОС, продумать в каком виде данные будут обрабатываться быстрее, создать доку, чтобы разработчики пользовались этим форматом.
Если данные созданные один раз выводятся тысячу раз, то их лучше не конвертировать.
Ну или конвертировать только заголовок данных.
Современные контроллеры уже не изменяться, или это будет уже другие скорости, и системы.

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

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