|
nedoPC.orgElectronics hobbyists community established in 2002 |
|
Разработка ПК экзотической архитектуры
Разработка ПК экзотической архитектуры
Author |
Message |
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Навеялo из отсюда, так как лет 20 подобное уже обдумывал. А именно… Как показывает многократная практика дискуссий на эту тему, многие в упор не понимают, что мною имеется ввиду. И приходится идти на всяческие ухищрения, чтобы всё стало простым и доходчивым. И в этот раз я попытаюсь вернуться к этому вопросу, но с несколько другого ракурса на примере DOS. Для начала, сравните два кода: "Классическая DOS-версия" | | | | Code: org 00100h
Start: mov dx,sHello ; Приветствование mov ah,009h ; Код функции печати с долларовым терминатором int 021h ; Вызов DOS-API: Печатаем сообщение на экран mov ah,008h ; Код функции ввода символа с ожиданием без эха @wait_cr: int 021h ; Обращаемся к DOS-API и ожидаем ввод символа cmp al,00Dh ; Если это не клавиша Enter jne @wait_cr ; Необходимо дождаться её нажатия mov ah,000h ; Нужно изменить режим экрана mov al,007h ; Режим монохромного текста 80x25 int 010h ; Обращаемся к BIOS-API и переключаем видеорежим @wait_esc: mov ah,008h ; Код функции ввода символа с ожиданием без эха int 021h ; Обращаемся к DOS-API и ожидаем ввод символа cmp al,01Bh ; Если это клавиша Esc je @exit ; Завершим нашу задачу mov ah,002h ; Функция DOS-API для печати символа mov dl,al ; Регистр передачи кода символа int 021h ; Обращаемся к DOS-API jmp @wait_esc @exit: mov ah,04Ch ; Готовимся к завершению задачи mov al,dl ; Вернём код предыдушей клавиши до Esc int 021h ; Возвращаемся в DOS
sHello: db 'Hello, World!',00Dh,00Ah db 'Press ENTER key to continue...$' | | | | |
"Аппаратно-портовая версия DOS" | | | | Code: Start: mov ax,sHello ; Адрес строки в аккумулятор mov dh,021h ; Индекс страницы портов DOS mov dl,009h ; Индекс порта печати строки out dx,ax ; Пишем в порт адрес и строка печатается mov dl,008h ; Индекс порта ввода символа с ожиданием @wait_cr: in al,dx ; Вводим символ с ожиданием cmp al,00Dh ; Если это не код клавиши Enter jne @wait_cr ; Дожидаемся её нажатия mov dh,010h ; Индекс страницы портов экрана mov dl,000h ; Индекс порта режима экрана mov al,007h ; Текстовый монохромный режим 80x25 out dx,al ; Записью в порт меняем режим mov dh,021h ; Возвращаемся к портам DOS @wait_esc: mov dl,008h ; Индекс порта ввода символа с ожиданием in al,dx ; Вводим символ. Если нет, генерируется сигнал Wait cmp al,01Bh ; Если это клавиша Esc je @exit ; Наша задача завершится mov dl,002h ; Индекс порта вывода символа out dx,al ; Выводим код символа в порт для его печати jmp @wait_esc @exit: mov dl,04Ch ; Индекс порта ErrorLevel out dx,ax ; Вот здесь не 256, а 65536 комбинаций hlt ; Через hlt достигается терминация процесса
sHello: db 'Hello, World!',00Dh,00Ah db 'Press ENTER key to continue...',0 | | | | |
Видно, что вторая версия не использует никаких вызовов системных функций и под них не нужно резервировать ни байта системного кода. Программа может иметь в своём распоряжении до 1 Мб памяти, так как и BIOS, как таковой, находится в теневой странице памяти. В этом примере прикладная программа не нуждается ни в каком системном коде, так как нужно просто программировать порты. Плюсы: Если вы когда-нибудь программировали на Бейсике, то могли сталкиваться с ситуацией, когда необходимо было обратиться к функции DOS-API через USR. Необходимо было верно выбрать сегмент памяти под POKE, которыми записывался машинный код. Туда же вписывались и все нужные параметры. В общем, программисту-новичку приходилось не очень сладко, так как с высокого уровня необходимо было спуститься на самый элементарный уровень! А если бы существовала аппаратная DOS-машина, на уровне Бейсика достаточно было оператором OUT и функцией IN обратиться к портам и всё. Никаких POKE и USR! Всё на достаточно высоком уровне остаётся. Минусы: - Необходимо довольно умное и дорогое железо, чтобы обрабатывать обращения ко всем прописанным портам на высоком уровне. Как вариант - карточка с дополнительным сервис-процессором, отдельной памятью ОЗУ и ПЗУ под всё функциональное API
- Либо необходим, как минимум, процессор i286, где уже имелись нормальные механизмы защиты памяти и портов ввода-вывода. Лучше, конечно, процессор i386 с полной виртуализацией памяти и портов. Через механизмы исключений система просто определяет, к какому порту приложение пыталось вести доступ и просто исполняет высокоуровневую функцию
- Обращение к портам ввода-вывода занимает относительно много машинного времени по тактам. Однако, учитывая, что приложение обращается не к каким-то там элементарным периферийным регистрам, а программирует DOS-операции высокого уровня, то по скорости обращение к порту будет не хуже классического call/int вызова
XXI век: Если бы в своё время с появлением i286 сама DOS совершила бы «квантовый скачок» и перешла бы на уровень аппаратной виртуализации своего функционала, то и Windows могла бы полностью уйти на тот же уровень… При этом, необходимость в верхних 2 Гб памяти под системное API полностью отпала бы. Приложению можно предоставить все 4 Гб адресного пространства, так как вместо загрузки системных библиотек, код которых нам не доступен на чтение и не так важен, ведь он просто засоряет где-то адресное пространство и нужен лишь для call-вызовов. Вместо этого, имелись бы порты ввода-вывода под такие высокие уровни, как OpenAL, OpenGL, DirectSound, DirectPlay, DirectInput, GDI и т.д. Никаких подгружаемых системных библиотек. Только порты. При этом, даже сам DOS формата *.com мог бы несколькими строчками ассемблера запрограммировать порт окна и OpenGL, выведя туда 3D-сферу. То есть, вместо кривой виртуализации DOS-машины, мы бы имели бы эволюционное развитие DOS-программ под Windows-среду. P.S.: А что мы получили? У Linux - int 80h, у Windows - int 2Eh… А как итог, *.com файлы на современной системе вообще не поддерживаются.
Last edited by Paguo-86PK on 01 Nov 2019 13:48, edited 1 time in total.
|
01 Nov 2019 11:17 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
A вот практически, можно пойти дальше. Например, онлайн доступен запуск той же Windows'95. Ничего не мешает сделать элементарный эмулятор того же i8086 и отрабатывать карту портов. Лет 12 тому назад я попытался написать подобный эмулятор и с помощью нескольких строчек ассемблера вывел в окно сферу средствами OpenGL. Но на том и застрял, так как идея есть, а чёткого плана и продуманной концепции - нет. Ссылкиhttp://blagin.ru/sozdanie-drajverov-chast-4-obmen-dannymi/http://vsokovikov.narod.ru/New_MSDN_API/Services/fn_createservice.htmhttp://vsokovikov.narod.ru/New_MSDN_API/Services/fn_openscmanager.htmhttps://ruskod.net/ms-rem.dot-link.net/ch008_06.html?kdePLRpcxIoSednzB5nocucqBOUwzlZF=1
Last edited by Paguo-86PK on 14 Nov 2019 18:22, edited 2 times in total.
|
01 Nov 2019 11:17 |
|
|
Konstantin18
Maniac
Joined: 15 Jan 2019 15:48 Posts: 326 Location: Украина, Луганская обл.
|
Paguo-86PK, в вашей "аппаратно-портовой версии" есть тот-же самый код библиотек, только он спрятан за "портом" и для его выполнения нужен дополнительный процессор. Это имеет смысл, если производительность основного не достаточна. Кроме того обновление этого кода маловозможно (как пример БИОС EGA адаптера).
|
01 Nov 2019 13:44 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Мне кажется, это - не проблема. Уже на i386 35 лет назад можно было всё это дело виртуализовать. Но для системы из пяти i8080 это тоже вполне реально. Так как, по-сути, будем иметь 4 специализированных компьютеров и один - основной-прикладной. А через сетевые карты обеспечивать магистральные шины можно практически мгновенно. Сейчас любая система перепрошивается любым доступным способом.
|
01 Nov 2019 14:02 |
|
|
Konstantin18
Maniac
Joined: 15 Jan 2019 15:48 Posts: 326 Location: Украина, Луганская обл.
|
Я просто не пойму основной цели, которая преследуется при разработке данного устройства, извините.
|
02 Nov 2019 00:56 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Eсть одна статья про конструктор на базе PIC32 со встроенным Бейсиком: Всегда задавался вопросом о возможности построения ЭВМ, где программируешь на ассемблере как на языке высокого уровня. Выше я уже сказал, что в Бейсике POKE/USR очень узкое место и программы теряют портабельность. Тогда как работа с портами через IN/OUT универсальна в своём роде, если вместо элементарного железа через них «программируешь OS»… Вот объясню на пальцах. Допустим у наш две машины: Первая - на i8080, вторая - на i8086. На уровне ассемблера они напрямую не совместимы. А вот диалекты Бейсика могут иметь две единственные операции - IN/OUT. Подключив Принтер «Электроника СМ6337-М1» мы можем на обеих машинах печатать абсолютно идентичные графики, так как принтеру всё равно от какого процессора он получает команды по интерфейсу. Главное, чтобы соблюдался протокол. В своё время я этим принтером печатал ещё на Pentium-90 MHz под Windows'98. Естественно, и на РАДИО-86РК, и на ZX-Spectrum принтер будет работать одинаково, если посылать правильные цепочки данных прямо в порты. А теперь представим, что вместо принтера у нас уже интерактивный терминал с 3D-графикой, мышью и интернетом. Но, он работает как и принтер - через порт. Получается, и на РАДИО-86РК с помощью Бейсика, и на ПОИСКе мы сможем построить 3D-сцену. При этом, сама 3D-периферия в тысячу раз будет мощнее самого управляющего компьютера! (Хотя, тот же Radeon мощнее центрального процессора - факт…) А мораль идеи в следующем: Раньше был стандарт MSX, который гарантировал работу любых устройств. И у меня в 90-х появилась мысль, что можно было бы построить аппаратную операционную систему. Позволите немного фантазии с ретроспективой? В 90-е была популярна одна из интерактивных телепередач: "Позвоните Кузе" Тогда у меня появилась идея, похожая на современные Облачные технологии. Допустим в студии установлен мощный кластер со всем необходимым программным обеспечением. А мы посылаем ему команды через «бутылочное горлышко» - модемом на 14400 бод… Дозвонившись на BBS мы могли на терминал отправлять элементарные команды в другой город, а результат видеть через приём сигнала СТВ на бытовой телевизор. Тем самым, даже через РАДИО-86РК с модемом и Бейсиком можно было дозвониться до BBS, чтобы отослать туда команды построения собственной сцены в 3D, заранее оплатив услугу. Таким образом, сам РАДИО-86РК мог построить 3D-сцену с громадным разрешением и тенями, отправляя лишь команды на уровне «ИсточникСвета#1 в такую-то позицию», «Переместить Камеру#1 в такую-то позицию», «Построить куб такого-то материала и такого-то размера», «Использовать текстуру из библиотеки с изображением бабочек #17879» и т.п… То есть, работаем как с принтером, но вместо управления кареткой и бумагой, используется очень высокоуровневый интерфейс. P.S.: Надеюсь, хоть чуточку приблизил вас к пониманию концептуальной мечты детства?
|
02 Nov 2019 03:01 |
|
|
Icer
Senior
Joined: 21 Aug 2018 07:39 Posts: 163 Location: Кемеровская обл.
|
ПК выполняет команды РК(ZX), где то уже такое было. Если Вам не хватает производительности и появляется желание приделать к РК к ПК, не томитесь и переходите на ПК. ПК и без РК вполне себе так. Хотя если душа очень просит, то никто Вам не советчик.
|
02 Nov 2019 03:40 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Я попытался описать модель Объектно-Ориентированного Компьютера… "Много текста, но раскрывается суть" Немного лирикиВ средние 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, так как код студии манипулировал бы объектами аппаратного уровня… А в реальности, на уровне высокой индустрии подобные задачи до сих пор не решены.
|
03 Nov 2019 17:42 |
|
|
Icer
Senior
Joined: 21 Aug 2018 07:39 Posts: 163 Location: Кемеровская обл.
|
Если в Вашем идеальном компьютере(терминале) всего 1Мб ОЗУ, то остальные терабайты распределены по исполнительным устройствам. Терминал и исполнительные устройства сами по себе(по отдельности) бесполезны. ПК с мощным ЦП и большим объемом ОЗУ более универсален, а следовательно дешевле. При отсутствии аппаратных декодеров способен декодировать аудио/видео и нарисовать программно не очень сложную 3D сцену. Сложность OpenGL это дань универсальности, Вы ведь не только сферы хотите рисовать, но и сложные поверхности. Взгляните на современные поделия игровой индустрии, слабый ЦП не осиливает передачу объема данных в видеокарту и это в прямой связке ЦП>шина>видеокарта. Вы ведь к этому и идете: терминал(ЦП), каналы связи(шина).
Драйверная модель ОС Windows как раз избавляет программиста от работы с портами, предоставляя API для работы с устройствами как с объектами. В некоторых случаях возможна программная замена отсутствующих как самих устройств так и их возможностей т.е. эмуляция. Ваш терминал на такое не будет способен.
|
03 Nov 2019 19:59 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Видимo, спойлер проигнорирован был…
|
03 Nov 2019 21:35 |
|
|
SAA
Senior
Joined: 12 Jul 2016 21:30 Posts: 136
|
Когда приводите аналогию создания через порт 3D-объекта, то что подразумеваете под этим: полный текстурированный 3D-объект (к примеру дом), текстурированная поверхность, просто треугольная поверхность с нормалью?
|
03 Nov 2019 23:15 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Eсли говорить точно, то объектная модель OpenGL должна предоставлять возможность той же элементарной сфере, как примитиву, назначать различные события, каскадные стили с морфингом и анимацией. Классически за секунду само приложение обязано десятки раз в секунду перерисовывать фреймы 3D-сцены. Тогда как объектный OpenGL, как и 3DMLW позволил бы в порт отправить указатель на описание сцены, а дальше лишь обрабатывать события (коллизии, наведение мыши, уход в тень и т.д.). И сцена должна иметь иерархию.
|
04 Nov 2019 00:45 |
|
|
SAA
Senior
Joined: 12 Jul 2016 21:30 Posts: 136
|
Стало понятней, но в этом случае память основного процессора передающего задание должна быть видна другому практически полностью, объем сцены по указателю многие мегабайты, если не больше. Рассматриваете проблемы заключаемые в таком способе передачи данных между процессорами?
|
04 Nov 2019 01:29 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Вoт именно, дело всё в том, что на шину процессора подключается периферийный микроконтроллер, который обрабатывает все обращения к портам и имеет доступ ко всей памяти запрашивающего процессора. - out dx,eax - Передать адрес пакета. Здесь периферийный контроллер получает указатель на адрес в памяти приложения
- out dx,ax - Выбрать слой данных (reserved)
- out dx,al - Переключить статус пакета с указанием его направления. Если направление исходящее, по полученному раннее адресу считывается в сетевой буфер весь пакет из памяти приложения с проверкой целостности данных подсчётом CRC и открывается межсетевая передача до целевого пункта. Если направление запрашивающее, из целевого пункта запрашивается пакет, который затем будет записан в память приложения
- in eax,dx - Прочесть пакетное CRC
- in ax,dx - Прочесть статус слоя (reserved)
- in al,dx - Прочесть статус пакета
Видно, что данные по одному и тому же порту не равнозначны. В варианте с i386 всё проще, так как сама Операционная Система берёт на себя функцию периферийного контроллера и обрабатывает любой доступ к портам от приложения. При этом меняется принцип работы некоторых операций. - rep outsd - Передать данные по адресу esi сервисному процессу с индексом edx. В ecx указывается объём данных
- rep outsw - Передача между слоями (reserved)
- rep outsb - Биндинговая передача (reserved)
- rep insd - Получить данные в буфер по edi от сервисного процесса с индексом edx в размере не более, чем указано в ecx
- rep insw - Приём из прослойки (reserved)
- rep insb - Биндинговый приём (reserved)
Здесь видно, что вместо 16-битного dx читается полное слово 32 бит регистра edx, так как ядро операционной системы имеет доступ к контексту приложения и возможность читать любые регистры. Тем самым, та же «rep outsd» для приложения сработает как «nop» без цикла, но сервису откроется системой окно по esi размером ecx. Тем самым, само приложение машинным временем может даже и "не почувствовать" эту «rep insd» даже размером ecx в 1 Гб, так как цикла не будет, но система переназначит окна памяти так, чтобы по edi открылся доступ к системной куче 1 Гб с доступом к данным определённого сервиса… То есть, здесь «rep insd» работает просто как «VirtualLock» (например) и никакого цикла не происходит…
|
04 Nov 2019 21:21 |
|
|
SAA
Senior
Joined: 12 Jul 2016 21:30 Posts: 136
|
Детализируйте процесс доступа за пакетом данных. Почему появился вдруг "сетевой буфер", откуда? Каким физическим методом процессор получающий задание получает и доступ в память управляющего им процессора. Как Вы рассчитываете физически развязать память между процессорами? Не один из процессоров не должен останавливаться при доступе к памяти другого, какие у Вас варианты?
|
05 Nov 2019 01:46 |
|
|
Who is online |
Users browsing this forum: No registered users and 5 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|