Такой вопрос. Вот осознал что всегда работал на неком уровне абстракции — платформа тебя заботливо ограждает от реальных сущностей, причем очень очень сильно ограждает, так что даже теряется общее представление как оно устроено, даже если у тебя опыт работы много лет.
Хотелось бы больше для ликбеза чуть приблизиться к реальному железу, понять на каком языке с ним разговаривают уже после уровня драйверов. Но при этом не хотелось бы вдаваться в системные языки — все в рамках C#.
К примеру, узнал интересное про сеть. В .Net есть класс Socket. Но он не умеет напрямую IP-протокол, поверх которого все строится. По сути глобальный протокол 1 уровня — это именно IP (не считая канальные и всякие прочие — которые не выходят из локальной зоны) — а TCP и UDP уже поверх него. Предлагают некую байду — https://github.com/PcapDotNet/Pcap.Net , который работает поверх WinPcap. Ну хотя бы так.
Интересное еще про говорилку. Как оно вообще внутри работает? Ей подают сигнал в виде потока просто? Аналогичный вопрос про слушалку — с нее получаем просто поток?
Про показывалку вопрос. Что принимает драйвер видеокарты в общем виде? Вектор и растр? Вектор видимо отличается сильно по возможностям для разных карт — но в среднем какие там возможности? Как-то можно напрямую с этим поработать на любимом ЯП?
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Вот осознал что всегда работал на неком уровне абстракции — платформа тебя заботливо ограждает от реальных сущностей, причем очень очень сильно ограждает, так что даже теряется общее представление как оно устроено, даже если у тебя опыт работы много лет.
S>Хотелось бы больше для ликбеза чуть приблизиться к реальному железу, понять на каком языке с ним разговаривают уже после уровня драйверов. Но при этом не хотелось бы вдаваться в системные языки — все в рамках C#.
Ниже уровня драйверов с ним, железом, ОС разговаривает-- прерывания и та вещи. Это Си, вам.
S>Про показывалку вопрос. Что принимает драйвер видеокарты в общем виде? Вектор и растр? Вектор видимо отличается сильно по возможностям для разных карт — но в среднем какие там возможности? Как-то можно напрямую с этим поработать на любимом ЯП?
Можно через interop.
Недавно же поднимали эту тему, какой смысл еще раз?
Здравствуйте, Sharov, Вы писали:
S>Ниже уровня драйверов с ним, железом, ОС разговаривает-- прерывания и та вещи. Это Си, вам.
Не ниже — выше. Т.е. работать средствами ОС, но максимально близко — выжать все возможное.
S>>Про показывалку вопрос. Что принимает драйвер видеокарты в общем виде? Вектор и растр? Вектор видимо отличается сильно по возможностям для разных карт — но в среднем какие там возможности? Как-то можно напрямую с этим поработать на любимом ЯП?
S>Можно через interop.
Здравствуйте, Shmj, Вы писали:
S>>>Про показывалку вопрос. Что принимает драйвер видеокарты в общем виде? Вектор и растр? Вектор видимо отличается сильно по возможностям для разных карт — но в среднем какие там возможности? Как-то можно напрямую с этим поработать на любимом ЯП?
S>>Можно через interop.
S>Интересуют конкретные практики.
Для начала можно создать device independent bitmap и порисовать на нем вручную разные графические примитивы, шрифты, проекции, z-глубину и т.п, поглядывая в GDI. Потом разобрать несколько форматов растра для разных устройств.
Смысла в этом примерно никакого, только размять мозги. Любимый ЯП не угонится за производительностью железа от средне-древней видеокарты, и вряд ли даже превзойдет программную эмуляцию отсутствующих возможностей драйвера видяхи.
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Вот осознал что всегда работал на неком уровне абстракции — платформа тебя заботливо ограждает от реальных сущностей, причем очень очень сильно ограждает, так что даже теряется общее представление как оно устроено, даже если у тебя опыт работы много лет.
S>Хотелось бы больше для ликбеза чуть приблизиться к реальному железу, понять на каком языке с ним разговаривают уже после уровня драйверов. Но при этом не хотелось бы вдаваться в системные языки — все в рамках C#.
Грубо говоря, взаимодействие между программой на любимом ЯП и любой железкой строится по одной из двух схем:
1. Программа->ОС->Драйвер->Железка.
2. Программа->Память->Железка
Второй способ применяется для ускорения работы, и доступен не для всего и не везде. Требует специальных усилий от разработчиков железки и драйверов для неё.
Поэтому вас должен интересовать способ номер один. Вообще говоря, цепочка может оказаться и длиннее (к примеру, для обработки соединений по HTTP в винде есть отдельный драйвер режима ядра; естественно, этот драйвер "разговаривает" не с железкой, а с драйвером TCP/IP), но для начала разбора этого достаточно.
Современные операционные системы всё взаимодействие с прикладными программами представляют в виде вызовов из динамически прилинкованных библиотек.
Поэтому всё, что вам нужно уметь делать — это интероп.
А дальше — открываете документацию и читаете. Для вашего удобства какие-то детали реализации скрыты за общими абстракциями.
Например, если вы хотите выводить 2d-графику, то в windows есть подсистема GDI. Она построена в терминах некоторых абстракций типа контекст устройства, над которым можно выполнять растровые (BitBlt) и векторные операции, а также текстовый вывод. Вам не нужно разбираться, как именно делается оптимизация этих операций в различных видеокартах.
Если вам нужно выводить 3d-графику, то вы можете взять DirectX. Или OpenGL. Или ещё какой-то стандарт, который избавит вас от изучения различий между ATI и NVidia.
Или, наоборот, вы можете взять документацию по конкретно вашей графической карте, и освоить её.
Там будет ровно всё то же самое — какая-то dll, экспортирующая набор функций. И некоторый формат представления данных в параметрах этих функций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Вот осознал что всегда работал на неком уровне абстракции — платформа тебя заботливо ограждает от реальных сущностей, причем очень очень сильно ограждает, так что даже теряется общее представление как оно устроено, даже если у тебя опыт работы много лет.
S>Хотелось бы больше для ликбеза чуть приблизиться к реальному железу, понять на каком языке с ним разговаривают уже после уровня драйверов. Но при этом не хотелось бы вдаваться в системные языки — все в рамках C#.
S>Грубо говоря комп представляет из себя: S>1. Вычислялку — процессор.
Их может быть несколько и у каждого могут быть ядра и потоки и ядра могут быть производительные и слабые. S>2. 2 хранилки — быструю временную и медленную (ОЗУ и диск).
а еще есть регисты, Cache L1, L2, L3 и L4 бывает и потом только ОЗУ, да и ОЗУ разделена на строки, банки, ранки и т.п. при этом разница в скорости на несколько порядков.
с дисками тоже много приколов, особенно с ссд S>3. Показывалку — монитор.
их может быть много S>4. Вводилку — клавиатуру/мышь/сенсор.
еще планшеты, геймпады и шлемы есть S>5. Говорилку/слушалку. S>6. Связывалку — сеть.
А как же ком порты и bt-le
S>Интересное еще про говорилку. Как оно вообще внутри работает? Ей подают сигнал в виде потока просто? Аналогичный вопрос про слушалку — с нее получаем просто поток?
просто блоками кормишь и так же блоками получаешь по мере готовности.
S>Про показывалку вопрос. Что принимает драйвер видеокарты в общем виде? Вектор и растр? Вектор видимо отличается сильно по возможностям для разных карт — но в среднем какие там возможности? Как-то можно напрямую с этим поработать на любимом ЯП?
Напрямую вам особо никто не даст, но можете spir-v поизучать.
А вообще если хочется железа возьмите ардуинку поковыряйте или одноплатники типа jetson
Здравствуйте, Shmj, Вы писали:
S>Интересное еще про говорилку. Как оно вообще внутри работает? Ей подают сигнал в виде потока просто? Аналогичный вопрос про слушалку — с нее получаем просто поток?
Простая звуковая карта может получать на входе просто поток самплов. Сложная может иметь внутри себя специализированный процессор, да еще и не один.
Поскольку обработка звукового потока на лету — задача не больно-то напряжная для современного процессора, то в этой области имеется тенденция к упрощению. Т.е., все преобразования звука делаются в софте, и только финальное преобразование цофры в аналоговый сигнал делается в железе.
С микрофона поступает поток самплов.
S>Про показывалку вопрос. Что принимает драйвер видеокарты в общем виде? Вектор и растр? Вектор видимо отличается сильно по возможностям для разных карт — но в среднем какие там возможности? Как-то можно напрямую с этим поработать на любимом ЯП?
Ой, драйвера видеокарт неимоверно сложные. Современная видеокарта представляет собой несколько десятков специализированных процессоров. Причем никто из производителей не хочет раскрывать в точности их систему команд.
Кроме того, существует куча исторически обусловленных интерфейсов, которые должна поддерживать видеокарта.
Поэтому она может выглядеть и как растр, в который можно рисовать определенными графическими примитивами ("нарисуй линию", "всоси фонт", "напиши слово ранее всосанным фонтом"), так и как программируемое устройство, и, например, если она реализует OpenGL, то команда будет, "на тебе текст программы на (почти) С, откомпилируй и запусти в видеокарте"), если это будет какой-нибудь Vulkan, то программа будет не в виде текста на C, а в виде байт-кода, а есть еще в венде DirectX, со своими собственными прибамбасами, которых я не особо знаю.
И все это одновременно в одном драйвере.
Я бы на месте писателей видеодрайверов давно удавился от отчаянья.
Здравствуйте, Shmj, Вы писали:
S>>Ниже уровня драйверов с ним, железом, ОС разговаривает-- прерывания и та вещи. Это Си, вам.
S>Не ниже — выше. Т.е. работать средствами ОС, но максимально близко — выжать все возможное.
Если ты сделаешь TCP, взяв на себя работу с пакетами через PCAP, то, скорее всего, твой TCP будет работать медленнее и хуже чем тот, который в ядре. В частости потому, что внутриядерный интерфейс между ядерной реализацией TCP и драйвером сетевой карты продуман лучше, чем тот попакетный интерфейс, который тебе выдаст PCAP.
Могу что-то путать, заранее извиняюсь. Напишу, как знаю.
Есть центральный процессор. Кроме него в типовом компьютере есть ещё много других процессоров. Звуковая карта со своим процессором. Сетевая карта со своим процессором. Ну про графическую все знают. Даже в SSD-диске свой процессор.
Понятно, что ты программируешь именно центральный процессор. Код для других процессоров (прошивку) обычно пишет производитель.
Вот дальше я немножко плаваю, но насколько я знаю, основной способ общения центрального процессора с другими процессорами и прочими устройствами это виртуальная или реальная оперативная память, а также механизм прерывания.
К примеру сетевая карта получает сетевые пакеты, записывает их в оперативную память по заранее договорённому адресу один за другим и в какой-то момент посылает прерывание, например когда пакетов стало слишком много.
Также в x86 процессоре имеются т.н. порты, но вроде как они в современных ОС не используются после этапа загрузки, поэтому для простоты их можно опустить.
Т.е. всё, что тебе надо для работы напрямую с железом из C# это иметь доступ к произвольным адресам оперативной памяти. Ну и, конечно, возможность запустить виртуальную машину без операционной системы и запустить свой код. Думаю, что и то и другое вполне достижимо. Понятно, что при загрузке какая-то часть будет написана на C/Assembler, но потом контроль передадут тебе и уже ты будешь за всё отвечать.
Но вообще, насколько я понимаю, этот уровень, на котором разговаривают с железом, это многие талмуды из многих тысяч страниц. Один USB реализовывать задолбаешься. И если по открытым стандартам ты можешь и сможешь написать драйвер клавиатуры или мыши, то когда дело зайдёт о проприетарном железе, даже о банальной звуковой карте, то тут уже никакой информации у тебя вообще не будет. Производитель её не публикует. В ядре линукса может быть найдёшь код драйверов. Ну или реверс-инжинирингом виндовых драйверов чего добиться сможешь, если устройство не слишком сложное. Но это явно не занятие для самообразования. Это уже полный хардкор.
S>К примеру, узнал интересное про сеть. В .Net есть класс Socket. Но он не умеет напрямую IP-протокол, поверх которого все строится. По сути глобальный протокол 1 уровня — это именно IP (не считая канальные и всякие прочие — которые не выходят из локальной зоны) — а TCP и UDP уже поверх него. Предлагают некую байду — https://github.com/PcapDotNet/Pcap.Net , который работает поверх WinPcap. Ну хотя бы так.
А тут всё просто. Во-первых такое API работает только от root (от администратора), от обычных пользователей это делать запрещено. Поэтому уже тут львиная доля его полезности теряется. Ну а во-вторых TCP/IP стек в операционной системе реализован нормально и никакой нужды пытаться его повторять обычно нет.
Кстати когда такая нужда у Google появилась, они сделали свой протокол поверх UDP, а не поверх IP.
S>Интересное еще про говорилку. Как оно вообще внутри работает? Ей подают сигнал в виде потока просто? Аналогичный вопрос про слушалку — с нее получаем просто поток?
Как я понимаю, в общем случае это N каналов (например 7 динамиков и сабвуфер), в каждый канал пишется звук в определённом формате. Ну примерно так же с микрофоном. Кроме того у звуковых карт имеется какая-то своя логика, например хорошие карты умеют смешивать сигналы сами, например ты ей подаёшь два сигнала от браузера и от музыкального плеера, а она их смешивает сама. В целом это всё проприетарное и специфичное для конкретной звуковой карты, стандартов тут, насколько я знаю, нет.
S>Про показывалку вопрос. Что принимает драйвер видеокарты в общем виде? Вектор и растр? Вектор видимо отличается сильно по возможностям для разных карт — но в среднем какие там возможности? Как-то можно напрямую с этим поработать на любимом ЯП?
Видеокарта это отдельный полноценный компьютер. Видеодрайвер это практически отдельная операционная система. Это всё неимоверно сложная машинерия. Вряд ли ты с этим сможешь поработать на железном уровне. Лучшее, что ты можешь попробовать, это найти старые стандарты вроде VGA, по идее даже современные видеокарты их поддерживают, это, конечно, будет использование видеокарты на мизерную долю процента от своих возможностей, но формально — ты будешь говорить с ней "напрямую".
А вообще с твоими желаниями тебе прямой путь в микроконтролеры. Да, придётся писать на С, но никакой беды в этом нет. Зато там довольно интересно, всё открыто и понятно.
Здравствуйте, Shmj, Вы писали:
>? Как-то можно напрямую с этим поработать на любимом ЯП?
Рекомендую забыть о «любимом ЯП», если собираешься заниматься перечисленным. Лоу левел — это кровавый си с элементами плюсов, абстракции только мешают.
Здравствуйте, Pzz, Вы писали:
Pzz>Ой, драйвера видеокарт неимоверно сложные. Современная видеокарта представляет собой несколько десятков специализированных процессоров. Причем никто из производителей не хочет раскрывать в точности их систему команд.
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Вот осознал что всегда работал на неком уровне абстракции — платформа тебя заботливо ограждает от реальных сущностей, причем очень очень сильно ограждает, так что даже теряется общее представление как оно устроено, даже если у тебя опыт работы много лет.
S>Хотелось бы больше для ликбеза чуть приблизиться к реальному железу, понять на каком языке с ним разговаривают уже после уровня драйверов. Но при этом не хотелось бы вдаваться в системные языки — все в рамках C#.
То есть хочешь работать на фактической реализации, пользуясь инструментами, предназначенными для того, чтобы максимально от неё абстрагироваться.
Так-то и в бейсике можно, когда-то достаточно было команд POKE, DATA, RANDOMIZE USR.
Здравствуйте, Sharov, Вы писали:
Pzz>>Ой, драйвера видеокарт неимоверно сложные. Современная видеокарта представляет собой несколько десятков специализированных процессоров. Причем никто из производителей не хочет раскрывать в точности их систему команд.
S>А в чем проблема отреверсить?
Здравствуйте, vsb, Вы писали:
vsb>Т.е. всё, что тебе надо для работы напрямую с железом из C# это иметь доступ к произвольным адресам оперативной памяти. Ну и, конечно, возможность запустить виртуальную машину без операционной системы и запустить свой код. Думаю, что и то и другое вполне достижимо. Понятно, что при загрузке какая-то часть будет написана на C/Assembler, но потом контроль передадут тебе и уже ты будешь за всё отвечать.
Что значит запустить вирт. машину без ОС? Кому bios (uefi) передаст управление?
Здравствуйте, Sharov, Вы писали:
vsb>>Т.е. всё, что тебе надо для работы напрямую с железом из C# это иметь доступ к произвольным адресам оперативной памяти. Ну и, конечно, возможность запустить виртуальную машину без операционной системы и запустить свой код. Думаю, что и то и другое вполне достижимо. Понятно, что при загрузке какая-то часть будет написана на C/Assembler, но потом контроль передадут тебе и уже ты будешь за всё отвечать.
S>Что значит запустить вирт. машину без ОС?
Ну то и значит.
S>Кому bios (uefi) передаст управление?
Загрузчику какому-нибудь. Загрузчик найдёт диски, подмонтирует файловые системы, найдёт все нужные для запуска файлы и передаст управление уже непосредственно виртуальной машине, которая загрузит нужные DLL-ки и запустит выполнение.
Конечно это потребует доработки самой виртуальной машины, чтобы она могла работать в таких условиях.
Кстати Microsoft писали уже ОС на C#: Singularity. Можно посмотреть, как там сделано.
Здравствуйте, Teolog, Вы писали:
S>>Что значит запустить вирт. машину без ОС? Кому bios (uefi) передаст управление? T>Baremetal это зовется. Иногда применяется даже на контейнерных серверах ради экономии ресурсов.
Или контроллер какой-нибудь, т.е. спец. железка. Кстати, а зачем контейнеры (если речь о докер?), если
нету ОС?
Здравствуйте, vsb, Вы писали:
S>>Кому bios (uefi) передаст управление? vsb>Загрузчику какому-нибудь. Загрузчик найдёт диски, подмонтирует файловые системы, найдёт все нужные для запуска файлы и передаст управление уже непосредственно виртуальной машине, которая загрузит нужные DLL-ки и запустит выполнение.
Чем ВМ в данном случае будет от ОС отличаться? А зачем dll(как формат) без ОС?
vsb>Конечно это потребует доработки самой виртуальной машины, чтобы она могла работать в таких условиях.
Ага, доработки до полноценной ОС. И в чем смысл тогда?
vsb>Кстати Microsoft писали уже ОС на C#: Singularity. Можно посмотреть, как там сделано.
Мы говорим про ВМ без ОС, зачем ссылаться на ОС?
Все это смахивает на какой-нибудь гипревизор, но он для упаврления ОС как раз и нужен, иначе --
