Выравнивание машинного кода - PullRequest
4 голосов
/ 07 марта 2011

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

Я надеялся реализовать процедуру автоматического выравнивания, которая может обрабатывать код в целом ивставить выравнивание в соответствии со спецификацией ЦП (ширина строки кэша, 32/64 бита и т. д.) ...

Может кто-нибудь дать некоторые советы об этой процедуре?Например, целевым процессором может быть 64-разрядная платформа Intel Core i7.

Спасибо.

Ответы [ 4 ]

3 голосов
/ 07 марта 2011

Я не квалифицирован, чтобы ответить на ваш вопрос, потому что это такая обширная и сложная тема. Здесь, вероятно, гораздо больше механизмов, кроме размера строки кэша.

Однако я хотел бы указать на сайт Агнера Фога и руководства по оптимизации для производителей компиляторов , которые вы можете найти там. Они содержат множество информации по этим видам предметов - строки кэша, прогноз ветвления и выравнивание данных / кода.

2 голосов
/ 07 марта 2011

Выравнивание абзаца (16 байт) обычно является наилучшим.Однако это может привести к тому, что некоторые «локальные» инструкции JMP больше не будут локальными (из-за увеличения размера кода).Может также привести к не так много кеширования кода.Я бы выровнял только основные сегменты кода, я бы не выровнял каждую крошечную подпрограмму / раздел JMP.

1 голос
/ 08 марта 2011

Как упоминалось ранее, это очень сложная область.Агнер Фог кажется хорошим местом для посещения.Что касается сложностей, я наткнулся на статью здесь Torbjörn Granlund на тему «Улучшенное деление на инвариантные целые числа» и в коде, который он использует для иллюстрации своего нового алгоритма, первая инструкция в - я думаю - основной меткой является nop- нет операции.Согласно комментарию это значительно повышает производительность.Пойди разберись.

1 голос
/ 07 марта 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...