Эксперимент

[Alex/AT]

К предложенному ядру RTK вытеснение задач добавить - как два пальца... Если надо - сделаю.

[Advertiser]

[random]

К предложенному ядру RTK вытеснение задач добавить - как два пальца... Если надо - сделаю.

respect! внес здравое зерно в дискуссию. а как насчет выделения памяти и тд?

[SfS]

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

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

[Alex/AT]

Про выделение памяти уже думал... Если бы была возможность переключать не только верхнюю страницу - все бы было здорово. А так напрашивается только копирование... Или еще возможна сегментация области кода - т.е. выделяется 4-8 кб под код, если программа хочет еще - она говорит ядру - "скопируй мне новые 4-8к вот отсюда, и запусти их с адреса такого-то". Имхо разумный вариант.

З.Ы. Следующую "preview" ZX-Worms project 2 (с ядром на RTK) положил в "Игры".

P.P.S. Если речь идет о С/C++ и совместимом рантайме (*nix) - то можно C-ядро держать в несвапабельной странице...

[lvd]

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

Вообще-то здравая мысля была - оставаться в рамках обычного 128к спекки. А если так, то НМИ отдыхает. А если говорить о хардваремодах, то тогда КУДА логичнее контроллер прерываний нормальный, а не нми.

Кстати, завесить нми - как два пальца об асфальт - стек в ПЗУ и прощай...

[Vitamin]

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

fork- всего лишь метод создания процесса. а диспетчеризация- дело другое.

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

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

[Vitamin]

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

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

2. Споры по поводу INT vs NMI считаю неконструктивным поскольку и то и другое можно реализовать и выбирать при помощи настроек системы. У ..skipped

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

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

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

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

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

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

[Vitamin]

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

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

[Vitamin]

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

[Corpsegrinder]

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

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

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

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

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

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