Рубрика «x86_64»

Вступление

Центральный процессор (CPU, Central Processing Unit) — это основной компонент устройств, который выполняет все вычисления и логические операции, необходимые для работы программ.

Здесь я постараюсь рассказать про строение и работу процессора на примере x86–64 архитектуры.

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

Я решил поделиться своими заметками, так как возможно кому-то это может показаться полезным. На детальность информации не претендую, но не против конструктивной критики.

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

Как устроена страничная организация памяти x86_64 - 1

В этом посте я буду говорить о страничной организации только в контексте PML4 (Page Map Level 4), потому что на данный момент это доминирующая схема страничной организации x86_64 и, вероятно, останется таковой какое-то время.

Окружение

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

В этом году Apple потрясла рынок десктопных процессоров чипом Apple M1 и устройствами на нём. Похожее событие произошло в мире облачных вычислений в прошлом году. AWS выпустили новый тип сервера на собственных ARM процессорах Graviton2. По заявлениям Amazon, соотношение производительности к цене у новых процессоров на 40% выше, чем у аналогов на x86. Ещё одно недавнее обновление - сервера Amazon RDS (облачный сервис, предоставляющий сервера баз данных) на Graviton2. Я запустил несколько бенчмарков и нагрузочный тест реального бэкенд приложения, чтобы проверить настолько ли хороши сервера на ARM процессорах и узнать какие проблемы совместимости могут возникнуть.

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

Месяц назад я попытался сосчитать, сколько разных инструкций поддерживается современными процессорами, и насчитал 945 в Ice Lake. Комментаторы затронули интересный вопрос: какая часть всего этого разнообразия реально используется компиляторами? Например, некто Pepijn de Vos в 2016 подсчитал, сколько разных инструкций задействовано в бинарниках у него в /usr/bin, и насчитал 411 — т.е. примерно треть всех инструкций x86_64, существовавших на тот момент, не использовались ни в одной из стандартных программ в его ОС. Другая любопытная его находка — что код для x86_64 на треть состоит из инструкций mov. (В общем-то известно, что одних инструкций mov достаточно, чтобы написать любую программу.)

Я решил развить исследование de Vos, взяв в качестве «эталонного кода» компилятор LLVM/Clang. У него сразу несколько преимуществ перед содержимым /usr/bin неназванной версии неназванной ОС:

  1. С ним удобно работать: это один огромный бинарник, по размеру сопоставимый со всем содержимым /usr/bin среднестатистического линукса;
  2. Он позволяет сравнить разные ISA: на releases.llvm.org/download.html доступны официальные бинарники для x86, ARM, SPARC, MIPS и PowerPC;
  3. Он позволяет отследить исторические тренды: официальные бинарники доступны для всех релизов начиная с 2003;
  4. Наконец, в исследовании компиляторов логично использовать компилятор и в качестве подопытного объекта :-)

Начну со статистики по мартовскому релизу 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 оказывается на треть меньше что по размеру, что по общему числу инструкций.

А вот распределение по числу инструкций:
Сколько инструкций процессора использует компилятор? - 1 Сколько инструкций процессора использует компилятор? - 2 Сколько инструкций процессора использует компилятор? - 3 Сколько инструкций процессора использует компилятор? - 4 Сколько инструкций процессора использует компилятор? - 5 Сколько инструкций процессора использует компилятор? - 6Читать полностью »

Мы живём в эпоху доминирования архитектуры 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 запутало нас ещё сильнее с тем, что между «разрешёнными» наборами есть ещё и какие-то зависимости.
Читать полностью »

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 функцию, один из первых советов, который вам дадут: не делайте так.

Но что если вам это очень-очень нужно? В таком случае, прошу под кат.

Что нужно знать, если вы хотите вызывать Go функции из ассемблера - 1

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

Продолжение цикла обзорных статей с конференции CppCon 2017.

На этот раз очень интересное выступление от автора Compiler Explorer (godbolt.org). Обязательно читать всем, кто для быстроты умножает на 2 с помощью сдвига (по крайней мере, на x86-64). Если вы знакомы с ассемблером x86-64, то можете перемотать до разделов с примерами ("Умножение", "Деление" и т.д). Далее слова автора. Мои комментарии в квадратных скобках курсивом.

Моя цель сделать так, чтобы вы не боялись ассемблер, это полезная вещь. И использовали его. Не обязательно все время. И я не говорю, что вы должны все бросить и учить ассемблер. Но вы должны уметь просмотреть результат работы компилятора. И когда вы это сделаете, то оцените, как много работы проделал компилятор, и какой он умный.

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

Введение
В этой статье мы попробуем разобраться как работает Return Oriented эксплоит. Тема, в принципе, так себе заезженная, и в инете валяется немало публикаций, но я постараюсь писать так, чтобы эта статья не была их простой компиляцией. По ходу нам придется разбираться с некоторыми системными особенностями Linux и архитектуры x86-64 (все нижеописанные эксперименты были проведены на Ubuntu 14.04). Основной целью будет эксплуатирование тривиальной уязвимости gets с помощью ROP (Return oriented programming).
Читать полностью »

Android NDK, Revision 10 поддерживает архитектуру Intel 64 bitХорошая новость для разработчиков приложений под Android: новая, десятая версия Android NDK, вышедшая в июле, содержит целых три новых 64-битных ABI: arm64-v8a, x86_64 и mips64, что благоприятным образом скажется на производительности программ. Нам особенно приятно отметить появившуюся поддержку x86_64Читать полностью »

Сегодня я хочу рассказать об одной интересной сложности декодирования/дизассемблирования IA-32 инструкций.

Перед прочтением этой статьи рекомендую обратиться в статье «Префиксы в системе команд IA-32», описывающей общую структуру IA-32 команды и существующие префиксы. В этой статье я подробнее расскажу про обязательные префиксы (англ. mandatory prefixes) и некоторые нюансы, связанные с ними.
Читать полностью »


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