Эксперимент

[lvd]

ММУ - не обязателен, хотя и желателен. Что касается "монстроидности" ядра - все зависит от набора его функций. Если взять минимальный набор - то ядро совсем компактненькое получается. Реально - у меня для ARMа реализация менеджера памяти (кстати - тоже без ММУ) и стандартного интерфейса драйверов - около 5 Кбайт занимает. И это учитывая, что длина команды ARMa - 16 бит всегда (в режиме THUMB, который я использую). Для Z80 - программа явно короче будет.

Ну вот - 5 кб, в то время как сколько там упакованное ядро линуха обычного занимает? Пример, как не надо делать на спектруме =)

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

Ну нифига себе не ось - кто-то тут предложил все 32 кб (ил 48?) младших адресов угрохать на ось! =)))

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

Особенно важно распределить приоритеты задач. Я в свое время писал для AT90S8535 программку для управления тех процессом. У меня была жесткая привязка к реальному времени следующих вещей - 4 7сегментника, три канала АЦП - измерения напряжения трежфазной сети. Молодой был, глупый. Пока приоритеты правильно между задачами не распределил - индикатор маргал неравномерно и ьбезбожно, сеть мерялась ужасно. Думал быстродействия не хватает, а оказалось - приоитеты задач - это не пустой звук. Переделал - все как часы заработало.

Не вижу проблем. Сделать преемптивную (вытесняющую) многозадачность - есть 128 (например) приоритетов, на каждом - своя очередь задач. Если на высоком приоритете нету жаждущих процессора задач - отдавать время низшим приоритетам. Если задача проснулась, поделала чего-то и затихла до истечения её кванта (20ms), - опять же, остаток низшим приоритетам. Для особо важных дел задачи могут вешать свои сервера на прерывание.

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

Ничего делать не придётся. Достаточно DI, а далее вообще вытворять всё, что угодно. =)

[lvd]

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

Это к вопросу о DMA USC. =)

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

Или из библиотек - как на амиге. Кстати - у меня собственно есть подробные описания амигаоса в виде тамошних *.guide - могу выложить - и попытаться даже в хтмл сконвертить - стоит?

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

См. моё предложение в предыдущем посте - комментарии?

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

Тут имхо как раз основные проблемы

Мелкие проги будут себя хорошо чувствовать в страничках (по 16кб), а крупные ? Например, уровня аласма - полностью без использования памяти #0000-#BFFF ? Даже написать такое - мазохизм будет... И вообще, как ты себе представляешь работу с выделенной памятью? Например, хочешь ты выделить память под хранение переменных к-л проги, вот дали тебе кусок, скажем, 256 байт - а дальше что - постоянные ld a,(ix+n) или ld h,'addr, ld l,переменная ld a,(hl)? А если эта память в другой странице - не в той, где код работает?

[lvd]

Мдя Идей вижу много, идей хороших и неочень, но вот в чем вопрос, а чего всё это грузить? с дискет ? не кажется ли вам, что стоит начать написание оси с начального старта компьютера, с boot-strap'а ?

НЕТ! Не кажется. Это вообще то, что в самом конце делается.

короче нужна FS! будет FS - будет над чем работать! (я как раз и работаю над этим вопросом )

Не нужна - пока и тырдос сойдёт.

кста по поводу раздела памяти #4000 - #8000 - таблицы и подгружаемыые драйвера ? по поводу таблиц ничего против не имею, а вот надчет дров, все видимо дружно заб(и/ы)ли что это область slow memory !!! и всё это будет жутко торрмозить! единственное для чего эта область пригодна это для хранения данных!!!

А ты недружно забыл, видимо, что слоу мемори только на фирменных и на самых примитивных клонах? В нормальных клонах везде быстрая (точнее, везде одинаковая =).

[CityAceE]

Объясните мне, пожалуйста, для чего на Спектруме может понадобиться многозадачность?

На мой взгляд самым оптимальным было бы иметь такую задачность как, например, в MagOS.

[CHRV]

Объясните мне, пожалуйста, для чего на Спектруме может понадобиться многозадачность?

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

[Alex/AT]

Вот, кому надо - ловите ядро управляемой многозадачности. До 8 тасков + поддержка спецтасков с четкой синхронизацией по времени в кадре. Полезно для игрушек (используется в текущем проекте ZX-Worms -= Project Two =-) и много для чего другого. A80 - исходник, RAR - демонстрашка

P.S. Хочу отметить низкие ресурсные требования данной штуковины. На внутреннее переключение тасков уходит 156-195 тактов. На вызов RTK_TSLICE (отдача времени другим таскам) - 131 такт, на отдачу времени до следующего прерывания - вызов RTK_TIDLE - 164 такта. Итого имеем всего лишь от 287 до 359 тактов на фактическое переключение таска. Если в этот момент происходит отработка критического (синхронизированного) таска - еще 174/138 тактов, но это одноразово. На прерывание уходит тоже всего ничего - 272-296 тактов.

