В С вообще нет ничего для работы с железом. Я не знаю, почему ты думаешь, что в С можно работать с памятью. В общем случае нельзя. Если и получается, то это особенность компилятора (то бишь это уже не совсем C и не переносимо, впрочем это и очевидно).
Что такое порты, я не знаю. Я работал немного с микроконтролерами, там нет никаких портов, взаимодействие с оборудованием осуществляется через память. Поэтому утверждать, что эти порты это базовая концепция, я бы не стал.
Здравствуйте, Shmj, Вы писали:
S>А вот прерывания никак не сделать на голом С — эта концепция как бы не вписывается в язык.
боже мой, ну ты это всё на серьёзных щах что ли?
в кросс-платформенный язык "как бы не вписывается концепция" аппаратных особенностей конкретных платформ, вот это поворот!
вот это неожиданность, ну кто бы мог такое представить!
Здравствуйте, LuciferSaratov, Вы писали:
LS>боже мой, ну ты это всё на серьёзных щах что ли? LS>в кросс-платформенный язык "как бы не вписывается концепция" аппаратных особенностей конкретных платформ, вот это поворот! LS>вот это неожиданность, ну кто бы мог такое представить!
Подправил — там же не прерывания а работа с портами ввода-вывода, это такая же базовая концепция железа как и память. Но для работы с памятью есть механизм почему то а для портов нету
Но тут как посмотреть, конечно, ведь некоторые как бы мапят и порты а память.
Видимо так же и прерывания можно мапить на память в виде указателей на функцию.
Кстати, на каком уровне произведен мапинг видеопамяти как бы в обычную память? Это на уровне BIOS или на уровне железа?
Здравствуйте, Shmj, Вы писали:
S>По идее порты ввода-вывода такая же базовая концепция как и память? так ведь? Они на уровне железа как и память, верно? Так почему же их не добавили а память добавили?
У Интеловских процессоров, начиная с 8086 (а, вернее, с 8080) порты не отображены на память. Чтение из порта и чтение из памяти — это разные операции на шине. Поэтому у них и команды разные.
У большинства других процессоров порты ввода-вывода, действительно, отображены на диапазон адресов памяти и с ними работают теми же командами.
Но это еще и от перефирийного устройства зависит. Среди PCI-ных устройств совершенно не редкость, когда то, что логически является портами ввода-вывода, фактически отображено на пространство памяти.
Здравствуйте, Shmj, Вы писали:
S>Т.е. все остальное — обращение к видео-памяти и пр. — все это делается на голом С. Видео-память просто через указатель с константным адресом 0xb8000 — тут все ОК. А вот прерывания никак не сделать на голом С — эта концепция как бы не вписывается в язык.
В досовские времена были раcширения Borland C++ — отдельное соглашение о вызовах что-то вроде interrupt.
Такие процедуры автоматом сохраняли и восстанавливали регистры.
На современном gcc наверняка есть расширения для системных целей, ибо gcc для юниксов и был изначально написан.
Тем более, для защищенного режима сохранение и восстановление регистров не нужно. Насколько помню, там автоматически происходит переключение задачи на обработчик прерывания. (Знатоки поправят).
Здравствуйте, Shmj, Вы писали:
S>Т.е. если сделать мин. загрузчик и передачу в библиотеку на голом С — то эта библиотека целиком и полностью может обойтись без ассемблерных вставок, окромя вызова прерываний? Ведь прерывания то не мапятся на адрес с возможность дернуть указатель на функцию. S>Прав ли я? Так же интересует мнение по этому поводу.
Ну если есть желание обойтись почти без ассебмлера,
то можно теоретически подсократить в этом данном проекте использование
ассемблера с помощью чего-то типа "__attribute__((__interrupt__))".
Но насколько это нужно не очень понятно, все равно в настоящей ОС
без ассемлера не обойтись.
то даже банальное вычисление количества "замыкающих" нулевых битов
может потребоваться сделать в ОС очень быстро, в x86 есть инструкция "bsf",
которая сделает то что нужно, а без всяких расширений конкретного компилятора типа "__builtin_ctz" (gcc, clang)
фиг ты до него доберешься.
Чего (идеологически важного) нет в С?
Возможности ограничивать и контролировать ресурсы. Например вы не можете попросить выполняться функцию не более 10мс и не хавать более 25кб. Или например вызывать метод не реже чем через n тактов.
Нет локальный функций, нет анонимных функций. Всего один стэк нет возможности возможности оперировать с алгоритмом для его последовательной модификации.
Здравствуйте, vsb, Вы писали:
vsb>В С вообще нет ничего для работы с железом. Я не знаю, почему ты думаешь, что в С можно работать с памятью. В общем случае нельзя. Если и получается, то это особенность компилятора (то бишь это уже не совсем C и не переносимо, впрочем это и очевидно).
Вот этот момент мне и не ясен — кто и почему решил, что адрес 0xb8000 — это именно видеопамять при начальной загрузке (в режиме VGA или как там)? Наверное даже не компилятор а BIOS-система это определяет, скорее всего. Или нет...
Вот если без BIOS загрузиться — как обратиться к девайсам?
vsb>Что такое порты, я не знаю.
Порт — это и есть та самая ножка микроконтроллера, к которой ты припаиваешь светодиод. Ну да, обычно оно тоже как-то мапится на память.
И тоже тут вопрос — на каком уровне оно мапится на память? На уровне компилятора или девайса?
Здравствуйте, Shmj, Вы писали:
vsb>>В С вообще нет ничего для работы с железом. Я не знаю, почему ты думаешь, что в С можно работать с памятью. В общем случае нельзя. Если и получается, то это особенность компилятора (то бишь это уже не совсем C и не переносимо, впрочем это и очевидно).
S>Вот этот момент мне и не ясен — кто и почему решил, что адрес 0xb8000 — это именно видеопамять при начальной загрузке (в режиме VGA или как там)? Наверное даже не компилятор а BIOS-система это определяет, скорее всего. Или нет...
Интересно ты смешиваешь разные вещи — одинокий порт на одной ножке для микроконтроллера и адреса видеопамяти для x86. Ты понимаешь, что между ними разница в несколько уровней?
S>Вот если без BIOS загрузиться — как обратиться к девайсам?
К одним просто — они сидят на стандартных адресах в пространстве портов.
К другим сложнее — надо сходить узнать их конфигурацию и настроить, какие адреса будут использоваться, а перед этим — настроить ещё и шлюзы между шинами.
vsb>>Что такое порты, я не знаю. S>Порт — это и есть та самая ножка микроконтроллера, к которой ты припаиваешь светодиод. Ну да, обычно оно тоже как-то мапится на память.
"Это не те порты, которые ты ищешь" (tm).
S>И тоже тут вопрос — на каком уровне оно мапится на память? На уровне компилятора или девайса?
Ну и там идея какая. Делаем на ассемблере подготовку (переход в защищеный режим и пр.) — а потом уже переходим на уровень выше и пишем на голом С. ОК вроде.
Т.е. все остальное — обращение к видео-памяти и пр. — все это делается на голом С. Видео-память просто через указатель с константным адресом 0xb8000 — тут все ОК. А вот прерывания работу с портами ввода-вывода никак не сделать на голом С — эта концепция как бы не вписывается в язык.
Т.е. если сделать мин. загрузчик и передачу в библиотеку на голом С — то эта библиотека целиком и полностью может обойтись без ассемблерных вставок, окромя вызова прерываний работы с портами ввода-вывода?
По идее порты ввода-вывода такая же базовая концепция как и память? так ведь? Они на уровне железа как и память, верно? Так почему же их не добавили а память добавили?
Прав ли я? Так же интересует мнение по этому поводу.
Здравствуйте, rg45, Вы писали:
S>>Чего (идеологически важного) нет в С? R>RAII
Да опять вы за свое. Я не об этом.
Вопрос в другом. Вот есть голое железо и язык С. Почему мы не можем полностью работать с этим железом на голом С а нужны некие ассемблерные вставки? По каким причинам?
Вот одно из что я привел — нет поддержки портов ввода-вывода как в примере выше.
Ведь с памятью то можем работать же напрямую. А с портами нет. Что еще кроме памяти и портов нужно для железа? И кто мапит память устройств на общую память — это на уровне железа или на уровне BIOS?
Здравствуйте, Shmj, Вы писали:
S>Вопрос в другом. Вот есть голое железо и язык С. Почему мы не можем полностью работать с этим железом на голом С а нужны некие ассемблерные вставки? По каким причинам?
Железа разного много, а си один. А асм под каждую архитектуру свой.
Здравствуйте, Shmj, Вы писали:
S>По идее порты ввода-вывода такая же базовая концепция как и память? так ведь? Они на уровне железа как и память, верно? Так почему же их не добавили а память добавили?
Как уже сказали выше, отдельное адресное пространство портов ввода-вывода — это специфика x86, на других архитектурах это может быть обычная память.
В Borland С++ были соответствующие интринсики.
Я помню, в студенческие годы изобретал велосипед с оператором [], чтобы пользоваться как в турбо-паскале
port[i] = j;
Здравствуйте, Shmj, Вы писали:
S>Подправил — там же не прерывания а работа с портами ввода-вывода, это такая же базовая концепция железа как и память. Но для работы с памятью есть механизм почему то а для портов нету
1. Порты как механизм специфичны только для x86 линии (начиная с 8080) и в таком виде появились от того, что методы обращения к памяти и IO предполагались разные, а сводить в одну команду авторам 8080 не хотелось. Дополнительные линии на шине помогали сократить сложность опознания обращения.
Обрати внимание, что в ранних IBM PC делали, например, что порты 44-47, 48-4B, 4C-4F, ..., 5C-5F были тем же самым что 40-43. Это чисто экономия на декодинге. Потом уже начали их использовать. Опять же, чем дешевле для первой версии, тем лучше.
Остальные архитектуры использовали отображение на память. Ну не считаем линию от S/360 до System/Z, в которой только пара базовых устройств типа таймера доступна через встроенные команды, а остальные — через каналы ввода-вывода (в качестве аналогии представь себе, что это всё висит на таком ну очень быстром USB или SCSI, что легче представить).
Так что ничего "базового" в портах в их нынешнем x86 виде нет, это локальная заморочка.
2. В большинстве Unix-систем доступ к портам идёт через функции, часто заврапленные под конкретные шинные переходники. Вот, например, сетевуха системы "старой доброй" NE2000 может отразить регистры на память, а может на порты. Драйвер пользуется универсальным bus_write_i32(), а вызвать команду out или запись в память — решает нижележащий драйвер шины.
А вот когда уже дошло до конкретной in или out, используются ассемблерные переходники или builtin-функции. Компилятор может их заинлайнить (скорее всего), а может — нет, по настроению. В любом случае платформа в виде компилятора даёт такое средство.
3. С прерываниями таки важнее — функция, пригодная напрямую из C как обработчик прерывания, должна иметь особые пролог и эпилог. Заморачиваются этим только в мелком embedded. В крупном (грубо говоря, где можно запустить Linux) используют ассемблерные переходники.
S>Но тут как посмотреть, конечно, ведь некоторые как бы мапят и порты а память.
Мапят, да. Могут вообще пространство I/O не использовать.
Если говорить об x86, есть ещё третье адресное пространство — конфигурации PCI. Ты о нём даже не пытался вспоминать а ведь самые базовые настройки железа сейчас собраны именно туда. Оно в зависимости от чипсета накладывается или на участок памяти, или на порты ввода-вывода в режиме узкого окна.
S>Видимо так же и прерывания можно мапить на память в виде указателей на функцию.
Нет. Для C нужны пролог, который создаст всю необходимую обстановку для C рантайма, и эпилог, который восстановит всё обратно.
S>Кстати, на каком уровне произведен мапинг видеопамяти как бы в обычную память? Это на уровне BIOS или на уровне железа?
Судя по формулировке вопроса, ты не понимаешь, что спрашиваешь.
Непосредственно обращения отрабатывает железо. А вот правила раутинга запросов доступа для него настраивает или BIOS, или потом ОС.
Здравствуйте, Shmj, Вы писали:
S>Вопрос в другом. Вот есть голое железо и язык С. Почему мы не можем полностью работать с этим железом на голом С а нужны некие ассемблерные вставки? По каким причинам?
Для настройки среды, в которой работает C код, нужно как минимум настроить:
1. Стек — выделить память, поставить указатель на её границу.
2. Для архитектур где используется global pointer (такой регистр) — его.
Это нельзя сделать сишным кодом. Настройка идёт откуда-то извне. Стандартно и удобнее всего — ассемблер.
Далее, в обработчике прерывания надо на входе сделать то же самое (в плане установки регистров) и сохранить все регистры, которые не сохраняются в обычной функции (через них передаются аргументы и забирается результат), на выходе — восстановить их.
S>Вот одно из что я привел — нет поддержки портов ввода-вывода как в примере выше.
Не смотри на x86. Смотри на ARM или MIPS. Там портов нет, с ними не надо работать.
А вот то что я выше назвал — надо.
А ещё там разные барьеры памяти, которые может не уметь компилятор сам по себе.
А ещё специфичные команды типа WFE (wait for events).
S>Ведь с памятью то можем работать же напрямую. А с портами нет. Что еще кроме памяти и портов нужно для железа? И кто мапит память устройств на общую память — это на уровне железа или на уровне BIOS?
В ARM/MIPS/etc. обычно жёстко прописано в железе.
В x86 всё сложно. Если ME не выделит заранее BIOS'у оперативную память, то и её нет! Надо сначала вытащить данные конфигурации модулей памяти и настроить маппинг через регистры.
Регистры эти в PCI configuration space, куда, пока не настроил их отображение на память, доступ только через шлюз в виде двух регистров ввода-вывода (CF8, CFC).
Начальный этап BIOS, пока она это настраивает, нельзя написать на C, потому что там даже стека нет. Потом может использовать кэш процессора как эмуляцию памяти, но он маленький. Всё равно ассемблер.
Только после этого можно подключать основную память.
EFI где-то так и сделан — после первой инициализации строится среда для кода, написанного в основном на C/C++, и он начинает выполняться.
Здравствуйте, Shmj, Вы писали:
vsb>>В С вообще нет ничего для работы с железом. Я не знаю, почему ты думаешь, что в С можно работать с памятью. В общем случае нельзя. Если и получается, то это особенность компилятора (то бишь это уже не совсем C и не переносимо, впрочем это и очевидно).
S>Вот этот момент мне и не ясен — кто и почему решил, что адрес 0xb8000 — это именно видеопамять при начальной загрузке (в режиме VGA или как там)? Наверное даже не компилятор а BIOS-система это определяет, скорее всего. Или нет...
Точного ответа я не дам, я в этом плаваю. Но в целом — настраивается некий маппинг. Т.е. когда процессор получает команды на чтение/запись памяти по определенным адресам, то вместо обращения к DDR-памяти он обращается к другим устройствам. Кто именно это настраивает — я не знаю. В микроконтролерах он сразу после старта обычно уже настроен, но там процессор со всей периферией на одном кристалле напечатан. В ПК, наверное, биос или ещё что-то подобное настраивает.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, reversecode, Вы писали:
S>>>Так же интересует мнение по этому поводу. R>>зачем, для ваших курсов/обзоров на ютубчике?
S>У меня нет таких курсов или обзоров.
Мне кажется, пора начинать.
Ты ведь не просто так задаёшь 20 вопросов в неделю с рангом от левого до правого края "общей теории всего" (tm) ?
Пора полученное и переработанное разливать по ёмкостям.
S> Просто для философского понимания сути.
"Ты вот сколько философов знаешь?
А один только наш философский факультет выпускает 50 в год!"
Здравствуйте, vsb, Вы писали:
vsb>В С вообще нет ничего для работы с железом. Я не знаю, почему ты думаешь, что в С можно работать с памятью. В общем случае нельзя. Если и получается, то это особенность компилятора (то бишь это уже не совсем C и не переносимо, впрочем это и очевидно).
Ты же сломал главный козырь всех школьных хакеров, изверг!
Здравствуйте, vsb, Вы писали:
vsb>Что такое порты, я не знаю. Я работал немного с микроконтролерами, там нет никаких портов
Хм, как Вам удалось изучать программирование МК, но ни разу не встретить упоминаний о портах ввода/вывода? Это, как бы, одно из базовых понятий в связке любого железа и софта.
Здравствуйте, netch80, Вы писали:
N>Порты как механизм специфичны только для x86 линии (начиная с 8080) и в таком виде появились от того, что методы обращения к памяти и IO предполагались разные, а сводить в одну команду авторам 8080 не хотелось.
А ничего, что порты появились в незапамятные времена, на самых первых компьютерах?
Здравствуйте, Евгений Музыченко, Вы писали:
vsb>>Что такое порты, я не знаю. Я работал немного с микроконтролерами, там нет никаких портов
ЕМ>Хм, как Вам удалось изучать программирование МК, но ни разу не встретить упоминаний о портах ввода/вывода? Это, как бы, одно из базовых понятий в связке любого железа и софта.
Ну так вот получилось. Я и сейчас не понимаю, о чём речь. Если мне надо поморгать диодом, я меняю нужный бит по нужному адресу, который в даташите можно найти. Я даже ARM ассемблер изучал и не видел там никаких команд, связанных с портами.
Из этого топика я понял, что на x86 есть отдельные команды для работы с этими портами, ну с x86 на низком уровне мне пока работать не приходилось. Программы на 8086 для доса в университете я писал, там тоже никаких портов не припомню. Для работы с графикой так же писал по какому-то адресу что нужно и всё.
Здравствуйте, vsb, Вы писали:
vsb>Я и сейчас не понимаю, о чём речь.
Ну так отчего б не почитать хотя бы это? Или в англоязычном оригинале, более подробно.
vsb>Если мне надо поморгать диодом, я меняю нужный бит по нужному адресу
vsb>Из этого топика я понял, что на x86 есть отдельные команды для работы с этими портами
Выделенные порты/каналы, со специальными командами обращения к ним, были испокон веков на каждом компьютере, пока не придумали (если не ошибаюсь, в 1970-е) объединить их с основным адресным пространством.
vsb>Программы на 8086 для доса в университете я писал, там тоже никаких портов не припомню.
Хм. Даже если Вы писали сугубо прикладные программы, то получается, что Вы не читали вообще никакой литературы, кроме "для чайников", хотя и там понятие порта упоминалось почти всегда. А уж в любой книжке/статье по серьезному программированию под DOS они описывались в обязательном порядке, пусть и кратко. Скорее всего, сработало что-то вроде вытеснения.
Вообще, конечно, грустно наблюдать, как вся история вычислительной техники свелась к 808x и тому, что из них выросло. Это как "истинным" христианам/иудеям неинтересно задаваться вопросом, было ли что-то раньше, чем 5500 лет назад. Ну, или как изучать автомобилестроение, начиная с какого-нибудь VW Beetle или Ford Mustang.
Здравствуйте, BSOD, Вы писали:
BSO>В современном компиляторе VC тоже есть
Функции типа inp/outp были в любой реализации для архитектур с выделенными портами. В Lattice C (из которого сделали MS C под DOS) они были библиотечными, но в 80-х и не нужно было иметь их встроенными — портов достаточного быстродействия тогда просто не было. Когда появились — стали делать встроенными.
Но такой шикарной поддержки архитектуры на уровне C, как у Borland, не было почти нигде. Вроде в TopSpeed C тоже были регистровые псевдопеременные, но это не точно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, netch80, Вы писали:
N>>Порты как механизм специфичны только для x86 линии (начиная с 8080) и в таком виде появились от того, что методы обращения к памяти и IO предполагались разные, а сводить в одну команду авторам 8080 не хотелось.
ЕМ>А ничего, что порты появились в незапамятные времена, на самых первых компьютерах?
Хм, и откуда бы вам быть таким уверенным в этом, коллега?
Иём в вики: Port-Mapped I/O: PDP-8 (звыняйте, забыл) — 1965; Nova — 1970е — -про неё ниже. Уже после этого в 8080 и дальше. И всё — из того широчайшего спектра марок и моделей, что было.
Memory-mapped I/O: более раннего упоминания, чем PDP-11 (1970), нет. Я тоже не слышал. Видимо, она была пионерной в этом.
А что было раньше? А вот два варианта.
Первый, попроще и послабее: берём PDP-1 для примера. "Спецкоманда 3 — напечатать на пишущей машинке, спецкоманда 4 — инициировать получение с пишущей машинки". Две пишущих машинки не предусматривались. Поэтому это не "порты", а команды доступа к фиксированному набору железа.
Второй поинтереснее: 1964, S/360 (ссылки сами найдёте). Все адреса были изменяемыми в пределах возможностей железа (как 2 канала — один мультиплексный и один селекторный — до сих пор помню EC-1022), и там было одно устройство — таймер — с которым работали через команды процессора, а с остальными — через каналы. Каналы делали асинхронные операции со встроенными DMA контроллерами через память, и там тоже не было "портов" в том виде — вы не могли сделать ничего с устройством кроме как сформировать блок channel control words (CCW) в памяти, рядом сложить данные для команд, дождаться освобождения устройства, вызвать SIO (start I/O) на него и дождаться уже этого завершения. А почему так? А потому что устройства выносились на десятки и сотни метров, и канальный дизайн был эффективнее, чем набивать стойку рядом с процессором раздельными контроллерами и от них тянуть кабеля по системе "звезда".
И даже в суперпоследних System/Z с процессорами на 14нм технологии и прочими фишками типа "у процессорного модуля памяти меньше 80GB не бывает" сохраняется этот канальный подход, ибо традиции надо беречь. Ну вместо одного адреса на устройство делают пучок по количеству одновременно поддерживаемых операций, но суть та же.-
(Nova, упомянутая там в вики как пример для PMIO, на самом деле канальная, а порты в жёстком наборе изображали интерфейс устройства уже по ту сторону канала. Интересный промежуточный формат, но я бы его считал канальным, а не портами.)
А все модели до тотального распространения MMIO + PMIO имели, вон как PDP-1, процессорные команды "вывести строку на принтер" или "прочитать байт с перфоленты".
Так откуда у вас представление про "порты ввода-вывода" в самых первых компах?
Здравствуйте, vsb, Вы писали:
vsb>В С вообще нет ничего для работы с железом. Я не знаю, почему ты думаешь, что в С можно работать с памятью. В общем случае нельзя.
Тут опять же полезно знать историю. Сами разработчики C делали язык прежде всего для эффективной работы с железом без привлечения ассемблера. Они вообще не делали различий между указателем и адресом — в те времена (и для тех программистов) это были фактически синонимы.
Это уже потом, когда выросли первые поколения "С-программистов", которые вообще не изучали толком ни аппаратных архитектур, ни ассемблеров, а просто "записывали алгоритм конструкциями языка", и на первое место вышли задачи переносимости, появились все эти оговорки о том, что указатель обычно (но не обязательно) является адресом памяти. Апогея, конечно, все это достигло только в C++, но и на C тоже ретроспективно повлияло.
Здравствуйте, Евгений Музыченко, Вы писали:
vsb>>Что такое порты, я не знаю. Я работал немного с микроконтролерами, там нет никаких портов
ЕМ>Хм, как Вам удалось изучать программирование МК, но ни разу не встретить упоминаний о портах ввода/вывода? Это, как бы, одно из базовых понятий в связке любого железа и софта.
Ну вот я взял документ "STM32F405/415, STM32F407/417, STM32F427/437 and STM32F429/439 advanced Arm®-based 32-bit MCUs". Почему этот — ну первый такого рода попался под руку.
"Peripheral register" — на каждом шагу и это как раз место адресного пространства, куда записывая значения, можно добиться какого-то эффекта, читая — узнать состояние. "Port" — в отношении GPIO и означает именно один вывод ("ногу") контроллера или группу выводов.
Хорошо, смотрю рядом. Документ по AtMega8 ("8-bit Atmel with 8KBytes In-System Programmable Flash") от и до, команды процессора и вся периферия. И снова register в той же роли. Устройство с такими-то регистрами. Регистр управления по такому-то адресу. И прочая и прочая. ну да, слово "peripheral" не присутствует. Но и "port" снова это сущность в виде GPIO выводов. А то, что вы считаете "портом", это у них регистр.
Ваше x86-центричное (и даже x86-ограниченное) мышление понятно, но надо ж понимать, что и другие миры есть.
Вот, кстати, на засыпку. В терминах IBM что говорится вместо RAM ("random access memory"), она же оперативная память? Можете попробовать загуглить
Здравствуйте, netch80, Вы писали:
N>Хм, и откуда бы вам быть таким уверенным в этом, коллега?
Оттуда, что ранние компьютеры использовали команды фиксированной длины, и отдельные команды для разных устройств можно было использовать лишь до тех пор, пока этих устройств было два-три. Как только устройств стало больше, иметь для них отдельные команды стало слишком расточительно, и перешли к универсальным командам ввода/вывода с адресацией устройств.
N>Иём в вики
Это лишь описание различий между отображаемыми способами ввода/вывода, когда доступ к устройствам предельно унифицирован, и есть только две команды — ввод и вывод. А здесь, по сути, был поднят вопрос о том, как получить доступ ко внешнему устройству, если его регистр(ы) не отображены на обычную память. В этом смысле "порт" обозначает "интерфейс устройства". Это может быть отдельная команда для работы с конкретным устройством, или команда работы с группой каналов, или команда вида in/out с адресом порта.
N>берём PDP-1 для примера. "Спецкоманда 3 — напечатать на пишущей машинке, спецкоманда 4 — инициировать получение с пишущей машинки". Две пишущих машинки не предусматривались. Поэтому это не "порты", а команды доступа к фиксированному набору железа.
А если почитать внимательнее, то можно увидеть:
Bits 12 through 17, which are used to designate a elass of input or output devices such as typewriters, may be further defined by Bits 7 through 11 as referring
to Typewriter 1, 2, 3, etc. In several of the optional in-out devices, in particular the magnetic tape, Bits 7 through 11 specify particular functions such as forward,
backward etc. If a large number of specialized devices are to be attached, these bits may be used to further decode the in-out transfer instruction to perform totally
distinct functions.
То есть, команда с кодом 72, по сути, является общей командой ввода/вывода, остальные разряды которой кодируют вид устройства, его адрес в группе, выполняемую операцию и прочее.
N>как 2 канала — один мультиплексный и один селекторный
Да я в курсе, как это работало. Это опять модель "для работы с устройством нужно выполнить специальные команды, указав для них определенные данные". Тогда концепция интерфейса/канала/порта использовалась для обозначения некой сущности, которой можно было послать команду, данные, или получить их оттуда. А уже потом сообразили, что это можно унифицировать, сведя все многообразие команд к двум или нескольким, и сделав общее адресное пространство для всех устройств.
Здравствуйте, netch80, Вы писали:
N>Ну вот я взял документ "STM32F405/415, STM32F407/417, STM32F427/437 and STM32F429/439 advanced Arm®-based 32-bit MCUs".
В документации по STM32 упоминаются, как минимум, Debug Access Port и JTAG Port.
N>Документ по AtMega8
У этих вообще сплошь и рядом упоминаются I/O Ports.
N>Но и "port" снова это сущность в виде GPIO выводов. А то, что вы считаете "портом", это у них регистр.
Порт — это сущность любой связи со внешним миром. Это интерфейс, канал, контроллер, регистр и все остальное, через что процессор может общаться с тем, что вокруг него.
N>Ваше x86-центричное (и даже x86-ограниченное) мышление понятно, но надо ж понимать, что и другие миры есть.
Я, если что, познакомился с x86 только в начале 90-х, а с вычислительной техникой связался с 80-го.
N>В терминах IBM что говорится вместо RAM ("random access memory"), она же оперативная память?
Что значит "вместо"? Во всей литературе по вычтехнике поначалу (и довольно долго) говорили просто о "memory", не выделяя специально случайность доступа к ней. Насколько я помню, термин RAM вошел в обиход в то время, когда появились микросхемы памяти (70-е, если не ошибаюсь).
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Хм, и откуда бы вам быть таким уверенным в этом, коллега?
ЕМ>Оттуда, что ранние компьютеры использовали команды фиксированной длины,
Цитирую:
EM> А ничего, что порты появились в незапамятные времена, на самых первых компьютерах?
Так вот от "самых первых компьютеров" даже до PDP-8 — три формальных поколения, 15-20 лет бурного развития и смены всех парадигм по нескольку раз.
А предшествующие поколения использовали явные команды для устройств.
Фактически, PDP-11 это первая система, у которой адресуемый ввод-вывод был настоящий, а не предшествующие эрзацы — и то это MMIO. Первый настоящий PMIO это 8080.
EM> и отдельные команды для разных устройств можно было использовать лишь до тех пор, пока этих устройств было два-три. Как только устройств стало больше, иметь для них отдельные команды стало слишком расточительно, и перешли к универсальным командам ввода/вывода с адресацией устройств.
Верно. Но опять же среди всех методов
1) Команды для конкретных устройств
2) MMIO
3) PMIO
4) каналы и канальные команды (пусть будет ChIO)
PMIO стало переходить из аутсайдеров в основной метод уже только с распространением x86 в виде IBM PC (и закатываться обратно с распространением PCI).
И на архитектурах, не подверженных влиянию x86, оно никогда и не появлялось.
N>>Иём в вики ЕМ>Это лишь описание различий между отображаемыми способами ввода/вывода, когда доступ к устройствам предельно унифицирован, и есть только две команды — ввод и вывод. А здесь, по сути, был поднят вопрос о том, как получить доступ ко внешнему устройству, если его регистр(ы) не отображены на обычную память.
Нет. В обсуждаемой теме вопрос именно в том, что не может C без ассемблера.
C без ассемблера может в произвольный доступ к памяти по любому программно сгенерированному адресу, но не может в команды in и out (как бы они ни назывались).
EM> В этом смысле "порт" обозначает "интерфейс устройства". Это может быть отдельная команда для работы с конкретным устройством, или команда работы с группой каналов, или команда вида in/out с адресом порта.
Нет. Для PMIO нужны команды, которые на C без библиотечных функций не выполнить.
Для ChIO нужны команды, которые на C без библиотечных функций не выполнить (а если в стиле S/360, а не S/370, а ещё и работа с прерываниями, то нужна сериализация доступа к конкретным областям памяти).
Только MMIO (и то без прерываний!) доступен на C без дополнительной поддержки в библиотеке или компиляторе (если нужны обработчики прерываний в явном виде).
N>>берём PDP-1 для примера. "Спецкоманда 3 — напечатать на пишущей машинке, спецкоманда 4 — инициировать получение с пишущей машинки". Две пишущих машинки не предусматривались. Поэтому это не "порты", а команды доступа к фиксированному набору железа.
ЕМ>А если почитать внимательнее, то можно увидеть:
...
ЕМ>То есть, команда с кодом 72, по сути, является общей командой ввода/вывода, остальные разряды которой кодируют вид устройства, его адрес в группе, выполняемую операцию и прочее.
С такой точки зрения все команды "общие" — ADD, SUB и NOP, например, единообразно инициируют операцию в АЛУ, только разные операции задают.
Ваше рассмотрение непрактично.
N>>как 2 канала — один мультиплексный и один селекторный
ЕМ>Да я в курсе, как это работало. Это опять модель "для работы с устройством нужно выполнить специальные команды, указав для них определенные данные". Тогда концепция интерфейса/канала/порта использовалась для обозначения некой сущности, которой можно было послать команду, данные, или получить их оттуда. А уже потом сообразили, что это можно унифицировать, сведя все многообразие команд к двум или нескольким, и сделав общее адресное пространство для всех устройств.
И снова — нет. Канальный подход нельзя заменить на MMIO/PMIO, не потеряв преимущество в виде каналов как шин почти произвольной длины с каскадным включением и асинхронным исполнением.
Но для обсуждаемой темы, повторюсь, важно не это, а то, что, например, получить результат операции ввода-вывода на S/360 значило
1) Войти в глобальную "критическую секцию" (захватить мьютекс), могло упрощаться на однопроцессорном дизайне с запретом шедулинга. Тут же — запретить прерывания.
2) Вызвать TIO для данного устройства.
3) Проанализировать результат по адресам 64-71 или скопировать его для дальнейшего анализа.
4) Выйти из критической секции, разрешить обратно прерывания.
И вот только (3) штатно делается на C. Остальные требуют ассемблера или библиотечных функций.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Но и "port" снова это сущность в виде GPIO выводов. А то, что вы считаете "портом", это у них регистр. ЕМ>Порт — это сущность любой связи со внешним миром. Это интерфейс, канал, контроллер, регистр и все остальное, через что процессор может общаться с тем, что вокруг него.
Тем не менее терминология может плавать. Как видим, то, что "порт" на уровне x86, и "порт" в таких контроллерах, не имеет ничего общего.
N>>Ваше x86-центричное (и даже x86-ограниченное) мышление понятно, но надо ж понимать, что и другие миры есть. ЕМ>Я, если что, познакомился с x86 только в начале 90-х, а с вычислительной техникой связался с 80-го.
Тогда непонятно, откуда попытки увести разговор в эту сторону и именно таким методом.
N>>В терминах IBM что говорится вместо RAM ("random access memory"), она же оперативная память? ЕМ>Что значит "вместо"? Во всей литературе по вычтехнике поначалу (и довольно долго) говорили просто о "memory", не выделяя специально случайность доступа к ней.
Диск или перфолента они тоже memory. Нет, речь именно об оперативной памяти.
EM> Насколько я помню, термин RAM вошел в обиход в то время, когда появились микросхемы памяти (70-е, если не ошибаюсь).
Здравствуйте, netch80, Вы писали:
N>Цитирую: EM> А ничего, что порты появились в незапамятные времена, на самых первых компьютерах?
Все верно. Вы видите где-то здесь "PMIO появилось..."?
N>А предшествующие поколения использовали явные команды для устройств.
Вы мне возражаете так, будто я утверждаю, будто в первых компьютерах уже использовался именно port-mapped I/O, как он есть сейчас в том же x86, а регистры для этого именовались словом "порт". А я такого не говорил. Я говорил о "портах", как интерфейсах ввода/вывода, отдельных объектах, доступ к которым осуществлялся неким специальным образом — хоть через отдельные команды, хоть через отдельные же регистры. Я ведь отвечал в контексте противопоставления доступа ко внешним устройствам через порты (неважно какие) доступу через единое адресное пространство — MMIO vs "все остальное".
Термин "порт" начал использоваться для обозначения интерфейса устройства очень давно. Мне не удалось с ходу найти литературу 50-60-х, но в патентных заявках, начиная с 70-го, он используется, как сам собой разумеющийся, без каких-либо специальных объяснений.
N>Нет. В обсуждаемой теме вопрос именно в том, что не может C без ассемблера. N>C без ассемблера может в произвольный доступ к памяти по любому программно сгенерированному адресу, но не может в команды in и out (как бы они ни назывались).
Дык, а я о чем? Именно о том, что в любой реализации C по определению возможна работа с MMIO, а "со всем остальным" — только при наличии специальной поддержки. Это "все остальное" и называют совокупным термином "порты".
EM>> В этом смысле "порт" обозначает "интерфейс устройства". Это может быть отдельная команда для работы с конкретным устройством, или команда работы с группой каналов, или команда вида in/out с адресом порта.
N>Нет. Для PMIO нужны команды, которые на C без библиотечных функций не выполнить. N>Для ChIO нужны команды, которые на C без библиотечных функций не выполнить (а если в стиле S/360, а не S/370, а ещё и работа с прерываниями, то нужна сериализация доступа к конкретным областям памяти).
Не понимаю, к чему здесь "нет", когда Ваши утверждения никак не противоречат моим, а вполне себе идут параллельно.
N>Только MMIO (и то без прерываний!) доступен на C без дополнительной поддержки в библиотеке или компиляторе (если нужны обработчики прерываний в явном виде).
Ну да. Разве я где-то на это возражал?
N>С такой точки зрения все команды "общие" — ADD, SUB и NOP, например, единообразно инициируют операцию в АЛУ, только разные операции задают.
Разделение на "внутренний" и "внешний" мир было понятно с самого начала. Команды обработки данных всегда (или в первую очередь) работают с тем, что уже каким-то образом попало в память. Кстати, насколько я помню, в самых первых реализациях программных средств ввода-вывода не было вообще — какое-то количество ячеек памяти или регистров можно было заполнить с помощью переключателей, и увидеть их состояние на индикаторах.
N>И снова — нет. Канальный подход нельзя заменить на MMIO/PMIO, не потеряв преимущество в виде каналов как шин почти произвольной длины с каскадным включением и асинхронным исполнением.
И снова не понимаю, к чему здесь "нет". Вы определенно возражаете не на то, что я утверждал, а на что-то другое.
Здравствуйте, netch80, Вы писали:
N>видим, то, что "порт" на уровне x86, и "порт" в таких контроллерах, не имеет ничего общего.
"Портами" издавна называли и сами аппаратные интерфейсы.
N>Тогда непонятно, откуда попытки увести разговор в эту сторону и именно таким методом.
Я не делал таких попыток, Вам показалось. Скорее всего, на мои утверждения о портах вообще у Вас сработала ассоциация на PMIO, а дальше уже пошло на автомате.
N>Диск или перфолента они тоже memory. Нет, речь именно об оперативной памяти.
Посмотрел документы IBM 60-х годов. У них там полный раздрай: в одних документах они полностью избегают слова "memory", предпочитая "storage" (при этом, что характерно, диски у них — "storage units", а ленты — только "devices"), в других документах тех же лет они активно используют "memory" наравне со "storage".
