Рубрика «системное программирование» - 66

Почти каждый микроконтроллерщик сталкивался с громадными switch-case и мучительно их отлаживал.
И много кто, начиная писать реализацию какого-либо протокола, задумывался как написать её красиво, изящно, так чтобы через месяц было понятно что ты имел в виду, чтобы она не отжирала всю память и вообще какала бабочками.
И вот тут на помощь приходят машины состояний, они же конечные автоматы (те самые которые используются в регулярных выражениях).

Собственно через регулярные выражения я к ним и пришёл.
Читать полностью »

Мне периодически приходится объяснять разным людям некоторые аспекты архитектуры Intel® IA-32, в том числе замысловатость системы адресации данных в памяти, которая, похоже, реализовала почти все когда-то придуманные идеи. Я решил оформить развёрнутый ответ в этой статье. Надеюсь, что он будет полезен ещё кому-нибудь.
При исполнении машинных инструкций считываются и записываются данные, которые могут находиться в нескольких местах: в регистрах самого процессора, в виде констант, закодированных в инструкции, а также в оперативной памяти. Если данные находятся в памяти, то их положение определяется некоторым числом — адресом. По ряду причин, которые, я надеюсь, станут понятными в процессе чтения этой статьи, исходный адрес, закодированный в инструкции, проходит через несколько преобразований.

Адреса памяти: физические, виртуальные, логические, линейные, эффективные, гостевые

На рисунке — сегментация и страничное преобразование адреса, как они выглядели 27 лет назад. Иллюстрация из Intel 80386 Programmers's Reference Manual 1986 года. Забавно, что в описании рисунка есть аж две опечатки: «80306 Addressing Machanism». В наше время адрес подвергается более сложным преобразованиям, а иллюстрации больше не делают в псевдографике.
Читать полностью »

Базовым адресом по умолчанию для DLL является 0x10000000, но для исполняемых файлов это 0x00400000. Почему именно такое особое значение для EXE? Что такого особенного в 4 мегабайтах?

Это имеет отношение к размеру адресного пространства, отображаемого одной таблицей страниц в архитектуре x86, и такую конструкцию выбрали в 1987 году.

Единственным техническим требованием для базового адреса EXE является кратность 64 КБ. Но некоторые варианты базового адреса лучше, чем другие.

Цель выбора базового адреса состоит в минимизации вероятности, что модули будут перемещены. Это означает, что следует предотвратить столкновение 1) с другими объектами, которые уже в адресном пространстве (что и вызовет перемещение); 2) а также с объектами, которые могут появиться в адресном пространстве позже (форсируя их перемещение). Для исполняемых файлов избегать конфликта с объектами, которые могут появиться позже, означает уход из района адресного пространства, который может быть заполнен библиотеками DLL. Поскольку сама операционная система помещает файлы DLL в старшие адреса и базовым адресом по умолчанию для несистемных DLL является is 0x10000000, то базовый адрес для EXE должен быть где-то младше 0x10000000, и чем младше, тем больше места останется до того, как вы начнёте конфликтовать с библиотеками. Но насколько низко нужно заходить?
Читать полностью »

Полное оригинальное название статьи: «Why your first FizzBuzz implementation may not work: an exploration into some initially surprising but great parts of Rust (though you still might not like them)»

tl;dr;-версия: На первый взгляд некоторые аспекты Rust могут показаться странными и даже неудобными, однако, они оказываются весьма удачными для языка, который позиционируется как системный. Концепции владения (ownership) и времени жизни (lifetime) позволяют привнести в язык сильные статические гарантии и сделать программы на нём эффективными и безопасными, как по памяти, так и по времени.

Лицензия: CC-BY, автор Chris Morgan.

Почему ваша первая реализация FizzBuzz может не работать: исследование некоторых особенностей Rust, которые изначально шокируют, но в действительности являются его лучшими сторонами (хотя они всё равно могут вам не понравиться)

http://chrismorgan.info/media/images/rust-fizzbuzz.svgFizzBuzz предлагается как простое задание для новичка, но в Rust присутствуют несколько подводных камней, о которых лучше знать. Эти подводные камни не являются проблемами Rust, а, скорее, отличиями от того, с чем знакомо большиство программистов, ограничениями, которые на первый взгляд могут показаться очень жёсткими, но в действительности дают громадные преимущества за малой ценой.

