Пишем свою ОС. Практика

[jerri]

Я думаю ученику Zet9, стоит объяснить для чего он создал тему "Пишем свою ОС. Практика." и когда же будет написана указанная им ОС. или хотя бы ее ядро. Ведь если пошла практика значит концепция уже есть, так? в противном случае имеет место быть миссабж

[Advertiser]

[Vadim]

А вот здесь мы всё-таки приходим к выводу, что нужна ОС. Что программа не может единолично распоряжаться всем ОЗУ, которое ей доступно и т.д. и т.п. Что программа должна исполняться в некотором окружении, что было оговорено в цпм. Позднее в мсдос. Питер Нортон в 80-х, писал, что если бы все программы бы на пц, взаимодействовали с экраном, клавиатурой и мышью через, хотя бы вызовы bios пц, то, проблем с совместимостью бы было мало. Идеально - их бы не было вообще. Но, как в случае с цпм, так и в случае с мсдос программисты обращались напрямую к "железу" компа. ОС служила лишь, как прослойка, для доступа к файлам, не более того. В рамках спектрума, в принципе, нам этого и достаточно, но проблема в том, что пресловутой "ОС" так и нет..... Есть программно-аппаратные эмуляторы существующих систем и не более того..

---------- Post added at 02:47 ---------- Previous post was at 02:40 ----------

А если идея состоит в поддержке (читай в загружаемости и исполнении) ранее созданных программ, то я свои идеи излагал ещё в 1998г. Западные товарищи предложили ещё один вариант - винтовый вариант +3 плюс к нему программно-аппаратное решение DevIDE. Т.е. в рамках нативного доступа к винту мы имеем доступ к ленточнуму софту(конечно только к тому который обращается для загрузки к процедурам ПЗУ). Но и это, согласитесь не решение! Софт трдос я вообще не знаю как классифицировать...

---------- Post added at 02:55 ---------- Previous post was at 02:47 ----------

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

В MP/M ещё был применён механизм вытеснения, то что ты описываешь может "кооперация"? А при вытеснении мы имеем хоть сколько задач. Каждой дается максимальный квант времени, после чего она прервется. Управление передастся следующей в списке задаче (по приоритету), насколько я знаю, что даже в W95, диспетчер задач вызывался не ранее чем 1/50c.

[Vovoi]

А вот здесь мы всё-таки приходим к выводу, что нужна ОС. Что программа не может единолично распоряжаться всем ОЗУ, которое ей доступно и т.д. и т.п.

Как только речь заходит об осестроении, начинают собираться всё одни и те же )))))))))))))) так, в скором времени и объединимся.

...В MP/M ещё был применён механизм вытеснения, то что ты описываешь может "кооперация"? А при вытеснении мы имеем хоть сколько задач....

Не-не, я имел в виду "наше классическое" ZX-вытеснение, например MythOS.
Чтобы тут не возникло ненужных постов с уточнением терминов, скажу, что проги пишутся и потом работают только в окне 49192-65535 (последняя 16к банка) и путем переключателя, находящегося в оперативке "ниже", эти банки меняются с частотой, которую настроит осестроитель или юзер (это мелочи, просто два байтика менять). МифОС четко предупреждает при старте, мол, ребята, на Спеке128 тока 3 проги, по числу свободных банок. Теоретически эту память можно систематизировать и поместить туда даже указатель стека, тогда особые проблемы отпадут. Кое-что из общесистемных, либо буфер обмена можно хранить "внизу". Особых заморочек нет, кроме:
* объем проги всего 16к
* трудности использования доп.памяти (хоть нижнюю забирай)
* придется отслеживать ситуевину, когда обе проги запросили дать оперативки или запросили чтение/запись диска.
* если не использовать регулируемую очередь, то вся работа - это постоянное переключение страниц.
Под кооперативной я понимал простейший, тоже можно сказать, классический для бутов движок. Диспетчер "висит" на прерываниях и поочередно запускает проги + играет музычка. Вероятно здесь придется меньше переключать страницы. Но все, в конечном счете зависит от осеписателя. Вот я думал так, а начал делать приложение и вышло хрен знает как. Но лучше обломиться, чем с пеной у рта доказывать, что, например, такая-то ось должна писаться так, а не по другому

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

[osa]

