nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 13 Nov 2019 11:33



Reply to topic  [ 27 posts ]  Go to page 1, 2  Next
Разработка ПК экзотической архитектуры 

Обуждаемая тема
Да, автору удалось донести концептуальный смысл идеи 10%  10%  [ 1 ]
Да, автор старался разъяснить свою идею, но всё запутано 20%  20%  [ 2 ]
Идея, в принципе, понятна. Однако, в XXI веке многое потеряло смысл 20%  20%  [ 2 ]
В те времена такое было бы слишком сложно, дорого и никому не нужно 10%  10%  [ 1 ]
Вообще ничего не понял. Причём тут API, порты и DOS? 40%  40%  [ 4 ]
Вообще какая-то ересь. Автор DOS-Box пытается переделать? 0%  0%  [ 0 ]
Total votes : 10

Разработка ПК экзотической архитектуры 
Author Message
Online
Fanat
User avatar

Joined: 12 Apr 2011 21:43
Posts: 93
Location: Tashkent
Reply with quote
Навеял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! Всё на достаточно высоком уровне остаётся.

Минусы:
  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-среду.

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


Last edited by Paguo-86PK on 01 Nov 2019 14:48, edited 1 time in total.



01 Nov 2019 12:17
Profile WWW
Online
Fanat
User avatar

Joined: 12 Apr 2011 21:43
Posts: 93
Location: Tashkent
Reply with quote
A вот практически, можно пойти дальше.
Например, онлайн доступен запуск той же Windows'95. Ничего не мешает сделать элементарный эмулятор того же i8086 и отрабатывать карту портов.

Лет 12 тому назад я попытался написать подобный эмулятор и с помощью нескольких строчек ассемблера вывел в окно сферу средствами OpenGL. Но на том и застрял, так как идея есть, а чёткого плана и продуманной концепции - нет.


01 Nov 2019 12:17
Profile WWW
Senior

Joined: 15 Jan 2019 16:48
Posts: 127
Location: Украина, Луганская обл.
Reply with quote
Paguo-86PK, в вашей "аппаратно-портовой версии" есть тот-же самый код библиотек, только он спрятан за "портом" и для его выполнения нужен дополнительный процессор.
Это имеет смысл, если производительность основного не достаточна.
Кроме того обновление этого кода маловозможно (как пример БИОС EGA адаптера).


01 Nov 2019 14:44
Profile
Online
Fanat
User avatar

Joined: 12 Apr 2011 21:43
Posts: 93
Location: Tashkent
Reply with quote
Konstantin18 wrote:
Paguo-86PK, в вашей "аппаратно-портовой версии" есть тот-же самый код библиотек, только он спрятан за "портом" и для его выполнения нужен дополнительный процессор.
Quote:
Минусы:
  1. Необходимо довольно умное и дорогое железо, чтобы обрабатывать обращения ко всем прописанным портам на высоком уровне. Как вариант - карточка с дополнительным сервис-процессором, отдельной памятью ОЗУ и ПЗУ под всё функциональное API
  2. Либо необходим, как минимум, процессор i286, где уже имелись нормальные механизмы защиты памяти и портов ввода-вывода. Лучше, конечно, процессор i386 с полной виртуализацией памяти и портов. Через механизмы исключений система просто определяет, к какому порту приложение пыталось вести доступ и просто исполняет высокоуровневую функцию
Мне кажется, это - не проблема. Уже на i386 35 лет назад можно было всё это дело виртуализовать.
Но для системы из пяти i8080 это тоже вполне реально. Так как, по-сути, будем иметь 4 специализированных компьютеров и один - основной-прикладной. А через сетевые карты обеспечивать магистральные шины можно практически мгновенно.
Konstantin18 wrote:
Кроме того обновление этого кода маловозможно (как пример БИОС EGA адаптера).
Сейчас любая система перепрошивается любым доступным способом.


01 Nov 2019 15:02
Profile WWW
Senior

Joined: 15 Jan 2019 16:48
Posts: 127
Location: Украина, Луганская обл.
Reply with quote
Я просто не пойму основной цели, которая преследуется при разработке данного устройства,
извините.


02 Nov 2019 01:56
Profile
Online
Fanat
User avatar

Joined: 12 Apr 2011 21:43
Posts: 93
Location: Tashkent
Reply with quote
Konstantin18 wrote:
Я просто не пойму основной цели, которая преследуется при разработке данного устройства,
извините.
Eсть одна статья про конструктор на базе PIC32 со встроенным Бейсиком:
Image

Всегда задавался вопросом о возможности построения ЭВМ, где программируешь на ассемблере как на языке высокого уровня. Выше я уже сказал, что в Бейсике 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 04:01
Profile WWW
Novelist
User avatar

Joined: 21 Aug 2018 08:39
Posts: 49
Location: Кемеровская обл.
Reply with quote
ПК выполняет команды РК(ZX), где то уже такое было.
Если Вам не хватает производительности и появляется желание приделать к РК к ПК, не томитесь и переходите на ПК.
ПК и без РК вполне себе так.
Хотя если душа очень просит, то никто Вам не советчик.


02 Nov 2019 04:40
Profile
Online
Fanat
User avatar

