Понимаю, что с Вашей точки зрения всё выглядит примерно так: Человек решил написать
очередную ОСь, но в силу некомпетентности ли, неопытности ли или невежественности, делает всё как-то не так, не по-человечески.
Замечу, что я это понимаю. Дело в том, что я именно не хочу пополнять
пухлый список существующих операционнок своей собственной.
Практически все операционки, начиная с (де-факто) UNIX, приложениям всегда представляются набором библиотек функций и прерываний. Т.е. для приложений они (операционки) видимы. Всё выглядит как типичное: Пришло частное лицо (приложение) в государственную инстанцию (операционное окружение) и начало делать запрос у чиновников на получение доступа к архивам или документам.
В моём случае plutOS должна быть
операционкой-невидимкой, чтобы приложения её не видели. Выглядит это как сказочный дворец из сказки "Аленький цветочек": Хлопнул в ладоши и невидимая сила что-то да сделала.
Понимаете, у человека (меня) есть голубая мечта построить такой "сказочный дворец" в исполнении операционной среды. Подчёркиваю,
Операционной Среды (ОС), а не Операционной Системы.
По поводу использования портов ввода-вывода и сегментов, о которых нужно забыть и забить, как о рудиментах DOS. Да, я знаю, что всё проецируется в память. У процессора 6802 в Dendy не было никаких портов. Насколько я помню, порты -
ноухау Intel при разработке ещё первых i4004 из-за недостатка адресного пространства. Не обижайтесь, но я в курсе на счёт всего этого. Это, как Вы предполагаете, не моя дремучесть на счёт положения вещей. Это моё упрямство!
Итак, попытаюсь сейчас быть предельно краток и с нуля описать задумку:
1. Мне не нравится, что в x86 деление на ноль оформлено как прерывание с вылетом программы. (Если утрировать, получается Голливуд: комп сделал ошибку и всё кругом начало взрываться!). Деление на ноль не такая критическая ситуация. Так же, как и в инструкции BOUND. Поэтому менеджер в первую очередь при всех исключениях от делении на ноль и bound должен просто установить флаг OF-приложения и возобновить его работу со следующей инструкции. В моём понимании - устранить рудиментальный баг процессора;
2. Так-как вся память (страницы по 4Гб) не виртуальная, а формальная. Тем самым, в Windows мне надо добиться, чтобы все четыре сегмента (DS/ES/FS/GS) указывали только на один регион формальной памяти 4Гб. Чтобы чтение/запись по любому адресу сразу вызвало исключение с передачей управления моему менеджеру. Мой менеджер сам разбирётся по префиксу, куда формальные 4Гб обращены;
3. Таблица прерываний для обработки событий имеется, но не стандартные 256 от INT. Существует формальный контролер прерываний - регион памяти в 4Гб разделённый на 256 параграфов по 16Мб.
Тем самым, INT 0x21 - не вызов прерывания DOS, а исключение с проверкой наличия события в потоке #33. Т.е. если поток #33 настроен как буфер консоли (клавиатуры), то он среди тех 4Гб займёт параграф 0x21000000..0x21FFFFFF.
И INT 0x21 вернёт флаг OF, если события консоли имелись. Тем самым приложение сможет сразу прочитать до 8Mb (unicode) текста. А чтобы преодолеть ограничение в 16Mb, можно просто настроить следующие параграфы на консоль.
Тогда INT 0x21..0x22 будут дублировать одно. И вопреки логике, на те 256 векторов нельзя повесить свои обработчики событий. Приложение обязано само вызывать INT. Чтобы периодические INT команды оповещали мой менеджер, что тот процесс не завис. Предположите, что INTO примерно как Ping-Pong работает;
4. Операции LOCK/CLI/STI работают как и INT - не по назначению. LOCK служит для доступа к настройкам сегмента.
Так mov al,gs:[0] и lock mov al,gs[0] - совершенно разные команды. Первая - вернёт (после исключения) в AL байт из формальной памяти (девайса). Т.е. код клавиши и т.п. Вторая же - вернёт в EAX (помните, ширина слова - опция) служебную информацию из структуры с настройками сегмента GS.
Поэтому так же и mov es,ax и lock mov es,ax - тоже разные. Первое выбирает один из 4млрд сегментов. А второе - указывает, что EAX - ссылка на строку с именем девайса, который должен теперь обслуживать тот сегмент;
5. Операции CLI и STI - операторные скобки. Внутри которых машинный код превращается в скрипт. С помощью динамической компиляции такой x86-скрипт адаптируется и внедряется в системный процесс. Да, хоть на уровне ядра! Тем самым, можно вешать глобальные хуки на что угодно. Правда, подчеркну слово
адаптируется.
Что означает, что вся работа с памятью (lods или mov dx,es:[ebp]) транслируется в call-вызовы. Тем самым, ограничивая
мятежный код. И если es указывал на GDI, то все stosd-инструкции заменятся на SetPixel(hdc, x ++, y, eax) и т.д. Причём, Jcond переходы в скрипте тоже корректируются.
Какрас по этому пункту я не голословен и на моей страничке можно скачать исходный архив проекта на Си с рабочей демонстрацией. А также html-dom дизассемблер этих x86-скриптов;
6. Как я писал выше, чтобы воспроизвести видео, нужно построить из сегментов цепочку. То же самое можно сказать про всё остальное. Например, если WinRAR-девайс назначается на сегмент как монитор над другим сегментом, то при попытке читать данные из WinRAR-сегмента запустится архивирование данных из приклеплённого сегмента, прежде чем в WinRAR-сегменте появится содержимое архива. Если же на сегмент назначается FASM- или Pascal-девайс, то, как уже понятно, чтение из этого сегмента запустит компиляцию до появления готового к исполнению кода;
7. Допустим, plutOS запущена в Windows и доступна через диск B:, как описывал выше. Чтобы все эти WinRAR-, Pascal-, FASM- и XVID-, OpenGL- и GDI-девайсы заработали, необходимо иметь их в виде dll-плагинов в папке менеджера. А также ini-прописку в конфигурации симулятора plutOS. Без этого приложению при попытке закрепить сегмент за девайсом будет возвращаться флаг OF и всё.
P.S.:А что такое plutOS вообще?
Poly-Layered Utilization Twisting Operating System - Операционная Система с Использованием Искривлений Полислоя.
Иначе говоря, использование многослойной памяти через искривление операционки. Типо так.
Короче, говоря по-русски, смысл в том, что операционку
колбасит.
Как видите, само название говорит само за себя! Оправдывая и тормоза, и сегменты, и порты!
А если серъёзнее, то нужно разобраться с Poly-Layer.
Ещё на самом первом шаге, описанном постом выше, разработки концепции я ввёл термин
полимерной ячейки памяти.
Ввёл, когда понял, что при исключении ширину операнда можно интерпретировать опционально.
Т.е. movsd и movsb уже не будут переносить двойное слово или байт соответственно. И в той ещё первой структуре первые 64кб адресовали бы не 16384 rgba-пиксела, как ожидалось, а все 65536. Каким образом - читайте в конце.
В полимерной памяти d->(d)ata, а b->(b)ase. Т.е. movsd копирует данные из одного сегмента в другой. Причём ширина слова данных не определена. Под d может скрываться и byte, и word и, и dword, и qword, и структуры POINT или RECT. Короче, что угодно!
А вот чтобы определить тип (класс) переносимых данных, нужно переключить эти ячейки памяти на нужный слой. Отсуда и термин Polylayered Cell.
Так, если стандартно byte[2] и byte[3] являются соседними половинками, которые объединяются в word[1]. То в полимерной памяти, как Вы уже догадались, это не так. И lodsd может вернуть значение в eax, если это видеопамять (rgba). А может и просто в ax, если это unicode буфера клавиатуры.
Причём, в видеопамяти mov eax,[4] и mov eax,[8] - это не чтение пиксела #1 и #2 соответственно как ожидалось бы. А чтение пиксела #4 и #8 соответственно. Т.е. во время исключения адресация на пиксел
автоматически выравнивается! Пусть хоть видеорежим - 24bpp, хоть 16bpp. Хоть даже CGA режим 320x200, где 4 пиксела на байт. Вектор адреса всегда ссылается на определёёный пиксел.
То же самое и с outsb или outsw. Нету никаких составляющих байтов одного слова.
Но, зачем же я использовал ширину операнда лишь как опциональный ключ? Неужели префиксов сегментов и lock мне мало?
Просто я в концепции заранее подчеркнул, что само приложение, а вернее, сам разработчик этого приложения уже знает, что это не ширина операнда, а некий постфикс. Вот такая префиксно-постфиксная организация программирования.
P.P.S.:Как уже сказано, я лишь хочу посмотреть, оправдано ли меня критикуют остальные (все) разработчики операционнок за такую свистопляску? Действительно ли будут жутчайщие тормоза? Или...
Или, как я упрямо и расчитываю, можно всё таки умело устроить алгоритм приложений так, что исключения будут генерироваться значительно реже.
Просто мне (невежде) любопытно! Любопытно и всё...
P.P.P.S.:Есть несколько отличных примеров, вдохновляющих меня.
Это известная карманная игра [url=http://ru.wikipedia.org/wiki/Ну,_погоди!_(электронная_игра)]Ну, Погоди![/url] и
canvas cycle (не сочтите за рекламу).
В первом - на ЖК-дисплее заранее вытравлены все спрайты, а процессор лишь управляет их отображением или гашением.
Во втором - каждый элемент картины зависим от своего цветового регистра палитры. Меняя один цвет в палитре - изменяем общую картину в целом.
PlutOS - эксперимент. Можно ли после сотен исключений (при инициализации приложения с настройкой сегментов) добиться, чтобы число исключений снизилось к минимуму. И потом одно-два исключения уже меняло всю схему приложения и вырабатывало целый поток данных.
Кстати, у меня есть план на FPGA спроектировать свой микрокомпьютер. Там обращение к видеопамяти должно здорово тормозить процессор. Т.е. при записи в какой-то пиксел процессор остановится, пока схема видеопамяти не дойдёт до этого же пиксела. Короче, без мультиплексеров всё.
Зачем?
Во-первых, если картину рисовать не пиксел за пикселом, а прыгая через строки, можно добиться, что процессор не будет простаивать в ожидании весь кадр;
Во-вторых, динамическую анимацию в такой системе никак не организуешь. А значит, можно лишь делать только пейжажи или подобные "Ну, Погоди!" игры.
Смысл? Исследование. Кто-то мне сказал, что значительный ряд моих идей не имеют практического применение. Только теоретическое, для исследований.
Как известный клеточный автомат
Жизнь.
З.Ы.:К сожалению, предугадывая Вашу реакцию (типо "ах вон оно что! ну тогда фиг с тобой. майся сам, не жди помощи"), скажу, что от задумки не откажусь. Я прошёл уже некоторую закалку: Столько лет скитаюсь по форумам, описываю одно и то же, выслушиваю одно и тоже...
Увы, Ваши аргументы и доказательства для меня не открытие. А очередное эхо. Как в хоре программистов...
Вход
Регистрация
FAQ
Поиск
