Операционная система от А до Я: Планировщик

Планировщик — мозг операционной системы. Его задача: решать, какая задача выполняется сейчас, и по каким правилам выдавать процессор другим задачам. Для embedded систем это особенно критично: ресурсы ограничены, реальное время важно, а поведение должно быть предсказуемым. Это вторая из цикла статей про создание микроядерной операционной системы. В прошлой статье рассматривался таймер и HAL. Для вновь пришедших необходимо сначала ознакомиться с ней: https://habr.com/ru/articles/935058/

https://habr.com/ru/articles/936762/

#ос #операционная_система #avr #ассемблер #планировщик #микроядро #микроядерная_архитектура

Операционная система от А до Я: Таймер и HAL

Последние несколько вечеров я занимаюсь написанием простенькой операционной системы с микроядерной архитектурой. Зная, что такое занятие имеет не только исследовательский смысл, но и может стать кому то темой для курсовой или дипломной работы, я решил поделиться матчастью и показать, как всё устроено. OSdev был и остаётся высшим пилотажем в мире программирования, и я готов помочь.

https://habr.com/ru/articles/935058/

#ос #операционная_система #avr #ассемблер #таймер #микроядро #микроядерная_архитектура

[Перевод] Программа «Hello World» на машинном коде под DOS

Как-то раз я послушал следующее интересное выступление (по-немецки): https://media.ccc.de/v/ds24-394-linux-hello-world-nur-mit-einem-hex-editor В нём разобрано, как написать программу «hello world» для 64-разрядного дистрибутива Linux в шестнадцатеричном редакторе. Ассемблер здесь не используется, программа пишется непосредственно на машинном коде. Правда, в ней есть издержки на использование ELF . Мне понравилась такая идея, и я решил повторить такой опыт, но немного в иной форме – а именно, под 16-разрядной DOS в реальном режиме . У меня должен был получиться файл в формате COM , а не EXE , так как (на данном этапе) меня интересовал не столько формат файла, сколько кодировка инструкций. В вышеупомянутой лекции, если честно, не сообщается почти никаких подробностей о том, как именно перейти от ассемблерного кода к машинному — поскольку в случае разбора этих тем лекция, пожалуй, растянулась бы на несколько часов. Но здесь я всё разберу подробно, и при этом собираюсь пользоваться только документацией lntel , а также дизассемблировать код в целях верификации. Также мы коротко поговорим о сегментации . В качестве шестнадцатеричного редактора на этот раз воспользуемся hexedit .

https://habr.com/ru/articles/934032/

#ассемблер #helloworld #память #низкоуровневое_программирование #программирование #машинный_код

Гайд на полиморфизм. Rust

В прошлых статьях мы разобрали теорию: что такое полиморфизм и какие существуют способы его реализации. Настало время посмотреть, как это реализуется на практике. В качестве примера был выбран Rust — язык с богатой функциональностью, с одной стороны, и простой, прозрачной реализацией — с другой.

https://habr.com/ru/articles/925576/

#rust #полиморфизм #перегрузка_операторов #vmt #перегрузка #указатели #виртуальные_функции #assambler #under_the_hood #ассемблер

Низкоуровневое программирование под 8086 для любопытных, часть 2

В этой части нас ждёт погружение в один из способов организации мультипоточности на базе единственного ядра процессора. Мы научимся принудительно переключать выполнение между полностью зацикленными участками кода, ничего не "знающими" о каком-то другом коде, конкурирующем за процессорное внимание. По ходу повествования будут даны все необходимые пояснения и читателю не придётся обращаться к другим источникам, кроме первой части статьи.

https://habr.com/ru/articles/907312/

#assembler #i8086 #низкоуровневое_программирование #agalilov #прерывания #стек #видеобуфер #ассемблер #ассемблер_для_начинающих #мультизадачность

Часть 3. Векторизация на Go: CGo, транзакции, компиляторы, поддержка, байтовые инструкции

В первой части статьи мы рассмотрели , как можно вручную ускорить Go-код с помощью векторизации и SIMD-инструкций, реализованных через Go-ассемблер. Написали простую, но показательно быструю реализацию sliceContains и увидели, что даже базовая векторизация может дать ускорение в 10–14 раз по сравнению со стандартной реализацией. Во второй части статьи погрузились в практическое применение SIMD в Go-ассемблере, реализовали функцию SliceContainsV1 и изучили, как с помощью VADD, VDUP и других инструкций можно добиться 10–14-кратного ускорения простых задач. Но возможности оптимизации Go-программ на этом не заканчиваются. В этой части мы пойдём дальше: рассмотрим другие техники низкоуровневой оптимизации — от использования C-кода и альтернативных компиляторов с поддержкой векторизации до работы с аппаратными транзакциями памяти на Intel. Поговорим о том, как внедрять ассемблер в продакшен-код, не боясь за его поддержку, и как обойти ограничения стандартного Go-компилятора. Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества, веду телеграм-канал и youtube-канал. Если вы уже знакомы с базовыми техниками векторизации, эта часть поможет глубже понять, как устроены продвинутые способы ускорения Go-кода и на что стоит обратить внимание при работе с архитектурно-зависимыми оптимизациями.

