Флейм
GameDev.ru / Флейм / Форум / FantasmOS

FantasmOS

Поделиться

Страницы: 1 2 Следующая

AlikberovПостоялецwww9 ноя. 201715:36#0
Навеяло вот отсюда: Решил просто открыть отдельную ветку. Может, кому-то да будет практически полезной…

В 1997 году на досуге я занимался дизайном собственной компьютерной системы с чистого листа и не придерживаясь никаких стандартов и традиций: Чистый полёт фантазии на современной элементарной базе…

Предисловие
Так как более-менее смутное представление у меня имелось об архитектуре процессора i386, многие из базовых основ опираются именно на его возможности и уникальные отличия от того же i8086.

Базовый принцип
Каждый процесс в своё распоряжение получает все 4Гб адресного пространства. Так как аппаратные возможности страничной адресации i386 позволяют «скрутить» память до 1млн. страниц по 4Кб каждая, изначально прикладной процесс попадает именно в «царство зеркал», где 4Гб пространства - это миллион зеркал на одни и те же 4Кб памяти. Чем достигается эффект работы BIOS/DOS, где существовала «демократичная политика» доступа: по любым адресам этих 4Гб можно производить чтение или запись - никакого эффекта закрытия программы по ошибке доступа к зарезервированной области памяти не будет. Словно к процессору подключена микросхема памяти в 4Кб, адресная шина использует младшие 12 разрядов, а старшие 20 - не используются. Получается эффект системы с неполной дешифрацией адресной шины.
То же самое положение обстоит и с портами ввода/вывода: Прикладной процесс может читать любой порт или писать в него. Так как обработчик генерируемых исключений изначально будет представляться заглушкой, все такие операции ввода-вывода со стороны приложения будут подобны холостым операциям с очень длинным циклом по тактам, которые будут выделяться на переключение в код обработки исключений.
Таким образом, все приложения запускаются как бы в тотальной «песочнице»: Могут производить любые операции по доступу к памяти или портам, но внешне на операционную среду это никак не будет сказываться…
Что мы получаем?
Получается, можно запустить сотни различных приложений, которые будут тотально инкапсулированны со всех сторон и внешне всё будет работать как тьма кода из холостых операций. Не более… Что бы в них ни происходило. Словно каждая из программ - является своей BIOS-прошивкой в собственном компьютере, не имеющего никакой периферии. Чисто - процессор и память.

Основы концепции
Единственное, что доступно всем приложениям для взаимодействия с внешней средой, это набор ESCAPE-инструкций. В этом отношении, именно i386 мне нравится больше всего, так как его кристалл не нагружен никаким сопроцессором. И если взять 100 материнских плат со спартанской архитектурой «ROM-RAM-CPU», то они будут работать все, но толку от них не будет никакого… Одна плата - один процесс.
Ключевой момент состоит в том, что остаются пустыми розетки под сопроцессор. Именно в них (виртуально) вставляются жгуты и к ним подключается не математический сопроцессор, а компьютер-супервизор. Тем самым, в системе команд появляются проекции ESCAPE-команд от самого супервизора. Напоминает чем-то «мэйн-фрейм»…
Так как группа ESCAPE-команд содержит 8 операционных кодов, эти 8 кодов представляются как группы тематических API и одним кодом можно делать что-то одно.
Например:

  • Одной ESCAPE-инструкцией можно управлять дешифрацией адресного пространства и запросить в него проекцию на зеркало какого-либо процесса или файла. В этом плане, инструкция работает подобно fopen/CreateFile и т.д. А через операнды инструкции в регистра передаётся, например, указатель на имя запрашиваемого, собственно, ресурса, а также указатель на регион в памяти под проекцию этого ресурса в адресное пространство. Если очень нужно, можно запросить проекцию любой библиотеки в своё адресное пространство, подобно LoadLibrary, чтобы в свою память получить поддержку готового системного кода для самостоятельного выполнения;
  • Другой ESCAPE-инструкцией можно управлять дешифрацией устройств ввода-вывода и назначить определённому порту ссылку на необходимый ресурс. В этом плане, операции ввода/вывода будут подобны функциям PostMessage/SendMessage, когда для отправки какому-либо приложению какого-либо сообщения с генерацией соответствующего события, нужно просто записать/прочитать порт (rep+outs/ins - для передачи целых строк или структур), а сама операционная среда определит, за «кем» закреплён этот порт в текущем приложении и переключит управление на адресата (В случае с rep+outs/ins адресат также получает проекцию на контекст вызывающего процесса, чтобы прочитать ecx/esi/edi регистры и указатель на проекцию в память того процесса). Так как операции ввода-вывода изначально поддерживали и т.н. «медленные устройства», которые могли «притормозить» процессор своим сигналом на соответствующий Wait-пин, то затрачиваемое время на подобные операции может быть неопределённым и сходным по эффекту с функцией WaitForSingleObject Win-API;
  • Третьей ESCAPE-инструкцией можно управлять «облачными вычислениями», так как традиционный математический сопроцессор, как сказано выше, объявлен «вне закона». Тем самым, через операнды ESCAPE-инструкции передаётся, допустим, указатель на «вычислительный сценарий», а операционная среда сама займётся его обработкой. Таким образом, можно передать ссылку на MathML, LaTeX, LuaTeX или CUDA сценарий. Получается эффект явного параллелизма, где приложение может просто представить ссылку на какой-либо сценарий, а операционная среда сама решит, каким из специализированных серверов (диспетчеров/интепретаторов) будет выделен отдельный поток под сессию для выполнения конкретного сценария. Ближе всего в этом плане - спулер печати со своей очередью: Рендеринг нескольких SVG/OpenGL сцен от нескольких различных приложений будет выполняться в свою очередь, а сами приложения при этом не будут терять собственные кванты машинного времени на процесс визуализации сценария. Также, всё справедливо и для открытия дополнительных потоков, где подобно CreateThread операции приложение может открывать дополнительные потоки, а система может выделить под них отдельные секции группы серверов (затачивалось под «мэйн-фрейм») или ядра (классически). Так, отдельный поток можно сделать специализированным на работе с числами и тогда у него открывается классический набор FPU-операций, а взаимодействие с API операционной среды резко ограничивается;

