Отличный канал и отличное видео про io подсистему компьютера и ее устройства.
Автор рассмотрел Memory-mapped IO vs Port-mapped IO, programmed I/O (Polling) vs Interrupt-Driven I/O
Почему memory mapped IO все-таки не самый лучший способ обустраивать взаимодействие с железом. Особенно
см. слайд на https://youtu.be/tadUeiNe5-g?si=Hv7x9iKaSgqM-2eA&t=1284
Объяснил почему ранние компьютеры были несовместимы -- всё делалось через mmi, но у каждого по-своему и гвоздями
прибивалось к материнке.
В общем, крайне годное, кмк, базовое видео про основы. Поэтому и на этом форуме.
ЗЫ: Странно, что про DMA немного, но там, на yt, есть на эту тему неплохие комментарии.
Здравствуйте, Sharov, Вы писали:
S>Отличный канал и отличное видео про io подсистему компьютера и ее устройства. S>Автор рассмотрел Memory-mapped IO vs Port-mapped IO, programmed I/O (Polling) vs Interrupt-Driven I/O S>Почему memory mapped IO все-таки не самый лучший способ обустраивать взаимодействие с железом. Особенно S>см. слайд на https://youtu.be/tadUeiNe5-g?si=Hv7x9iKaSgqM-2eA&t=1284
У автора каша в голове и ролик тупой в доску.
Во-первых, отличие memory-mapped I/O и port-mapped I/O не играет такого принципиального значения. От того, что на x86 отдаются IN и OUT, это всё равно идёт через CPU. А на другой архитектуре, как ARM, уже в процессоре может быть заложено, например, что доступ по адресам 0÷3FFF_FFFF пошёл в оперативку, 4000_0000÷7FFF_FFFF — в ПЗУ, а 8000_0000÷BFFF_FFFF в I/O, причём к каждому своя шина своей специфической конструкции. Вообще отдельные команды IN/OUT это только линия 8080->x86, а остальные ничего, живут без них, но получая сходные результаты.
MMIO по сравнению с PMIO вкуснее несколькими вещами, про которые автор ни слова не сказал:
1. Для устройств типа видеоадаптера, сетевухи... можно отобразить их собственную память, вместо того, чтобы через регистры гонять данные или выделять куски оперативки для них. Это особенно для современных видеокарт.
2. Память устройства можно отобразить, регулируя доступ к ней у разных процессов. Пример 1 — таймер HPET: во всех современных ОС через него читают текущее время, не переключаясь в режим ядра. Пример 2 — сетевуха, в которой VLANы (или что там ещё будет) распределены между виртуалками, каждая получает свой VLAN через свои странички и думает, что у неё полная сетевуха (или явно знает, что один VLAN, но не имеет проблемы синхронизации с соседями). Во всех случаях нужно выделение по границам страниц виртуальной памяти.
3. Наконец, просто не нужно лишних команд и, при общей шине, отдельного типа обращений по ней.
А принципиально то, что или процессор гоняется сам по каждому байтику (это называется обычно Programmed I/O, PIO), или отдаёт операции с памятью на DMA модуль, который сам это делает. (В PCI, DMA называется busmastering, и ведётся самим устройством через встроенный DMA контроллер, суть та же). Но: если мы говорим про современные (⩾2008) процессоры x86, что Intel, что AMD, то там доступ между памятью и шинами всяких PCI всё равно бегает через процессор, через северный мост, который сейчас встроен в процессор. (А если несколько "камней" и соответственно несколько доменов — то ещё и через шину между ними.) На это не тратится управляющий блок CPU, но сам CPU всё равно участвует в этом.
И вот если расцепить это обратно, сделав мост между памятью и I/O (функция "северного моста") отделённой, то и скорость для чистых I/O операций может стать реально неограниченной (при использовании DMA // busmastering, вестимо). Но, судя по тому, что продолжают держать этот мост в процессоре, пока что отделять его невыгодно.
Далее, interrupt-driven I/O — это вообще не имеет никакого отношения к вопросу скорости одной передачи, это вопрос адекватного написания кода. Если любой код, который может выполняться, должен каждую микросекунду поллить все устройства, то так работать больше чем на пару килобайт не будет. Прерывания нужны для того, чтобы переключиться на специализированный код максимально близко к тому, когда нужно, без изменения(!) всего остального кода. А будет обработчик прерывания перекачивать данные по байтику, или, отметив завершение операции (когда устройство уже всё прочитало или записало), задать новую (если есть) — это одинаково и не зависит от того, MMIO или PMIO: или устройство умеет свою память или DMA, или корячиться по байтику (ладно, по слову).
Такое впечатление, что автор не видит различия между interrupt-driven I/O и DMA (busmastering).
И вот тут как раз стоит вспомнить channel-based I/O: пусть оно и есть только в одной, насколько я знаю, архитектуре (SystemZ): есть отдельные канальные процессоры, или попросту каналы, которые выполняют канальные программы, отдавая команды устройствам, принимая и передавая данные. Хаб, в который включаются канальные процессоры вместе с командными процессорами (обычными CPU), может отрабатывать доступ к памяти от обоих видов наравне, не ходя через CPU.
CBIO имеет свои недостатки. Например, таймер через него будет жутко неэффективен, поэтому в SystemZ он прямо в процессоре явными командами (да-да). Операции типа "запустить и ждать результата", как ожидание входящего пакета в сетевуху, на него плохо ложатся. Зато его колоссальное преимущество — оно проходит с минимальными затратами через виртуализацию: там, где даже у лучшего эмулятора диска на IO пространстве или памяти ты на каждую операцию с регистрами получишь прерывание эмуляции в гипервизор (поэтому драйвера виртуальных устройств стараются делать операции через подготовку структуры в памяти и один вызов гипервизора), тут запуск операции делается что на железе, что в виртуалке одной командой типа start device.
S>Объяснил почему ранние компьютеры были несовместимы -- всё делалось через mmi, но у каждого по-своему и гвоздями S>прибивалось к материнке.
Вообще разные компьютеры между собой не очень совместимы. У одного, например, сетевуха RTL8139, у другого Attansic L3, и оба на материнке. Вот и ищи для каждого свой драйвер.
MMIO или нет, на это не влияло. Разные устройства — разные методы доступа. А когда ты выжимаешь каждый бит — то вообще о совместимости не думают. PMIO тоже различалось. NE2000, 3C905 и DEC Tulip все были сетевухами, но ничего общего в управлении не имели.
Какая-то унификация есть только на CBIO и только для команды "прочитать без особенностей" (код 02), потому что она для загрузки. Остальное — добрая воля (иногда под дулом пистолета или факов от Линуса) производителей железа.
До этого, у массовых компьютеров до PDP-11 вообще не было MMIO. PDP-11 почти первый с таким, а это 1970 год. Типовым тогда было наличие команд типа "отправить байт на перфоленту", "принять код с клавиатуры" — именно так, с фиксацией роли устройства за командой. Гибкости в виде смены адреса не было.
S/360 (предок SystemZ) тут был чуть ли не первый с универсализацией через набор команд типа start device, test device, через канальные процессоры, это 1964-66.
PDP-11 с принципом "у нас всё через чтение-запись памяти, только протокол уточнить и базовый адрес для конкретного экземпляра устройства" стал тем, за кем пошли чуть менее чем все (опять же, кроме IBM). PMIO образца 8080 возник от того, что разнесли в этом процессоре для микроконтроллера операции с памятью из-за другого протокола.
S>В общем, крайне годное, кмк, базовое видео про основы. Поэтому и на этом форуме.
Жаль. Потому что такая чушь только сбивает с толку.
S>ЗЫ: Странно, что про DMA немного, но там, на yt, есть на эту тему неплохие комментарии. S>https://www.youtube.com/watch?v=tadUeiNe5-g
Ну так потому что невежа-автор не отличает DMA от прерываний — потому и немного.
Когда программа на x86 обращается якобы к портам командами IN, OUT (INS, OUTS — туда же):
1. Если порты из диапазона 0CF8÷0CFF: обращение перехватывается и преобразуется в обращение в PCI configuration space. Это отдельный вид общения по PCI, третий, по отношению к операциям с памятью и портами ввода-вывода.
2. Если порты из диапазона 0÷FF: обращение не выходит за пределы пути процессор -> южный мост. У многих стоит ограничение на выпуск на шины, на которых реальные разъёмы внешних устройств.
Когда обращение идёт к адресу в памяти: уже на уровне контроллера памяти (в северном мосту в процессоре) перехватываются обращения к диапазонам: local APIC, I/O APIC, расширенному PCI configuration space, транслируясь в соответствующие внутренние обращения.
Дальше вспоминаем кэши памяти, так что даже то, что якобы вышло в пространство памяти, может иметь совершенно другой характер обращения.
За кэшами стоит наконец контроллер памяти, который разбрасывает согласно своей конфигурации в одну сторону запросы в память (на разные каналы), в другую на шины (через PCI root hub). Запросы на шины отрабатываются мостами, каждый из которых знает диапазон адресов, которым он владеет.
По сказанному, на x86 формальное различие доступа "в память" и "к портам" давно потеряло смысл: реальная картина сложнее. На уровне доступа PCI различие между IoRead, MemRead, ConfRead это только разные значения четырёхбитного поля типа операции. (Да, есть потоковые чтения-записи, принципиально не влияют.) Остаётся то, что портов всего 2↑16, поэтому никакую реальную память на них не замапить и в стиле "прочесть N байт из последовательного блока" с ними не делают. А расширять не видят смысла, почти всё проще перекинуть на память.
Вывод о содержании видео тот же.
The God is real, unless declared integer.
Re[2]: Отличное видео про io подсистему компьютера.
Здравствуйте, netch80, Вы писали:
N>Ну так потому что невежа-автор не отличает DMA от прерываний — потому и немного.
Во первых, порекомендуй видео лучше. А во вторых, в каком то виде про прерывания он так или иначе сказал. Только без малейших подробностей, но если копать — там закопаешься, особенно если еще разные архитектуры. Основное так или иначе в видео сказано, и где там равенство DMA от прерываний я не очень понимаю, даже близко такого не увидел. И там много чего не сказано, что хотелось бы знать. Например как разные устройства делят адресное пространства, как драйвер узнает, что такой то адрес будет использоваться именно такой видеокартой и отображать адреса нужно именно сюда, как разрешаются конфликты если поставили 2 видеокарты, особенно интересно про видеокарты встроенную в процессор.
Да и вообще, как эти шины все работают я не понимаю лично вообще ни черта, начиная с шины ISA, про PCI и говорить не стоит. Когда понимал — тогда было просто — на шину были выведены большинство контактов процессора, а далее уже пошли эти мосты и уже понимания как это все работает через эти мосты нет ни черта! Понимания в деталях естественно, включая всякие Plug And Play и т.д. А знать иногда б не помешало, например какого хрена USB устройства периодически отваливаются. А там ведь лютая жуть идет, мало того что через чипсет, так потом может идти устройства через USB разветвители — уже давно это работает блин как магия для меня. Общий принцип то понятен — прерывания, DMA и таймер, все как раньше, но как именно это все мапится на адресное пространство, что происходит при включении — вообще темный лес.
Re[3]: Отличное видео про io подсистему компьютера.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, netch80, Вы писали:
N>>Ну так потому что невежа-автор не отличает DMA от прерываний — потому и немного. E>Во первых, порекомендуй видео лучше.
Эээ... почему это я должен рекомендовать _видео_? Это наименее подходящий формат для объяснения подобных вещей. Видео полезно там, где что-то показываешь и иначе слишком долго и занудно рассказывать про «вот тот зелёный элемент который второй слева и на котором написано «хрен», но на самом деле там горчица, что и показано на нём же рисунком в стиле порошка».
Такие вещи подаются текстом. Возможно, с картинками. И вообще, можно начать с книг Таненбаума, Иртегова и прочих, кто писал про это...
E> А во вторых, в каком то виде про прерывания он так или иначе сказал. Только без малейших подробностей, но если копать — там закопаешься, особенно если еще разные архитектуры.
"В каком-то виде" он сказал, да, но совсем не то, что надо было сказать.
E> Основное так или иначе в видео сказано, и где там равенство DMA от прерываний я не очень понимаю, даже близко такого не увидел.
В том, что то, что он сказал про прерывания, если хоть как-то попытаться конструктивно понять, то это применимо именно для DMA. Иначе противопоставления с PIO в принципе быть не может, PIO не противопоставляется прерываниям, а дополняет (как одно из) их до полного механизма.
E> И там много чего не сказано, что хотелось бы знать.
Да. Лучше сказать, что там вообще ни о чём.
E> Например как разные устройства делят адресное пространства,
При правильной настройке они получают разные адреса. Настройкой занимается BIOS или OS в случае PCI (и ISA PnP, было когда-то такое), или производитель карт плюс админы (если могут переключателями менять) в случае ISA. Главное, что таки в современном мире эти адреса у каждого устройства можно менять в широких пределах.
E> как драйвер узнает, что такой то адрес будет использоваться именно такой видеокартой
Зависит от ОС. Но в общем случае его вызывает ОС со словами "гляди, тут, кажется, для тебя устройство" и предоставляет некую ссылку (указатель), по которой можно найти те адреса, которые задала ОС (поменяла после BIOS или нет, уже следующий вопрос).
E> и отображать адреса нужно именно сюда,
Этого не понял.
E> как разрешаются конфликты если поставили 2 видеокарты,
На ISA так нельзя было. На PCI они просто получат разные адреса в процессе первичной настройки, а метод детекта типа устройства в PCI даст, что ОС будет знать, что тут таки видеокарты, и позовёт драйвера соответственно типу.
У каждого устройства на PCI можно получить фиксированные данные — пару id vendor+device (ну ещё есть такие же для поставщика, иногда зовётся не device id, а card id), по ним в базе в самой ОС и ищется драйвер. Как это сделано — зависит от ОС. Например, FreeBSD предпочитает подход, где в данных драйвера вкомпилирован список пар таких id.
E> особенно интересно про видеокарты встроенную в процессор.
Она выглядит точно так же, как видеокарта, только находится в современных процессорах на шине 0, которая не выходит за пределы процессора.
Дальше уже дело BIOS и ОС опознать, какая карта активна — например, спросить каждую, вставлен ли в неё хоть какой-то шнурок от монитора. Но тут я уже деталей не знаю. Возможно, данные ещё и передаются по наследству от BIOS.
E>Да и вообще, как эти шины все работают я не понимаю лично вообще ни черта, начиная с шины ISA, про PCI и говорить не стоит. Когда понимал — тогда было просто — на шину были выведены большинство контактов процессора, а далее уже пошли эти мосты и уже понимания как это все работает через эти мосты нет ни черта!
Про мост достаточно сказать простую вещь: он слушает обращения к нему и если комбинация тип+адрес входит в диапазон настроенного у него, он пробрасывает в подчинённую сторону, иначе игнорирует.
E> Понимания в деталях естественно, включая всякие Plug And Play и т.д. А знать иногда б не помешало, например какого хрена USB устройства периодически отваливаются.
Про USB я уже тут ничего не скажу. Может, драйвер плохо рассчитывает толщины потоков и игнорирует какие-то устройства. Тут надо детали знать.
E> А там ведь лютая жуть идет, мало того что через чипсет, так потом может идти устройства через USB разветвители — уже давно это работает блин как магия для меня.
Да там нет особой магии и жути. Хост имеет пул номеров (от 1 до 127), которые могут назначаться устройствам. Хаб умеет запросы сверху, если знает такое устройство, передать вниз к устройству (или другому хабу), а снизу от устройства — передать наверх. Ну и хаб умеет определять факт подключения устройства и транслировать общение с ним, пока не задан номер. В общем и всё.
Жуть там начинается, когда распределяются полосы трафика. И то, возможно, это я не видел описания, как это делать прямо и ровно.
E> Общий принцип то понятен — прерывания, DMA и таймер, все как раньше, но как именно это все мапится на адресное пространство, что происходит при включении — вообще темный лес.
Ну можешь поспрашивать постепенно. Кто-нибудь ответит, хоть и не сразу.
The God is real, unless declared integer.
Re[2]: Отличное видео про io подсистему компьютера.
Здравствуйте, netch80, Вы писали:
S>>Отличный канал и отличное видео про io подсистему компьютера и ее устройства. S>>Автор рассмотрел Memory-mapped IO vs Port-mapped IO, programmed I/O (Polling) vs Interrupt-Driven I/O S>>Почему memory mapped IO все-таки не самый лучший способ обустраивать взаимодействие с железом. Особенно S>>см. слайд на https://youtu.be/tadUeiNe5-g?si=Hv7x9iKaSgqM-2eA&t=1284 N>У автора каша в голове и ролик тупой в доску.
Я, увы, тут тоже плохо разбираюсь, соотв. увидел видео по теме, посмотрел, понравилось. Он, кмк, делает
весьма интересные видео про низкоуровневые вещи. Можно глянуть на канале.
N>Во-первых, отличие memory-mapped I/O и port-mapped I/O не играет такого принципиального значения. От того, что на x86 отдаются IN и OUT, это всё равно идёт через CPU. А на другой архитектуре, как ARM, уже в процессоре может быть заложено, например, что доступ по адресам 0÷3FFF_FFFF пошёл в оперативку, 4000_0000÷7FFF_FFFF — в ПЗУ, а 8000_0000÷BFFF_FFFF в I/O, причём к каждому своя шина своей специфической конструкции. Вообще отдельные команды IN/OUT это только линия 8080->x86, а остальные ничего, живут без них, но получая сходные результаты.
А ну т.е. одно можно симулировать с помощью другого? Ну как бы автор их особо и не противопостовлял, просто сказал, что
pmio есть только на CISC. Хуже-лучше не было.
N>MMIO по сравнению с PMIO вкуснее несколькими вещами, про которые автор ни слова не сказал: N>1. Для устройств типа видеоадаптера, сетевухи... можно отобразить их собственную память, вместо того, чтобы через регистры гонять данные или выделять куски оперативки для них. Это особенно для современных видеокарт. N>2. Память устройства можно отобразить, регулируя доступ к ней у разных процессов. Пример 1 — таймер HPET: во всех современных ОС через него читают текущее время, не переключаясь в режим ядра. Пример 2 — сетевуха, в которой VLANы (или что там ещё будет) распределены между виртуалками, каждая получает свой VLAN через свои странички и думает, что у неё полная сетевуха (или явно знает, что один VLAN, но не имеет проблемы синхронизации с соседями). Во всех случаях нужно выделение по границам страниц виртуальной памяти. N>3. Наконец, просто не нужно лишних команд и, при общей шине, отдельного типа обращений по ней.
Может и скажет еще. Но вот вдаваться в детали это видео на 1 час как минимум. Будем посмотреть, тема интересная.
Ну вообще говоря, из пункта 1 следует, что эти два подхода давольно разные, т.е. есть принципиальная разница.
Одно дело удобство, другое дело принципиальная невозможность или жуткие тормоза (это про 1 пункт, про GPU).
N>А принципиально то, что или процессор гоняется сам по каждому байтику (это называется обычно Programmed I/O, PIO), или отдаёт операции с памятью на DMA модуль, который сам это делает. (В PCI, DMA называется busmastering, и ведётся самим устройством через встроенный DMA контроллер, суть та же). Но: если мы говорим про современные (⩾2008) процессоры x86, что Intel, что AMD, то там доступ между памятью и шинами всяких PCI всё равно бегает через процессор, через северный мост, который сейчас встроен в процессор. (А если несколько "камней" и соответственно несколько доменов — то ещё и через шину между ними.) На это не тратится управляющий блок CPU, но сам CPU всё равно участвует в этом.
Он эту тему затрагивает, про северный мост.
N>И вот если расцепить это обратно, сделав мост между памятью и I/O (функция "северного моста") отделённой, то и скорость для чистых I/O операций может стать реально неограниченной (при использовании DMA // busmastering, вестимо). Но, судя по тому, что продолжают держать этот мост в процессоре, пока что отделять его невыгодно.
N>Далее, interrupt-driven I/O — это вообще не имеет никакого отношения к вопросу скорости одной передачи, это вопрос адекватного написания кода. Если любой код, который может выполняться, должен каждую микросекунду поллить все устройства, то так работать больше чем на пару килобайт не будет. Прерывания нужны для того, чтобы переключиться на специализированный код максимально близко к тому, когда нужно, без изменения(!) всего остального кода. А будет обработчик прерывания перекачивать данные по байтику, или, отметив завершение операции (когда устройство уже всё прочитало или записало), задать новую (если есть) — это одинаково и не зависит от того, MMIO или PMIO: или устройство умеет свою память или DMA, или корячиться по байтику (ладно, по слову). N>Такое впечатление, что автор не видит различия между interrupt-driven I/O и DMA (busmastering).
Придираетесь, он рассказывает про способы передачи данных -- interrupt vs polling. Про DMA ему в комментариях
написали.
Кстати, вот что по этому поводу выдал гугол (его AI):
Interrupt-driven I/O использует центральный процессор для передачи каждого блока данных, в то время как DMA (Direct Memory Access) перекладывает эту задачу на отдельный контроллер, позволяя ЦП заниматься другими делами во время передачи. DMA работает с помощью прерываний, которые сигнализируют ЦП об успешном завершении операции, а не о каждом отдельном байте.
Про DMA автор зря не упомянул, Вы правы. Но в комментариях ему об этом написали. Они тоже интересные, для меня по
крайне мере.
N>И вот тут как раз стоит вспомнить channel-based I/O: пусть оно и есть только в одной, насколько я знаю, архитектуре (SystemZ): есть отдельные канальные процессоры, или попросту каналы, которые выполняют канальные программы, отдавая команды устройствам, принимая и передавая данные. Хаб, в который включаются канальные процессоры вместе с командными процессорами (обычными CPU), может отрабатывать доступ к памяти от обоих видов наравне, не ходя через CPU.
N>CBIO имеет свои недостатки. Например, таймер через него будет жутко неэффективен, поэтому в SystemZ он прямо в процессоре явными командами (да-да). Операции типа "запустить и ждать результата", как ожидание входящего пакета в сетевуху, на него плохо ложатся. Зато его колоссальное преимущество — оно проходит с минимальными затратами через виртуализацию: там, где даже у лучшего эмулятора диска на IO пространстве или памяти ты на каждую операцию с регистрами получишь прерывание эмуляции в гипервизор (поэтому драйвера виртуальных устройств стараются делать операции через подготовку структуры в памяти и один вызов гипервизора), тут запуск операции делается что на железе, что в виртуалке одной командой типа start device.
S>>Объяснил почему ранние компьютеры были несовместимы -- всё делалось через mmi, но у каждого по-своему и гвоздями S>>прибивалось к материнке.
N>Вообще разные компьютеры между собой не очень совместимы. У одного, например, сетевуха RTL8139, у другого Attansic L3, и оба на материнке. Вот и ищи для каждого свой драйвер. N>MMIO или нет, на это не влияло. Разные устройства — разные методы доступа. А когда ты выжимаешь каждый бит — то вообще о совместимости не думают. PMIO тоже различалось. NE2000, 3C905 и DEC Tulip все были сетевухами, но ничего общего в управлении не имели. N>Какая-то унификация есть только на CBIO и только для команды "прочитать без особенностей" (код 02), потому что она для загрузки. Остальное — добрая воля (иногда под дулом пистолета или факов от Линуса) производителей железа. N>До этого, у массовых компьютеров до PDP-11 вообще не было MMIO. PDP-11 почти первый с таким, а это 1970 год. Типовым тогда было наличие команд типа "отправить байт на перфоленту", "принять код с клавиатуры" — именно так, с фиксацией роли устройства за командой. Гибкости в виде смены адреса не было. N>S/360 (предок SystemZ) тут был чуть ли не первый с универсализацией через набор команд типа start device, test device, через канальные процессоры, это 1964-66. N>PDP-11 с принципом "у нас всё через чтение-запись памяти, только протокол уточнить и базовый адрес для конкретного экземпляра устройства" стал тем, за кем пошли чуть менее чем все (опять же, кроме IBM). PMIO образца 8080 возник от того, что разнесли в этом процессоре для микроконтроллера операции с памятью из-за другого протокола.
Это чуть позже осмыслю и задам вопросы.
S>>В общем, крайне годное, кмк, базовое видео про основы. Поэтому и на этом форуме. N>Жаль. Потому что такая чушь только сбивает с толку.
Вот нет, для ликбеза самое то. Я больших косяков не увидел. Ну про DMA не упомянул, это плохо.
Но как вводное видео в тему пойдет.
S>>ЗЫ: Странно, что про DMA немного, но там, на yt, есть на эту тему неплохие комментарии. S>>https://www.youtube.com/watch?v=tadUeiNe5-g N>Ну так потому что невежа-автор не отличает DMA от прерываний — потому и немного.
Дадим шанс, может исправится.
Кодом людям нужно помогать!
Re[3]: Отличное видео про io подсистему компьютера.
Здравствуйте, Sharov, Вы писали:
S>Я, увы, тут тоже плохо разбираюсь, соотв. увидел видео по теме, посмотрел, понравилось. Он, кмк, делает S>весьма интересные видео про низкоуровневые вещи. Можно глянуть на канале.
Я уже боюсь смотреть, вдруг там такое же поверхностное галопом по европам с десятками ошибок.
N>>Во-первых, отличие memory-mapped I/O и port-mapped I/O не играет такого принципиального значения. От того, что на x86 отдаются IN и OUT, это всё равно идёт через CPU. А на другой архитектуре, как ARM, уже в процессоре может быть заложено, например, что доступ по адресам 0÷3FFF_FFFF пошёл в оперативку, 4000_0000÷7FFF_FFFF — в ПЗУ, а 8000_0000÷BFFF_FFFF в I/O, причём к каждому своя шина своей специфической конструкции. Вообще отдельные команды IN/OUT это только линия 8080->x86, а остальные ничего, живут без них, но получая сходные результаты.
S>А ну т.е. одно можно симулировать с помощью другого?
Да. Почти везде кроме x86 почти все операции ввода-вывода идут через общее адресное пространство. "Почти" — потому что есть особые случаи SystemZ с CBIO, какие-то особые исключения через обращения к сопроцессорам (стиль MIPS, ARM) и прочее.
S> Ну как бы автор их особо и не противопостовлял, просто сказал, что pmio есть только на CISC. Хуже-лучше не было.
PMIO в явном виде есть только на x86 (ну и предшественнике 8080). CISC сам по себе тут ни при чём.
А вот в неявном виде — смотрим, например, описание команды fence в самом что ни на есть рисковом RISC-V. До барьера и после — 4 варианта операции: read, write, in, out. Как in и out назначены 1) операции, влияющее на состояние процессора (не наша тема сейчас), 2) чтение и запись регионов, которые обозначены как I/O области, хотя мапятся на общее адресное пространство (их отличает уже какой-то-там контроллер процессора).
Так что снова недопустимое упрощение.
S>Ну вообще говоря, из пункта 1 следует, что эти два подхода давольно разные, т.е. есть принципиальная разница. S>Одно дело удобство, другое дело принципиальная невозможность или жуткие тормоза (это про 1 пункт, про GPU).
Ну да. Потому PMIO достаточно редок. Зачем ещё один механизм, когда достаточно пространства памяти?
А "принципиальная" разница... ничто не мешало в x86 сделать, например, 32-битное пространство портов. Просто решили, что незачем, память тут работает лучше.
S>Он эту тему затрагивает, про северный мост.
Да. Но невнятно и криво.
S>Придираетесь, он рассказывает про способы передачи данных -- interrupt vs polling.
Но он смешивает interrupt и DMA.
S> Про DMA ему в комментариях написали.
Да. Ну хоть в комментариях кто-то толковый завёлся.
S>Кстати, вот что по этому поводу выдал гугол (его AI): S>
S>Interrupt-driven I/O использует центральный процессор для передачи каждого блока данных, в то время как DMA (Direct Memory Access) перекладывает эту задачу на отдельный контроллер, позволяя ЦП заниматься другими делами во время передачи. DMA работает с помощью прерываний, которые сигнализируют ЦП об успешном завершении операции, а не о каждом отдельном байте.
Тоже не вполне верно. Polling vs. interrupt — одна ось противопоставления. PIO vs. DMA — вторая. Могут быть свободно все 4 сочетания.
Прерывание на передачу блока данных вместо одного байта или сколько там будет — да, в случае DMA эффективность выше. Но и тут некорректно так жёстко делить. У компорта с FIFO можно назначать прерывание на наличие 1 байта в приёмном буфере, а можно 4, 10 или 14. У многих сетевух можно назначать на передачу каждого пакета, а можно по опустошению буфера передачи. Это уже детали. Надо помнить главное — что прерывания помогают не поллить, а DMA — не грузить процессор прямой передачей.
S>Вот нет, для ликбеза самое то. Я больших косяков не увидел. Ну про DMA не упомянул, это плохо. S>Но как вводное видео в тему пойдет.
Ну, если потом согласны заметно корректировать запомненное — то ок.
The God is real, unless declared integer.
Re[2]: Отличное видео про io подсистему компьютера.
N>Вообще разные компьютеры между собой не очень совместимы. У одного, например, сетевуха RTL8139, у другого Attansic L3, и оба на материнке. Вот и ищи для каждого свой драйвер. N>MMIO или нет, на это не влияло. Разные устройства — разные методы доступа. А когда ты выжимаешь каждый бит — то вообще о совместимости не думают. PMIO тоже различалось. NE2000, 3C905 и DEC Tulip все были сетевухами, но ничего общего в управлении не имели.
Ну нет, автор говорил все-таки про запуск программ и обращение к соотв. адресам для устойств, которые были
разные для каждого вендора компа. Выше проблемы с сетевухами решаются драйверами, на запуск программ и работоспособность
это никак не влияет, а вот разные "защитые" адреса устройств еще как влияют.
N>Какая-то унификация есть только на CBIO и только для команды "прочитать без особенностей" (код 02), потому что она для загрузки. Остальное — добрая воля (иногда под дулом пистолета или факов от Линуса) производителей железа.
N>До этого, у массовых компьютеров до PDP-11 вообще не было MMIO. PDP-11 почти первый с таким, а это 1970 год. Типовым тогда было наличие команд типа "отправить байт на перфоленту", "принять код с клавиатуры" — именно так, с фиксацией роли устройства за командой. Гибкости в виде смены адреса не было.
Ну так с MMIO легче не стало, он об этом в конце говорит. Каждое ПК по своему отображал адреса устройств, это
нельзя было поменять и у каждого вендора было своего отображение. Отсюда и несовместимость.
N>S/360 (предок SystemZ) тут был чуть ли не первый с универсализацией через набор команд типа start device, test device, через канальные процессоры, это 1964-66. N>PDP-11 с принципом "у нас всё через чтение-запись памяти, только протокол уточнить и базовый адрес для конкретного экземпляра устройства" стал тем, за кем пошли чуть менее чем все (опять же, кроме IBM). PMIO образца 8080 возник от того, что разнесли в этом процессоре для микроконтроллера операции с памятью из-за другого протокола.
Т.е. это из-за модели, предложенной Dec, компьютеры в "древность" были не совместимы? Я вот не понял, PMIO как-то
решает проблему совместимости или все то же, что и MMIO?
Вообще, я вот не до конца понимаю, а почему всем этим программам при запуске не узнавать необходимые адреса соотв. железа? Положим, разные ОС, ну собрали для разных ОС свою Си программу, в чем дальше может быть проблема?
Кодом людям нужно помогать!
Re[3]: Отличное видео про io подсистему компьютера.
Здравствуйте, Sharov, Вы писали:
N>>Вообще разные компьютеры между собой не очень совместимы. У одного, например, сетевуха RTL8139, у другого Attansic L3, и оба на материнке. Вот и ищи для каждого свой драйвер. N>>MMIO или нет, на это не влияло. Разные устройства — разные методы доступа. А когда ты выжимаешь каждый бит — то вообще о совместимости не думают. PMIO тоже различалось. NE2000, 3C905 и DEC Tulip все были сетевухами, но ничего общего в управлении не имели.
S>Ну нет, автор говорил все-таки про запуск программ и обращение к соотв. адресам для устойств, которые были разные для каждого вендора компа. Выше проблемы с сетевухами решаются драйверами, на запуск программ и работоспособность это никак не влияет, а вот разные "защитые" адреса устройств еще как влияют.
Если управление одинаково, но адреса разные — это решается сильно легче. Но между разными принципиальными моделями компов такое редко. Разве что для совсем стандартных устройств типа линии 8250..16450..16550..16550A для компортов, для некоторых SCSI, и прочее...
Но если у тебя один комп на x86, другой на m68k, третий на PDP-11 — то у тебя проблемы больше, чем просто адреса.
S>Ну так с MMIO легче не стало, он об этом в конце говорит. Каждое ПК по своему отображал адреса устройств, это нельзя было поменять и у каждого вендора было своего отображение. Отсюда и несовместимость.
И снова — если вообще по-разному надо писать драйвер, то уже неважно, что адреса разные. Адрес меняется одним параметром в коде или в паре мест в бинаре. А вот ST506, IDE и SCSI контроллеры (которые из?) ты в принципе не обобщишь, даже если адреса совпадут (ой не надо).
А вот если у тебя оба компа IBM PC, оба с IDE — там адреса совпадали с гарантией процентов ну 99 (если не совсем специфическое вендорское железо). Порты видеоадаптеров, адреса видеопамяти, адреса LPT, COM1, таймеров, DMA контроллера, контроллера прерываний, и прочая и прочая — совпадали, это был стандарт платформы. Иначе бы хрен вообще работала MS-DOS на таком большинстве.
S>Т.е. это из-за модели, предложенной Dec, компьютеры в "древность" были не совместимы?
Из чего такой вывод?
S> Я вот не понял, PMIO как-то решает проблему совместимости или все то же, что и MMIO?
Нет. Они в этом смысле одинаковы: не помогают и не мешают решать её. Совместимость — дело производителей. В пределах одного набора типа IBM PC одного поколения у тебя совместимость в подавляющем большинстве устройств. В пределах одного набора типа PDP-11 — тоже. Между IBM PC и PDP-11, IBM PC и Apple Macintosh — она нулевая.
S>Вообще, я вот не до конца понимаю, а почему всем этим программам при запуске не узнавать необходимые адреса соотв. железа? Положим, разные ОС, ну собрали для разных ОС свою Си программу, в чем дальше может быть проблема?
Ну так начиная с MCA, PCI (и частично с ISA PnP) именно так и сделано. Во времена ISA ещё это считалось слишком дорого, поэтому не делали, а теперь это практически единственный вариант.
Грубо говоря, в 1980-м юзеры были опытнее и в состоянии внести пару параметров в программу, а железо, которое умело менять адреса по команде извне, было слишком дорогим, не окупалось. А вот примерно с середины 1980-х картина повернулась в противоположную сторону: стало необходимым допускать к использованию и тех, для кого максимум технологической грамотности это не забыть включить в розетку; автоконфигурирование начало становиться основным средством, всех начали форсировать на это, ну а поставить микруху, что это умеет, стало подъёмным (грубо говоря, от 5$/карту в начале 90-х до 0.5$ в 2000).
Первой была в этом плане MCA, проприетарная шина от IBM, была только в их PS/2 компах. Но идеи были переняты в PCI, и с первой половины 90-х начали распространяться. В этом дизайне есть возможность послать запросы чтения/записи так называемого конфигурационного пространства на конкретный физический слот (или псевдослот за северным мостом), а в этом пространстве есть указание на что за устройство (общий тип, производитель и модель) и настройки адресов. Подробнее тут. И вот там есть base address registers, которые BIOS настраивает (а потом OS может менять) такими значениями, чтобы бесконфликтно всех разместить. А затем драйвер может или сам проитерировать все устройства, или, скорее, OS предоставляет ему интерфейс получить список устройств — с типами и адресами. Драйверу остаётся отобрать те, с которыми он может работать.
ISA PnP было странным переходником в 1990-х, которое делало то же на ISA. Можешь глянуть спеку, там хитрый алгоритм широковещания на выделенных портах такими последовательностями, какие не реальны в обычной работе, и механизм взаимного исключения конфликта между устройствами. Но это именно что промежуточное временное решение, которое и не предполагало долго жить.
The God is real, unless declared integer.
Re[4]: Отличное видео про io подсистему компьютера.
S>>Т.е. это из-за модели, предложенной Dec, компьютеры в "древность" были не совместимы? N>Из чего такой вывод?
N>PDP-11 с принципом "у нас всё через чтение-запись памяти, только протокол уточнить и базовый адрес для конкретного экземпляра устройства" стал тем, за кем пошли чуть менее чем все (опять же, кроме IBM).
Пошли все, а потом разошлись и стали не совместимы. Это же они ввели mmio.
S>> Я вот не понял, PMIO как-то решает проблему совместимости или все то же, что и MMIO? N>Нет. Они в этом смысле одинаковы: не помогают и не мешают решать её. Совместимость — дело производителей. В пределах одного набора типа IBM PC одного поколения у тебя совместимость в подавляющем большинстве устройств. В пределах одного набора типа PDP-11 — тоже. Между IBM PC и PDP-11, IBM PC и Apple Macintosh — она нулевая.
Нулевая из-за цпу? Потому что в видео говорилось, что при одинаковом цпу все равно была несовместимость.
S>>Вообще, я вот не до конца понимаю, а почему всем этим программам при запуске не узнавать необходимые адреса соотв. железа? Положим, разные ОС, ну собрали для разных ОС свою Си программу, в чем дальше может быть проблема?
N>Ну так начиная с MCA, PCI (и частично с ISA PnP) именно так и сделано. Во времена ISA ещё это считалось слишком дорого, поэтому не делали, а теперь это практически единственный вариант.
N>Грубо говоря, в 1980-м юзеры были опытнее и в состоянии внести пару параметров в программу, а железо, которое умело менять адреса по команде извне, было слишком дорогим, не окупалось. А вот примерно с середины 1980-х картина повернулась в противоположную сторону: стало необходимым допускать к использованию и тех, для кого максимум технологической грамотности это не забыть включить в розетку; автоконфигурирование начало становиться основным средством, всех начали форсировать на это, ну а поставить микруху, что это умеет, стало подъёмным (грубо говоря, от 5$/карту в начале 90-х до 0.5$ в 2000).
N>Первой была в этом плане MCA, проприетарная шина от IBM, была только в их PS/2 компах. Но идеи были переняты в PCI, и с первой половины 90-х начали распространяться. В этом дизайне есть возможность послать запросы чтения/записи так называемого конфигурационного пространства на конкретный физический слот (или псевдослот за северным мостом), а в этом пространстве есть указание на что за устройство (общий тип, производитель и модель) и настройки адресов. Подробнее тут. И вот там есть base address registers, которые BIOS настраивает (а потом OS может менять) такими значениями, чтобы бесконфликтно всех разместить. А затем драйвер может или сам проитерировать все устройства, или, скорее, OS предоставляет ему интерфейс получить список устройств — с типами и адресами. Драйверу остаётся отобрать те, с которыми он может работать.
Все-таки я не до конца понял, откуда взялась татальная несовместимость -- вот у меня есть Си программа. Я могу ее
собрать без переписывания для Apple Macintosh и IBM PC? Ну т.е. собираю на IBM PC под IBM PC, тоже для Apple. Понятно, что
без перекомпиляции я не смогу запустить на соотв. ОС\железе, но сам код надо было переписывать (с нуля?)?
Кодом людям нужно помогать!
Re[5]: Отличное видео про io подсистему компьютера.
Здравствуйте, Sharov, Вы писали:
S>>>Т.е. это из-за модели, предложенной Dec, компьютеры в "древность" были не совместимы? N>>Из чего такой вывод?
S>
N>>PDP-11 с принципом "у нас всё через чтение-запись памяти, только протокол уточнить и базовый адрес для конкретного экземпляра устройства" стал тем, за кем пошли чуть менее чем все (опять же, кроме IBM).
S>Пошли все, а потом разошлись и стали не совместимы. Это же они ввели mmio.
Не совместимы стали не потому, что пошли за PDP-11, а потому, что не поддерживали совместимость всех со всеми. Её и до того не было, и после не стало. Только в механизм добавили гибкости, теперь не надо было думать, как одну команду "вывести символ на принтер" растянуть на случай двух принтеров, или думать, как менять систему команд, если решили добавить устройство, о котором проектировщики системы команд даже в диких мечтах не догадывались.
А так — вот тебе три соседних IBM PC с идентичными процессорами, материнкой и видяхой. Но в первом сетевуха NE2000, во втором DEC Tulip, в третьем 3Com Boomerang. Диск — в первом подключен к набортному ATA, у второго Adaptec 2940, у третьего LSI Megaraid. Адреса различны, методы конфигурирования и управления принципиально различны.
S>>> Я вот не понял, PMIO как-то решает проблему совместимости или все то же, что и MMIO? N>>Нет. Они в этом смысле одинаковы: не помогают и не мешают решать её. Совместимость — дело производителей. В пределах одного набора типа IBM PC одного поколения у тебя совместимость в подавляющем большинстве устройств. В пределах одного набора типа PDP-11 — тоже. Между IBM PC и PDP-11, IBM PC и Apple Macintosh — она нулевая. S>Нулевая из-за цпу? Потому что в видео говорилось, что при одинаковом цпу все равно была несовместимость.
Да. Она и сейчас есть. См. предыдущий мой абзац. Разные устройства — разные результаты. Но при этом в рамках IBM PC хотя бы базовые функции устройств на материнке — одинаковы. А с другой стороны, в банкомате может стоять что-то с пнём на борту, у которого и материнка очень специализированная и всё делает иначе, другие устройства и другие адреса.
А уж между архитектурами тем более общего около нуля. Хотя, если у тебя, например, плата типа мультипортовки на 32 последовательных порта, с интерфейсом PCI, то ей будет пофиг, куда её воткнули тем PCI — в x86, Alpha, POWER или ещё куда-то.
(Для контроллера дисков или видео так просто не пойдёт, у них своё ПЗУ, его надо под платформу перешивать.)
S>Все-таки я не до конца понял, откуда взялась татальная несовместимость
Из отсутствия желания (подкреплённого кем-то очень авторитетным, и последствий на миллионы от его невыполнения) делать всё одинаково. И из-за естественного прогресса, когда старые подходы становятся грузом на ногах.
S> -- вот у меня есть Си программа. Я могу ее S>собрать без переписывания для Apple Macintosh и IBM PC?
Если продолжать эту аналогию, то:
1) Ты вначале писал под, например, Vitamin, когда он стал сдыхать — пришлось переписать под Turbo Vision, потом под Borland VCL, потом после проблемы Борланда под MFC, потом под DirectX, потом под OpenGL, потом под Vulkan, и вот так она и работает сейчас. Это примерно соответствует цепочке ISA — VLB — PCI — PCI-X — PCI-E и что там ещё было. Во всех случаях у тебя типа тот же оконный интерфейс, методы одинаковые, но по факту пришлось переписать всё. При этом твой собственный (не связанный с графикой) код остался на C. Графика же развивалась.
2) А рядом два места с очень похожей выходной программой, в одном пишут на Java, а в другом вообще на связке Haskell+OCaml+Erlang.
S> Ну т.е. собираю на IBM PC под IBM PC, тоже для Apple. Понятно, что S>без перекомпиляции я не смогу запустить на соотв. ОС\железе, но сам код надо было переписывать (с нуля?)?