Joined: 12 Apr 2011 21:43
Posts: 93
Location: Tashkent
Reply with quote
Icer wrote:
ПК выполняет команды РК(ZX), где то уже такое было.
Я попытался описать модель Объектно-Ориентированного Компьютера…
 "Много текста, но раскрывается суть"
Немного лирики
В средние 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 18:42
Profile WWW
Novelist
User avatar

Joined: 21 Aug 2018 08:39
Posts: 49
Location: Кемеровская обл.
Reply with quote
Если в Вашем идеальном компьютере(терминале) всего 1Мб ОЗУ, то остальные терабайты распределены по исполнительным устройствам.
Терминал и исполнительные устройства сами по себе(по отдельности) бесполезны.
ПК с мощным ЦП и большим объемом ОЗУ более универсален, а следовательно дешевле. При отсутствии аппаратных декодеров способен декодировать аудио/видео и нарисовать программно не очень сложную 3D сцену.
Сложность OpenGL это дань универсальности, Вы ведь не только сферы хотите рисовать, но и сложные поверхности.
Взгляните на современные поделия игровой индустрии, слабый ЦП не осиливает передачу объема данных в видеокарту и это в прямой связке ЦП>шина>видеокарта.
Вы ведь к этому и идете: терминал(ЦП), каналы связи(шина).

Драйверная модель ОС Windows как раз избавляет программиста от работы с портами, предоставляя API для работы с устройствами как с объектами.
В некоторых случаях возможна программная замена отсутствующих как самих устройств так и их возможностей т.е. эмуляция.
Ваш терминал на такое не будет способен.


03 Nov 2019 20:59
Profile
Online
Fanat
User avatar

Joined: 12 Apr 2011 21:43
Posts: 93
Location: Tashkent
Reply with quote
Icer wrote:
Ваш терминал на такое не будет способен.
Видимo, спойлер проигнорирован был…


03 Nov 2019 22:35
Profile WWW
Fanat

Joined: 12 Jul 2016 22:30
Posts: 97
Reply with quote
Paguo-86PK wrote:
А в реальности, на уровне высокой индустрии подобные задачи до сих пор не решены.

Когда приводите аналогию создания через порт 3D-объекта, то что подразумеваете под этим: полный текстурированный 3D-объект (к примеру дом), текстурированная поверхность, просто треугольная поверхность с нормалью?


04 Nov 2019 00:15
Profile
Online
Fanat
User avatar

Joined: 12 Apr 2011 21:43
Posts: 93
Location: Tashkent
Reply with quote
SAA wrote:
Когда приводите аналогию создания через порт 3D-объекта, то что подразумеваете под этим: полный текстурированный 3D-объект (к примеру дом), текстурированная поверхность, просто треугольная поверхность с нормалью?
Eсли говорить точно, то объектная модель OpenGL должна предоставлять возможность той же элементарной сфере, как примитиву, назначать различные события, каскадные стили с морфингом и анимацией.
Классически за секунду само приложение обязано десятки раз в секунду перерисовывать фреймы 3D-сцены. Тогда как объектный OpenGL, как и 3DMLW позволил бы в порт отправить указатель на описание сцены, а дальше лишь обрабатывать события (коллизии, наведение мыши, уход в тень и т.д.).
И сцена должна иметь иерархию.


04 Nov 2019 01:45
Profile WWW
Fanat

Joined: 12 Jul 2016 22:30
Posts: 97
Reply with quote
Paguo-86PK wrote:
позволил бы в порт отправить указатель на описание сцены, а дальше лишь обрабатывать события (коллизии, наведение мыши, уход в тень и т.д.).И сцена должна иметь иерархию.


Стало понятней, но в этом случае память основного процессора передающего задание должна быть видна другому практически полностью, объем сцены по указателю многие мегабайты, если не больше. Рассматриваете проблемы заключаемые в таком способе передачи данных между процессорами?


04 Nov 2019 02:29
Profile
Online
Fanat
User avatar

Joined: 12 Apr 2011 21:43
Posts: 93
Location: Tashkent
Reply with quote
SAA wrote:
Стало понятней, но в этом случае память основного процессора передающего задание должна быть видна другому практически полностью, объем сцены по указателю многие мегабайты, если не больше. Рассматриваете проблемы заключаемые в таком способе передачи данных между процессорами?
В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 22:21
Profile WWW
Fanat

Joined: 12 Jul 2016 22:30
Posts: 97
Reply with quote
Paguo-86PK wrote:
...., по полученному раннее адресу считывается в сетевой буфер весь пакет из памяти приложения с проверкой целостности данных подсчётом CRC и открывается межсетевая передача до целевого пункта. Если направление запрашивающее, из целевого пункта запрашивается пакет, который затем будет записан в память приложения


Детализируйте процесс доступа за пакетом данных. Почему появился вдруг "сетевой буфер", откуда? Каким физическим методом процессор получающий задание получает и доступ в память управляющего им процессора. Как Вы рассчитываете физически развязать память между процессорами? Не один из процессоров не должен останавливаться при доступе к памяти другого, какие у Вас варианты?


05 Nov 2019 02:46
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 27 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: Paguo-86PK and 2 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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.