И т.д…

Мультизадачность
Как уже понятно, все процессы в системе работают без строгой синхронизации, как бы через сеть. Если какой-то процесс подвисает или завис совсем, обращение к нему подобно ситуации, когда «сервер не отвечает». Тем самым, архитектура операционной среды изначально не расчитана, чтобы, например, в определённый момент времени произвести гибернацию всего в целом. Так как нет совместно разделяемых ресурсов явно с указателями и ссылками на них. Это и не нужно, так же, как и не нужно «делать снимок» связей и маршрутов во всей сети интернет в целом…
Диспетчера задач в классическом смысле нету, так как существует специальная директория под запуск и исполнение новых процессов. Так, при создании очередной поддиректории в ней система резервирует ресурсы под открытие очередного процесса. Создаваемая пустая директория автоматически получает идентификационное новое имя под новый процесс. Теперь необходимо просто распаковать все необходимые файлы запускаемой программы в эту новую директорию и покинуть её (либо командной строкой, либо браузером) для запуска процесса.
Весь механизм распределения машинного времени между процессами и потоками устроен так, что любой процесс автоматически «замораживается» при входе в директорию его ресурсов. Тем самым, любой процесс можно в любой момент «заморозить» и упаковать его текущее состояние в архив, чтобы, например, продолжить его выполнение в другой раз или на другой машине…
При этом, все файлы подкачки памяти, раскладки зеркал ресурсов в адресном пространстве и т.п. хранится непосредственно в директории конкретного процесса. А состояние контекста со всеми регистрами и дампами - проецируется в XML-файл лога, что позволяет обходиться без специального отладчика для просмотра состояния процесса при его «заморозке»…
Следует обратить внимание также на то, что вся текущая карта памяти и портов ввода-вывода оперативно представляется так же - в XML-файле в виде отдельных правил. Например, если добавить строчку «При записи строки по диапазону адресов 0x89AB0000-0x89ABCDEF отправлять SMS-сообщение на номер 1234», то приложение сможет отправлять SMS-ки, само того не подозревая, так как операционная среда сделает всё абсолютно «прозрачно»…
Тем самым, можно как из-вне вручную корректировать всю схему взаимодействия конкретного приложения с другим приложением или операционной средой, редактируя правила XML-файла конфигурации «дешифрации адреса». Так можно и отслеживать эту конфигурацию, которую само приложение изменяет ESCAPE-инструкциями…
К любой задаче можно подтянуть любое количество клавиатур или консольных окон, пусть даже те будут находиться на другом континенте. В приложении просто, абсолютно прозрачно для него, будут оперативно проецироваться все эти ресурсы как регионы памяти с динамическим контекстом.

Концепция дизайна приложений
При дизайне классического подобия Win-приложения какой-то из портов ввода-вывода настраивается на обмен событиями (подобие GetMessage-WinAPI) и при всяком обращении к нему задача «зависает», пока не появится какого-либо события, адресуемого конкретно данной задаче… Чем достигается изначальный дизайн данной операционной системы, где множество процессоров выполняют свою задачи и обмениваются данными, взаимодействуя и синхронизируясь, через порты ввода-вывода.
Например, одно приложение предприняло попытку чтения из порта, который закреплён за другим приложением. Так как операции ввода-вывода (классического) запрещены, первое приложение генерирует этим исключение. Супервизор сканирует таблицу раскладки портов и в случае с обнаружением ссылки к другому приложению, в очередь событий второго приложения добавляется событие, сигнализирующее о необходимости принять-обработать-вернуть внешние данные. В свою очередь, когда второе приложение получает свой квант машинного времени и достигает момента обработки соответствующего события, оно получает в своём адресном пространстве проекцию на контекст первого процесса, где в распоряжение попадает содержимое всех регистров ожидающего процесса. То есть, вторая программа частично становится супервизором над первой программой и способна изменить значения любых регистров (не ограничиваясь eax) или содержимое региона памяти той программы (если явно использовалось rep ins/outs), чтобы непосредственно обменяться произвольным пакетом данных. После чего, вторая программа обязана сама скорректировать регистр eip ожидающего процесса на следующую инструкцию, чтобы тот продолжил своё выполнение так, будто операция чтения порта прошла успешно…


Основное положение (лирикой)


Как известно, абсолютное большинство операционных систем опирается на основы, наработанные опытом применения Больших-ЭВМ лет 40-50 тому назад - солидный срок ведь… Многое из тех понятий, которые были Де-Факто в тот период времени (перфокарты, перфоленты, магнитные ленты, память на феррите) давно уже безнадёжно устарели и вычеркнуты из обихода в буднях не только офисов, но и малых организаций…
Тем не менее, абсолютно множество компьютерных систем иннерционно всё так же строится на базовых принципах полувековой давности. Могу ошибаться, но понятия «библиотека», «файл» или «каталог» могли войти технически в основы иерархии файловых систем именно тогда, когда для смены «рабочего каталога» требовалось, в буквальном смысле, ручная работа по замене перфолент или целого каталога перфокарт библиотеки подпрограмм, что сейчас может казаться просто диким. Но, именно в те времена и зарождались такие коренные и важные понятия, как «Индекс Диска», «Имя Каталога», «Имя Файла», «Флажки Свойств» и т.д… Ещё совсем недавно я пользовался флоппи-дисками и физически переключал кусочком пластмассы такой флажок, как «диск только для чтения»!
Молодёжь или очень продвинутые (но не «крайне продвинутые») пользователи сейчас всё сильнее отдаляются чисто «оптически» от всех тех «рудиментов ЭВМ», которыми были перенасыщенны институты и различные серъёзные отделы научных вычислений. С приходом сенсорных панелей и всё большего отстранения от физической клавиатуры с мышью, технологически всё сильнее маскируются давно устаревшие понятия: «Диск» - стал «Облачным Хранилищем», «Папка Документов» - превратилась в «Галлерею» и т.п… Однако, стоит копнуть чуточку глубже и, скажем, заняться настройкой системы, то мы окунёмся в мир странных «винтажных» понятий. Таких, как например «Девайс» (буквально - «выдумка») или «Драйвер» (буквально - «водитель») и т.п… Тем самым, «установить драйвер девайса» для человека с литературным знанием английского языка может слышаться совсем уж необычно и крайне странно, что-то из «поставить водителя выдумки»… Кстати, техническая руссификация справки Windows'95 с её советами «бить мышей по почкам» и «удобством посылок на…» частично показывает, насколько дико выглядит со стороны всё то, от чего нас сейчас покрывают интерфейсы сенсорных панелей…
Как Вы уже понимаете, наверное, эту «воду» я здесь изливаю не просто так… Просто, хочу заранее подготовить читающего благодарного пользователя к тому, что «многие дикости» из моей личной концепции операционной системы - лишь один шаг в сторону от того «бардака», который унаследован от Больших-ЭВМ эпохи Гагарина…

Взаимодействие приложения с системой


Классической традицией всех операционных систем являет способ предоставления собственных ресурсов через API-интерфейс. Так, и BIOS, и DOS, и ранние версии Windows предоставляли собственную библиотеку услуг посредством программных INT-прерываний. На данный момент, ведущие операционные системы ограничиваются CALL/JMP таблицами со смещениями до целевых процедур выбранных библиотек. Что, так или иначе, требует, чтобы пространство памяти приложения принудительно разделялось с областями к системным API. В свою очередь, под Win-32 это отнимает добрые целых 2Гб объёма. С некоторыми не очень стабильными «трюками» можно объём увеличить и до 3Гб, но это не такой популярный метод в быту…
Тем самым, основной целью при начальной разработке концепции описываемой операционной системы ставилась задача, чтобы устранить принудительное проецирования региона системных API в пространство приложения. Тем самым, приложению доступно все 4Гб пространства и нету никаких таблиц векторов INT-прерываний для взаимодествия с операционной средой.
Получается, формальное, всякое очередной приложение запускается как «в вакууме», словно компьютер построен по схеме «Процессор<->Память» и приложение может абсолютно свободно обращаться к любым ячейкам своего пространства, как в «песочнице». Может производить сложнейщие математические вычисления внутри этих 4Гб и делать всё, на что только может быть способен код…
Однако, чтобы эта «песочница» перестала быть замкнутым изолятором, можно отдельные регионы этого пространства несколько перенастроить. Как пример, можно просто верхние 2Гб памяти просто объявить Windows-проекцией, чтобы приложение начало «себя чувствовать» словно под управлением самой Windows. В таком случае, никакой уникальности операционной системы мы не заметим и получим в распоряжение всё богатство Win-API как есть…
Для переключения режимов проецирования памяти необходимо воспользоваться «полимерными свойствами» пространства…

Полимерная память


Одной из особенностей описываемой здесь операционной системы является так называемая «полимерная память». Нет, это не память, инженерно исполненная из каких-то полимеров, как можно подумать…
Полимерная память представляется отдельными ячейками с дополнительным «измерением» для доступа к их свойствам. Говоря простым языком программиста, каждая ячейка или группа ячеек имеет свой дескриптор или так называемый «handle» в его классическом понимании. Тем самым, когда определённый регион памяти резервируется, скажем, под мультимедийный ресурс, например, как Surface от DirectDraw, все ячейки этого региона в своих свойствах несут подробную информацию о том, в какой момент происходило резервирование, какой участок приложения запрашивал это и какому драйверу по контексту принадлежит эта группа ячеек. Иными словами, если один процесс пытается сканировать память другого процесса, он может получить избыточную информацию о каждой ячейки памяти в нём, как пример…
Как известно, некоторые MMX/SSE операции требуют строгого выравнивания указателей и могут вызывать соответствующее исключение. Эта особенность архитектуры современных процессоров и была использована «флажок полимерного доступа» к памяти. Другими словами, чтобы объявить тот или иной регион пространства памяти контекстом какой-либо библиотеки или отдельной мультимедийной среды (OpenAL, OpenGL и т.д.), достаточно вызвать исключение доступа к памяти с ошибкой выравнивания указателя, чтобы операционная среда диспетчером памяти принялась обрабатывать это событие. А особенное состояние ключевых регистров процессора в этом случае будет рассматриваться именно как намеренное исключение как «диалог приложения с системой», а не спонтанное событие с ошибкой построения алгоритма…

Правка: 14 ноя. 2017 7:23

AlikberovПостоялецwww9 ноя. 201715:37#1
Примернo в 1997 году, когда я «работал» над концепцией абстрактного программирования 3D-сцен, побочным продуктом стала идея подобия «настольной MainFrame».
Суть подобной «персональной MainFrame» заключалась в том, что операционная система представлялась однозадачным подобием DOS-среды… Однако, одна программа получала в своё распоряжение полное 32-битное «чистое» адресное пространство. Под «чистым» имелось ввиду то, что никаких проекций страниц видео-памяти или BIOS в нём не предполагалось в принципе. Просто, процессор работал во всём этом пространстве как в «локальном вакууме». Что сейчас именуется «песочницей»…
Однако, за пределами этих 4Гб пространства (Pentium-Pro имел 48 пинов физической адресации) находились пространства как других приложений или библиотек, так и «интеллектуальное железо»…
Так, представим себе, что контроллер жёсткого диска не является каким-то специализированным чипом, а выполнен в виде отдельной микро-ЭВМ, работающей сопроцессором, как FPU. Этим сопроцессором в приложениях отлавливаются особые команды, типа «найти файл» или «развернуть содержимое», которые никак не будут прерывать центральный процессор, подобно операциям с плавающей запятой… Аппаратно система в этом случае выполняется довольно сложно: Клавиатура считывается своим сопроцессором, встроенный спикер управляется другим сопроцессором, контроллер памяти - третьим сопроцессором и т.д. и т.п…
Как результат, сама программа составляет не набор int/call-вызовов, а содержит набор многих «экзотических» инструкций десятков сопроцессоров… Например, чтобы приложению получить какую-либо проекцию чего-нибудь в своё пространство памяти, достаточно использовать нужную инструкцию сопроцессора и передать регистрами ему нужные сведения.

8086 Instruction Set:

ESC (Escape) The ESC instruction is used as a prefix to the coprocessor instructions. The 8086 processor put the source operand on the data bus but no operation further takes place. The coprocessor continuously examined the data bus content and it is activated by ESC instruction and it reads two operands and thereafter starts execution. The detailed operation is illustrated in the chapter on Coprocessors.