P.P.S. Как пользоваться. Для начала настраиваем в исходнике расположение системных таблиц (RTK_ISR, RTK_IST, RTK_CTS/RTK_CTC, RTK_TEL, RTK_TS), а также самого RTK - ставим ORG, ему нужно порядка #200 байт. В начале программы делаем RTK_INIT, добавляем таски, разрешаем прерывания, делаем HALT и уходим (без возврата) на RTK_EXEC. Дальше всем рулит RTK.

Добавление тасков - в HL кладем указатель на инициализатор таска, в DE - указатель на описатель таска (рассчитывается как RTK_TS+<номер таска 0-7>*8). Вызываем RTK_INITTASK. Затем правим RTK_TCP, сбрасывая в нем бит соответствующего таска (биты по порядку: 128 - таск 0, 64 - таск 1 и т.д.). Если таск "обязательный" - должен обязательно исполняться раз в прерывание, то делаем то же самое в RTK_TCR. Высшим приоритетом обладает TASK0, низшим - TASK7 (хотя приоритеты, в общем-то, равны, но TASK0 исполняется раньше).

Добавление синхронизируемых тасков - по адресу RTK_CTS лежит список на 32 таска по 4 байта на таск. Первый байт - последний ли это синхротаск в списке (1 - последний). Второй байт - точка синхронизации (в единицах по 1024 такта). Третий и четвертый байты - точка входа в синхротаск. Далее очевидно. Синхротаски должны быть ОБЯЗАТЕЛЬНО отсортированы по точке синхронизации в порядке возрастания.

Теперь о тасках. Примитивный таск выглядит так:
; initialization
TASK
LD SP,TASK_STACK+#100
CALL RTK_TINIT ; done

; task code
TASK_1
... do something ...

; release slice (optional)
LD A,1
CALL RTK_TIDLE

... do something ...

; idle task
LD A,1
CALL RTK_TIDLE
JP TASK_1

Т.е., до инициализация начинается с TASK. До вызова RTK_TINIT надо настроить стек таска. После RTK_INIT таск начинает исполняться. RTK_TSLICE - опциональный вызов на отдачу времени другим таскам (от максимального периода времени выполнения каждого таска зависит точность синхронизации). RTK_TIDLE - отдача времени до следующего прерывания (для обязательных тасков), или до того, как таску вновь будет разрешено выполняться (для необязательных, т.е. новый вызов будет только после выполнения всех остальных тасков). В аккумуляторе при вызове TIDLE/TSLICE должно находиться количество времени, занятое исполнением таска после предыдущего вызова, в единицах по 1024 такта (1=1024, 2=2048 и т.д.). Выполнение таска в следующий раз продолжается после команды вызова TIDLE/TSLICE, стек восстанавливается, все регистры теряются (поэтому нужные перед "отдыхом" надо положить на стек или в переменные).

Критические таски используют основной стек (стек контекста вызова RTK_EXEC), и должны возвращаться по RET. Перед возвратом в аккумуляторе - количество времени, занятое таском (в 1024-тактовых единицах).

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

[Advertiser]

[lvd]

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

Нету многозадачности - нету и оконного интерфейса нормального, и тд, и тп. Аля-магос - а зачем тогда и вообще ось нужна? Наклонировал цп/мок в памяти с 1 виртуальным диском (или винтом) - и работай себе.

[Alex/AT]

Аааа... ушла уже страница. Сообщением выше положил решение для многозадачности.

[Vitamin]

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

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

Однозначно - кэш. Тогда ОС можно апгрейдить и изменять без перепрошивки ПЗУ. Огромный плюс.

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

Ядро и драйвера к нему должно поставляться либо в исходных текстах (для крутых кульхацкеров) либо просто под конкретную конфигурацию, которая в общем определяется набором встроенных- и подгружаемых драйверов. Скажем будет версия "SuperpuperOS v,Pentagon-1024" или версия "SuperpuperOS v,АТМ-7.10". Пользователь ее скачивает, устанавливает и работает - без гребли с компиляцией.

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

Привязка событий к окошкам - это извратик. Есть понятие "процесс". Есть понятие "сигнал". Несколько "процессов" могут обмениваться "сигналами" межу собой. А рисует процесс окошко или передает данные по модему - не принципиально.

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

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

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

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

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

Распределение памяти мне видется примерно таким:
------------------------- #FFFF
Пользовательские процессы.
------------------------- #C000
Область разделяемых данных
------------------------- #8000
Системные таблицы+подгружаемые драйвера
------------------------- #4000
Ядро+встроенные драйвера.
------------------------- #0000

Такая схема будет работать минимум на 128к, если есть возможность повешать на NMI таймер (хотя можно и через INT - но повиснуть может). Главное, чтобы имелся порт для включения теневого ОЗУ с адреса #0000.

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

[Vitamin]

Теоретиков, вижу, много. А где же практики???

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