Просмотр полной версии : Эксперимент
spectrum
24.02.2005, 22:45
Админ удали тему...
какого характера операционка?
графический интерфейс (кривой или крутой)- это еще не операционка, это только надводная часть айсберга, могу сказать по своему небольшому опыту.
в качестве примера могу посоветовать сравнить win3.1 и UNIX. в первом все красиво, а внутри- пустышка. во втором случае- командная строка с мигающим курсором и неограниченные возможности.
эта тема меня тоже очень занимает, но к сожалению катастрофически нет времени чтобы чтото делать (учеба, работа, хочется другие проекты делать). хотя одна из разработок имеет прямое отношение к ОСям и разрабатывалась в рамках подобного экспериментального проекта.
Максагор
24.02.2005, 23:23
А почему бы не экспериментировать с очередным проектом, а в рамках того же эксперимента не присоединиться к тов.Breeze, чтобы помочь ему в разработке его ОС AQUA DOORS?
Графический интерфейс в примере кривой и недоделанный, но функциональный. А вообще по внешнему виду и механизму работы слегка смахивает на Windows. Это касается только граф.интерфейса, а что касается самой ОС, то посмотри на картинки прицепленные к этому сообщению. Что касается времени, то у меня его тоже нет, но творить то хочется.... :smile:
посмотрел, заценил. чувствуется системный подход :)
плиз, в следующий раз делай картинки гифами или пнгшками чтоб меньше весили.
я пока долго и нудно раздумывал на тему осей, стал пристально поглядывать в сторону unix и потратил уже почти штуку на закупку книжек по этой тематике. и если честно, думаю это самое то что нужно для спектрума.
во-первых, графический интерфейс не обязателен. в условиях довольно скромных аппаратных ресурсов это будет немаловажный фактор
во-вторых, не существует проблемы поддержки других файловых систем (в плане расширяемости) и эмуляции виртуальных дисков. (а также поддержки любого железа и прочего, за подробностями- к источникам о файловой системе юниха)
в-третьих, данная система изначально разрабатывалась для слабых компьютеров, несмотря на то, что написана на языке довольно высокого уровня (Си), показала довольно хорошие результаты.
зы. если интересно- стучись в аську
Согласен насчёт Юникса. Есть резон попробовать если время будет. У меня где то валяется ядро minixa для проца Z80. Вот только один ньюанс - адресное пространство 64 Кб разбивается на 32 Кб ядро и 32Кб программа. И это как пишет его автор минимум, чтоб хоть, что то работало. Хотелось бы сказать, что есть "псевдо многозадачность" со свопингом на HDD. Есть вроде несколько утилит, но всё смотриться мрачновато как-то. Я думаю, что если перетащить или откомпилировать с С асм, то он не поместиться в эти 32 КБ. А что касается экрана, то его в это конфигурации просто нет. :sleep:
Что касается "эксперемента" то как видно из картинок была сделана попытка стереть грани в некоторых понятиях при написании самой ОС и её компонентов. А сам граф. интерфейс сделать универсальным и гибким (смотри краткое приложение).
minix?!?!?!?!?! это не тот ли самый миникс, с которого торвальдс начинал? :)
если переделывать вручную, то думаю и в 16 поместится. потому как там компилятор юзает передачу параметров через стек, что с точки зрения клиента (то бишь вызываемой процедуры) просто замечательно, но с точки зрения вызывающего просто хреново (и это мягко сказано).
концепции графического интерфейса были разработаны и стандартизированы еще черт-те когда, зачем изобретать велосипед? хотя, с другой стороны, нельзя просто брать и бездумно сдирать все подряд, нужно перерабатывать все в зависимости от обстоятельств.
заходи ко мне в аську, а то форум тут чат уже напоминает :)
minix?!?!?!?!?! это не тот ли самый миникс, с которого торвальдс начинал? :)
Имеется ввиду UZI (unix z80 implementation). Рекомендую смотреть в сторону UZIX -- реализация UZI на MSX. uzix.sf.net, если не ошибаюсь.
Имеется ввиду UZI (unix z80 implementation). Рекомендую смотреть в сторону UZIX -- реализация UZI на MSX. uzix.sf.net, если не ошибаюсь.
посмотрел на сайт. впечатлился по самое не балуйся :)
вопрос- на MSX есть текстовый режим? или все как на спеке?
Выдержка из http://www.work.de/nocash/portar.htm#videomodesscreens:
M1 M2 M3 M4 M5 Screen format
1 0 0 0 0 Text 40x24 (BASIC SCREEN 0)
0 0 0 0 0 Half text 32x24 (BASIC SCREEN 1)
0 0 1 0 0 Hi resolution 256x192 (BASIC SCREEN 2)
0 1 0 0 0 Multicolour 4x4pix blocks (BASIC SCREEN 3)
----Below MSX2 only----
0 0 0 1 0 Screen2 with 8 Sprites/Line (BASIC SCREEN 4)
0 0 1 1 0 256*212, 16 colours/pixel (BASIC SCREEN 5)
0 0 0 0 1 512*212, 4 colours/pixel (BASIC SCREEN 6)
0 0 1 0 1 512*212, 16 colours/pixel (BASIC SCREEN 7)
0 0 1 1 1 256*212, 256 colours/pixel (BASIC SCREEN 8)
1 0 0 1 0 Text 80x24 (BASIC SCREEN 0, WIDTH 80)
посмотрел на сайт. впечатлился по самое не балуйся :)
вопрос- на MSX есть текстовый режим? или все как на спеке?
Чтобы остудить пыл спектрумистов в области UZIX, приведу цитату уважаемого dhau из соседнего топика:
Насчет Uzix - да - все продумано хорошо, и реально работает, сам пробовал, *НО*, !!!сюрприз-сюрприз!!!, все тормозит просто ужастно. Более ли менее идет только на моей MSX TurboR GT, но в этой машине стоит R800 - недо-рисковский аппаратный эмулятор Z80, который любую Z80 комманду выполняет за один такт и работает на частоте 7MHz! Кто-то из MSX-еров говорил что грубо говоря это примерно как обычный Z80, но разогнанный на 40MHz. Как только все спектрумы обзаведутся Z80 @ 40MHz, можно смело переходить на Uzix
а кто сказал что необходимо брать этот юзикс и переносить вот так сразу? для начала можно поучиться что там и как сделали. с другой стороны можно самостоятельно попробовать себя в роли компилятора и писать код по исходу на С. это даст прирост скорости в 2 и более раза. плюс другие изменения/дополнения и может чтото из этого выйдет
а кто сказал что необходимо брать этот юзикс и переносить вот так сразу? для начала можно поучиться что там и как сделали. с другой стороны можно самостоятельно попробовать себя в роли компилятора и писать код по исходу на С. это даст прирост скорости в 2 и более раза. плюс другие изменения/дополнения и может чтото из этого выйдет
Человек в роли оптимизирующего компилятора может побороться лишь со старыми компиляторами 80-х годов - большого прироста скорости это не даст, а вот времени убъет немерянно :wink:
Человек в роли оптимизирующего компилятора может побороться лишь со старыми компиляторами 80-х годов - большого прироста скорости это не даст, а вот времени убъет немерянно :wink:
Ну не скажи. Ни один компилятор сей не догадается на з80 юзать стек как попало (даже скорее как обычно =). Для всяких "недо"процессоров типа з80, мцс51, пик, авр вряд ли хоть один компилятор сравнится по извращенским оптимизациям с человеком =). А вот для таких монстров, как например ppc - компайлеры могут уже и порулить человека. Как-то я видел доку от мутороллы - что надо менять в компайлерах, чтоб код оптимизировали не под g3, а под g4. Там столько разных заморочек, незнание которых приводит к СОВСЕМ не оптимизированному коду.
Ну не скажи. Ни один компилятор сей не догадается на з80 юзать стек как попало (даже скорее как обычно =). Для всяких "недо"процессоров типа з80, мцс51, пик, авр вряд ли хоть один компилятор сравнится по извращенским оптимизациям с человеком =). А вот для таких монстров, как например ppc - компайлеры могут уже и порулить человека. Как-то я видел доку от мутороллы - что надо менять в компайлерах, чтоб код оптимизировали не под g3, а под g4. Там столько разных заморочек, незнание которых приводит к СОВСЕМ не оптимизированному коду.
Даже для z80 есть компиляторы, которые аргументы функций не через стек передают (точнее не все через стек), а по мере возможности через регистры. Хотя может критические участки кода и можно человеку писать, например внутренности циклов или разворачивать циклы работы с экраном и т.д. - где выигрышь в одном проходе не единицы тактов может дать существенный прирост в цикле.
Для всяких "недо"процессоров типа з80, мцс51, пик, авр вряд ли хоть один компилятор сравнится по извращенским оптимизациям с человеком =)
Никто не спорит. Но к времени когда ты докончишь оптимизировать ls и chmod, миром уже будут управлять органические роботы-киборги, а земля будет эксклюзивной курортной зоной для туристов из альдебарана :)
Мое мнение - операционки надо писать на С и только на С. Разумется, после отладки - критичные места надо оптимизить ручками на асме.
Мнение основано на том, что в свое время я разрабатывал специфичные реал-таймовые микро-операционки для AVR, сейчас реал-таймовую разрабатываю операционку для ядер ARM. Уже работает уровень драйверов. Сейчас вожусь с менеджером задач и файловым уровнем. Еще пришлось работать с операцонкой для 196го писанной на асме. Кошмар!
В общем асм - это не для больших проектов. Однозначно. Лично мне по душе такой подход:
- Разрабатывается структура системы (я за основу принял UNIX-идеологию).
- Пишется на С вся ОС в общем виде.(особенно удобно на С описание структур, без которых ни одна нормальная ОС не обходится).
- Все отлаживается (особенно попистая отладка - это менеджеры памяти и задач).
- Выделяются узкие по производительности места.
- Переписываются узкие места (возможно на асме), оптимально.
Времени экономится - масса.
А с нуля раскорячивать идеи в ассемблер - никакого времени не хватит. Убъешь массу времени на "супер-оптимальный" кодинг, а потом окажется, что вся структура системы или части системы - плохо продумана и надо все переделывать.
Это мое ИМХО.
Мое мнение - операционки надо писать на С и только на С. Разумется, после отладки - критичные места надо оптимизить ручками на асме.
Мнение основано на том, что в свое время я разрабатывал специфичные реал-таймовые микро-операционки для AVR, сейчас реал-таймовую разрабатываю операционку для ядер ARM. Уже работает уровень драйверов. Сейчас вожусь с менеджером задач и файловым уровнем. Еще пришлось работать с операцонкой для 196го писанной на асме. Кошмар!
В общем асм - это не для больших проектов. Однозначно. Лично мне по душе такой подход:
- Разрабатывается структура системы (я за основу принял UNIX-идеологию).
- Пишется на С вся ОС в общем виде.(особенно удобно на С описание структур, без которых ни одна нормальная ОС не обходится).
- Все отлаживается (особенно попистая отладка - это менеджеры памяти и задач).
- Выделяются узкие по производительности места.
- Переписываются узкие места (возможно на асме), оптимально.
Времени экономится - масса.
А с нуля раскорячивать идеи в ассемблер - никакого времени не хватит. Убъешь массу времени на "супер-оптимальный" кодинг, а потом окажется, что вся структура системы или части системы - плохо продумана и надо все переделывать.
Это мое ИМХО.
Целиком поддерживаю коллегу.
Осталось только оптимизирующий C компилятор где нить нарыть :)
Alchemist
14.03.2005, 09:51
Целиком поддерживаю коллегу.
Осталось только оптимизирующий C компилятор где нить нарыть :)
Очень интересно было бы узнать чего вам не хватило в SDCC. (это серьезный вопрос, без иронии :))
Целиком поддерживаю коллегу.
Осталось только оптимизирующий C компилятор где нить нарыть :)
Я во флейме писал - есть свободный кроскомпилер. Правила оптимизации можешь писать к нему сам, если стандартных не хватает. Оптимизирует на уровне ассемблерного исходника. Для обкатки идей - более чем достаточно.
Суть эксперимента такова - написать ОС для компьютера семейства ZX Spectrum и эго клонов. … Есть работающий пример графического интерфеса …
Мое мнение - операционки надо писать на С и только на С. … Это мое ИМХО.
Какие графические интерфейсы, какой C? Вы что и зачем писать хотите, сами понимаете? Операционка ради операционки – это, конечно, хороший способ набраться опыта в работе с текстовым редактором, но разве она не должна решать существующие проблемы? Кто-то в этом форуме уже предлагал добавить в ПЗУ несколько RST для нормальной работы с памятью и файловой системой, вот уж что действительно было бы полезно. А какая польза будет от новой графической запускалки?
Никто не спорит. Но к времени когда ты докончишь оптимизировать ls и chmod, миром уже будут управлять органические роботы-киборги, а земля будет эксклюзивной курортной зоной для туристов из альдебарана :)
Эээ - по поводу оптимизации лс и чмода - это к Робусу =)))
Мы с ним раньше уже общались, все вопросы к нему....
PS: Кидаю ещё "картинки" для размышлений.... :smile:
Боюсь с начальным опытом MS Visio и схемами плана USER->KEYBOARD->MONITOR никуда не уедешь....
Хорошая ось - это очень непросто... Тот же IS-DOS огого написать...
скинуться по 100$ и заказать у майкрософт на заказ ;)
или у Genesi или их там омижниковых морфосников...
Какие графические интерфейсы, какой C? Вы что и зачем писать хотите, сами понимаете? Операционка ради операционки – это, конечно, хороший способ набраться опыта в работе с текстовым редактором, но разве она не должна решать существующие проблемы? Кто-то в этом форуме уже предлагал добавить в ПЗУ несколько RST для нормальной работы с памятью и файловой системой, вот уж что действительно было бы полезно. А какая польза будет от новой графической запускалки?
Я уже писал, почему С. Потому что пока ты на асме отладишь все эти RST дополнительные - у тебя столько времени уйдет - что все надоест. А "нормальная работа с памятью и файловой системой" вообщето и является одними из основных функций почти любой ОС. Что значит "добавить несколько RST" ? Одного достаточно. Но дело не в RST. Дело в том, что ОС обеспечиват прежде всего работу с разнородным оборудованием, устраняя проблемы несовместимости. Грубо говоря - программа пользователя обратилась к ОС с запросом - "дай мне 2к памяти", ОС должна вернуть адрес выделенного блока в какойто форме или код ошибки, если памяти нет. А уж на какие там порты подключено переключение страниц памяти и в какие окна и как все это делается - это сугубо интимные проблемы дрпайвера памяти, установленного на данной ОС в данной машине. И они никак не должны касаться программы пользователя.
Или работа с файлами - на кой программе юзера знать - на какой физической файловой системе лежит файл с данными игрушки ? Пусть эти проблемы мучают ОС. А программа пользователя должна только уметь сказать ос "myfileid=open("/games/mysupergame.dat",O_RDONLY):read(myfileid, &buffer, size);close(myfileid); - все !!! Остальное - интимные проблемы драйверов файловой системы и драйверов устройств !
Все нормальные компы так работают....
чем вам IS-DOS не угодил? его б лучше дорулить...
Привет всем снова!
Продолжаем эксперимент. Вот привожу детальную структуру окна привидённого ранее в "Структура оконного интерфейса.jpg". В будущем выложу на обозрение текущую версию документа эксперементального проекта в котором ведётся сама разработка.
Давайте присоединяйтесь экспериментаторы !!!
:smile:
Товарищ экспериментатор ! Может я несколько самонадеян, НО !!!! ОС - это не ГРАФ ИНТЕРФЕЙС. Это НЕ КНОПОЧКИ !!!! ЧТО ЗА ВИНДОВОЗНО-МИКРОСОФТНЫЙ ПОДХОД ?!
ОС - это прежде всего работа с оборудованием.
Подумай вот над чем:
- Как будет реализована работа с памятью. Алгоритм выделения, освоюождения памяти. То есть менеджер памяти.
- Как будет выглядеть единый интерфейс драйверов устройств.
- Как будут отображаться устройства на виртуальную файловую систему.
- Как будут подключаться файловые системы устройств к виртуальной файловой системе.
- Как буде реализована файловая система и взаимодействие с ней.
- Как будет работать менеджер задач. (Тип многозадачности, распределение времени)
И только потом, когда ты нарисуешь и обкатаешь эти схемы - сможешь подумать "кнопочках, рюшечках и прочей байде". Событийный графинтерфейс написать - несложно.
чем вам IS-DOS не угодил? его б лучше дорулить...
Всем. По сути это не ОС, а только ДОС. На кой нам однозадачная ОС ? Это неправильно.
Подумай вот над чем:
- Как будет реализована работа с памятью. Алгоритм выделения, освоюождения памяти. То есть менеджер памяти.
- Как будет выглядеть единый интерфейс драйверов устройств.
- Как будут отображаться устройства на виртуальную файловую систему.
- Как будут подключаться файловые системы устройств к виртуальной файловой системе.
- Как буде реализована файловая система и взаимодействие с ней.
- Как будет работать менеджер задач. (Тип многозадачности, распределение времени)
Странно, что ты свалил всё в кучу - ФС и задачи с памятью.
Надо сильно думать вот над чем
1. механизмы многозадачности.
2. память.
3. 'событийные' механизмы: сигналы, мессаги, семафоры.
Все драйвера далее могут взаимодействовать с задачами на основе этих механизмов. ФС/etc же вообще тут не причём - её можно добавить как отдельную либу, у которой уже свои механизмы работы (основывающиеся на событийных и тасковых механизмах) с драйверами ФСов и драйверами накопителей.
По крайней мере так ось сделана на амиге - всем осописателям кстати рекомендуется ознакомиться. =)
И только потом, когда ты нарисуешь и обкатаешь эти схемы - сможешь подумать "кнопочках, рюшечках и прочей байде". Событийный графинтерфейс написать - несложно.
Ну да, всё это сделать-то несложно, но применительно к спеку возникают проблемы нехватки памяти, быстродействия, етц. И возможно не так уж неправы были исдосники, что сделали монолитную систему-командер.
Странно, что ты свалил всё в кучу - ФС и задачи с памятью.
Все драйвера далее могут взаимодействовать с задачами на основе этих механизмов. ФС/etc же вообще тут не причём - её можно добавить как отдельную либу, у которой уже свои механизмы работы (основывающиеся на событийных и тасковых механизмах) с драйверами ФСов и драйверами накопителей.
В Unix-системах драйвера взаимодействуют с программой пользователя как файлы устройств. В этом отношении мне Юниксы нравятся своей простотой и логичностью. Возможно мы имеем ввиду разные файловые системы ? Есть файловые системы хранения файлов на физ. уровне (FAT, Ext2 и тд), а я говорил о виртуальной файловой системе, которая объединяет все файловые системы в одно дерево. В этом дереве - и фйлы данных и файлы устройств и файлы-ссылки и т.д. и т.п.
По крайней мере так ось сделана на амиге - всем осописателям кстати рекомендуется ознакомиться. =)
Не спорю. А так же всем осописателям рекомендуется изучить книги "Операционные системы" Т.Б.Большаков - Д.В.Иртегов и "Сетевые операционные системы" Н. А. Олифер, В. Г. Олифер... В общем и обзорно и с реальными примерами рассмотрены типы ОС, типы менеджеров памяти, файловых систем, методов взаимодействия с драйверами и т.п.
Ну да, всё это сделать-то несложно, но применительно к спеку возникают проблемы нехватки памяти, быстродействия, етц. И возможно не так уж неправы были исдосники, что сделали монолитную систему-командер.
Они просто копировали Нортон и идеологию ДОС (заметь - не ОС, а ДОС!), распостраненных на тот момент. Привязывать ядро ОС к пользовательскому интерфейсу - глупость несусветная ! Причем выигрыша в быстродействии никакого не дает. Какая разница - загружена у тебя программа, выводящая на экран окошки как внешняя или вкомпилена в ядро ОС ? Для процессора - никакой. Он и то и это будет выполнять с примерно равной скоростью. А вот с памятью ситуевина как раз прямо обратная. Вкомпиленный в ядро интерфейс пользователя - это ПОПА !!! В том смысле - что он жрет память не зависимо от того нужен он реально пользователю или нет. А если он подгружаемый - то все более приятно. Есть память - можно подгружать оконно-мышинный супероконный. Нет памяти - подгрузил маленкий интерпретатор комстроки - или нечто Нортон-подобное...
принял бы участие в написании unix подобной оси/ядра для спека. опыт в языке Си - 9 лет. только давайте действительно сначала определимся с многозадачностью и системой меж процессовых комуникаций. остальное, в принципе, уже пройденный путь. естественно файл система будет модульной. но нам, для начала, микро ядро надо продумать.
может сделать отдельную ветку? с идеей автора данной темы это довольно большая разница. (я вообще против графического интерфейса в составе оси как таковой. если программе понадобится графика, пускай сама делает. в крайнем случае напишем либу какую-нибудь).
целью считаю размещение самого ядра и минимума драйверов в 16кб странице (вместо пзу).
CityAceE
15.03.2005, 07:58
может сделать отдельную ветку? с идеей автора данной темы это довольно большая разница. (я вообще против графического интерфейса в составе оси как таковой. если программе понадобится графика, пускай сама делает. в крайнем случае напишем либу какую-нибудь).
PalmOS, например, сразу изначально базировалась на GUI, хотя на самом первом Палме памяти было как у современного Спектрума, процессор стоял слабенький (сопоставимый по мегагерцам со Спектрумовским) и однобитный экран 160х160. Я помнится даже в REAL.SPECCY кидал скриншоты с палмовских электронных таблиц в формате SCR 6912... Так что может быть не стоит вот так сразу откидывать идею с GUI? Хотя, вероятно, именно для Спектрума GUI вовсе и не нужен...
целью считаю размещение самого ядра и минимума драйверов в 16кб странице (вместо пзу).
Примерно об этом я и писал вот здесь: http://zx.pk.ru/showthread.php?t=168
В Unix-системах драйвера взаимодействуют с программой пользователя как файлы устройств. В этом отношении мне Юниксы нравятся своей простотой и логичностью. Возможно мы имеем ввиду разные файловые системы ? Есть файловые системы хранения файлов на физ. уровне (FAT, Ext2 и тд), а я говорил о виртуальной файловой системе, которая объединяет все файловые системы в одно дерево. В этом дереве - и фйлы данных и файлы устройств и файлы-ссылки и т.д. и т.п.
Это как раз идеология унихов - всякие там / и все девайсы как файлы etc. В результате имеем монструозное ядро. Да и к тому же унихам ММУ нужен (ну есть конечно uClinux, но думаешь он спасёт на Z80?).
Они просто копировали Нортон и идеологию ДОС (заметь - не ОС, а ДОС!), распостраненных на тот момент. Привязывать ядро ОС к пользовательскому интерфейсу - глупость несусветная ! Причем выигрыша в быстродействии никакого не дает.
Ну да - глупость, когда например в винде таски обменивааться месагами могут только через окошки =) Я говорю, что может быть это и глупость, но таки позволила хоть куда-то уехать - мне навскидку трудно прикинуть, с какой скоростью будет работать честная многозадачная ос на спеке и сколько будет жрать ОЗУ, етц.
. Так что может быть не стоит вот так сразу откидывать идею с GUI? Хотя, вероятно, именно для Спектрума GUI вовсе и не нужен...
Примерно об этом я и писал вот здесь: http://zx.pk.ru/showthread.php?t=168
От ГУЯ отказываться не надо. Просто ГУЙ - это отдельная довеска, которая может быть в ОС, а может ее и не быть. Короче уровень ОС - это драйвер экрана, мыши и клавиатуры. А уровень ГУИ - это просто программа или набор библиотек для рисования окошек, кнопок и так далее. Нужен пользовательской программе ГУЙ - подгружаем этот набор библиотек и используем, не нуже - не надо и память занимать.
В общем ОС - это ядро. А ГУЙ - это пользовательская программа. ИМХО так правильнее.
Это как раз идеология унихов - всякие там / и все девайсы как файлы etc. В результате имеем монструозное ядро. Да и к тому же унихам ММУ нужен (ну есть конечно uClinux, но думаешь он спасёт на Z80?).
ММУ - не обязателен, хотя и желателен. Что касается "монстроидности" ядра - все зависит от набора его функций. Если взять минимальный набор - то ядро совсем компактненькое получается. Реально - у меня для ARMа реализация менеджера памяти (кстати - тоже без ММУ) и стандартного интерфейса драйверов - около 5 Кбайт занимает. И это учитывая, что длина команды ARMa - 16 бит всегда (в режиме THUMB, который я использую). Для Z80 - программа явно короче будет.
Ну да - глупость, когда например в винде таски обменивааться месагами могут только через окошки =) Я говорю, что может быть это и глупость, но таки позволила хоть куда-то уехать - мне навскидку трудно прикинуть, с какой скоростью будет работать честная многозадачная ос на спеке и сколько будет жрать ОЗУ, етц.
Основная память и ресурсы - жруться не ядром ОС, а программами пользователя и подгружаемыми драйверами. Отсюда вывод - чем больше у тебя устройств приткнуто к спеку - тем больше памяти драйвера будут занимать. Сколько временннЫх ресурсов ОС жрать будет - это вообще отдельный вопрос. Тут все зависит от того какой тип многозадачности и какими приоритетами обладают задачи. Главное - следует помнить, что большинство функций ОС запускаются не "сами по себе", а только в результате обращения к ОС программы пользователя.
Особенно важно распределить приоритеты задач. Я в свое время писал для AT90S8535 программку для управления тех процессом. У меня была жесткая привязка к реальному времени следующих вещей - 4 7сегментника, три канала АЦП - измерения напряжения трежфазной сети. Молодой был, глупый. Пока приоритеты правильно между задачами не распределил - индикатор маргал неравномерно и ьбезбожно, сеть мерялась ужасно. Думал быстродействия не хватает, а оказалось - приоитеты задач - это не пустой звук. Переделал - все как часы заработало.
С точки зрения программ пользователя - ресурсопрожорливость вообще не оценить - откуда я могу знать какой очередной изврат "крутых хацкеров" пожелают под ОС запустить ? Скорее всего придется делать режим "монопольное использование процессора" для нормального запуска программ, где все привязано к тактам проца.
налопался шоколада, почитал данный тред, полистал рульную книжку "UNIX изнутри" и пробило на высказывание некоторых мыслёв народу. от народа требуется высказывание мнений по каждому пункту. желательно с аргументацией и разумными доводами
1) многозадачность нужна. как показывает практика, большую часть времени процессы проводят в ожидании ввода/вывода, т.е. ожидания чтения с носителей (в случае спека не совсем актуально- чтением занимается процессор) или ввода пользователем чего-нибудь. имеет смысл использовать свободное время с пользой.
2) прошивка ядра ОС вместо ПЗУ (как вариант- кеш), потому что основной памяти и так мало
3) делать ядро из модулей (типа линуха). в начальной поставке идет универсальное ядро, поддерживающее всевозможное железо или минимальную конфигурацию, работающую где угодно. юзер на целевой машине конфигурирует сборщик, определяя нужные ему возможности и выкидывая ненужные. ядро пересобирается. все довольны.
4) графический пользовательский интерфейс (не путать с Hacker User Interface :) ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. отсюда вытекает невозможность привязки событий и проч. к оконной структуры (как в винде). имхо, следует обратить свой взор к *nix системам (что было сделано в предыдущих постах)
5) если углубляться дальше, то нужно затронуть тему диспетчеризации процессов. с целью уточнения, проконсультировался с преподом у себя в универе. согласно выдвинутым требованиям, он предложил схему с двумя классами процессов- реального времени и разделения времени. процессы реального времени выполняются каждый квант диспетчеризации по цепочке. это могут быть процессы времени, обслуживания ау и проч. остальные процессы распределяются согласно своим приоритетам в оставшееся свободное время.
6) менеджмент памяти. вот тут возникают довольно большие проблемы. в частности изза страничной организации памяти. нижнюю память можно отдать на откуп системы для хранения структур, таблиц и проч. а в верхних страницах хранить процессы. проблема в диспетчере, который должен обеспечивать контроль всей доступной верхней памяти (пусть с точностью до блока в 256 байт)- сложности в ее переменном количестве и возможности разделения одной области памяти несколькими процессами. в принципе эта проблема почти решена, дело за реализацией чтобы проверить идею.
фух. выдохся %)
хочется услышать мнение народа
(2spectrum: я же тебе говорил, что надо делать базу а не оболочку ;)
оболочка без содержания- воздушный шарик, который можно помять)
1) многозадачность нужна. как показывает практика, большую часть времени процессы проводят в ожидании ввода/вывода, т.е. ожидания чтения с носителей (в случае спека не совсем актуально- чтением занимается процессор) или ввода пользователем чего-нибудь. имеет смысл использовать свободное время с пользой.
Согласен - простейший вариант реализации - повешать на NMI таймер, который будет слать прерывания скажем каждую миллисекунду. Пришло прерывание - опросил все устройства (через их драйвера) - есть ли что читать-писать, выполнил нужное. Разумеется это не оптимально. По идее каждое устройство должно уметь само послать прерывание, чтобы драйвер его обработал. Но зато вариант с таймером на NMI - самый простой.
2) прошивка ядра ОС вместо ПЗУ (как вариант- кеш), потому что основной памяти и так мало
Однозначно - кэш. Тогда ОС можно апгрейдить и изменять без перепрошивки ПЗУ. Огромный плюс.
3) делать ядро из модулей (типа линуха). в начальной поставке идет универсальное ядро, поддерживающее всевозможное железо или минимальную конфигурацию, работающую где угодно. юзер на целевой машине конфигурирует сборщик, определяя нужные ему возможности и выкидывая ненужные. ядро пересобирается. все довольны.
Ядро и драйвера к нему должно поставляться либо в исходных текстах (для крутых кульхацкеров) либо просто под конкретную конфигурацию, которая в общем определяется набором встроенных- и подгружаемых драйверов. Скажем будет версия "SuperpuperOS v,Pentagon-1024" или версия "SuperpuperOS v,АТМ-7.10". Пользователь ее скачивает, устанавливает и работает - без гребли с компиляцией.
4) графический пользовательский интерфейс (не путать с Hacker User Interface :) ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. отсюда вытекает невозможность привязки событий и проч. к оконной структуры (как в винде). имхо, следует обратить свой взор к *nix системам (что было сделано в предыдущих постах)
Привязка событий к окошкам - это извратик. Есть понятие "процесс". Есть понятие "сигнал". Несколько "процессов" могут обмениваться "сигналами" межу собой. А рисует процесс окошко или передает данные по модему - не принципиально.
5) если углубляться дальше, то нужно затронуть тему диспетчеризации процессов. с целью уточнения, проконсультировался с преподом у себя в универе. согласно выдвинутым требованиям, он предложил схему с двумя классами процессов- реального времени и разделения времени. процессы реального времени выполняются каждый квант диспетчеризации по цепочке. это могут быть процессы времени, обслуживания ау и проч. остальные процессы распределяются согласно своим приоритетам в оставшееся свободное время.
Согласен. К процессам реального времени - относятся драйвера и ядро. К остальным - пользовательские (за исключением некоторых - скажем старых программ, которые требуют монопольного выделения процессорного времени).
6) менеджмент памяти. вот тут возникают довольно большие проблемы. в частности изза страничной организации памяти. нижнюю память можно отдать на откуп системы для хранения структур, таблиц и проч. а в верхних страницах хранить процессы. проблема в диспетчере, который должен обеспечивать контроль всей доступной верхней памяти (пусть с точностью до блока в 256 байт)- сложности в ее переменном количестве и возможности разделения одной области памяти несколькими процессами. в принципе эта проблема почти решена, дело за реализацией чтобы проверить идею.
Не вижу больших проблем. Надо хранить таблицу (точнее список) страниц по 16К и свободного места на них. При программировании вся программа разбивается на сегменты длиной не более 16К, что вполне достаточно для весма нехилого куска кода. В начале кажого сегмента программы имеется таблица адресов точек входа. Никакой сегмент программы не может обращаться к другому сегменту иначе, как через эту таблицу. Данными процессы обмениваются через посылку сигналов друг другу, через файлы и через область разделяемых данных в памяти.
Распределение памяти мне видется примерно таким:
------------------------- #FFFF
Пользовательские процессы.
------------------------- #C000
Область разделяемых данных
------------------------- #8000
Системные таблицы+подгружаемые драйвера
------------------------- #4000
Ядро+встроенные драйвера.
------------------------- #0000
Такая схема будет работать минимум на 128к, если есть возможность повешать на NMI таймер (хотя можно и через INT - но повиснуть может). Главное, чтобы имелся порт для включения теневого ОЗУ с адреса #0000.
в общем я полностью согласен, именно так себе и представляю такую ОСь.
только одно дополнение к таблице памяти - возможное резервирование экрана (пускай даже Ч/Б) максимум 6912 байт.
CityAceE
16.03.2005, 07:58
Теоретиков, вижу, много. А где же практики??? :)
давайте уже составлять ТЗ, я повторяю, готов потратить часть своего свободного времени на написание C кода.
Мдя :cool: Идей вижу много, идей хороших и неочень, но вот в чем вопрос, а чего всё это грузить? с дискет ? не кажется ли вам, что стоит начать написание оси с начального старта компьютера, с boot-strap'а ?
короче нужна FS! будет FS - будет над чем работать! (я как раз и работаю над этим вопросом :rolleyes: )
кста по поводу раздела памяти #4000 - #8000 - таблицы и подгружаемыые драйвера ? по поводу таблиц ничего против не имею, а вот надчет дров, все видимо дружно заб(и/ы)ли что это область slow memory !!! и всё это будет жутко торрмозить! единственное для чего эта область пригодна это для хранения данных!!! :sleep:
breeze, не тормози. написание оси да и вообще всего что угодно начинается не с bootstrap'а, а с толкового ТЗ. с чего грузить, с чего грузить. это вообще вопрос десятый.
breeze, не тормози. написание оси да и вообще всего что угодно начинается не с bootstrap'а, а с толкового ТЗ. с чего грузить, с чего грузить. это вообще вопрос десятый.
Золотые слова. Поэтому скорей всего никогда Оси не появится, ибо во первых делают в одиночку, а во вторых не знают совершенно что делают :smile: .
Кстати не раз уже об этом писал!
ММУ - не обязателен, хотя и желателен. Что касается "монстроидности" ядра - все зависит от набора его функций. Если взять минимальный набор - то ядро совсем компактненькое получается. Реально - у меня для ARMа реализация менеджера памяти (кстати - тоже без ММУ) и стандартного интерфейса драйверов - около 5 Кбайт занимает. И это учитывая, что длина команды ARMa - 16 бит всегда (в режиме THUMB, который я использую). Для Z80 - программа явно короче будет.
Ну вот - 5 кб, в то время как сколько там упакованное ядро линуха обычного занимает? Пример, как не надо делать на спектруме =)
Основная память и ресурсы - жруться не ядром ОС, а программами пользователя и подгружаемыми драйверами. Отсюда вывод - чем больше у тебя устройств приткнуто к спеку - тем больше памяти драйвера будут занимать. Сколько временннЫх ресурсов ОС жрать будет - это вообще отдельный вопрос. Тут все зависит от того какой тип многозадачности и какими приоритетами обладают задачи. Главное - следует помнить, что большинство функций ОС запускаются не "сами по себе", а только в результате обращения к ОС программы пользователя.
Ну нифига себе не ось - кто-то тут предложил все 32 кб (ил 48?) младших адресов угрохать на ось! =)))
Однако ось будет-таки жрать - хотя бы на свиче контекстов и прочей многозадачной чепухе - это то, от чего не избавиться и что есть всегда.
Особенно важно распределить приоритеты задач. Я в свое время писал для AT90S8535 программку для управления тех процессом. У меня была жесткая привязка к реальному времени следующих вещей - 4 7сегментника, три канала АЦП - измерения напряжения трежфазной сети. Молодой был, глупый. Пока приоритеты правильно между задачами не распределил - индикатор маргал неравномерно и ьбезбожно, сеть мерялась ужасно. Думал быстродействия не хватает, а оказалось - приоитеты задач - это не пустой звук. Переделал - все как часы заработало.
Не вижу проблем. Сделать преемптивную (вытесняющую) многозадачность - есть 128 (например) приоритетов, на каждом - своя очередь задач. Если на высоком приоритете нету жаждущих процессора задач - отдавать время низшим приоритетам. Если задача проснулась, поделала чего-то и затихла до истечения её кванта (20ms), - опять же, остаток низшим приоритетам. Для особо важных дел задачи могут вешать свои сервера на прерывание.
С точки зрения программ пользователя - ресурсопрожорливость вообще не оценить - откуда я могу знать какой очередной изврат "крутых хацкеров" пожелают под ОС запустить ? Скорее всего придется делать режим "монопольное использование процессора" для нормального запуска программ, где все привязано к тактам проца.
Ничего делать не придётся. Достаточно DI, а далее вообще вытворять всё, что угодно. =)
1)(в случае спека не совсем актуально- чтением занимается процессор) или ввода пользователем чего-нибудь. имеет смысл использовать свободное время с пользой.
Это к вопросу о DMA USC. =)
3) делать ядро из модулей (типа линуха). в начальной поставке идет универсальное ядро, поддерживающее всевозможное железо или минимальную конфигурацию, работающую где угодно. юзер на целевой машине конфигурирует сборщик, определяя нужные ему возможности и выкидывая ненужные. ядро пересобирается. все довольны.
Или из библиотек - как на амиге. Кстати - у меня собственно есть подробные описания амигаоса в виде тамошних *.guide - могу выложить - и попытаться даже в хтмл сконвертить - стоит?
5) если углубляться дальше, то нужно затронуть тему диспетчеризации процессов. с целью уточнения, проконсультировался с преподом у себя в универе. согласно выдвинутым требованиям, он предложил схему с двумя классами процессов- реального времени и разделения времени. процессы реального времени выполняются каждый квант диспетчеризации по цепочке. это могут быть процессы времени, обслуживания ау и проч. остальные процессы распределяются согласно своим приоритетам в оставшееся свободное время.
См. моё предложение в предыдущем посте - комментарии?
6) менеджмент памяти. вот тут возникают довольно большие проблемы. в частности изза страничной организации памяти. нижнюю память можно отдать на откуп системы для хранения структур, таблиц и проч. а в верхних страницах хранить процессы. проблема в диспетчере, который должен обеспечивать контроль всей доступной верхней памяти (пусть с точностью до блока в 256 байт)- сложности в ее переменном количестве и возможности разделения одной области памяти несколькими процессами. в принципе эта проблема почти решена, дело за реализацией чтобы проверить идею.
Тут имхо как раз основные проблемы
Мелкие проги будут себя хорошо чувствовать в страничках (по 16кб), а крупные ? Например, уровня аласма - полностью без использования памяти #0000-#BFFF ? Даже написать такое - мазохизм будет... И вообще, как ты себе представляешь работу с выделенной памятью? Например, хочешь ты выделить память под хранение переменных к-л проги, вот дали тебе кусок, скажем, 256 байт - а дальше что - постоянные ld a,(ix+n) или ld h,'addr, ld l,переменная ld a,(hl)? А если эта память в другой странице - не в той, где код работает?
Мдя :cool: Идей вижу много, идей хороших и неочень, но вот в чем вопрос, а чего всё это грузить? с дискет ? не кажется ли вам, что стоит начать написание оси с начального старта компьютера, с boot-strap'а ?
НЕТ! Не кажется. Это вообще то, что в самом конце делается.
короче нужна FS! будет FS - будет над чем работать! (я как раз и работаю над этим вопросом :rolleyes: )
Не нужна - пока и тырдос сойдёт.
кста по поводу раздела памяти #4000 - #8000 - таблицы и подгружаемыые драйвера ? по поводу таблиц ничего против не имею, а вот надчет дров, все видимо дружно заб(и/ы)ли что это область slow memory !!! и всё это будет жутко торрмозить! единственное для чего эта область пригодна это для хранения данных!!! :sleep:
А ты недружно забыл, видимо, что слоу мемори только на фирменных и на самых примитивных клонах? В нормальных клонах везде быстрая (точнее, везде одинаковая =).
CityAceE
16.03.2005, 13:31
Объясните мне, пожалуйста, для чего на Спектруме может понадобиться многозадачность?
На мой взгляд самым оптимальным было бы иметь такую задачность как, например, в MagOS.
Объясните мне, пожалуйста, для чего на Спектруме может понадобиться многозадачность?
Реальная многозадачность - действительно совершенно не нужна, а вот управляемая (переключение задач пользователем) может понадобиться!
Типичный пример: Набрал чтото в редакторе, переключился в ассемблер компильнул - увидел ошибки (но при этом редактор не исполняется, он насмерть заморожен), переключился в редактор - исправил и т.д.
Вот, кому надо - ловите ядро управляемой многозадачности. До 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-тактовых единиц) для проверки, можно ли выполняться.
Реальная многозадачность - действительно совершенно не нужна, а вот управляемая (переключение задач пользователем) может понадобиться!
Типичный пример: Набрал чтото в редакторе, переключился в ассемблер компильнул - увидел ошибки (но при этом редактор не исполняется, он насмерть заморожен), переключился в редактор - исправил и т.д.
Нету многозадачности - нету и оконного интерфейса нормального, и тд, и тп. Аля-магос - а зачем тогда и вообще ось нужна? Наклонировал цп/мок в памяти с 1 виртуальным диском (или винтом) - и работай себе.
Аааа... ушла уже страница. Сообщением выше положил решение для многозадачности.
Согласен - простейший вариант реализации - повешать на 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.
Теоретиков, вижу, много. А где же практики??? :)
теория обязательно должна предшествовать практике. иначе будет бесполезная трата сил и времени на заведомо неправильные вещи %)
народ восставал против NMI по той причине что не надо вмешиваться в аппаратуру. имхо модульная структура позволит использовать все что угодно.
NMI - это идеальный вариант. МОжно и стандартный INT - это не принципиально. Так что если "народ восставал" - то пусть юзают стандартный INT. Но тогда зависшую после DI программу - не снимешь без рестарта. Впрочем - можно написать поддержку и NMI и INTа - пусть кому что нравится юзают.
а с другой стороны практически полное отсутствие защиты от несанкционированной записи в ядро
Ну это уж не проблема. Кому очень захочится такой защиты - могут сделать порт блокировки записи в нижние 16к ОЗУ. Или лучше - порт, который позволяет блокировать запись в любую из 4х страниц. Большинству же это поровну. ИМХО, для большинства - прошить ПЗУ большая проблема, нежели мириться с отсутствием защиты.
для того чтобы скомпилять ядро того же линукса не обязательно быть крутым кулхацкером. и это несмотря на то что оно в исходах. компилятор все делает по скриптам за тебя. и никакой мороки
Ну это кому как удобнее. Совершенно непринципиальный вопрос.
ну должен поддерживаться стандартный джентльменский набор IPC: семафоры, критические секции, сигналы, каналы
В иделае - да. Но надо начинать с минимума. ИМХО, минимум - это разделяемая память, стандартный интерфейс драйверов и менеджер задач. Если пытаться реализовать все сразу - то только мороки больше будет.
выделять по 16 кило на процесс- слишком жирно. плюс желательно предусмотреть возможность использования одного куска кода разными процессами (тогда можно будет делать fork и не ломать голову с нитями)
Сразу в стандарте POSIX мыслишь ? ))) МОжет форки и нити на чуть потом оставим ?)
Я и не собирался 16К на процесс выделять. В ядре хранится таблица свободных странц и для каждой страницы есть флаг - занята она целиком под процесс или частично. Если целиком - то все понятно. А если частично - то на странице присутствует структура, типа локальной кучи. Таким образом на странице может быть много процессов.
у меня были такие идеи. вся верхняя память делится по блокам, при загрузке процесса выделяется место под его код и еще немного (сколько надо) под локальную память, которая распределяется статически самим процессом (хотя можно и системный менеджер кучи прикрутить). если процессу надо много памяти, он запрашивает систему и она выделяет память. правда доступ лучше реализовывать через буфер- доступ к верхней памяти по блокам. хоть тут есть один жирный минус- довольно большие затраты, зато много плюсов- не нужны резиденты в нижней памяти (их роль на себя берет система), на систему также можно возложить остальные операции по перемещению/копированию памяти (пускай делает это как ей удобно), контроль на запись данных (хранить контрольную сумму блока), возможность использования общей памяти с функцией copy-on-write.
Тут подходов может быть несколько. Не на всех компах все сработают. Скажем там где можно щелкать не только последние 16К памяти - все упрощается. На 128й стандартной машине - вообще сложно сделать нормально по быстродействию. Моя точка зрения - надо делать все по минимуму. Тогда быстрее будет виден результат. А затем уже дополнять чего не хватает.
Короче так или иначе - надо ориентироваться на 128к - стандарт как минимум. Для навороченных машин типа ATM - другой менеджер памяти однозначно нужен.
acidrain
17.03.2005, 12:37
LVD писал:
По крайней мере так ось сделана на амиге - всем осописателям кстати рекомендуется ознакомиться. =)
Тем более, что аос - это легкая (как в плане освоения, так и в плане кодинга) и удобная операционка 8).
Простота работы с либлами и ресурсами там на высоте. Присоеденяюсь к совету LVD - не зацикливайтесь вы на унихах и пц, есть и другие оси ;)
acidrain
17.03.2005, 12:43
3) делать ядро из модулей (типа линуха). в начальной поставке идет универсальное ядро, поддерживающее всевозможное железо или минимальную конфигурацию, работающую где угодно. юзер на целевой машине конфигурирует сборщик, определяя нужные ему возможности и выкидывая ненужные. ядро пересобирается. все довольны.
Я не согласен. Не нужно мне клона линукса, где надо все компилить и пр. мне не нужно делать чужую работу - мне охота купить, вкл. и работать (с минимальными настройками). Все должно быть в комплекте, если челу не нужно что-то, то просто "это" удалит.
4) графический пользовательский интерфейс (не путать с Hacker User Interface ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. ...
Обязателен в минимальной конфигурации. Мне не нужна коммандная строка, вместо нормальной работы с процессами. Если будет нужна консоль - вызову ее. =)
Всего лишь сугубо личное мнение, на которое можно не обращать никакого внимания, но другая ось на спеке мне не нужна =)
Я не согласен. Не нужно мне клона линукса, где надо все компилить и пр. мне не нужно делать чужую работу - мне охота купить, вкл. и работать (с минимальными настройками). Все должно быть в комплекте, если челу не нужно что-то, то просто "это" удалит.
И то и то нужно.
Обязателен в минимальной конфигурации. Мне не нужна коммандная строка, вместо нормальной работы с процессами. Если будет нужна консоль - вызову ее. =)
А какое отношение работа с процессами имеет к пользовательскому интерфейсу ? ИМХО - никакого. В ядре точно графическому интерфейсу делаить нечего. Только вкомпиленные драйвера стандартного экрана допустимы. Хочешь всегда работать в графике - поставил установку, чтобы GUI сам грузился - и все.
Всего лишь сугубо личное мнение, на которое можно не обращать никакого внимания, но другая ось на спеке мне не нужна =)
Радуйся, если хоть какаянибудь для начала появится )) Явно что ось для спека - не будет похожа ни на что другое)
NMI - это идеальный вариант. МОжно и стандартный INT - это не принципиально. Так что если "народ восставал" - то пусть юзают стандартный INT. Но тогда зависшую после DI программу - не снимешь без рестарта. Впрочем - можно написать поддержку и NMI и INTа - пусть кому что нравится юзают.
насчет идеальный- это да. тогда его тоже надо делать с периодичностью 50гц чтоб не было разницы. если будет модульная поддержка, можно будет присобачить что угодно
Ну это уж не проблема. Кому очень захочится такой защиты - могут сделать порт блокировки записи в нижние 16к ОЗУ. Или лучше - порт, который позволяет блокировать запись в любую из 4х страниц. Большинству же это поровну. ИМХО, для большинства - прошить ПЗУ большая проблема, нежели мириться с отсутствием защиты.
собсно да, но просто надо с осторожностью относиться к аппаратным доработкам
В иделае - да. Но надо начинать с минимума. ИМХО, минимум - это разделяемая память, стандартный интерфейс драйверов и менеджер задач. Если пытаться реализовать все сразу - то только мороки больше будет.
семафоры нужны по любому. хотя бы потому что большинство процедур ядра нереентерабельны, потому что юзают глобальные структуры и таблицы. поэтому повторный запуск приведет к краху
Сразу в стандарте POSIX мыслишь ? ))) МОжет форки и нити на чуть потом оставим ?)
Я и не собирался 16К на процесс выделять. В ядре хранится таблица свободных странц и для каждой страницы есть флаг - занята она целиком под процесс или частично. Если целиком - то все понятно. А если частично - то на странице присутствует структура, типа локальной кучи. Таким образом на странице может быть много процессов.
просто я проверял уже концепцию форков. намного меньшая ресурсоемкость при создании и по расходам памяти (один код на всех). а насчет памяти- лучше унифицировать все к единому интерфейсу (хотя бы по блокам, можно по килобайтам) и отсюда плясать
Тут подходов может быть несколько. Не на всех компах все сработают. Скажем там где можно щелкать не только последние 16К памяти - все упрощается. На 128й стандартной машине - вообще сложно сделать нормально по быстродействию. Моя точка зрения - надо делать все по минимуму. Тогда быстрее будет виден результат. А затем уже дополнять чего не хватает.
Короче так или иначе - надо ориентироваться на 128к - стандарт как минимум. Для навороченных машин типа ATM - другой менеджер памяти однозначно нужен.
вот поэтому я и гну линию сборки ядра из кусков. хранить одновременно несколько разных драйверов- пустая трата памяти. а так- выбрал нужный драйвер, он влился в ядро и работает как надо
Тем более, что аос - это lite unix 8).
Простота работы с либлами и ресурсами там на высоте. Присоеденяюсь к совету LVD - не зацикливайтесь вы на унихах и пц, есть и другие оси ;)
человек советует юних и советует на нем не зацикливаться ;)
а где можно взять инфу по этой ОС? а то заинтересовало
Я не согласен. Не нужно мне клона линукса, где надо все компилить и пр. мне не нужно делать чужую работу - мне охота купить, вкл. и работать (с минимальными настройками). Все должно быть в комплекте, если челу не нужно что-то, то просто "это" удалит.
откуда удалять? из пзу кусок выжигать? %)
ты пробовал линукс? советую пощщупать. ставишь и сразу работаешь. не в минимальной правда конфигурации а на полную все (основное железо по крайней мере). чтото не нужно или наоборот чегото не хватает- настраивай скрипт и компиляй ядро (5 строчек в консоли ввести для этого надо)
Обязателен в минимальной конфигурации. Мне не нужна коммандная строка, вместо нормальной работы с процессами. Если будет нужна консоль - вызову ее. =)
борщ отдельно, мухи отдельно %)
система не знает что такое консоль и что такое гуй. для нее юзер- источник асинхронных событий. поэтому вешать можно все что угодно. а ось- это не окошки со стрелочками, это гораздо больше....
Всего лишь сугубо личное мнение, на которое можно не обращать никакого внимания, но другая ось на спеке мне не нужна =)
в споре рождается истина (с) ктото древний
принял бы участие в написании unix подобной оси/ядра для спека. опыт в языке Си - 9 лет. только давайте действительно сначала определимся с многозадачностью и системой меж процессовых комуникаций. остальное, в принципе, уже пройденный путь. естественно файл система будет модульной. но нам, для начала, микро ядро надо продумать.
а не стоит ли начать с глобального вопроса/опроса: зачем вам нужна ОС на спекке, какие задачи вы хотите возложить на ОС?
имхо, от ответа на него будет зависеть очень многое. например: имеет ли смысл задумываться над многозадачностью/GUI/консолью...
по ходу прочтения этой ветки складывается впечатление, что каждый из обсуждающих хочет видеть абсолютно разные вещи...
acidrain
17.03.2005, 21:26
человек советует юних и советует на нем не зацикливаться ;)
а где можно взять инфу по этой ОС? а то заинтересовало
я несколько дезинформировал тебя и всех присутствующих, приношу свои извинения. аос - самостоятельная ось, не похожая ни на что другое. Хотя (судя по истории амиги) изначально вся аос планировалась наподобие никсов, тк один из кодеров до этого работал (точно не помню кто и что делал) над униксами.
А инфа какого плана тебя интересует? конкретно описания функционирования аос? могу выслать, как уже предлагал lvd, описание библиотек и на словах объяснить как оно работает=)
Есть еще огроменная фало по этому поводу, тож можно найти...
acidrain
17.03.2005, 21:40
откуда удалять? из пзу кусок выжигать? %)
ты пробовал линукс? советую пощщупать. ставишь и сразу работаешь. не в минимальной правда конфигурации а на полную все (основное железо по крайней мере). чтото не нужно или наоборот чегото не хватает- настраивай скрипт и компиляй ядро (5 строчек в консоли ввести для этого надо)
Толком не пробовал, вызвала внутреннее отвращение, как и виндовз. Выжигать не из пзу, ведь уважаемая тобой линух не записана в пзу? Повторять ошибки синклера? Нет уж увольте... =)
борщ отдельно, мухи отдельно %)
система не знает что такое консоль и что такое гуй. для нее юзер- источник асинхронных событий. поэтому вешать можно все что угодно. а ось- это не окошки со стрелочками, это гораздо больше....
Ду маешь я об оси сужу по стрелочкам и окошкам?
Толком не пробовал, вызвала внутреннее отвращение, как и виндовз. Выжигать не из пзу, ведь уважаемая тобой линух не записана в пзу? Повторять ошибки синклера? Нет уж увольте... =)
у меня поначалу тоже отвращение вызвало. несколько недружественным пользовательским интерфейсом. потом просек фишку. если бы мне ктото два года назад сказал что работа в консоли может мне показаться приятной, я бы плюнул тому человеку в лицо %)
Ду маешь я об оси сужу по стрелочкам и окошкам?
да нет, не думаю. просто так рьяно заявил "консоль только через мой труп!" что я аж испугался %))))
я несколько дезинформировал тебя и всех присутствующих, приношу свои извинения. аос - самостоятельная ось, не похожая ни на что другое. Хотя (судя по истории амиги) изначально вся аос планировалась наподобие никсов, тк один из кодеров до этого работал (точно не помню кто и что делал) над униксами.
А инфа какого плана тебя интересует? конкретно описания функционирования аос? могу выслать, как уже предлагал lvd, описание библиотек и на словах объяснить как оно работает=)
Есть еще огроменная фало по этому поводу, тож можно найти...
кинь линки на всю имеющуюся инфу. интересует архитектура, возможности, описания
человек советует юних и советует на нем не зацикливаться ;)
а где можно взять инфу по этой ОС? а то заинтересовало
Наиболее полный источник - родные РКМы (ром кернель мануал то бишь) в амижных форматах (гипертекстовый amigaguide). Вот попробовал конвертнуть в хтмл (заранее сорри - автоматом всё бьётся в кучу мелких файлов). Ща буду сюда втыкать =)
Ещё - самое главное.
Файлы склеить в алфавитном порядке и раззипить как обычный зип.
Я не виноват - это всё хфорум - не позволяет 1 зип в 1.5 мега пихнуть, только таким извратом.
PS: читать начать можно с exec libraries - это основное (позволит составить представление о многозадачности на амми)
PPS: везде главный файл - MAIN.html
семафоры нужны по любому. хотя бы потому что большинство процедур ядра нереентерабельны, потому что юзают глобальные структуры и таблицы. поэтому повторный запуск приведет к краху
Для этого есть хороший аппаратный семафор - DI/EI (в момент доступа к глобальным таблицам). =)
просто я проверял уже концепцию форков. намного меньшая ресурсоемкость при создании и по расходам памяти (один код на всех). а насчет памяти- лучше унифицировать все к единому интерфейсу (хотя бы по блокам, можно по килобайтам) и отсюда плясать
Дык как ты себе представляешь форки без мму и без автоматического разделения данных (по мере надобности)?
а не стоит ли начать с глобального вопроса/опроса: зачем вам нужна ОС на спекке, какие задачи вы хотите возложить на ОС?
Этот вопрос можно обобщить: "зачем вам нужен спекк?"
у меня поначалу тоже отвращение вызвало. несколько недружественным пользовательским интерфейсом. потом просек фишку. если бы мне ктото два года назад сказал что работа в консоли может мне показаться приятной, я бы плюнул тому человеку в лицо %)
Хе, а я вот как на линухе поставил фидоноду, так и успокоился по этому поводу. Даже апач с пхп компилял и заставлял работать - но как-то не втыкает это. Хорошая ось, позволяет много чего делать - и причём довольно-таки удобно (по мере привыкания к ней), но вот втыкать - не втыкает.
(ух ты - моё 300-тое сообщение! осталось обогнать только cityace, dhau и chrv! =)
Для этого есть хороший аппаратный семафор - DI/EI (в момент доступа к глобальным таблицам). =)
в случае NMI DI/EI не помогут. вот плохо что команды типа SET 0,A,(IX+1) сначала меняют значение, а потом загружают. если б было наоборот, проблема семафоров решилась бы на ура. а так... надо думать
Дык как ты себе представляешь форки без мму и без автоматического разделения данных (по мере надобности)?
мму нужен естесно. вопрос в его структуре и функциональности. в простейшем случае, при форке копируется только дескриптор вновь создаваемого процесса со своим стеком, т.е. код остается старый
А правда, создайте опрос про необходимость ОСи, я думаю, он должен показать главное требуемое направление, в котором нужно далее обсуждать и двигаться. Только вариантов ответов нужно побольше, а не только про многозадачность.
насчет идеальный- это да. тогда его тоже надо делать с периодичностью 50гц чтоб не было разницы. если будет модульная поддержка, можно будет присобачить что угодно
Модульность - я обеими ногами-руками за ! Только начальные драйвера (винчестера, кллавы, экрана) - полюбому придется сразу в ядро пихать.
собсно да, но просто надо с осторожностью относиться к аппаратным доработкам
Почему ? Модульность позволяет и без особой осторожности. Есть поддержка нужной фичи на аппаратном уровне - грузим нужный модуль (или прописываем в настройках какогото модуля SuperFicha=On) и все. )
семафоры нужны по любому. хотя бы потому что большинство процедур ядра нереентерабельны, потому что юзают глобальные структуры и таблицы. поэтому повторный запуск приведет к краху
Да никто не спорит что семафоры нужны. Но это настолько легкореализуемый механизм, что особо на нем циклиться не стоит. Стандартный короче механизм, в любом букваре описанный.
просто я проверял уже концепцию форков. намного меньшая ресурсоемкость при создании и по расходам памяти (один код на всех). а насчет памяти- лучше унифицировать все к единому интерфейсу (хотя бы по блокам, можно по килобайтам) и отсюда плясать
А с данными как ? Виртуализации памяти то нет. Так что либо - вся адресация в либах по базовому адресу+смещение, либо все данные для одной либы - в одинаковых адресах на разных страницах. Либо - копировать (о ужас!).
вот поэтому я и гну линию сборки ядра из кусков. хранить одновременно несколько разных драйверов- пустая трата памяти. а так- выбрал нужный драйвер, он влился в ядро и работает как надо
Согласен. Кроме того о чем я уже писал (драйвера винчестера, кллавы, экрана).
в случае NMI DI/EI не помогут. вот плохо что команды типа SET 0,A,(IX+1) сначала меняют значение, а потом загружают. если б было наоборот, проблема семафоров решилась бы на ура. а так... надо думать
Таки есть ex (sp),hl всё же - но это как минимум ДИ и ещё полдесятка команд.
...Собственно это к вопросу о НМИ. Ты возможно помнишь, в zx.spectrum тоже был кадр такой - Andrew ?. Mikheev - и он как-то тоже поднял разговор о своей поделке на z80 - где на интах висели только обработчики прерываний от устройств, а на нмях - только свичинг контекстов. И он мужественно боролся с тем, чтобы нми не переключал контекст, когда он прервал инт (и видимо с семафорами тоже боролся - раз DI/EI не канает). И при этом бия себя пяткой в грудь утверждал, что мол котлеты отдельно, и мухи - тоже отдельно. Можешь на groups.google.com поискать архивы.
А с данными как ? Виртуализации памяти то нет. Так что либо - вся адресация в либах по базовому адресу+смещение, либо все данные для одной либы - в одинаковых адресах на разных страницах.
Вообще-то да - для форка не только же данные копировать, а ещё и дескрипторы всех-всех-всех файлов, девайсов, хзчего ещё.
Более того - вот есть у проги кусок данных - а в этом куске абсолютные адреса. А отфорканной проге надо данные скопировать - по другим адресам. И кто будет править абсолютные адреса?
Да ну вы тут понаписали блин!
Если реализуется хотя бы одна десятая этого всего да на спек-128 - можно памятник заказывать разработчику (Правда я не знаю куда софт потом помещаться будет).
А еще прикиньте клевая штука получится - своп файл на 5.25дисководе!
И все же переключаемая(фоновая) многозадачность спеку совершенно не нужна. Нужна с переключением между процессами, но с замораживанием (остановом) фоновых процесов - это и проще и рулее.
acidrain
18.03.2005, 12:39
кинь линки на всю имеющуюся инфу. интересует архитектура, возможности, описания
lvd уже выложил см. выше =) но это далеко не все =)
lvd уже выложил см. выше =) но это далеко не все =)
Для ознакомления достаточно. А дальше - проще эмулятор поставить, и я бы сразу в #?.guide бы послал.
Попробую за выходные настругать на С некоторые зачатки ОСИ и выкинуть тут. (То есть переложить на Z80 свои творения для других процов). Если ничто не помешает, то выложу тут менеджер памяти и интерфейс доступа к драйверам. Там все на простом С писано без извратов. Так что должно перекласться с минимумом телодвижений.
Cкидываю отредактированный файл в котором нарисована структура ОС, как я ее представляю. Критикуйте.
Cкидываю отредактированный файл в котором нарисована структура ОС, как я ее представляю. Критикуйте.
Все вполне нормально, вот только возни с номерами драйверов, структурой KUI, и прочего, будет немало. А о такой унификации драйверов что-то я раньше не думал... :(
я чего то не понял, лично мне тот пример многозадачности что выкладывали на примере WORMS DEMO является наилучшим примером как может быть ПОЛЕЗНА многозадачность на спеке. а вы сразу ЗАМОРОЗКА, зачем нужны многочисленные процессы. вам что, сразу кажется что юзер будет запускать Элиту, XAS и пытаться одновременно флоп форматить? мне кажется что в ПЕРВУЮ очередь это будет полезно для самих приложений под эту ось, для организации четкой архитектуры и единого интерфейса ввода, вывода, работы с диском.
И все же переключаемая(фоновая) многозадачность спеку совершенно не нужна. Нужна с переключением между процессами, но с замораживанием (остановом) фоновых процесов - это и проще и рулее.
совершенно это как? и остановка (заморозка) это насколько? ведь на ПэЦэ и Амиге тоже ОДНОВРЕМЕННО два приложения не исполняются.
совершенно это как? и остановка (заморозка) это насколько? ведь на ПэЦэ и Амиге тоже ОДНОВРЕМЕННО два приложения не исполняются.
Смотря что ты под одновременностью понимаешь. Ты прикинь если на спеке будет как на ПЦ постоянная раздача квантов времени всем процессам, вот тормозуха то будет, и так скорости не хватает!
А я предлагаю чтобы работало токо основное приложение!
Смотря что ты под одновременностью понимаешь. Ты прикинь если на спеке будет как на ПЦ постоянная раздача квантов времени всем процессам, вот тормозуха то будет, и так скорости не хватает!
А я предлагаю чтобы работало токо основное приложение!
а чем пример с WORMS не яркое опровержение тобой предсказуемых "тормозов"?
Модульность - я обеими ногами-руками за ! Только начальные драйвера (винчестера, кллавы, экрана) - полюбому придется сразу в ядро пихать.
я имею в виду модульность на этапе компиляции, а не только на этапе выполнения. см. соответствующий тред в ветке про программирование
Почему ? Модульность позволяет и без особой осторожности. Есть поддержка нужной фичи на аппаратном уровне - грузим нужный модуль (или прописываем в настройках какогото модуля SuperFicha=On) и все. )
туда же. но надо чтобы был обеспечен какой-либо минимальный набор аппаратуры на которой бы все запустилось
Да никто не спорит что семафоры нужны. Но это настолько легкореализуемый механизм, что особо на нем циклиться не стоит. Стандартный короче механизм, в любом букваре описанный.
дык одних алгоритмов синхронизации штуки 4 только %) (почему запомнил- слегка "поплавал" на них на экзамене %))
А с данными как ? Виртуализации памяти то нет. Так что либо - вся адресация в либах по базовому адресу+смещение, либо все данные для одной либы - в одинаковых адресах на разных страницах. Либо - копировать (о ужас!).
почему нет? вчера (сегодня уже то бишь) с тов. GriV'ом перетирали данную тему. пришли к такой идее. процессы юзают только верхнюю память в страницах, нижняя память целиком и полностью принадлежит системе. каждому процессу выделяется какой-то объем памяти в странице, который он юзает как локальную кучу и адресует непосредственно. если же ему надо дофига памяти, он обращается к менеджеру, который выделяет память в других страницах и возвращает указатель на _дескриптор_ блока памяти. при дальнейшем доступе к выделенной памяти диспетчер выделяет окно в нижней памяти и перекидывает туда кусок из верхней. после записи (если разрешена), данные копируются обратно. хотя и накладно по ресурсам, зато получаем сразу кучу плюсов- защита памяти, нет необходимости в резидентах, возможность свопинга.
Таки есть ex (sp),hl всё же - но это как минимум ДИ и ещё полдесятка команд.
...Собственно это к вопросу о НМИ. Ты возможно помнишь, в zx.spectrum тоже был кадр такой - Andrew ?. Mikheev - и он как-то тоже поднял разговор о своей поделке на z80 - где на интах висели только обработчики прерываний от устройств, а на нмях - только свичинг контекстов. И он мужественно боролся с тем, чтобы нми не переключал контекст, когда он прервал инт (и видимо с семафорами тоже боролся - раз DI/EI не канает). И при этом бия себя пяткой в грудь утверждал, что мол котлеты отдельно, и мухи - тоже отдельно. Можешь на groups.google.com поискать архивы.
надо будет посмотреть. а также стандартные алгоритмы (при условии что удастся найти элементарные команды)
Вообще-то да - для форка не только же данные копировать, а ещё и дескрипторы всех-всех-всех файлов, девайсов, хзчего ещё.
Более того - вот есть у проги кусок данных - а в этом куске абсолютные адреса. А отфорканной проге надо данные скопировать - по другим адресам. И кто будет править абсолютные адреса?
форк по большому счету не обязан копировать все данные родительского процесса. делаем как в одной ОСи: есть функция под названием vfork, которой на входе подается флаг чего надо копировать. если нам нужна, грубо говоря, рабочая нить, зачем нам тянуть все открытые файлы и память? достаточно скопировать дескриптор и стек, а выполняться будет родительский код. т.е. у процесса из своего может быть только стек и дескриптор (иначе никак), а все остальное он может и не иметь.
копирование дескрипторов файлов заключается в увеличении числа ссылок открытого файла (попробуй одновременно родительским и дочерним процессом читать из файла- они оба изменяют указатель позиции). копирование памяти можно выполнять только после внесенных туда изменений (copy-on-write). так что пространства для творчества- хоть отбавляй
Cкидываю отредактированный файл в котором нарисована структура ОС, как я ее представляю. Критикуйте.
видно, человек проникся идеологией С/UNIX :)
VFS и таблицы драйверов с виртуальными (практически) функциями- самое то что надо.
имею единственное предложение по формату системных вызовов: делать приложения релоцируемыми. т.е. загрузили их туда, где выделили память, настроили адреса под конкретное значение, попутно занеся адреса нужных системных вызовов. кернель сокращается с 3 до 2 байт на точку входа (хотя это могут быть не только функции, а также переменные, константы), нет лишних тактов, все делается самым быстрым способом.
Смотря что ты под одновременностью понимаешь. Ты прикинь если на спеке будет как на ПЦ постоянная раздача квантов времени всем процессам, вот тормозуха то будет, и так скорости не хватает!
А я предлагаю чтобы работало токо основное приложение!
посмотри на структуру любого нормального обработчика прерываний:
push all_registers
do_smth
pop all_registers
ei
ret
а теперь на структуру диспетчера задач при вытесняющей многозадачности:
push all_registers
change_sp_ptr
pop all_registers
ei
ret
похоже слегка, не так ли? %)
единственное, на что будут "лишние" такты- это непосредственно выбор кандидата на выполнение. алгоритмов этому куча, можно выбрать любой.
Дело в тормозах не потомучто обработчик-распределитель долго работает, а потомучто фоном еще куча фигни не нужной выполняется.
Конечно есть задачи которые нужны, там типа часов, АУ плеера, так пусть они и вставляют свой вызов в обработку прерывания.
А например мне нужно простейшая задача: редактор+ассемблер+спрайтэ дитор, и я не хочу чтобы они в фоне еще там чего то квакали :smile: . Но переключаться мануально между ними я очень хочу!
Corpsegrinder
19.03.2005, 10:22
Да! серьёздно разраслась тема, и правда уже пора писать техзадание, даже на основе того, что здесь уже выложено.
Коментарии по ходу чтения:
1. Предложеная Vitamin'ом схема разделения памяти - хороша тем, что позволяет унифицировать все процессы - они хранятся в 16 кб страничках, как аласм. Кдинственное в ней в сегменте между #8000 и #c000 нужно давать возможность размещать как разделяемые несколькими потоками данные быстрого доступа, так и часть кода для быстрой обработки данных лежащих вне страницы с основным кодом (иначе я себе просто не представляю как делать те же текстовые редакторы или асемблер - они же тормозить будут)
2. Споры по поводу INT vs NMI считаю неконструктивным поскольку и то и другое можно реализовать и выбирать при помощи настроек системы. У кого есть MNI каждую милисекунду - настраивает на работу с NMI, у кого нет - на работу через INT. Что качается периода вызова, тоже не вижу проблем, можно так же настраивать период квантования для правильного учёта процессорного времени (для INT 1/50 секунды, для NMI - уж как реализована аппаратная часть). Разумеется при загрузке и инициализации сначала все работать должно на INT а то и вообще с запрещёнными прерываниями, а уж потом, если есть соответствующие настройки - включает через порты фишку с NMI раз в 1 милисекунду и разуется жизни форева. С INT будет вытесняющая многозадачность (di поставил и жрёшь ресурсы сколько влезет) а с NMI - вытесняющая, посколько прерывания немаскируемые.
3. По поводу Fork и разделяемого кода. Можно для библиотек ввести дескрипторы (2-4 байта - систему выдачи уникальных идентификаторов вроде GUID у мелкомягких), такие же дескрипторы использовать и для приложений, тогда можно будет при необходимости пользоваться чужим кодом вызываю его через дескрипторы. Так же, в случае fork, Vitamin верно предложил, по минимуму можно для нового потока, порождённого через fork, копировть только стек, ну ещё контексты (вроде DC в виндовз).
4. Замораживающая многозадачность уже реализована в QC и RC, а так же в ACE и Alasm ;) но от этого никому легче не становиться, програм поддерживающих это практически нет, разве что выход в командер после прочтения текста в листалке, созданной с помощью TextMaker, да по всей видимости в продуктах AlCo.
Теперь по поводу необходимоси всего этого, если бы всё это было не нужно и неудобно, никто бы не заглядывался на писюки и амиги вот как там здорово можно несколько задач выполнять не делая сброс компьютера. Другое дело, что чтобы сделать дейстующий экземпляр чего-то такого придётся неплохо поломать голову и немало времени потратить на реализацию, особенно, если будет хорошо поддержана совместимость со старыми программами, хотябы под TR-DOS.
Без приложений ОС не нужна никому кроме как разработчиков, которые семореализовались, написав её. А запускать программы пользователю фиолетово, хоть через TR-DOS+boot/командер хоть через супер-пупер навороченую ОС с многозадачностями. С точки зрения программиста, в ОС для спека особенно важно, чтобы ограничений на оптимозацию работы программ под неё было минимум. Но и эта проблема, я думаю, не слишком тяжела, если всё правильно спроектировать и разработать механизм быстрого доступа к данным и коду, как собственной программы, так и ядра системы(один из вариантов решения этой задачи я уже предлагал в пункте 1).
Дело в тормозах не потомучто обработчик-распределитель долго работает, а потомучто фоном еще куча фигни не нужной выполняется.
Какой например? По-твоему, если в винде висит полсотни процессов, то каждый из них ужирает кусочек времени? Нифига, они просто висят и ждут, когда их разбудят. По крайней мере не знаю как в винде, а в амигаос именно так. Всем рекомендуется ознакомиться :) (а то блин форки на спектруме собрались делать!)
А например мне нужно простейшая задача: редактор+ассемблер+спрайтэ дитор, и я не хочу чтобы они в фоне еще там чего то квакали :smile: . Но переключаться мануально между ними я очень хочу!
Ну и отлично. 3 задачи висят в памяти. Работаешь с редактором - его экран показывается, сообщения от мыши и клавы идут ему. В это время спредитор или асм спят - их экран не активен и сообщений ему не идёт, шедулер их не запускает.
2. Споры по поводу INT vs NMI считаю неконструктивным поскольку и то и другое можно реализовать и выбирать при помощи настроек системы.
[skip]
С INT будет вытесняющая многозадачность (di поставил и жрёшь ресурсы сколько влезет) а с NMI - вытесняющая, посколько прерывания немаскируемые.
Вытесняющая многозадачность не имеет отношения к INT/NMI. Зато вот простейшие действия типа критических частей (в самих ф-циях оси, например!) вызывут кучу проблем при НМИ и всего лишь DI/EI при INT. А что касается железных доработок - уж лучше контроллер прерывания поставить, чем генератор НМИев каждуй миллисекунду (хм - а может каждые 100 тактов сразу?).
К предложенному ядру RTK вытеснение задач добавить - как два пальца... Если надо - сделаю.
К предложенному ядру RTK вытеснение задач добавить - как два пальца... Если надо - сделаю.
respect! внес здравое зерно в дискуссию. а как насчет выделения памяти и тд?
Вытесняющая многозадачность не имеет отношения к INT/NMI. Зато вот простейшие действия типа критических частей (в самих ф-циях оси, например!) вызывут кучу проблем при НМИ и всего лишь DI/EI при INT. А что касается железных доработок - уж лучше контроллер прерывания поставить, чем генератор НМИев каждуй миллисекунду (хм - а может каждые 100 тактов сразу?).
Кто запрещает в схему генерации NMI от таймера (котрой стандартно нет, кстати) добавить порт, доступный только из ОС, который может запрещать-разрешать генерацию NMI ? Таким образом программы пользователя не смогут завесить ОС, а сама ОС для выполнения атомарных действий будет запрещать генерацию NMI.
Про выделение памяти уже думал... Если бы была возможность переключать не только верхнюю страницу - все бы было здорово. А так напрашивается только копирование... Или еще возможна сегментация области кода - т.е. выделяется 4-8 кб под код, если программа хочет еще - она говорит ядру - "скопируй мне новые 4-8к вот отсюда, и запусти их с адреса такого-то". Имхо разумный вариант.
З.Ы. Следующую "preview" ZX-Worms project 2 (с ядром на RTK) положил в "Игры".
P.P.S. Если речь идет о С/C++ и совместимом рантайме (*nix) - то можно C-ядро держать в несвапабельной странице...
Кто запрещает в схему генерации NMI от таймера (котрой стандартно нет, кстати) добавить порт, доступный только из ОС, который может запрещать-разрешать генерацию NMI ? Таким образом программы пользователя не смогут завесить ОС, а сама ОС для выполнения атомарных действий будет запрещать генерацию NMI.
Вообще-то здравая мысля была - оставаться в рамках обычного 128к спекки. А если так, то НМИ отдыхает. А если говорить о хардваремодах, то тогда КУДА логичнее контроллер прерываний нормальный, а не нми.
Кстати, завесить нми - как два пальца об асфальт - стек в ПЗУ и прощай...
Какой например? По-твоему, если в винде висит полсотни процессов, то каждый из них ужирает кусочек времени? Нифига, они просто висят и ждут, когда их разбудят. По крайней мере не знаю как в винде, а в амигаос именно так. Всем рекомендуется ознакомиться :) (а то блин форки на спектруме собрались делать!)
fork- всего лишь метод создания процесса. а диспетчеризация- дело другое.
Ну и отлично. 3 задачи висят в памяти. Работаешь с редактором - его экран показывается, сообщения от мыши и клавы идут ему. В это время спредитор или асм спят - их экран не активен и сообщений ему не идёт, шедулер их не запускает.
ну чтобы не усложнять задачу, реализовать добровольный пропуск кванта. или слать сигналы SIGSTOP/SIGCONT для останова/продолжения работы процесса. хотя все равно накладно. уж лучше пускай процесс сам себе ставит низкий приоритет и уступает квант.
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). начиная от каналов и сокетов и заканчивая буфером обмена.
Вытесняющая многозадачность не имеет отношения к INT/NMI. Зато вот простейшие действия типа критических частей (в самих ф-циях оси, например!) вызывут кучу проблем при НМИ и всего лишь DI/EI при INT. А что касается железных доработок - уж лучше контроллер прерывания поставить, чем генератор НМИев каждуй миллисекунду (хм - а может каждые 100 тактов сразу?).
имея на руках готовый код, можно замерить затраты времени на переключение контекстов и диспетчеризацию. а потом строим функцию реакции системы в зависимости от частоты прерываний (потому как скорость процессора от них не меняется). экстремум этой функции и будет оптимумом %)
пришпиливаю исход модуля работы с процессами (юзался в одном из вариантов ChAOS). обвязку не прилагаю, компилять и запускать смысла нет %) код страшный, так что просьба не пугаться
Corpsegrinder
20.03.2005, 14:30
ну авторство не только мое %)
в нижней памяти стоит разрешать только библиотеки располагать. да и то по требованию. по умолчанию их можно пихать в верхнюю же память и вызывать через менеджер. потому как тогда можно будет многоразово использовать код и следовательно экономить драгоценную нижнюю память
Так а всё таки как ты представляешь себе например ACEdit адоптированный к такой среде, неужели текст по несколько киолбайт только обрабатывать?
Без размещения кода, который колбасит текст в других нежели редактор страничках, в нижней памяти я себе это не представляю, пусть бы даже и он(код) копировался каждый раз из верхней памяти по необходимости в нижнюю.
зачем уложнять, вводить систему? делать идентификатором физический адрес объекта. решается проблема унификации и упрощения доступа.
кста, DC- относится к графической части окошек %)
ну и что, я про саму идею. Физический адрес - не идентифицирует уникально нужный код, поскольку код может лежать в разных страницах в разное время запуска процесса, а может и вообще не быть запращиваемого кода, когда библиотека не загружена.
одно, на мой взгляд самое большое, преимущество одной системы на несколько одновременно работающих приложений- система обмена информацией (IPC). начиная от каналов и сокетов и заканчивая буфером обмена.
Вот это и есть самое главное преимущество!!! Возможность не нажимая на reset делать разноплановые задачи и иметь возможность перетаскивать данные из одной задачи в другую, будь то текст, графика или просто синхронизирующие работу разных задач сообщения. Например для редактирования текстов в общем случае не нужно всё процессорное время каждую единицу времени и его можно занять например компиляцией.
Так а всё таки как ты представляешь себе например ACEdit адоптированный к такой среде, неужели текст по несколько киолбайт только обрабатывать?
Без размещения кода, который колбасит текст в других нежели редактор страничках, в нижней памяти я себе это не представляю, пусть бы даже и он(код) копировался каждый раз из верхней памяти по необходимости в нижнюю.
при работе с большими кусками памяти резидет обязателен. имхо, лучше его оформить в виде разделяемой библиотеки. ведь в чем заключается, по большей части, работа с данными? вывод на экран, пересылка, вставка, удаление. т.е. вполне стандартный набор процедур. и велика вероятность, что не только одна программа будет выполнять такие операции. а с процесса по резиденту- уменьшается объем доступной памяти и увеличивается анархия %)
ну и что, я про саму идею. Физический адрес - не идентифицирует уникально нужный код, поскольку код может лежать в разных страницах в разное время запуска процесса, а может и вообще не быть запращиваемого кода, когда библиотека не загружена.
процесс описывается своим дескриптором. все остальные объекты, которые необходимо описывать, лежат в нижней памяти. отсюда и однозначное наименование
Вот это и есть самое главное преимущество!!! Возможность не нажимая на reset делать разноплановые задачи и иметь возможность перетаскивать данные из одной задачи в другую, будь то текст, графика или просто синхронизирующие работу разных задач сообщения. Например для редактирования текстов в общем случае не нужно всё процессорное время каждую единицу времени и его можно занять например компиляцией.
вот с этого я и начинал!!! большую часть времени программы проводят в ожидании, почему бы не занять это время полезным делом? а насчет вытесняющей/коперативной многозадачности- чисто дело реализации. хотим вытесняющую- диспетчеризацией будет заниматься процессор. хотим кооперативную- нехай юзверь щелкает задачами. правда в таком случае теряется интерактивность. как компромисс- введение интерактивного процесса, не активного в данный момент, в "кому"- пускай просто подает признаки жизни и реагирует на критические события
10 страниц мне даже читать не хочется...
2Moders> надо было с самого начала чётко ограничить тему техническим заданием и конкретными вопросами, построение операционной системы не делается одним предложнием...
Мы с витамином разработали схему, которая позволяет чрезвычайно эффективно работать с любой памятью (теоретически,чтобы ось реально работала даже на компах с 16кб памяти), от 16 кб до нескольких десятков МБ, если надо могу спецификации закинуть...
Касательно диспетчирезации задач тоже есть наработки...
Давайте уже закрывать тему и открывать более конкретные, чтобы не валить в один котёл и дрова и колбасу...
Вообще-то здравая мысля была - оставаться в рамках обычного 128к спекки. А если так, то НМИ отдыхает. А если говорить о хардваремодах, то тогда КУДА логичнее контроллер прерываний нормальный, а не нми.
Вообщето была мысля сделать модульную систему. Минимум для запуска - 128К стандарт. А навороты все - как отдельные модули грузятся. DI: jr -2 и капец. Прога висит. Хотя помоему - решение должно быть комплексное - если уж делать контроллер прерываний - то почему туда и таймер для NMI не всунуть ? На любом микроконтроллере можно реализовать. Или еще вариант - NMI от клавиатуры - это у многих уже есть (MAGIK родимый).
Кстати, завесить нми - как два пальца об асфальт - стек в ПЗУ и прощай...
И много программ со стеком в ПЗУ работать смогут ? Я к тому что речь идет о реальных программах, а не о спецподелках чтобы NMI завесить. Скажем отлаживаешь программу - а она возьми и повисни. Лезешь в деспетчер задачь и снимаешь ее. Или еще вариант - пошагловая отладка.
Что касается памяти - то вот что придумалось за выходные.
Что касается памяти - то вот что придумалось за выходные.
Извиняюсь - не отправилось сначала.
В общем во вложении - некоторые наброски по управлению памятью. В каталоге doc есть файл с "Организация памяти.pdf" - там нарисованы некоторые соображения.
Я к тому что речь идет о реальных программах, а не о спецподелках чтобы NMI завесить. Скажем отлаживаешь программу - а она возьми и повисни. Лезешь в деспетчер задачь и снимаешь ее. Или еще вариант - пошагловая отладка.
Реальные программы, зависнув, всю память запортят, и нми опять же не спасёт. Это тебе не винда или линь.
Пошаговость - опять нми не причём, так как оно по фронту, в то время как инт - по уровню.
Уважаемые разработчики, взгляните, какую работу проделал Spectrum! Неужели никто не оценит?
P.S. Я к сожалению не разработчик, и могу оценивать указанную работу только с точки зрения логики, структуры документа и методологии проекта. Но это наверно не так интересно.
acidrain
17.05.2005, 12:43
А ОС (среда) - как инструмент для достижения поставленных задач.
прочитал больше половины дока - радует одно рвение и объем проделанной работы.
Но, мое мнение , мне б такая ось не подошла =) Одним словом - не то, что я ожидал...
Без обид плиз!
это скорее всего больше похоже на кусок сырого мяса. Я его от версии к версии кромсаю. Как видно окончательный вариант получиться когда всё мясо перекромсается до неузнаваемости.Получится фарш.:)
- В начале 90х мозги дальше подобия встроенного монитора ПЗУ 90 года далеко не уходили.Да да, в начале 90-х на спекки работали динозавры, :eek: к счастью почти все они вымерли.
- В середине 90х в голове был ИСДОС1991 (начало разработки 1989).
- В 97 году предполагался вариант похожий на CPM.1991 (Profi), а вообще то CP/M это еще начало 80-х
- В конце столетия (круто звучит) был вариант аля юних (всё файлы).это что за зверь?
- В начале 2000 была многозадачка (есть вариант многозадачного редактора строки - с классическими очередями, динамической памятью и вытесняющей многозадачкой).??? что конкретно?
Да уж куда круче. А в итоге всех этих мыслевытеканий всё вылилось в простоту.Скорее в пустоту. Хорошее словечко «мыслевытекание» :D
Хочется для людей делать, а не как всегда не пойми для кого.Вы, что всегда делали "не пойми для кого"? ;)
Если этот проект дойдёт до какого-то логического завершения, то я скорее буду на спеке сидеть на 60% больше, нежели щас.Надо указывать сколько сейчас, а то если 0 или 18ч то задачка может не иметь решения.:D
И неплохо было бы к спеку FLASH или ещё что-нить из новых девайсов прикрутить, чтоб полноценно можно было работать.Сколько угодно:
http://members.tripod.com/~piters/zx.htm (http://members.tripod.com/~piters/zx.htm)
http://user.tninet.se/~vjz762w/ (http://user.tninet.se/~vjz762w/)
http://members.chello.se/erkan/plus3/ (http://members.chello.se/erkan/plus3/)
http://8bitorbust.info/ (http://8bitorbust.info/)
http://myweb.absa.co.za/dan_antohi/ (http://myweb.absa.co.za/dan_antohi/)
Шутки все воспринимают по разному.Не обижайтесь: прочитав ваше сравнение с пригоровлением мяса, я решил что вы шутите.
Просмотрел. Впечатляет.
Одно "но"! (Прошу не обижаться на критику.)
Выкинь нафиг интерфейсы пользователя из ОС.
Это должны быть внешние программы. Однозначно. Зачем юзеру, который пользуется ГУИ командный интерпретатор ? Зачем к ОСи присабачивать нортон-подобный довесок ? Пусть все это лежит на диске. Надо - загрузил. Надо - выгрузил.
В остальном - покритикую после подробного прочтения.
acidrain
17.05.2005, 19:39
Если не затруднит в будущем напишите поконретней, с чем не согласны, как лучше, чем хуже. Хочется для людей делать, а не как всегда не пойми для кого. Если этот проект дойдёт до какого-то логического завершения, то я скорее буду на спеке сидеть на 60% больше, нежели щас. И неплохо было бы к спеку FLASH или ещё что-нить из новых девайсов прикрутить, чтоб полноценно можно было работать.
Уважаемый спектрум!
=)
Как я уже говорил - не дочитал. Например, из двух вариантов вызова системных функций второй меня устроит больше, а rst #xx - утопия, хотя и экономия памяти (? зачем, спрашивается, если, например 256 кб?) по тому, что ограничиваем сами себя - потом будем нагромождать всякие патчи для оси тп лишь бы добавить либлу или еще чего. Потом многозадачность - это для меня основа оси. Резиденты -это что вообще такое? Процессы? Или скрытые части проги, тихо затаившиеся, как в мониторе стс, например =)? Зачем они нужны?
А остальное - после, как дочитаю ;)
Второй вариант - он стирает грани между уровнями, если не стирает уровни как понятие. Вот например ситемный уровень уже отпал - зачем декодировать какие-то номера и функции если идёт прямой вызов? Тоже и с оборудованием. Правда зачем страдать фигнёй по поределени. kempston это или нет - просто вызов и всё.
Многозадачность реализуема, если другие проги будут работать в страницах. А если происходит выгрузка контекста, то многозадачность уже не работает. Правда программа должна решать с кем её работать - в купе в мнозозадачности или самостоятельно отбросив все догмы. Резиденты - это с одной стороны могут быть процессы, а сдругой стороны как дополнение к программе или её окружению.
А я все-таки за rst xx, db xx... Это структурирует программу, легче запоминается, легче воспринимается другими (на случай, если кто-то будет доделывать твою прогу).
Скорость и размеры не смущают? А если ПЗУ не трогать, то делать перехват RST?...
А здесь в асме получается типа CALL function (здесь указываешь поимённое название, а не адрес), а после компиляции получишь уже вызов внутри таблицы JUMP-ов. Этот способ занимает 6 байт (типа - вызов, декодирование кода функции, переход). Сдесь только наверно важно договориться о правилах передачи, возврата параметров или всё будет зависеть от той области (уровня) с которым ты работаешь.
RST выглядит наглядно, только для кого? Или всё-таки смущают фиксированные адреса функций? Ты же когда пишешь игры ты же не используешь что-то типа RST, а делаешь CALL или JUMP. А для фиксированных адресов нужно делать резервацию для дальнейшего расширения.
Я думаю, что метод типа CALL function избавит систему от не нужных действий. Ну и самое примечательное - это гибкое изменение адресов переходов на лету.
А зачем тогда ОС, если все и так пишут CALL. Может возьмем кучу программ и будем использовать их возможности (CALL)?
Шутка конечно.
Но прямой CALL мне не нравится. Представь, сколько их будет? Даже если и будет отдельный файлик в котором они прописаны.
Да, и на счет расширения как поступать? Сделать таблицу на x байт длиннее на будущее? А если опять не хватит, что потом? Нужно все равно как-то ограничивать кол-во функций. Хотя бы по тем разделам, которые ты предлагаешь.
acidrain
18.05.2005, 12:21
RST выглядит наглядно, только для кого? Или всё-таки смущают фиксированные адреса функций? Ты же когда пишешь игры ты же не используешь что-то типа RST, а делаешь CALL или JUMP. А для фиксированных адресов нужно делать резервацию для дальнейшего расширения.
Я думаю, что метод типа CALL function избавит систему от не нужных действий. Ну и самое примечательное - это гибкое изменение адресов переходов на лету.
Опять 25. Я уже выкладывал по амижным библиотекам инфу? Так вот, умные люди там сделали так: В инклудах хранится смещение, которое перед вызовом функции записывается в виде (макрос) CALLINT LockPubScreen
Где:
callInt - макрос, на самом деле заменяется командой jsr /1(a6);
LockPubScreen - это смещение, заданное заранее (например, LockPubScreen EQU -277 - адрес от "фонаря" - не проверяйте ;) ).
Результат этого макроса таков:
jsr -227(a6)
В итоге получается, что происходит вызов функции со смещением -277 от адреса прописанного в адресном регистре А6. При всем при этом, изменение адреса расположения функции в самой библиотеке не несет за собой переделку всех заранее установленных смещений.
Отсюда возникает вопрос - ЗАЧЕМ нужен подход (который пытался применить Shaos в разрабатываемой им для спринтера оси), когда идет вызов по НОМЕРУ функции, это ведь чистой воды бред. Или я опять не прав? Причем я пытался это разжевать И Shaos, но видимо мои речи не столь понятны окружающим, как мне самому ;)))
acidrain
18.05.2005, 12:59
Гибкое изменение - это возможность в области, где прописаны JUMP-ы, менять адрес перехода (или вообще например - RET поставить).
Эта область нужна только если будут меняться адреса функций уровней ОС от версии к версии, для обеспечения совместимости адресов вызовов.
Тут я, увы, вообще не понял о чем Вы говорите. Причем тут версии оси или либлы? Я говорил за общий подход по вызову библиотечных (или ядренных;) ) функций. Предложил упрощение.
И, пожалуйста, не называйте меня на Вы, ок? =)
Не стоит забывать, также, что амига ось полностью релоцируема, кроме жестко зафиксированного адреса $4.w.
Как тут обстоит дело с осью для спеки? Вообще, прорабатывались ли варианты релоцируемости?
Для разъяснения моих мысле по поводу системных вызовов напишу код:
ld hl,dosbase
ld a,-36 ; open file
sbс a,hl ; к сожалению, не помню как это на z80 пишется =)
call (hl) ; тоже самое =)
...
dos.library:
ret
; library info
; -"-"-
...
openfile jp #26a0 ; тож фанарный адрес ;)
...
ret
...
#26а0 ...
ret
Принцип понятен? =)
acidrain
18.05.2005, 13:12
В соседнем форуме:
Mac Buster
PostPosted: 03 Feb 2004 16:43 Post subject:
Quote:
Все таки по поводу ОС несколько слов:
- стоит ли поддерживать фат для жестких дисков?
Очень не хочется, но в виде отдельного модуля файловой системы придется поддерживать эту fs.
Quote:
Может использовать какойнить другой формат попроще, что там в Амиге?
У Амиги свои файловые системы и большинство из них значительно сложнее fat.
Quote:
Ибо FAT мне важен если честно только на флопах, чтобы туда-сюда таскать проги...
Единственное достоинство fat - распространенная поддержка, она часто используется в качестве промежуточной при копировании данных из одной системы в другую.
Quote:
Обрисуй всетаки что там у тебя ожидается?
Ничего особенного, как у всех - 64 задачи, семафоры, очереди, сообщения, библиотеки функций, перехват/дополнение/замена функций Тип ядра - модульный, т.е. после компиляции он дополняется модулями файловой системы, базовыми библиотеками, интерфейсом и т.д. Получившийся непрерывный файл записывается на диск первым сразу после начального загрузчика (возможно последний будет включать в себя простейшую систему управления запуском операционной системы - режим экрана, ресурсы, и прочее).
Есть идея сделать следующее - так как обращение к функциям связано с некоторыми затратами времени на копирование аргументов, можно сделать некоторые функции в виде релоцируемых модулей, которые по запросу приложения могут быть скопированы в 64К отведенных задаче для самостоятельного максимально быстрого использования. Но это дело далекого будущего Из раздела «а почему-бы не сделать».
Вот так-то =)
только не пойму, почему опять отдельно от мира спекки?
acidrain
18.05.2005, 19:07
;Программа CALL fun1 .......... .......... ;Область переходов fun1 JP _fun1 fun2 JP _fun2 fun3 JP _fun3 fun4 JP _fun4 .......... .......... ;Здесь сама функция fun1 .......... .......... Всего функций - неограничено Длина команд - 6 байт
Ну, а дальше - версия 1.11 ядра системы, прийдется все include менять? =)
Я когда писал - торопился на работу, в связи с чем ошибся там надо проще:
call dosbase+openfile ; что составляет три байта %) и количество ф-ций не ограничено :) (ну, скажем до 65536/3 ~ 22 тыс. ф-ций) Если кнечно асм реальные числа может считать - тогда вообще нет ограничений, теоретически :cool:
acidrain
18.05.2005, 20:13
Хм..я вообще предполагал делать сборку "для себя". Причём тут include? Они будут всегда на месте ведь адрес CALL то будет определён в качестве стандарта - навсегда. Как ты насчитал 3 байта если один CALL 3 байта занимает? В моём варианте вызов функции - это вызов в области перехода, где номер функции является смещением через 3 байта (потому, что там JUMP). По моему проще не бывает и регистры для определения номера функции (и вообще) не используются. Я сам на практике знаю, что если использовать регистры при вызове функций ядра то иногда просто не знаешь как передать параметры в функцию, чтобы это было не накладно. Если есть желание что обсудить, то пишите в приват, почту или в асю. А то тема так разрослась, что скоро людям не интересно читать будет.
А релоцируемость? Как ты собираешься адрес делать фиксированным? Поэтому и используют некую базу, прибавив/убавив от которой получим адрес фызова функции. А насчитал элементарно, как и ты, впрочем =)
Я не знаю скоко салл занимает в памяти (уж лет так 10 не писал для спеки ничего =)), а знаю, что jp addr - ровно 3 байта, так и посчитал. =)
Я постучался в аську :)
Не знаком с вашей публикацией. :(
Гибкое изменение - это возможность в области, где прописаны JUMP-ы, менять адрес перехода (или вообще например - RET поставить).
Эта область нужна только если будут меняться адреса функций уровней ОС от версии к версии, для обеспечения совместимости адресов вызовов.
Так как все-таки на счет расширения количества функций с применением прямого вызова?
Кстати в оправдание (может быть) call смотрите вложение.
Я предлагал вроде втроить их, но это не значит, что их надо использовать. По идее программе полная свобода. А выбор типа интерфейса и используемых программ производить самому на этапе сборки или подготовки к использованию.
И вообще, мне как-то ОС видиться больше в статическом исполнении (типа держишь в ОС, что тебе надо). Там я ещё писал, из-за переключения контекста надо делать выгрузку области программ. Поскольку держать уровни ОС там накладно (размеры) и невозможно (выгрузка области), то есть пока только идея расположить ОС в области ПЗУ или теневом ОЗУ (чтоб не занимать память в "области программ" вынести необходимые уровни ОС в другое место). Хотя можно конечно в виде программ в страницах использовать, но вот как эта программа будет обрабатывать данные из других страниц?
На критику "по делу" не обижаюсь - это неоценимаю помощь.
Если писать нормальную ОСЬ - однозначно надо пихать ее в ПЗУ (или теневое ОЗУ с 0). Для работы с другими страницами создается некий стандарт (хотябы по принципу, предложенному мной) и приведенную тут http://zx.pk.ru/showthread.php?t=507&page=7&pp=10 или то что привел Griv там же.
При этом все программы под ОСЬ, должны будут придерживаться этого стандарта.
Насчет статичнского-динамического исполнения. Тут надо сделать возможность указать при сборке что в статике компилировать, а что в виде подгружаемых модулей.
Скажем драйвер стандартного экрана - сразу к ядру присобачивается, драйвеа мыши, клавиатуры. А вот драйвер какого-нибудь экрана 320х200х256 - он может либо быть встроен в ядро, либо вообще исключен (если у юзера нет такого режима), либо откомпилирован в виде отдельного модуля, подгружаемого по мере надобности.
Еще по поводу RST-JUMP и системных вызовов. Однозначно в ОСЬ должна быть ОДНА точка входа. Причем для вызова ОС использовать надо call.
call #SYSTEM
db num_func
db param1
db param2
...
Тогда во-первых приятно писать, а во-вторых можно использовать call необходимо, чтобы можно было саму ОС запихать в любую часть памяти
Все это изврат, если честно. Если у нас будет динамическая линковка ("DLL"), то эти проблемы с релоцируемостью отпадают.
Все это изврат, если честно. Если у нас будет динамическая линковка ("DLL"), то эти проблемы с релоцируемостью отпадают.
Так помоему речь и идет о спецификации на память, чтобы реализовать DLL, Reloctable и т.д.)
А тогда нафига таблицы переходов??? ОС грузит бинарник, попутно по меткам в нем проставляя все адреса. Достаточно простой таблицы адресов для "подсовывания" в бинарник.
acidrain
19.05.2005, 23:12
Еще по поводу RST-JUMP и системных вызовов. Однозначно в ОСЬ должна быть ОДНА точка входа. Причем для вызова ОС использовать надо call.
call #SYSTEM
db num_func
db param1
db param2
...
Тогда во-первых приятно писать, а во-вторых можно использовать call необходимо, чтобы можно было саму ОС запихать в любую часть памяти
Если имелся ввиду мой коммент, то я писал о библиотеках (некоторые на пц вариант опсывают их длл-ками), а про вход в ось - он точно должен быть один, как на амиге ;)
И почему отпадают проблемы с релоцируемостью? Если в систему все либлы релоцируемы, а ваша прога с фиксированного адр. должна пускаться, а ее место уже занято под, например, системные переменные - то тогда и вся ось в сад из-за корявого прогерра? В нормальной ос не должно быть прог с фиксированными адр. кроме единственной точки входа в ось. А саму ось, при необходимости мона будет в верхние страницы запхать, ну вдруг кому преспичит? ;) ПЗУ- в сад, на стандартном спеке без переделки возможно теневую страницу озу с 0го адр. выставить? Тогда о чем может быть речь?
Если в систему все либлы релоцируемы, а ваша прога с фиксированного адр. должна пускаться
Не должно такого быть. И точка. А точка входа в ось тоже не обязана быть фиксированной. Можно "на лету" при загрузке подставить релокейшны.
А саму ось, при необходимости мона будет в верхние страницы запхать, ну вдруг кому преспичит? ;) ПЗУ- в сад, на стандартном спеке без переделки возможно теневую страницу озу с 0го адр. выставить? Тогда о чем может быть речь?
Я думаю, что ОС должна мочь собираться и для работы из теневой страницы и для работы из верхней страницы ОЗУ. А если все ограничивать только стандартом 128 - то ничего хорошего не будет.
То есть ОС должна работать и в стандарте и в расширенных компах типа АТМ.
acidrain
20.05.2005, 10:25
Я думаю, что ОС должна мочь собираться и для работы из теневой страницы и для работы из верхней страницы ОЗУ. А если все ограничивать только стандартом 128 - то ничего хорошего не будет.
То есть ОС должна работать и в стандарте и в расширенных компах типа АТМ.
Дык, я об том же =)
acidrain
20.05.2005, 10:28
Не должно такого быть. И точка. А точка входа в ось тоже не обязана быть фиксированной. Можно "на лету" при загрузке подставить релокейшны.
Alex/AT вне форума Добавить к репутации Alex/AT Пожаловаться на это сообщение
Точно, как на амиге =)
Вообще этот тред стал напоминать нечто вроде "докажи эсиду то, о чем он и говорит, а то этот тупарь (эсид) умничает много говорит то, о чем мы и так знаем" =)
Может более конструктивно будем общаться и вникать в то, что пишет другой человек? =)))
Ничего личного - это у меня сложилось такое впечатление 8)
Цитирую:
В программирование на ассемблере в объектно-ориентированном стиле
особенных сложностей не доставляет. В вызываемый метод-функцию просто
передаётся указатель на объект. А как быть, если имеем дело с виртуальными
функциями? Тут к каждому объекты добавляется ссылка на таблицу адресов
виртуальных функций. Продемонстрирую на примере:
; Создадим объект, на стеке. Для большей наглядности того, что статических
; адресов нигде нет.
ld hl, size_of_object - 2
add hl, sp
ld sp, hl
push hl
ld hl, object_virtual_table
ex (sp), hl
push hl
call object_constructor
pop hl
....
; Теперь используем объект. В данную функцию передаётся указатель на объект
; типа созданного ранее, или унаследованный от него.
; HL = указатель на объект.
function:
push hl
call some_virtual_function
pop hl
call some_non_virtual_function
....
; вызванная функция-метод, общая для всех унаследованных объектов
; просто перенаправляет вызов через таблицу виртуальных функций
some_virtual_function:
ld a, object_function_no * 3
jp call_virtual
; тело виртуальной функции конкретного объекта
some_virtual_function_body:
....
ret
; тело невиртуальной функции
some_non_virtual_function:
...
ret
; таблица виртуальных функций конкретного объекта
object_virtual_table:
jp some_virtual_function_body
object_function_no equ 0
jp some_virtual_function2_body
object_function2_no equ 1
jp some_virtual_function3_body
object_function3_no equ 2
...
; вспомогательная процедура, для вызова через таблицу виртуальных функций
call_virtual:
push hl
add a, (hl)
inc hl
ld h, (hl)
ld l, a
adc a, h
sub l
ld h, a
ex (sp), hl
ret ; 93 такта от some_virtual_function
Я предполагаю, что указатель на объект передаётся всегда в регистре HL,
а в регистре AF никогда и никаких аргументов не передаётся.
Итого получается, что на вызов невиртуальной функции-метода требуется
всего 27 тактов процессора (call + ret), а на вызов виртуальной функции
аж 120 тактов, вместе с первым call и последним ret. И ещё регистр AF
нужен.
Кроме того, см: http://cdwalk.narod.ru/modules.html, http://cdwalk.narod.ru/ide-driver.html.
Предлагается в качестве стандарта, независимо от каких-либо ОС.
В настоящее время планируется COM-подобная (component object model)
система, с немного другой структурой модуля.
Если есть желание, то заходите.
Да ты и сам заходи, хоть изредка!
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot