1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

Hardware DOS Machine

Тема в разделе "WASM.OS.DEVEL", создана пользователем Paguo_86PK, 1 ноя 2019.

?

Обсуждаемая тема

  1. Теперь многое стало ясно, что автор имел ввиду

    50,0%
  2. Теперь стало яснее, но всё как-то запутано

    0 голосов
    0,0%
  3. Смысл сказанного ясен, но не понятно, для чего всё это в XXI веке

    25,0%
  4. В те времена это было слишком сложно и никому не нужно

    0 голосов
    0,0%
  5. Я ничего не понял. Причём здесь порты заменяющие API

    25,0%
  6. Какая-то «охота на ведьм»…

    0 голосов
    0,0%
Можно выбрать сразу несколько вариантов.
  1. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    Старoжилы могут меня помнить по попыткам наработки концепции виртуальной Операционной Системы без API. Как показывает многократная практика дискуссий на эту тему, многие в упор не понимают, что мною имеется ввиду. И приходится идти на всяческие ухищрения, чтобы всё стало простым и доходчивым.

    И в этот раз я попытаюсь вернуться к этому вопросу, но с несколько другого ракурса на примере DOS.
    Для начала, сравните два кода:
    Код (Text):
    1. ; Классическая DOS-версия
    2.     org     00100h
    3.  
    4. Start:
    5.     mov    dx,sHello   ; Приветствование
    6.     mov    ah,009h     ; Код функции печати с долларовым терминатором
    7.     int    021h        ; Вызов DOS-API: Печатаем сообщение на экран
    8.     mov    ah,008h     ; Код функции ввода символа с ожиданием без эха
    9. @wait_cr:
    10.     int    021h        ; Обращаемся к DOS-API и ожидаем ввод символа
    11.     cmp    al,00Dh     ; Если это не клавиша Enter
    12.     jne    @wait_cr    ; Необходимо дождаться её нажатия
    13.     mov    ah,000h     ; Нужно изменить режим экрана
    14.     mov    al,007h     ; Режим монохромного текста 80x25
    15.     int    010h        ; Обращаемся к BIOS-API и переключаем видеорежим
    16. @wait_esc:
    17.     mov    ah,008h     ; Код функции ввода символа с ожиданием без эха
    18.     int    021h        ; Обращаемся к DOS-API и ожидаем ввод символа
    19.     cmp    al,01Bh     ; Если это клавиша Esc
    20.     je     @exit       ; Завершим нашу задачу
    21.     mov    ah,002h     ; Функция DOS-API для печати символа
    22.     mov    dl,al       ; Регистр передачи кода символа
    23.     int    021h        ; Обращаемся к DOS-API
    24.     jmp    @wait_esc
    25. @exit:
    26.     mov    ah,04Ch     ; Готовимся к завершению задачи
    27.     mov    al,dl       ; Вернём код предыдушей клавиши до Esc
    28.     int    021h        ; Возвращаемся в DOS
    29.  
    30. sHello:    db 'Hello, World!',00Dh,00Ah
    31.            db 'Press ENTER key to continue...$'
    Код (Text):
    1. ; Аппаратно-портовая версия DOS
    2. Start:
    3.     mov    ax,sHello   ; Адрес строки в аккумулятор
    4.     mov    dh,021h     ; Индекс страницы портов DOS
    5.     mov    dl,009h     ; Индекс порта печати строки
    6.     out    dx,ax       ; Пишем в порт адрес и строка печатается
    7.     mov    dl,008h     ; Индекс порта ввода символа с ожиданием
    8. @wait_cr:
    9.     in     al,dx       ; Вводим символ с ожиданием
    10.     cmp    al,00Dh     ; Если это не код клавиши Enter
    11.     jne    @wait_cr    ; Дожидаемся её нажатия
    12.     mov    dh,010h     ; Индекс страницы портов экрана
    13.     mov    dl,000h     ; Индекс порта режима экрана
    14.     mov    al,007h     ; Текстовый монохромный режим 80x25
    15.     out    dx,al       ; Записью в порт меняем режим
    16.     mov    dh,021h     ; Возвращаемся к портам DOS
    17. @wait_esc:
    18.     mov    dl,008h     ; Индекс порта ввода символа с ожиданием
    19.     in     al,dx       ; Вводим символ. Если нет, генерируется сигнал Wait
    20.     cmp    al,01Bh     ; Если это клавиша Esc
    21.     je     @exit       ; Наша задача завершится
    22.     mov    dl,002h     ; Индекс порта вывода символа
    23.     out    dx,al       ; Выводим код символа в порт для его печати
    24.     jmp    @wait_esc
    25. @exit:
    26.     mov    dl,04Ch     ; Индекс порта ErrorLevel
    27.     out    dx,ax       ; Вот здесь не 256, а 65536 комбинаций
    28.     hlt                ; Через hlt достигается терминация процесса
    29.  
    30. sHello:    db 'Hello, World!',00Dh,00Ah
    31.            db 'Press ENTER key to continue...',0
    Видно, что вторая версия не использует никаких вызовов системных функций и под них не нужно резервировать ни байта системного кода. Программа может иметь в своём распоряжении до 1 Мб памяти, так как и BIOS, как таковой, находится в теневой странице памяти. В этом примере прикладная программа не нуждается ни в каком системном коде, так как нужно просто программировать порты.

    Плюсы: Если вы когда-нибудь программировали на Бейсике, то могли сталкиваться с ситуацией, когда необходимо было обратиться к функции DOS-API через USR. Необходимо было верно выбрать сегмент памяти под POKE, которыми записывался машинный код. Туда же вписывались и все нужные параметры. В общем, программисту-новичку приходилось не очень сладко, так как с высокого уровня необходимо было спуститься на самый элементарный уровень!
    А если бы существовала аппаратная DOS-машина, на уровне Бейсика достаточно было оператором OUT и функцией IN обратиться к портам и всё. Никаких POKE и USR! Всё на достаточно высоком уровне остаётся.

    Минусы:
    1. Необходимо довольно умное и дорогое железо, чтобы обрабатывать обращения ко всем прописанным портам на высоком уровне. Как вариант - карточка с дополнительным сервис-процессором, отдельной памятью ОЗУ и ПЗУ под всё функциональное API
    2. Либо необходим, как минимум, процессор i286, где уже имелись нормальные механизмы защиты памяти и портов ввода-вывода. Лучше, конечно, процессор i386 с полной виртуализацией памяти и портов. Через механизмы исключений система просто определяет, к какому порту приложение пыталось вести доступ и просто исполняет высокоуровневую функцию
    3. Обращение к портам ввода-вывода занимает относительно много машинного времени по тактам. Однако, учитывая, что приложение обращается не к каким-то там элементарным периферийным регистрам, а программирует DOS-операции высокого уровня, то по скорости обращение к порту будет не хуже классического call/int вызова

    XXI век:
    Если бы в своё время с появлением i286 сама DOS совершила бы «квантовый скачок» и перешла бы на уровень аппаратной виртуализации своего функционала, то и Windows могла бы полностью уйти на тот же уровень…
    При этом, необходимость в верхних 2 Гб памяти под системное API полностью отпала бы. Приложению можно предоставить все 4 Гб адресного пространства, так как вместо загрузки системных библиотек, код которых нам не доступен на чтение и не так важен, ведь он просто засоряет где-то адресное пространство и нужен лишь для call-вызовов.

    Вместо этого, имелись бы порты ввода-вывода под такие высокие уровни, как OpenAL, OpenGL, DirectSound, DirectPlay, DirectInput, GDI и т.д.
    Никаких подгружаемых системных библиотек. Только порты.
    При этом, даже сам DOS формата *.com мог бы несколькими строчками ассемблера запрограммировать порт окна и OpenGL, выведя туда 3D-сферу. То есть, вместо кривой виртуализации DOS-машины, мы бы имели бы эволюционное развитие DOS-программ под Windows-среду.

    А так как сейчас популярны Облачные технологии, то такая Операционная Система могла бы стать Облачной ещё с появлением i386, где API - где-то «Там в Облаках», а не в верхних 2 Гб.
    (Вот про это я думаю уж 20 лет. А не с потолка вчера содрал!)

    P.S.: А что мы получили?
    У Linux - int 80h, у Windows - int 2Eh…
    А как итог, *.com файлы на современной системе вообще не поддерживаются.
     
    Последнее редактирование: 1 ноя 2019
    UbIvItS, eroha и q2e74 нравится это.
  2. voffka0

    voffka0 Member

    Публикаций:
    0
    Регистрация:
    22 янв 2019
    Сообщения:
    73
    ставил freedos 1.2 на intel core i5-7200u, нету драйверов, смысл? убить билла 3, скоро во всех кинотеатрах мира ну и третий майдан, куда же без него? скучно жить( а развиваться профессионально не дают, на форуме lenovo забанили, больше ничего не куплю из железа, принципиально! только наркота и алкоголь, только хард!пока трамп и си дзен пин не поцелуют мне руку в знак уважения)
     
    Последнее редактирование: 2 ноя 2019
  3. f13nd

    f13nd Active Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    869
    То есть из одной вычислительной машины сделать тандем из двух? "Карточка с дополнительным сервис-процессором, отдельной памятью ОЗУ и ПЗУ под всё функциональное API" позволит не загружать на первой "никаких подгружаемых системных библиотек" и разгрузить тем самым ОЗУ первой? И по возможности организовать между ними обмен хотя бы с пропускной способностью не ниже чем у ОЗУ первой. Че-то я скептически к этому отношусь.
     
  4. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    2.647
  5. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    A я не говорил, что именно из двух.
    Тeма открыта про Raspberry как раз.
    Кластеры сейчас копейки стоят для сборки.
    [​IMG]
    Уже про это я сказал выше:
    По классике жанра, обмен у них происходит на уровне сетевых протоколов и сетевых контроллеров.
    А я предлагаю связать всё это на реальные порты.
    Фокус в том, что раньше обмен с памятью тоже был медленным. Но так как технологии развивались с добавлением кешей, то сейчас имеем нормальную производительность. Тогда как с портами ввода-вывода инженеры не возились и кешированием не занимались. Тем самым, развивая именно портовую концепцию, можно придумать технологию быстрого и короткого обмена.
    Межсетевой обмен - самый медленный. Но программное обеспечение устроено асинхронно и не дожидается ответа сразу после отправки пакета. Тем самым, допустим, в программе мы обойдёмся одними командами OUT с передачей адреса фреймов в стеке на структуры. Когда этот фрейм отправится - мы не знаем. Но, сама по себе инструкция OUT выполнится в сто раз быстрее, чем вызов того же «send(socket, …)», так как эту операцию мы и перенесём в аппаратно-портовую плоскость, чтобы сам прикладной код ни байта кода send-операции не выполнил…
    И я понимаю, почему…
    Вы вчитываетесь в моё поверхностное описание концепции уже с мышлением по шаблону.
    То есть, если программа пишет в порт OpenGL для вывода сферы, то она в порты будет передавать и координаты, и радиус, и т.д…
    На самом деле, просто в памяти описывается целая порция сцены, а потом через OUT в порт передаётся указатель на ту структуру.
    При этом, память по указателю уже читает другой процессор.
    То есть, просто нужно начать мыслить несколько иначе, чтобы вникнуть в плюсы концепции.

    Вот в GDI мы имеем набор из SetPixel/GetPixel/LineTo и т.д. Всё это дело очень медленное, а значит, ошибочное.
    Через порты попиксельно передавать всё это в процессе очень накладно и сервисные процессоры захлебнуться.
    Потому смотрим в сторону формата WMF и становится очевидным, что просто нужно подготовить список, завернуть в структуры и в порт передать указатель на него.
    Тем самым, все мелкие функции из программы сами по себе выбрасываются автоматически: getc/putc/printf, SelectObject/GetStockObject/DrawText, SendMessage/CreateFile и т.д.

    Вы спросите: А как же без них?
    А так же, как и в Облачной БД. Браузером посылаешь запрос на создание, а принимаешь событие готовности или ошибку.
    Выше я сразу сказал
    Только в Облако путь короче - прямо процессорной инструкцией IN/OUT.
     
    Последнее редактирование: 2 ноя 2019
  6. f13nd

    f13nd Active Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    869
    Кешируется содержимое памяти, резервная копия часто используемых данных с меньшим временем обращения к ней. Что кешировать при обмене с внешним исполнителем сервисов?

    В tcp/ip стек протоколов, часто избыточный ради универсальности, время исполнения send-запроса tcp/ip не характеристика самой концепции. Я вот часто вижу реализацию Controller Area Network, когда в составе микроконтроллера есть CAN-контроллер, обмен с которым реализован через системные регистры проца. Там стек максимум из 2 протоколов и то второй только ради передачи фрагментированных данных, что не всегда нужно. Там почему-то не додумались довести асинхронный обмен до абсурда: после установки любого вшивого флага в управляющем регистре прошивка ожидает нужного статуса в другом, это же касается передачи и приема данных. Пусть между процессором и кан-контроллером будет прокладка, в которую можно выбрасывать запросы и двигаться дальше. Усложнение программы таким образом, чтобы она могла правильно обработать любые полученные постфактум ошибки и скорректировать свои действия, не перевесит профит от такой асинхронности?
     
  7. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    Кeшировать ничего, собственно, не надо.
    (Хотя лет 30 тому назад перезаписывать циклически все 256 регистров VGA-палитры для эффекта плазмы - было актуальным. Вот там и надо было изворачиваться!)
    Мною же имелось ввиду, что при записи в порт указателя на структуру, периферийный контроллер сделает снимок участка памяти по полученному указателю и отправит этот фрейм сервисному процессору на обработку.
    Например:
    Код (Text):
    1.     mov dx,gdi ; Порт GDI окна
    2.     mov ax,pic ; Ссылка на wmf
    3.     out dx,ax  ; Отправляем wmf-файл на отрисовку
    4.     ...
    5. pic:dw 6,0,META_MOVETO,0,0
    6.     dw 6,0,META_LINETO,120,90
    7.     dw 2,0,META_EOF
     
    Последнее редактирование: 2 ноя 2019
  8. f13nd

    f13nd Active Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    869
    Это позволит программе курить или заниматься чем-нибудь еще, пока результат исполнения не будет получен. В рамках одного потока такие занятия каким-то чем-нибудь сильно усложнили бы программу, благо потоков можно наплодить много, они прозрачно переключаются и могут синхронизироваться друг с другом где надо. Чем больше ядер, тем больше потоков могут исполняться одновременно, деля между собой общие ресурсы. А могли бы иметь каждое свою оперативку и отдельную шину для связи с другими ядрами. И за счет чего-нибудь это работало бы быстрей и стоило бы дешевле.
     
  9. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    Вoт именно!
    Под Windows вызов LineTo обрабатывает сам прикладной код в верхних адресах подгруженного DLL.
    А в случае моей портовой концепции, запрос от out-инструкции уйдёт, допустим, от одной Raspberry платы к десятой. И вот десятая и будет строить линию.
    Ведь та же графическая память приложению Windows недоступна и нужно чуток потанцевать с бубном, чтобы в обход GDI напрямую записать пиксель.
    Тогда как и у меня, если графикой занимается десятая плата, то и память графическая не обязана распространяться на остальные.
    О чём я и говорю!

    P.S.: Вижу, Вы хоть и начинаете понимать суть моей операционки, но прагматизм нагнетает скепсиса…
     
    Последнее редактирование: 2 ноя 2019
  10. f13nd

    f13nd Active Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    869
    Перезобрел видеокарту :derisive: Тут по-моему нужны дополнительные исследования того, что такой кластер из себя представляет в плане общей производительности, пропускной способности шины между отдельными элементами, что он в итоге может и стоит ли этих копеек.
    Не, пост был саркастический :boast:
     
    Последнее редактирование: 2 ноя 2019
  11. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    A я и не говорил, что всё ограничивается GDI.
    С самого начала я говорю, чтобы в самом чистом режиме (1 Mb памяти не тратятся на резиденцию BIOS и DOS) программа через порты может строить SVG-изображения или WebGL-сцены. Да и вообще, использовать все самые последние и передовые технологии.
    Никакого рудиментарного доступа к обычным стандартным портам.
    Все 65536 портов используются под различные сервисы.
    Если программа отправляет данные в порт, который никем не обслуживается, абсолютно ничего не произойдёт. Просто обратное событие готовности с индексом этого порта придёт с пометкой холостой обработки.

    А теперь подумайте, сколько в Windows библиотек и суммарное число всех их функций.
    Как я уже сказал, такие, как putc сразу выкидываем, так как один символ раздуется до громадного пакетного запроса.
    И, тем самым, нужно пересмотреть саму концепцию программирования и избавиться от UNIX-рудиментов.

    То есть, аналогично высокоуровневому ООП, необходимо с портами работать уже не по-старинке, а как с объектами Облака.
    То есть, настраивать одно графическое GUI-Облако на взаимодействие с другим Облаком с событиями мыши.
    Тем самым, прикладной задаче нет необходимости постоянно считывать координаты x,y-мыши. Приложение может просто дожидаться события, когда на какой-то элемент интерфейса пользователь наведёт указатель.
    Проще говоря, получаем тот же JavaScript, но на уровне машинных команд с in/out.
    А так как в Windows SendMessage отправляет программу в очередь ожидания сообщений от другого окна, так и по IN приложение может заснуть. И приложение может работать в синхронном режиме с таймерами и пользователем.
    Плевать!

    Если такую Операционку оформить как некую карточку, то и под IBM PC-XT, и под Yamaha-MSX эта карточка позволит прямо из-под Бейсика хоть шейдерами баловаться.
    Достигается почти 100% совместимость между разными машинами.
     
    Последнее редактирование: 2 ноя 2019
  12. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    442
    Paguo_86PK, если на такой операционке ntp сервак поднять, у него секунды будут одинаковые? или одни короче, а другие длиннее?
     
  13. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    Вoт это я не знаю.
    Я уже говорил, что в 2008 написал на Си эмулятор, который, как Bochs, исполнял инструкции i8086, чтобы несколькими строчками ассемблера в окна отобразить OpenGL-сцену. Писал много, но зашёл в тупик. Не технически, а концептуально.
    Да, я убедился, что формально так можно (было бы) сделать. И сфера двигалась и дышала… Только вот тупо записью в порт построения сфер. Эдакий, VRML в x86-байт-код кодировании.
    Но вот протоколы какие использовать, если по-хорошему всё это организовать!?

    Тот же WebGL многими критикуется за его костыльность как практически полный тупой порт библиотеки OpenGL в браузер.
    А так как OpenGL морально давно уже устарел, то получилась технология 90-х в браузерах! Если на то пошло, то ещё и в IE4 это можно было бы сделать сквозь ActiveX.

    Вот и у меня в том же проблемы.
    Сделать то всё можно. А вот как детально расписать верхнюю абстракцию модели операционной системы?
    Ещё на заре UNIX, когда требовалась какая-то функция, её писали, описывали, стандартизировали мануалом и всё. И это дело всё росло и пузырилось, как на дрожжах.

    Но вот попробуйте так же расписать с чистого листа сотни портов и протоколы с нуля, чтобы «не пахло элементарными железячками»!
    Вот тут я и споткнулся. Уж 20 лет мечтаю о такой системе, 12 лет назад писал эмулятор. Но, «бизнес плана» расписанного не имеется…
    Хотя, по идее, на доске мелом всё это надо начертить! Как это сделали авторы идеи Облачных Технологий.

    P.S.: Понимаете, в чём затык?
     
    q2e74 нравится это.
  14. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    q2e74, Благодaря жаркой дискуссии с Вами, конкретно сейчас до меня наконец-то дошло понимание коренной причины того, почему основную концептуальную модель своей системы я сам и реализовать не могу даже в ограниченных рамках демонстрационного кода, ни доходчиво объяснить остальным все плюсы подобного подхода к организации системы.

    Почему в качестве удачного примера (в этот раз) я избрал именно DOS и удалось здесь другим прояснить картину, и самому многое осознать?

    Немного лирики
    В средние 90-е я на своём РАДИО-86РК сталкивался с обрывами печатной платы, когда и символы на экран начинали выводиться половинкою, и ОЗУ теряло бит разрядности. Естественно, первая проблема была не так пагубна и решалась кусочком ластика подставляемого прямо под плату включенного компьютера. Тогда как из-за обрыва в шине ОЗУ любая программа моментально уничтожалась.
    И однажды я задумался о базовых архитектурных проблемах компьютеров, находясь под впечатлением фильма «Космическая Одиссея 2001» в его финальных кадрах отключения «HAL 9000» с горячим извлечением его модулей, когда у HAL деградирует синтез голоса и меняется алгоритм «рассудка», но он долгое время всё ещё не зависает и продолжает функционировать…
    В то же время, за перелистыванием журналов РАДИО, мне попалась статья о подключении отечественной клавиатуры к IBM-PC через микроконтроллер К1816ВЕ48. Именно тогда я стал понимать, что крупная ЭВМ может составляться из отдельных мелких. Не говоря уж про контроллеры НГМД.

    Когда я пересел за Поиск и немного практически поработал с DOS, подумал, что всё могло быть намного эффективнее, если бы всё состояло из кучи различных самостоятельных контроллеров.
    В частности, чтобы не сам центральный процессор искал файл на диске через контроллер НГМД, а чтобы файлы искались самим контроллером НГМД, будь он помощнее.
    И это - ключевой момент: Файловая Система - не часть Операционной Системы, а всего лишь вспомогательная память.
    (Я же за РАДИО-86РК воспитывался, где вообще файловой системы не имелось, а лично я сам выполнял функцию того файлового контроллера, когда вручную искал нужные файлы перематыванием кассет…)

    Проблемы концепций
    Если судить очень и очень грубо, то DOS и PC/XT с его аппаратным оснащением являются Объектно-Ориентированной Системой нижнего класса.
    То есть, порты 0x60 - это «объект "Клавиатура"», а порты 3C0…3CF - «объект "Графика"»…
    И мне всегда хотелось, чтобы линии строились и заливка контуров производилась именно самим графическим контроллером, а не процессором.
    И когда я пересел уже на Pentium с Windows'98, мне не понравилось, что больше нельзя работать с портами. Да, система всё ещё позволяла иметь доступ к ним, но мне не нравилось именно то, что процессор всё так же сам и файлы ищет, и контуры заливает…
    Понимаете, о чём я? Современный PC концептуально уступает до сих пор тому «HAL 9000», не смотря даже на все эти Radeon'ы…
    Тот же «HAL 9000» имел модульность и всё можно было конфигурировать налету. И память была ассоциативная…

    Реалии
    Вбиваю список объектно-ориентированных операционных систем и перыми результатами выходят ссылки #1, #2 и #3!
    Вы уже догадываетесь, на что я намекаю и в чём проблема?
    Нету прямых ссылок на реальные нормальные Объектно-Ориентированные Операционные Системы, а есть костыль в лице Объектно-Ориентированной Платформы Windows, которую я в упор не вижу! Вот не вижу я, чтобы в Direct-3D куб был объектом и сфера была объектом. Вот в HTML ссылка <A> - объект, так как срабатывают события, когда на него наводится указатель. А где эти события в том же OpenGL? Надо кучу кода написать с проекцией луча, чтобы выяснить, на какой объект сцены мышка указывает. И, судя по многочисленным темам на разных форумах с элементарными вопросами по интерактивному выделению объектов сцены, всё ещё находится в самом плачевном состоянии на уровне 90-х! Тот же списанный VRML был объектно-ориентированным. А вот WebGL, как и всё остальное - нет…

    Снежный ком
    Меня напрягает всё более гнетущее нагромождение всевозможных библиотек с переходом систем на 64 бита, вместо предложения реально современных решений.
    Ведь задумайтесь сами: Когда памяти под 32-битной платформы стало слишком мало, приняли такое же костыльное решение, как и с регистрами - AX->EAX->RAX и т.п.
    Под теми же 64 битами сейчас и 16 Гб ОЗУ мало! Это же с ума сойти, когда видишь на деградацию программного обеспечения и того же интерфейса Windows.

    Как итог
    Следуя классике жанра - «HAL 9000», свою концепцию Операционной Системы я надумал именно как интерфейсно-портовую…
    Во-первых, через порт мы получаем возможность обмена с конкретным аппаратным объектом. Поэтому, не должно быть портов контроллеров ПДП/НЖМД, а должны быть порты аппаратных объектов файловой системы, которые сами будут обрабатывать запрос по поиску файлов на уровне Облака, как тот же Google.
    Во-вторых, чтобы искать документы в интернете, нет необходимости прокачивать свой браузер до предела. Да, Chrome/FF/Opera требуют обновлений. Но это, в основном, из-за проблем их дыр и маркетинговой политики. На любом кнопочном мобильном телефоне встроенным браузером можно узнать тот же прогноз погоды.

    Тем самым, у меня вся попытка реализации демонстрационного эмулятора моей системы завалилась не по причине моих собственных просчётов и промахов.
    В демонстрации мой код из нескольких in/out-инструкций добавил в окно OpenGL-сферу. То есть, если взять тот же i8086 и подключить к нему 1 Мб ОЗУ, то программа из 20 инструкций способна будет построить простейшую 3D-сцену, если порты ввода-вывода будут очень умными. А говоря проще, железо будет объектно-ориентированным!
    А так как практически не существует никаких нормальных решений и тот же OpenGL никогда не был объектно-ориентированным, то в своём эмуляторе я просто не понял, куда двигаться!
    И пусть даже в реальности тот же «HAL 9000» не работал с портами и был устроен совершенно иначе. Но факт, что клавиатура - отдельный микрокомпьютер и выполняет свои функции в полном объёме, говорит в пользу того, что инженеры дальше так и не продвинулись…
    А именно… Нажимаешь клавишу, генерируется событийное прерывание, читаешь код клавиши. Максимально простая и функционально законченная схема: Объект->Событие->Код.
    Под всё остальное требуется тонны драйверов и гигабайты памяти!!!

    P.S.: Иными словами, я, как идиот, всегда мечтал сделать идеальный компьютер, в котором и 1 Мб памяти достаточен, чтобы туда уместилась та же 3D-Studio MAX, так как код студии манипулировал бы объектами аппаратного уровня…
    Надеюсь, теперь меня поняли абсолютно все!
     
    Последнее редактирование: 4 ноя 2019
  15. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    442
    Paguo_86PK, я бы гуглил не объектно ориентированные ос, а микроядерные операционные системы, потому как мои первые ассоциации к тому что вы хотите, что-то среднее между netbsd и mesh network, может быть QNX и http://www.barrelfish.org будут ближе. Могу ошибаться, так как не знаток этих штук.

    вот наверно забавная штука https://ru.wikipedia.org/wiki/JNode
     
  16. f13nd

    f13nd Active Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    869
    Сценарий для этого кино написали Артур Кларк и Стенли Кубрик и только один из них закончил в 63 году колледж с уклоном на физику и математику. Сцена с постепенным деградированием синтеза голоса и угасанием рассудка машины скорее условность, чем задумка кого-то из авторов, в которую мог бы быть заложен какой-то практический смысл. Это как насмотревшись в асассинс крид взломов ядра ОС путем верчения шара на экране что-нибудь придумать.
     
  17. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    В Windows графика жёстко встроена в ядро и если падает графика, может рухнуть всё.
    В то же время, в том же Linux имеется набор графических/оконных менеджеров с выбором подходящего. И нормально продуманное приложение может пережить их горячее переключение(?), судя по некоторым статьям сравнения различных операционных систем.
    Тем самым, это не притягивание за уши технологий к фантастике, а совершенно реальные вещи. Вот, например, если падает какой-то сервер, его функции на себя берёт другой. Для рядового пользователя сети всё абсолютно прозрачно.
    Или те же дроны, которых фантасты толком и не предсказали: В фильмах они либо слишком милитаризованы, либо слишком умны, либо удел избранных.
    QNX я как-то запускал с дискеты, как и MenuetOS. Кто-то сказал, что моя концепция напоминает Plan_B, только вместо файлов - порты.
     
    Последнее редактирование: 5 ноя 2019
  18. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    442
    так сейчас много чего на гитхабе есть. причем вообще всякого
    jnode вот к примеру https://github.com/jnode/jnode/tree/master/core/src/native/x86
    по проектам можно быстро пробежаться в поисках использования портов, вдруг кто-то думал так же как вы?
     
  19. Paguo_86PK

    Paguo_86PK Руслан

    Публикаций:
    0
    Регистрация:
    8 окт 2007
    Сообщения:
    871
    Адрес:
    Ташкент
    Eщё с первым появлением процессоров Intel порты считались чуть ли ни рудиментом, где-то я читал. В основном, из-за Си, где драйверам легче обрабатывать структуры в памяти, чем инлайнить in/out. Сейчас всё проецируется в память, на сколько можно судить…
    Потому, вряд ли кто-то будет заморачиваться над портами так, как я расписал. В лучшем случае, в эмуляторе будут эмулировать стандартное железо.
     
  20. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    442
    ну возьмите эмулятор малины. это же всё, я так понимаю, не принципиально. Узкое место - реализация IPC. Какая принципиальная разница, сузили вы дыкру до апи сисколов, или до сообщений mqtt сервера? Вы не собираетесь строить общий рантайм, вы создаете взаимодействие рантаймов, словно взаимодействие объектов. И по этим рантаймам, словно по сети водопроводных труб, хотите запустить куски кода. У вас получается раньше рантайм был статичный, а теперь динамично изменяющийся. Межпроцессное взаимодействие должно быть отличным - принципиально. Нужен прототип. Вокруг много заготовок, эмуляторы железа, готовые оси отвязанные от железа, как будет выглядеть межпроцессное взаимодействие? Но эта задача из нерешенных(наверно, как минимум не публично). Скорее всего, я притягиваю ваши идеи к своим, я хотел когда-то сделать процессы как активных агентов из обучения с подкреплением, которые перемещаются по разным рантаймам, но мне не хватает квалификации для создания прототипа.