Rust это движущаяся цель, тем не менее, язык становится стабильней. Код из статьи работает с версией 0.12. Если что-то сломается, пожалуйста, свяжитесь со мной. Касательно кода на Python, он будет работать как в двойке, так и в тройке.
Читать полностью »

Классической тестовой программой для большинства программистов на системах, имеющих хоть какой-то дисплей, является Hello World. Такая традиция была введена Керниганом и Ритчи в 1978 году.

Для микроконтроллеров аналогичным примером уже давно стала программа, которая мигает светодиодом. В этой статье я покажу результат эксперимента по максимальному сокращению такой программы на примере контроллера ATTiny15 фирмы Атмел.

image

UPD: В комментариях привели ссылку на рекордное решение в 12 байт. Браво!

Читать полностью »

Большинство разработчиков воспринимают сборку мусора (garbage collection) как нечто само собой разумеющееся. Это стандартный процесс, который периодически освобождает память, удаляя ненужные объекты. А вот американский программист Кен Фокс (Ken Fox) захотел досконально разобраться и заглянуть «под капот» современных сборщиков мусора.

Кен «поигрался» с пятью разными алгоритмами сборки мусора и опубликовал маленькие анимации, которые наглядно демонстрируют их работу.

Анимации большего размера выложены на github.com/kenfox/gc-viz.
Читать полностью »

В предыдущей части я рассказал о трёх режимах IA-32: защищённом, VM86 и SMM. Хотя их и не принято связывать с виртуализацией, они служат для создания изолированных окружений для программ, исполняемых на процессоре. В этой статье я опишу «настоящую» технологию виртуализации Intel® VT-x. Я хочу показать, как теория эффективной виртуализации проявляется в каждом аспекте её практической реализации.

Виртуализация¹

На КДПВ: Запущенная под управлением Ubuntu Linux программа Oracle VirtualBox, в которой запущена операционная система MS Windows XP, в которой исполняется симулятор Bochs, в котором запущена операционная система FreeDOS, в котором запущен симулятор MYZ80 для процессора Z80, в котором загружена операционная система CP/M (в полноэкранном режиме).
Читать полностью »

Классическая теория эффективной виртуализации и обзор состояния индустрии в целом описаны в моей предыдущей публикации. В этой статье речь пойдёт о поддержке виртуализации в широком смысле в архитектуре Intel® IA-32.

Виртуализация⁰
Черепаха на спине черепахи на спине черепахи на спине… — космологическая теория, которой придерживаются создатели виртуальных машин.

Эта статья — нулевая в небольшой серии о технологиях Intel, помогающих представить компьютер не тем, чем он в реальности является, для программ (в т.ч. операционных систем, BIOS и прошивок), на нём запущенных.
В ней не будет говориться о настройке конкретных VMM, прозрачной миграции виртуальных машин, создании невидимых руткитов и многих других интереснейших вещах, произрастающих из этой фрактальной и потому неисчерпаемой темы. Мой взгляд будет с позиции системного программиста, занимающегося разработкой операционных систем и firmware или мониторов виртуальных машин и симуляторов, а также всех им сочувствующих.
Читать полностью »

Перехват функций ядра является базовым методом, позволяющим переопределять/дополнять различные его механизмы. Исходя из того, что ядро Linux почти полностью написано на языке C, за исключением небольших архитектурно-зависимых частей, можно утверждать, что для осуществления встраивания в большинство из компонентов ядра достаточно иметь возможность перехвата соответствующих функций.

Данная статья является продолжением анонсированного ранее цикла, посвящённого частным вопросам реализации наложенных средств защиты и, в частности, встраиванию в программные системы.

Читать полностью »

Разработка и отладка UEFI драйверов на Intel Galileo, часть 2: готовим плацдарм
Здравствуйте, уважаемыее.
Опрос в первой части показал, что тема разработки UEFI-драйверов достаточно интересна сообществу, поэтому я приступаю к написанию дальнейших частей этого цикла. В этой речь пойдет о подготовке платы Intel Galileo к работе, необходимом и желательном железе и ПО, сборке и установке BSP. В результате получится недорогая аппаратная платформа, пригодная для аппаратной отладки UEFI-драйверов и доступная любому энтузиасту.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js