а чем пример с WORMS не яркое опровержение тобой предсказуемых "тормозов"?Цитата:
Сообщение от CHRV
Вид для печати
а чем пример с WORMS не яркое опровержение тобой предсказуемых "тормозов"?Цитата:
Сообщение от CHRV
я имею в виду модульность на этапе компиляции, а не только на этапе выполнения. см. соответствующий тред в ветке про программированиеЦитата:
Сообщение от SfS
туда же. но надо чтобы был обеспечен какой-либо минимальный набор аппаратуры на которой бы все запустилосьЦитата:
Сообщение от SfS
дык одних алгоритмов синхронизации штуки 4 только %) (почему запомнил- слегка "поплавал" на них на экзамене %))Цитата:
Сообщение от SfS
почему нет? вчера (сегодня уже то бишь) с тов. GriV'ом перетирали данную тему. пришли к такой идее. процессы юзают только верхнюю память в страницах, нижняя память целиком и полностью принадлежит системе. каждому процессу выделяется какой-то объем памяти в странице, который он юзает как локальную кучу и адресует непосредственно. если же ему надо дофига памяти, он обращается к менеджеру, который выделяет память в других страницах и возвращает указатель на _дескриптор_ блока памяти. при дальнейшем доступе к выделенной памяти диспетчер выделяет окно в нижней памяти и перекидывает туда кусок из верхней. после записи (если разрешена), данные копируются обратно. хотя и накладно по ресурсам, зато получаем сразу кучу плюсов- защита памяти, нет необходимости в резидентах, возможность свопинга.Цитата:
Сообщение от SfS
надо будет посмотреть. а также стандартные алгоритмы (при условии что удастся найти элементарные команды)Цитата:
Сообщение от lvd
форк по большому счету не обязан копировать все данные родительского процесса. делаем как в одной ОСи: есть функция под названием vfork, которой на входе подается флаг чего надо копировать. если нам нужна, грубо говоря, рабочая нить, зачем нам тянуть все открытые файлы и память? достаточно скопировать дескриптор и стек, а выполняться будет родительский код. т.е. у процесса из своего может быть только стек и дескриптор (иначе никак), а все остальное он может и не иметь.Цитата:
Сообщение от lvd
копирование дескрипторов файлов заключается в увеличении числа ссылок открытого файла (попробуй одновременно родительским и дочерним процессом читать из файла- они оба изменяют указатель позиции). копирование памяти можно выполнять только после внесенных туда изменений (copy-on-write). так что пространства для творчества- хоть отбавляй
видно, человек проникся идеологией С/UNIX :)Цитата:
Сообщение от SfS
VFS и таблицы драйверов с виртуальными (практически) функциями- самое то что надо.
имею единственное предложение по формату системных вызовов: делать приложения релоцируемыми. т.е. загрузили их туда, где выделили память, настроили адреса под конкретное значение, попутно занеся адреса нужных системных вызовов. кернель сокращается с 3 до 2 байт на точку входа (хотя это могут быть не только функции, а также переменные, константы), нет лишних тактов, все делается самым быстрым способом.
посмотри на структуру любого нормального обработчика прерываний:Цитата:
Сообщение от CHRV
push all_registers
do_smth
pop all_registers
ei
ret
а теперь на структуру диспетчера задач при вытесняющей многозадачности:
push all_registers
change_sp_ptr
pop all_registers
ei
ret
похоже слегка, не так ли? %)
единственное, на что будут "лишние" такты- это непосредственно выбор кандидата на выполнение. алгоритмов этому куча, можно выбрать любой.
Дело в тормозах не потомучто обработчик-распределитель долго работает, а потомучто фоном еще куча фигни не нужной выполняется.
Конечно есть задачи которые нужны, там типа часов, АУ плеера, так пусть они и вставляют свой вызов в обработку прерывания.
А например мне нужно простейшая задача: редактор+ассемблер+спрайтэ дитор, и я не хочу чтобы они в фоне еще там чего то квакали :smile: . Но переключаться мануально между ними я очень хочу!
Да! серьёздно разраслась тема, и правда уже пора писать техзадание, даже на основе того, что здесь уже выложено.
Коментарии по ходу чтения:
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).
Какой например? По-твоему, если в винде висит полсотни процессов, то каждый из них ужирает кусочек времени? Нифига, они просто висят и ждут, когда их разбудят. По крайней мере не знаю как в винде, а в амигаос именно так. Всем рекомендуется ознакомиться :) (а то блин форки на спектруме собрались делать!)Цитата:
Сообщение от CHRV
Ну и отлично. 3 задачи висят в памяти. Работаешь с редактором - его экран показывается, сообщения от мыши и клавы идут ему. В это время спредитор или асм спят - их экран не активен и сообщений ему не идёт, шедулер их не запускает.Цитата:
А например мне нужно простейшая задача: редактор+ассемблер+спрайтэ дитор, и я не хочу чтобы они в фоне еще там чего то квакали :smile: . Но переключаться мануально между ними я очень хочу!
Вытесняющая многозадачность не имеет отношения к INT/NMI. Зато вот простейшие действия типа критических частей (в самих ф-циях оси, например!) вызывут кучу проблем при НМИ и всего лишь DI/EI при INT. А что касается железных доработок - уж лучше контроллер прерывания поставить, чем генератор НМИев каждуй миллисекунду (хм - а может каждые 100 тактов сразу?).Цитата:
Сообщение от Corpsegrinder
К предложенному ядру RTK вытеснение задач добавить - как два пальца... Если надо - сделаю.
respect! внес здравое зерно в дискуссию. а как насчет выделения памяти и тд?Цитата:
Сообщение от Alex/AT
Кто запрещает в схему генерации NMI от таймера (котрой стандартно нет, кстати) добавить порт, доступный только из ОС, который может запрещать-разрешать генерацию NMI ? Таким образом программы пользователя не смогут завесить ОС, а сама ОС для выполнения атомарных действий будет запрещать генерацию NMI.Цитата:
Сообщение от lvd
Про выделение памяти уже думал... Если бы была возможность переключать не только верхнюю страницу - все бы было здорово. А так напрашивается только копирование... Или еще возможна сегментация области кода - т.е. выделяется 4-8 кб под код, если программа хочет еще - она говорит ядру - "скопируй мне новые 4-8к вот отсюда, и запусти их с адреса такого-то". Имхо разумный вариант.
З.Ы. Следующую "preview" ZX-Worms project 2 (с ядром на RTK) положил в "Игры".
P.P.S. Если речь идет о С/C++ и совместимом рантайме (*nix) - то можно C-ядро держать в несвапабельной странице...
Вообще-то здравая мысля была - оставаться в рамках обычного 128к спекки. А если так, то НМИ отдыхает. А если говорить о хардваремодах, то тогда КУДА логичнее контроллер прерываний нормальный, а не нми.Цитата:
Сообщение от SfS
Кстати, завесить нми - как два пальца об асфальт - стек в ПЗУ и прощай...
fork- всего лишь метод создания процесса. а диспетчеризация- дело другое.Цитата:
Сообщение от lvd
ну чтобы не усложнять задачу, реализовать добровольный пропуск кванта. или слать сигналы SIGSTOP/SIGCONT для останова/продолжения работы процесса. хотя все равно накладно. уж лучше пускай процесс сам себе ставит низкий приоритет и уступает квант.Цитата:
Сообщение от lvd
ну авторство не только мое %)Цитата:
Сообщение от Corpsegrinder
в нижней памяти стоит разрешать только библиотеки располагать. да и то по требованию. по умолчанию их можно пихать в верхнюю же память и вызывать через менеджер. потому как тогда можно будет многоразово использовать код и следовательно экономить драгоценную нижнюю память
полностью согласен. это уже детали реализации. будет настраиваемый код- будет возможность поддержать что угодноЦитата:
Сообщение от Corpsegrinder
зачем уложнять, вводить систему? делать идентификатором физический адрес объекта. решается проблема унификации и упрощения доступа.Цитата:
Сообщение от Corpsegrinder
кста, DC- относится к графической части окошек %)
одно, на мой взгляд самое большое, преимущество одной системы на несколько одновременно работающих приложений- система обмена информацией (IPC). начиная от каналов и сокетов и заканчивая буфером обмена.Цитата:
Сообщение от Corpsegrinder
имея на руках готовый код, можно замерить затраты времени на переключение контекстов и диспетчеризацию. а потом строим функцию реакции системы в зависимости от частоты прерываний (потому как скорость процессора от них не меняется). экстремум этой функции и будет оптимумом %)Цитата:
Сообщение от lvd
пришпиливаю исход модуля работы с процессами (юзался в одном из вариантов ChAOS). обвязку не прилагаю, компилять и запускать смысла нет %) код страшный, так что просьба не пугаться
Так а всё таки как ты представляешь себе например ACEdit адоптированный к такой среде, неужели текст по несколько киолбайт только обрабатывать?Цитата:
Сообщение от Vitamin
Без размещения кода, который колбасит текст в других нежели редактор страничках, в нижней памяти я себе это не представляю, пусть бы даже и он(код) копировался каждый раз из верхней памяти по необходимости в нижнюю.
ну и что, я про саму идею. Физический адрес - не идентифицирует уникально нужный код, поскольку код может лежать в разных страницах в разное время запуска процесса, а может и вообще не быть запращиваемого кода, когда библиотека не загружена.Цитата:
зачем уложнять, вводить систему? делать идентификатором физический адрес объекта. решается проблема унификации и упрощения доступа.
кста, DC- относится к графической части окошек %)
Вот это и есть самое главное преимущество!!! Возможность не нажимая на reset делать разноплановые задачи и иметь возможность перетаскивать данные из одной задачи в другую, будь то текст, графика или просто синхронизирующие работу разных задач сообщения. Например для редактирования текстов в общем случае не нужно всё процессорное время каждую единицу времени и его можно занять например компиляцией.Цитата:
одно, на мой взгляд самое большое, преимущество одной системы на несколько одновременно работающих приложений- система обмена информацией (IPC). начиная от каналов и сокетов и заканчивая буфером обмена.
при работе с большими кусками памяти резидет обязателен. имхо, лучше его оформить в виде разделяемой библиотеки. ведь в чем заключается, по большей части, работа с данными? вывод на экран, пересылка, вставка, удаление. т.е. вполне стандартный набор процедур. и велика вероятность, что не только одна программа будет выполнять такие операции. а с процесса по резиденту- уменьшается объем доступной памяти и увеличивается анархия %)Цитата:
Сообщение от Corpsegrinder
процесс описывается своим дескриптором. все остальные объекты, которые необходимо описывать, лежат в нижней памяти. отсюда и однозначное наименованиеЦитата:
Сообщение от Corpsegrinder
вот с этого я и начинал!!! большую часть времени программы проводят в ожидании, почему бы не занять это время полезным делом? а насчет вытесняющей/коперативной многозадачности- чисто дело реализации. хотим вытесняющую- диспетчеризацией будет заниматься процессор. хотим кооперативную- нехай юзверь щелкает задачами. правда в таком случае теряется интерактивность. как компромисс- введение интерактивного процесса, не активного в данный момент, в "кому"- пускай просто подает признаки жизни и реагирует на критические событияЦитата:
Сообщение от Corpsegrinder
10 страниц мне даже читать не хочется...
2Moders> надо было с самого начала чётко ограничить тему техническим заданием и конкретными вопросами, построение операционной системы не делается одним предложнием...
Мы с витамином разработали схему, которая позволяет чрезвычайно эффективно работать с любой памятью (теоретически,чтобы ось реально работала даже на компах с 16кб памяти), от 16 кб до нескольких десятков МБ, если надо могу спецификации закинуть...
Касательно диспетчирезации задач тоже есть наработки...
Давайте уже закрывать тему и открывать более конкретные, чтобы не валить в один котёл и дрова и колбасу...
Вообщето была мысля сделать модульную систему. Минимум для запуска - 128К стандарт. А навороты все - как отдельные модули грузятся. DI: jr -2 и капец. Прога висит. Хотя помоему - решение должно быть комплексное - если уж делать контроллер прерываний - то почему туда и таймер для NMI не всунуть ? На любом микроконтроллере можно реализовать. Или еще вариант - NMI от клавиатуры - это у многих уже есть (MAGIK родимый).Цитата:
Сообщение от lvd
И много программ со стеком в ПЗУ работать смогут ? Я к тому что речь идет о реальных программах, а не о спецподелках чтобы NMI завесить. Скажем отлаживаешь программу - а она возьми и повисни. Лезешь в деспетчер задачь и снимаешь ее. Или еще вариант - пошагловая отладка.Цитата:
Сообщение от lvd
Что касается памяти - то вот что придумалось за выходные.
Что касается памяти - то вот что придумалось за выходные.
Извиняюсь - не отправилось сначала.
В общем во вложении - некоторые наброски по управлению памятью. В каталоге doc есть файл с "Организация памяти.pdf" - там нарисованы некоторые соображения.
Реальные программы, зависнув, всю память запортят, и нми опять же не спасёт. Это тебе не винда или линь.Цитата:
Я к тому что речь идет о реальных программах, а не о спецподелках чтобы NMI завесить. Скажем отлаживаешь программу - а она возьми и повисни. Лезешь в деспетчер задачь и снимаешь ее. Или еще вариант - пошагловая отладка.
Пошаговость - опять нми не причём, так как оно по фронту, в то время как инт - по уровню.
Уважаемые разработчики, взгляните, какую работу проделал Spectrum! Неужели никто не оценит?
P.S. Я к сожалению не разработчик, и могу оценивать указанную работу только с точки зрения логики, структуры документа и методологии проекта. Но это наверно не так интересно.
прочитал больше половины дока - радует одно рвение и объем проделанной работы.Цитата:
А ОС (среда) - как инструмент для достижения поставленных задач.
Но, мое мнение , мне б такая ось не подошла =) Одним словом - не то, что я ожидал...
Без обид плиз!
Получится фарш.:)Цитата:
Сообщение от spectrum
Да да, в начале 90-х на спекки работали динозавры, :eek: к счастью почти все они вымерли.Цитата:
Сообщение от spectrum
1991 (начало разработки 1989).Цитата:
Сообщение от spectrum
1991 (Profi), а вообще то CP/M это еще начало 80-хЦитата:
Сообщение от spectrum
это что за зверь?Цитата:
Сообщение от spectrum
??? что конкретно?Цитата:
Сообщение от spectrum
Скорее в пустоту. Хорошее словечко «мыслевытекание» :DЦитата:
Сообщение от spectrum
Вы, что всегда делали "не пойми для кого"? ;)Цитата:
Сообщение от spectrum
Надо указывать сколько сейчас, а то если 0 или 18ч то задачка может не иметь решения.:DЦитата:
Сообщение от spectrum
Сколько угодно:Цитата:
Сообщение от spectrum
http://members.tripod.com/~piters/zx.htm
http://user.tninet.se/~vjz762w/
http://members.chello.se/erkan/plus3/
http://8bitorbust.info/
http://myweb.absa.co.za/dan_antohi/
Не обижайтесь: прочитав ваше сравнение с пригоровлением мяса, я решил что вы шутите.Цитата:
Сообщение от spectrum
Просмотрел. Впечатляет.
Одно "но"! (Прошу не обижаться на критику.)
Выкинь нафиг интерфейсы пользователя из ОС.
Это должны быть внешние программы. Однозначно. Зачем юзеру, который пользуется ГУИ командный интерпретатор ? Зачем к ОСи присабачивать нортон-подобный довесок ? Пусть все это лежит на диске. Надо - загрузил. Надо - выгрузил.
В остальном - покритикую после подробного прочтения.
Уважаемый спектрум!Цитата:
Сообщение от spectrum
=)
Как я уже говорил - не дочитал. Например, из двух вариантов вызова системных функций второй меня устроит больше, а rst #xx - утопия, хотя и экономия памяти (? зачем, спрашивается, если, например 256 кб?) по тому, что ограничиваем сами себя - потом будем нагромождать всякие патчи для оси тп лишь бы добавить либлу или еще чего. Потом многозадачность - это для меня основа оси. Резиденты -это что вообще такое? Процессы? Или скрытые части проги, тихо затаившиеся, как в мониторе стс, например =)? Зачем они нужны?
А остальное - после, как дочитаю ;)
А я все-таки за rst xx, db xx... Это структурирует программу, легче запоминается, легче воспринимается другими (на случай, если кто-то будет доделывать твою прогу).Цитата:
Сообщение от spectrum
А зачем тогда ОС, если все и так пишут CALL. Может возьмем кучу программ и будем использовать их возможности (CALL)?Цитата:
Сообщение от spectrum
Шутка конечно.
Но прямой CALL мне не нравится. Представь, сколько их будет? Даже если и будет отдельный файлик в котором они прописаны.
Да, и на счет расширения как поступать? Сделать таблицу на x байт длиннее на будущее? А если опять не хватит, что потом? Нужно все равно как-то ограничивать кол-во функций. Хотя бы по тем разделам, которые ты предлагаешь.
Опять 25. Я уже выкладывал по амижным библиотекам инфу? Так вот, умные люди там сделали так: В инклудах хранится смещение, которое перед вызовом функции записывается в виде (макрос) CALLINT LockPubScreenЦитата:
Сообщение от spectrum
Где:
callInt - макрос, на самом деле заменяется командой jsr /1(a6);
LockPubScreen - это смещение, заданное заранее (например, LockPubScreen EQU -277 - адрес от "фонаря" - не проверяйте ;) ).
Результат этого макроса таков:
В итоге получается, что происходит вызов функции со смещением -277 от адреса прописанного в адресном регистре А6. При всем при этом, изменение адреса расположения функции в самой библиотеке не несет за собой переделку всех заранее установленных смещений.Код:jsr -227(a6)
Отсюда возникает вопрос - ЗАЧЕМ нужен подход (который пытался применить Shaos в разрабатываемой им для спринтера оси), когда идет вызов по НОМЕРУ функции, это ведь чистой воды бред. Или я опять не прав? Причем я пытался это разжевать И Shaos, но видимо мои речи не столь понятны окружающим, как мне самому ;)))
Тут я, увы, вообще не понял о чем Вы говорите. Причем тут версии оси или либлы? Я говорил за общий подход по вызову библиотечных (или ядренных;) ) функций. Предложил упрощение.Цитата:
Сообщение от spectrum
И, пожалуйста, не называйте меня на Вы, ок? =)
Не стоит забывать, также, что амига ось полностью релоцируема, кроме жестко зафиксированного адреса $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
В соседнем форуме:
Вот так-то =)Цитата:
Mac Buster
PostPosted: 03 Feb 2004 16:43 Post subject:
Quote:
Все таки по поводу ОС несколько слов:
- стоит ли поддерживать фат для жестких дисков?
Очень не хочется, но в виде отдельного модуля файловой системы придется поддерживать эту fs.
Quote:
Может использовать какойнить другой формат попроще, что там в Амиге?
У Амиги свои файловые системы и большинство из них значительно сложнее fat.
Quote:
Ибо FAT мне важен если честно только на флопах, чтобы туда-сюда таскать проги...
Единственное достоинство fat - распространенная поддержка, она часто используется в качестве промежуточной при копировании данных из одной системы в другую.
Quote:
Обрисуй всетаки что там у тебя ожидается?
Ничего особенного, как у всех - 64 задачи, семафоры, очереди, сообщения, библиотеки функций, перехват/дополнение/замена функций Тип ядра - модульный, т.е. после компиляции он дополняется модулями файловой системы, базовыми библиотеками, интерфейсом и т.д. Получившийся непрерывный файл записывается на диск первым сразу после начального загрузчика (возможно последний будет включать в себя простейшую систему управления запуском операционной системы - режим экрана, ресурсы, и прочее).
Есть идея сделать следующее - так как обращение к функциям связано с некоторыми затратами времени на копирование аргументов, можно сделать некоторые функции в виде релоцируемых модулей, которые по запросу приложения могут быть скопированы в 64К отведенных задаче для самостоятельного максимально быстрого использования. Но это дело далекого будущего Из раздела «а почему-бы не сделать».
только не пойму, почему опять отдельно от мира спекки?
Ну, а дальше - версия 1.11 ядра системы, прийдется все include менять? =)Цитата:
Сообщение от spectrum
Я когда писал - торопился на работу, в связи с чем ошибся там надо проще:
call dosbase+openfile ; что составляет три байта %) и количество ф-ций не ограничено :) (ну, скажем до 65536/3 ~ 22 тыс. ф-ций) Если кнечно асм реальные числа может считать - тогда вообще нет ограничений, теоретически :cool:
А релоцируемость? Как ты собираешься адрес делать фиксированным? Поэтому и используют некую базу, прибавив/убавив от которой получим адрес фызова функции. А насчитал элементарно, как и ты, впрочем =)Цитата:
Сообщение от spectrum
Я не знаю скоко салл занимает в памяти (уж лет так 10 не писал для спеки ничего =)), а знаю, что jp addr - ровно 3 байта, так и посчитал. =)
Я постучался в аську :)
Так как все-таки на счет расширения количества функций с применением прямого вызова?Цитата:
Сообщение от spectrum
Кстати в оправдание (может быть) call смотрите вложение.