Со временем вендоры добавляли новые и новые инструкции в процессоры, управляющие нашими ноутбуками, серверами, телефонами и многими другими устройствами. Добавление машинных инструкций, решающих конкретные вычислительные подзадачи, является хорошим способом улучшить производительность системы в целом, не усложняя конвейер и не пытаясь нарастить частоту до запредельных величин. Одна новая инструкция, выполняющая ту же операцию, что и несколько старых, позволяет неоднократно увеличить производительность решения заданной задачи.
Новые инструкций, такие как Intel Software Guard Extensions (Intel SGX) и Intel Control-flow Enforcement Technology (Intel CET), также способны предоставить абсолютно новую функциональность.



Хороший вопрос заключается в том, как скоро новые инструкции, добавленные в архитектуру, достигают конечного пользователя. Могут ли операционные системы и другие приложения воспользоваться новыми инструкциями, принимая во внимание, что они, как правило, обеспечивают обратную совместимость и способность исполняться независимо от модели установленного процессора? Много лет назад использование новых инструкций достигалось с помощью пересборки программы под новую архитектуру и добавления проверок, предотвращающих запуск на старой аппаратуре и печатающих что-то вроде “sorry, this program is not supported on this hardware”.

Я воспользовался полноплатформенным симулятором Wind River Simics, чтобы узнать, в какой степени современное программное обеспечение способно использовать новые инструкции, оставаясь при этом совместимым со старым оборудованием.

Вряд ли сейчас кого-то удивишь тем, что развитием архитектуры IA-32 занимается не только Intel, но и такие компании, как AMD и VIA. Больше информации можно найти, например, в статье A. Fog'a. Сегодня я планирую рассказать об одном, на мой взгляд, не до конца продуманном изменении ISA, внесенном компанией AMD.



При мыслях о влиянии AMD на архитектуру IA-32 в первую очередь вспоминается REX префикс и поддержка 64-битного режима процессора. И это безусловно «положительный» эффект, который сделал IA-32 лучше. Однако были и другие интересные изменения, которые лично я положительными назвать не могу.

Привет, %username%!
Декодирование IA-32 кода — задача архисложная. Чтобы в этом убедиться, можете обратиться к Intel Software Development Manual или к статьям, ранее написанным на хабре: Префиксы в системе команд IA-32, Правильно ли работает ваш дизассемблер?. Давайте посмотрим, как с этой задачей борется функционально точный полноплатформенный симулятор Wind River Simics, позволяющий создать высокопроизводительное виртуальное окружение, в котором любая электронная система, начиная с одной платы и заканчивая целыми многопроцессорными, многоядерными и даже многомашинными системами, может быть определена, разработана и запущена.
Большинство библиотек для декодирования IA-32 инструкций генерируют или используют таблицы соответствия между кодами операций и инструкциями. Пример использования данного подхода описан в статье Дизассемблер своими руками. Однако декодирование префиксов и аргументов обычно написано руками: libopcodes, metasm, beaengine, distorm. Данный подход обладает существенным недостатком — добавление поддержки новых наборов команд потребует большого количества ручной работы.
Существуют и другие способы создания декодеров, например с помощью языка GDSL. Данный подход является универсальным и позволяет создавать декодеры для любых архитектур.
Simics же использует совершенно другой не менее универсальный подход для работы с IA-32 инструкциями, названный раздельным декодированием. Также Simics имеет возможность использования внешних декодеров, но об этом немного позже.

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

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

Сегодня я хочу рассказать вам о префиксах в системе команд Intel IA-32 в 32- и 64-битных вариантах (также именуемых как x86 и x86_64). Но для начала напомню вкратце общую структуру IA-32 инструкции:

• Префиксы. Могут отсутствовать. Может присутствовать сразу несколько.
• Опкод. Может состоять из одного, двух или трех байтов.
• Mod_R/M байт. Используется для адресации операндов. Может отсутствовать в кодировке, если инструкция не имеет явных операндов.
• SIB (Scale Index Base) байт. Второй байт, использующийся для адресации операндов в памяти. Может отсутствовать.
• Байт смещения адреса (англ. displacement). 1, 2, 4 или ни одного байта.
• Константа (англ. immediate). 1, 2, 4 или ни одного байта.

Привет, хабр!

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

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



Для начала расскажу, что я нагуглил и почему мне это не понравилось:

Привет, Хабр!

В свое время это тема показалась мне очень интересной, поэтому я решил поделиться своими скромными знаниями с вами. Данная статья не претендует на полное детальное описание, скорее это краткий обзор.

Введение

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

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

При изменении состояния текущей ячейки необходимо каким-то образом сообщить об этом остальным кэшам. Например, генерируя широковещательных сообщения, доставляемые по внутренней сети многопроцессорной системы.

Было придумано множество протоколов когерентности, отличающиеся алгоритмами, количеством состояний и, как следствие скоростью работы и масштабируемостью. Большинство современных протоколов когерентности представляют вариации протокола MESI [1]. По этой причине мы его и рассмотрим.