https://habr.com/ru/companies/oleg-bunin/articles/905972/

#golang #optimizations #компилятор #gccgo #gollvm #ассемблер #word #byte #производительность

Зачем программисту дизассемблер в 2025: отладка на слепую под редкие MCU

Даже в 2025 году, когда вокруг нейросети, автогенерация кода и IDE с предиктивным интеллектом, работа с редкими микроконтроллерами всё ещё может обернуться настоящим хардкором. Особенно, если речь идёт о «слепой» отладке без отладчика, когда в арсенале только прошивка, HEX-файл и пара байтов на выводе. В этой статье — личный опыт, много хардкора, дизассемблирование вручную и поиск глюка в 2 КБ бинаря. Когда говорят «отладка», в 2025 году чаще всего имеют в виду жмяк на F5 в Visual Studio Code или лог с CI/CD. Но в embedded-мире, особенно если ты копаешься в системах с 8-битным контроллером 2006 года выпуска, это слово может означать кое-что пострашнее. Например — «прошивка вылетает на 4-й секунде, данных в UART нет, отладочного интерфейса нет, документации почти нет, а заказчик просит сделать "как раньше работало"». И вот тут начинается старый добрый reverse engineering.

https://habr.com/ru/articles/907810/

#дизассемблер #MCU #отладка #embedded #MSP430 #бинарный_анализ #прошивка #ассемблер

Часть 1. Почему Go-ассемблер и векторизация могут быть полезны: идея для ускорения

Когда речь заходит о производительности в Go, большинство разработчиков полагаются на стандартные библиотеки и встроенные инструменты оптимизации, но компилятор Go не всегда генерирует оптимальный машинный код. В таких случаях можно взять дело в свои руки и использовать ассемблерные инструкции для ускорения критически важных участков. Ассемблер может показаться сложным и пугающим, но он открывает большие возможности для работы с низкоуровневыми оптимизациями. Готовы разобраться, как это работает? Тогда погнали! Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества.

https://habr.com/ru/companies/oleg-bunin/articles/905966/

#golang #optimization #intermediate_representation #ssa #ассемблер #машинный_код #simd #intrinsic #синтаксис #VMOV

[Перевод] Как специально написать чрезвычайно медленный код

Раз в несколько лет я устраиваю в нашей исследовательской группе челлендж «Напиши медленный код». Цель – написать код с минимально работоспособным количеством инструкций на цикл (IPC) с условием, чтобы этот код выполнялся на заранее подобранном сервере с архитектурой x86. На первый взгляд, это абсурд! В сущности, так и есть. Однако, есть в этой безумной задаче и некоторая методическая ценность. Инженеры, проектирующие процессоры, прилагают все усилия ради достижения наивысшего возможного IPC… даже для очень неэффективного кода . Так и задумано, что писать код с очень высоким показателем IPC непросто . Следовательно, челлендж “Напиши медленный код” оказывается заковыристым упражнением, вынуждающим задумываться, как именно работает процессор, и как применить себе на пользу его острые углы.

https://habr.com/ru/articles/906144/

#ассемблер #x86 #производительность #челлендж #низкоуровневое_программирование

[Перевод] Как специально написать чрезвычайно медленный код

Раз в несколько лет я устраиваю в нашей исследовательской группе челлендж «Напиши медленный код». Цель – написать код с минимально работоспособным количеством инструкций на цикл (IPC) с условием, чтобы этот код выполнялся на заранее подобранном сервере с архитектурой x86. На первый взгляд, это абсурд! В сущности, так и есть. Однако, есть в этой безумной задаче и некоторая методическая ценность. Инженеры, проектирующие процессоры, прилагают все усилия ради достижения наивысшего возможного IPC… даже для очень неэффективного кода . Так и задумано, что писать код с очень высоким показателем IPC непросто . Следовательно, челлендж “Напиши медленный код” оказывается заковыристым упражнением, вынуждающим задумываться, как именно работает процессор, и как применить себе на пользу его острые углы.

https://habr.com/ru/articles/906144/

#ассемблер #x86 #производительность #челлендж #низкоуровневое_программирование