Мне 38 лет, я сварщик из Санкт‑Петербурга. Профильного IT‑образования у меня нет. В июне 2026 года я купил ноутбук, поставил Linux и начал разбираться, как всё устроено изнутри. В октябре с этого же ноутбука я открыл страницу на смартфоне по обычному Wi‑Fi. Страницу отдавала операционная система, которую я собрал сам.
Рубрика «x86_64»
Микроядро seL4, Ada-SPARK и 185 модулей: разбор проекта
2026-10-16 в 12:09, admin, рубрики: sel4, spark, TCB, x86_64, микроядро, отладка, формальная верификацияРежимы работы x86-процессора
2026-10-16 в 7:03, admin, рубрики: long mode, OSDev, x86, x86_64, x86-64, архитектура процессора, ОС, процессор, режимы работы процессора, системное программированиеЭтой статьей я хочу описать часть своих знаний, приобретенных на моем пути в OSDev и системном программировании. Параллельно я буду писать также документацию по CS, которую в скором времени выложу на свой GitHub.
Важно подметить, что мой путь ещё далеко не окончен и я, можно сказать, нахожусь в самом его начале. Зачем тогда я это делаю? Чтобы закрепить уже имеющиеся знания, получить критику от более опытных специалистов, а также, возможно, помочь некоторым новичкам подробно разобраться в теме.
Принцип работы процессора.
Пишем на C самоизменяющуюся программу x86_64
2025-05-28 в 13:01, admin, рубрики: ruvds_перевод, x86_64, набор команд, опкоды, самомодифицирующийся код, шеллкодинг
«Зачем вообще писать программу, меняющую код в процессе выполнения? Это же ужасная идея!»
Да, всё так и есть. Но это и хороший опыт. Такое делают только тогда, когда хотят что-то исследовать, или из любопытства.
Самоизменяемые/самомодифицируемые программы не обладают особой полезностью. Они усложняют отладку, программа становится зависимой от оборудования, а изучение кода превращается в очень утомительный и запутанный процесс, если только вы не опытный разработчик на ассемблере. Единственный разумный сценарий применения самоизменяемых программа в реальном мире — это механизм маскировки зловредного ПО от антивирусов. Моя цель исключительно научна, поэтому ничем подобным я заниматься не буду.
Предупреждение: в этом посте активно используется язык ассемблера x86_64, в котором я ни в коем случае не являюсь специалистом. Для написания статьи мне пришлось изучать приличный объём материалов, и, возможно (почти наверняка), в ней есть ошибки.
Мои заметки про процессоры для cовсем маленьких
2024-11-01 в 7:15, admin, рубрики: amd64, x86, x86_64, архитектура процессора, простыми словами, процессор, строение процессора, схема процессораВступление
Центральный процессор (CPU, Central Processing Unit) — это основной компонент устройств, который выполняет все вычисления и логические операции, необходимые для работы программ.
Здесь я постараюсь рассказать про строение и работу процессора на примере x86–64 архитектуры.
Когда-то это всё я конспектировал для себя в дружелюбном для новичка виде, чтобы мне самому было проще вовзвращаться к этой информации время от времени.
Я решил поделиться своими заметками, так как возможно кому-то это может показаться полезным. На детальность информации не претендую, но не против конструктивной критики.
Как устроена страничная организация памяти x86_64
2024-02-02 в 9:05, admin, рубрики: gdb, qemu, x86_64, страничная организация памяти
В этом посте я буду говорить о страничной организации только в контексте PML4 (Page Map Level 4), потому что на данный момент это доминирующая схема страничной организации x86_64 и, вероятно, останется таковой какое-то время.
Окружение
ARM сервера — более производительные и более дешёвые
2020-12-31 в 10:51, admin, рубрики: arm64, AWS, EC2, Graviton2, RDS, x86_64, высокая производительность, сервер, Серверная оптимизация, Серверное администрирование, хранение данныхВ этом году Apple потрясла рынок десктопных процессоров чипом Apple M1 и устройствами на нём. Похожее событие произошло в мире облачных вычислений в прошлом году. AWS выпустили новый тип сервера на собственных ARM процессорах Graviton2. По заявлениям Amazon, соотношение производительности к цене у новых процессоров на 40% выше, чем у аналогов на x86. Ещё одно недавнее обновление - сервера Amazon RDS (облачный сервис, предоставляющий сервера баз данных) на Graviton2. Я запустил несколько бенчмарков и нагрузочный тест реального бэкенд приложения, чтобы проверить настолько ли хороши сервера на ARM процессорах и узнать какие проблемы совместимости могут возникнуть.
Читать полностью »
Сколько инструкций процессора использует компилятор?
2020-06-16 в 17:04, admin, рубрики: AArch64, ARMv7, i386, powerpc, sparc, x86_64, визуализация данных, Компиляторы, Процессоры, Статистика в ITМесяц назад я попытался сосчитать, сколько разных инструкций поддерживается современными процессорами, и насчитал 945 в Ice Lake. Комментаторы затронули интересный вопрос: какая часть всего этого разнообразия реально используется компиляторами? Например, некто Pepijn de Vos в 2016 подсчитал, сколько разных инструкций задействовано в бинарниках у него в /usr/bin, и насчитал 411 — т.е. примерно треть всех инструкций x86_64, существовавших на тот момент, не использовались ни в одной из стандартных программ в его ОС. Другая любопытная его находка — что код для x86_64 на треть состоит из инструкций mov. (В общем-то известно, что одних инструкций mov достаточно, чтобы написать любую программу.)
Я решил развить исследование de Vos, взяв в качестве «эталонного кода» компилятор LLVM/Clang. У него сразу несколько преимуществ перед содержимым /usr/bin неназванной версии неназванной ОС:
- С ним удобно работать: это один огромный бинарник, по размеру сопоставимый со всем содержимым /usr/bin среднестатистического линукса;
- Он позволяет сравнить разные ISA: на releases.llvm.org/download.html доступны официальные бинарники для x86, ARM, SPARC, MIPS и PowerPC;
- Он позволяет отследить исторические тренды: официальные бинарники доступны для всех релизов начиная с 2003;
- Наконец, в исследовании компиляторов логично использовать компилятор и в качестве подопытного объекта :-)
Начну со статистики по мартовскому релизу LLVM 10.0:
| ISA | Размер бинарника | Размер секции .text | Общее число инструкций | Число разных инструкций |
|---|---|---|---|---|
| AArch64 | 97 МБ | 74 МБ | 13,814,975 | 195 |
| ARMv7A | 101 МБ | 80 МБ | 15,621,010 | 308 |
| i386 | 106 МБ | 88 МБ | 20,138,657 | 122 |
| PowerPC64LE | 108 МБ | 89 МБ | 17,208,502 | 288 |
| SPARCv9 | 129 МБ | 105 МБ | 19,993,362 | 122 |
| x86_64 | 107 МБ | 87 МБ | 15,281,299 | 203 |
В прошлом топике комментаторы упомянули, что самый компактный код у них получается для SPARC. Здесь же видим, что бинарник для AArch64 оказывается на треть меньше что по размеру, что по общему числу инструкций.
А вот распределение по числу инструкций:
Читать полностью »
.NET Core: интринсики x86_64 на виртуальных машинах
2020-04-03 в 9:01, admin, рубрики: .net, C#, intrinsics, netcore, qemu-kvm, x86_64, виртуализацияМы живём в эпоху доминирования архитектуры x86. Все x86-совместимые процессоры похожи, но и все при этом немного отличаются. И не только производителем, частотой и количеством ядер.
Архитектура x86 за время своего существования (и популярности) пережила много крупных апдейтов (например, расширение до 64 бит — x86_64) и добавлений «расширенных наборов инструкций». К этому приходится подстраиваться и компиляторам, которые по-умолчанию генерируют максимально общий для всех процессоров код. Но среди расширенных инструкций есть много интересного и полезного. Например, в шахматных программах часто используются инструкции для работы с битами: POPCNT, BSF/BSR (или более свежие аналоги TZCNT/LZCNT), PDEP, BSWAP и т.д.
В компиляторах C и C++ явный доступ к таким инструкциям реализован через «присущие (intrinsic) данному процессору функции». пример1 пример2
Для .NET и C# такого удобного доступа не существовало, поэтому когда-то давно я сделал свою обёртку, которая предоставляла эмуляцию таких функций, но если CPU их поддерживал, то заменяла их вызов прямо в вызывающем коде. Благо, большинство нужных мне интринсиков помещались в 5 байт опкода CALL. Подробности можно почитать на хабре по этой ссылке.
С тех пор прошло много лет, в .NET нормальных интринсиков так и не появилось. Но вышел .NET Core, в котором ситуацию исправили. Сначала появились векторные инструкции, в потом и почти весь* набор System.Runtime.Intrinsics.X86.
* — нет «устаревших» BSF и BSR
И всё вроде-бы стало хорошо и удобно. Если не считать того, что определение поддержки каждого набора инструкций всегда было запутанным (какие-то включаются сразу наборами, для каких-то есть отдельные флаги). Так .NET Core запутало нас ещё сильнее с тем, что между «разрешёнными» наборами есть ещё и какие-то зависимости.
Читать полностью »
Что нужно знать, если вы хотите вызывать Go функции из ассемблера
2020-02-22 в 12:04, admin, рубрики: amd64, asm, Go, golang, x86_64, Компиляторы, ненормальное программирование, системное программированиеYou've run into a really hairy area of asm code.
My first suggestion is not try to call from assembler into Go. — Ian Lance Taylor
До тех пор, пока ваш ассемблерный код делает что-то простое, всё выглядит неплохо.
Как только у вас возникает задача вызвать из ассемблерного кода Go функцию, один из первых советов, который вам дадут: не делайте так.
Но что если вам это очень-очень нужно? В таком случае, прошу под кат.
[CppCon 2017] Matt Godbolt: Что мой компилятор сделал для меня?
2017-10-12 в 12:46, admin, рубрики: c++, clang, cppcon, gcc, godbolt, x86_64, ассемблер, Компиляторы, отладка, ПрограммированиеПродолжение цикла обзорных статей с конференции CppCon 2017.
Содержание цикла
- Бьёрн Страуструп: Изучение и преподавание современного C++
- Ларс Кнолл: C++ фреймворк Qt: История, Настоящее и Будущее
- Herb Sutter: Метапрограммирование и кодогенерация в C++
- Matt Godbolt: Что мой компилятор сделал для меня?
На этот раз очень интересное выступление от автора Compiler Explorer (godbolt.org). Обязательно читать всем, кто для быстроты умножает на 2 с помощью сдвига (по крайней мере, на x86-64). Если вы знакомы с ассемблером x86-64, то можете перемотать до разделов с примерами ("Умножение", "Деление" и т.д). Далее слова автора. Мои комментарии в квадратных скобках курсивом.
Моя цель сделать так, чтобы вы не боялись ассемблер, это полезная вещь. И использовали его. Не обязательно все время. И я не говорю, что вы должны все бросить и учить ассемблер. Но вы должны уметь просмотреть результат работы компилятора. И когда вы это сделаете, то оцените, как много работы проделал компилятор, и какой он умный.