http://www.worldofspectrum.org/forum...t=32785&page=6
кто-то что-то пишет, мне правда еще не совсем понятно, мож боян ваще

[Splinter]

Надо взять свою железку, сдуть пыль, подключить винт и поэксперементировать )))...

[NovaStorm]

>для истинной многозадачности надо как минимум два окна памяти
Да и с одним окном жить можно. Например виртуализуя это окно для процесса, а при переключении задач копируя всю его память из банков в основное адресное пространство. Но разве ж это жизнь?..
>Но при этом будет ограничен размер кода на задачу.
Ну 16кб банки хватить должно на многое, и никто не мешает задаче свитчить банк самой.
>Про ограничение на размер стека даже молчу.
Тут, я думаю, драматизировать не надо, стека нужно скорее всего не так уж много - 6502 же как то жил.
>системные вызовы
Могут идти через RST или вообще напрямую в ПЗУху(которую делать всё равно придётся - не бейсик же оставлять?) а дальше, если вызов в код вне 0000-4000 танцевать с банками. Так же и с библиотеками.
>Или делать Forth-систему.
VM ,конечно, решение, но уж слишком радикальное. Без JIT будет слишком медленной, особенно при работе с памятью.

[alone]

Ну 16кб банки хватить должно на многое, и никто не мешает задаче свитчить банк самой.

Мешает то, что стек лежит в основной странице задачи. Если стек размещать в нижней памяти, то получится искусственное ограничение на число задач.

16К - это не так уж много. Писать под ОС будут, естественно, на ЯВУ. А, к примеру, одна только библиотека поддержки FAT32 на C весит 32К. С другой стороны, байт-код оптимальнее по объёму. Вспомним рекордного по размеру Snake на кодах калькулятора. Если взять программы DNA OS, то увидим ряд характерных конструкций:
LD L,(IX+9):LD H,(IX+10)
OR A:SBC HL,DE
LD E,(HL):INC HL:LD D,(HL):INC HL
LD A,(HL):INC HL:LD H,(HL):LD L,A
В байт-коде это весьма неплохо сожмётся.
Только вот ассемблерные вставки в этом случае не сделать никак.

Самостоятельно следить за размером стека программист не может. Компилятор Аласма, например, складирует туда все программные скобки начиная от INCLUDE и кончая макросами. А когда ещё и обращение к TR-DOS...

[NovaStorm]

>Мешает то, что стек лежит в основной странице задачи.
С GriV'ом давненько это обсуждали кажется, сошлись на том, что третью четверть можно тоже отдать программам как раз для подобных целей. Такие себе сверх-far call'ы получаются вроде или даже RPC =)
>Если стек размещать в нижней памяти, то получится искусственное ограничение на число задач.
Где размещать стек и как им пользоваться надо дать возможность решать конкретной программе. Потому что наверняка будут мелкие процессы, которых влезет кучка в одну банку вместе со всеми сегментами, и большие, которые будут откусывать от третьей четверти(остаток четверти после экрана наверное всё же за системой).
>Писать под ОС будут, естественно, на ЯВУ.
Не с нашим склерозом на 128к =) Хотелось бы конечно, но даже на Си компилятор породит "ряд характерных конструкций" танцев со стекфреймом. Кстати что за кусок? По идее такое восстановление регистров должно быть только в таскменеджере, при работе с процедурами сохранение их пойдёт через стек, а при выходе просто SP меняется на начало фрейма при входе?

[alone]

Индексные регистры? Это из файловой системы. Вообще так на Z80 выглядит практически любая работа со структурами/объектами. См. Vars.H, там даже макросы для этого есть: GETWORD, PUTWORD.

Писать под 128К не вижу смысла. Это музейный экспонат, который надо кисточкой протирать. А среди нового парка спектрумов больше всего АТМ2-совместимых - более 200 шт.

[bigral]

Писать под 128К не вижу смысла. Это музейный экспонат, который надо кисточкой протирать. А среди нового парка спектрумов больше всего АТМ2-совместимых - более 200 шт.

В чем состоит "музейность" 128к по сравнению с ATM2? В чем принципиальное преимущество выпустить продукт для ATM2 по сравнению с 128к?

Я бы понял если бы тут речь шла о 24bit прямоадрессуемом пространстве или скорости большей на порядок а так... в чем?