FUZIX для Ориона (ПРО)

[Error404]

А вообще, сегодня слазил в проект, чего-то они там пытаются делать самостоятельно на предмет сети, но пока конечно еще конь не валялся: типа верхнего скелета основных функций. Пару лет еще надо подождать пока будет работоспособный TCP/IP. Но лично для меня это будет значить, что уже пора переходить на FUZIX. А с компилятором что-нить придумаем.

Что же касается 64к на процесс, то я думаю последнее за что надо переживать - это за количество памяти для процессов. Даже если не делать свап на энергонезависимый носитель, то любому орионщику судя по форуму - явно за счастье будет новые проводнички припаять и расширить память до, скажем, 2-4 МБ. Тем более это на статике сделать очень легко (добавить 3 мсх по 512кб). Какой восторг от любой ничем неподдержанной железки у наших софорумчан-железячников, мне это даже трудно понять, а тут будет внятная доработка под лучшую ОС Ориона - осилим общими усилиями.

[ksanf(138)]

А мне вот чего то тоже стал интересен сей проект.
Одного не понимаю, зачем эти пересылки при переключении процессов если есть непереключаемая область(0f000h-0ffffh)?
Объясните дебилу, пожалста.
Ещё в бытность пользования Орионом-128 чего то задумывался над многозадачностью...
Виделось так-система вызывает процесс, процесс пошёл, приходит прерывание (1/50-1/100 сек.), возвращается системе, система вызывает следующий..
И так по кругу..
А здесь как (в фузиксе)?
зы: Херня! Мы ещё кеды под фузиксом поднимем!
ззы: А процессы в фузиксе с какого адреса стартуют , ежели для кажного страница , с 0 или 100h ?

[Error404]

Виделось так-система вызывает процесс, процесс пошёл, приходит прерывание (1/50-1/100 сек.), возвращается системе, система вызывает следующий..
И так по кругу..
А здесь как (в фузиксе)?
зы: Херня! Мы ещё кеды под фузиксом поднимем!
ззы: А процессы в фузиксе с какого адреса стартуют , ежели для кажного страница , с 0 или 100h ?

так же и тут - коммутируемая многозадачность с прерыванием, сохранением/восстановлением и переключением контекста.
Процессы стартуют с 100h для совместимости с CP/M (точнее чтобы ничего критичного не класть в область 0..ff - эта область нужна для "имитатора" среды CP/M) - чтобы можно было бинарники CP/M запускать

[b2m]

Одного не понимаю, зачем эти пересылки при переключении процессов если есть непереключаемая область(0f000h-0ffffh)?

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

Например:
F000-FFFF непереключаемая общая область
ED00-EFFF тут область памяти задачи, даже если включено ядро
0000-EСFF тут включается либо ядро, либо одна из задач

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

[ksanf(138)]

Ну хорошо, я это понимаю. Но в Орионе же есть режим с непереключаемой областью (31 сегмент).То есть этот сегмент отображается только до страницы #7?
Нехорошо то как... В идеале-4 МБ ОЗУ, страница 60К на процесс.. А что 4 Килобайт мало для того чтобы разместить в них общую и область задач?

[b2m]

А что 4 Килобайт мало для того чтобы разместить в них общую и область задач?

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

[Advertiser]

[Sayman]

когда-нибудь, когда я разберусь с графикой для спринтера (всякие демки, игрушки и прочее) я мутану юзикса или фузикса туда)) уж с 4мя метрами озу и фаст рамой там эээхъ как можно юзикса мутануть. причём не останавливает тема старта с адреса 100h, т.к. ЦПМа там нет)))) и это будет именно ОС, а не приложение для доса/цпма, как это было ранее для других платформ)) хотя, пожалуй, на МСХ там не приложение для доса, а именно ОС. что-то я подзабыл...

[ksanf(138)]

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

Так в том то и вопрос! Неужели нельзя эту область сделать общей? Пусть и несколько побольше... С 0F000h и вверх?
ps:Стек общий ,или у каждого процесса свой?

[Error404]

Так в том то и вопрос! Неужели нельзя эту область сделать общей? Пусть и несколько побольше... С 0F000h и вверх?
ps:Стек общий ,или у каждого процесса свой?

Стек у каждого процесса вообщето свой, но он должен быть доступен из ядра чтобы работали трапы ОС (сигналы и т.п.). Т.е. система должна уметь переходить в процесс и возвращаться в ядропо стеку процесса вторым уровнем (т.е. безотносительно первого уровня - прерывания и восстановления контекста с возвращением в контекст). Значит, стек выполняемого процесса в момент выполнения трапов должен быть в непереключаемой области (либо какие-то другие меры более заумные). Если эта область большая (как в Орионе-ПРО - 4 кб), то можно задействовать в ней несколько кусков под процессы и обойтись без копирования, но в ядре тогда нужно все обращения туда делать не по абсолютному адресу, а по индексу процесса, т.е. тоже снижение скорости пускай возможно и не такое большое. Если сохранять совместимость с Орионом(128/256/512), то там в непереключаемой области - максимум 1кб и остается только вариант с копированием. Как по мне, LDIR 800 байт (400 на включение нового контекста и 400 сохранение предыдущего) на каждое переключение контекстов - это не так уж и много, для того и разгоняют процы чтобы покрывать такие накладные расходы.

- - - Добавлено - - -

это будет именно ОС, а не приложение для доса/цпма, как это было ранее для других платформ)) хотя, пожалуй, на МСХ там не приложение для доса, а именно ОС. что-то я подзабыл...

На MSX есть оба варианта (UZIX - работает само, FUZIX стартует из-под DOS). Потому что на самом деле это вопрос не "настоящестости" ОС, а теологии (т.е. веры и предпочтений). Никто не мешает мне например драйвер дисков и экрана затащить в ядро и стартовать ОС без CP/M (от которой я использую только загрузчик этих двух драйверов и сами драйверы). Только нафига? Они на асме (и на порядок более функциональные чем простетские дефолтные для UZIX/FUZIX), а ОС - на С, пишутся и отлаживаются обособленно. Пока отладка самой ОС не завершена, склеивать ужа и ежа, усложняя себе сборку и отладку - преждевременно.

Кстати, такой подход весьма распространен в бытовых и промышленных ОС, где есть первоначальный загрузчик-конфигуратор (по сути: маленькая ОС на отдельном разделе или в ПЗУ - для загрузки большой), после загрузки основной ОС не используемый. На вскидку: винда ранних версий (ранее 95), Open-VMS, AIX (и все ОС на базе Power OpenFirmware), IBM I/OS, да даже Linux OrangePI которым я сейчас играюсь - и тот грузит ядро и конфиги с FAT-раздела, а потом уже работает со вторым, линуксовым разделом где все основное лежит (FAT нужен только для загрузки ОС). Да взять тот же UEFI (т.е. большинство x86 серверов) - это что как не оно? На пару порядков посложнее чем CP/M.