Microprocessor 8086 instruction description
58. Instruction Descriptions 58 8086 Microprocessor ESC – Escape This instruction is used to pass instructions to a co-processor, such as the 8087 math processor which shares the address and data bus with 8086. Instructions for the co-processor are represented by a 6-bit code embedded in the escape instruction. As the 8086 fetches instruction bytes, the co-processor also catches these bytes from the data bus and puts them in its queue.

Иными словами, слишком многозначная политика Intel и разработчики IBM-PC с их нацеленностью на дешёвый настольный ПК с дополнительным сопроцессорным расширением лишь до научных математических вычислений, перечеркнули изначально перспективную идею "подтягивания" периферийного оснащения в саму систему команд.
Читаем:
Набор команд микропроцессора 8088 содержит команду ESC, которая сама по себе не выполняется в микропроцессоре 8088. В системах без сопроцессора 8087 команда ESC идентична команде NOP - за исключением того что для ее выполнения требуется больше времени.
Все команды ESC имеют встроенную адресную информацию, а именно, для вычисления адреса, они используют байт mod=r/m. Несмотря на то, что команда ESC действует как команда NOP, микропроцессор 8088 выполняет вычисление исполнительного адреса, а заетм выполняет чтение памяти по результирующему адресу, хотя и не производит никаких действий с данными. Если байт mod=r/m определяет регистр, а не память микропроцессора 8088, никакого чтения памяти не происходит.

Тем временем микросхема 8087 "наблюдает" за последовательностью команд, выполняемых микропроцессором 8088. Когда микропроцессор выполняет команду ESC, микросхема 8087 распознает эту команду, как свою собственную. Затем микросхема 8087 ждет, пока микропроцесоор 8088 выполнить фиктивное чтение памяти. Когда адрес памяти оказывается на системной шине, микросхема 8087 "захватывает" его, и начиная с этого момента знает, где находятся данные в памяти, не вычисляя при этом адреса. Микропроцессор 8088 вычисляет адрес, а микросхема 8087 выполняет остальную часть команд. Теперь микросхема 8087 может "похищать" некоторые циклы памяти для чтения или записи данных, а микропроцесоор 8088 в это время продолжает работу.


