В YADRO есть команда, которая разрабатывает и отлаживает UEFI для самых разных продуктов компании. Подробнее о ней — в видеоролике → .
Первая особенность работы — в распределенной команде. Серверы, на которых инженеры разрабатывают прошивки, могут находиться в Москве, а разработчики — в других городах: от Владивостока до Калининграда и от Архангельска до Смоленска.
Системы, для которых разрабатывают прошивки в YADRO, делятся на два типа: с BMC и без него.
Больше о работе команды и, в целом, об истории BIOS/UEFI читайте в статье →
А если тоже хотите стать «поваром» UEFI, присмотритесь к одной из вакансий:
SystemVerilog отжил свое? На пятки наступает Scala/Chisel?
DARPA, управление перспективных исследовательских проектов Минобороны США, описывает Chisel как технологию, позволяющую маленьким командам создавать большие цифровые проекты. И я вполне могу с этим согласиться, но есть нюансы.
Chisel — это, по сути, библиотека Scala, а точнее, Domain Specific Language. Языку Scala уже больше 20 лет, он постоянно развивается, сочетает функциональное и императивное программирование. При написании кода на Scala вам доступны все библиотеки Java.
Scala — это масштабируемый язык, который позволяет добавлять свои языковые конструкции. На основе Scala можно создать язык под свои задачи. Так 12 лет назад и поступили инженеры в Беркли: выкинули из Verilog 90%, оставив только нужное, и обернули все это в Scala. Получился Chisel.
Chisel используют прежде всего для создания RTL-описаний. Также он позволяет проводить симуляцию несложных модулей. Это удобно для создания юнит-тестов и моделирования работы различных алгоритмов. В плане симуляции не стоит возлагать на Chisel такие же надежды, как на System C или что-то подобное. Симулировать вы сможете лишь очень маленькие схемки, а генерировать — хоть целые кластеры из тысяч процессоров, вообще все, что захотите.
На основе Chisel/Scala можно написать свой HLS-инструмент (High Level Synthesis), где одним росчерком пера вы будете создавать очень большие схемы, что с использованием одного Verilog невозможно.
В блоге YADRO Денис Муратов подробно сравнил Chisel/Scala с SystemVerilog в создании RTL-описаниях, раскрыл основные преимущества и недостатки альтернативы, а также ее дополнительные возможности — функциональное программирование и переиспользование модулей.
Я информирую о релизе постом только потому, что у меня лично сейчас нет свободного времени написать полноценную статью об всех изменениях. Изменений много.
Важное изменение, которое всё же я упомяну - появился свой backend для компилятора. То есть отказ от LLVM состоялся, но на данный момент только для Linux x86_64.
Системным программистам в YADRO нужно было «обмануть» драйвер в Linux: он не должен «знать», что работает в эмуляции.
Для этого ведущий инженер Никита приступил к созданию виртуального двойника Intel NTB Gen3 в QEMU, документации к которому в открытом доступе нет. Реализованная модель позволяет производить разработку и тестирование протоколов более высокого уровня, а также выполнять их качественное сравнение.
PCIe NTB не позволяет увидеть адресное пространство, которое принадлежит к подключенному по NTB соседнему устройству. Вкратце он работает так:
перенаправляет трафик PCIe между шинами как мост,
CPU рассматривает мост как конечное устройство,
CPU не «видит» все устройства на «другой» стороне, как правило, другая сторона — это другой компьютер.
Упрощенное представление PCIe NTB
С точки зрения эмуляции, нужно уделить особое внимание регистрам, прерываниям и моделированию поведения устройств.
В работе с PCI BAR необходимо обеспечить прозрачное использование Linux-драйвера Intel NTB для оптимального взаимодействия с оборудованием, которое мы эмулируем. Еще одна задача — разработать новые транспорты, которые работают поверх эмуляции: RPMSG, Virtio/Vhost, NTRDMA и другие. Также одна модель помогла найти ошибки в инициализации драйвера.
Никита подробно описывает тернистый путь создания виртуального двойника Intel NTB Gen3 в статье →
«Пушим байты» в сугробы: новогодняя демосцена 2025
Признанная классика демосцены — PICO-8, в арсенале которой сотни игр разной сложности. Мы же пойдем более оригинальным путем и напишем новогоднюю демку для BytePusher. Эта приставка включает 8-битный процессор, предлагает разрешение 256x256 и 8-битный цвет. Но самое интересное в ней — это OISC-архитектура ByteByeJump (BBJ).
OISC, One-Instruction Set Computer, известна гораздо меньше, чем RISC или CISC. Ее простота, очевидная из названия, привлекает немного энтузиастов, судя по странице BytePusher. Тем интересней будет сделать что-нибудь для нее с нуля.
Этим и занялся в своей статье Пётр Советов, специалист в области разработки DSL-компиляторов и старший научный сотрудник лаборатории специализированных вычислительных систем РТУ МИРЭА. Написал ассемблер на Python, разобрался с вычислениями без АЛУ и «отрисовал» классическое демо с падающим снегом. Еще и со «звездочкой» в виде сугробов и статичных цифр.
Три проверенных метода организовать обмен прерываниями между машинами QEMU c KVM и без
Эмулятор QEMU помогает решать ряд задач, в том числе разработку и отладку любого уровня коммуникаций. Вы можете эмулировать работу не только отдельной машины, но и связывать несколько независимых машин между собой.
Быстрая работа такой связки приятна при разработке/отладке и очень важна при массовом прогоне автотестов в CI. Как оптимизировать обмен прерываниями и какой подход к организации IQI вам подойдет — узнаете из статьи. А еще разберемся c:
устройством QEMU под капотом,
реализацией модели и драйвера,
добавлением прерываний MSI-X,
результатами замеров.
На бонус: десяток полезных материалов для изучения.
В гостях у подкаста «Битовые маски» — Николай Иготти, разработчик, участвовавший в создании многих известных проектов международных корпораций. Николай успел поработать над HotSpot в Sun Microsystems, над гипервизором VirtualBox, а также в разных проектах Google и EMC. Руководил разработкой Kotlin/Native компилятора и Compose Multiplatform в JetBrains, а сейчас трудится в Huawei. В выпуске затронули много разных тем — от гипервизоров до дизайна современных языков программирования:
Чем виртуальные машины отличаются друг от друга и от процессоров.
В чем сложности создания гипервизоров.
С какими проблемами придется столкнуться при создании нового языка программирования.
В чем особенности и отличия разработки системного ПО от прикладного.
Как связана разработка современных UI-фреймворков с системным программированием.
Какие задачи в системном программирование самые интересные.
Как учить будущих специалистов в этой сфере.
Бонус: разбор того, что не давало запустить VirtualBox c MacOS на архитектуре x86.
Добрый день. Пару месяцев назад я закончил написание книги и выставляю её в открытый доступ: GitHub
В чём идея? Контент этой книги представляет собой не только обучение языку C, но и обучение большому количеству прикладных вещей с серьёзной глубиной погружения. Я постарался дать ответ на как можно большее количество вопросов, которые возникают в процессе изучения, оставив минимальное количество дыр в понимании, как всё работает.
Посмотреть .html файл книги можно на GitHub-е. Но он не рендерит MathJax, поэтому лучше скачать файл c-book.html локально. Можно как угодно (в том числе в issues) сообщать мне о нерабочем коде в примерах, опечатках, неправильных утверждениях с моей стороны. Буду также рад увидеть конструктивную критику. Возможно, в ответ на неё, я буду добавлять новые главы в книгу.
(Эта книга абсолютно точно не является рекламой Zig-а.)
Если вы откроете проект на gitee.comвы увидите что проект включает в себя больше 700 (семисот!) репозиториев. Секрет в том что ни один из этих проектов в отдельном репозитории не компилируется независимо! Один знакомый разработчик, который работает с этим богатством, рассказал мне, что чтобы скомпилировать какой либо из проектов составляющих OpenHarmony вы должны скачать и скомпилировать минимум 450 репозиториев! Дело в том что даже отдельные приложения такие как mailBox, storage с СМС-ками, с контактами, видео плеер, ... которые, казалось бы, должны быть отдельными приложениями таковыми не являются. Они все компилируются как части одной монолитной прошивки смартфона (как части операционной системы) и вы не можете скомпилировать их без компиляции всей системы, такая опция просто не предусмотрена.
Поэтому OpenHarmony превратилась в огромного монстра который уже не может даже шевелиться от собственной тяжести. Внутренние связи и зависимости между функциями приложений и зависимостями ядра и системных библиотек никто не контролирует, они постоянно дублируются все в новых и новых модификациях, входят в противоречие друг другом, генерируют противоречивые потоки данных, копии данных, несовместимые интерфейсы, ... все это подобно раковой опухоли которая разъедает-разрывает носителя изнутри.
Каждый новый добавленный в OpenHarmony репозиторий приближает видимый крах проекта.
Интересно как обстоят дела у Андроида в этом смысле.
Вот мы (те кто следит за языком Zig) и дожили до этого момента. Большой вопрос зачем Zig в проде сейчас. Но сам факт такого похвальный. Начали появляться смельчаки, готовые взять ещё очень молодой язык в работу. Я туда не откликнусь, не мой стек. Но может найдутся желающие
Всем привет. Возможно, вы помните меня по статьям об изменениях в C++ и о фреймворке 🐙 userver, поэтому сразу к делу. 27 июля я выступаю на конференции C++ Zero Cost Conf, которая пройдёт в Москве и Ереване. Там я поделюсь новостями со встречи Международного комитета по стандартизации языка в Сент-Луисе и расскажу о наших планах на C++26 и C++29. А ещё отвечу на ваши вопросы. Приходите в гости!
Помимо меня, вас также будут ждать:
Константин Владимиров, руководитель отдела компиляторов и средств разработки Syntacore. Покажет развитие архитектуры сложного LLVM-based-C++-проекта и конкретные задачи, возникающие при его развитии.
Андрей Аксёнов, руководитель разработки инфраструктуры поиска Авито/Sphinx. Расскажет историю из продакшена с One Billion Row Challenge, парсингом гигабайтов TSV’шек, десятью странными оптимизациями и боттлнеками вообще везде.
Сергей Слотин, разработчик. Поговорит об устройстве памяти и кешей, их странностях и неожиданных последствиях для производительности.
Константин Облаков, старший разработчик браузера Яндекс Поиска и Рекламных технологий. Покажет на практике, как GDB позволяет добиться результатов, недоступных другими методами.
Полный список спикеров и темы докладов смотрите на сайте.
Если не получится прийти лично, подключайтесь дистанционно.
25.03.2024 года «Лаборатория программно‑аппаратных комплексов с искусственным интеллектом» при финансовой поддержке ООО «НИЦ ЦТ» организовала первый семинар, посвящённый системному программированию.
#include <stdio.h>
int main () {
int a [100];
int i;
for (i=0; i<100; i++)
printf ("%d ", a[i]);
return 0;
}
При компиляции без оптимизации и вызове в Linux она выдаст некоторые числа, являющиеся мусорным содержимым памяти. Кто-нибудь в состоянии объяснить, откуда конкретно они берутся, и почему каждый раз разные при последовательных запусках программы?
Казалось бы, если это просто содержимое адресов, на которые приходится соответствующая секция исполняемого модуля, то оно должно бы сохраняться от запуска к запуску?
Объяснение в стиле “потому что виртуальные адреса мапируются на реальные рандомно” я и сам могу дать, хочется более глубокого понимания. Компьютер – вещь детерминированная, в нём случайность – это не познанная закономерность.
Upd: ответ дан уважаемым @alexvangog в закреплённом комментарии.
Утечки памяти преследовали программы на языке С с тех пор, как существует этот язык. Было предложено множество решений, вплоть до идеи переписать программы на языке C на других языках. Но есть лучший способ.
Здесь представлено простое решение, которое устранит утечки памяти в каждой программе на языке C. Используйте этот модуль с вашей программой, и утечки памяти останутся в прошлом.
Every allocated pointer is saved in the big bucket, where it remains accessible. Even if no other references to the pointer exist in the program, the pointer has not leaked.
It is now entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.