При этом, сама операционная среда должна заниматься лишь переключением контекстов самих задач и переключать глобальный контекст для остальных устройств (или их программные прослойки). Так, в Windows используются явные хэндлы контекстов, будь то файл или какой-либо иной ресурс. Тогда как в моей концепции всё окружение (железо) - облачное и никто не может иметь права управлять так или иначе его контекстом.
Примитивный пример: Чтобы нарисовать линию поверх окна #1 из задачи #2 в Windows достаточно получить хэндл окна #1 и запросить GDI-контекст от него. Причём, программа с окном #1 не будет знать даже, что её окно «пачкается» сторонней программой. В концепции описываемой здесь системы это - баг/дыра. В концепции Windows - всё правильно и так задуманно с самого начала. Что говорит о том, какие сложности в понимании моей системы могут возникнуть у программиста, привыкшиму к «благам Win-API»…
(Было бы хорошо, конечно, утолить справедливую жажду вопрошаемого человека и избавить его мучительного тупикового вопроса: А как же два окна, стоящие на одном экране, могут всё-таки порисовать друг у друга на «физиономиях», если этой системой в принципе это не предусматривается? Для этого просто нужно представить, что ваш компьютер под управлением такой системы является «удалённым сервером», а две задачи с отдельными окошками - для удалённых пользовательских клиента. Тем самым, взаимодействие между ними возможно, например, через туннельные протоколы… Иначе говоря, задача #2 может обратиться к задаче #1 с посылом «просьбы» сделать то-то с её окном от чужого имени…)

P.S.: Подчеркну, что сама идея - 1997 года (увы, документально доказать не могу - флоппи-диски с текстовыми набросками давно размагнитились)…
А вот 12 лет тому назад почему-то вспомнил про ту идею и понял, что ту ЭВМ «моей мечты» можно реально исполнить как Операционную Систему, а вместо кучи аппаратных сопроцессоров просто использовать механизм исключений и т.д…
Необходимо лишь радикально пересмотреть систему обработки исключений выравнивания указателей адреса и «перетряхнуть» набор ESC-инструкций, устранив в них «монополию FPU»…

Правка: 10 ноя. 2017 8:40

AlikberovПостоялецwww9 ноя. 201715:37#2
reserved
AlikberovПостоялецwww9 ноя. 201715:37#3
reserved
=A=L=X=Постоялецwww9 ноя. 201716:01#4
"Полимерная память" на том же x86 легко реализуется механизмом страниц - регионами по 4Кб можно там перехватывать и чтение и запись в ядро оси и там что угодно имитировать, это можно.
Похожая очень концепция в плане подмены API на записи/чтение из памяти происходит при низкоуровневом программировании при обращении к портам ввода-вывода отображённым в адресное пространство процессора. Такая консоль как Game Boy Advance, имхо, такой способ общения с железом эпохи 16-битных консолей довела до совершенства практически, я про это в соседних темах писал. Тем не менее это именно настоящее железо, а не интерфейс к оси, но как я написал выше - это вполне реально через механизм виртуальной памяти сделать прослойкой к ОС. Непонятно только в чём профит по существу.
AlikberovПостоялецwww9 ноя. 201716:40#5
=A=L=X=
"Полимерная память" на том же x86 легко реализуется механизмом страниц - регионами по 4Кб можно там перехватывать и чтение и запись в ядро оси и там что угодно имитировать, это можно. Похожая очень концепция в плане подмены API на записи/чтение из памяти происходит при низкоуровневом программировании при обращении к портам ввода-вывода отображённым в адресное пространство процессора. Такая консоль как Game Boy Advance, имхо, такой способ общения с железом эпохи 16-битных консолей довела до совершенства практически, я про это в соседних темах писал. Тем не менее это именно настоящее железо, а не интерфейс к оси, но как я написал выше - это вполне реально через механизм виртуальной памяти сделать прослойкой к ОС. Непонятно только в чём профит по существу.
Вoт-вот, о чём я оффтопиком здесь писал более-менее подробно. Там же я и сказал, что у меня OS выступает как «эмулятор чипсета» - фантомного железа: Можно моей ОСью пользоваться или просто заказать чипсет за льярд юаней…

P.S.: Вы просто подтвердили, что в игрушках всяких это и используется, а я просто подчеркнул: Не надо хронить безнадёжно отставшую от игровых консолей ту же IA-32! Можно просто бы написать совершенно новую ОСь, без оглядки и поддержки всяких Unix, Posix и т.д…

Правка: 9 ноя. 2017 16:42

gudleifrПостоялецwww9 ноя. 201717:02#6
Мне кажется, что для начала следовало бы ознакомиться с теми самыми "устаревшими основами".

ASPПостоялецwww9 ноя. 201717:16#7
Alikberov
> А особенное состояние ключевых регистров процессора в этом случае будет
> рассматриваться именно как намеренное исключение как «диалог приложения с
> системой», а не спонтанное событие с ошибкой построения алгоритма…
Именно таким методом происходит переключение в режим ядра в современных ОС. И он далеко не так быстр как простой вызов по CALL/JMP, а также позволяет ограничивать доступ к аппаратным ресурсам. Или ты планируешь сделать систему в которой как в ДОСе всем всё дозволено?
>Мне кажется, что для начала следовало бы ознакомиться с теми самыми "устаревшими основами".
Полностью поддерживаю. Создается впечатление что человек рассуждает о том чего не понимает. Может сначала стоит узнать почему сделано именно так, а не иначе?
Большинство текущих решений в ОС сделаны именно так из-за технических ограничений, если же ты собираешься делать ОС под другую архитектуру, отличную от IA-32, то посмотри на консоли, там и так другие ОСи и другие хаки, связанные с реальными железками и требованиями к ним.
AlikberovПостоялецwww9 ноя. 201722:30#8
ASP
Или ты планируешь сделать систему в которой как в ДОСе всем всё дозволено?
Именнo про это я говорил где-то: Если в виртуальных DOS-машинах эмулируется реальное железо, а сменой графических режимов достигается изменение настроек окна консоли с её геометрией и палитрой, то почему нельзя построить тот же аналог DOS-машины, но где нет привязки к реальному железу DOS-эпохи.

Вот смотрите.
Под DOS в режиме 320x200 с палитрой 256 цветов графика записывается в сегмент страницы 0xA0000, джойстик считывается с порта 200h и клавиатура имеет порт 60h. Причём, никаких API для построения минимального приложения  не надо: Читай скэн-коды напрямую из порта и меняй графику прямо в сегменте.
Мною же предлагается концепция, где операционная система - это виртуальная машина из своего состава СОВРЕМЕННОГО железа. То есть, приложение получает холостое пространство в 4Гб, а затем само решает, где в этом пространстве будет регион оконного GDI, например. А где будет храниться очередь происходящих событий о том, что происходит с клавиатурой, мышью, сетью, дисками и т.д. То есть, вместо DOS-порта 060h с кодом от клавиатуры, приложение может запросить регион в 16Мб для проекции в него Unicode-очереди с клавиатуры, которая находится на конкретном ПК с конкретным IP на другом континенте. Причём, вместо явных сокетных send/recv через CALL/JMP, здесь генерируется исключение от сбоя доступа к такой-то области памяти, система проверяет наличие данных, обнавляет страницу, заполняя ими и приложение получает управление обратно, будто оно прочитало буфер обмена компьютера на другом континенте.

ASP

Именно таким методом происходит переключение в режим ядра в современных ОС. И он далеко не так быстр как простой вызов по CALL/JMP
В том и весь фокус, что следуя технологиям 60-70-х, проще для всех приложений в адресном пространстве организовать общий регион в пару Гб и «насыпать» туда сотни разных библиотек… Но, Вы упускаете из внимания ключевой момент - у меня концепция «облачной OS»… То есть, генерировать «медленные исключения» для организации доступа к поверхности графического окна - очень дурная практика. В моей концепции нет таких операций, как аналоги GetDC/SetPixel/LineTo/MoveWindow… Это так же, как пытаться на PHP средствами MySQL искать библиотеку, чтобы поморгать светодиодиком на таком-то сервере.
Пожалуйста, выйдите за рамки классического программирования, где имеются тысячи маленьких различных функций для открытия сокетов, чтения пакетов и состояния нажатий клавиш.
У меня в концепции 1997 года этого не предусматривалось. Прикладная программа просто описывает свойства всех нужных ей регионов памяти и описывает сценарий взаимодействий между ними.
То есть, Вы имеете несколько серверов. Один - только OpenGL, второй - только OpenAL и т.д. А Ваша программа должна выступить маршрутизатором между ними. В этом смысле, никаких VirtualAlloc или GetKeyState и быть не может! Это всё равно, что пытаться WiFi-маршрутизатор прошить так, чтобы он следил за движениями мышки.
Тем самым, генерация исключений - хоть и медленный способ взаимодействия с API, но качественно - иной: Или сотни тысяч раз вызвать SetPixel для закраски окна, или один раз построить XML-древо и передать его браузеру, чтобы получить окно нужного цвета.
Ghost2Постоялецwww9 ноя. 201723:30#9
Alikberov

> мир странных «винтажных» понятий. Таких, как например «Девайс» (буквально - «выдумка»)
Девайс - это устройство. А выдумка оно для тех, кто не знает, как правильно пишется слово по английски.

AlikberovПостоялецwww10 ноя. 20176:10#10
Ghost2
Девайс - это устройство. А выдумка оно для тех, кто не знает, как правильно пишется слово по английски.

Device:
device: варианты переводаимя существительное
устройствоdevice, arrangement, system, appliance, structure, mechanism
приборdevice, instrument, appliance, apparatus, gear, implement
аппаратapparatus, machine, device, machinery, instrument, staff
приспособлениеdevice, adaptation, accommodation, adjustment, attachment, arrangement
средствоmeans, agent, way, remedy, medium, device
приемreception, acceptance, method, appointment, device, dose
механизмmechanism, machinery, gear, machine, arrangement, device
способway, method, process, manner, means, device
изобретениеinvention, patent, device, artifice, contrivance, notion
схемаscheme, diagram, circuit, schema, pattern, device
девизmotto, slogan, device, word, posy, bearing
эмблемаemblem, insignia, symbol, device, ensign, blazon
затеяscheme, contrivance, device, ploy
злой умыселmalice, device, design
планplan, outline, schedule, scheme, blueprint, device
проектproject, draft, projection, design, plan, device

Так как я учил английский по технической литературе, впадал в задумчивость, когда в какой либо песне слышал фразу, содержащую слово «девайс»: Почему они поют про устройства?
Это потом, с приходом гугл-переводчика восполнился пробел и я открыл много иных значений…
P.S.: Потому, ваш комментарий об обратном.
P.P.S.: И вообще, причём здесь, по-вашему, ошибочная трактовка терминов в буквальном смысле, если здесь я не сдаю экзамена на знание английского языка, а просто излагаю свою фантазию на тему «операционной среды Аликберова» от 1997 года?

Правка: 10 ноя. 2017 8:10

nonamezeroxПостоялецwww10 ноя. 201710:34#11
В том и весь фокус, что следуя технологиям 60-70-х, проще для всех приложений в адресном пространстве организовать общий регион в пару Гб и «насыпать» туда сотни разных библиотек… Но, Вы упускаете из внимания ключевой момент - у меня концепция «облачной OS»… То есть, генерировать «медленные исключения» для организации доступа к поверхности графического окна - очень дурная практика. В моей концепции нет таких операций, как аналоги GetDC/SetPixel/LineTo/MoveWindow… Это так же, как пытаться на PHP средствами MySQL искать библиотеку, чтобы поморгать светодиодиком на таком-то сервере.

www.cse.unsw.edu.au/~cs9242/03/project/l4-x2.pdf

https://github.com/dzavalishin/phantomuserland

Правка: 10 ноя. 2017 10:41

AlikberovПостоялецwww10 ноя. 201711:45#12
nonamezerox, наверноe сразу заметно, что вступительная часть сильно совпадает с моей?
Современные операционные системы на деле вовсе не так современны — практически все их многообразие реализует единственную концептуальную модель, сформулированную еще в середине XX века при создании ОС Unix, на которой базируются и популярные сегодня клоны Unix (FreeBSD, Linux), и формально далекие от нее системы (Windows). Все они воссоздают одну и ту же модель программа-процесс-файл. И кажется уже, что эта модель неизбежна, что она чуть ли не дана нам свыше, как законы физики, а подвергать ее сомнению — кощунственно. Но тем не менее попробуем.
Кажется, с автором я переписывался, чуток…
В принципе, базовое положение как бы полностью у нас с ним похожи. Только есть несколько отличий…
У меня все задачи работают так, будто каждая исполняется монопольно на своей отдельной машине. Тем самым, любую задачу можно «заморозить» (эффект, будто удалённый компьютер вдруг завис и перестал отвечать), запаковать всё в архив, перенести на другой компьютер (допустим, более производительный) и «разморозить» распаковкой обратно… В этом случае, делать снимок всего состояния системы в целом нет смысла, как и пытаться делать снимок всех межсетевых связей компьютеров в мире.

Очень просто дело обстоит с «заморозкой» процессов: Стоит войти «из-вне» в объектную директорию какого-либо процесса, как этот процесс замораживается совсем (выпадает из очереди многозадачности конвейера) и можно легко изучить всё его текущее состояние. В частности, всё содержимое регистров процессора и частичный дамп стека/инструкций всегда проецируется в краткий XML-файл. Тем самым, для поверхностной отладки не нужно использовать никаких инструментов. Достаточно войти в директорию, бегло осмотреть, изменить состояние (отдельных регистров, например) и просто покинуть директорию, чтобы процесс «разморозился» и продолжил свою работу…
Нету какого-либо глобального своп-файла: Каждый из процессов в собственной директории уже имеет все локальные свопы. А когда пользователь начинает архивацию какой-то из этих директорий, тот процесс, соответственно, «замораживается», как сказано выше, до тех пор, пока архиватор «не покинет» его директорию (не закроет последний из дескрипторов доступа к ресурсам той директории)…

Да, Вы достаточно внимательны, чтобы заметить сходство с «Фантомом»! И Вы - правы…
Только вот моя концепция немного «устаревшая» (именно так в 1997 года я представлял современный компьютер) и имеет ряд открытых нестыковок…
Но, в принципе, думаю, ядро «Фантома» можно «допилить» до «кондиции»…
В частности, диспетчер «полимерной памяти» нужен и реализация «исключительного интерфейса» для связи между приложением и средой через механизм исключений…
(Так как инструкция lea служит только для вычисления адреса в формате «регистр,[адрес]» и попытка использовать «регистр,регистр» генерирует исключение, эта операция также используется как префикс передачи имён регистров системе перед какой-либо процедурой. Что избавляет от «гадкой» необходимости впихивать все аргументы в стек перед вызовом любых процедур и следить за указателем стека. Ведь API тут - такой же сопроцессор, как и FPU)…
И остро стоит проблема высокоуровневого программирования: Критикуется то, что из языка программирования сложно обойтись без call-вызовов к API. На ассемблере же с этим никаких проблем нет, так как можно городить любые «инструкционные кренделя»! А вот высокоуровневая модель (подобно операциям перемножения матриц sse-средствами через интринсики)…

P.S.: Спасибо за внимание…

Правка: 10 ноя. 2017 12:05

ASPПостоялецwww10 ноя. 201711:57#13
Alikberov
Всё слишком расплывчато, может для начала дашь ссылку на "ЭВМ твоей мечты". Пока выглядит как попытка написать ОС под несуществующее железо. И вообще, определись, у тебя DOS, где всё всем дозволено, или всё же каждое приложение в песочнице и не может на прямую рисовать на окнах другого приложения.
ASPПостоялецwww10 ноя. 201712:09#14
Alikberov
> наверноe сразу заметно, что вступительная часть сильно совпадает с моей?
Не осилил всю статью. А вообще там идет демагогия и подмена понятий. Если мы на компе монопольно выполняем только одну задачу - это не шаг вперед, это шаг назад к DOS. Если же все программы выполняются в своей песочнице, то ОС для них уже будет гипервизор, который следит за этими песочницами, в статье же получается что песочницы (виртуальные машины) видимо сами по себе как-то организуются и живут на одной реальной машине, чего не может быть в принципе. А вообще до определенного уровня и BIOS можно считать ОС, вот только имея один BIOS исполнять программы становится не так удобно. А вообще речь видимо идет об RTOS, ну тогда фантазируй сколько хочешь.

Страницы: 1 2 Следующая

/ Форум / Флейм / ПроЭкты

2001—2017 © GameDev.ru — Разработка игр