Методы вызова функций и манглинг имен могут быть достаточно сложными. Существует много различных соглашений о вызовах функций, и разные марки компиляторов не совместимы друг с другом в этом отношении. Если вы вызываете ассемблерную процедуру из C++, самым логичным и совместимым будет объявляление вашей функции как extern "C" и _cdecl. К имени ассемблерной функции надо прибавить символ подчеркивания и компилировать ее нужно указав чувствительность к регистрам в именах внешних функций и переменных (опция -mx).

Если вам нужно использовать перегружаемые функции, перегружаемые операторы, функции-члены классов и другие расширения C++, тогда вам нужно сначала написать это на C++ и заставить ваш компилятор перевести это в ассемблер, чтобы получить верную информацию о линковке и методе вызова, так как они могут отличаться у разных компиляторов. Если вам нужна ассемблерная функция, соглашение о вызове которой отличается от extern "C" и _cdecl, вам нужно получить ее имя, создаваемое компилятором. Вот пример перегруженной функции вычисления квадратного корня:

Способ передачи параметров зависит от соглашения о вызове функции:

Использование регистров в 16-ти битном режиме или Windows, C или C++: 16-ти битное значение возвращается в AX, 32-х битное значение в DX:AX, значение с плавающей запятой в ST(0). Регистры AX, BX, CX, DX, ES и арифметические флаги могут быть изменены процедурой; другие регистры должны быть сохранены и восстановлены. Процедура может полагаться на то, что при вызове другой процедуры значение SI, DI, BP, DS и SS не изменится.

Использование регистров в 32-х битных Windows, C++ и других языках программирования: целочисленное значение возвращается в EAX, значение с плавающей точкой возвращается в ST(0). Регистры EAX, ECX, EDX (но не EBX) могут быть изменены процедурой; все другие регистры должны быть сохранены и восстановлены. Сегментные регистры нельзя изменять даже временно. CS, DS, ES и SS указываеют на плоский сегмент. FS используется операционной системой. GS не используется, но зарезервирован. Флаги могут меняться процедурой, но со следующими ограничениями: флаг направления равен 0 по умолчанию. Его можно изменить временно, но при выходе из процедуры необходимо очистить. Флаг прерывания не может быть очищен. Стековый регистр плавающей запятой пуст при входе в процедуру и должен быть пустым при выходе, если только ST(0) не используется для возвращения значения. Регистры MMX можно изменять, и если это было сделано, их нужно очистить с помощью инструкции EMMS перед возвращением или вызовом любой другой процедуры, которая может использовать регистры плавающей запятой. Все XMM регистры можно свободно изменять. Правила для передачи параметров и возвращения значений через регистры XMM объяснены в интеловском документе AP 589. Процедура может полагаться на неизменность EBX, ESI, EDI, EBP и всех сегментных регистров при вызове другой процедуры.

Большая часть приведенной здесь информации основывается на моих собственных исследованиях. Много людей прислали мне полезную информацию и исправления для этого руководства, и я обновляю его каждый раз, когда у меня появляется важная информация. Поэтому данное руководство наиболее точно, подробно и исчерпывающе, нежели любой другой источник информации, и оно содержит множество подробностей, которые трудно найти гед-бы то ни было еще. Эта информация во многих случаях позволит вам, сколько тактов займет выполнение определенного кода. Тем не менее, я не утверждаю, что вся информация в данном руководстве верна: некоторые измерения очень трудно или невозможно сделать точно, и у мнея нет доступа к информации о внутренней реализации, которая есть у тех, кто пишет интеловские руководства.

В данном руководстве обсуждаются следующие версии процессоров Pentium:

В данном руководстве используется синтаксис MASM 5.10. Для языка ассемблера x86 не существует официального стандарта, но это фактически является стандандартом, так как многие ассемблеры имеют режим совместимости с MASM 5.10. (Я не рекомендую использовать сам MASM версии 5.10, так как в нем есть серьезный баг, проявляющийся в 32-х битном режиме. Используйте TASM или более позднюю версию MASM).

Некоторые замечания в данном руководстве могут показаться критикой Intel. Это не нужно понимать, что другие марки лучше. Семейство микропроцессоров Pentium вполне сравнимы со своими конкурентами, они лучше документированы и у них есть другие отличительные особенности.

Программированить на ассемблере гораздо сложнее, чем на языке высокого уровня. Сделать ошибку очень легко, а найти ее очень трудно. Вы были предупреждены! Предполагается, что у читателя уже есть опыт в программировании на ассемблере. Если нет, пожалуйста, прочитайте соответствующие книги по этому теме и наберитесь определенного опыта в программировании, прежде чем вы начнете выполнять сложную оптимизацию.

Арихтектура чипов PPlain и PMMX имеет много особенностей, которые оптимизированны специально под некоторые наиболее часто используемые инструкции или комбинации инструкций. В этих случаях нельзя использовать общие методики оптимизации. Следовательно, правила для оптимизирования программного обеспечения весьма сложны и имеют много исключений, но возможный выигрыш в производительности значителен. У процесоров PPro, PII и PIII совершенно разный дизайн в том, как процессор берет на себя часть оптимизации, запуская инструкции в совершенно разном порядке, но усложненный дизайн этих процессоров становится причининой множества потенциальных узких мест, поэтому можно много выиграть, оптимизируя код вручную для этих процессоров. У Pentium 4 также другой дизайн, и пути оптимизации для Pentium 4 отличаются от тех, которые используются для других версий. Это руководство не рассказывает о Pentium 4 - читатель может обратиться к руководствам от Intel.

Прежде, чем вы начнете конвертировать ваш код в ассемблер, убедитесь, что используемый вами алгоритм оптмален. Зачастую вы можете гораздо сильнее улучшить ваш код путем оптимизации алгоритма, чем переписыванием кода на ассемблере.

Затем вам нужно выделить критические части вашей программы. Зачастую более, чем 99% времени процессора тратится на внутренний цикл программы. В этом случае вам нужно только оптимизировать этот цикл и оставить все остальное на языке высокого уровня. Некоторые асм-программисты тратят огромное количество энергии на оптимизирование не тех частей своей программы, единственным значительным результатом чего становится то, что программу становится труднее отлаживать и распространять!

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

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

Пожалуйста, не посылайте мне ваши вопросы о программировании. Я не собираюсь делать за вас вашу домашнюю работу.

Удачи в охоте за наносекундами!

Я не будут давать здесь прямые ссылки, потому что местоположение файлов часто меняется. Вы можете найти нужные вам документы используя функцию поиска на developer.intel.com или перейдя по ссылке, которые находятся на www.agner.org/assem.

Затем переведите код на язык ассемблера.

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

Если размер массива кратен 32 байтам, вам следует и выравнивать его по границе 32 байта.

Кэш set-ассоциативен. Это означает, что кэш-ряд нельзя ассоциировать с произвольным адресом памяти. У каждого кэш-ряда есть 7-ми битное значение, которое задает биты 5-11 адреса в физической памяти (биты 0-4 определяются положением элемента данных в кэш-ряде). У PPlain и PPro два кэш-ряда для каждого из возможных 128 set-значений, поэтому с определенным адресом в памяти можно ассоциировать только два жестко заданных кэш-ряда. В PMMX, PII и PIII - четыре.

Следствием этого является то, что кэш может содержать не более двух или четырех различных блока данных, у которых совпадают биты 5-11 их адресов. Вы можете определить, совпадают ли эти биты у двух адресов следующим образом: удалите нижние пять битов каждого адреса, чтобы получить значение, кратное 32. Если разница между этими обрезанными значениями кратна 4096 (=1000h), значит у этих адресов одно и то же set-значение.

Давайте я проиллюстрирую вышеизложенное с помощью следующего кода, где ESI содержит адрес, кратный 32:

У всех трех адресов, использованных здесь, совпадают set-значения, потому что разница между обрезанными адресами будет кратна 4096. Этот цикл будет очень плохо выполняться на PPlain и PPro. Во время записи в ECX нет ни одного свободного кэш-ряда, поэтому тот, который был использован для значения, помещенного в EAX, заполняется данными с [ESI+204096] до [ESI+204096+31] и записывает значение в ECX. Затем во время чтения EAX оказывается, что кэш-ряд, содержавший значение для EAX, уже изменен, поэтому то же самое происходит с кэш-рядом, содержащим значение для EBX, и так далее. Это пример нерационального использования кэша: цикл занимает около 60 тактов. Если третью линию изменить на:

мы пересечем границу в 32 байта, поэтому у нас будет другое set-значение, и не возникнет никаких проблем с ассоциирование кэш-рядов к этим трем адресам. Цикл теперь занимает 3 такта (не считая первого раза) - весьма значительное улучшение! Стоит упомянуть, что у PMMX, PII и PIII для каждого set-значения есть четыре кэш-ряда. (Некоторые интеловские документы ошибочно утверждают, что у PII по два кэш-ряда на каждое set-значение).

Определить, одинаковые или у переменных set-значения, может оказаться достаточно сложным, особенно, если они разбросаны по разным сегментам. Лучшим, что вы можете придумать для избежания проблем подобного рода - это держать все данные, используемые в критической части вашей программы внутри одного блока, который будет не больше, чем кэш, либо в двух блоках, не больших, чем половина от его размера (например, один блок для статических данных, а другой для данных в стеке). Это будет гарантией того, что ваши кэш-ряды используются оптимальным образом.

Если критическая часть вашего кода имеет дело с большими структурами данных или данными, располагающимися в памяти случайным образом, тогда вам стоит подумать о том, чтобы держать наиболее часто используемые переменные (счетчики, указатели, флаговые переменные и т.д.) в одном блоке с максимальным размеров в 4 килобайта, чтобы использовались все кэш-ряды. Так как вам еще требуется стек для параметров подрограммы и возвращаемых адресов, лучшее, что вы можете сделать - это скопировать наиболее часто используемые статические данные в динамические переменные в стеке, а после выхода из критической части кода скопировать обратно те из них, которые подверглись изменению.

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

При считывании больших блоков данных из памяти, скорость ограничена временем, уходящим на заполнение кэш-рядов. Иногда вы можете увеличить скорость, считывая данные в непоследовательном порядке: еще не считав данные из одного кэш-ряда, начать читать первый элемент из следующего кэш-ряда. Этот метода можете повысить скорость на 20-40% при считывании данных из основной памяти или кэша второго уровня на PPlain и PMMX, или из кэша второго уровня на PPro, PII и PIII. Недостаток этого метода заключается в том, что код программы становится очень запутанным и сложным. Другую информацию об этом методе вы можете получить на www.intelligentfirm.com.

Когда вы пишите в адрес, которого нет в кэше первого уровня, тогда значение пойдет прямо в кэш второго уровня или в память (в зависимости от того, как настроен кэш второго уровня) на PPlain и PMMX. Это займет примерно 100 ns. Если вы пишите восемь или более раз в тот же 32-байтный блок памяти, ничего не читая из него, и блок не находится в кэше первого уровня, возможно стоит сделать фальшивое чтение из него, чтобы он был загружен в кэш-ряд. Все последующие чтения будут производиться в кэш, что занимает всего лишь один такт. На PPlain и PMMX иногда происходит небольшая потеря в производительности при повторяющемся чтении по одному и тому же адресу без чтения из него между этим.

На PPro, PII и PIII запись обычно ведет к загрузке памяти в кэш-ряд, но возможно указать область памяти, с которой следуюет поступать иначе (смотри Pentium Pro Family Developer's Manual, vol. 3: Operating System Writer's Guide").

Другие пути увеличения скорости чтения и записи в память обсуждаются в главе 27.8.

У PPlain и PPro есть два буфера записи, у PMMX, PII и PIII - четыре. На PMMX, PII и PIII у вас может быть до четырех незаконченных записей в некэшированную память без задержки последующих инструкций. Каждый буфер записи может обрабатывать операнды до 64 бит длиной.

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

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

Хранение временных данных в регистрах, разумеется, более эффективно. Так как регистров мало, вы, возможно, захотите использовать [ESP] вместо [EBP] для адресации данных к стеку, чтобы освободить EBP для других целей. Только не забудьте, что значение ESP меняется каждый раз, когда вы делаете PUSH или POP. (Вы не можете использовать ESP под 16-ти битным Windows, потому что прерывание таймера будет менять верхнее слово ESP тогда, когда это невозможно предугадать.)

Есть отдельных кэш для кода, которых схож с кэшем данных. Размер кэша кода равен 8 килобайтам на PPlain и PPro и 16 килобайтам на PMMX, PII и PIII. Важно, чтобы критические части вашего кода (внутренние циклы) умещались в кэш кода. Часто используемые процедуры следует помещать рядом друг с другом. Редко используемые ветви или процедуры нужно деражть в самом низу вашего кода или где-нибудь еще.

• Загрузка кода из RAM в кэш занимает намного больше времени, чем его выполнение.

• Любые данные, к которым обращается код должны быть загружены в кэш, что также занимает много времени. Когда код повторяется, данные, как правило, уже находятся в кэше.

• Инструкция перехода не будет находится в буфере предсказывания переходов в первый раз, поэтому маловероятно, что она будет предсказана правильно. Смотри главу 22.

• На PPlain декодирование инструкций является узким месом. Если определение длины инструкции занимает один такт, то процессор не может раскодировать за такт две инструкции, так как он не знает, где начинает вторая инструкция. PPlain решает эту проблему, запомина длину любой инструкции, которая осталась в кэше. Как следствие, ряд инструкции не спариваются на PPlain во время первого исполнения, если только первые две инструкции не занимают по одному байту. У PMMX, PPro, PII и PIII таких потерь нет.

Пример:

У PPro, PII и PIII нет задержки AGI для чтения из памяти и LEA, но есть задержка при записи в память. Это не очень важно, если только последующий код не должен ждать, пока операция записи не будет выполнена.

Пример:

Этот код можно разбить на следующую последовательность, которая будет занимать только 3 такта:

Таким же образом вы можете разбивать не спариваемые инструкции на спариваемые:

Разбивается на:

Другие примеры неспариваемых инструкций, которые можно разбить на простые спариваемые:

Если разбиваение иснтрукций не повышает скорось, вы можете оставить сложные или неспариваемые конструкции, чтобы уменьшить размер кода.

Разбивание инструкций не требуется, кроме тех случаев, когда это будет генерировать меньше уопов (uops).

Следующие инструкции могут находится в любом конвеере.

• MOV регистр, память или уже заданного числа в регистр или память

• PUSH регистр или число, POP регистр

• LEA, NOP

• INC, DEC, ADD, SUB, CMP, AND, OR, XOR,

• и некоторые разновидности TEST (смотри главу 26.14)

Следующие инструкции спариваемы только в U-конвеере:

• ADC, SBB

• SHR, SAR, SHL, SAL с число в качестве аргумента

• ROR, ROL, RCR, RCL с единицей в качестве аргумента

Следующие инструкции спариваемы только в V-конвеере:

• ближний вызовой

• короткий и ближний переход

• короткий и ближний условный переход

Все другие целочисленные инструкции могут выполняться только в U-конвеере и не могут спариваться.

Две следующие друг за другом инструкции будут спариваться, если соблюденые следующие условия:

• Первая инструкция спариваема в U-конвеере, а вторая - в V-конвеере.

• Вторая инструкция не читает и не пишет из регистра, если пишет первая инструкция.

Примеры:

3. Неполные регистры считаются полными регистрами. Пример:

пишут в разные части одного и того же регистра, не спаривается.

4. Две инструкции, пишущие в разные части регистра флагов могут спариваться не смотря на правила 2 и 3. Пример:

5. Инструкция, которая пишет в регистр флагов может спариваться с условным переходом несмотря на правило 2. Пример:

6. Следующая комбинация инструкций может спариваться несмотря на тот факт, что обе изменяют указатель на стек:

7. Есть ограничения на спаривание инструкций с префиксами. Есть несколько типов префиксов:

• у инструкций, обращающихся к сегменту, не являющемся сегментом по умолчанию, есть сегментный префикс.

• у инструкций, использующих 16-ти битные данные в 32-ом режиме или 32-х битные данные в 16-битном режиме, есть префикс размера операнда.

• у инструкций, использующих 32-х битную адресацию через регистры в 16-ти битном режиме, есть префикс размера адреса.

• у повторяющихся есть префикс повторения.

• у закрытых инструкций есть префикс LOCK.

• у многих инструкций, которых не было на процессоре 8086 есть двухбайтный опкод, чей первый байт равен 0FH. Байт 0FH считается префиксом только на PPlain. Наиболее часто используемые инструкции с этим префиксом следующие: MOVZX, MOVSX, PUSH FS, POP FS, PUSH GS, POP GS, LFS, LGS, LSS, SETcc, BT, BTC, BTR, BTS, BSF, BSR, SHLD, SHRD, и IMUL с двумя операндами и без числового операнда.

На PPlain инструкция с префиксом может выполняться только в U-конвеере, кроме ближних условных переходов.

На PMMX инструкции с префиксами размера операнда, размера адреса или 0FH могут выполняться в любом конвеере, в то время как инструкции с префиксами сегмента, повторения или LOCK могут выполняться только в U-конвеере.

8. Инструкция, в которой используется одновременно адресация со смещение и числовые данные на PPlain не спариваются, на PMMX могут спариваться только в U-конвеере:

(Другая проблема, связанная с подобными инструкциями, выполняющимися на PMMX, заключается в том, что такие инструкции могут быть длинее семи байтов, а это приводит к невозможности раскодировки больше одной инструкции за такт, подробнее это объясняется в главе 12.)

9. Обе инструкции должны быть заранее загружены и раскодированы. Это объяснение в главе 8. 10. Есть специальные правила спаривания для инструкций MMX на PMMX:

• MMX-сдвиг, инструкции упаковки или распаковки могут выполнять в любом конвеере, но не могут спариваться с другим MMX-сдвигом, инструкциями упаковки или распаковки.

• MMX-инструкции умножения могут выполняться в любом конвеер, но не могут спариваться с другими MMX-инструкциями умножения. Они занимают 3 такта, и последние 2 такта могут перекрыть последующие инструкции, также как это делают инструкции плавающей запятой (смотри главу 24).

• MMX-инструкция, обращающаяся к памяти или целочисленным регистрам может выполняться только в U-конвеер и не могут спариваться с не-MMX инструкцией.

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

Несовершенное спаривание возникает в следующих случаях:

• Если вторая инструкция приводит к задержке AGU (глава 9).

• Две инструкции не могут обращаться к одному и тому двойному слову в памяти одновременно:

Два операнда внутри одного и того же двойного слова, поэтому они не могут выполняться одновременно. Пара займет два такта для выполнения.

Эти два операнда находятся в разных двойных словах, поэтому они прекрасно спариваются и занимают всего один такт.

3. Правило 2 расширяет зону своего действия, если биты 2-4 обоих адресов одинаковы (конфликт банков кэша). Для адресов размеров в двойное слово это означает, что они не разность между обоими адресами не должна делиться на 32. Примеры:

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

Спариваемая целочисленная инструкция, которая читает из памяти, делает какие-то вычисления, а затем сохраняет результат в регистрах или флагах, занимает 2 такта (инструкции чтения/модифицирования).

Спариваемая целочисленная инструкция, которая читает из памяти, делает какие-то вычисления, а затем записывает результат обратно в память, занимает 3 такта (инструкции чтения/модифицирования/записи).

4. Если инструкция чтения/модифицирования/записи спаривается с инструкцией чтения/модифицирования или чтения/модифицирования/записи, тогда они спарятся несовершенно.

Количество тактов, которые потребуются для выполнения такой пары, даны в следующей таблице:

Пример:

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

6. Спариваемая инструкция плавающей запятой и следующая за ней FXCH повлекут несовершенное спаривание, если следующая инструкция не является инструкцией плавающей запятой.

Чтобы избежать несовершенного спаривания, вы должны знать, какие инструкции пойдут в U-конвеер, а какие - в V-конвеер. Вы можете выяснить это, просмотрев свой код и поискав инструкции, которые неспрариваются, или спариваются только в определенном конвеере, или не могут спариваться в силу одного из вышеизложенных правил.

Несовершенное спаривание можно зачастую избежать, реорганизовав свои инструкции.

Пример:

Здесь две инструкции MOV формируют несовершенную пару, потому что обе обращаются к одной и той же области в памяти, поэтому последовательность займет 3 такта. Вы можете улучшить этот код, реорганизовав инструкции так, чтобы 'INC ECX' спаривалась с одной из инструкции MOV.

Пара 'INC EBX / MOV ECX,[EAX]' несовершенная, потому что следующая инструкция приводит к задержке AGI. Последовательность занимает 4 такта. Если вы вставите NOP или какую-нибудь другую инструкцию, чтобы 'MOV ECX,[EAX]' спаривался с 'JMP L1', последовательность займет только три такта.

Следующий пример выполняется в 16-ти битном режима, предполагается,что SP делится на 4:

Инструкции PUSH формируют две несовершенные пары, потому что оба операнда в каждой паре обращаются к одному и тому же слову в памяти. 'PUSH BX' могла бы совершенно спариться с PUSH CX (потому что они находятся по разные стороны от границы, отделяющей двойные слова друг от друга), но этого не происходит, потому что она уже спарена с PUSH AX. Поэтому последовательность занимает 5 тактов. Если вы вставите NOP или другую инструкцию, чтобы 'PUSH BX' спаривалась с 'PUSH CX', а 'PUSH DX' с 'CALL FUNC', последовательность займет только 3 такта. Другой путь разрешения данной проблемы - это убедиться, что SP не кратен четырем. Правда, узнать это в 16-ти битному режиме довольно сложно, поэтому лучший выход - использовать 32-х битный режим.

На PPlain возникает задержка в один такт для каждого префикса, кроме 0FH в

инструкциях условного ближнего перехода.

У PMMX не задержки раскодирования из-за префикса 0FH. Префиксы сегментов и

повторения занимают один такт для раскодирования. PMMX может раскодировать

две иснтрукции, если у первой инструкции нет префиксов или есть префикс

сегмента или повторения, у второй инструкции нет префиксов. Инструкции с

префиксами размера адреса или операнда на PMMX раскодировываются только

отдельно. Инструкции с несколькими префиксами занимают по одному такту на

каждый префикс.

Префиксы размера адреса нужно избегать, используя 32-х битный режим. Префиксы

сегментов можно избежать в 32-х битном режиме, используя плоскую модель

памяти. Префикс размера операнда можно избежать в 32-х битном режиме,

используя только 8-ми битные и 32-х битные числа.

Когда префисы нельзя избежать, задержку раскодирования можно скрыть, если

предыдущая инструкция занимает больше одного такта для исполнения. Правило

для PPlain такого: каждая инструкция, которая занимает N тактов для

выполнения (не для раскодирования) может 'затенять' задержку раскодирования

N-1 префиксов в следующих двух (иногда трех) инструкциях или пар инструкций.

Другими словами, кажды дополнительных так, который требует инструкция для

выполнения, может быть использован для раскодирования одного префикса в

следующей иснтрукции. Этот эффект иногда распространяется даже на правильно

предсказанный переход. Любая инструкция, которая занимает больше одного такта

для выполнения, и любая инструкция, чье выполнение задерживается из-за AGI,

неправильного использования кэша, неправильного выравнивания или неправильного

предсказания перехода, создает эффект 'затемнения'.

У PMMX есть похожий эффект 'затемнения', но он имеет другой механизм.

Раскодировываемые инструкции хранятся в прозрачном "первым-вошел-первым-вышел"

(FIFO) буфере, в котором может храниться до четрырех инструкций. Когда буфер

пуст, инструкции выполняются сразу после раскодировки. Бфер заполняется, когда

инструкции раскодировываются быстрее, чем выполняются, то есть они неспарены

или являются мультитактовыми. Буфер FIFO опустошается, когда иснтрукции

выполняются быстрее, чем раскодировываются, то есть когда возникают задержки

из-за префиксов. Буфер FIFO становится пустым после неправильно предсказанного

перехода. Буфер FIFO может получить две инструкции за такт, если у второй

инструкции нет префиксов и ни одна из инструкций не длинее 7 байт. Два

конвеера (U и V) могуть получать по одной инструкции за такт из буфера FIFO.

Примеры:

Инструкция CLD занимает два такта, и поэтому затемняет задержку раскодировки

префикса REP. Код занял бы на один такт больше, если бы инструкция CLD

находилась достаточно далеко от REP MOVSD.

Инструкция CMP занимает два такта, потому что это инструкция

чтения/модифицирования. Префикс 0FH инструкции SETNZ раскодировывается во

время второго такта выполнения CMP, поэтому задержка раскодирования скрыта на

PPlain (у PMMX нет задержки для 0FH).

Потери производительности, связанные с префиксами, на PPro, PII и PIII

объясняются в главе 14.

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

Декодеры могут обрабатывать три инструкции за такт, но только, если соблюдены

определенные условия. Декодер D0 может обработать за один такт любую

инструкцию, которая генерирует до 4 мопов. Декодеры D1 и D2 могут обрабатывать

только те инструкции, которые генерируют 1 моп и эти инструкции не могут

занимать больше 8 байт.

Резюмируем правила для декодирования двух или трех инструкций за один такт:

• Первая инструкци (D0) не должна генерировать больше 4-х мопов.

• Вторая и третья инструкции не должны генерировать больше, чем по одному мопу.

• Вторая и третья инструкции не могут быть занимать больше 8-ми байтов каждая.

• Инструкции должны содержаться внутри одного 16-байтного БДИ (смотри следующую главу).

Нет ограничение на длину инструкции в D0 (несмотря на то, то руководства от

Интел говорят об обратном) пока все три инструкции влезают в один 16-ти

байтный блок.

Инструкция, которая генерирует больше 4-х мопов требует два или больше такта

для раскодировки, и ни одна другая инструкция не может раскодировываться

параллельно.

Из вышеприведенных правил следует, что декодеры могут генерировать максимум

шесть мопов за такт, если первая инструкция в каждой раскодировываемой группе

разбивается на 4 мопа, а другие две - на один каждая. Минимальное количество -

это два мопа за такт, еси все инструкции генерируют по два мопа, так что D1 и

D2 никогда не используются.

Для максимальной производительности рекомендуется перегруппировать ваши

инструкции в блоки 4-1-1: инструкции, которые генерирует 2 или 4 мопа

можно разбить на две простые одномопные инструкции, что не будет вам

стоить ни такта.

Пример:

Это занимает три такта для раскодировки. Вы можете сохранить один такт,

перегруппировав инструкции в две декодируемые группы:

Теперь декодеры генерируют 8 мопов за два такта, что удовлетворительно. На

более поздних стадиях конвеер может обрабатывать только 3 мопа за такт,

поэтому при скорости декодирования высшей, чем эта, вы можете считать, что

декодирование не является узким местом. Тем не менее, сложности в механизме

доставки могут задержать раскодирование так, как это рассказывается в

следующей главе, поэтому чтобы быть спокойным, лучше стремиться к скорости

раскодировки большей 3-х мопов за такт.

Вы можете узнать количество генерируемых инструкцией мопов в таблице в главе

29.

Префиксы инструкций также приводят к потере скорости раскодировки. У

инструкций могут быть префиксы следующих видов:

• Префикс размера операнда требуется, когда вы используете 16-ти битный

операнд в 32-х битном окружении или наоборот. (Не считая инструкций,

у которых операнды могут быть только одного размера, например FNSTSW AX).

Префикс размера операнда вызывает потерю нескольких тактов, если у

инструкции есть числовой 16-ти или 32-х битный операнд, потому что размер

операнда меняется префиксом.

Примеры:

Последную инструкцию следует заменить на

• Префикс размера адреса используется при 32-х битной адресации в 16-ти

битном режиме или наоборот. Это редко требуется и этого следует избегать.

Префикс размера адреса вызывает потери каждый раз, когда операнды

используются явно, потому что интерпретация изменяется с помощью

префикса. Инструкции, использующие оеранды памяти неявно (например

строковые операции), не приводят к потерям, связанных с префиксом

размера операнда.

• Префиксы сегментов используются, когда вы обращаетесь к данным,

находящимся не в сегменте данных по умолчанию. На PPro, PII и PIII

префиксы сегментов не приводят к потерям.

• Префиксы повторения и префиксы закрытия (lock prefixes) не приводят к

потерям при декодировании.

• Всегда есть потери, когда у вас больше одного префикса. Обычно уходит

по одному такту на префикс.

Двойной буфер может доставить один 16-ти байтный чанк за такт и может

сгенерировать один БДИ за это же время. БДИ обычно 16-ти байтов длиной, но

могут быть короче, если есть предсказанный переход в блоке. (Смотри главу

22 о предсказании переходов).

К сожалению, двойной буфер недостаточно велик, чтобы обрабатывать инструкции

связанные с переходами без задержек. Если БДИ, который содержит инструкцию

перехода, пересекает 16-ти байтную границу, двойному буферу требуется держать

два последовательных 16-ти байтных чанка, чтобы сгенерировать его. Если первая

инструкция после перехода пересекает 16-ти байтную границу, тогда двойной

буфер должен загрузить два новых 16-ти битных чанка кода, прежде чем будет

сгенерировать БДИ. Это ознаает, что в худшем случае раскодировка первого

инструкции после перехода может быть задержана на два цикла. У вас происходят

потери из-за 16-ти байтных границ в БДИ, содержащем переход, и из-за

пересечения 16-ти байтной границы после перехода. Вы можете получить выигрыш в

производительности, если у вас больше, чем одна раскодировываемая группа в

БДИ, которая содержит переход, потому что это дает двойному буферу

дополнительное время для доставки одного или двух чанков кода, следующих за

переходом. Подобные выигрыши могут компенсировать потери согласно таблице

ниже. Если двойной буфер доставляет только один 16-ти байтный чан после

перехода, тогда первый БДИ после перехода будет идентичен этом чанку, то есть

выравнен по 16-ти байтной границе. Другими словами, первый БДИ после перехода

не будет начинаться с первой инструкции, но с ближайшего предшествующего

адреса, кратного 16. Если у двойного буфера есть время, чтобы загрузит два

чанка, тогда новый БДИ может пересечь 16-ти байтную границу и начаться с

первой инструкции после перехода. Эти правила кратко прорезюмированы в

следующей таблице:

Переходы задерживают доставку, поэтому цикл всегда занимает на два такта

больше за выполнение, чем количество 16-ти байтных границ в цикле.

Следующая проблема с механизмом доставки инструкций заключается в том, что

новый БДИ не сгененирируется, пока предыдущий не будет полностью отработан.

Каждый БДИ может содержать несколько раскодировываемых групп. Если БДИ длиной

16 байт заканчивается незавершенной инструкцией, тогда следующий БДИ начнется

в начале этой инструкции. Первая инструкция в БДИ всегда идет в D0, а

следующие две инструкции направляются в D1 и D2, если это возможно. Как

следствие, D1 и D2 используются не совсем оптимально. Если код структурирован

согласно правилу 4-1-1, а инструкция, которая, как предполагалось, должна

направиться в D1 или D2, оказывается первой инструкцией в БДИ, тогда она

попадает в D0, что ведет к потере одного такта. Вероятно, это недостаток

архитектуры процессора. Из-за этого время, которое займет раскодировка

определенного кода может зависеть от того, где начнется первый БДИ.

Если скорость раскодирования инструкций критична, и вы хотите избежать этой

проблемы, вам нужно знать, где начинается каждый БДИ. Это довольно нудная

работа. Вначале вам разделить ваш сегмент на параграфы, чтобы знать, где

находятся 16-ти байтные границы. Затем вам нужно взглянуть на ассемблерный

листинг, чтобы увидеть, какова длина каждой инструкции. (Рекомендуется,

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

Если вы знаете, где начинается один БДИ, тогда вы можете найти, где начинается

другой следующим образом: сделать блок 16 байтов длиной. Если он кончается на

границе между инструкциями, значить следующий БДИ начнется здесь. Если он

включает в себя часть инструкции, тогда следующий БДИ начнется с этой

инструкции. (Здесь нужно подсчитывать только длины инструкций, не имеет

значения, сколько мопов они генерируют.) Таким образом вы можете обработать

весь код и отметить, где начинается каждый из БДИ-блоков. Единственная

проблема - это узнать, где находится первый БДИ. Вот несколько подсказок.

• Первый БДИ после перехода, вызова или возвращения может начинаться

либо с первой, либо с ближайшей предшествующей 16-ти байтной границе,

согласно вышеприведенной таблице. Если вы выравняете первую инструкцию

так, чтобы она начиналась с 16-байтной границы, вы можете быть уверены,

что первый БДИ начнется здесь. Вы можете выравнять подобным образом

важные процедур и циклы, чтобы убыстрить работу программы.

• Если комбинированная длина двух последовательных инструкций больше 16

байтов, вы можете быть уверены, что вторая не влезет в тот же БДИ, что

и первая, следовательно вы можете быть увенны, что вторая инструкция

будет первой в БДИ. Вы можете использовать ее в качестве стартовой

точки для того, чтобы найти где начинаются следующие БДИ.

• Первый БДИ после неправильного предсказания перехода начинается по 16-ти

байтной границе. Как объясняется в главе 22.2, цикл, который повторяется

больше 5 раз, всегда будет приводить к неправильному предсказанию

перехода при выходе. Первый БДИ после такого цикла будет начинаться по

ближайшей предшествующей 16-ти байтной границе.

• Есть также другие события, приводящие к подобному эффекту, например

прерывания, исключения, самомодифирующийся код и такие инструкции как

CPUID, IN и OUT.

Я уверен, что теперь вы хотите получить пример:

Давайте предположим, что первый БДИ начинается по адресу 1000h и заканчивается

в 1010h. Это до завершения инструкции 'MOV [MEM], 0', поэтому следующий БДИ

начнется в 1007h и закончится в 1017h. Это граница между инструкциями, поэтому

третий БДИ начнется в 1017h и захватит весь остаток цикла. Количество тактов,

которое уйдет на раскодировку - это количество инструкций, попадающих в D0.

Всего их в цикле 5. Последний БДИ содержит три раскодировываемых блоков,

включая последние пять инструкций, и одну 16-ти байтную границу (1020h). Если

мы еще раз посмотрим на таблицу, то увидим, что первый БДИ после перехода

будет начинаться с первой инструкции после перехода (та, где стоит метка LL) и

заканчиваться у 1015h. Это перед концом инструкции LEA, поэтому следующий БДИ

будет начинаться с 1011h до 1021h, а последний будет идти от 1021h до самого

конца. Теперь LEA и DEC попадают в начало БДИ, поэтому они обе направляются в

D0. У нас есть 7 инструкции в D0 и на раскодироваку цикла во втором повторении

уходит 7 тактов. Последний БДИ содержит только одну раскодировываемую группу

(DEC ECX / JNZ LL) и у него нет 16-ти байтной границы. Согласно таблице,

следующий БДИ после перехода начнется с 16-ти байтной границы, то есть 1000h.

Мы оказываемся в той же ситуации, что и в первом повторении, и вы увидите, что

раскодировка цикла занимает соответственно 5 и 7 тактов. Так как других узких

мест нет, на выполнение цикла 1000 раз уйдет 6000 тактов. Если бы стартовый

адрес был другим, и в первой или последней инструкции была бы 16-ти байтная

граница, то это бы заняло 8000 тактов. Если вы перегруппируете цикл, так

чтобы инструкции для D1 или D2 не попадали в начало БДИ, тогда выполнение

цикла заняло бы еще меньше - 5000 тактов.

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

местом является доставка инструкций и их раскодировка. Самый легкий путь

избежать этой проблемы - это структурировать ваш код, чтобы он генерировал

больше 3 мопов за такт, чтобы раскодировка не была узким местом несмотря на

приведенные потери скорости. В маленьких циклах это может быть невозможно,

поэтому вам нужно найти путь, чтобы оптимизировать доставку инструкций и

раскодировку.

Например вы можете изменить стартовый адрес вашей процедуры, чтобы избежать

16-ти байтных границ, когда они вам не нужны. Помните, ваш сегмент кода должен

быть выравнен по параграфу, чтобы вы знали, где находятся границы.

Если вы вставите директиву 'ALIGN 16' до начала цикла, тогда ассемблер

поместит NOP и другие подобные инструкции, чтобы выравнять код. Большинство

ассемблеров используют инструкцию 'XCNG EBX, EBX' в качестве двухбайтного

заполнителя (иногда ее называют "двухбайтным NOP'ом"). Кому бы ни пришла в

голову эта идея, лучше данную инструкцию не использовать, потому что она

занимает больше времени, чем два NOP'а на большинстве процессоров. Если

цикл выполняется много раз, тогда то, что находится за его пределами неважно,

если говорить о скорости и вы не должны заботиться о том, какую инструкцию

использовать в качестве заполнителя. Но если время, занимаемое этими

инструкциями играет роль, тогда вы можете выбрать инструкцию-заполнитель

самостоятельно. Вы также можете использовать инструкции, которые делают

что-нибудь полезное, например обновляют регистр, дабы избежать задержек при

чтении регистра. Например, если вы используете регистр EBP для адресации, но

редко пишете в его, вы можете использовать 'MOV EBP,EBP' или 'ADD EBP, 0' в

качестве заполнителя, чтобы снизить возможность вышеупомянутых задержек. Если

вам не делать ничего подобного, вы можете использовать FXCH ST(0), потому что

она не создает никакой нагрузки на порты выполнения, при условии, что ST(0)

содержит верное значение с плавающей запятой.

Еще одним лекарством может стать перегруппировка ваших инструкций таким

образом, что границы между БДИ не приносили вреда. Это может стать сложной

головоломкой и найти приемлимое решение не всегда возможно.

Другая возможность - манипуляции с длинами инструкций. Иногда вы можете

заменить одну инструкцию другой с иной длиной. Многие инструкции можно

закодировать различными вариантами с разной длиной. Ассемблер всегда

выбирает наиболее короткую версию инструкции, но все можно закодировать

более длиную версию. Например 'DEC ECX' занимает один байт длиной,

'SUB ECX, 1' - тир байта, и вы можете закодировать 6-ти байтовую версию,

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

Инструкции с операндами в памяти можно сделать на оди байт длинее с помощью

SIB-байта, но самым легким путем сделать инструкцию на один байт длинее

является добавление сегментного префикса DS (DB 3Eh). Микропроцессоры обычно

принимают избытычные и ничего не значащие префиксы (не считая LOCK), если

длина инструкции не превышает 15-ти байт. Даже инструкции без операндов

памяти могут иметь сегментный префикс. Поэтому если вы хотите, чтобы

инструкция 'DEC ECX' была два байта длиной, напишите:

Помните, что при этом у вас будут потери при раскодировке, если у инструкции

больше одного префикса. Вомзожно, что инструкции с ничего не значащими

префиксами, особенно префиксами повторения и закрытия, будут использоваться в

будущих процессорах для новых инструкций, когда не останется свободных кодов,

но полагаю, что использование сегментных префиксов с уже существующими

инструкциями вполне безопасно.

Переименование регистров - это продвинутая техника, используемая этими

микропроцессорами, чтобы убрать зависимости между различными частями кода.

Пример:

Здесь последние три инструкции независимы от трех первых в том смысле, что

им не требуется результат, полученный после их выполнения. Чтобы

оптимизировать этот код на ранних процессорах вы были должны использовать

другой регистр, отличный от EAX, в последних трех инструкциях и

перегруппировать инструкции так, чтобы последние три выполнялись параллельно

с первыми тремя. PPro, PII и PIII делают это автоматически. Они назначают

новый временный регистр для EAX каждый раз, когда вы пишете в него. Таким

образом инструкции 'MOV EAX, [MEM3]' становятся независимыми от предшествующих

инструкций. С помощью выполнения не по порядку 'MOV [MEM4], EAX' может

выполниться до того окончания обработки медленной инструкции IMUL.

Переименование регистров происходит полностью автоматически. Новый временный

регистр назначается как псевдоним постоянному регистру каждый раз, когда

инструкция пишет в этот регистр. Например инструкция 'INC EAX' использует

один временный регистр для ввода и другой временный регистр для вывода. Это,

разумеется, не убирает зависимости, но имеет некоторое значение для

последующих чтений из регистра, о чем я расскажу позже.

Все регистры общего назначения, указатель на стек, флаги, регистры плавающей

запятой, регистры MMX, регистры XMM и сегментные регистры могут быть

переименованы. Контрольные слова и слово статуса плавающей запятой не могут

быть переименованы, поэтому навряд ли у вас кончаться временные регистры.

Общей практикой установки значения регистра в ноль является 'XOR EAX,EAX' или

'SUB EAX, EAX'. Эти инструкции не распознаются как независимые от предыдущего

значения регистра. Если вы хотите убрать зависимость от медленных

предшествующих инструкций, используйте 'MOV EAX, 0'.

Переименование регистров контролируется таблицей псевдонимов регистров (RAT)

и буфером перегруппировки (ROB). Мопы из декодеров поступают в RAT через

очередь, затем в ROB, а после чего в резервационную станцию (reservation

station). RAT может обрабатывать только 3 мопа за такт. Это означает, что

суммарная производительность процессора не может превышать 3 мопа за такт.

Практически нет никаких ограничений на количество переименований. RAT может

переименовывать три регистра за такт, и он может даже переименовать один и

тот же регистр три раза за один такт.

16.2 Задержки чтения регистров.

Но существует другое ограничение, которое может быть весьма серьзеным, и это

то, что за один такт вы можете читать только из двух постоянных регистров. Это

ограничение относится ко всем регистрам, используемых инструкциям, не считая

тех регистров, в которые инструкции только пишут. Пример:

Первая инструкция генерирует два мопа: один считывает EAX, а другой - EDI и

ESI. Вторая инструкция генерирует один моп, который читает ESP и EBP. EBX не

учитывается, поскольку инструкция только пишет в него. Давайте предположим,

что эти три мопа идут вместе через RAT. Я буду использовать слово триплет для

группы из трех последовательных мопов, которые идут вместе через RAT. Так как

ROB может обрабатывать только два чтения из постоянных регистров за такт, а

нам нужно пять чтений, то наш триплет будет задержен на два дополнительных

такта, прежде чем он попадет в резервационную станцию. При трех или четырех

чтений из постоянных регистров он был бы задержен на один такт.

Из одного регистра в одном триплете можно читать больше одного раза без

ущерба для качества. Если вышеприведенные инструкции поменять на:

тогда произойдет только два чтения из регистров (EDI и ESI) и триплет не

будет задержен.

Регистр, в который будет произведена запись текущим мопом, сохраняется в ROB,

поэтому из него можно свободно читать, пока он не будет выгружен оттуда, что

занимает по меньшей мере три такта, а обычно еще больше. Выгрузка из ROB

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

Другими словами, вы можете читать любое количество раз из регистра в RAT без

задержек, если их значение еще не стало доступным у модулей выполнения,

поэтому вы можете быть уверены, что из регистра, в который была произведена в

одном триплете, можно свободно читать как минимум в трех последующих. Если

выгрузка (writeback) была задержена перегруппировкой, медленными инструкциями,

цепочками зависимости, задержкой кэша или по какой-то другой причине, тогда

из регистра можно свободно читать еще некоторое время.

Пример:

Эти шесть инструкций генерирую 1 моп каждая. Давайте предположим, что первые

три мопа идут через RAT вместе. Эти три мопа читают регистры EBX, ECX и EAX.

Но так как мы пишем в EAX до того, как начали из него читать, чтение

прозводится "бесплатно" и у нас нет никаких задержек. Следующие три мопа

читают EAX, ESI, EBX, EDI и ECX. Так как оба EAX, EBX и ECX были изменены

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

поэтому учитываются только ESI и EDI, и у нас нет задержек и во втором

триплете. Если инструкцию 'SUB ECX, EAX' в первом триплете заменить на

'CMP ECX, EAX', тогда в ECX не производится запись, и у нас происходит

задержка во втором триплете при чтении ESI, EDI и ECX. Подобным же образом,

если инструкция 'INC EBX' в первом триплете поменять на NOP или что-нибудь

вроде этого, тогда у нас будет задержка во втором триплете при чтении ESI,

EBX и EDI.

Ни один моп не может читать больше, чем из двух регистров. Поэтому все

инструкции, читающие больше, чем из двух регистров, разбиваются на два или

больше мопа.

Чтобы подсчитать количество прочитываемых регистров, вам нужно включить все

регистры, которые считываются инструкцией. В это число входят все

целочисленные регистры, флаговые регистры, указатель на стек, регистры

плавающей запятой и регистры MMX. Регистр XMM идет за два, кроме тех случаев,

когда используется только его чать, например в ADDSS и MOVHLPS. Сегментные

регистр и указатель на инструкцию не учитываются. Например в 'SETZ AL' вы

считаете флаговый регистр, но не AL. В 'ADD EBX, ECX' считаются и EBX и ECX,

но не регистр флагов, потому что в него только производится запись. 'PUSH EAX'

читает EAX и указатель на стек, а потом пишет в последний.

Инструкция FXCH является особым случаем. Она работает с помощью

переименования, но не считывает никаких значений, поэтому она не попадает

под действие какого-либо правила о задержке чтения из регстра. Инструкция

FXCH ведет себя как один моп, который ни читает, ни пишет в регистр, когда

дело касается правил задержек чтения из регистра.

Не путайте триплеты мопов с раскодировываемыми группами. Последняя может

генерировать от одного до шести мопа, и даеж если раскодировываемая группа

имеет три инструкции и генерирует три мопа, нет никакой гарантии, что эти

три мопа попадут в RAT вместе.

Очередь между декодерами и RAT так которотка (10 мопов), что вы не можете

предположить, что задержки чтения регистров не оказывают влияния на декодеры,

или какие-то изменения в выводе декодеров не задерживают RAT.

Очень трудно предсказать, какие мопы пойдут через RAT вместе, если очередь не

пуста, и для оптимизированного кода очередь должна быть пуста только после

неправильно предсказанного прехода. Несколько мопов, генерируемых одной

инструкцией не обязательно пойдут через RAT вместе; мопы просто берутся

последовательно из очереди по три за раз. Последовательность не нарушается

предсказанным переходом: мопы до и после перехода могут пойти через RAT

вместе. Только неправильно предсказанный переход сбросит очередь и начнет все

сначала, поэтому три следующих мопа точно попадут в RAT вместе.

Если три последовательных мопа читают больше, чем из двух регистров, то вы бы,

конечно, предпочли, чтобы они не шли вместе друг с другом в RAT. Вероятность

того, что они пойдут вместе - одна третья. Задержка чтения трех или четырех

выгруженных регистра в одной тройке мопов - один такт. Вы можете считать

задержку в один такт эквивалентом загрузки еще трех мопов в RAT. С

вероятностью в 1/3 что три мопа пойдут в RAT вместе, средняя задержка будет

эквивалентна 3/3 = 1 моп. Чтобы посчитать следнее время, которое займет для

некоторого кода проход через RAT, добавьте количество потенциальных задержек

чтения регистров к количеству мопов и поделите на три. Вы можете видеть, что

нет смысла убирать задержки с помощью добавления дополнительных регистров,

пока вы точно не уверены, какие мопы пойдут в RAT вместе, или же вы можете

предотвратить больше, чем одну задержку чтения регистра с помощью одной

дополнительной инструкции.

В ситуациях, когда вашей целью является производительность 3 мопа за такт,

ограничение в чтении только двух постоянных регистров за такт может стать

узким местом, которое будет трудно обойти. Возможные пути обойти возможные

задержки чтения регистра следующие:

• Держать мопы, которые читают один и тот же регистр близко друг к другу,

чтобы они попали в один триплет.

• Держать мопы, которые читают разные регистры подальше друг от друга,

чтобы они не могли попасть в один триплет.

• Располагать мопы, которые читают регистр не дальше трех-четырех триплетов

от инструкции, которая писала или изменяла этот регистр, чтобы он не был

выгружен прежде, чем будут произведены все необходимые операции чтения

(не важно, если у вас есть переход, если он будет правильно предсказан).

Если у вас есть основания полагать, что запись в регистр будет задержена,

вы можете спокойно читать из него еще некоторое количество инструкций.

• Использовать абсолютные адреса вместо указателей, чтобы снизить

количество читаемых регистров.

• Вы можете переименовать регистр в триплете, если это не вызывает

задержку, чтобы предотвратить задержку чтения для этого регистра в

одном или больше следующих далее триплетов. Пример:

'MOV ESP,ESP / ... / MOV EAX,[ESP+8]'. Этот метод стоит дополнительный

моп, поэтому его стоит применять только, если среднее предполагаемое

количество предотвращенных задержек чтения больше 1/3.

Для инструкций, которые генерируют больше одного мопа, вы можете захотить

узнать порядок мопов, генерируемых инструкцией, чтобы сделать предсказание

возможных задержек чтения регистра более точным. Ниже я перечислил наиболее

общие случаи.

Запись в память

Запись в память генерирует два мопа. Первый (в порт 4 ) - это операция

сохранения, считывающая регистр, который нужно сохранить, второй моп вычисляет

адрес памяти, читая любые регистры-указатели.

Примеры:

Первый моп читает EAX, второй читает EDI.

Первый моп читает ST(0), второй моп читает EBX и ECX.

Чтение и модифицирование

Инструкция, которая читает операнд в памяти и модифицирует регистр с помощью

какой-либо арифметической или логической операции генерирует два мопа. Первый

(порт 2) - это инструкция загрузки из памяти, читающая любой регистр-указатель,

второй моп - это арифметическая инструкция (порт 1 или 2), читающая и пишущая

в регистр назначения и, возможно, пишущая в регистр флагов.

Пример:

Первый моп читает ESI, второй моп читает EAX и пишет EAX и регистр флагов.

Чтение/модифицирование/запись

Инструкция этого рода генерирует четыре мопа. Первый моп (порт 2) читает

регистр-указатель, второй (порт 0 или 1) читает и производит запись в исходный

регистр и, возможно, пишет в регистр флагов, третий моп (порт 4) считывает

только временный результат, которые не учитывается здесь, четвертый (порт 3)

читает все регистры-указатели снова. Так как первый и четвертый регистр не

могут идти в RAT вместе, вы не получить преимущество от того, что они читают

один и тот же регистр-указатель.

Пример:

Первый моп читает ESI и EDI, второй читает EAX и пишет в EAX и в регистр

флагов, третий читает только временный результат, четвертый читает ESI и EDI

снова. Вне зависимости о того, в каком порядке эти мопы пойдут в RAT, вы

можете быть уверены, что моп, которы читает EAX пойдет вместе с тем, который

читает ESI и EDI. Поэтому задержка чтения регистра неизбежна в этой инструкции,

если только один из регистров не был изменен ранее.

Сохранение регистра в стек.

Сохранение регистра в стек генерирует 3 мопа. Первый (порт 4) - это инструкция

сохранения, чтение регистра. Второй моп (порт 4) генерирует адрес, считывая

указатель на стек. Третий (порт 0 или 1) вычитает размер слова из указателя на

стек, читая и модифицируя его.

Обратная операция генерирует два мопа. Первый (порт 2) загружает значение,

считывая указатель на стек и записывая значение в регистр. Второй моп (порт

0 или 1) корректирует указатель на стек, читая и модифицируя его.

Вызов

Ближний вызов генерирует 4 мопа (порты 1, 4, 3, 01). Первый два мопа читают

указатель на инструкцию (EIP), который не учитывается, потому что он не может

быть переименован. Третий моп читает указатель на стек. Последний моп читает

и модифицирует его.

Возврат

Ближний возврат генерирует 4 мопа (порт 2, 01, 01, 1). Первый моп считывает

ESP. Третий читает и модифицирует его.

Пример того, как избежать задержку чтения регистра можно найти в примере 2.6.

Запись в память не может быть выполнена по порядку, если она зависит от других записей. Есть четыре буфера записи, поэтому вы можете ожидать большие потери производительности во время такой записи в память или записи в некэшированную память, поэтому рекомендуется, чтобы вы делали четыре записи за раз и были уверены в том, что у процессора есть чем еще заняться, прежде чем вы нагрузите его еще четырьмя записями. Чтение из памяти и другие инструкции могут выполняться не по порядку, кроме IN, OUT и синхронизирующих операций.

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

Есть несколько модулей выполнения, сгруппированных вокруг пяти портов. Порт 0 и 1 - для арифметических операций. Простые пересылки, арифметические и логические операции попадают в порт 0 или 1, в зависимости от того, какой из них свободен. Порт 0 также обрабатывает умножение, деление, целочисленные побитовые сдвиги и операции с плавающей запятой. Порт 1 в дополнение к основным функциям занимается переходами и некоторыми операциями MMX и XMM. Порт 2 обрабатывает все чтения из памяти и несколько строковых операций. В главе 29 вы найдете полный список мопов, генерируемых инструкциями кода с указанием того, в какой порт они попадают. Заметьте, что все операции записи в память требуют два мопа, один для порта 3, а другой для порта 4, в то время как операции чтения из памяти требуют только один моп (порт 2).

В большинстве случаев каждый порт может получать один моп за такт. Это означает, что вы можете выполнять до 5 операций мопов за такт, если они попадают в пять разных портов, но так как есть ограничение на 3 мопа за такт, установленное ранее в конвеере, вам никогда не удастся выполнить больше 3 мопов за такт в среднем.

Вы должны убедиться, что никакой порт не получает больше одной трети мопов, если вы хотите достичь производительности в 3 мопа за такт. Используйте таблицу мопов в главе 29 и подсчитайте, сколько мопов попадет в каждый порт. Если порты 0 и 1 перегружены, в то время как порт 2 свободен, вы можете улучшить свой код, заменив некоторые пересылки вида "регистр, регистр" или "регистр, числовое значение" на пересылку вида "регистр, память", чтобы перенести часть нагрузки с портов 0 и 1 на порт 2.

Большинство мопов занимают один такт для выполнения, но умножения, деления и многие операции с плавающей запятой занимают больше:

Сложения и вычитания плавающей запятой занимают 3 такта, но модуль выполнения полностью конвееризован, поэтому он может принимать новые FADD и FSUB каждый такт, пока предыдущие инструкции выполняются (конечно, если они независимы друг от друга).

Целочисленное умножение занимает 4 такта, умножения плавающей запятой - 5, а умножения MMX - 3 такта. Умножения целых чисел и MMX конвееризованы, поэтому они могут получать новые инструкции каждый такт. Умножения плавающей запятой частично конвееризованы: модуль выполнения может получать новую инструкцию FMUL через два такта после получения предыдущей, поэтому максимальная производительность будет равная одному FMUL за каждые два такта. "Дыры" между FMUL'ами нельзя заполнить целочисленными умножениями, так как они используют ту же схему. Сложения и умножения XMM занимают 3 и 4 такта соотвественно и полностью конвееризованы. Но так как каждый регистр XMM представлен в виде двух 64-х битных регистров, упакованная инструкция XMM будет состоять из двух мопов, а производительность будет равна одной арифметической инструкции XMM каждые два такта. Инструкции сложения и умножения XMM могут выполняться параллельно, потому что оне не используют одни и те же порты.

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

Также инструкции переходов, вызовов и возвратов не полностью конвееризованы. Вы не можете выполнить новый переход в первом же такте после предыдущего перехода. Поэтому максимальная производительность для переходов, вызовов и возвратов равна одному за каждые два такта.

Конечно вы должны избегать инструкций, которые генерируют много мопов. Например инструкцию LOOP XX нужно заменить на DEC ECX / JNZ XX.

Если у вас есть две последовательные POP-инструкции, вы можете заменить их на другие, чтобы снизить количество мопов.

Первый код генерирует 6 мопов, последующий - 4 и декодируется быстрее. Делать то же самое с инструкциями PUSH менее выгодно, потому разбитый код будет генерировать задержки чтения регистров, если только у вас нет других инструкций, которые можно вставить между ними или какие-то регистры не были переименованы раньше. Делать подобное с инструкциями CALL и RET означает мешать правильному предсказанию перехода. Также обратите внимание, что 'ADD ESP' может вызвать задержку AGI в более ранних моделях процессоров.

Станция вывода из обращения может обрабатывать три мопа за такт. Может

показаться, что здесь нет никакой проблемы, потому что вывод уже ограничен

в RAT тремя мопами за такт. Тем не менее, вывод из обращения может стать

узким местом по двум причинам. Во-первых, инструкции должны выводиться из

обращения по порядку. Если моп был выполнен не по порядку, то он не может

быть выведен из обращения, пока все мопы, предшествующие ему по порядку, не

будут выведены из обращения до него. И второе ограничение - это то, что

полученные переходы должны быть выведены из обращения в трех первых слотах

станции. Как декодеры D1 и D2 могут быть неактивны, если следующая инструкция

помещается только в D0, последние два слота станции вывода из обращения могут

быть неактивны, если следующий моп, который должен быть веведен из обращения -

это полученный (taken) переход. Это важно, когда у вас есть маленький цикл,

количество мопов в котором не кратно трем.

Частичная задержка регистра - это проблема, которая возникает, когда вы пишите в часть 32-х битного регистра, а затем читаете из всего регистра или его большей части. Пример:

Происходит задержка в 5-6 тактов. Причина состоит в том, что в соответствие AL был поставлен временный регистр (чтобы сделать его независимым от AH). Модулю выполнения пришлось ждать, пока запись в AL не будет выведена из обращения, прежде чем станет возможным соединить значение AL c тем, что находится в остальной части EAX. Задержку можно избежать, изменив код, поменяв код на:

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

Вам нужно остерегаться частичных задержек, когда вы смешиваете различные размеры данных (8, 16 и 32):

У вас не будет задержки при чтении части регистра после записи в целый регистр или его большую часть:

Самый легкий путь избегать частиные задержки регистра - это всегда использовать полные регистры и использовать MOVZX или MOVSX при чтении из операндов более мелкого размера. Эти инструкции быстры на PPro, PII и PIII, но медленны на более ранних процессорах. Если вы хотите, чтобы ваш код выполнялся достаточно быстро на всех процессорах, то существует разумный компромисс. 'MOVZX EAX,BYTE PTR [M8]'

Процессоры PPro, PII и PIII делают специальное исключение для этой комбинации, поэтому при последующем чтении из EAX задержки не возникнет. Происходит это потому, что регистр помечается как пустой, когда он XOR'ится сам с собой. Процессор помнит, что верхние 24 бита равны нулю и за счет этого избегается задержка. Этот механизм работает только со следующими комбинациями:

Установка регистра в ноль вычитанием его из самого себя работает так же как XOR, но обнуление регистра с помощью инструкции MOV не предотвращает задержку.

Вы можете установите XOR снаружи цикла:

Процессор помнит, что верхние 24 бита EAX равны нулю пока не происходит вызов прерывания, неправильного предсказания перехода или другого синхронизирующего события.

Вы должны помнить, что необходимо нейтрализовывать возможные частичные задержки регистра вышеописанным способом при вызове процедуры, которая будет PUSH'ить полный регистр:

Большинство языков высокого уровня PUSH'ат EBX в начале процедуры, что в вышеприведенном примере привело к частичной задержке регистра, если бы ее не нейтрализовали.

Обнуление регистра с помощью XOR не устраняет его зависимость от предыдущих инструкций:

Обнуление регистра дважды может показаться излишней, но без 'MOV EAX, 0' последние инструкции будут ждать, пока выполниться медленный DIV, а без 'XOR EAX, EAX' случиться частичная задержка регистра.

Инструкция 'FNSTSW AX' особенная: в 32-х битном режиме она ведет себя так же, как если бы писала в весь EAX. Фактически она делает в 32-х битном режиме следующее:

Поэтому при чтении регистра после этой инструкции у вас не возникнет частичной задержки регистра в 32-х битном режиме:

19.2 Частичные задержки флагов

Регистр флагов также может вызвать частичную задержку:

Инструкция JBE читает и флаг переноса, и флаг нуля. Так как инструкция INC изменяет флаг нуля, но не флаг переноса, то инструкции JBE приходится подождать, пока две предыдущие инструкции не будут выведены из обращения, прежде чем она сможет скомбинировать флаг переноса от инструкции CMP с флагом нуля от инструкции INC. Подобная ситуация больше похожа на баг, чем на преднамеренную комбинацию флагов. Чтобы скорректировать эту ситуацию, измените INC ECX на ADD ECX, 1. Похожий баг, вызывающий задержку, - это 'SAHF / JL XX'/. Инструкция JL тестирует флаг знака и флаг переполнения, но не меняет последний. Чтобы исправить это, измените 'JL XX' на 'JS XX'.

Неожиданно (и в противоположность тому, что говорят руководства от Intel), частичная задержка регистра может случиться, если были изменены какие-то биты регистра флагов, а затем считаны неизмененные.

но не при чтении только изменных битов:

Частичные задержки флагов возникают, как правило, при использовании инструкций, которые считывают много или все биты регистра флагов, например LAHF, PUSHF, PUSHFD. Инструкции, которые вызывают задержку, если за ними идут LAHF или PUSHF(D), следующие: INC, DEC, TEST, битовые тесты, битовые сканирования, CLC, STC, CMC, CLD, STD, CLI, STI, MUL, IMUL, и все виды битовых сдвигов и вращений. Следующие инструкции не вызывают задержки: AND, OR, XOR, ADD, ADC, SUB, SBB, CMP, NEG. Странно, что TEST и AND ведут себя различно, хотя по описанию они делают с флагами одно и то же. Вы можете использовать инструкции SETcc вместо LAHF или PUSHF(D) для сохранения значения флага, чтобы избежать задержки.

Примеры:

Потери при частичной задержки флагов примерно равны 4 тактам.

19.3 Задержки флагов после сдвигов и вращений

При чтении любого флагового бита после сдвига или вращения (кроме сдвига и вращения на 1, т.н. короткая форма) может возникнуть задержка, похожая на частичную задержку флагов:

Потери для этого вида задержек приблизительно равны 4 тактам.

19.4 Частичные задержки памяти

Частичная задержка памяти похожа на частичную задержку регистра. Она случается, когда вы смешиваете размеры данных применительно к одному адресу в памяти:

Здесь случается задержка, потому что процессор должен скомбинировать байт, записанный из AL с тремя следующими байтами, которые были в памяти раньше, чтобы получить все четыре байта, необходимые для произведения записи в EBX. Потери приблизительно равны 7-8 тактов.

В отличии от частичных задержек регистра, частичная задержка памяти случается, когда вы записывает операнд в память, а затем читаете его часть, если она не начинается по тому же адресу:

Вы можете избежать этой задержки, если измените последнюю лини на 'MOV BH, AH', но подобное решение невозможно в ситуации, подобной этой:

Интересно, что частичная задержка памяти может также случиться при записи и чтении совершенно разны адресов, если у них одинаковое set-значение в разных банках кэша:

Пример:

В этом примере инструкция ADD генерирует 2 мопа, один для чтения из памяти (порт 2) и один для сложения (порт 0 или 1). Моп чтения может выполняться не по порядку, в то время как моп сложения дожна ждать, пока выполниться предыдущий моп. Эта цепочка зависимости занимает не очень много времени, так как каждое сложение требует только один такт. Но если в вашем коде содержатся медленные инструкции, такие как умножения, или еще хуже - деление, тогда вам определенно нужно сделать что-нибудь, чтобы убрать цепочку зависимости. Это можно сделать, используя разные приемники:

Здесь вторая инструкция IMUL может начаться до того, как будет завершено выполнение первой. Так как у инструкции IMUL вызывает задержку в 4 такта и полностью конвееризована, вы можете использовать до 4-х приемников.

Деление не конвееризовано, поэтому вы не можете делать то же самое со связанными делениями, но, разумеется, вы можете умножить все делители и сделать только одно деление в конце.

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

Вам потребуется для этого много инструкций FXCH, но не беспокойтесь: они стоят дешево. Инструкции FXCH обрабатываются в RAT с помощью переименования регистров, поэтому они не создают никакой назгрузки на порты выполнения. Тем не менее, FXCH генерирует один моп в RAT, ROB и в станции вывода из обращения.

Если цепочка зависимости очень длиная, вам может потребоваться три приемника:

Избегайте сохранения промежуточных данных в памяти и немедленного их считывания:

Возникают потерю из-за попытки чтения из памяти до того, как завершена предыдущая запись туда же. В вышеприведенном примере измените последнюю инструкцию на 'MOV EBX, EAX' или поместите какие-нибудь инструкции между ними.

Есть одна ситуация, когда вы не сможете избежать сохранения промежуточных данных в памяти. Она возникает тогда, когда вы перемещаете данные из целочисленного регистра в регистр FPU или наоборот. Например:

Если вам нечего поместить между записью в TEMP и считыванием из него, вы можете использовать регистр плавающей запятой вместо EAX:

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

Если вы ожидаете потери при работе с кэшем, вам нужно перегруппировать код, чтобы наиболее используемые части кода были ближе друг к другу.

Предсказания основываются на буфере переходов (BTB), который сохраняет историю каждого перехода и делает предсказания, основываясь на прежних выполнения каждой инструкции. BTB организован как множественно-ассоциативный (set-associative) кэш, в котором новые элементы используются согласно псевдослучайному методу замещений.

Оптимизируя код важно снижать количество возможных неправильных предсказаний перехода. Это можно сделать при хорошом понимании того, как работает предсказание переходов.

Механизм предсказания переходов адекватно не объясняется ни в руководствах от Интела, ни где-нибудь еще, поэтому здесь дается очень детальное описание. Эта информация основывается на моих собственных исследованиях (осуществленных с помощью Karki Jitendra Bahadur для PPlain).

Далее я буду использовать термин "команда передачи управления" для любой инструкции, которая меняет eip, включая условные и безусловные, прямые и косвенные, ближние и дальние переходы, вызовы и возвраты. Все эти инструкции используют предсказание.

22.1 Предсказывание переходов в PPlain

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

У PPlain есть буфер переходов (BTB), который может содержать информацию о 256 инструкциях перехода. BTB организована в виде 4-х направленного множественно-ассоциативного кэша по 64 элемента на каждом направлении. Это означает, что BTB может содержать не больше чем 4 элемента для каждого set-значения. Как высчитывается set-значение будет объяснено позже. Каждый элемент BTB хранит адрес, куда должен быть совершен переход и состояние предсказания, которое может иметь три разных значения:

• состояние 0: "не будет осуществлен"

• состояние 1: "возможно не будет осуществлен"

• состояние 2: "возможно будет осуществлен"

• состояние 3: "будет осуществлен"

Предсказывается, что инструкция перехода будет осуществлена, когда состояние равно 2 или 3, и пропускается при состоянии 0 или 1. Состояние перехода работает как двух-битный счетчик, поэтому состояние увеличивается на 1, если переход был осуществлен и понижается, если этого не произошло. Понижение и повышение значения происходит по принципу "насыщения", то есть значение не может понизиться ниже 0 (и стать 3) и не может повыситься выше 3 (и стать 0). По идее, все это должно привести к довольно хорошему проценту правильных предсказаний, потому что до того, как будет изменено предсказание, инструкция перехода должна быть выполнена два раза не так, как она выполняется обычно.

Тем не менее, этот механизм может был поставлен под угрозу тем, что состояние 0 также означает "неиспользованный элемент BTB". Поэтому элемент BTB с состоянием 0 означает примерно то же, что если бы его вообще не было. Это имеет смысл, потому что если у инструкции перехода нет соответствующего элемента BTB, предсказывается, что она не будет осуществлена. Это улучшает использование BTB, так как инструкция перехода, которая редко осуществляется большую часть времени не будет занимать никакого элемента BTB.

Если у инструкции перехода нет своего элемента в BTB, генерируется такой элемент и значение его состояние будет установлено в 3. Это означает, что перейти от состояния 0 к состоянию 1 невозможно (кроме очень специфических случаев, обсуждаемых позже). От состояния 0 вы можете перейти только к состоянию 3, если иснтрукция перехода будет выполнена. Если этого не произойдет, она не получит свой элемент в BTB.

Это серьезный промах в дизайне архитектуры процессора. Очевидно, что таким образом дизайнеры отдали предпочтение минимизации потери роизводительности при загрузке в первый раз часто выполняющихся инструкций перехода и проигнорировали то, что это серьезно искажает первоначальную идею и снижает производительность в маленьких внутренних циклах. Следствием этого изъяна явлется то, что инструкция перехода, которая большую часть времени не выполняется, может иметь в три раза больше неправильных предсказаний, чем инструкция перхода, которая большую часть времени выполняется. (Похоже, что пока я не опубликовал свои исследования, инженеры Интела были не в курсе насчет этого).

Вы можете принять эту ассиметричность в расчет, организовав ваши ветви так, чтобы они чаще выполнялись, а не пропускались. Посмотрите на этот пример конструкции if-then-else:

Если ветвь 1 выполняется чаще, чем ветвь 2, а последняя выполняется реже в два раза, тогда вы можете снизить количество неправильных предсказаний, поменяв две ветви так, чтобы инструкция перехода выполнялась чаще, чем пропускалась:

(Это противоречит рекомендациям в интеловских руководствах и туториалах).

Тем не менее, есть причины, что помечать чаще выполняющуюся вертвь первой:

• Помещение редко используемых ветвей подальше от основного кода делает использование кода кэша более оптимальным.

• Редко выполняющаяся инструкция перехода не будет напрасно занимать элемент BTB, что, вероятно, сделает использование BTB более оптимальным.

• Инструкция перехода будет предсказан как не выполняющаяся, если она была вытеснена другими инструкциями из BTB.

• Ассиметричность предсказывания переходов существует только в PPlain.

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

Так же вам следует организовать циклы таким образом, чтобы проверка условия производилась внизу цикла, как в нижеприведенном примере:

Если N велико, тогда инструкция JNZ будет чаще выполняться, чем пропускаться.

Представьте ситуацию, где инструкция перехода выполняется каждый второй раз. В первый раз она попадает в BTB с состоянием 3, а затем будет колебаться между состояниями 2 и 3. Каждый раз будет предсказываться, что она выполниться, но только 50% этих предсказаний будет верными. Теперь предположите, что однажды она отклонилась от привычного поведения и была пропущена.

Дополнительный пропуск помечен знаком '^'. После этого происшествия элемент BTB будет колебаться между состояниями 1 и 2, что будет давать 100% неправильных предсказаний. И так будет продолжаться, пока не случиться еще одно отклонение. Это худшее, что можете произойти в работе этого механизма предсказания переходов.

22.1.2 BTB смотрит вперед (PPlain)

Механизм BTB подсчитывает инструкции попарно, а не по отдельности, поэтому вы должны знать, как инструкции спариваются, чтобы суметь проанализировать, где храниться элемент BTB. Элемент BTB для любой управляющей инструкции присоединяется к адресу инструкции в U-конвеере из предыдущей пары инструкций (неспариваемая инструкция идет за одну пару).

Пример:

Здесь SHR спаривается с MOV, а CMP спаривается с JB. BTB-элемент для 'JB L' присоединяется к адресу инструкции 'SHR EAX,1'. Когда встречается этот BTB-элемент, и он находится в состоянии 2 или 3, тогда Pentium считает целевой адрес из элемента BTB и загрузит инструкции, следующие за L в конвеер. Это произойдет до того, как будет декодирована инструкция перехода, поэтому Pentium полагается исключительно на информацию, содержащуюся в BTB, когда делает это.

Вы можете вспомнить, что инструкции редко спариваются в первый раз при выполнении (смотрите главу 8). Если инструкции выше не спарились, тогда элемент BTB будет присоединен к адресу инструкции CMP, и данный элемент будет неверен при следующем выполнении, когда инструкции уже спарились. Тем не менее, в большинстве случаев PPlain достаточно умен, чтобы не делать элемент BTB при неиспользованной возможности спаривания, поэтому вы получите BTB-элемент только при втором выполнении, а следовательно, предсказания начнутся только с третьего. (В редких случаях, когда каждая вторая инструкция размером в один байт, элемент BTB может возникнуть уже при первом выполнении, что окажется неверным при втором выполнении, но так как инструкция, к которой был присоединен элемент, попадет в V-конвеер, это игнорируется и не вызывает особых потерь. Элемент BTB считывается только тогда, когда он присоединен к адресу инструкции для U-конвеера).

BTB-элемент идентифицируется своим set-значением, которое равно битам 0-5 адреса, к которому он присоединен. Биты 6-31 сохраняются в BTB как тег. Адреса, которые находятся на расстоянии кратном 64 байтам, будут иметь одно и то же set-значение. Вы можете иметь не более четырех BTB-элементов с одинаковым set-значением. Если вы хотите проверить, не будет ли ваша инструкция перехода бороться с другой инструкцией за один и тот же элемент BTB, вы можете сравнить биты 0-5 адресов инструкций, направляющихся в U-конвеер, из предыдущих пар инструкций. Это очень утомительно, и я никогда не слышал о том, что кто-нибудь делал подобное. Нет никаких инструментов, которые могли бы выполнить эту работу за вас.

22.1.3 Последовательные ветви (PPlain)

Когда переход пресдказан неправильно, то конвеер очищается. Если следующая пара инструкций также содержит управляющую инструкцию, то PPlain не будет загружать ее цель, так как он не может этого сделать, пока конвеер не очищен. В результатет вторая инструкция предсказывается как невыполняющаяся вне зависимости от состояния элемента BTB. Поэтому, если второй переход также выполняется на самом деле, то вы получите новые потери. Состояние BTB-элемента для второго перехода будет, тем не менее, правильно изменено. Если у вас есть длиная цепочка инструкций передачи управления, и первый переход в цепочке был предсказан неправильно, тогда конвеер будет постоянно очищаться, и предсказания будут постоянно неправильными, пока не будет встречена пара инструкций, в которой не будет перехода. Самый экстремальный случай подобного рода - это цикл, в котором происходят потери при каждой итерации из-за постоянного неправильного предсказания.

Это не едиснтвенная проблема с последовательными управляющими инструкциями. Другая проблема состоит в том, что у вас может быть другая управляющая инструкция между BTB-элементом и управляющей инструкцией, принадлежащей ему. Если первая инструкция производит переход, то могут произойти странные вещи. Представьте следующий пример:

Когда 'JB L1' пропускается, вы можете получить элемент BTB, присоединенный к адресу 'CMP EAX,EBX'. Но что случится, если 'JB L1' будет выполнена? В тот момент, когда считывается BTB-элемент для 'JMP L2', процессор не знает, что следующая пара инструкций не содержит команду перехода, поэтому он фактически предскажет, что пара инструкций 'MOV EAX,EBX / INC EBX' перейдет на L2. Потери, связанные с предсказанием инструкций, не являющихся командами перехода, равны 3 тактам. Элемент BTB для 'JMP L2' понизит свое состояние на один, потому что он относится к чему-то, что не совершает перхода. Если мы перейдем к L1, тогда состояние элемента BTB для 'JMP L2' будет понижежено до 1 и 0, поэтому данная проблема исчезнет, пока не снова не будет выполнено 'JMP L2'.

Потери при предсказании инструкций, не являющихся управляющими, случаются только тогда, когда предсказавыется переход на L1. В случае, если выполнение 'JB L1' предсказано ошибочно, тогда конвеер очищается, и мы не получим фальшивую загрузку цели L2, поэтому в этом случае мы не заметим потери от предсказания неуправляющих инструкций как выполняющихся, но состояние элемента BTB для 'JMP L2' будет понижено.

Теперь предположите, что мы заменяем инструкцию 'INC EBX' на другую инструкцию перехода. Тогда третья инструкция перехода будет использовать тот же элемент BTB, что и 'JMP L2', что приводит к возможным потерям из-за предсказания неправильной цели (если только целью не является L2).

Теперь прорезюмируем возможные проблемы, к которым могут привести последовательные переходы:

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

• элемент BTB может быть присоединен не к инструкции перехода и предсказать их как выполняющиеся.

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

• две инструкции перехода могут использовать один и тот же элемент BTB, что может привести к предсказанию неправильной цели.

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

Теперь еще один показательный пример:

На первый взгляд как будто все в порядке: вызов функции, цикл, который пропускается, если счетчик равняется нулю, и другой вызов функциии. Какие проблему могут возникнуть?

Сначала мы можем заметить, что функция P вызывается из двух различных мест кода. Это означает, что цель возвращения из P будет все время меняться. Соответственно, возврат из P будет все время предсказываться неправильно.

Теперь предположите, что EAX равен нулю. При переходе на L2 его цель не будет загружена, так как неправильно предсказанное возвращение приведет к очищению конвеера. Затем цель второго вызова P также не будет загружена, потому что 'JZ L2' вызовет новое очищение ковеера. Здесь мы имеем ситуацию, в которой цепь последовательных переходов заставляет постоянно очищаться конвеер из-за того, что первый переход был предсказан неправильно. Элемент BTB для 'JZ L2' сохраняется по адресу инструкции возвращения из функции P. Этот элемент BTB будет теперь неправильно присоединен к тому, что должно быть после второго вызова P, но это не приводит к потерям, так как конвеер очищается из-за неправильно предсказанного второго возвращения.

Теперь давайте посмотрим, что случитсья, если EAX не равен нулю в следующий раз: 'JZ L2' будет всегда предсказываться как невыполняющийся из-за очищения конвеера. Второй 'CALL P' будет иметь свой элемент по адресу 'TEST EAX,EAX'. Этот элемент будет неправильно ассоциирован с парой 'MOV/ADD', предсказывая их переход на P. Это приведет к очищению конвеера, который не даст загрузить цель 'JNZ L1'. Если мы уже были здесь ранее, тогда второй 'CALL P' будет иметь другой элемент BTB с адресом 'DEC EAX'. При втором и третьем повторении цикла этот элемент также будет неправильно ассоциирован с парой 'MOV/ADD', пока ее состояние не понизится до 1 или 0. Это не вызовет потерь во втором выполнении, так как очищение конвеера от 'JNZ L1' не даст загрузить неверную цель, но в третьем выполнении так и случится. Последовательные итерации цикла не приводят к потерям, но если они есть, то JNZ L1 будет предсказан неправильно. Очищение буфера сделает невозможной загрузку цели 'CALL P', не считая того, что ее элемент BTB уже был уничтожен несколькими неправильными ассоциированиями.

Мы можем улучшить этот код, поместив несколько NOP'ов, чтобы отделить друг от друга последовательные переходы:

Дополнительные NOP'ы стоят 2 такта, но они сохранят гораздо больше. Более того, 'JZ L2' теперь перемещяется в U-конвеер, что снижает потери в случае неправильного предсказания с 4 до 3 тактов. Единственная оставшаяся проблема - это возвраты из P, которые всегда предсказываются неправильно. Эту проблему можно решить, заменив вызов P на макрос (если у вас есть достаточное количество свободного кэша кода).

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

Мультиветвенные переходы (выражения условий) можно сделать либо в виде дерева инструкций переходов, либо в виде списка адресов переходов. Если вы выберите дерево инструкций переходов, то вам стоит включить несколько NOP'ов или других инструкций, чтобы отделить последовательные переходы друг от друга, поэтому список адресов может быть более выгодным вариантом на PPlain. Список адресов переходов следует помещать в сегменте данных. Никогда не помещайет данные в сегменте кода!

22.1.4 Маленькие циклы (PPlain)

В маленьких циклах часто происходит доступ к одному и тому же элементу BTB с небольшими интервалами. Вместо того, чтобы ждать, когда обновится элемент BTB, PPlain каким-то образом минует конвеер и получает состояние после последнего перехода, прежде, чем оно записывает в BTB. Этот механизм почти прозрачен для пользователя, но в некоторых случаях он приводит к забавным эффектам: вы можете видеть предсказание перехода от состояния 0 к состоянию 1, а не к состоянию 3, если ноль еще не быль записан в BTB. Это случается, если в цикле не больше четырех пар инструкций. В цикла с двумя парами инструкций может случиться так, что состояние 0 сохраняется на протяжении двух итераций, причем элемент не стирается из BTB. В таких маленьких циклах в редких случаях предсказание использует состояние, бывшее два цикла назад, а не в предыдущем повторении. Эти забавные эффекты обычно не приводят к снижению качества.

22.2 Предсказание переходов в PMMX, PPro, PII и PIII

22.2.1 Организация BTB (PMMX, PPro, PII и PIII)

Буфер переходов (BTB) PMMX состоит из 256 элементов, организованых как 16 направлений * 16 множеств. Каждый элемент идентифицируется битами 2-31 адреса последнего байта инструкции передачи управления, которой он принадлежит. Биты 2-5 определяют множество, а биты 6-31 сохраняются в BTB как тег. Инструкции передачи управления, находящиеся друг от друга на расстоянии 64 байт, имеют одинаковое set-значение, и поэтому могут случайно выдавливать друг друга из BTB. Так как есть 16 направление на множество, то это не будет происходить слишком часто.

Буфер переходов PPro, PII и PIII имеет 512 элементов (16 направлений * 32 множества). Каждый элемент идентифицируется битами 4-31 адреса последнего байта инструкции передачи управления, к которой он принадлежит. Биты 4-8 определяют множество, и все биты сохраняются в BTB как тег. Инструкции передачи управления, которые находятся друг от друга на расстоянии 512 байт, могут случайно выдавливать друг друга из BTB. Так как есть 16 направлений на множество, это не бдует происходить слишком часто.

PPro, PII и PIII резервируют элемент BTB для любой инструкции передачи управления в первый раз ее выполнения (независимо от того, совершает ли она переход, или пропускается). PMMX резервирует элемент в первый раз, когда совершается переход. Инструкция перехода, которая никогда не совершает переход, будет оставаться вне BTB на PMMX. Как только она однажды совершит переход, она окажется в BTB и будет оставаться там все время, даже если она никогда не будет совершать переход снова.

Элемент может быть выдавлен из BTB, когда другой инструкции передачи управления с тем же самым set-значение требуется элемент BTB.

22.2.2 Потери при неверном предсказании (PMMX, PPro, PII и PIII)

На PMMX потери из-за неверного предсказания условного перехода равны 4 тактам для инструкции в U-конвеере и 5 тактам, если она выполнялась в V-конвеере. Для всех других инструкций передачи управления потери равны 4 тактам.

На PPro, PII и PIII потери из-за неверного предсказания очень высоки, так как у этих процессоров длинный конвеер. Неправильное предсказание обычно стоит от 10 до 20 тактов. Поэтому очень важно избегать плохо предсказуемых ветвей, если программа будет выполняться на PPro, PII и PIII.

22.2.3 Распознавание последовательностей условных переходов (PMMX, PPro, PII и PIII)

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

Этот механизм называется "двух-уровневой адаптирующейся схемой предсказания". Он был изобретен T.-Y. Yeh и Y. N. Patt. Механизм основывается на разновидности двухбитного счетчика, использующихся в PPlain (но без изъяна, описанного выше). Счетчик повышается, когда совершается переход и понижается, когда этого не происходит. Нет автоматического обнуления при повышении 3 или приравнивания к 3 при понижении 0. Инструкция перехода предсказывается как выполняющаяся, если соответствующий счетчик равен 3 или 3, и предсказывается как несовершающая переход, если он равен 0 или 1. Значительное улучшение данного алгоритма было получено путем введения 16 таких счетчиков для каждого элемента BTB. Он выбирает один из этих шестнадцати счетчиков, основываясь на истории выполнения переходов за четыре последних раза. Если, например, инструкция перехода однажды выполняется, а потом нет на протяжении четырех последних раз. Если, например, инструкция перехода совершает его однажды и затем не делает его три раза подряд, тогда биты истории равны 1000 (1 = переход, 0 = не-переход). Значит, будет использоваться счетчик под номером 8 (1000b = 8) для предсказания в следующий раз и обновления состояния счетчика.

Если последовательность 1000 всегда следует за 1, тогда счетчик под номером 8 вскоре достигнет своего нивысшего состояния (3), что означает постоянное предсказываения последовательности 1000. Потребуется два отклонения от этой последовательности, чтобы изменить предсказание. Посвторяющаяся последовательность 100010001000 будет иметь счетчик 8 в состоянии 3 и счетчик 1, 2 и 4 в состоянии 0. Другие двенадцать счетчиков не будут использоваться.

22.2.4 Последовательности, предсказанные совершенно (PMMX, PPro, PII, PIII)

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

Читая эту таблицу, вы должны учитывать, что если последовательность предсказывается верно, тогда та же последовательность, но прочитанная задом-наперед также будет предсказана верно, также как и та же последовательность, но с инвертированным битами. Пример: в таблице мы нашли последовательность: 001011. Изменение порядка битов на обратный дает: 1101000. Инвертирование всех битов дает 1110100. Изменение порядка битов и инвертирование вместе: 0010111. Все эти четыре последовательности будут распознаны. Циклический сдвиг всех битов на одну позицию влево дает: 0010110. Это, конечно, не новая последовательность, а всего лишь чуть сдвинутая версия той, которую мы рассматривали. Все последовательности, которые могут быть выведены от одной из перечисленных в таблице с помощью изменения порядка битов, инвертирования и циклического сдвига также могут быть разпознанны. В целях экономии места они не были перечисленны.

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

22.2.5 Обработка отклонений от регулярных последовательностей (PMMX, PPro, PII и PIII)

Механизм предсказания также довольно хорошо справляется с обработкой 'почти регулярных' последовательностей или отклонений от регулярной последовательности. Он не только заучивает, как выглядит регулярная последовательность, он также изучает, какие существуют отклонения от нее. Если отклонения все время одни и те же, тогда он будет помнить, что идет после отклонения, и оно будет стоить толко одно неправильное предсказание.

Пример:

В этой последовательности 0 означает не-переход, а 1 - переход. Механизм выучивает то, что повторяющаяся последовательность равна 000111. Первое отклонение - это неожиданный 0, который я отметил знаком '^'. После этого 0 следующие три перехода могут быть неправильно предсказаны, потому что механизм еще не выучил, что идет после 0010, 0101 и 1011. После одного или двух отклонений того же вида он выучивает, что после 0010 идет 1, после 0101 идет 1, а после 1011 идет 1. Это означает, что после двух отклонений одного и того же вида, он выучивает как их обрабатывать, допуская только одно неправильное предсказание.

Механизм предсказания очень эффективени, когда происходит смена одной регулярной последовательности на другую. Если, например, у нас была последовательность 000111 (с периодом 6), которая повторилась много раз, потом последовательность 01 (период 2) много раз, а затем произошел возврат на последовательность 000111, тогда механизм не должен снова изучать последовательность 000111, так как счетчики, которые были использованы для этой последовательность остались в неприкосновенности. После нескольких смен последовательностей с одной на другую, механизм также выучивает, как обрабатывать изменения ценой только одного неправильного предсказания во время переключения одной последовательности на другую.

22.2.6 Последовательности, не предсказываемые совершенно (PMMX, PPro, PII и PIII)

Простейшая последовательность, которая не может быть предсказана совершенно - это переход, который совершается каждый 6-ой раз. Вот последовательность:

За последовательностью 0000 следует 0 в позициях, помеченных 'a', и 1, в позициях, помеченных 'b'. Это влияет на счетчик под номером 0, который постоянно повышает и понижает свое значение. Если счетчик 0 был вначале равен 0 или 1, тогда он будет колебаться между 0 и 1. Это приведет к неправильному предсказанию в позиции b. Если счетчик 0 был в самом начале равен 3, тогда он будет колебаться между состояниями 2 и 3, что приведет к неправильному предсказанию в позиции a. Худший случай - это когда его состояние было в начале равно 2. Он будет колебаться между 1 и 2, что приведет к неправильному предсказанию в обоих позициях. (Это аналогично худшему случаю для PPlain, объясненному выше). Какую из этих ситуаций мы получим, зависит от истории элемента BTB до того, как он был зарезервирован. Мы не можем это проконтролировать, так как элементы BTB выбираются случайно.

В принципе, можно избежать худший случай, если задать в самом начале задать специально спроектированную последовательность, чтобы поместить счетчик в желаемое состояние. Такой подход трудно порекомендовать, так как он значительно усложняет код и любая информация, которую мы поместим в счетчик будет, похоже, потеряна при следующем прерывании или переключении задач.

22.2.7 Полностью случайные последовательности (PMMX, PPro, PII и PIII)

Мощная способность распознавания последовательностей имеют небольшой изъян в случае полностью случайных нерегулярных последовательностей.

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

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

22.2.8 Маленькие циклы (PMMX)

Предсказание переходов ненадежно в маленьких циклах, где у механизма распознавания последовательностей нет времени, чтобы обновить свои данные перед новой встречей с переходом. Это означает, что простые последовательности, которые в обычном случае были бы предсказаны совершенно, не будут распознанны. Также некоторые последовательности, которые в обычном случае не были бы распознаны, будут предсказаны в маленьком цикле. Например, цикл, который всегда повторяется 6 раз, имел бы последовательность 111110 для инструкции ветвления в начале цикла. В этой последовательности было бы одно или два неправильных предсказаний за итерацию, но в маленьком цикле не будет ни одного. То же самое касается цикла, который повторяется 7 раз. С другим количеством повторений предсказуемость будет хуже в маленьких циклах, чем обычно. Это означает, что количество повторений, равное 6 или 7, более предпочтительно для маленьких циклов. Вы можете развернть цикл, чтобы сделать его больше.

Чтобы узнать, подпадает ли цикл на PMMX под действие вышеизложенных правил, вы можете сделать следующее: подсчитайте количество инструкций в цикле. Если количество равно 6 или меньше, тогда цикл является "маленьким". Если у вас больше 7 инструкций, тогда у вас может быть достаточно твердая уверенность в том, что распознавание последовательностей будет работать нормально. Довольно странно, что количество тактов, которое требуется для выполнения инструкций, не играет роли, как и спариваемость инструкций и вызываемые ими задержки. Сложные целочисленные инструкции при подсчете не учитываются. В цикле может быть много таких инструкций, и он будет себя вести как "маленький". Сложная целочисленная инструкция - это не спариваемая целочисленная инструкция, которая всегда требует больше одного такта. Сложные инструкции плавающей запятой и инструкции MMX идут одна за одну. Обратите внимание, что это правило выведено эвристическим путем и не 100% надежно. В важных случаях вы можете провести свое собственное тестирование. Вы можете использовать датчик качества с номером 35 в PMMX, чтобы подсчитать количество неправильно предсказанных переходов. Результаты тестов также не могут быть полностью надежны, потому что предсказания переходов зависят от истории элемента BTB до резервирования.

Маленькие циклы на PPro, PII и PIII предсказываются нормально, и каждое повторение занимает минимум два цикла.

22.2.9 Косвенные переходы и вызовы (PMMX, PPro, PII и PIII) Распознавание последовательностей не работает в случае косвенных переходов и вызовов, а BTB не может запомнить больше одной цели для косвенного вызова. Предсказывается переход к той же цели, что и в прошлый раз. 22.2.10 JECXZ и LOOP (PMMX) На PMMX распознавание последовательностей не работает с этими двумя инструкциями, просто предсказывается то, что произошло в последний раз. Эти две инструкции следует избегать в критическом коде для PMMX (на PPro, PII и PIII) предсказания осуществляются с помощью распознавания последовательностей, но специальные инструкции циклов все равно ужасны по сравнению с DEC ECX / JNZ). 22.2.11 Возвраты (PMMX, PPro, PII и PIII)

У процессоры PMMX, PPro, PII и PIII есть стековый буфер возвратов (RSB), который используется для предсказывания инструкций возвратов. RSB работает как FIFO (первым-вошел-первым-вышел) буфер. Каждый раз, когда выполняется инструкция вызова, соответствующий адрес возврата помещается в RSB. И каждый раз, когда выполняется инструкция возврата, адрес возвращения вынимается из RSB и используется для предсказывания возврата. Этот механизм обеспечивает корректное предсказание этих инструкций, когда одна и та же подпрограмма вызывается из разных мест.

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

RSB может содержать до 4 элементов в PMMX, шестнадцать в PPro, PII и PIII. В случае, когда RSP пуст, инструкция возврата предсказывается также, как и косвенный переход, то есть ожидается переход туда, куда он был совершен в последний раз.

На PMMX, когда подпрограммы вложены друг в друга более, чем на 4 уровня, все возвраты, кроме 4 самых внутренних уровней, поддерживаемых PMMX, используют простой механизм предсказания, пока не происходит новых вызовов. Инструкция возврата, находящаяся в RSB, также занимает один элемент BTB. Четыре элемента в RSB PMMX'а кажутся не весть чем, но это, вероятно, эффективно. Подрограммы, вложенные более, чем на 4 уровня, не являются чем-то необычным, но только внутренние уровни максимально эффективны в плане скорости, не считая возможности рекурсивных процедур.

На PPro, PII и PIII, когда подпрограммы вложены глубже, чем на 16 уровней, внутренние 16 уровней используют RSB, в то время как все последующие возвраты из внешних уровней предсказываются неверно, поэтому рекурсивные процедуры не следует делать вложенными более, чем на 16 уровней.

22.2.12 Статическое предсказание (PMMX)

Инструкция передачи управления, которая не встречалась ранее, или которая не находится в BTB всегда предсказывается как невыполняющаяся на PMMX. Не играет роли, куда совершается переход: вперед или назад.

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

Любая инструкция передачи управления, которая переходит на адрес, непосредственно следующий за ней же, не получает элемент в BTB.

Пример:

LL:

Эта инструкция никогда не поулчит элемент в BTB и поэтому всегда будет предсказываться неправильно.

22.2.13 Статическое предсказывание (PPro, PII и PIII)

На PPro, PII и PIII инструкция передачи управления, которая не встречалась ранее или которой нет в BTB, предсказывается как невыполняющаяся, если она указывает вперед, и как выполняющаяся, если она указывает назад (например, цикл). Статическое предсказываение занимает больше времени, чем динамическое предсказание на этих процессорах.

Если похоже, что ваш код не прокэширован, то предпочтительнее, чтобы наиболее часто встречающаяся инструкция перехода не выполнялась, чтобы улучшить доставку.

22.2.14 Закрытые переходы (PMMX)

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

Элемент BTB для инструкции передачи управления определяется по битам 2-31 адреса последнего байта инструкции. Если две инструкции передачи управления находятся так близко друг от друга, что отличаются только битами 0-1 этих адресов, то у нас есть проблема разделяемого элемента BTB. Пример:

Если последний байт инструкции CALL и последний байт инструкции JNC находятся внутри того же слова памяти, то мы получаем потери. Вы должны взглянуть на сгенерированный ассемблерный листинг, чтобы увидеть, разделены ли эти два адреса границей двойного слова или нет (граница двойного слова - это адрес, который делится на 4).

Есть несколько путей решить эту проблему:

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

• Изменить короткий переход на ближний переход, чтобы конец инструкции сместился чуть вниз.

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

Если вы хотите избежать проблем и на PPlain, тогда поместите вместо MOV два NOP'а, чтобы предотвратить спаривание.

Инструкция RET особенно беззащитна перед этой проблемой, потому она всего один байт длиной.

Здесь вам может потребоваться вставить три байта:

22.2.15 Последовательные вызовы или возвраты (PMMX)

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

Пример:

Требуется два NOP перед 'CALL FUNC2', потому что один NOP будет спариваться с CALL. Одного NOP достаточно перед RET, потому что эта инструкция неспариваема. Не требуется NOP между двумя инструкциями CALL, потому что нет потерь при вызове после возврата (на PPlain вам потребуется здесь два NOP).

Подобные потери последовательных вызовах возникают только, когда одни и те же подпрограммы вызываются из более, чем одного места (вероятно, это происходит из-за обновления RSB). Последовательные возвраты всегда приводят к потерям. Иногда возникает небольшая задержка при переходе после вызова, но нет потерь при возврате после вызова, вызова после возврата, перехода, вызова или возврата после перехода или перехода после возврата.

22.2.16 Последовательные переходы (PPro, PII и PIII) Переход, вызов или возврат не может выполниться в первый такт после предыдущего перехода, вызова или возврата. Поэтому последовательные переходы занимают по два такта на переход, и вы можете захотеть убедиться, что у процессора есть чем еще заняться. В силу определенных причин цикл требует не менее двух тактов на итерацию на этих процессорах. 22.2.17 Проектирование предсказуемых переходв (PMMX, PPro, PII и PIII)

Многоветвенные переходы (реализующие высокоуровневые выражения switch/case) реализуются как список адресов переходов или как дерево инструкций переходов. Так как косвенные переходы предсказываются плохо, то последний метод может быть более предпочтителен, если дерево будет представлено в виде хорошо предсказуемой последовательности и у вас есть достаточное количество элементов BTB. В случае, если решите использовать предыдущий метод, рекомендуется, чтобы адреса переходов были помещены в сегмент данных.

Вы можете захотеть реорганизовать ваш код так, чтобы последовательности переходов, которые не предсказываются совершенно, были заменены другими последовательностями. Предположите, например, цикл, который выполняется 20 раз. Условный переход внизу цикла выполнится 19 раз и нет - каждый 20 раз. Эта последовательность регулярна, но не будет узнана механизмом распознавания последовательностей, поэтому невыполнение данной инструкции будет всегда предсказываться неправильно. Вы можете сделать два вложенных цикла по 4 и 5 повторений или развернуть цикл в четыре раза и позволить ему выполниться 5 раз, чтобы были только распознаваемые последовательности. Этот вид сложных схем оправдывает себя только на PPro, PII и PIII, где неверное предсказание стоит слишком дорого. Для циклов с большим количеством повторения особо смысла бороться с одним неправильным предсказанием нет.

22.3. Избегание переходов (все процессоры)

Есть много причин, почему вы можете захотеть снизить количество переходов, вызовов и возвратов:

• неверные предсказания стоят очень дорого

• в зависимости от процессора могут возникнуть различные потери при последовательных вызовах

• инструкции перехода могут выталкивать друг друга из буфера переходов

• возврат занимает 2 такта на PPlain и PMMX, вызовы и возвраты генерируют 4 мопа на PPro, PII и PIII.

• На PPro, PII и PIII доставка инструкций может быть задержена после перехода (глава 15), а вывод из обращения может быть менее эффективным для совершенных переходов, чем для других мопов (глава 18).

Вызовы и возвраты можно избежать, если заменить маленькие процедуры макросами. Во многих случаях можно снизить количество переходов, перегруппировав ваш код. Например, переход на переход можно заменить переходом к конечной цели. В некоторых случаях это возможно сделать даже с условными переходами, если условие то же самое или известно. Переход на возврат можно заменить возвратом. Если вы хотите устранить возврат на возврат, тогда вы не должны манипулировать стековым указателем, потому что это будет создавать помехи механизму предсказания, основывающимся на RSP. Вместо этого вы можете заменить предыдущий вызов на переход. Например 'CALL PRO1 / RET' можно заменить на 'JMP PRO1', если PRO1 заканчивается тем же видом RET.

Вы можете также устранить переходом, дублируя код, на который совершается переход. Это может быть полезным, если у вас есть двухнаправленная ветвь внутри цикла или до возврата.

Пример:

Переход на C можно устранить, продублировав эпилог цикла:

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

22.4. Избегание условных переходов, используя флаги (все процессоры)

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

(На PPlain и PMMX используйте 'MOV EDX,EAX / SAR EDX,31' вместо CDQ).

Флаг переноса особенно полезен для подобных трюков:

• Установка флага переноса, если значение равно нулю: CMP [VALUE],1

• Установка флага переноса, если значение не равно нулю: XOR EAX,EAX / CMP EAX,[VALUE]

• Повышение счетчика на 1, если установлен флаг переноса: ADC EAX,0

• Установка бита каждый раз, когда установлен флаг переноса: RCL EAX,1

• Генерация битовой маски, если установлен флаг переноса: SBB EAX,EAX

• Установка бита при определенном условии: SETcond AL

• Установка всех бит при определенном условии: XOR EAX,EAX / SETNcond AL / DEC EAX (помните о том, что в последнем примере условие должно быть сформулировано наоборот).

Следующий пример находит меньшее из двух беззнаковых чисел: if (b < a) a = b

А вот пример, как выбрать между двумя числами: if (a != 0) a = b; else a = c;

Стоит или нет применять подобные трюки зависит от того, насколько предсказумы условные переходы, есть или нет возможности под спариванию инструкций, есть или нет рядом другие переходы, из-за которых могут возникнуть потери.

22.5. Замена условных переходов услоными перемещениями (PPro, PII и PIII)

У процессоров PPro, PII и PIII есть инструкции условного перемещения данных, созданных специально для избежания переходов, потому что неверное предсказание перехода стоит на этих процессорах слишком дорого. Есть инструкции условного перемещения данных и для целочисленных регистров и для регистров плавающей запятой. В коде, который будет выполняться только на этих процессорах, вы можете заменить плохо предсказуемые переходы инструкциями условного перемещения там, где это возможно. Если вы хотите, чтобы ваш код выполнялся на всех процессорах, вы можете сделать две версии самого критичного кода, одну для процессоров, которые поддерживают инструкции условного перемещния и одну для тех, которые не поддерживаются (смотрите главу 27.10, чтобы узнать, как определить, поддерживает ли процессор условные переходы).

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

32-х битный код обычно больше, чем 16 битный код, потому что адреса и константы занимают 4 байта в 32-х битном режиме, а 16-ти битном режиме только два. Тем не менее, 16-ти битный код другие потери, такие как префиксы и проблемы с соседнеми словами памяти (смотри главу 10.2). Некоторые другие методы для уменьшения размера кода обсуждаются ниже.

Оба адреса перехода, адреса данных и константы занимают меньше места, если их значение находится между -128 до +127.

Для адресов переходов это означает, что короткие переходы занимают два байта, в то время как переходы более чем 127 байт занимают 5 байтов, если переход безусловный и 6 байтов, если условный.

Таким же образом адреса данных занимают меньше места, если они могут быть выраженны как указатель в интервале от -128 до +127

Пример:

Уменьшаем размер:

Преимущество использования указателя становится еще более очевидным, если вы используете его много раз. Хранение данных в стеке и использование EBP или ESP в качестве указателя сделает ваш код меньше, чем если бы вы использовали абсолютные адреса, если только, конечно, ваши данные в пределах +/-127 байтах указателя. Использование PUSH и POP для записи и чтения временных данных еще короче.

Константы могут также занимать меньше места, если они между -128 и +127. Большинство инструкций с числовыми операндами имеют короткую форму, где операнд - это один байт со знаком.

Примеры:

Самая важная инструкция с числовым операндом, у которой нет короткой формы, это MOV.

Примеры:

Можно заменить на:

И

Можно заменить на:

или:

И

Можно заменить на:

Если один и тот же адрес или константа используется несколько раз, вы можете загрузить ее в регистр. MOV с 4-х байтным числовым операндом иногда можно заменить на арфметическую инструкцию, если известно значение регистра до MOV.

Пример:

Предполагая, что mem1 и mem3 находятся в пределах -128/127 байтов от em2, это можно изменить на:

Остерегайтесь задержек AGI в инструкции LEA (для PPlain и PMMX).

Также стоит учитывать то, что разные инструкции имеют разную длину. Следующие инструкции занимают только один байт и поэтому очень привлекательны: PUSH reg, POP reg, INC reg32, DEC reg32. INC и DEC с 8-ми битовыми регистрами занимают 2 байта, поэтому 'INC EAX' короче, чем 'INC AL'.

'XCHG EAX,reg' также однобайтовая инструкция и поэтому занимает меньше места, чем 'MOV EAX,reg', но это медленнее.

Некоторые инструкции занимают на один байт меньше, когда они используют аккумулятор, а не другой регистр.

Пример:

Инструкции с указателями занимают на один байт меньше, чем когда они используют адресацию по базе (не ESP) со сдвигом, а не косвенную адресацию с масштабированием, или и то, и другое вместе, или ESP в качестве базы.

Примеры:

Инструкции с EBP в качестве базы без смещения занимают на один байто больше, чем при использовании других регистров:

Также адресация со сдвигом бывает выгоднее, чем адресация с масштабированием:

• первая инструкция (выполняющаяся в U-конвеере) должна быть FLD, FADD, FSUB, FMUL, FDIV, FCOM, FCHS или FABS.

• вторая инструкция (в V-конвеере) должна быть FXCH.

• инструкция, следующая за FXCH, должна быть инструкцией плавающей запятой, иначе FXCH спарится несовершенно и займет лишний такт.

Это особенное спаривание играет важную роль, что вкратце будет объяснено.

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

Пример:

Очевидно, что выполнение двух инструкциий не может пересекаться, если второй инструкции нужен результат первой. Так как почти все инструкции плавающей запятой работают с вершиной стека регистров ST(0), возможностей сделать их независимыми друг от друга не очень много. Решение этой проблемы состоит в переименовании регистров. Инструкция FXCH в реальности не обменивает содержимое двух регистров, оно только меняет их имена. Инструкции, которые помещают или извлекают значение из стека регистров также работают с помощью переименования. Переименование регистров на Pentium настолько хорошо оптимизировано, что можно переименовать использующийся регистр. Переименование регистров никогда не вызывает задержек - возможно даже переименовать регистр более чем один раз за такт, например, когда вы спариваете FLD или FCOMPP с FXCH.

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

Пример:

В вышеприведенном примере мы создали три независимые ветви. Каждый FADD занимает 3 такта, поэтому мы можем каждый такт начинать выполнение нового FADD. Когда мы начали выполнение ветви 'a', у нас есть время, чтобы начать выполнение двух новых инструкций FADD в ветвях 'b' и 'c' до возвращения к ветви 'a', поэтому каждый третий FADD принадлежит той же ветви. Мы используем инструкции FXCH каждый раз, когда необходимо, чтобы ST(0) стал равен регистру, который принадлежит к желаемой ветви. Как вы можете видеть из примера, это образует регулярную последовательность, но уясните хорошо, что инструкции FXCH повторяются с периодом, равным двум, в то время как у ветвей период равен трем. Это может немного смущать, поэтому вам следует проработать этот пример, чтобы понять где находится какой из регистров.

Все версии инструкций FADD, FSUB, FMUL и FILD занимают три такта и конвееризуются, поэтому вышеописанный метод можно применять и с этими инструкциями. Использование переменных в памяти не отнимает больше времени, чем использование регистров, если переменная в памяти находится в кэше первого уровня и правильно выравнена.

Вы уже, наверное, что у всех правил есть исключения, и у вышеизложенного они тоже есть: вы не можете начать выполнение инструкции FMUL на следующий такт после другой инструкции FMUL, потому что FMUL не может спариваться совершенно. Рекомендуется, чтобы вы поместили другую инструкцию между двумя FMUL'ами.

Пример:

Здесь у вас есть задержка между FMUL [b2] и между FMUL [c2], потому что другая FMUL началась в предыдущий такт. Вы можете улучшить этот код, поместив инструкции FLD между FMUL'ами.

В других случаях вы можете поместить FADD, FSUB или что-нибудь еще между FMUL'ами, чтобы избежать задержек.

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

Здесь у нас есть задержка в один такт перед FADD [f], потому что она ожидает результата выполнения FADD [d] и задержка в два такта перед последним FADD, потому что она ожидает результата FADD [f]. Более поздняя задержка может быть спрятана путем заполнения ее несколько целочисленными инструкциями, но с первой задержкой это не получится, так как целочисленная инструкция в этом месте приведет к тому, что FXCH будет спариваться несовершенно.

Первую задержку можно избежать, создав три ветви вместо двух, но это будет стоить дополнительно FLD, поэтому мы ничего не выиграем, прибегнув к этому варианту, если только у нас нет восьми чисел, которые нужно сложить.

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

Пример:

Первый FXCH спаривается с FDIV, но занимает дополнительный такт, потому что за ней не следует инструкция плавающей запятой. Пара SHR / INC начинает свое выполнение до того, как будет закончено выполнение FDIV, но была вынуждена подождать, пока свое выполнение закончит FXCH.

Если у вас нет ничего, что поместить после инструкции плавающей запятой, которая может выполняться одновременно с целочисленной инструкцией, (FDIV, FSQRT), вы можете поместить чтение значение из какой-нибудь переменной в памяти, которое может вам понадобиться в дальнейшем, чтобы она на 100% была в кэше.

Пример:

Здесь мы загружаем загружаем значение в [ESI] в кэш, в то время как FDIV вычисляется (результат самой операции сравнения нам не важен).

В главе 28 приведен полный список инструкций плавающей запятой, и с чем они могут спариваться.

Никаких потерь при использовании переменных в памяти в инструкциях плавающей запятой, потому что модуль арифметических вычислений на один шаг дальше в конвеере, чем модуль чтения. Однако при сохранении данных может случиться задержка, аналогичная задержке AGI: выполнение инструкции FST или FSTP с переменной в памяти в качестве операнда занимает два такта, но данные должны быть готовы в предыдущем такте, поэтому будет задержка в один такт, если значение, которое нужно сохранить не будет готово еще в предыдущем такте.

Пример:

FSTP задерживается на один такт, потому что результат FADD не был готов в предыдущем такте. Во многих случаях вы не можете скрыть этот тип задержек бзе организования вашего кода с плавающей запятой в четыре ветви или помещения внутрь каких-то целочисленных инструкций. Два такта на стадии выполнения инструкции FST(P) не могут спариваться или пересекаться с любой другой последующей инструкцией.

Инструкции с целочисленными операндами, такими как FIADD, FISUB, FIMUL, FIDIV, FICOM можно разделить на простые операции, чтобы улучшить пересекаемость выполнений инструкций.

Пример:

Разделить на:

В этом примере вы экономите два такта, пересекая выполнение двух инструкций FILD.

Во всех следующих примерах предполагается, что все данные находятся в кэше первого уровня. Если скорость ограничивается из-за того, что данные загружаются в кэш, нет никакого смысла оптимизировать инструкции. Лучше сконцентрируйтесь на правильной организации данных (глава 7).

25.1 Циклы в PPlain и PMMX

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

Эта процедура на C может выглядеть так:

Переводя ее на ассемблер мы могли бы написать эту процедуру следующим образом:

Пример 1.1:

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

Использование только спариваемых инструкций (PPlain и PMMX)

Пример 1.2:

Здесь мы используем только спариваемые инструкции, и так их располагаем, что они все спариваются. Теперь они занимают только 4 такта за итерацию. Мы можем получить ту же самую скорость не разделяя инструкцию NEG, но другие неспариваемые инструкции все же стоит разделить.

Использования одного регистра как счетчика и индекса

Пример 1.3:

Использование одного регистра как счетчика и индеска уменьшает количество инструкций в теле цикла, но он по-прежнему занимает 4 такта, так как у нас две неспариваемые инструкции.

Пусть конечное значение счетчика равняется нулю (PPlain и PMMX)

Мы хотим избавиться от инструкции CMP в примере 1.3, сделав так, чтобы последнее значение счетчика равнялось нулю, и использовать флаг нуля как знак того, что цикл закончен (как мы сделали в примере 1.2). Один вариант заключается в том, чтобы исполнить цикл задом наперед, взяв последний элемент первым. Тем не менее, кэш данных оптимизирован для получения последних в прямом порядке, а не в обратном, поэтому если вероятны промахи кэша, вам следует задать значение счетчика -N и повышать его значение до нуля. Базовые регистры тогда должны указывать на конец массива, а не на его начало:

Пример 1.4:

Однако цикл по-прежнему занимает 4 такта из-за плохой спариваемости. (Если адреса и размеры массива являются константами, мы можем сохранить два регистра). Теперь давайте посмотрим, как мы можем улучшить спариваемость.

Спаривание вычислений в цикле (PPlain и PMMX)

Мы можем улучшить спаривание, перемешав инструкции вычисления с инструкциями управления циклом. Если мы хотим поместить что-нибудь между 'INC ECX' и 'JNZ L1', это должно быть что-нибудь, что не влияет на флаг нуля. Инструкция 'MOV [EDI+4*ECX],EBX после 'INC ECX' сгенерирует задержку AGI, поэтому нам придется нужно быть более искусными:

Пример 1.5:

Здесь я использовал другой способ, чтобы посчитать отрицательное значение EAX: инвертирование всех битов и добавление еще одного. Причина, по которой я задействовал этот метод состоит в том, что я могу использовать хитрый трюк с инструкцией INC: INC не изменяет флаг переноса, в то время как ADD это делает. Я использую ADD вместо INC, чтобы повышать счетчик цикла и проверяю флаг переноса, а не флаг нуля. Тогда можно поместить 'INC EAX' между ними без вреда для флага переноса. Возможно вы подумали, что можно было бы использовать 'LEA EAX,[EAX+1]' вместо 'INC EAX', по крайней мере он не меняет никаких флагов, но инструкция LEA сгенерирует задержку AGI, поэтому это не лучшее решение. Обратите внимание, что трюк с инструкцией INC, которая не меняет флаг переноса, будет полезен только на PPlain и PMMX, так как на PPro, PII и PIII будут сгенерированы частичные задержки регистра флагов.

Здесь мне удалось добиться совершенного спаривания, и цикл теперь занимает только 3 такта. Хотите ли вы повышать значение счетчика цикла на 1 (как в примере 1.4) или на 4 (как в примере 1.5) - это дело вкуса, никакого влияния на время выполнения цикла это не окажет.

Пересечение времени выполнения одной операции с другой (PPlain и PMMX)

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

Пример 1.6:

Здесь мы начинаем считывать второе значение до того, как сохранили первое, и это, конечно, улучшает возможности к спариванию. Инструкция 'MOV EBX,0' была помещена между 'INC ECX' и 'JNZ L1' не для того, чтобы улучшить спаривание, а для того, чтобы избежать задержку AGI.

Разворачивание цикла (PPlain и PMMX)

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

Пример 1.7:

Теперь мы делаем две операции одновременно, что приводит к лучшему спариванию. Нам приходится тестировать N на нечетность, и если оно нечетно, то делаем дополнительную операцию вне цикла, потому что внутри него мы можем сделать только четное количество операций.

В цикле есть задержка AGI, генерируемая первой инструкцией MOV, потому что ECX повышается на 1 в предыдущем такте, поэтому для двух операций цикл занимает 6 тактов.

Реорганизация цикла для удаления задержки AGI (PPlain и PMMX)

Пример 1.8:

Трюк заключается в том, что найти пару инструкций, которые не используют счетчик цикла в качестве индекса, и реорганизовать цикл так, чтобы счетчик повышал свое значение в предыдущем такте. Сейчас мы близки к 5 тактам для двух операций, что близко к самому лучшему варианту.

Если кэширование данных критично, тогда вы можете улучшить скорость, соединив массивы A и B в один массив, так чтобы каждый B[i] находился непосредственно за соответствующим A[i]. Если структурированный массив выровнен по крайней мере на 8, тогда B[i] всегда будет находится в той же линии кэша, что и A[i], поэтому будет всегда случаться промах кэша при записи в B[i]. Это, конечно, может сглаживаться приростом производительности в других частях программы, поэтому вы должны взвесить все за и против.

Разворачивание более чем на 2 (PPlain и PMMX)

Вы можете прикинуть возможность более чем двух операций за одно повторение, чтобы снизить количество действий, необходимых для организации цикла. Но так как в большинстве случаев время, требуемое для выполнения таких действий, можно снизить только на один такт, то разворачивание цикла в четыре раза, а не в два, сохранит только 1/4 такта на операцию, что вряд ли стоит усилий, которые будут на это потрачены. Только если можно сохранить еще больше, и если N очень велико, вам стоит думать о разворачивании цикла в четыре раза.

Недостатки слишком большого разворачивания цикла следующие:

• Вам будет необходимо посчитать N MODULO R, где R - это коэффициент разворачивания, и сделать N MODULO R операций до или после основного цикла, чтобы выполнить недостающее количество операций. На это уйдет дополнительный код и плохо предсказуемые операции условного перехоа. И, конечно, тело цикла станет больше.

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

• Значительное увеличение кода делает работу с кэшем менее эффективной.

Одновременная обработка нескольких 8-ми или 16-ти битных операндов в 32-х битных регистра (PPlain и PMMX)

Если вам нужно обрабатывать массивы, состоящие из 8-ми или 16-ти битных операндов, тогда у вас появятся проблемы с развернутыми циклами, потому что вы не сможете спарить две операции доступа к памяти. Например, 'MOV AL,[ESI] / MOV BL,[ESI+1]' не будут спариваться, так как оба операнда находятся внутри одного и того же двойного слова памяти. Но есть продвинутый способ обрабатывать сразу два байта за раз в одном 32-х битном регистре.

Следующий пример добавляет 2 ко всем элементам массива байтов:

Пример 1.9:

Этот цикл занимает 5 тактов для каждых 4 байт. Массив, разумеется, должен быть выравнен на 4. Если количество элементов в массиве не кратно четырем, тогда вы можете добавить в конец несколько байтов, чтобы сделать его делимым на четыре. Этот цикл будет читать за концом массива, поэтому вам нужно убедиться, что тот не находится в конце сегмента, дабы избежать ошибки общей защиты.

Обратите внимание, что перед прибавлением я "спрятал" наивысший бит каждого байта, чтобы не испортить их значение (если результат сложения для конкретного байта превысит 256). Я использую XOR, а не ADD, когда помещаю последний бит на место по той же самой причине.

Инструкция 'ADD ESI,4' можно избежать, если использовать счетчик цикла в качестве индекса, как это сделано в примере 1.4. Тем не менее, в результате количество инструкций в цикле будет нечетно, а значит одна инструкция будет не спарена, и цикл по-прежнему займет 5 тактов. Делая инструкцию перехода неспаренной сохранит один такт после последней операции, если инструкция была предсказана неверно, но нам придется потратить дополнительный такт в коде пролога, чтобы установить указатель в конец массива и высчитать -N, поэтому эти два метода будут одинакого быстры. Метод, представленный здесь, является самым простым и самым коротким.

Следующий пример находит длину строки, заканчивающейся нулем, путем поиска первого байта, равного нулю. Он быстрее, чем использовать REP SCASB:

Пример 1.10:

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

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

Инструкция 'TEST ECX,00008080H' неспариваема. Вы можете использовать здесь спариваемую инструкцию 'OR CH,CL' вместо нее, но тогда вам придется поместить NOP или что-нибудь еще, чтобы избежать потерь из-за последовательных инструкций перехода. Другая проблема с 'OR CH,CL' состоит в том, что она вызовет частичную задержку регистра на PPro, PII или PIII. Поэтому я выбрал использование неспариваемой инструкции TEST.

Обработка 4-х байт за раз может быть довольно сложной. Код использует формулу, которая генерирует ненулевое значение для байт только тогда, когда байт равен нулю. Это делает возможным протестировать все четыре байта за одну операцию. Этот алгоритм включает вычитание 1 из всех байтов (в инструкции LEA). Я не стал "прятать" наивысший бит перед вычитанием, как я сделал это в предыдущем примере, поэтому операция вычитания может испортить значение следующего байта в EAX, но только если текущий равен нулю, и нам не важно, что будет со следующим байтом. Если бы мы искали нулевой байт в обратном порядке, нам бы пришлось считать двойное слово повторно после обнаружения нуля, а затем протестировать все четыре байта, чтобы найти последний ноль, или использовать BSWAP для изменения порядка байтов.

Если вы хотите найти байт с другим, ненулевым значением, тогда вы можете XOR'ить все четыре байта со значением, которое вы ищете, а затем используйте метод выше для поиска нуля.

Циклы с операциями MMX (PMMX)

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

Возвращаясь к задаче добавления двух ко всем байтам в массиве, мы можем воспользоваться возможностями, предоставляемыми MMX-инструкциями:

Пример 1.11:

Инструкция сохранения помещена после инструкции управления циклом, чтобы избежать задержки сохранения.

Этот цикл занимает 4 такта, потому что инструкция PADDB не спаривается с 'ADD ESI, 8'. (Инструкция MMX с доступом к памяти не может спариваться с не-MMX инструкцией или с другой инструкцией MMX с доступом к памяти). Мы можем избавиться от 'ADD ESI, 8', используя в качестве индекса ECX, но это приведет к задержке AGI.

Так как затраты на управления циклом значительны, мы можем захотеть развернуть цикл:

Пример 1.12:

Этот развернутый цикл занимает 6 тактов на выполнение при обработке 16 байтов. Инструкции PADDB не спариваются. Две ветви перемешаны, чтобы избежать задержки сохранения.

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

Циклы с инструкциями плавающей запятой (PPlain и PMMX).

Методы оптимизации циклов с инструкциями плавающей запятой примерно те же самые, что и для циклов с целочисленными инструкциями, хотя инструкции плавающей запятой пересекаются, а не спариваются.

У нас есть следующий код языка C:

Этот кусок кода (под названием DAXPY) является ключем к решению линейных уравнений.

Пример 1.13:

Здесь мы использовали те же методы, что и в примере 1.6: использовали счетчик цикла в качестве индекса и пробег от негативных значений к нулю. Конец выполнения одной операции пересекается с началом выполнени другой.

Смешение различных инструкций плавающей запятой работает прекрасно: задержка в 2 такта между FMUL и FSUBR заполняется FSTP предыдущего результата. Задержка в 3 такта между FSUBR и FSTP заполняется инструкциями управления циклом и первые двумя инструкциями следующего повторения. Задержку AGI удалось избежать благодая чтению в первом такте после изменения индекса только тех параметров, которые от индекса не зависят.

Это решение занимает 6 тактов на операцию, и оно лучше, чем аналогичное развернутое решение от Интела!

Разворачивание циклов с инструкциями плавающей запятой (PPlain и PMMX)

Цикл DAXPY, развернутый в 3 раза, довольно сложен:

Пример 1.14:

L4:

Причина, по которой я показываю вам, как развернуть цикл в три раза, не в том, чтобы порекомендовать подобный подход, а в том, чтобы продемонстрровать, как это сложно! Будьте готовы провести значительное количество времени, отлаживая и проверяя ваш код, когда будете делать что-нибудь подобное. Есть несколько проблем, о которых нужно позаботиться: в большинстве случаев вы не сможете устранить все задержки из цикла с инструкциями плавающей запятой, развернутого менее чем на 4, если только вы не свернете его (то есть в конце цикла будут операции, выполнение которых закончится в конце следующего повторения). Последний FLD в основном цикле выше является началом первой операции в следующем повторении. Было бы соблазнительным сделать решение, которое бы считывало после конца массива, а затем бы избавлялось от лишнего значения (как в примере 1.9 и 1.10), но это не рекомендуется с инструкциями плавающей запятой, потому что чтение дополнительного значения может сгенерировать исключение ненормального значение операнда, если после массива не находится число с плавающей запятой. Чтобы избежать этого, нам приходиться совершать по крайней мере на одну операцию больше после основного цикла.

Количество операций, которое необходимо выполнить снаружи развернутого цикла, как правило будет равно N MODULE R, где N - количество операций, а R - коэффициент развернутости цикла. Но в случае со свернутым циклом, нам нужно сделать на одну операцию больше, то есть (N-1) MODULO R + 1 в силу вышеуказанных причин.

Обычно мы делаем дополнительные операции до основного цикла, но здесь мы должны сделать их после в силу двух причин: одна причина - это позаботиться об оставшемся операнде (из-за свертывания). Другая причина состоит в том, что вычисление количества дополнительных операций требует деления, если R не является степенью 2-х, а деление занимает много времени. Дополнительные операции после цикла решают эту проблему.

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

Эпилоговый код, делающий 1-3 операции, можно организовать как отдельный цикл, но это будет стоить неправильного предсказания, поэтому решение выше быстрее.

Теперь, когда я напугал вас трудностями разворачивания на 3, я покажу, насколько проще разворачивать на 4:

Пример 1.15:

Обычно довольно легко добиться отсутствия задержек в цикле, развернутом на 4, и нет нужды в свертывании последней операции. Количество дополнительных операций, которые нужно сделать за пределами основного цикла равно N MODULO 4, что можно легко посчитать без деления, просто протестировав два нижних бита в N. Дополнительные операции делаются до основного цикла, а не после, чтобы сделать обработку счетчика цикла проще.

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

В качестве основной рекомендации, я бы посоветовал, что если N велико или если сворачивание цикла без развертывания не может удалить некоторых задержек, тогда вам следует развернуть критические целочисленные циклы в два раза, а циклы с инструкциями плавающей запятой в 4 раза.

25.2 Циклы в PPro, PII и PIII

В предыдущей главе (25.1) я объяснил, как использовать свертывание и разворачивания циклов, чтобы улучшить спаривание в PPlain и PMMX. На PPro, PII и PIII нет никакой причины делать это благодяря механизму выполнения инструкций не по порядку. Но здесь есть другие проблемы, о которых надо позаботиться, связанные с границами БДИ и задержка чтения регистров.

Я выбрал те же примеры, что и в главе 25.1 для предыдущих микропроцессоров: процедура, которая считывает целые числа из массива, изменяет их знак, и сохраняет результаты в другой массив.

На C эта процедура выглядела бы так:

Переводя ее на ассемблер, нам следовало бы написать так:

Пример 2.1:

Это выглядит как довольно красивое решение, но не самое оптимальное, потому что он использует инструкции LOOP, LODSD и STOSD, которые генерируют много мопов. Одна итерация цикла занимает 6-7 тактов, если все данные находятся в кэше первого уровня. Если мы будем избегать данных инструкций, то получим следующее:

Пример 2.2:

Комментарии интерпретируются следующим образом: инструкция 'MOV EAX,[ESI]' два байта длиной, она генерирует один моп для порта 2, который читает ESI и пишет в (переименовывает) EAX. Эта информация требуется для анализирования возможных узких мест.

Давайте сначала проанализируем раскодировку инструкций (глава 14): одна из инструкций генерирует два мопа ('MOV [EDI],EAX'). Эта инструкция должна попасть в декодер D0. Есть три раскодировываемые группы в цикле, поэтому его можно раскодировать за 3 такта.

Теперь давайте посмотрим на доставку инструкций (глава 15): если границы между БДИ не дадут первым трем инструкциям раскодироваться вместе, тогда будет три раскодировываемые группы в последнем БДИ, поэтому в следующем повторении БДИ начнется с первой инструкции, там где нам нужно, и мы получим задержку только в первом повторении. Худшим вариантом будет 16-ти байтная граница и граница БДИ в одно из следующих трех инструкций. Согласно таблице, приведенной в соотвествующей главе, это сгенерирует задержку в один такт, и приведет к тому, что в следующем повторении первый БДИ будет выровнен на 16, и проблема будет повторяться каждую итерацию. В результате время доставки будет равно 4 тактам на итерацию (а не 3). Есть два пути предотвратить подобный вариант развития событий: первый метод заключается в том, чтобы контролировать расположение 16-ти байтных границ. Другой метод проще. Так как во всем цикле только 15 байт кода, вы можете избежать 16-ти байтных границ, выровняв цикл на 16, как показано выше. Тогда весь цикл будет умещаться в один БДИ, поэтому никакого дальнейшего анализа доставки инструкций не потребуется.

Третья проблема - это задержки чтения регистров (глава 16). В этом цикле не читается ни один регистр, если по крайней мере несколько тактов назад в него не была произведена запись.

Четвертый анализ - это выполнение инструкций (глава 17). Подсчитывая мопы, предназначающиеся для разных портом, мы получаем:

порт 0 или 1: 4 мопа порт 1 : 1 моп порт 2: 1 моп порт 3: 1 моп порт 4: 1 моп

Предположив, что мопы, которые могут пойти в порт 0 или 1, распределяются оптимальным образом, время выполнения будет равно 2.5 такта на итерацию.

Последний анализ, который необходимо провести, это вывод из обращения (глава 18). Так как количество мопов в цикле не кратно 3, слоты вывода из обращения не будут использоваться оптимальным образом, когда переход будет выводиться из обращения через первый слот. Время, необходимое для вывода из обращения равно количеству мопов, деленное на 3 и округленное в сторону ближайшего целого числа. Это дает 3 такта для вывода из обращения.

В заключение, цикл, представленный выше, может выполняться за 3 такта на итерацию, если код цикла выровнен на 16. Я предполагаю, что условный переход предсказывается каждый раз, кроме выхода из цикла (глава 22.2).

Использование одного и того же регистра для счетчика и индекса, последнее значение счетчика равно нулю (PPro, PII и PIII)

Пример 2.3:

Количество мопов было снижено до 6. Базовые указатели указывают на конец массивов, поэтому индекс можно увеличивать от негативных значений до нуля.

Раскодировка: в этом цикле две раскодировываемые группы, поэтому раскодировка пройдет в два такта.

Доставка инструкций:

Цикл всегда занимает по крайней мере на один такт больше, чем количество 16-ти байтных блоков. Так как в этом цикле только 11 байтов кода, можно уместить их все в один БДИ. Выровняв цикл на 16 мы будем уверены, что будет только один 16-ти байтный блок, поэтому возможно осущесвить доставку за 2 такта.

Задержки чтения регистров:

Регистры ESI и EDI прочитаны, но не модифицируются внутри цикла. Поэтому эти считывания будут осуществляться из постоянных регистров, но не в одном триплете. Регистры EAX, ECX и флаги модифицируются внутри цикла и считываются до того, как они записываются обратно, поэтому чтения постоянных регистров не будет. То есть можно сделать заключение, что задержек чтения регистров нет.

Выполнение: порт 0 or 1: 2 моп порт 1: 1 моп порт 2: 1 моп порт 3: 1 моп порт 4: 1 моп Время выполнения: 1.5 такта.

Вывод из обращения: 6 мопов = 2 такта.

Заключение: этот цикл занимает только два такта на итерацию.

Если вы используете абсолютные адреса вместо ESI и EDI, тогда цикл будет занимать 3 такта, потому что он не сможет уместиться в один 16-ти байтный блок.

Разворачивание цикла (PPro, PII и PIII)

Осуществление более чем одной операции за проход, а соответственно, и меньшего количества проходов называется разворачиванием циклов. В предыдущих процессорах вам следовало развернуть циклы, чтобы разворачивать циклы, чтобы добиться лучшего спаривания (глава 25.1). В PPro, PII и PIII это не требуется, потому что об этом заботится механизм выполнения инструкций не по порядку. Нет никакой надобности использовать два разных регистра, потому что этим занимается переименование регистров. Целью разворачивания является снижение расходов на управление циклом при каждом повторении.

Следующий пример по смыслу тот же, что и пример в 2.2, но развернутый в два разм, что означает выполнение двух операций за раз, и меньшее в два раза количество проходов.

Пример 2.4:

В примере 2.2 инструкции управления циклом (то есть изменение значений указателей и счетчика, а также переход назад) занимал 4 мопа, а 'реальная работа' занимала 4 мопа. При разворачивании цикла в два раза

Анализируя доставку инструкций в этом цикле мы увидим, что новый БДИ начинается с инструкции 'ADD ESI, 8', следовательно она пойдет в декодер D0. Поэтому цикл раскодировывается за 5 тактов, а не за 4, как нам хотелось. Мы можем решить эту проблему, заменив предыдущую инструкцию на более длинную версию.

Изменить 'MOV [EDI+4],EAX' на:

Это заставит новый БДИ начаться с длинной инструкции 'MOV [EDI+4]', поэтому время раскодировки сейчас близко к 4 тактам. Оставшаяся свободная часть конвеера может обрабатывать 3 мопа за такт, поэтому ожидаемое время выполнения равно 4 тактам или 2 тактам на операцию.

Тестирование этого решения показало, что в реальности оно занимает немного больше. Мои измерения показывают примерно 4.5 такта за итерацию. Вероятно это связано с неоптимальной перегруппировкой мопов. Возможно, ROB не смог найти оптимального порядка выполнения. Проблемы подобного рода непредсказуемы, и только тестирование может выявить их. Мы можем помочь ROB'у сделать часть перегруппировки сами:

Пример 2.5:

Цикл теперь выполняется в 4 тактах на итерацию. Также была решена проблема с БДИ. Это стоило нам дополнительного регистра, потому что мы не могли использовать преимущества переименования регистров.

Разворачивание более чем в 2 раза

Развертка циклов рекомендуется, когда инструкции по управлению циклами занимают значительную часть общего времени выполнения. В примере 2.3 они занимают только 2 мопа, поэтому выгода будет невелика, но тем не менее я покажу, как его развернуть, просто ради упражнения.

'Настоящая работа' равна 4 мопам, на управление циклом уходит 2 мопа. Развернув его, мы получим 2*4+3 = 10 мопов. Время вывода из обращения будет равно 10/3, огругляем в сторону ближайшего целого, получается 4 такта. Эти вычисления показывают, что разворачиванием мы ничего не добьемся:

Пример 2.6:

БДИ распределяются так, как нам нужно. Время раскодировки равно 6 тактам.

Задержки чтения регистров является здесь проблемой, так как ECX выводится из обращения в конце цикла, а нам нужно читать ESI, EDI и ECX. Инструкции были перегруппированы так, чтобы избежать чтения ESI рядом с концом цикла во избежания задержки чтения регистра. Другими словами причина перегруппировки инструкций и использования дополнительного регистра не та, что в предыдущем примере.

Здесь 12 мопов и цикл выполняется за 6 тактов на итерацию или 1.5 тактов на операцию.

Вы можете прикинуть возможность более чем двух операций за одно повторение, чтобы снизить количество действий, необходимых для организации цикла. Но так как в большинстве случаев время, требуемое для выполнения таких действий, можно снизить только на один такт, то разворачивание цикла в четыре раза, а не в два, сохранит только 1/4 такта на операцию, что вряд ли стоит усилий, которые будут на это потрачены. Только если можно сохранить еще больше, и если N очень велико, вам стоит думать о разворачивании цикла в четыре раза.

Недостатки слишком большого разворачивания цикла следующие:

• Вам будет необходимо посчитать N MODULO R, где R - это коэффициент разворачивания, и сделать N MODULO R операций до или после основного цикла, чтобы выполнить недостающее количество операций. На это уйдет дополнительный код и плохо предсказуемые операции условного перехоа. И, конечно, тело цикла станет больше.

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

• Значительное увеличение кода делает работу с кэшем менее эффективной.

Использование коэффициента разворачиванивания, не являющегося степенью 2 делает вычисление N MODULO R довольно трудным, и как правило не рекомендуется, если только N не кратно R. Пример 1.14 показывает, как разворачивать в 3 раза.

Обработка нескольких 8-ми или 16-ти битных операндов одновременно в 32-х битных регистрах (PPro, PII или PIII).

Иногда возможно обрабатывать четыре байта за раз в том же 32-х битном регистре. Следующий пример добавляет 2 ко всем элементам массива байтов.

Пример 2.7:

Обратите внимание, что перед прибавлением я "спрятал" наивысший бит каждого байта, чтобы не испортить их значение (если результат сложения для конкретного байта превысит 256). Я использую XOR, а не ADD, когда помещаю последний бит на место по той же самой причине.

Этот цикл в идеальном случае занимает 4 такта на итерацию, но в реальном случае он может занять немного больше из-за цепочки зависимости и трудностей с перегруппировкой. На PII и PIII вы можете это делать еще более эффективно, используя регистры MMX.

Следующий пример находит длину строки, заканчивающейся нулем. Он гораздо быстрее, чем REPNE SCASB:

Пример 2.8:

Этот цикл занимает 3 такта на каждую итерацию, тестируя 4 байта. Строка, разумеется, должна быть выравнена на 4 байта. Код может считать несколько байт из памяти, находящейся за концом строки, поэтому строка не должна находиться у конца сегмента.

Обработка 4-х байт за раз может быть довольно сложной. Код использует формулу, которая генерирует ненулевое значение для байт только тогда, когда байт равен нулю. Это делает возможным протестировать все четыре байта за одну операцию. Этот алгоритм включает вычитание 1 из всех байтов (в инструкции LEA). Я не стал "прятать" наивысший бит перед вычитанием, как я сделал это в предыдущем примере, поэтому операция вычитания может испортить значение следующего байта в EAX, но только если текущий равен нулю, и нам не важно, что будет со следующим байтом. Если бы мы искали нулевой байт в обратном порядке, нам бы пришлось считать двойное слово повторно после обнаружения нуля, а затем протестировать все четыре байта, чтобы найти последний ноль, или использовать BSWAP для изменения порядка байтов.

Если вы хотите найти байт с другим, ненулевым значением, тогда вы можете XOR'ить все четыре байта со значением, которое вы ищете, а затем используйте метод выше для поиска нуля.

Циклы с инструкциями MMX (PII и PIII)

С помощью инструкций MMX мы можем сравнивать 8 байтов за одну операцию:

Пример 2.9:

В этом цикле 7 мопов для порта 0 и 1, что дает среднее время выполнения 3.5 такта на итерацию. Тесты показали 3.8 тактов, что говорит о том, что ROB справляется с ситуацией достаточно хорошо, несмотря на цепочку зависимости, которая равна 6 мопам. Тестирование 8 байтов меньше, чем за 4 такта гораздо быстрее, чем REPNE SCASB.

Циклы с плавающими инструкциями (PPro, PII и PIII)

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

Предположите код на языке C:

Этот кусок кода (под названием DAXPY) является ключем к решению линейных уравнений.

Пример 2.10:

Цепочка зависимости длиной в 10 тактов, но цикл занимает только 4 такта на итерацию, потому что он может начать новую операцию еще до того, как выполнена предыдущая. Цель выравнивания - предотвратить 16-ти байтную границу в последнем БДИ.

Пример 2.11:

Здесь мы используем тот же самый трюк, что и в примере 2.3. В идеальном случае, этот цикл будет занимать 3 такта, но измерения говорят примерно о 3.5 в виду длинной цепочки зависимости. Разворачивание цикла сэкономило немного.

Циклы с инструкциями XMM (PIII)

Инструкции XMM на PIII позволят вам оперировать четырьмя числами с плавающей запятой одинарной точности одновременно. Операнды должны быть выравнены на 16.

Алгоритм DAXPY не очень подходит для инструкций XMM, потому что точность невелика, может не быть возможности выравнять операнды на 16, поэтому вам потребуется дополнительный код, если количество операций не кратно четырем. Тем не менее, я покажу вам код в качестве примера цикла с инструкциями XMM:

Пример 2.12:

Цикл L1 занимает 5-6 тактов на 4 операции. Инструкции с ECX были помещены до и после 'MULPS XMM0, XMM1', чтобы избежать задержки чтения регистра, которую бы сгенерировало чтение двух частей регистра XMM1 вместе с ESI и EDI в RAT. Дополнительный код после L2 заботится о ситуации, когда N не делится на 4. Обратите внимание, что этот код может прочитать несколько байтов после конца A и B. Это может задержать последнюю операцию, если в этих байтах не находились нормальные числа с плавающей запятой. Если возможно, поместите в массив какие-нибудь дополнительные данные, чтобы сделать количество операций кратным 4 и избавиться от лишнего кода после L2.

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

Пример:

Гораздо быстрее, чем

Инструкцию LEA можно использовать, чтобы делать сложение или сдвиг без изменения флагов. Источник и назначение не обязательно должны быть размером в слово, поэтому 'LEA EAX,[BX]' может стать возможной заменой для 'MOVZX EAX,BX', хотя на многих процессорах это не совсем оптимально.

Как бы то ни было, вам следует знать, что инструкция LEA вызывает задержку AGI на PPlain и PMMX, если она использует базовый или индексный регистр, в которой была произведена запись в предыдущем такте.

Так как инструкция LEA спариваема в V-конвеер на PPlain и PMMX, а инструкции сдвига - нет, вы можете использовать LEA в качестве замены SHL на 1, 2 или 3, если вы хотите, чтобы инструкция выполнялась в V-конвеере.

У 32-х битных конвееров нет документированного режима адресации с только индексным регистром, поэтому инструкция LEA EAX,[EAX2] на самом деле записывается как 'LEA EAX,[EAX2+00000000] с 4-х байтовым смещением. Вы можете снизить размер инструкции, написав 'LEA EAX,[EAX+EAX]' или, что еще лучше, 'ADD EAX,EAX'. Последний вариант не приведет к задержке AGI на PPlain и PMMX. Если случилось так, что у вас есть регистр, равный нулю (например, счетчик цикла после последнего прохода), вы можете использовать его как базовый регистр, чтобы снизить размер кода:

27.2 Деление (все процессоры) Деление отнимает очень много времени. На PPro, PII и PIII целочисленное деление занимает 19, 23 или 39 для байта, слова и двойного слова соответственно. На PPlain и PMMX беззнаковое челочисленное деление занимает приблизительно то же время, хотя деление со знаком занимает немного больше. Поэтому более предпочтительно использовать операнды маленького размера, которые не вызовут переполнения, даже если это будет стоить префикса размера операнда, и использовать по возможности беззнаковое деление. Целочисленное деление на константу (все процессоры)

Целочисленное деление на степень от двух можно сделать, сдвигая значение вправо. Деление беззнакового целого числа на 2N:

Деление целого числа со знаком на 2N:

Альтернативный SHR короче, чем 'AND if N > 7, но может попасть только в порт 0 (или U-конвеер), в то время как AND может попасть как в порт 0, так и в порт 1 (U- или V-конвеер).

Деление на константу можно сделать на обратное число. Чтобы произвести беззнаковое целочисленное деление q = x / d, вам вначале нужно посчитать число, обратное делителю, f = 2r / d, где r определяет позицию двоично-десятичной точки (точка основания системы счисления). Затем нужно умножить x на f и сдвинуть полученный результат на r позиций вправо. Максимальное значение r равно 32+b, где b равно числу двоичных цифр в d минус 1. (b - это самое большое целое число, для которого 2b <= d). Используйте r = 32+b, чтобы покрыть максильное количество возможных значений делимого x.

Этот метод требует некоторых приемов, чтобы скомпенсировать ошибки округления. Следующий алгоритм даст вам верные результаты для деления беззнакового целого чила с усечением, то есть тот же результат, что дает инструкция DIV (спасибо Terje Mathisen, который изобрел этот метод):

Пример:

Предположите, что вы хотите разделить на 5.

Дробная часть больше, чем половина: используем случай C. Округляем f вверх до 0CCCCCCCDh.

Следующий код делит EAX на 5 и возвращает результат в EDX:

После умножения EDX содержит значение, сдвинутое вправо на 32. Так как r = 34, вам нужно сдвинуть еще на 2, чтобы получить окончательный результат. Чтобы поделить на 10, вам нужно всего лишь заменить последнюю строку на 'SHR EDX,3'.

В случае B у вас будет следующее:

Этот код работает для всех значений x, кроме 0FFFFFFFFH, которое дает ноль из-за переполнения в инструкции INC. Если возможно, что x = 0FFFFFFFFH, тогда замените этот код на:

Если значение x ограничено, тогда вам следует использовать меньшее значение r, то есть меньшее количество цифр. Может быть несколько причин для того, чтобы сделать это:

• вы можете установить r = 32 и избежать 'SHR EDX,b' в конце.

• вы можете установить r = 16+b и использовать инструкции умножения, которые дают 32-х битный результат, вместо 64-х битного. Тогда можно освободить регистр EDX: IMUL EAX,0CCCDh / SHR EAX,18

• вы можете выбрать значение r, которое будет чаще приводить к случаю C, а не B, чтобы избежать инструкции 'INC EAX'.

Максимальное значение x в этих случаях равно по крайней мере 2r-b, иногда выше. Вы должны делать систематические тесты, если хотите узнать точное максимально значение x, при котором ваш код будет работать корректно.

Вы можете заменить медленную инструкцию умножения более быстрыми инструкциями, как это объяснено в главе 26.5.

Следующий пример делит EAX на 10 и возвращает результат в EAX. Я выбрал r=17, а не 19, потому что это дает код, который легче оптимизировать, и он покрывает такое же количество значений x. f = 217 / 10 = 3333h, случай B: q = (x+1)*3333h:

Проведенные тесты показываеют, что этот код работает правильно для всех значений x < 10004H.

Повторяемое деление целого цисла на одно и то же значение (все процессоры)

Если делитель не известен во время ассемблирования программы, но вы делите на одно и то же число несколько раз, вы тоже можете использовать данный метод. Код должен определить, с каким случаем (A, B и C) он имеет дело, и высчитать f до совершения делений.

Следующий далее код показывает, как делать несколько делений на одно и то же число (беззнаковое деление с усечением). Сначала вызовите SET_DIVISOR, чтобы установить делитель и обратное ему число, затем вызовите DIVIDE_FIXED для каждого значения, которое нужно разделить на один и тот же делитель.

Этот код даст тот же результат, что и инструкция DIV для 0 <= x < 232, 0 < d < 232.

Обратите внимание, что линия 'JC DOVERFL' и ее цель не нужны, если вы уверены, что x < 0FFFFFFFFH.

Если степени от 2 случаются так редко, что не стоит делать специальную оптимизацию из-за них, то вы можете убрать переход на DSHIFT и делать вместо него умножения с CORRECTION = 0 для случая A.

Если делитель меняется так часто, что процедура SET_DIVISOR нуждается в оптимизации, то вы можете заменить инструкцию BSR кодом, который приведен в главе 26.15 для процессоров PPlain и PMMX.

Деление чисел с плавающей запятой (все процессоры) Деление чисел с плавающей запятой занимает 38 или 39 тактов при самой высокой точности. Вы можете сэкономить время, указав более низкую точность в контрольном слове (на PPlain и PMMX только FDIV и FIDIV более быстры при низкой точности; на PPro, PII и PIII это также относится к FSQRT. Выполнение других инструкций убыстрить этим способом нельзя). Параллельное деление (PPlain и PMMX)

На PPlain и PMMX можно производить деление числа плавающей запятой и целочисленное деление параллельно. На PPro, PII и PIII это не возможно, потому что целочисленное деление и деление чисел с плавающей запятой используют один и тот же механизм.

Пример: A = A1 / A2; B = B1 / B2

Убедитесь, что вы установили в контрольном слове FPU желаемый метод округления.

Использование обратных инструкций для быстрого деления (PIII)

На PIII вы можете использовать быстрые обратные инструкции RCPSS или PCPPS с делителем, а затем умножить на делимое. Правда, точность будет всего 12 бит. Вы можете повысить ее до 23-х, использовав метод Ньютона-Рафсона, объясненного в интеловской сопроводительной заметке AP-803:

где x0 - это первое приближение к обратному от делителя d, а x1 - лучшее приближение. Вы должны использовать эту формулу перед умножение на делимое:

Это позволяет сделать 4 деления за 18 тактов с точностью 23 бита. Повышение точность, повторяя формулу Ньютона-Рафсона возможно, но не очень выгодно.

Если вы хотите использовать этот метод для целочисленных делений, тогда вам нужно проверять результаты на ошибки округления. Следующие код делает четыре деления с усечением на упакованных целых числах размером в слово за примерно 42 такта. Это дает точные результаты для 0 <= делимое < 7FFFFH и 0 < делитель lt;= 7FFFFH:

Этот код проверяет, не слишком ли мал результат и делает соответствующую коррекцию. Не нужно проверять, если результат слишком велик.

Избегание делений (все процессоры)

Очевидно, что вам минимизировать количество делений. Деления плавающей запятой на константу или повторяющиеся деления на одно и то же значения следуюет делать через умножения на обратное число. Но есть много других ситуаций, когда вы можете снизить количество делений. Например: if (A/B >c) можно переписать как if (A > B*C), если B положительны, и как обратное сравнение, если B отрицательны.

A/B + C/D можно переписать как (AD + CB) / (B*D)

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

27.3 Освобождение регистров FPU (все процессоры)

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

Самый быстрые способ освободить один регистр - это FSTP ST. Самый быстрый способ освбодить два регистра на PPlain и PMMX - это FCOMPP, на PPro, PII и PIII вы можете использовать как FCOMPP, так и FSTP ST дважды.

Не рекомендуется использовать FFREE.

27.4 Переход от инструкций FPU к MMX и обратно (PMMX, PII и PIII)

Вы должны выполнить инструкцию EMMS после инструкции MMX, за которой может последовать код с инструкциями FPU.

На PMMX переключение между инструкциями FPU и MMX вызывает высокие потери. Выполнение первой инструкции FPU после EMMS занимает примерно на 58 тактов больше, а первой инструкции MMX после инструкции FPU - на 38 тактов больше.

На PII и PIII подобных потерь нет. Задержку после EMMS можно скрыть, поместив целочисленные инструкции между EMMS и первой инструкции FPU.

27.5 Конвертации чисел с плавающей запятой в целые (все процессоры)

Все подобные конверсии и обратно должны осуществляться через память:

На PPro, PII и PIII этот код может вызвать потерит из-за попытки считать из [TEMP] до того, как закончена запись туда же, потому что инструкция FIST медленная (глава 17). WAIT не поможет (глава 26.6). Рекомендуется поместить другие инструкции между записью в [TEMP] и чтением оттуда, что бы избежать этих потерь. Это относится ко всем примерам, которые последуют в дальнейшем.

Спецификация языка C и C++ требует, чтобы конверсия из чисел с плавающей запятой в целые числа осуществлялась с помощью усечения, а не округления. Метод, используемый большинством библиотек C, это изменение контрольного слова FPU, чтобы указать инструкции FISTP на усечение, и изменение контрольного слова в прежнее состояние после ее выполнения. Это метод очень медленнен на всех процессорах. На PPro, PII и PIII контрольное слово FPU не может быть переименовано, поэтому все последующие инструкции плавающей запятой будут ждать, пока инструкция FLDCW не будет выведена из обращения.

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

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

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

Округление к ближайшему

Усечение к нулю

Усечение к минус бесконечности

Эти процедуры работают для -231 < x < 231-1. Они не проверяют на переполнение или NAN'ы.

У PIII есть инструкции для усечения чисел с плавающей запятой одинарной точности: CVTTSS2SI and CVTTPS2PI. Эти инструкции очень полезны, если одинарная точность вас удовлетворяет, но если вы конвертироуете число с более высокой точностью в число с одинарной точностью, чтобы использовать эти инструкции, у вас могут столкнуться с тем, что число может быть округлено вверх во время конверсии.

Альтернатива инструкции FISTP (PPlain и PMMX)

Конвертирование числа с плавающей запятой в целое обычно осуществляется следующим образом:

Альтернативный метод заключает в:

Добавление 'волшебного числа' 251+252 есть такой эффект, что любое целое число между -231 и +231 будет выравнено в нижних 32-х битах, когда сохраняется как число с плавающей запятой двойной точности. Результат будет такой же, какой бы вы получили с помощью инструкции FISTP со всеми методами окруления, кроме усечения к нулю. Результат будет отличаться от FISTP, если в контрольном слове задано усечение или в случае переполнения. Вам может потребоваться инструкция WAIT для совместимости со старым 80287 процессором (глава 26.6)

Этот метод не быстрее использования FISTP, но он дает большую гибкость на PPlain и PMMX, потому между FADD и FSTP 3 такта, которые можно заполнить другими инструкциями. Вы можете умножить или разделить число на степень от друх в той же операции, сделав обратно по отношению к магическому числу. Вы также можете добавить константу, добавив ее к магическому числу, которое тогда будет иметь двойную точность.

27.6 Использование целочисленных инструкция для осуществления операций плавающей запятой (все процессоры)

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

Пример:

Заменить на:

Тестируем, не равно ли значение с плавающей запятой нулю:

Значение с плавающей запятой, равное нулю, обычно представляется как 32 или 64 обнуленных бита, но здесь есть один подводные камень: бит знака может быть равен нулю! Минус ноль считается правильным числом с плавающей запятой, и процессор может сгенерировать ноль с уставноленным битом знака, если, например, отрицательное число было умножено на ноль. Поэтому если вы хотите узнать, не равно ли число с плавающей запятой нулю, вам не следует тестировать бит знака.

Пример:

Используйте целочисленные инструкции вместо этого и сдвиньте бит знака:

Если число с плавающей запятой имеет двойную точность (QWORD), тогда вам нужно протестировать только биты 32-62. Если они равны нулю, тогда нижняя половина будет также равна нулю, если это верное число с плавающей запятой.

Тест на то, отрицательно ли значение:

Число с плавающей запятой отрицательно, если бит знака и установлен по крайней мере один бит.

Пример:

Манипулирование битом знака:

Вы можете изменить знак числа с плавающей запятой просто инвертирововав бит знака:

Пример:

Похожим образом вы можете получить асбсолютное значение числа с плавающей запятой, просто сANDив бит знака:

Сравнивание чисел:

Числа с плавающей запятой сохраняются в особом формате, который позволяет использовать целочисленные инструкции для сравнения чисел с плавающей запятой, не считая бита знака. Если вы уверены, что оба сравниваемые числа с плавающей запятой являются правильными и положительными, вы можете простой сравнить их как целые:

Пример:

Изменить на:

Этот метод работает только, если у двух чисел одна и та же точность, и вы уверены, что ни у одного из числа не установлен бит знака.

Если возможны отрицательные числа, вы можете их сконвертировать определенным образом и сделать знаковое сравнение:

Этот метод работает для всех правильных чисел с плавающей запятой, включая -0.

27.7 Использование инструкции с плавающей запятой, чтобы осуществлять целочисленные операции (PPlain и PMMX)

Целочисленное умножение (PPlain и PMMX)

Умножение плавающей запятой быстрее, чем целочисленное умножение на PPlain и PMMX, но цена конверсии целых чисел в числа с плавающей запятой и конвертирование результата обратно в целое число очень высоко, поэтому умножение плавающей запятой имеет смысл только тогда, если количество требуемых преобразование мало сравнимо с количеством умножений. (Довольно соблазнительно использование ненормальных чисел с плавающей запятой, чтобы пропустить часть конвертаций, но обработка таких чисел очень медленна, поэтому это плохая идея!)

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

Целочисленное умножение быстрее, чем умножение с плавающей запятой на PPro, PII и PIII.

Целочисленное деление (PPlain и PMMX)

Деление плавающей запятой не быстрее, чем целочисленное деление, но вы можете делать другие целочисленные операции (включая целочисленное деление, но не целочисленное умножение), в то время как работает FPU на деление плавающей запятой (смотри пример выше).

Конвертирование двоичных чисел в десятичные (все процессоры)

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

27.8 Перемещение блоков данных (все процессоры)

Есть несколько способов перемещения блоков данных. Наиболее общий метод - это REP MOVSD, но при определенных условиях другие методы быстрее.

На PPlain и PMMX быстрее переместить 8 байтов за раз, если место назначения не находится в кэше:

Источник и место назначения должны быть выравнены на 8. Дополнительное время, используемое медленными инструкциями FILD и FISTP компенсируется тем, что вам требуется сделать в два раза меньше операций записывания. Обратите внимание, что этот метод имеет преимущество только на PPlain и PMMX и только тогда, когда место назначения не находится в кэше первого уровня. Вы не можете использовать FLD и FSTP (без I) с противоположными последовательностями битов, потому что ненормальные числа обрабатываются медленно и не гарантируется, что они останутся неизмененными.

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

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

На процессорах PPro, PII и PIII инструкция REP MOVSD особенно быстра, если соблюдены следующие условия:

• источник и назначение должны быть выравнены на 8

• направление должно быть вперед (очищен флаг направления)

• счетчик (ECX) должен быть больше или равен 64

• разность между EDI и ESI должна быть больше или равна 32

На PII быстрее использовать регистры MMX, если вышеприведенные условия не соблюдены и место назначения находится в кэше первого уровня. Цикл можно развернуть в два раза, а источник и назначение должны быть выравнены на 8.

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

В отличии от FLD, MOVAPS может обрабатывать любую пследовательность битов без всяких проблем. Помните, что источник и назначение должны быть выравнены на 16.

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

На PIII у вас также есть опция прямой записи в RAM-память без вовлечения кэша, используя инструкцию MOVNTQ или MOVNTPS. Это может быть полезным, если вы не хотите, чтобы место назначение попало в кэш. MOVNTPS чуть-чуть быстрее, чем MOVNTQ.

27.9 Самомодифицирующийся код (все процессоры)

Потери при выполнении кода сразу после того, как тот был изменен, занимают примерно 19 тактов на PPlain, 31 на PMMX и 150-300 на PPro, PII и PIII. Процессоры 80486 и более ранние требуют переход между модифицирующим и модифицируемым кодом, чтобы очистить кэш кода.

Чтобы получить разрешение на модифицирование кода в защищенное операционной системе, вам потребуется вызвать специальные системные функции: в 16-битной Windows это ChangeSelector, в 32-х битной Windows - VirtualProtect и FlushInstructionCache (или поместить код в сегмент данных).

Самомодифицирующийся код не считается хорошим тоном программирования, но можно пойти на его применение, если выигрыш в скорости значителен.

27.10 Определение типа процессора (все процессоры)

Я думаю, что теперь достаточно очевидно, что оптимальное для одного процессора может не являться таковым для другого. Вы можете сделать несколько вариантов наиболее критичных участков кода вашей программы, чтобы они выполнялись максимально быстро на любом процессоре. Однако вам потребуется определить, на каком процессоре программа выполняется в настоящий момент. Если вы используете инструкции, которые не поддерживаются всеми процессорами, т.е. условные перемещения, FCOMI, инструкции MMX и XMM), то вы можете сначала проверить, поддерживает ли процессор данные инструкции. Процедура, приведенная ниже, проверяет тип процессора и поддерживаемые им технологии.

Обратите внимание, что некоторые операционные системы не позволяют использовать инструкции XMM. Информация о том, как узнать, поддерживает ли операционная система инструкции XMM, можно найти в интеловской инструкции AP-900: "Identifying support for Streaming SIMD Extensions in the Processor and Operating System". Больше информации о идентификации процессора можно найти в инструкции AP-485: "Intel Processor Identification and the CPUID Instruction".

Если ассемблер не поддерживает инструкции MMX, XMM, условного перемещения данных, можно использовать специальные макросы (www.agner.org/assem/macros.zip)

Операнды: r = регистр, m = память, i = число, sr - сегментный регистр,

m32 = 32-х битный операнд памяти и так далее.

Такты: указанные значения являются минимальными. Промахи кэша,

невыравненность и исключения могут значительно увеличить количество

требуемых для выполнений тактов.

Спариваемость: u = спаривается в u-конвеере, v = спаривается в v-конвеере,

uv = спаривается в любом конвеере, np = не спаривается.

28.1 Целочисленные инструкции (PPlain и PMMX)

28.2 Инструкции FPU (PPlain и PMMX)

Пояснения:

Операнды: r = регистр, m = память, sr - сегментный регистр,

m32 = 32-х битный операнд памяти и так далее.

Такты: указанные значения являются минимальными. Промахи кэша,

невыравненность, ненормальные операнды и исключения могут значительно

увеличить количество требуемых для выполнений тактов.

Pairability:

• = pairable with FXCH, np = not pairable with FXCH.

Спариваемость: + = спариваемо c FXCH, np = не спариваемо с FXCH.

i-ov: пересечение времени выполнения с целочисленными инструкциями. i-ov = 4

означает, что последние четыре такта могут пересекаться с последующими

целочисленными инструкциями.

fp-ov: пересечение времени выполнения с инструкциями FPU. fp-ov = 2

означает, что последние два такта могут пересекаться с последующими

инструкциями FPU (WAIT здесь считается как инструкция FPU).

28.3 Инструкции MMX (PMMX)

Список периодов выполнения инструкций MMX не требуется, потому что они все

занимают один такт, кроме инструкций умножения MMX, которые занимают три

такта. Время выполнения инструкций умножения MMX может пересекаться и

конвееризироваться, поэтому можно добиться производительности в одно

умножение за такт.

Инструкция EMMS занимает только один такт, но первая инструкция FPU после

EMMS занимает примерно на 58 тактов больше, а первая инструкция MMX после

инструкции FPU занимает примерно на 38 тактов больше.

Нет потерь при использовании операндов памяти в инструкции MMX, потому

что арифметический модуль MMX на один шаг дальше в конвеере, чем модуль

загрузки. Но потери будут, когда вы станете сохранять данные из регистра MMX

в память или в 32-х битный регистр: данные должны быть готовы на один такт

раньше. Это аналогично инструкциям FPU.

Все инструкции MMX, кроме EMMS, спариваются в любом конвеере. Правила

спаривания для инструкций MMX объяснены в главе 10.

Операнды: r = регистр, m = память, i = число, sr = сегментный регистр, m32 = 32-х битный операнд в памяти и так далее.

Микрооперации: количество микроопераций, которые генерит инструкция для каждого порта выполнения.

• p0: порт 0: ALU и т.д.

• p1: порт 1: ALU, переходы

• p01: инструкции, которые могут попасть как в порт 0, так и в порт 1 (какой будет свободен первым)

• p2: порт 2: загрузка данных и т.д.

• p3: порт 3: генерация адреса для сохранения

• p4: порт 4: сохранение данных

Задержка:

Это задержка, которую генерирует инструкция в цепочке зависимости. (Это не то же самое, что время, потраченное в модуле выполнения. Значения могут быть неточны в тех ситуациях, когда они не могут быть измерены точно, особенно, что касается операндов в памяти). Значения являются минимальными. Промахи кэша, невыравненность и исключения могут повысить количество тактов весьма значительно. Предполагается, что операнды с плавающей запятой являются нормальными. Ненормальные числа, NAN'ы и бесконечность увеличивают задержку на 50-150 тактов, кроме перемещений XMM, перемешиваний и булевых инструкций. Переполнения FPU, потеря значимости, ненормальные или NAN-результаты дают аналогичную задержку.

Производительность: максимальная производительность для нескольких инструкций одного вида. Например, производительность в 1/2 для FMUL означает, что новая инструкция FMUL может начинать выполнение каждые 2 такта.

29.1 Целочисленные инструкции (PPro, PII и PIII)

29.2 Инструкции FPU (PPro, PII и PIII)

29.3 Инструкции MMX (PII и PIII)

29.4 Инструкции XMM (PIII)

Программа ниже полезна для измерения количества тактов, которое занимает код.

Программа выполняет код 10 раз и сохраняет 10 значений счетчика. Программу

можно использовать как в 16-ти, так и в 32-х битном режиме на PPlain и PMMX.

Подсобные инструкции до и после тестируемого кода были включены, чтобы

получить адекватные результаты на PPlain. CLD - это неспариваемая инструкция,

которая была вставлена, чтобы порядок спаривания инструкций в первый раз будет

такой же, как и во все остальные. Восемь инструкций NOP были вставлены, чтобы

предотвратить возможные префиксы в тестируемом коде, которые могли бы

раскодироваться в тени предыдущих инструкций на PPlain. Однобайтовые

инструкции использовались здесь, чтобы получить тот же порядок спаривания,

что

На PMMX вы можете захотеть вставить 'XOR EAX,EAX / CPUID' перед тестируемым

кодом, если вы хотите, чтобы FIFO-буфер инструкций был очищен или какую-нибудь

длительную инструкцию (например, CLI или AAD), если вы хотите, чтобы он был

полон (CPUID не вызывает эффекта затенения может начаться раскодировка

префиксов последующих инструкций).

На PPro, PII и PIII вы можете вставить 'XOR EAX,EAX / CPUID' до и после

каждого RDTSC, чтобы предотвратить ее возможное выполнение параллельно с

какой-нибудь другой инструкцией и убрать подсобные инструкции. (CPUID - это

синхронизирующая инструкция, что означает то, что она очищает конвеер и

ждет, пока все исполняющиеся инструкции не будут выполнены, и только тогда

выполнится сама. Это может быть полезно для тестирования.)

Инструкция RDTSC не может выполняться в виртуальном режиме на PPlain и PMMX,

поэтому если вы запускете DOS-программы, вам нужно перегрузиться в реальный

режим. (Нажмите F8 во время загрузки и выберите "safe mode command promt only"

или "bypass startup files").

Полный исходник тестовой программы доступен на www.agner.org/assem/.

У процессоров Pentium есть специальные счетчики наблюдения за качеством

работы, которые отслеживают и подсчитывают такие события как промахи кэша,

невыравненность, различные задержки. Подробности об использовании счетчиков

не затрагиваются в данном руководстве, но их можно найти в "Intel Architecture

Software Developer's Manual", vol. 3, Appendix A.

Эх, на кой ляд я написал эту статью ? Существует много подобных статей об оптимизации. Да, это пpавда, и также существует много хоpоших и кульных тутоpов [ Билли, твой док pулит! *]. Hо как вы можете видеть, не каждый автоp тутоpиала помнит, что означает теpмин "оптимизация", многие дают советы только по уменьшению кода. Есть много аспектов оптимизации и я хочу обсудить их здесь и пpодемонстpиpовать pасшиpенный взгляд на эту пpоблему.

Когда я начал писать эту статью, я был очень пьян и находился под воздействием наpкотиков (хехе), поэтому если вы чувствуете, что я сделал какую-нибудь ошибку или вы думает, что то, что здесь написано, непpавда или пpосто хотите меня поблагодаpить, вы можете найти меня на IRC UnderNet, на каналах #vir и/или #virus или написать по адpесу benny@post.cz. Спасибо за все положительные (и также отpицательные) комментаpии.

3. Введение

Как я сказал несколько секунд назад, оптимизация имеет несколько аспектов. В общем, мы оптимизиpуем наш код, чтобы он:

• был меньше

• был быстpее

• был меньше и быстpее

Хоpошо, это дает нам новую пищу для pазмышлений. Если мы оптимизиpуем наш код:

• код будет меньше, но медленнее

• код будет больше, но быстpее

• код будет меньше и быстpее

Мы должны найти компpомисс (если мы не можем сделать так, как в тpетьем пункте) между пеpвым и втоpым пунктом. Я увеpен, вы не хотите беспокоить юзеpа ухудшившимся качеством pаботы системы из-за:

• большого и неоптимизиpованного кода

• маленького, но медленного кода

или встpевожить пользователя pезким уменьшением свободного места на диске.

Вы должны pешать, какой путь избаpть. У нас есть путеводная нить:

• если наш код (или блок кода, напpимеp пpоцедуpа тpеда) маленькая, мы должны оптимизиpовать ее так, чтобы она была более быстpой

• если наш код (или блок кода) большой, мы должны найти компpомисс между скоpостью и pазмеpом

Тем не менее, мы должны оптимизиpовать наш код уменьшая его pазмеp и повышая его скоpость, но вы знаете, как это тpудно.

Вы понимаете это? Я увеpен, что вы уже знаете об этом. Hо все же есть еще много аспектов оптимизации. Возьмем для пpимеpа две инстpукции, котоpые делают одно и то же, но:

• одна инстpукция больше

• одна инстpукция меньше

• одна инстpукция меняет дpугой pегистp

• одна инстpукция пишет в память

• однак инстpукция меняет флаги

• одна инстpукция быстpее на одном пpоцесоpе, но медленнее на дpугом

Почему LODSB быстpее на 80386 и почему он занимает только один такт на Pentium? Pentium - это супеpскаляpный пpоцессоp, поддеpживающий пайплайнинг, поэтому он может запускать паpу двух целочисленных инстpукций в пайпе, то есть он может запускать эти инстpукции одновpеменно. Две инстpукции, котоpые могут быть запущены одновpеменно, называются спаpенными инстpукциями.

Хе-хе, эта статья не об аpхитектуpе пpоцессоpа Pentium, поэтому вы можете забыть слова, котоpые я вам только что сказал. Может быть попозже, если я напишу дpугую статью об оптимизации Pentium-пpоцессоpов, я объясню подpобнее, что такое пайпы, V-пайп, U-пайп, спаpивание и так далее. Сейчас вы можете забыть об этом. Только помните, что значит слово "спаpивание".

Сейчас мы шаг за шагом обсудим каждую из техник оптимизации.

4. Оптимизиpование кода Хоpошо, давайте оптимизиpовать. Я начну с самой легкой опеpации. Hачинающие, пpиготовились... 4.1. Обнуление pегистpа

Я больше не хочу видеть этого

Эта самая худшая инстpукция, котоpую я когда-либо видел. Конечно, кажется логичным, что вы пишеть в pегист ноль, но вы можете сделать более оптимизиpовано так:

или

Hа одной инстpукции сэкономлено тpи байта, пpекpасно! X-D Hо что лучше использовать, SUB или XOR ? Я пpедпочитаю XOR, потому что Micro$oft пpедпочитает SUB, а я знаю, что Windozes - меееедленная система, хе-хе. Hеет, это не настоящая пpичина. Как вы думает, что лучше (для вас) - вычесть два числа или сказать, "где 1 и 1, написать 0) ? Тепеpь вы знаете, почему я пpедпочитаю XOR (потому что я ненавижу математику X-D).

4.2. Тест на то, pавен ли pегистp нулю

Хммм, давайте посмотpим на pешение "в лоб":

[* ПРИМЕЧАHИЕ: Многие аpифметические опеpации оптимизиpованы для EAX, поэтому код, использующий этот pегистp будет быстpее и меньше. Пpимеp: CMP EAX, 12345678h (5 байт). Если я бы пpедпочел дpугой pегистp вместо EAX, инстpукция CMP была бы pавна 6 байтам *]

Аppх! Разве ноpмальный человек может сделать это ? Это 7 или 15 (!) байт для пpостого сpавнения. Hет, нет, нет, не делайте этого, а попытайтесь так:

или

Хмм, намного лучше, 4/8 байтов гоpаздо лучше, чем 7/15 байтов. Поэтому снова, что лучше, OR или TEST ? OR пpедпочитает Micro$oft, поэтому и в этот pаз я пpедпочитаю TEST |-). Тепеpь сеpьезно, TEST не пишет в pегистp (OR пишет), поэтому он лучше спаpивается, а значит, код будет более быстpым. Я надеюсь, вы все еще помните, что значит слово "спаpивание"... Если нет, пpочтите еще pаз секцию "Введение".

Тепеpь настоящее волшебство. Если вам не важно содеpжимое pегистpа ECX или неважно, где будет находится содеpжимое pегистpов (EAX и ECX), вы можете сделать так:

[* ПРИМЕЧАНИЕ: XCHG оптимизиpовано для pегистpа EAX, поэтому если XCHG будет использовать EAX, он будет на один байт длиннее.]

Пpекpасно! Мы оптимизиpовали наш код и сохpанили 4 байта.

4.3. Тест на то, pавен ли pегистp 0FFFFFFFFh

Многие API возвpащаю -1, когда вызов функции пpоваливается, поэтому важно уметь тестиpовать это значение. Я всегда бываю поpажен, когда вижу, когда кодеpы тестиpуют это значение как я сейчас:

Я ненавижу это. А сейчас посмотpим, как это можно оптимизиpовать:

Да, да, да, мы сохpанили тpи байта и сделали код быстpее ;).

4.4. Пеpеместить 0FFFFFFFFh в pегистp

Hекотоpые API тpебуют значение -1 в качестве паpаметpа. Давайте посмотpим, как мы можем сделать это:

Hаименее оптимизиpовано:

Более оптимизиpовано:

Или с таким же pезультатам (Super/29A):

Этот код очень полезен в некотоpых случая, напpимеp:

4.5. Обнулить pегистp и пеpеместить что-нибудь в нижнее слово или байт

Пpимеp неоптимизиpованного кода: ;1) xor eax, eax ;2 байта mov ax, word ptr [esi+xx] ;4 байта

386+ поддеpживает новую инстpукцию под названием MOVZX.

[* ПРИМЕЧАHИЕ: MOVZX быстpее на 386, на 486+ медленее *]

Пpимеp оптимизиpованного кода, когда мы можем сохpанить два байта:

Следующий пpимеp "уpодливого кода":

Тепеpь мы можем сохpанить ценный 1 байт X-D:

Это очень эффективно, когда вы хотите читать байты/слова из PE-заголовка. Так как вам нужно pаботать одновpеменно с байтами/словами/двойными словами, MOVZX лучше всего подходит в этом случае.

И последний пpимеp:

;5) xor eax, eax ;2 байта mov ax, bx ;3 байта

Лучше используйте этот ваpиант, котоpый сэкономит два байта:

Я использую MOVZX везде, где только возможно. Он мал и не так медленен как дpугие инстpукции.

4.6. Затолкать дpянь

Скажите мне, как вы сохpаните 50h в EAX...

Плохо:

Лучше:

Использование PUSH и POP несколько медленнее, но также и меньше. Когда опеpанд достаточно мал (1 байт длиной), push занимает 2 байта. В обpатном случае - 5 байт.

Давайте попpобуем дpугой случай. Затолкаем семь нулей в стек...

Hеоптимизиpованно:

Опимизиpовано, но все pавно многовато X-D:

Компактнее, но медленнее:

Ух ты, без всякого напpяга мы сэкономили 7 байт ;)).

А тепеpь истоpия из жизин... Вы хотите пеpеместить что-нибудь из одной пеpеменной в дpугую. Все pегистpы должны быть сохpанены. Вы, веpоятно, делаете это так:

А тепеpь, используя только стек, без pегистpов:

Это полезно, когда у вас нет свободных pегистpов. Я использую это, когда хочу сохpанить стаpую точку входа в дpугую пеpеменную...

Это сохpанит два байта. Хотя это немного медленнее, чем ноpмальные манипуляции с EAX (без его сохpанения), все же может случиться, когда вы не хотите (или не можете) использовать какой-либо pегистp.

4.7. Забавы с умножением

Скажите мне, как вы вычислите смещение последней секции, когда у вас в EAX number_of_sections-1?

Плохо:

Лучше:

Гоpаздо лучше:

Что делает IMUL ? IMUL умножает втоpой pегистp с тpетьим опеpандом и сохpаняет его в пеpвом pегистpе (EAX). Поэтому вы можете умножить 28h на EBX и сохpанить его в EAX:

Пpосто и эффективно (как в плане скоpости, так и pазмеpа). Я не хочу пpедставлять, как вы будете это делать с помощью инстpукции MUL... X-D

4.8. Стpоки в действии

Я хочу пеpепpыгнуть чеpез стену, когда вижу неоптимизиpованные опеpации со стpоками. Вот несколько подсказок, как вы можете оптимизиpовать ваш код, используя стpоковые инстpукции. Сделайте это, пожалуйста, или я сделаю это сам ! X-D

Hачнем с самого начала, как вы можете загpузить байт ?

Быстpее:

Меньше:

Я pекомендую использовать меньшую веpсию. Это однобайтовая инстpукция, котоpая делает то же самое, что и быстpая веpсия. Это быстpее на 80386, но гоpаздо медленнее на 80486+. Hа Pentium, быстpая веpсия тpебует только один такт из-за спаpивания. Тем не менее, я думаю, что лучшим pешением будет использовать меньшую веpсию.

И как вы можете загpузить слово ? Гpхм, HЕ ЗАГРУЖАЙТЕ слова, это слишком медленно в 32-х битном окpужении вpоде Win32. Hо если вы сеpьезно настpоились сделать это, вот ключ к pазгадке...

Быстpее:

Меньше:

Что насчет скоpости и pазмеpа ? Смотpи пpедыдущее описание (LODSB).

Аааах, загpузка слов тоже веселая штука. Посмотpите на это:

Быстpее:

Меньше:

Смотpи описание LODSW.

А тепеpь следующая полезность... Пеpемещаем что-нибудь откуда-нибудь куда-нибудь. Это - LODSB/LODSW/LODSD + STOSB/STOSW/STOSD. Вот пpимеp MOVSD:

Быстpее:

Меньше:

Быстpее на 486+, Меньше всегда ;).

Hаконец, я хочу сказать, что вам следует всегда использовать слова вместо байтов или слов, потому что пpоцессоp 386+ является 32-х битным. То есть вам пpоцессоp pаботает с 32-мя битами, поэтому если вы хотите pаботать с одним байтом, он вынужден загpузить двойное слово и обpезать его. Аааа, слишком много pаботы, поэтому если использование байтов/слов не является необходимым, не используйте их.

Тепеpь... как вы добеpетесь до конца стpоки ?

Вот метод JQwerty:

И метод Super'а:

Тепеpь, какой из них лучший ? Хммм, тpудно сказать... X-D Hа 80386+ будет выполняться быстpее метод Super'а, но на Pentium'е метод Jacky будет быстpее из-за спаpивания. Хе-хе, оба способа занимают одинаковое количество места, поэтому выбиpайте, какой вы хотите использовать... |-)

4.9. Сложная аpифметика

Тепеpь моя любимая тема. К сожалению, эта пpекpасная техника не нашла пpименения у VX-кодеpов. Тем не менее, инстpукции, о котоpых я хочу pассказать хоpошо известны (хех, но никто не знает, как их можно использовать), очень малы и очень быстpы на любом пpоцессоpе.

Вообpазите, что у вас есть таблица DWORD'ов. Указатель на таблицу находится в pегистpе EBX, индекс элемента таблицы находится в ECX. Вы хотите увеличить dword-элемент в таблице, чей индекс содеpжится в ECX (адpес элемента будет пpимеpно такой: EBX+(4*ECX)). Вы не хотите менять какой-либо pегистp.

Вы можете сделать это следующим обpазом (все так делают):

Или сделайте это лучше (никто так не делает):

Это действительно кpуто!!! Вы сохpанили пpоцессоpное вpемя (это очень быстpо), место в памяти (очень мало, как вы можете видеть) и сделали более читабельным ваш исходный код!!! Вы сохpанили 6 байтов одной пpостой инстpукцией!!!

Это не все (не все об инстpукции INC). Вообpазите дpугую ситуацию: EBX - указатель на память, ECX - индекс в таблице, вы хотите повысить следующий элемент в таблице EBX+(4*ECX)+1000h. Да, и вы хотите сохpанить все pегистpы. Вы можете сделать это сделать неоптимизиpованно:

Или очень оптимизиpованно...

Яхуууу, мы сохpанили 8 байтов одной инстpукцией (и это пpи том, что мы использовали IMUL вместо MUL), великолепно!

Эту магию можно использовать с любой аpифметической инстpукцией, а не только с INC. Вообpазите, как много места вы сможете сохpанит, если вы будете использовать эту технику вместе с ADD, SUB, ADC, SBB, INC, DEC, OR, XOR, AND и так далее.

А тепеpь пpишло вpемя для самой великой магии. Эй, паpни, скажите мне, что делает инстpукция LEA. Вы, веpоятно, знаете, что эту инстpукцию мы используем для манипуляций с пеpеменными в виpусе. Hо только некотоpые люди знают, как использовать эту инстpукцию действительно эффективно.

Инстpукция LEA pасшифpовывается как Load Effective Address. Это название несколько деклаpативно. Давайте взглянем, что действительно умеет LEA.

Сделайте следующее:

Как вы думаете, что будет EAX после выполнения этого опкода ?

Дpугой пpимеp (EBP = 1):

Что будет в pегистpе EAX ? Пpавильный ответ 12345679h. Давайте пеpеведем эту инстpукцию на "ноpмальный" язык:

Как вы можете видеть, LEA не pаботает с памятью. Она pаботает только с ее опеpандами и делает некотоpые опеpации с ними, затем она сохpаняет pезультат в пеpвый опеpанд (EAX в нашем пpимеpе). Тепеpь взглянем на pазмеp. Hевеpоятно, она делает то же самое (не совсем так, LEA сохpаняет флаги), но это коpоче. Давайте покажем всю ее магию...

5) Давайте посмотpим на неоптимизиpованный код:

6) Откpойте ваш pот и смотpите сюда:

Тепеpь закpойте ваш pот. LEA коpоче, быстpее (гоpаздо быстpее) и сохpаняет флаги. Давайте взглянем еще pаз, мы сохpаняем 5 байтов и пpоцессоpное вpемя (LEA гоpаздо быстpее на любом пpоцессоpе).

Я не буду объяснять здесь каждую аpифметическую инстpукцию, я думаю, что это не имеет смысла, потому что у них одинаковый синтаксис. Если вы хотите использовать эту технику, единственная вещь, котоpую вы должны деpжать в уме, это синтаксис:

4.10. Оптимизация дельта-смещения

Ээээх, вы веpоятно думаете, что я сумашедший. Если вы, как читатель этой статьи, не являетесь начинающим, вы должны знать, что такое дельта-смещение. Тем не менее, я видел немало VX-кодеpов, использующих дельта-смещения неэффективно. Если вы взглянете на мои пеpвые виpусы, то увидите, что я тоже так делал. И я не одинок. Давайте взглянем более подpобно..

Вот как обычно используется дельта-смещение...

Это обычный путь (но менее эффективно). Давайте взглянем, как мы можем с этим поpаботать...

Хммм, если вы взглянете на это под каким-нибудь дебуггеpом, вы увидите следующую линию:

В пеpвом поколении виpуса, pегистp EBP будет обнулен. Ок, но давайте посмотpим, что случится, если вы напишите следующее:

Хммм, удивительно. Иногда инстpукция занимет 6 байтов, в дpугой pаз 3 байта. Это ноpмально. Многие инстpукции оптимизиpуются для SHORT-значений, напpимеp SUB EBX, 3 будет 3 байта длиной. Если вы напишите SUB EBX, 1234h, инстpукция будет длиной в 6 байтов. Hе только SUB-инстpукция, также многие дpугие инстpукции.

Посмотpим, что пpоизойдет, если мы будем использовать "дpугой" путь, как получить дельта-смещение...

Всего-то! Как я и сказал, в пеpвом поколении виpуса, EBP будет обнулен (в пpедыдущей веpсии gdelta) и пеpеменная будет pавна 401000h. Это не очень хоpошо. Что вы скажете, если 401000h будет находится в EBP и повышаемое значение и будет той самой пеpеменной. Спасибо нашей новой веpсии gdelta, мы можем использовать SHORT-веpсию LEA и тем самым сохpаним 3 байта на адpесации пеpеменной. Вот пpимеp...

Ок, следующее, что мы должны сделать, это вставить все инициализиpованные пеpеменные pядом с дельта-смещением. Это действительно важно, иначе пеpеменные будут где-то далеко, поэтому не будет использоваться SHORT-веpсия LEA. Хех, вы, навеpное, думаете, что это какой-то тpюк, что есть какие-то огpаничеиня или что-нибудь в этом pоде, иначе бы все использовали это. Hе беспокойтесь, никаких огpаничений нет. Hо какого чеpта никто не использует эту технику ? Hа этот вопpос тpудно ответить. Я могу сказать, что не знаю почему. Действительно не знаю.

Мой новый виpус использует подобную обpаботку дельта-смещения, и я сэкономил огpомное количество байтов. Почему бы вам тоже не использовать этот метод ?

4.11. Дpугие способы оптимизации

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

Обнуление pегистpа EDX, если EAX меньше, чем 80000000h:

Я всегда использую CDQ вместо XOR. Почему ? Почему нет ? X-D

Сэкономим место, используя все pегистpы, вместо EBP и ESP:

Хотите получить эффект зеpкала относительно содеpжимого pегистpа?

Попpобуйте BSWAP.

Пpимеp:

Я не нашел какое-либо пpименение этой инстpукции в виpусах. Тем не менее, может быть кому-нибудь она пpигодится X-D.

Хотите сэкономить несколько байтов на отказе от CALL ?

Хех, мы сэкономили 4 байта и пpоцессоpное вpемя. Всегда замещайте call/ret инстpукцией jmp, если пpи вызове не надо помещать никаких pегистpов в стек...

Хотите выигpать немного вpемени, сpавнивая содеpжимое pегистpа и пеpеменной в памяти?

Хотите сэкономить место и пpоцессоpное вpемя во вpемя деления на число, являющееся степенью от двух?

Деление

Умножение:

Без комментаpиев...

Циклы, циклы и еще pаз циклы:

LOOP меньше, но медленее на 486+.

И следующая незабываемая вещь. Hикто в здpавом pассудке не может написать такое:

Делайте так и только так. Hичего, кpоме этого:

И снова, если опеpанд XCHG - EAX, он будет занимать 1 байт, в пpотивном случае - 2 байта. Поэтому когда вы хотите обменять ECX с EDX, XCHG будет 2 байта длиной:

Если вы только хотите пеpеместить содеpжимое одного pегистpа в дpугой, используйте пpостую инстpукцию MOV. Она лучше спаpивается под Pentium'ом и выполняется меньшее вpемя, если опеpандом не является EAX:

Hе используйте повтоpяющийся код (и код пpоцедуp):

Помните, если у вас есть любой излишний код, и это больше, чем инстpукция jmp, замещайте ею этот код. Если вы пишете свой собственный полимоpфный движок, у вас будет много возможностей сделать это. Hе упускайте их !

Манипуляции с пеpеменными:

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

И, наконец, одна недокументиpованная инстpукция. Мы назвали ее SALC (установить AL пpи пеpеносе), и она pаботает на Intel 8086+. Я пpотестиpовал ее на моем AMD K5 166MHz, и она тоже pаботает. SALC делает следующее:

Это идеально для написания полимоpфных движков. Я не думаю, что эвpистический эмулятоp знает все недокументиpованные опкоды X-D.

И это все, pебята.

5. И, наконец, несколько типов и тpюков

Здесь я дам коpоткий теоpетический обзоp наиболее важных оптимизационных техник. Вы должны помнить о них и пытаться использовать, когда используете в вашем собственном виpусе (и не только - пpим. пеpев.).

• Hасколько это возможно, избегайте использование стека и пеpеменных. Помните, что pегистpы гоpаздо быстpее, чем память (и стек, и пеpеменные в памяти!), поэтому...

• Используйте pегистpы так часто, как это возможно (используйте MOV вместо PUSH/POP)

• Попытайтесь использовать pегистp EAX так часто, как это возможно

• Убиpайте все ненужные NOP'ы, повысив число пpоходов (используйте TASM /m9)

• Hе используйте диpективу JUMPS

• Для вычисления больших выpажений используйте инстpукцию LEA

• Используйте инстpукции 486/Pentium, чтобы убыстpить код

• Hе тpахайтесь со своей сестpой !

• Hе используйте 16-ти битные pегистpы и опкоды в вашем 32-х битном коде

• Используйте стpоковые опеpации

• Hе используйте инстpукции, чтобы вычислять значения, котоpые можно вычислить с помощью пpепpоцессоpа

• Избегайте CALL'ы, если они не нужны и используйте пpямой код

• Используйте 32-х битный DEC/INC вместо 8/16-ти битные DEC/INC/SUB/ADD

• Используйте сопpоцессоp и недокументиpованные опкоды

• Деpжите в уме, что инстpукции, у котоpых нет никаких конфликтов с памятью/pегистpом могут спаpиваться, поэтому они будут выполняться минимум в два pаз быстpее на пpоцессоpе Pentium.

• Если какой-то код используется много pаз и занимает больше, чем 6 байт ("call label" и "ret" занимают 6 байт), сделайте ее пpоцедуpой и используйте вместо написания повтоpяющегося кода

• Сокpащайте использование условных пеpеходов к минимуму, их пpедсказание появилось начиная с P6+. Слишком много условных пеpеходов может затоpмозить ваш код в x-pаз. Безусловные пеpеходы - это ОК, но, тем не менее, каждый байт можно соптимизиpовать |-)

• Для аpифметических вычислений и последующих опеpаций используйте аpифметический pасшиpения инстpукций

• Уффф, я больше не знаю, что вам посоветовать. Мммм, пpочитайте это снова X-D

И это все, pебята. Давайт встpетимся где-нибудь в следующих жизнях...

6. В заключение

Уффф, хоpошо, если вы дочитали эту длинную статью. Что я хочу сказать ? Я надеюсь, что вы поняли все, что я изложил (или хотя бы 50 %), и будете использовать это в своем коде. Я знаю, я не один из тех pебят, котоpые оптимизиpуют все 100% своего кода. Тем не менее, я пытаюсь это сделать. В основном, я думаю, эта оптимизация кода можно пpоводить после того, как сделано все остальное. Эта одна из тех вещей, котоpая делает вас пpофессиональным кодеpом. Кодеp, котоpый не оптимизиpует его собственный код - это не пpофессиональный кодеp. Запомните это. Хе-хе, и снова моя любимая тема - если вам нpавится этот тутоpиал, я буду очень благодаpен вам, если вы напишите мне что-нибудь (benny@post.cz). Большое, большое спасибо.

Благодаpности: Darkman/29A, Super/29A, Jacky Qwerty/29A, GriYo/29A, VirusBust/29A, MDriler/29A, Billy_Bel/???, MrSandman и всем, кого я забыл...

Фоpмат библиотек импоpта MASM'а

MASM и Visual C++ могут использовать одинаковые библиотеки импоpта, что очень удобно. Микpософтовские библиотеки импоpта используют pазновидность фоpмата COFF, котоpое отлично от фоpмата OMF, используемого TASM'ом. По этой пpичине TASM не может использовать MASM'овские библиотеки импоpта и наобоpот. Я не буду углубляться в детали стpоения этих библиотек. Достаточно сказать, что каждая библиотека импоpта Microsoft'а содеpжит инфоpмацию о функциях из опpеделенных DLL. Эта инфоpмация включает в себя имена функций и общий pазмеp паpаметpов, пеpедаваемых функциям. Если вы пpобежитесь по kernel32.lib с помощью hex-pедактоpа, вы найдете найдете в ней следующее:

Имена функций имеют пpефикс '-'. Число, следующее за @ - это общий pазмеp паpаметpов этой функции в байтах. ExitProcess пpинимает только один паpаметp dword, поэтому это число pавно 4. Почему включается инфоpмация о pазмеpе паpаметpов? Эта инфоpмация используется MASM'ом, чтобы пpовеpить пpавильность пеpеданных функции паpаметpов, когда та вызывается с помощью ключевого слова 'invoke'. Если вы пpосто затолкаете паpаметpы в стек инстpукцией 'push' и запустите функцию инстpукцией 'call', MASM не будет пpовеpять пpавильность паpаметpов. Это пpеимущество делает невозможным создать библиотеки импоpта MASM из DLL, потому что DLL не содеpжит точной инфоpмации о pазмеpе пааpметpов, пеpедаваемых функции.

Создание библиотек импоpта MASM из DLL

Если вы готовы использовать функции с помощью 'push' и 'call', вы можете создать библиотеку импоpта из любой DLL следующим обpазом.

• Используйте dumpbin.exe, котоpая поставляется вместе с Visual C++, чтобы получить имена экспоpтиpуемой DLL функций.

• После того, как вы получили список функций, создайте модуль опpеделения файла с его помощью. Hапpимеp, если DLL содеpжит только одну функцию, GetSomeLine, напечатайте следующее:

• И сохpаните как blah.def.

• Запустите lib.exe, чтобы создать библиотеку импоpта из модуля опpеделения файла:

Вот и все. Вы получили blah.lib, котоpый можете использовать вместе с MASM, пока вам не тpебуется использовать 'invoke'.

Создание invoke'абельных библиотек импоpта

Я один из тех, кто очень неохотно использует вышепpиведенный подход. Использовать invoke гоpаздо более удобно. Это одна из пpичин, по котоpой я пpедпочитаю MASM TASM'у. Hо как было сказано pанее, пpактически невозможно создать invoke'абельную библиотеку импоpта с помощью той пpоцедуpы, что была изложена выше. Hапpимеp, вы можете pешить, что если вы измените имена функций в .def-файле, чтобы туда входило "@xx", библиотека импоpта может заpаботать как надо. Повеpьте мне. Это не будет pаботать.

Более легкий путь создать invoke'абельную бибиотеку импоpта - это использовать сам MASM. Если вы создатите DLL, то вы обнаpужите, что вместе с ней получили библиотеку импоpта, котоpая будет полностью invoke'абельна! Hаша стpатегия заключается в следующем:

• Получаем инфоpмацию об именах функций и общем pазмеpе паpаметpов.

• Создаем исходный код DLL, котоpая будет включать в себя эти функции с пpавильным числом и pазмеpом аpгументов.

• Создаем файл опpеделения модуля, в котоpом экспоpтиpуем соответствующие функции.

• Ассемблиpуем исходный asm-код как DLL-пpоект.

Вот и все. Вы получите полностью функциональную MASM'овскую библиотеку импоpта. Вышепpиведенные шаги заслуживают более подpобного объяснения.

Получение имен функций и общего pазмеpа паpаметpов

Это наиболее сложная часть пpоцесса. Если у вас есть только DLL, вам пpедстоит утомительное пpиключение. Hиже изложены несколько методов, котоpые вы можете использовать, хотя ни один из них не дает 100% гаpантию.

• Используйте Interactive Disassembler (IDA), чтобы дизассемблиpовать DLL. С помощью этого чудесного инстpумента вы можете получить полный pазмеp паpаметpов, пpинимаемых функцией. Однако это не совеpшенный способ. IDA - потpясающий дизассемблеp, но иногда только человек может pешить что есть что. Вам надо будет подумать и пpоpаботать весь листинг.

• Следите за значением указателя на стек до и после вызова всех функций в DLL. Метод состоит в следующем:

• Получить адpес функций с помощью GetProcAddress.

• Вызвать каждую функцию не пеpедавая ей никаких паpаметpов чеpез стек. Запомнить значение esp до вызова.

• Когда функция возвpатит упpавление, сpавнить значение esp после вызова с тем, что было пеpед вызовом. Логическое обоснование здесь следующее: пpи пеpедаче паpаметpов в фоpмате stdcall, функция беpет на себя ответственность соблюдения секового баланса. Разность значений esp и будет pазмеpом паpаметpов, ожидаемых функцией.

• Увы, этот метод не безупpечен. Он может не удастся в следующих обстоятельствах.

• Если функции в DLL используют дpугое соглашение пеpедачи паpаметpов, отличное от stdcall или pascal.

• Если функции не удается очистить стек, напpимеp пpи возникновении исключения.

• Если интеpесующие нас функции служат для чего-нибудь опасного, напpимеp для фоpматиpвания винта (Упаси Господь!)

• Изучите существующие пpогpаммы, котоpые используют нужную DLL. Вы можете отладить/дизассемблиpовать эти пpогpаммы, чтобы увидеть количество и pазмеp паpаметpов, пеpедаваемых фунциям в DLL. Тем не менее, если в DLL есть функции, котоpые не используются ни в одной из доступной вам пpогpамм, этот метод не будет pаботать.

Создание исходника DLL, котоpый будет содеpжать все эти функции

После того, как вы получите имена функций и pазмеp их паpаметpов, самое тpудное будет позади. Вам останется создать каpкас DLL и написать функции с такими же именами, как и в DLL. Hапpимеp, в DLL только одна функция, GetSomeLine, котоpая получает паpаметpов на 16 байт. В исходнике вы набиваете следующие линии:

Вы можете спpосить, что это такое? Пpоцедуpа, в котpой нет ни одной инстpукции? Библиотека импоpта не содеpжит никакой инфоpмации о том, что должна делать функция. Единственной ее целью является пpедоставление инфоpмации об именах функций и их паpаметpов. Поэтому нам не нужно помещать никаких инстpукций в пpоцедуpу-болванку. Все pавно мы сотpем бесполезную DLL после сбоpки. Все, что мы хотим - это помесить в исходный код инфоpмацию об именах функций и pазмеpе паpаметpов, чтобы MASM сгенеpиpовал pабочую библиотеку импоpта. Размеp каждого паpаметpа по отдельности не важен. Для вашего сведения, в настоящее вpемя MASM всегда pассматpивает каждый паpаметp как DWORD, какой бы модификатоp pазмеpа вы не поставили. Hапpимеp, мы можем сделать так:

И MASM создаст в библиотеке импоpта '_GetSomeLine@16'.

Создание файла опpеделения модуля

Это пpостой пpоцесс. Вам потpебуется этот файл, что MASM мог сгенеpиpовать DLL и библиотеку импоpта. Шаблон файла опpеделения модуля следующий:

Вам остается указать имя DLL, котоpое будет так же и именем библиотеки импоpта, а затем вставить имена функций после команды EXPORTS, по одному имени функции на каждой линии. Сохpаните файла и вы получите pабочий файл опpеделения модуля.

Ассемблиpование исходного кода как DLL-пpоекта

Последний шаг - самый пpостой. Вам потpебуются ml.exe и link.exe.

И вы получите invoke'абельную библиотеку импоpта.

Пpимеp

Сухое изложение выше может быть не до конца понятным. Я веpю в обучение чеpез действие. Поэтому я сделал пpимеp (находится в архиве wasm_files.zip: files/recovered/1018001/implibexample.zip), котоpый демонстpиpует вышеописанное. Файлы, входящие в пpимеp, следующие:

• Исходный код на ассемблеpе, котоpый содеpжит все функции в kernel32.dll (задокументиpованные).

• Файл опpеделения модуля.

• Батник, котоpый вы можете использовать для сбоpки библиотеки импоpта.

Скомпилиpовав пpимеp, вы получите kernel32.lib, котоpый вы можете использовать вместо того, котоpый пpедоставил Microsoft.

Дополнительные инстpументы Если вы хотите добавить/убpать функции из/в опpеделенную библиотеку импоpта, вы можете использовать две пpостые утилиты, написанные мной. Hапpимеp, если вы хотите добавить в kernel32.lib недокументиpованные функции, эти пpогpаммы окажутся вам полезными. Lib2Def

Она извлекает имена и соответсвующие pазмеpы из любой библиотеки импоpта. Запустите ее и она обpаботает все библиотеки, находящиеся в той же диpектоpии. У выходных файлов будет pасшиpение .icz. Их содеpжимое будет выглядеть пpимеpно так:

Если вы хотите добавить функцию, вам всего лишь нужно вставить новое имя (пpибавив к нему пpефикс '_') и суммаpный pазмеp паpаметpов. Если функция экспоpтиpуется по оpдиналу, то за именем надо поставить @xx. "xx" будет оpдиналом. Обpатите внимание, что эта пpостая утилита не пpовеpяет имена на повтоpение, потому что в некотоpых библиотека импоpта имена могут повтоpяться.

MLib

Эта утилита пpинимает файлы, генеpиpуемые Lib2Def и создает из них библиотеку импоpта. Она обpаботает все файлы с pасшиpением .icz. К вашему сведению, она паpсит линии .icz-файла и создает из них .asm и .def. Затем она вызывает ml.exe и link.exe, чтобы те сгенеpиpовали библиотеку импоpта. Файлы .obj, .asm, .exp и .dll удаляются и остается только .lib. Если этой утилите не удается сгенеpиpовать .lib-файл, пожалуйста пpовеpьте, нет ли повтоpяющихся линий в .icz-файле: это самый частый случай.

Скачайте (находится в архиве wasm_files.zip: files/recovered/1018001/implibtools.zip) эти две утилиты.

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

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

Команда без операндов. Во многих руководствах встречается макроопределение для компиляции инструкции CPUID, которую выполняют все модели микропроцессоров семейства Pentium. Ее могут компилировать только версии MASM, исполняющие директиву .586, в противном случае используется макрос, приведенный в примере 8.

Пример 8. Компиляция инструкции cpuid

Макровызовом этого определения является запись в исходном тексте программы инструкции cpuid, вместо нее в текст программы будет включена директива db 0Fh, 0A2h.

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

У микропроцессора Pentium Pro появились две группы команд условной пересылки CMOVcc и FCMOVcc. Первая группа относится к категории команд общего назначения. Инструкции второй группы исполняет процессор FPU, они применяются при программировании вычислений с плавающей точкой. В записи конкретной команды вместо маленьких букв cc подставляется мнемоническое обозначение условия, например, CMOVNE или FCMOVB.

Компилировать инструкции этих групп могут только версии MASM, начиная с 6.12 (исполняющие директиву .686), в противном случае надо применять специальные макроопределения. Мы опишем макроопределения для компиляции инструкций группы FCMOVcc. Операнды инструкций этой группы могут находиться только в числовых регистрах, что упрощает анализ и преобразование их имен.

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

В примере 9 приведены текст мета-макро определения FPIDEF и список его вызовов, содержащий имена восьми инструкций группы FCMOVcc с соответствующими им кодами операций. При вызове FPIDEF формируется и исполняется одно из 8-ми обычных макроопределений, имена которых совпадают с именем компилируемой инструкции, а параметрами являются ее (инструкции) операнды.

Пример 9. Мета-макро определения инструкций FCMOVcc

Предположим, что в тексте программы встретилась команда fcmove st, st(4). MASM ищет любые имена в своих списках зарезервированных символов и в таблицах имен, описанных в компилируемой программе. Обнаружив имя fcmove в списке, приведенном в конце текста примера 9, он формирует макровызов "fpidef fcmove, 0DAh, 0C8h". Макрос fpidef, в свою очередь, вместо OPNAME формирует и исполняет макроопределение "fcmove st, st(4)", которое компилирует команду и вставляет в текст программы директиву db 0DAh, 0CCh.

Макроопределение OPNAME проверяет имена операндов, формирует код второго операнда в переменной reg и включает в текст программы указанную выше директиву db, описывающую код команды.

Имя первого операнда проверяется сравнением с его допустимыми образцами st или st(0). Для того чтобы результат не зависел от регистра, на котором набраны буквы имени (st, ST, sT, St), сравнение выполняет директива IFDIFI (если различаются). Буква I в конце ее имени указывает на то, что перед сравнением операндов коды всех букв имен приводятся к одному регистру.

Для проверки второго операнда в переменную reg с помощью директивы SUBSTR помещается четвертый символ его имени. Если имя указано правильно, то это будет цифра от 0 до 7. Затем вторая директива SUBSTR копирует в переменную fvsym образец правильной записи имени второго операнда из списка допустимых имен. Наконец, директива IFDIFI сравнивает содержимое fvsym с именем второго операнда. При несовпадении выдается сообщение об ошибке и компиляция прекращается. В случае совпадения в текст программы вставляется код команды.

Дополнение к примеру 9. При выполнении инструкций группы FCMOVcc проверяется состояние разрядов регистра флагов EFLSGS. Обычным инструкциям FPU регистр флагов недоступен. Поэтому разработчики Pentium Pro ввели 4 новые операции, которые помещают результат сравнения операндов в разряды EFLAGS. Эти четыре инструкции имеют тот же формат, что и инструкции группы FCMOVcc. Поэтому для их компиляции можно использовать макроопределение примера 9 - просто добавьте в конец его текста следующие пять строчек:

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

Операнд в оперативной памяти. У новых двухадресных инструкций групп MMX, SSE1 и SSE2 один операнд находится в регистре mmx или xmm, а другой либо в регистре, либо в оперативной памяти. В большинстве случаев в оперативной памяти находится второй операнд, исключением являются инструкции пересылки. Они позволяют перемещать данные как из памяти в регистры, так и в обратном направлении.

Составить макроопределения для анализа и преобразования имен новых регистров mmx и xmm несложно. Намного сложнее выполнять анализ и преобразование адресов операндов, находящихся в оперативной памяти. При работе с 32-х разрядными адресами код операнда содержит переменное количество байтов, а в его мнемонической записи допускается использование арифметических и логических выражений. В качестве примера приведем три вполне корректные формы записи адресов операндов:

Очевидно, что для анализа и преобразования подобных выражений нужен разбор всех допустимых случаев, при этом текст макроопределения становится слишком большим и трудно обозримым. Пример макроса, обрабатывающего ограниченный набор способов записи адресов операндов, приведен в Интернет на моем сайте www.macro.aaanet.ru. Но и при разумных ограничениях текст макроса остается достаточно длинным, поэтому некоторые авторы выбирают другой путь. К их числу относится Агнер Фог. Разработанные им макросы для компиляции новых инструкций находятся в Интернет, на сайте www.agner.org.

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

Как уже говорилось, начиная с Pentium Pro, микропроцессоры семейства Pentium поддерживают группу CMOVcc, состоящую из 16-ти инструкций условной пересылки. При работе с версиями MASM 6.0 - 6.11 для компиляции инструкций этой группы нужно специальное макроопределение. Его текст приведен в примере 10.

Пример 10. Макроопределение для компиляции инструкций CMOVcc

Текст примера 6.10 состоит из мета-макро определения CMOVDEF и неполного списка его макровызовов с указанием имен 4-х первых инструкций группы CMOVcc и соответствующих им кодов операций.

Предположим, что в тексте программы встретилась команда "cmovb cx, [bx+2]". MASM находит имя инструкции в списке CMOVDEF и вызывает одноименное мета-макро определение с параметрами CMOVB, 42h. Оно, в свою очередь, формирует и выполняет макроопределение "cmovb cx, [bx+2]", в котором производится подмена имени компилируемой инструкции.

Для подмены взята инструкция BSF, ее исполняют микропроцессоры семейства Intel, начиная с модели 386, и могут компилировать все версии MASM, начиная с 5.1. Таким образом, реально компилируется команда "bsf cx, [bx+2]". В результате MASM получается объектный код "0F BC 4F 02". Остается заменить в этом коде содержимое второго байта (BC) на 42, т. е. сформировать код "0F 42 4F 02", соответствующий исходной команде "cmovb cx, [bx+2]"

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

1. При корректировке кода инструкции BSF в примере 10 изменяется содержимое второго байта, но в некоторых случаях, нужный байт может быть не вторым, а третьим или четвертым. Давайте разберемся, в каких случаях это происходит.

Начиная с Intel 386, микропроцессоры могут работать в 16-ти разрядном (реальном) и в 32-х разрядном (защищенном) режимах. Независимо от установленного режима у команд могут быть как 16-ти, так и 32-х разрядные операнды и адреса. Если разрядность операнда или адреса не совпадает с разрядностью установленного режима работы процессора, то у команды появляются один или два префикса. Префикс размера операнда имеет код 66h, а префикс размера адреса имеет код 67h.

При наличии префиксов текущий адрес, сохраненный в примере 10 в переменной X, не соответствует адресу начала кода операции, а содержимое адреса X+1 не является вторым байтом кода операции и его изменять нельзя. Как поступать в таких случаях?

MASM определяет разрядность режима работы микропроцессора исходя из модели памяти, указанной в директиве .MODEL. Допустимы следующие имена моделей: TINY, SMALL, COMPACT, MEDIUM, LARGE, HUGE, FLAT. Из них только модель FLAT соответствует 32-х разрядному режиму работы микропроцессора.

Если компилируемые инструкции работают только с 16-ти разрядными операндами и адресами, то вы можете выбрать любую модель, кроме FLAT. И наоборот, если инструкции работают только с 32-х разрядными операндами и адресами, то надо выбрать модель FLAT. Только при выполнении этих условий у команд отсутствуют префиксы, и макроопределение примера 10 является корректным.

Если по каким-то причинам указанное требование не выполнимо, то надо произвести предварительную компиляцию и получить листинг программы. По листингу уточняется наличие и количество префиксов перед командой BSF и вносится изменение в текст макроопределения примера 10. В зависимости от количества префиксов адрес в директиве ORG X+1 изменяется на X+2 или X+3. Ничего лучшего предложить нельзя.

2. Запись адреса операнда, находящегося в оперативной памяти, может состоять из нескольких слов или выражений, разделенных пробелами. При компиляции таких записей с применением макроопределения примера 10 будет выдано аварийное сообщение "слишком много операндов". Для того чтобы в подобных случаях не возникало аварийной ситуации, запись адреса в команде надо заключить в угловые скобки, например, <dword ptr [eax]>. Сказанное не распространяется на пробелы, используемые при записи индексных выражений, заключенных в квадратные скобки.

Следует подчеркнуть, что указанные особенности или недостатки относятся не только к примеру 10, но и ко всем макроопределениям, в которых применяется подмена компилируемой инструкции.

Условное ассемблирование. Одним из полезных приемов программирования является включение в исходный текст программы условных блоков. Так называют последовательность команд, директив или макроопределений, которые компилируются или не компилируются в зависимости от выполнения заданного условия. Мы опишем пример условного блока, но предварительно поясним его назначение.

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

Программист обычно знает номер версии MASM, с которой он работает, и самостоятельно решает вопрос о необходимости применения соответствующих макроопределений. Но если создается общедоступное макроопределение, то заранее неизвестно кто им воспользуется, и какая версия компилятора окажется в его распоряжении. В таком случае текст макроопределения целесообразно оформить в виде условного блока, перед компиляцией которого проверяется поддержка MASM конкретной группы директив. Текст начала такого блока приведен в примере 11.

В примере 6.11 проверяется поддержка MASM инструкций общего назначения, входящих в группу P6. Если вы собираетесь компилировать новые инструкции MMX, то, не изменяя версию, замените в тексте примера 6.11 директиву .686 на .mmx. При компиляции инструкций групп SSE надо изменить номер версии на 614, и вместо директивы .686 указать .xmm.

Замечание. Директивы .686, .mmx и .xmm разрешают компиляцию разных категорий инструкций микропроцессоров, поэтому их можно использовать совместно, но директива .686 должна быть указана первой. По крайней мере, так надо поступать при работе с версией MASM 6.15.

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

• пробовал на вкус акварельные "медовые" краски;

• пытался залить чернила в стержень авторучки;

• приносил домой гусениц, кормил их листьями и вылуплял бабочек.

Когда я сел за компьютер, подозрения перешли в твердую уверенность. Да, похоже, что я извращенец. Хотя все относительно - видал я таких извращенцев, по сравнению с которыми я просто … пуританин! А писать на ассемблере под WINDOWS не извращение? Молчите? И в этом молчании я слышу глас рассудка. ї А. Сапковский.

О чем эта статья? О программировании на ассемблере без компилятора, об отладчике DEBUG из стандартного пакета DOS/WINDOWS, о машинном коде и прочим смежным темам.

_ Alex FatMoon _

Как обычно пишутся программы на ассемблере? В редакторе - не суть важно, каком - набирается исходный текст, содержащий директивы ассемблера, мнемокоды инструкций, определения данных и метки. Затем вызывается компилятор - не суть важно, какой - который транслирует исходный файл в объектный. Затем линкер собирает исполняемый файл из одного или нескольких объектных модулей. Знакомая картина, не правда ли? Однако необходимо ли все это для создания работоспособной программы? Нет, конечно же. Для создания .com - файлов вполне достаточно отладчика DEBUG. Вот об этом и будет речь.

Почти любой отладчик имеет функцию транслирования мнемокодов в машинный код с возможностью записи на диск набранного блока. Поэтому в принципе эти же приемы могут быть использованы и с другими утилитами. Почему все-таки я описываю DEBUG? Он есть практически на любой машине, где установлена любая из версий MS-DOS или WINDOWS. Он прост в использовании, не требователен к ресурсам, знает почти все машинные коды и даже поддерживает инструкции сопроцессора. Он - первый друг взломщика сейвов к играм и просто хакера. И вообще - одно из лучших творений МикроСофт. Лежит он, родимый, в директории C:\DOS или C:\WINDOWS\COMMAND - даже если ваши папки называются по-другому и расположены на других дисках, найти его нетрудно. Переходим к непосредственному использованию.

Русские сначала придумывают себе препятствия, а потом их преодолевают.

_ (известный факт) _

Входите узкими вратами, ибо широки врата и просторен путь, ведущий в геену огненную.

_ (Евангелие от Матфея) _

Да, если у вас есть компилятор, использовать что-то еще нет нужды. Но представим себе, что компилятора нет. Или мы только начали изучать ассемблер и в принципе знаем мнемокоды по богатому опыту программирования на БК, Спектруме или Микроше, но о директивах имеем только общее представление. И напряженно думаем, с какими ключами запускать этот tasm? И почему tasm выдает ошибки при компиляции, хотя все написано правильно (кто бы мог подумать, что ss: mov ax, [si] на самом деле должно быть записано как mov ax, ss:[si]?). Тогда это для вас. А также если есть желание понять, как же работает компилятор и зачем он все-таки нужен. Подумав (от "DOOM") и перекрестясь (наведя перекрестье на последнего из монстров, нажав "fire primary" и выйдя из игры), приступим!

Пример программы.

Главная команда отладчика, которую будем использовать, "А" ssembly. Итак, входим в отладчик, набираем

и видим адрес ххх:0100. От нас ждут ввода инструкций. Собственно, можно набирать программу. Пример:

и готово. Однако это еще не конец. Надо скорректировать dx - 0100 туда засылается просто для того, чтобы обозначить команду. Ведь когда мы пишем:

мы еще не знаем адреса, с которого начнется строка "Hello, world!$", не так ли? Этот адрес мы узнаем только после того, как введем "ret". Итак, запоминаем в cx длину нашей программы - она равна адресу инструкции после строки, где мы нажали "Enter", чтобы выйти из режима компиляции, за вычетом 0100 - адрес, с которого начинается программа типа "COM". У меня для вышеприведенной программы получилось 016h. Значит, набираем:

А теперь корректируем адрес - строка начинается с 0108. Набираем:

Осталось сохранить программу на диске:

Вуаля! Теперь в директории, где мы находились перед вызовом отладчика, есть файл hello.com длиной в 22 байта, исправно печатающий при запуске строку "Hello, world!" и возвращающий управление ОС. Просто, не так ли? И никаких компиляторов. На самом деле в роли такового выступили мы сами - назначили строке фиктивный адрес (0100), затем заменили его на точный (0108). Вся помощь отладчика заключалась в переводе мнемокодов в машинные. Не можем же мы помнить все машинные коды!

Это кажется элементарным, не спорю. Попробуем сделать что-нибудь более сложное, и затем попытаемся оптимизировать это. То есть, обычная процедура для любой программы - сначала "рыхлый" код, от которого добиваются работоспособности, затем оптимизация. Лично я придерживаюсь именно такой тактики, и нахожу ее достаточно удобной. Для примера выведем бегущую строку на обычный текстовый экран 80*25 - разрешение, к которому все привыкли (надеюсь) в Norton Commander. Не претендуя на оригинальность, скажу, что нам потребуется две строки в качестве данных/переменных. Одна из строк будет оригиналом, а вторая - служить для хранения подстроки. Алгоритм весьма прост:

• Цикл: вырезать подстроку выбранной длины;

• переместить курсор на выбранное место на экране;

• вывести подстроку;

• сделать задержку;

• сдвинуться в строке на символ;

• если не конец строки, то продолжать цикл.

Но перед тем, как набивать в отладчике код, я несколько облегчу вам работу.

Каждый раз набивать программу в отладчике было бы очень долго и может навсегда отвратить от программирования. К счастью, в ДОС (и, в частности,("в частности" убрать) в коммандной строке Windows (согласен, переставить слово надо)) можно использовать перенаправление стандартного ввода-вывода. Как это делается? Пишем текстовый файл, например, содержащий предыдущую программу "Hello, world!", в виде:

Не забудьте пустую строку после DB(она выводит отладчик из режима ассемблирования), и не забываем поставить в конце команду выхода! Сохраняем его под именем, например, hello.dbg и пишем в командной строке:

В результате отладчик берет команды не с клавиатуры, а из файла. Вводит программу на языке ассемблера начиная с адреса 0100, и сохраняет на диск под именем hello.com. И выходит в ДОС. А что, почти обычная программа - только вместо

имеем

и еще команды в конце.

Точно также, чтобы получить красивый листинг при дизассемблировании, не обязательно делать PrintScreen после команды "u". Поскольку это наша программа и мы знаем, где находится код, а где данные, создаем файл d_hello.dbg, содержащий следующие строки:

И набираем в командной строке

Здесь мы перенаправляем как ввод (из файла d_hello.dbg), так и вывод (в файл hello.diz).

В результате получаем еще и файл hello.diz, содержащий дизассемблированную программу.

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

[прим.: Но это ещё не всё! В отличие от "простого" компилятора DEBUG может также сразу и выполнять (почти "интерпретировать") нашу "программу" (по аналогии с бейсиком), поэтому сохранять результат трансляции в отдельный файл нет необходимости - достаточно вместо команд RCX и N поставить G=100, не забыв завершить нашу программу инструкцией INT 3, если мы желаем увидеть содержимое регистров, с которым наша программа завершается. Итак, делаем следующий файл:

сохраняем это под именем ticks, даём команду DEBUG<TICKS>RESULT, и наблюдаем в файле RESULT в регистрах DX и AX значение системного таймера. Впрочем, конкретно для данного случая наша программа может быть "короче":

Использование внешнего файла и комментариев в нём также облегчает "настройку" адресов. Например, в исходном файле на месте меток можно вставить соответствующий комментарий, а в инструкциях перехода вместо имён меток будет фиктивное значение. Разумеется, в исходном файле не должно быть команды G, ведь программа ещё не завершена. Например:

После первого "прохода" (выполнения DEBUG с перенаправлением ввода-вывода) следует проанализировать вывод на наличие сообщений об ошибках. Потом следует проверить значения закомментированных меток и скопировать эти значения в соответствующие места (в данном случае значение метки top нужно вставить после инструкции loop). Теперь можно расскоментарить команду G и программа готова. :)]

Итак, набираем сразу в виде файла, чтобы потом "скомпилировать" его отладчиком.

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

• 555 - обозначил длину строки. На самом деле тут должно быть число, равное "адрес конца строки" - "адрес начала строки".

• 0200 - обозначим адрес начала строки. Мы его пока не знаем, но потом в листинге легко найдем.

• 0400 - адрес начала подстроки. Подстрока начнется сразу после конца строки. Этот адрес мы тоже пока не знаем.

• 0140 - адрес инструкции "ret". Он идет непосредственно перед строкой. И его тоже пока не знаем.

Сохраняем на диске 1К, поскольку точной длины программы опять же не знаем. Для тех, кто ввел очень длинную строку - можете сохранять не 0400h, а ff00h. Наверняка где-то в начале этого блока все-таки уместилась наша

"гигантская" программа.

Теперь загружаем в отладчик почти готовый r_string.com, и дизассемблируем, отмечая исправления, которые надо внести: строка начинается с 013ch, длина всей программы 0219h, длина строки =0319h-013ch=01ddh, адрес "ret" - 013bh. Вносим изменения - можно прямо в отладчике, можно в текстовом файле. Все должно работать. Оптимизация, очистка экрана в начале и прочее - на ваше усмотрение.

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

Блаженны больные, ибо исцелятся.

_ (почти из Библии) _

И тебя вылечат… И меня вылечат!

_ ("Иван Васильевич меняет профессию") _

Вот собственно для этого и нужен компилятор - назначить адреса меткам и переменным и правильно вставить их в машинный код. Чем больше переменных и переходов, тем сложнее написать программу в отладчике. И слава богу, что это делать не обязательно, поскольку есть компиляторы. Если же читатель достаточно безумен, чтобы попробовать самостоятельно написать довольно объемистый проект, флаг в руки. Моего терпения хватило однажды на двух-килобайтную видеодемку, и я думаю, что писать программы под ДОС, используя только debug, вполне реально. Хотя и неудобно. А вот для написания небольших скриптов и тестовых фрагментов использование DEBUG в качестве компилятора - самое оно. И, кстати, при этом автоматом решается проблема лицензионности компилятора. J

При этом надо помнить несколько вещей:

• смена сегментного регистра делается в две команды, поскольку это префикс, как и REP, LOCK и другие. То есть mov si, es:[di] записывается в виде

• переходы типа short возможны лишь в пределах 128 байт выше или ниже. Из-за этого могут быть проблемы при вводе программ вышеописанным способом.

• отладчик не выдаст ошибки, если какая-то инструкция неправильна. То есть, выдаст, но мы ее можем не увидеть, если используем перенаправленный ввод.

• некоторые машинные коды 186-го, 286-го, 386-го и выше процов к сожалению остаются для debug'а неизвестными, а именно:

• все команды, появившиеся в 486 и позднее

• все команды, использующие 32-битную адресацию и операнды

• insb / insw

• и некоторые другие.

Проблему можно решить, занося непосредственно код через

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

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

Например, определение следующего макроса позволяет сократить выражение test al,0xFF инструкцией tst:

После ключевого слова macro идет имя макроса и его содержимое внутри фигурных скобок {}. Вы можете использовать инструкцию tst в любом месте после её определения и она будет скомпилирована как test al,0xFF. Определение константы tst той величины дало бы тот же эффект, но разница в том, что имя макроса считается мнемоникой инструкции. То есть, макросы заменяются соответствующим кодом раньше, чем символические константы будут заменены их величинами. Так, если Вы определяете макрос и символическую константу с одним именем, и используете это название как мнемонику инструкции, она будет заменена содержанием макроса, но и будет заменена величиной, если символическая константа используется где-нибудь в операндах.

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

При использовании макрос stos0 будет заменен этими двумя инструкциями.

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

Когда инструкция align 4 будут найдена после определения этого макроса, она будет заменена его содержанием, и value станет равно 4, так что в результате мы получим rb (4-1) - ($+4-1) mod 4.

Если в макросе использовать инструкцию с тем же самым именем, будет использовано предыдущее значение этого имени. Таким образом, можно сделать полезное определение макроса в макросе, например:

Этот макрос расширил возможности инструкции mov, при его использовании оба аргумента могут быть сегментными регистрами. К примеру mov ds,es будут скомпилированы как push es и pop ds. В остальных случаях будет использована стандартная инструкция mov. Следующий макрос еще более расширяет возможности инструкции mov, используя предыдущий макрос:

Теперь mov может иметь три аргумента, но если опустить третий аргумент, будет использовано только два, потому что когда макросу дают меньше аргументов чем задано, недостающие аргументы будут иметь пустые величины. Когда даны все три аргумента, этот макрос станет двумя макросами предыдущего определения, так что mov es,ds,dx будет скомпилирована как push ds,pop es и mov ds,dx.

Директива purge позволяет удалить последнее определение макроса. Она используется с одним или более имен макросов разделенных запятыми. Если такого макроса не было определено, никаких ошибок не произойдет. Например, после использования mov расширенного макросами, определенными выше, Вы можете удалить синтаксис с тремя аргументами, используя директиву purge mov. Следующий purge mov удалит также синтаксис для сегментных регистров, но далее такие директивы ничего не сделают.

Если после директивы macro Вы задаете некоторую группу имен аргументов в квадратных скобках, это позволит использовать большее количество параметров для этой группы аргументов при использовании этого макроса. Любой аргумент, использованный после последнего аргумента такой группы, начнет новую группу и станет её первым аргументом. Именно поэтому после закрытия квадратной скобки нельзя определять аргументов. Содержание макроса будет обработано для каждой такой группы аргументов отдельно. Самый простой пример с одним аргументом в квадратных скобках:

Этот макрос принимает неограниченное количество аргументов, и каждый будет отдельно обработан с этими двумя инструкциями. Для примера stoschar 1,2,3 будет скомпилирован как следующие инструкции:

Есть некоторые специальные директивы, располагаемые только в определениях макросов. Директива local определяет локальные имена, которые будут заменены новыми значениями каждый раз, когда используется макрос. Она должна сопровождаться именами, отделенными запятыми. Эта директива обычно нужна для констант или меток которые макрос определяет и использует внутри себя. Например:

При использовании этого макроса метка move всегда имеет свое уникальное значение и повторение этого макроса не вызовет ошибок.

Директивы forward, reverse и common делят макрос на блоки, каждый обрабатывается после того, как обработка предыдущих закончена. Они отличаются по поведению, только если макрос позволяет множественные группы аргументов. Блок инструкций, что следует за директивой forward, будет обработан для каждой группы аргументов с первого до последнего - наподобие обычному блоку (не заданному в соответствии с любой из этих директив). Блок, который следует за директивой reverse, будет обработан для каждой группы аргумента в обратном порядке - от последнего до первого. Блок, который следует за директивой common, будет обработан только однажды, сразу для всех групп аргументов. Значение local, определенное в одном из блоков доступно во всех следующих блоках при обработке той же самой группы аргументов где оно было определено, когда оно определено в блоке common, оно доступно во всех следующих блоках независимо какая группа аргументов обрабатывается.

Вот пример макроса, который создаст таблицу адресов к строкам, заданных этими строками:

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

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

Этот макрос может использоваться для вызова процедур, использующих соглашение STDCALL, где аргументы сохраняются на стек в обратном порядке. Для примера stdcall foo, 1,2,3 будет собран как:

Если некоторое имя в макросе имеет множественные параметры (одним из аргументов, огороженных в квадратные скобки или локальным именем, определенным в блоке, следующем за директивой forward или reverse) и используется в блоке, следующем за директивой common, это имя будет заменено всеми ее величинами, отделенными запятыми. Например следующий макрос передаст все дополнительные аргументы предварительно заданному макросу stdcall:

Это может использоваться, чтобы вызывать косвенно (по указателю, находящемуся в памяти) процедуру, используя соглашение STDCALL.

Внутри макроса существует также специальный оператор #. Этот оператор связывает два имени в одно. Это может быть полезно, потому что это делается после того, как аргументы и локальные имена меняются на их настоящие значения. Следующий макрос произведет условный переход согласно аргументу cond:

К примеру jif ax,ae,10h,exit будет скомпилировано как cmp ax,10h и jae exit.

Чтобы сделать макрос, ведущий себя в зависимости от типа аргумента, когда аргументы - строки или нет, Вы может использовать факт, что ассемблер отличает напрямую указанные строки от указанных строк в численных выражениях, но не отличает численное выражение, которому предшествуют знак + от того же самого выражения без знака. Так строка, которой предшествуют + со знаком будут обрабатывать как численное выражение и не будет символически равен той же самой строке без любого знака, в то время как любая другая величина будет символически равна тому же самому выражению, которому предшествуют + знак. Вот пример макроса, использующий эту особенность:

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

Структуры

Директива struc - специальный вариант макро-директивы, которая используется, чтобы задавать структуры данных. Макрос, заданный директивой struc должен быть предварительно задан меткой (как при определении данных). Эта метка будет также содержаться в начале каждого имени, начинающегося с точки в содержании макроса.

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

Все правила относительно стандартных макрокоманд относятся и к макросам структур.

Вот пример структуры:

Например my point 7,11 определит структуру, с меткой my, содержащую две переменные: my.x с величиной 7 и my.y с величиной 11.

Следующий пример показывает, как расширить директиву db возможностью вычислить размер определенных данных:

С этим макросом msg db 'Hello!',13,10 определит также константу msg.size, равную размеру определенных данных в байтах и также дополнительную метку msg.data, которая будет указывать на данные типа байт.

Определение структур данных, к которым обращаются, используя регистры или абсолютные значения может быть сделано через директиву virtual в макросе структуры (см.??).

Директивы формата

Директива format, сопровождаемая идентификатором формата, позволяет выбирать формат выходного файла. Эта директива должна находится в начале исходного файла. Формат по умолчанию - плоский двоичный файл, также он может быть выбран командой format binary.

Директивы use16 и use32 вынуждают ассемблер компилировать 16 или 32-разрядный код, опуская установку по умолчанию для выбранного выходного формата.

Директива org устанавливает адрес, в котором как ожидается, будет работать код. Должна сопровождаться адресом.

Ниже описаны различные форматы с директивами, специфичными для этих форматов.

Формат MZ (MZ executable)

Для выбора выходного формата MZ, используйте директиву format MZ. Для этого формата по умолчанию создается 16 битный код.

Директива segment определяет новый сегмент, она должна следовать за меткой, чье значение будет именем сегмента, также можно задать use16, или use32 что определит, будет ли код в сегменте 16 или 32битным. Начало сегмента выравнивается по параграфам (16 байт). Все метки, определенные после этого будут иметь величины относительно начала сегмента.

Директива entry устанавливает точку входа для MZ файла, она должна сопровождаться дальним адресом (название сегмента, двоеточие и смещение в сегменте) точки входа.

Директива stack устанавливает стек для MZ файла. Она может сопровождаться численным выражением, определяющим размер стека, который будет создан автоматически или дальним адресом начальной кадра стека, если Вы хотите установить стек вручную. Когда стек не задан, он создается размером 4096 байт.

Директива heap должна сопровождаться 16 битной величиной, определяющей максимальный размер дополнительной кучи в параграфах (это куча в дополнение к стеку и неопределенным данным). Используйте heap 0 чтобы разместить только действительно необходимую программе память. Размер кучи по умолчанию - 65535.

Формат PE (Portable Executable)

Чтобы выбрать формат PE, используйте директиву format PE. Она может сопровождаться дополнительными типами формата: console, GUI или native оператор выбирает целевую подсистему (значение с плавающей запятой определяет версию подсистемы), DLL создает файл библиотеки. Потом может идти оператор at и численное выражение, определяющее, базу PE образа и затем произвольно on оператор, сопровождаемый строкой в кавычках, содержащей имя файла содержащего MZ заглушку для PE программы (если указанный файл не формата MZ он берется как обычный двоичный файл и конвертируется в MZ). Установка кода по умолчанию для этого формата - 32 бита.

Директива section определяет новый сегмент, за ней должна идти строка в кавычках, определяющая название сегмента за которым могут следовать один или более флагов сегментов. Возможные флаги: code, data, readable, writeable, executable, shareable и discardable. Среди флагов также могут быть определены специальные PE идентификаторы данных, чтобы создать сегмент специальные данных, доступные идентификаторы export, import, resource и fixups. Когда выбрано определение данных fixups, они создаются автоматически и не требуют дополнительной информации. Начало сегмента выравнивается по страницам (4096 байт).

Директива entry устанавливает точку входа для Portable Executable, необходимо значение точки.

Директива stack устанавливает размер стека для PE, за директивой идет значение, резервируемое под стек, произвольная величина стека может следовать через запятую. Когда стек не задан, он создается размером 4096 байт.

Директива heap задает размер кучи для PE, за директивой идет значение, резервируемое под кучу, произвольная величина стека может следовать через запятую. Когда куча не определена, она создается по умолчанию 65536 байт, когда размер кучи совершенно не установлен, она устанавливается в 0.

Директива data начинает определение специальных PE данных, она должна сопровождаться одним из идентификаторов данных (export, imort, resource или fixups) или номером записи данных в PE заголовке. Данные должны быть определены на следующих строках, заканчивающихся директивой end data. Когда выбрано определение данных fixups, они создаются автоматически и не требуют дополнительной информации.

Формат COFF (Common Object File Format)

Чтобы выбрать формат COFF, используйте format COFF или format MS COFF, если Вы хотите создать простой или Microsoft COFF файл. В этом формате код по умолчанию 32 - бит.

Директива section определяет новый сегмент, за ней должна идти строка в кавычках, определяющая название сегмента за которым могут следовать один или более флагов сегментов. Возможные флаги: code и data для обоих COFF вариантов, readable, writeable, executable, shareable и discardable только для Microsoft COFF. Начало сегмента выравнивается по страницам (4096 байт).

Директива extrn определяет внешний символ, она должна сопровождаться названием символа и опционально оператором размера, определяющим размер данных, маркированных этим символом.

Команда public объявляет существующий символ как public, он должен сопровождаться названием символа.

В этом руководстве раскрывается тема создания, использования (а главное – проектирования) макросов и макрофункций в проектах на MASM32.

Что не так важно в ЯВУ , то очень важно в программировании на ассемблере. Если выстроить по приоритетам недостатки программирования на ассемблере, то первым недостатком будет не объём строк написанного кода (как нестранно), а отсутствие средств, обеспечивающих хороший стиль написания кода.

Что значит стиль? А что значит плохой или хороший? Это можно быстро понять на простом примере.

Допустим, у вас есть процедура объёмом на несколько экранов. Вы её написали месяц назад, а теперь вам нужно несколько изменить её поведение. Для того, чтобы сделать это, вам необходимо:

1. Вспомнить её алгоритм (если забыли)

2. Вспомнить особенности реализации (у вас должны быть комментарии)

3. Вспомнить какой участок кода, чем занимается.

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

А это не так то просто, даже если исходник написан вами, в вашем неповторимом стиле.

Если этот стиль будет хорошим, вы потратите меньшее время, если бы стиль был бы плохим.

Хороший стиль программирования – это сэкономленное время, которое можно потратить на понимание, модификацию или, как это называют, сопровождение кода. Стиль программирования – это архитектура исходного кода – не только его внешнее оформление, но и использование констант, разбиения кода на функции или процедуры, способы вызова функций и процедур, согласованность структур, их потенциал к расширению, гибкость алгоритмов и многое другое. Стиль программирования сложно отделить от архитектуры самой программы, так как хорошо спроектированная программа не может иметь плохого стиля программирования.

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

Что такое шаблоны мышления? Всё чем вы так активно пользуетесь: - типы - функции - классы - массивы - указатели на типы - пространства имён - шаблоны (С++) Всё это направляет ваше понимание программирования как пространства сотканного из таких абстракций.

Недавно я прочёл следующую мысль на форуме WASM.RU:

Да, зачем вы пишите программы на asm под Win32, лучше уже писать под DOS, там хоть нет этого бесконечно однообразного кода создания окон и обработки сообщений.

Такое заявление говорит, что программист не желает писать проекты более чем на 6 000 строк (или 3 000 :)). Вместо того чтобы извлечь великую выгоду из единообразия кода, мы ругаем его. А ведь это первый звонок к автоматизации программирования.

Неужели программирование asm может быть похоже на Delphi (ох как его не любят некоторые)? Снова интегрированная среда? Конечно!!! (Жаль, её всё-таки нет!) Но это не значит, что она играет отрицательную роль. Хотя о средствах автоматизации и их создании мы поговорим в другой работе.

Ассемблер не определяет шаблонов мышления, и практически не имеет средств выражения каких либо шаблонов (из-за чего автор пользуется им).

Очень сложно назвать директиву proc средством выражение процедурной модели программирования.

Однако я могу ручаться, если вы научитесь писать качественно стилизированные программы на ассемблере, то на ЯВУ… :).

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

Если вы ещё не работали с макросами, или работали, но очень мало, я спешу признаться, что это руководство не предназначалось для начинающих. Но благодаря рекомендациям и советам TheSvin/HI-TECH я решился добавить в него вырезки и упражнения, которые позволят вам быстро войти во вкус макромира MASM32. Если же вы уже имеете дело с макросами, тогда это руководство укрепит ваши знания и представления по данной теме.

Для исследования макромира MASM мы воспользуемся директивой echo , которая позволит вывести нам на экран то, что творится в препроцессоре MASM. Очень удобно, а главное наглядно. Я уверен, что вы быстро усвоите этот материал.

В данной работе я часто пишу: «Препроцессор ML». Кто-то из умников (или просто жаждущих подловить «на горячем») воскликнет: «Да какой же такой ML.EXE – препроцессор? Наглая ложь». На всякий случай оговорю, что здесь имеется ввиду не утверждение «ML – препроцессор», а именование его подсистемы – препроцессор.

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

Многое из того, что написано в этом руководстве недокументированно (или плохо документировано) в официальном. Поэтому вы всегда должны помнить, что если в следующих версиях ML (например, 8.0) что-то не будет работать, никто не виноват.

Если вы думаете, что я дизассемблировал ML.EXE – то ошибаетесь. Алгоритмы работы, приведённые здесь, получены логическим путём на основе знаний работы компиляторов, а поэтому их не следует воспринимать как истинные. Важна сама логика работы, понимание которой, поможет вам безболезненно использовать макро, допуская меньшее количество ошибок.

На самом деле MASM очень плохо документирован, и видно MS совсем не относится к нему как к продукту (что вполне очевидно). Хотя уже в MSDN 2002 был внесён раздел MASM Reference , и всё равно – вы не найдёте лучше описания чем в MASM32 by Hutch.

Когда вы прочтете, то воскликните: « Да, зачем мне такой ML? ». Есть NASM и FASM – главная надежда мира ассемблерщиков. Однако и теперь ML всё ещё выигрывает у них по удобству эксплуатации, большей частью видимо благодаря Хатчу, и многим замечательным людям, поддерживающим MASM32. Кто знает, может после этой статьи кто-то воскликнет: « Я знаю, какой должен быть компилятор мечты асмовцев! ». И напишет новый компилятор. (Автор шутит ?)

Уверен, что программисты из MS вряд ли прочтут эту статью (они плохо знакомы с русским), и оно к лучшему. Возможно, такая статья могла бы их огорчить, а я не люблю портить настроение людям, трудами которых пользуюсь. (Снова шутит, только про что?)

И наконец-то мне в свою очередь хочется порадоваться, что многие вопросы по макросам в MASM закрыты на долгое время, во всяком случае, для русскоязычной аудитории. (Шутит, или нет? Гм…)

Терминология этой статьи различается от терминологии принятой в MASM.

В частности автором было предложено называть:

В MASM:

Можно было бы попросту выбрать терминологию MASM, однако последняя не позволяет объяснять материал систематически. То есть все четыре вида выражений – по сути, являются переменными или константами. Однако в терминологии MASM два последних определения называются текстовыми макро, подчёркивая их связь с макросами.

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

Что имеет ввиду автор? Посмотрите что такое макроопределение – это некий текст, который как бы «вставляется» препроцессором в исходный текст программы в месте вызова макро. А что такое в терминологии MASM numeric equates, или text macro – это некоторые переменные, значения которых «подставляются» в исходный текст программы во время компиляции вместо имён этих переменных. Таким образом, можно сказать, что определения представленные выше – макро, но в упрощённом их виде.

Этот спор не решаем, что не так и важно. Поэтому автор отдаёт предпочтение двум терминам для «text macro»: «текстовой макро» и «строковая макропеременная».

Понятие: «numeric equates» является общим для первых двух случаев, и разрывает смысловую связь с двумя последними определениями. Поэтому я пользуюсь своим вариантом терминологии, который подчёркивает, что определения:

являются подобными макро. А, кроме того, первое из низ – константа, а второе – переменная.

Не могу не написать этот пункт, ибо не только автору обязана эта статья.

Она обязана замечательной версии Win98 с инсталляцией от 2000, которая отформатировала весь мой винчестер, и унесла в небытие первый вариант настоящей статьи. :)

Не малая заслуга в вопросе терминологии MASM , и его разрешении принадлежит Four-F , который как он сам мне признался, съел на макросах собаку, при чём без соли :).

Когда я думаю, чтобы было бы без самого Маниакального редактора в Inet, CyberManiacа , то понимаю: без его правок мои статьи приводили бы в ужас, и лишали разума всех морально неустойчивых читателей. CyberManiac: «Только такой замечательный безумец как ты может выдержать ЭТО!!!» :).

FatMoon , Rustam , The Svin – вы дали понять мне то, что такая статья действительно нужна, и это, наверное, самое главное. Вряд ли я бы так долго работал над ней, если бы меня никто не подталкивал.

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

С уважением, Edmond/HI-TECH

Когда говорят, что лень – это двигатель прогресса, видимо лицемерят или преувеличивают. Скорее это нежелание выполнять одну и ту же работу очень часто. Первая парадигма к созданию макро звучит так:

Если есть что-то похожее, что нужно делать очень часто, я могу оформить это как макроопределение.

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

Та или иная методика программирования обязательно состоит из каких-либо компонентов, которые являются подобными друг другу. Например, следующие макро очень любимы в примерах пакета MASM32 :

Предположим, что кому-то так надоело писать:

И он решил придумать макро для этого. Эта пара команд осуществляет пересылку данных из одной ячейки памяти в другую. То есть теперь в программе, когда вы захотите написать push/pop , вы можете заменить это некой m2m операнд1, операнд2. Посмотрите на эти два участка кода:

Первый вариант не только занимает меньше строк (что тоже важно), но и намного понятнее, чем push/pop (если вы, знаете что такое m2m). Конечно, если говорить о макро m2m, то он имеет и очень важный недостаток.

Мощь макро была бы сказочной, если бы MASM умел следить за кодом, или ему можно было бы указать, что, например, сейчас регистр ebx == 0, или eax никем не используется. Хотя мы попробуем достичь подобного эффекта самостоятельно.

Этот недостаток потеря контроля над оптимальностью кода. Например, более быстрыми, по сравнению с парой команд push/pop , являются mov eax,… Употребляя макро m2m , вы получаете худший код, если стремитесь оптимизировать по скорости. И здесь есть две стороны проектирования кода:

1. Эффективность кода

2. Совершенство стилистики

Используя макро m2m , вы повышаете уровень стилистики, так как сокращаете время на понимание исходного кода (вами же или другим программистом). Однако с другой стороны вы теряете эффективность.

Это одна из вечных задач архитектора – найти баланс между эффективностью в коде и совершенством стилистики.

Другая парадигма использования макро звучит так:

Если, объединяя что-то в одно целое, я улучшаю стиль кода – это можно сделать в виде макроопределения.

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

В этих макро нет по сути никакой пользы, кроме эстетической. Зато, глядя на код, можно сразу понять, что это не что иное, как начало программы нечто вроде main() в C++.

И последняя парадигма использования макро:

Если ты используешь технологию программирования – попытайся заключить её в комплекс макроопределений. Например, для модульного программирования нужно создать макросы для определения модуля, его частей, кода и данных.

Наиболее важная часть использования макро. Посмотрите, например, файл Objects.INC из пакета MASM32 в папке oop (NaN & Thomas).

Мы начнём создание первых макро со следующей задачи.

Наверное, вы знаете, что EXE приложения всегда могут загружаться по адресу равному:

Во-первых, это даёт нам право убрать из приложения всю Relock секцию, тем самым, уменьшив объём образа (если эта секция нужна для систем плагинов, её можно держать отдельно).

Во-вторых мы можем более не вызывать функцию GetModuleHandle , что так же полезно для нас. Использование константы PROGRAM_IMAGE_BASE очень удобно. Однако, что будет значить это удобство, если всё-таки PROGRAM_IMAGE_BASE не определено? Это будет означать, что мы обязаны переписать весь код. А если этого кода много?

Определённо об этом нужно позаботится заранее. Давайте же будем решать эту проблему при помощи макро! Для этого нам станут необходимыми некоторые знания о том, как обрабатывается макро, и что это такое.

Макрос представляет собой именованный участок исходного текста программы, который обрабатывается компилятором каждый раз в том месте, где вызывается макрос.

-= Подробней =-

Пример: Создайте небольшой модуль с именем macro.asm. И напишите в нём несколько строчек Так действует директива echo. С помощью неё можно подсмотреть значения переменных. Если вы не знаете, как это работает, не волнуйтесь, обо всём будет рассказано. А пока несколько экспериментов: Напишите: Взгляните на код программы под отладчиком. Что у вас получилось? Что будет, если вы измените текст внутри макроопределения? Теперь напишите: Каким будет вывод на экран во время компиляции?

С этого момента вам придётся различать в ассемблере ML две подсистемы: препроцессор и компилятор. Если компилятор переводит код мнемоник в машинный код, вычисляет значения меток и смещений, то препроцессор занимается вычислением выражений этапа компиляции, и что самое важное – процессом раскрытия макросов.

Подобно многим объектам мира программирования макро имеет два состояния в исходном тексте: определение, и использование.

Таким образом, мы будем иметь дело с определением макроса (макроопределением), и его вызовом (использованием макроса).

Макроопределением называется любой текст, заключённый между ключевыми словами:

При каждом вызове макро, а именно:

Будет анализироваться и исполнятся текст, заключённый в макро. Именно так это и реализовано в ML. Поскольку текст в макроопределении не компилируется, то естественно, вы не увидите сообщений об ошибке, даже если с точки зрения ассемблера эта ошибка будет в теле макроопределения. Однако ошибка появится при попытке вызова макроопределения, её могут выдать вам, либо сам препроцессор, либо компилятор, если текст, сгенерированный препроцессором является неверным с точки зрения компилятора.

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

Вы можете самостоятельно удалять макроопределения, из памяти препроцессора используя директиву PURGE :

Эта директива удаляет тело макроопределения, однако не удаляет имя макро из таблицы имён. Таким образом, в данном случае:

Разработчики ML задумывали эту директиву для разрешения конфликтов между файлами с множеством макросов, однако мне совершенно не ясно как ей можно воспользоваться. Если вы хотите получить эффект «удаления» макро, лучше применять следующий метод:

В этом случае при попытке воспользоваться таким макро, компилятор выдаст ошибку, и вы будете проинформированы о его вызове, что намного лучше неведения. Поэтому просто запомните: «Не нужно использовать директиву PURGE».

Конечно же, использование макро не было бы столь полезным, если бы макро не имел формальных параметров. При вызове макро, препроцессор заменяет все имена формальных параметров их непосредственными значениями в теле макроопределения. Список формальных параметров разделяется запятой, и может иметь вид:

Здесь:

Param0 – пример определения параметра.

Param1:REQ – ключевое слово REQ указывает на то, что этот параметр обязательный. То есть, если он не будет указан, вы получите ошибку этапа компиляции.

Param2:= <0> – пример параметра, который имеет значение по умолчанию. То есть если этот параметр не будет указан при вызове макро, он будет равен этому значению.

Param3:vararg – становится именем параметра, который воспринимает всё остальное как строку. При этом запятые между параметрами так же попадают в строку, а значит число параметров макроса в принципе неограниченно.

Ограничениям являются особенности архитектуры компилятора. Так, например, компилятор имеет ограничение на длину логической строки, которая равна 512 байтам.

Конечно же, после параметра с директивой vararg не возможно объявить другие параметры.

Обратите внимание, что если при определении формального параметра в макро нет директивы – он считается необязательным параметром. Более подробно о вызове макро и значении параметров я расскажу далее.

-= Подробней =-

Пример: Так что же происходит с формальными параметрами? Посмотрите, как работает препроцессор ML: 1. Препроцессор берёт текст внутри макро, и заменяет в нём все слова param1, param2, на их значения: « mov eax, var mov ebx, 123 » 2. Полученный текст вставляет на место вызова макро, и передаёт компилятору. Вот интересно, а что будет если:

Можно различать два вида макро – макропроцедуры и макрофункции.

В официальном руководстве MASM различается четыре основных вида макро. Text macros – текстовый макрос Macro procedures – макро-процедура Repeat blocks – блок повторения Macro functions – макро-функция Однако автор считает, что разделение макро на два вида – лучше систематизирует материал, и отражает суть темы.

Макрофункции в отличие от макропроцедур могут возвращать результат, и получают список формальных параметров в скобках, подобно функциям в С. Например:

Заметьте, что к макрофункции невозможно обратится как к макро, вы всегда должны заключать формальные параметры макрофункции между «() », иначе MASM не будет распознавать её как макрофункцию:

Препроцессор MASM анализирует текст макроопределения на наличие директивы exitm , и помечает макрос как макрофункцию.

Ключевое слово exitm <retval>, аналогично оператору return в C++ , выполнение макро заканчивается, и возвращается необязательный параметр retval. Этот параметр – строка, которую должен вернуть макрос.

-= Внимание =-

Если в макро директива EXITM употребляется без параметров: EXITM То препроцессор считает, что это макропроцедура, а не макрофункция. Если в макроопределении есть два вида EXITM с параметром и без, то ML выдаст ошибку о недопустимом использовании директивы EXITM. EXITM <> EXITM : error A2126: EXITM used inconsistently Это подчёркивает тот факт, что макрофункцией считается только макро, который возвращает значение (хотя бы пустое), а директива EXITM без параметров не возвращает никакого значения, что недопустимо в макрофункции.

Таким образом, окончательно будем считать, что макро, которые не возвращают значение – это макропроцедуры, а макро, которые возвращают значение (хотя бы пустую строку) – это макрофункции.

Что касается директивы endm, которая заканчивает каждое макроопределение, в руководстве написано, что при помощи неё так же можно указать возвращаемый параметр: endm <retvalue> Однако на практике это не так. ? Очень странно, хотя об этом чётко написано в руководстве.

Заметьте, что макропроцедура может быть вызвана только в начале строки:

Макрофункция может быть вызвана в любых выражениях:

Чтобы строить макросы, важно понимать, как они работают, и как их обрабатывает MASM. Давайте рассмотрим типичный макро, и этапы его обработки.

1. Компилятор встречает лексему MyMacro

2. Он проверяет, содержится ли эта лексема в словаре ключевых слов

3. Если нет, то он проверяет, содержится ли эта лексема в списке макросов.

4. Если да, он передаёт текст, содержащийся в макро препроцессору. Препроцессор заменяет все вхождения формальных параметров в этом тексте на их значения. В данном случае мы имеем:

5. Препроцессор возвращает компилятору обработанный текст, который после компилируется.

Обратите внимание на пункт 4 и 5. Они ключевые. Очень часто при работе с макроопределениями появляются ошибки из-за неверного понимания порядка генерирования макро текста. Например:

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

Прежде чем объяснять действительный порядок, я оговорюсь, что директива echo никогда не обрабатывает определённые константы, такие как PROGRAM_IMAGE_BASE.

Это утверждение справедливо даже тогда, когда перед директивой echo стоит оператор % , который может раскрывать только текстовые макроопределения. То есть выражение:

Даст результат:

Теперь, когда мы немного порассуждали можно привести тот текст, который генерируется из макро:

Это означает следующее:

1. При вызове макро, значение формальных параметров воспринимается как текст, и передаётся в макро как строка.

2. Исключение составляют лишь макрофункции, результат выполнения которых вычисляется и присваивается значению параметра.

Специальный оператор % заставляет ассемблер вычислять текстовую строку, следующую за ним, и только потом подставлять в правое выражение. Например, если мы перепишем макровызов так:

То получим вывод:

Давайте рассмотрим ещё один пример, который хорошо показывает, как работает макро. Например, вы определили макропроцедуру (именно его, а не макрофункцию). То когда вы пишите такое:

Что делает препроцессор ML :

1. Считывает всю строку до символа возврата каретки;

2. Смотрит, как вы определили параметры в макро;

3. Сканирует строку на наличие символа «, » или «< », «> »;

4. Назначает формальным параметрам (любого типа, кроме VARARG) макро участки строк, которые были определены разделителями запятыми (предварительно очистив от хвостовых и начальных пробелов, если только строка не была определена в угловых кавычках < >);

5. Если макро содержит формальный параметр типа VARARG , то ML сперва инициализирует значениями (согласно пункту 4) обычные формальные параметры, и только потом назначает параметру типа VARARG (который может быть только один в конце списка параметров) всю строку до конца.

-= Обратите внимание =-

Если вы пишите макровызов как @Macro Param1 , Param2 То значение параметров будут: param1 = «Param1» param2 = «Param2» Если вы хотите передать сами значения строк, то должны заключит их в угловые кавычки: @Macro < Param1 >,< Param2 >

6. Препроцессор разрешает все вызовы макрофункций, если они есть в лексемах параметра, и присваивает их результат соответствующему параметру. Если лексему в строке параметра предваряет символ % , то он вычисляет её значение до того, как передаст строку внутрь макро.

-= Обратите внимание =-

Благодаря именно такому порядку: 1. Разделение строки на макропараметры 2. Поиск и Вызов макрофункций в значениях макропараметров 3. Присвоение результатов соответствующему макропараметру в следующем случае: строка, возращаемая макрофункцией присваивается параметру param1, а не param2, param3

Теперь вы в состоянии объяснить следующую ситуацию:

Как нужно было бы изменить этот макро (именно макро, а не макрофункцию), чтобы предупреждение не выдавалось? А почему оно происходит?

Если вы с лёгкостью ответили на этот вопрос, значит, материал усвоен, иначе советую ещё раз прочитать его, и ответить на следующий вопрос.

Как должен понять компилятор следующий код:

Естественно отвечать на этот вопрос вы должны без помощи компилятора (то есть проверить компиляцией). Если вы не можете ответить на этот вопрос, или неуверенны в верности ответа, я поменяю задание:

Запустите его в ML. Если и теперь вы сомневаетесь – перечитайте этот пункт снова и снова, продолжая экспериментировать.

Я бы назвал следующее:

макропеременными (с тем фактом, что переменная может иметь константный тип).

В терминологии MASM:

Потому что под термином «переменная» понимается:

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

Макропеременная может иметь только три типа – целочисленная макропеременная INEGER4 (dword), целочисленная макроконстанта или текстовой макро (строковая макропеременная).

Автор считает значительным упущением отсутствия возможности определять тип макропеременной. Это очень сильно ограничивает возможности макропрепроцессора. Но что поделать.

При чём, в зависимости от вида определения макропеременной ML считает, что:

Как вы уже догадались, каждое макроопределение обладает своими свойствами и возможностями.

1. Целочисленная макропеременная. Имеет тип INT (dword). Может участвовать во всех арифметических выражениях MASM. Как переменная она может изменять своё значение.

2. Макроконстанта может иметь целочисленное значение. Её значение не может быть повторно изменено.

3. Текстовой макро может быть любой строкой не более 255 символов. Поскольку он имеет статус переменной, его значение может быть изменено.

А теперь подробнее. Если с целочисленными макропеременными в достаточной степени ясно. То с определениями EQU полный бардак.

Как и в случае с вызовами макро, автор попытается построить алгоритм анализа EQU выражений:

1. Анализируем правую часть. В анализе правой части препроцессор выделяет лексемы, которые классифицирует как числа, строки. Так, например, в выражении:

«1234567890» – это лексема число, а «string1» – это строка, «macrofun()» – это всё равно строка (а не макрофункция!!!).

-= Внимание =-

Именно по этому такое определение будет давать ошибку: qqqq EQU 156n7 : error A2048: nondigit in number

2. Если правая часть является верным определением числа в MASM , то есть 123 или 123h или 0101b – выполнить шаг три, иначе шаг четыре.

-= Внимание =-

Обратите внимание, что числа с плавающей запятой в этом случае считаются строкой. Такое поведение связано с внутренней организацией препроцессора ML, который просто «не понимает» чисел с плавающей запятой, и не умеет с ними работать. То есть тип макропеременной Float: будет не числовой, а строковой

3. Если полученное число имеет значение, не превышающее диапазон значений для dword – это целочисленная макроконстанта.

-= Интересно =-

Если правая часть для EQU является верным числом более 25 символов, выдаётся ошибка: : error A2071: initializer magnitude too large for specified size При чём такая ошибка появляется даже в том случае, если выражение содержит другие символы через пробел: Это объясняется действиями в пункте 1, когда ML анализирует лексемы. Кроме того, если числовая лексема не соответствует правилам определения чисел в ML, то есть в середине числа появляется символ A-Z, либо другие символы, не входящие в разряд разделителей – то такая лексема порождает ошибку, даже если она содержит число большее dword диапазона.

4. Иначе – это строковая макропеременная.

Теперь попробуйте самостоятельно определить тип макроопределения:

В данном примере только второй и третий вариант – макроконстанта, остальные – текстовые макро. Последний вариант таким не является, так как превышает диапазон значений для dword.

Замете, что поскольку препроцессор в правой части выделяет корректные выражения, правая часть не может состоять из недопустимых символов. Но при этом она может состоять из директивы определения литерала: «< >» – угловых кавычек.

Директива <текст > – определяет литерал, таким образом, указывая препроцессору ML , что он должен воспринимать нечто как строку символов. При этом сами «< >» – в строку не попадают. Директива < > – является единственной директивой для препроцессора ML , которая определяет литералы.

Именно по этой причине, все виды кавычек – двойные, одинарные, – вот такие одинарные, воспринимаются как простые символы, и как следствие проходят к значениям параметров макро. То есть, например: MyMacro “Привет, это строка в двойных кавычках” MyMacro ‘Привет, это строка в одинарных кавычках' MyMacro Привет, это строка в специальных кавычках` MyMacro "Привет, это строка"'И это' И замете, что во всех случаях кавычки так же попадают в значения формального параметра макро. Вы можете использовать этот факт, например, для того, чтобы менять поведение макро, в зависимости от типа кавычек обрамляющих строку.

Кроме директивы, определяющей литерал, препроцессор ML имеет свой ESC -символ (символ отмены). В отличие от С этот символ – «! ». Он отменяет действие других символов (<, >, ", ', %, ; , а так же символ запятой), которые могут иметь функциональность в том, или ином выражении. Если вы хотите получить «! », вы должны использовать последовательность «!! ».

К сожалению, не обходится без проблем и с символом отмены «!». Восстановить точный алгоритм работы мне не удалось. Единственное, что возможно – это привести несколько примеров с непонятными эффектами при его использовании:

Вывод – не пользуйтесь директивой EQU для определения литералов, для этого есть другая директива – TEXTEQU.

Для директивы TEXTEQU алгоритм несколько отличен от алгоритма EQU , так как в TEXTEQU обрабатывается правое выражение на наличие символа %. То есть вы можете определить этот код:

Или

На самом деле как вы видите, внутренняя работа TEXTEQU значительно отличается от EQU < >. Видимо по этому разработчики ML решили её ввести.

В заключении к этому пункту, вы должны осознать, что тип определений невозможно изменить. То есть переменная не может стать целочисленной константой:

Второе переопределение символа literal , не изменит его тип на тип целочисленной константы.

Свои особенности имеют так же целочисленные выражения с оператором «=». В таких выражениях перед их выполнением осуществляется полная замена всех макроконстант, макропеременных на их значения, и вызов всех макрофункций.

Как вы думаете, что будет в следующем примере:

Варианты ответа:

1. Произойдёт ошибка переопределения константы.

2. literal = 1234.

Второй вариант ответа мы должны откинуть сразу, потому что в этом пункте чётко определили, что данное переопределение невозможно. Первый вариант ответа больше похож на правду.… Однако не соответствует истине. Что же произошло? А произошло следующее:

1. Препроцессор нашёл лексемы « literal » и « 1234 ».

2. Обнаружил, что « literal » является текстовым макро, и именно поэтому выполнил замену лексемы « literal » на её строковое значение.

3. Проанализировал строку: « Something = 1234 ».

Этот факт может быть легко доказан, следующим тестом:

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

А пока подумайте, что должно случится в этом примере:

На этом можно было бы закончить данный пункт, если бы не одна особенность использования строк в вызове макро. А точнее приоритет анализа кавычек и директивы определения литерала < >. Не смотря на описанный выше алгоритм поведения макро, оказывается, что препроцессор при вызове макро выполняет определение литерала в кавычках, но что самое интересное, как было отмечено, выше сами кавычки попадают в строку. Если вам нужно передать макро одиночную кавычку вы должны воспользоваться символом отмены «! ». Однако самое неприятное таится в том, что символы «< >» и кавычки конкурируют между собой в определениях строк. Например, попробуйте сказать, что должно было бы получиться в этом случае:

А можно было бы подумать, что ML должен принять операторы <> и запятую. Данное место – источник многих сложно обнаруживаемых ошибок. Например:

Если в строке попадается символ кавычки, а макропеременная char заменяется на значение кавычки, имеем:

В этом случае мы получаем ошибку:

Так и должно быть, потому что кавычки имеют высший приоритет анализа, чем оператор < >. Более того, угловые кавычки <> имеют самый низкий приоритет по отношению ко всем спец. символам, что согласуется с MASM Reference. Посмотрите на Дополнение к статье: пункт 3.a.i , который подозрительно выделен « жирным ». В частности, следующее выражение, которое работает без проблем:

Появляется закономерный вопрос: для чего символ отмены «! »?

Данный пример демонстрирует скрытые глубины анализатора ML. А точнее его архитектурное несовершенство. Так как выражения с TEXTEQU как видно обрабатываются отдельной функцией, которая проверяет в первую очередь наличие угловых скобок «< >». Все другие выражения ML обрабатываются другой стандартной функцией, которая была написана задолго до появления TEXTEQU.

Замечательная наука всем программистам, которая демонстрирует, во что выливается халатность архитектора при дальнейших попытках расширения продукта.

Зато благодаря TEXTEQU пример с поиском символа в строке имеет решение:

Единственно, отчего не может помочь данный код – это от вылавливания в строке символов «> или <». Для этого можно использовать специальную проверку в условных блоках на наличие символа «>», но при этом придётся отказаться от микроблока FORC.

MASM обрабатывает выражения в правой и левой части в зависимости от контекста. Там, где вам необходима предварительная обработка выражений, используется оператор «% ». Он заставляет препроцессор ML сначала вычислить выражение после оператора %(то есть выражение в правой части относительно %), и только потом продолжить анализ всей строки. Например, если вы хотите, чтобы при вызове макро:

макропараметр был бы равен не строке « num », а значению текстового макро num , вы должны поставить оператор % перед num. Например:

Но и с оператором % не всё гладко.

Оказывается препроцессор ML , различает два (фактически три) вида выражений, в которых используется оператор %. Первый вид выражений – Арифметические:

Все выражения, содержащие операторы +,-,*,\ а так же сдвиговые и битовые операции

Строковые выражения:

Все выражения результат вычисления которых – строка.

Примеры:

Так вот что интересно.

В арифметических выражениях происходит полная замена правой части: вызовы макрофункций, значение макроконстант, макропеременных любых типов, как строковых, так и целочисленных. Так же в левой части выражения: замена строковых макропеременных, и вызов макрофункций.

То есть:

Левая часть = Правая часть (Вызвать все макрофункции, и заменить все строковые макропеременные) = (Вызвать все макрофункции, и заменить все строковые и целочисленные макропеременные и константы)

В строковых выражениях происходит замена только строковых макропеременных (текстовых макро) (замете, что в ML нет строковых макроконстант). Это значит что в случае:

Появится: « PROGRAM_IMAGE_BASE », а не его числовое значение.

Однако есть и третий частный случай, когда оператор % относится только к одному литералу:

В этом случае происходит полный комплекс подстановок:

1. Вызываются макрофункции.

2. Заменяются все макропеременные или макроконстанты.

Например:

Значение literal будет подставлено в вызов макро, в независимости от того, какой тип имеет literal.

-= Внимание =-

Выдержка их руководства MASM: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= temp TEXTEQU %(SIZEOF array / LENGTHOF array) % ECHO Bytes per element: temp Note that you cannot get the same results simply by putting the % at the beginning of the first echo line, because % expands only text macros, not numeric equates or constant expressions. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Следует так же отметить, что в выражениях с exitm оператор % работает точно так же, как с выражениями в TEXTEQU.

Целочисленные, побитовые операции так же необходимы разработчику макроопределений. Они дают возможность скрыть обработку битовых полей, или вычисление сложных выражений. Например, как это сделано в макрофункции $$$MAKELANGID.

Вы всегда должны помнить, что препроцессор MASM не различается знаковые и беззнаковые числа (подобно тому, как это делает x86), и значение числа не может выходить за диапазон dword. Препроцессор MASM не выдаёт предупреждений при переполнении. Следующий пример демонстрирует такое поведение:

В следующей статье мы поговорим про то, как работать с 64-bits макропеременными, используя данный факт.

Ниже приводится список операций, которые могут участвовать в целочисленных выражениях MASM.

Оператор — Пример — Описание

AND — res = op1 AND op2 — Операция логического «И» над каждым битом операндов op1 и op2.

OR — res = op1 OR op2 — Операция логического «ИЛИ» над каждым битом операндов op1, op2

NOT — res = NOT op1 — Операция логического «НЕ» над каждым битом операнда op1

XOR — res = op1 XOR op2 — Операция XOR между операндами op1, op2

SHL — res = op1 SHL count — Выполняет побитовый сдвиг влево (наподобие команды x86 shl) операнда op1, на количество бит, указанное в операнде count.

SHR — res = op1 SHL count — Выполняет побитовый сдвиг вправо операнда op1, на число бит, указанное в операнде count.

+,-,*,/ — Основные математические операции

MOD — res = op1 MOD op2 — Возвращает остаток от деления операнда op1 на операнд op2

[] — res = op1[op2] — Операция: «Смещение». Выполняет сложение операндов op1 и op2

Теперь, когда мы рассмотрели правила анализа и вычисления выражений в MASM , остаётся раскрыть важный вопрос: « Как происходит анализ выражений, если они состоят из других выражений? ».

Обычно это называется короче: вложенные выражения.

Вложенное выражение – это такое выражение, элементы которого сами являются выражениями, которые так же могут иметь вложенность.

Замороченное определение, похожее на «Иди туда, не знаю куда, возьми то, не знаю что» – пример старинной народной русской рекурсии, которая так часто встречается в нашей жизни. :))

Например, вызов макрофункции при вызове макро – это вложенное выражение:

Вложенность характеризуется параметром количества уровней вложенности. В недавнем примере уровень вложенности был равен двум. При чём вызов Fun2() можно называть выражением низшего уровня вложенности, а вызов макро MyMacro – выражением верхнего уровня.

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

Например, для случая:

Порядок вычислений такой:

1. %(12+34) = 46

2. Fun2(46)

3. FunMacro(MyCount = 46)

4. Результат выполнения FunMacro(MyCount = 46)

А иначе препроцессор не смог бы. Если бы он начал вычисления выражений с верхнего уровня, то это то же самое, как если бы он попытался выполнить народную русскую рекурсию: «Пойди туда, не знаю куда…, вычисли то, не знаю что» или FunMacro(???)

То есть: Вложенные выражения вычисляются последовательно от низшего уровня к верхнему, и результаты вычисления каждого уровня становятся материалом для выражений следующего уровня.

Это правило называется рекурсивным вычислением выражений. Оно используется везде, кроме мест вычисления значений макропараметров при вызове макро (как макросов, так и макрофункций). В этом случае действует правило: результат вложенного выражения присваивается макропараметру и не анализируется повторно. Это значит, что в данном примере:

вывод будет таким:

То есть препроцессор не будет снова вычислять выражение для второго макропараметра функции FunMacro(). Если бы он сделал это, то тогда вывод был бы таким, как в этом случае:

Теперь, когда вы знаете все тонкости вычисления выражений в MASM, настало время рассмотреть Встроенные макрофункции и директивы, которые участвуют в этих выражениях.

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

MASM обладает несколькими встроенными макрофункциями, макропеременными и макроконстантами, которые работают так, как если бы они были макро, определённые вами. Вот список этих предопределений:

Определения Даты и Времени

@Date, текстовое макроопределение (не макрофункция) — Возвращает строку вида MM/ДД/ГГ Где: MM – месяц, две цифры ДД – день, две цифры ГГ – год, две цифры

@Time, текстовое макроопределение (не макрофункция) — Возвращает текущее время в 24-х часовом формате вида ЧЧ:ММ:СС ЧЧ – часы, два числа ММ – минуты, два числа СС – секунды, два числа

Информация об окружении

@Cpu, числовая макроконстанта — Битовая маска, определяющая режим работы процессора. Никакой информации о полях этой маски нет.

@Environ(env), макрофункция — Возвращает строковое значение переменной среды окружения. Например: Вывод: F:\Temp\asm

@Interface, целочисленная макроконстанта — Информация о языковых параметрах вызова.

@Version, строковая макроконстанта — Возвращает версию ML. Например:

Информация о файле

@FileCur, строковая макропеременная — Возвращает имя файла и путь к нему (если есть), так как был подан этот файл в командной строке компилятору ML. Пример:

@FileName, строковая макропеременная — Возвращает имя файла, без его расширения. То есть для модуля start.asm:

@Line, целочисленная макроконстанта — Возвращает номер текущей строки в файле. Пример:

Строковые макрофункции

@CatStr( string1 [[, string2...]] ), макрофункция — Возвращает строку, созданную объединением строк параметров функции. Пример:

@InStr( [[position]], string1, string2 ), макрофункция — Возвращает позицию вхождения строки string2 в строку string1. Если параметр position определён, тогда поиск начинается именно с этой позиции. Отсчёт позиции начинается с единицы. В случае, если вхождение не найдено макрофункция возвращает значение 0. Параметр position должен быть целым числом больше нуля, но не равным нулю. Пример:

@SizeStr( string ) макрофункция — Возвращает число, характеризующее длину строки, или, что тоже самое количество символов в строке. Функция возвращает число, однако, поскольку это макрофункция то тип возвращаемого значения – строка.

@SubStr( string, position [[, length]] ) макрофункция — Возвращает подстроку строки string, начиная с позиции, указанной в параметре position (отсчёт начинается с 1). Если необязательный параметр length задан, он ограничивает размер возвращаемой строки. Параметр length не может быть меньше нуля, и не может быть строкой. Пример:

Информация о сегментах

@code, строковая макропеременная — Возвращает имя сегмента кода.

@data, строковая макропеременная — Возвращает модель памяти. Пример:

@fardata?, строковая макропеременная — Равен имени сегмента FARDATA?

@WordSize, численная константа — Содержит размер слова в байтах. Для 16-bits – 2. Для 32-bits – 4.

@CodeSize, численная константа — Содержит идентификатор типа памяти. 0 – TINY, SMALL, COMPACT, FLAT. 1 – MEDIUM, LARGE, HUGE

@Model, численная константа — 1 – TINY 2 – SMALL 3 – COMPACT 4 – MEDIUM 5 – LARGE 6 – HUGE 7 – FLAT

@CurSeg, строковая макропеременная — Хранит имя текущего сегмента.

@fardata, @stack, строковая макропеременная — Содержат соответствующие имена сегментов

Кроме знания макрофункций, нам так же понадобятся знания о блоках ветвлений или просто IF блоках. Эти блоки позволяют исполнять тот или иной участок исходного кода в зависимости от того, выполняется какое-либо условие или нет. Часто это называют « Условным ассемблированием (компиляцией) », однако для MASM это нечто большее, нежели простое управление компилятором, так как, вы уже поняли, мы имеем дело, как с кодом машины, так и с макрокодом, который вычисляется и живёт только во время компиляции.

Условный блок в MASM имеет следующий общий вид:

Если выражение «Условие» равно истине, то выполняется блок кода, идущий после условной директивы, иначе управление передаётся на следующий оператор за блоком. [IFDIRECTIVE]/[ELSEDIRECTIVE] – могут быть той или иной директивой условия. Стандартные директивы IF /ELSEIF /ELSE требуют, чтобы выражение, стоящее при них, было целочисленным. Если вам необходимо проверять другие условия, то для этого в MASM предусмотрены специальные директивы.

Список [IFDIRECTIVE]/[ELSEDIRECTIVE]:

Блок — Условие выполнения блока

IF выражение ELSEIF выражение ELSE — если выражение равно истине

IF1 ELSEIF1 — если ассемблер выполняет первый проход

IF2 ELSEIF2 — если ассемблер выполняет второй проход (устарело)

IFE выражение ELSEIFE выражение — если выражение равно нулю

IFDEF выражение ELSEIFDEF выражение — если идентификатор, который является результатом выражения, определен. Идентификатором может быть макро, макропеременная, переменная, макроконстанта, любой другой идентификатор. При помощи этой директивы, можно проверить была ли определена та или иная переменная, макро, константа.

IFNDEF выражение ELSEIFNDEF выражение — если идентификатор не определён.

IFB строка ELSEIFB строка — если строка пустая. Строка считается пустой, если её длинна равна нулю, либо она содержит одни пробелы. С помощью этой директивы можно определяет присутствие/отсутствие необязательных макропараметров.

IFNB строка ELSEIFNB строка — если строка не пуста.

IFDIF str1,str2 ELSEIFDIF str1,str2 — если строки различны.

IFDIFI str1,str2 ELSEIFDIFI str1,str2 — если строки различны (без учёта различий в регистре букв).

IFIDN str1,str2 ELSEIFIDN str1,str2 — если строки одинаковы.

IFIDN str1,str2 ELSEIFIDN str1,str2 — если строки одинаковы (без учёта различий в регистре букв).

На протяжении всей статьи я часто пользовался следующей директивой, которая позволяет выводить текст на консоль во время компиляции. Эта директива echo. Как мы узнаем позже, она оказалось просто незаменимой при проектировании макро.

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

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

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

Именно для этого и существует простой набор директив условной генерации ошибки. Действуют они подобно условным блокам и директиве echo. Пример безусловной генерации ошибки:

Условная генерация ошибки, имеют ту же форму, что и IFDIRECTIVE в таблице выше, однако последним дополнительным параметром является строка сообщения. Например:

Ещё раз вернёмся к формальным параметрам макро. Как было сказано, при раскрытии макроопределения препроцессор заменяет в теле макро формальные названия на их величины. В MASM32 предусмотрено ещё одно средство подстановки макропараметров – внутри строкового литерала.

Предположим нам нужно, чтобы макро генерировал строку: « label_xx ». Где xx – это формальный параметр макро. Это можно сделать двумя способами:

То есть если во время генерации макро, препроцессор встречает в его теле символ «& », он анализирует строку после него. Если эта строка однозначно определяет один из макропараметров, препроцессор заменяет выражение &макропараметр& на значение макропараметра.

Следует отметить, что если макропараметр начинает или заканчивает литерал, то можно использовать только один символ «&»:

И, наконец, у читателя должен остаться единственный вопрос: « А как обрабатывать переменные типа VARARG »? Например, рассмотрим возможный макро для вызова функций – STDCALL :

Этот макро должен генерировать код вызова функции согласно конвенции STDCALL:

1. Поместить параметры в стек в обратном порядке их определению.

2. Вызвать функцию funname , предварительно видоизменив её имя по правилам STDCALL.

Получить видоизмененное имя функции по значению параметра funname можно было бы при помощи символа макроподстановки.

Но непонятно, как распознать параметры функции, которые представляют собой строку, где значения разделены символом «,». Более того, не понятно, как вообще можно получить эти параметры, и посчитать их число, ведь макропараметр params – это одна строка. То есть при вызове макро:

Мы должны как-то определить количество параметров, а потом их значения.

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

Первый из них FOR позволяет получить значения элементов, разделённых в строке символом «, ».

Вспоминая С конструкцию FOR , вы сразу поймёте что это цикл, где значение parameter последовательно принимает значения элементов списка string.

Вот вам wonderful пример:

А вот пример макрофункции, который подсчитывает число аргументов VARARG :

Вот в принципе, уже на основе этих знаний можно было бы организовать макрос stdcall :

Ещё несколько минут необходимо для того, чтобы понять, что этот макро работает неправильно. Хотя бы потому, что параметры помещаются в стек не так. Нужно было бы помещать их от последнего к первому, а не от первого к последнему. А, кроме того, ведь символ макроподстановки нельзя употреблять к макропеременной count , потому что это не макропараметр, это макропеременная.

К сожалению, в MASM нет обратной конструкции FOR. Поэтому самый простой выход, который напрашивается сам собой – это изменить порядок параметров в списке, а потом только генерировать команды push.

Вторую проблему можно легко решить, воспользовавшись макрофункцией конкатенации строк:

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

Как вы можете догадаться, в этом примере создаются макропеременные varXX , которым присваиваются значения параметров. Теперь с той же лёгкостью можно работать с этими переменными. Можно снова использовать цикл FOR , однако в данном случае, было бы грамотней воспользоваться значением count , и выполнить цикл столько раз, сколько записано в нашем счётчике параметров. Для этого мы воспользуемся ещё одним макроблоком rept , о котором скажем позже:

Блок REPT выполняется столько раз, сколько указано в nparams. Я ввёл эту дополнительную макропеременную, для того, чтобы значение, указанное в REPT осталось неизменным. Однако этого не нужно. Можно было бы написать и так:

Значение макропеременной count инициализирует цикл только один раз вначале, после чего, она может, как угодно менять значение.

И ещё один макроблок, без которого нам невозможно будет реализовать макрос для определения строк уникода, или макрос, который позволяет писать строки OEM в редакторе использующий кодировку win cp-1251 (например, при создании консольных приложений).

Этот макроблок FORC :

Блок FORC выполняется столько раз, сколько символов в строке string , при этом макропараметр char равен текущему символу из строки.

Например, посчитать количество символов в строке можно было бы так:

А вот так, можно было бы посчитать количество пробельных символов.

Упражнение:

TheSvin 'у, как и любому программисту, который часто имеет дело с битами, было бы удобно записывать значения бит по группам, через пробел.

Хорошо бы было написать некую макрофункцию, которая смогла бы позволить записывать эти выражения:

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

А напоследок… остаётся маленькая деталь.

И эта деталь не самая приятная. Отладка макроопределений и их испытания невозможны под отладчиком. А, кроме того, если при генерации макро возникает ошибка, то ML выдаёт её в жутком виде:

То есть он выдаёт относительную строку в макро MacroLoop(3) , где эта ошибка появилась. А если ещё макровызовы будут вложенными, то вам лучше не видеть этой замечательной картины.

Единственной возможностью качественно и относительно легко отлаживать макро – это употребление директивы echo.

На протяжении статьи вы не раз наблюдали примеры её использования. Но я снова повторюсь:

Заметьте, чтобы вывести значение целочисленной макропеременной необходимо воспользоваться макрофункцией @CatStr() , и перед аргументом указать оператор %. Почему именно так обсуждалась в пункте III.2. Определение макро переменных и строк.

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

1. Определены таблицы элементов:

Таблица переменных — Хранит сведения о всех переменных модуля

Таблица меток — Хранит список меток в коде.

Таблица процедур — Хранит таблицу и прототип процедур

Список ключевых слов KEYLIST — Хранит список ключевых слов, на которые реагирует ML

Таблица макрофункций — Хранит тело всех макро, их имена и тип: макрофункция, или макро. Список макропараметров

Таблица макросов — -=-

Таблица макропеременных, или переменных времени компиляции — Хранит тип макропеременной и её значение.

Всё остальное, что не включено

2. Начальное состояние анализа строки.

3. Читать поток символов, пока не встретится символ возврата каретки без предыдущего символа «/». Игнорировать часть строки после «;»

a. Определить наличие лексем первого уровня в строке:

i. Выделить все строковые литералы в кавычках, если только это не выражение с TEXTEQU и символ комментария «;»

ii. Строковые литералы: <текст>

iii. Численные литералы: 1234, 1234h, 01011b

iv. Правильные литералы: строка из символов «A-Z,a-z,_0-9», но не начинающаяся на цифру

v. Литералы разделители: «,.»

vi. Управляющие Литералы: «+-*» Правильные литералы: строка из символов «A-Z,a-z,_0-9», но не начинающаяся на цифру

b. Проверить правильные литералы на совпадение в списке ключевых слов, и определить схему выражения. В зависимости от схемы выражения, выполнить или пропустить:

i. Проверить правильные литералы на совпадение в списке макро (в зависимости от способа вызова в списке макрофункций, или макросов)

ii. Проверить на наличие имени правильного литерала в таблице макропеременных.

iii. Осуществить вызов и замену макро и макропеременных, в соответствии с выражением строки.

iv. Вычислить все выражения допустимые в ML (+-*).

c. Осуществить разбор схемы.

i. Если это определение процедуры, записать в таблице процедур имя и прототип новой процедуры

ii. Если это макроопределение: анализировать его тело. Если найден возвращаемый параметр, записать макроопределение в таблицу макрофункций, иначе в таблицу макросов.

iii. Если это определение EQU вычислить правую часть.

1. Если эта макропеременная уже есть в таблице макропеременных, и её тип – числовой, выдать ошибку. Если эта макропеременная имеет строковый тип, изменить строку, на которую указывает свойство value этой макропеременной.

2. Если правая часть числовой литерал – записать EQU определение в таблицу, и пометить его тип как числовой константы. Записать в свойство макропеременной value значение указателя на строку. Записать свойство value равным числу.

3. иначе EQU – переменная, имеющая указатель на строку. Записать в значения свойства value указатель на строку.

iv. Если это выражение с «=» или подобное, выполнить замену всех литералов на макроконстанты, переменные, вызов всех макрофункций, и только потом выполнять выражение.

4. Перейти к анализу следующей строки.

В начале было слово... Если точнее то было просто предложение от Kinder-а написать статью посвящённую макросам в FASM. Я согласился попробовать, но рассматривать макросы отдельно от синтаксиса как-то не очень правильно, а синтаксис без примеров разобрать сложно и в результате получилось сочинение о том как писать программы в FASM.

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

Основы.

Данный раздел является вольным

пересказом соответствующего раздела

руководства, поставляемого с

компилятором.

Данная статья посвящена использованию макросов в компиляторе FASM. Для начала вопрос: "Что такое макрос?" (поскольку я не могу услышать Ваш ответ прямо сейчас, когда пишу эту статью, отправляйте свои ответы мне по электронной почте, если Ваше мнение отличается от моего мнения).

Макрос - это инструкция препроцессору компилятора развернуть, встретившееся в коде программы, имя макроса (возможно с параметрами) в последовательность строк кода ассемблера с использованием переданных параметров (если таковые заданы).

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

Внутри определений макросов можно использовать инструкции if и else при этом каждая инструкция if должна закрываться инструкцией end if. Пример из руководства, поставляемого вместе с компилятором:

Этот макрос является расширением инструкции процессора mov. В данном случае если оба операнда макроса являются сегментными регистрами используется связка "push - pop", в любом другом случае используется стандартная инструкция "mov op1,op2". Оператор in позволяет проверить соответствие операнда нескольким значениям в угловых скобках.

Можно ещё более расширить эту инструкцию для пересылки трёх значений второго в первый, а третьего во второй:

В данном случае нас интересует инструкция eq , которая позволяет проверить эквивалентен ли операнд какому либо значению, в нашем случае мы проверяем его отсутствие, и если он отсутствует, то подставляется ветвь if иначе подставляется ветвь else.

Директива purge позволяет отменить последнее определение макроса.

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

Операндами этого макроса служат один обязательный (proc) и несколько необязательных параметров (arg). Директива reverse сообщает препроцессору, что следующие строки необходимо повторить столько раз, сколько параметров arg передано макросу начиная с последнего параметра. Директива common сообщает препроцессору, что следующие строки необходимо повторить только один раз. Директива forward сообщает препроцессору, что следующие строки необходимо повторить столько раз, сколько параметров arg передано макросу начиная с первого параметра. Действие директив common , forward и reverse заканчивается другой директивой common , forward или re-verse соответственно или закрывающейся фигурной скобкой. Если ни одна из этих директив не встречается в определении макроса, то макрос развернётся для всех параметров начиная с первого. Неизвестное количество параметров можно передать и другому макросу:

В этом примере при выполнении ветви if в макрос stdcall кроме параметра [proc] передаются все полученные параметры arg.

Внутри макроопределения может использоваться оператор # , который может использоваться для составления операторов ассемблера, например условного перехода:

При выполнении макроса jif ax,ae,10h,exit макрос будет развёрнут в следующую конструкцию:

Так же этот оператор можно использовать и для составления имён переменных или макросов внутри макроопределений:

Теперь при вызове данного макроса в секции данных

Мы будем иметь два массива из 10 байт каждый, с именами Chif.mas и Rab.mas.

Аналогично можно создать и переменные и макросы внутри определения макроса. Однако определить макрос внутри макроса обычным путём:

препроцессор не позволит использовать данную конструкцию, выход в использовании директивы fix она эквивалентна директиве equ , но препроцессор обрабатывает fix позже чем equ , что и позволяет использовать подобную конструкцию:

Синтаксис компилятора ФАСМ несколько отличается от синтаксиса других компиляторов, но отличия незначительны и в основном касаются макроязыка.

Средства макроязыка мы рассмотрим ниже, здесь же я хотел бы отметить только то, что передача адреса переменной производится указанием имени переменной без каких либо скобок или префиксов, а её содержимого написанием имени переменной в квадратных скобках.

mov eax,var; записываем в регистр еах адрес переменной var mov eax,[var]; записываем в регистр еах значение переменной var

Структура каркасного приложения на ФАСМ-е

В этой части мы рассмотрим, основы

синтаксиса данного компилятора и

рассмотрим каркасные приложения для

основных форматов исполняемых файлов.

Итак, что необходимо для работающего приложения?

Во-первых мы должны указать компилятору какого формата должен быть создаваемый файл. Это делается директивой format после, которой следует указание форматов:

• PE формат исполняемых файлов Windows. Далее должно следовать уточнение GUI (графический интерфейс), console (консольное приложение) и native (если Вы знаете, что это такое сообщите мне). Если выбран графический интерфейс, то следует также указать версию графического интерфейса 4.0, а так же зарезервированное слово DLL, если собирается динамическая библиотека.

• MZ формат исполняемых файлов MS DOS.

• COFF или MS COFF (для линковки продуктами Microsoft)для создания объектного файла, который в дальнейшем будет линковаться к другому проекту или к ресурсам.

• ELF формат для создания исполняемых файлов UNIX подобных систем (Linux).

Как Вы наверно поняли, я не знаком с файлами ELF типа и в данной статье мы не будем его рассматривать. Если директива format не указана, компилятор соберёт файл в формате com.

После указания формата выходного файла мы должны указать компилятору точку начала программы. Это делается с помощью директивы entry после которой указывается метка, с которой начинается код программы. Например entry start.

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

_Форматы PE исполняемых файлов Windows.

Консольные приложения_

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

Вот простой пример консольного приложения:

В данном примере создаётся три секции: данных, кода и секция импортируемых функций. Секцию импорта я создаю при помощи макроса _library , в стандартной поставке такого макроса нет, но если написать без подчёркивания перед library то всё скомпилируется правильно. Причина проста, я пользуюсь FASM-ом с версии 1.35, а тогда такого макроса еще не было (а сам я ещё не смог бы его написать) и для совместимости с ранее написанными программами я включил два варианта этого макроса. В ранней версии, необходимо было записывать все используемые в приложении функции вручную, теперь же работу по подключению только используемых функций берёт на себя компилятор, хотя за такое удобство приходится платить некоторым увеличением времени компиляции. Более подробно о принципе работы этого и других макросов будет написано в соответствующем разделе ниже.

Название секции импорта ".idata" , хотя название можно изменить и это не повлияет на работоспособность программы, т.к. мы указали назначение этой секции import data , далее следует указание атрибутов, в данном случае readable , что означает для чтения и этого достаточно, если Вы не собираетесь менять содержимое этой секции.

Следующей рассмотрим секцию данных. У нас секция данных имеет название ".data" , далее следует указание назначения секции data , что означает секцию данных, атрибуты указаны readable writeable , т.е. эта область памяти будет доступна для чтения и записи. Если указать только первый атрибут (readable) при выполнении программы произойдёт ошибка "Программа выполнила недопустимую операцию".

Последней рассмотрим секцию кода, она имеет название ".code" назначение секции code , т.е. исполняемая часть программы, атрибуты readable executable , что означает, что из секции кода мы можем читать данные (под данными может подразумеваться и коды инструкций и определённые в этой секции данные) и можем выполнять содержимое этой секции.

Кроме рассмотренных секций, консольное приложение может иметь секции экспортируемых функций и секцию ресурсов.

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

Графическое приложение

Графические приложения Windows это оконные приложения, такие как Word, Excel, Notepad и т.д.

В отличии от консольных приложений, GUI приложения должны содержать как минимум одну процедуру обработки сообщений, приходящих к окну. Вот простой пример оконного приложения:

Так же, как и в примере с консольным приложением, в первой строке указана директива format PE , но вместо console , как в предыдущем примере, дано указание GUI 4.0 компилятору собирать приложение с графическим интерфейсом версии 4.0.

Приложение из нашего примера ничего полезного не делает, оно просто создаёт окно, которое реагирует только на нажатие двух системных кнопок в верхнем правом углу окна "Свернуть" и "Закрыть". Приложение содержит секции данных, кода, импорта и ресурсов. После указания точки входа в программу entry start подключаются файлы содержащие макросы и определения констант и структур Windows. Затем следует секция данных, определение которой дано в предыдущем разделе, и секция кода. В секции кода мы получаем хендл нашего модуля (GetModuleHandle), загружаем иконку (LoadIcon), определённую в секции ресурсов, загружаем стандартный курсор Windows (LoadCursor) и заполняем структуру wc для дальнейшей регистрации класса нашего окна (RegisterClass). После регистрации класса окна мы создаём окно зарегистрированного класса (CreateWindowEx). В структуре wc имеется член .lpfnWndProc, в который мы записываем адрес начала процедуры обработки событий окна WindowProc. Далее следует цикл обработки сообщений, посылаемых окну системой Windows.

Процедура обработки сообщений получает от Windows четыре параметра:

proc WindowProc, hwnd, wmsg, wparam, lparam

где:

hwnd - хендл нашего окна

wmsg - код сообщения, которое Windows послало нашему окну

wparam и lparam - уточняющие параметры посланного сообщения.

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

Таким образом следующая строка proc Win,param будет развёрнута в следующую конструкцию:

Более подробно это означает, что мы определяем метку Win , которая означает начало процедуры. В следующей строке записана директива virtual at ebp+8 , которая должна заканчиваться директивой end virtual. Внутри этого определения помещаются переменные, которые будут размещаться с адреса указанного после at , в нашем примере это ebp+8. Это означает, что в нашем примере запись "mov param,eax " будет заменена на "mov [ebp+8],eax ". Если бы в определении процедуры было две или более переменных, то адрес каждой последующей переменной увеличивался бы на размер предыдущей переменной. Таким образом:

определит три переменные с адресами

У некоторых читателей может возникнуть вопрос: "А зачем все эти пляски?". Ответ прост: регистр ebp указывает на вершину стека и все переменные, передаваемые в процедуру, находятся выше (в смысле в памяти с адресами больше чем вершина стека т.к. вершина стека сдвигается вниз когда в стек помещаются данные и вверх, когда данные из стека изымаются) текущей вершины стека.

Первой, в определении переменных внутри virtual - end virtual записана директива local , которая указывает компилятору, что следующие за ней через запятую метки, локальны в данном макросе.

Последней, внутри описания виртуальных переменных, следует определение макропеременной ..ret = $ - (ebp+8) , которая фактически содержит количество переданных процедуре байт параметров. Она используется при написании эпилога процедуры для очистки стека при возврате управления инструкции, следующей за вызовом данной процедуры.

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

После определения макропеременных начинается блок определения виртуальных переменных, однако переменных в этом макросе нет. После макроса proc необходимо ставить макрос enter , который содержит заключительную часть пролога, а между ними могут располагаться локальные переменные. Для того, что бы имена переменных были локальными перед ними ставится точка. Например .param. Макрос enter определён следующим образом:

Таким образом dynamic_size - это размер памяти отведённой под локальные переменные. Последняя инструкция, в прологе процедуры, enter dynamic_size,0. Это единственная строка, которая попадёт в исполняемый код программы. Завершаться процедура должна макросом return, который определён следующим образом:

Полагаю здесь не должно быть сложностей с пониманием макроса.

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

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

Теперь пришло время посмотреть на секцию импорта. Она отличается от рассмотренной в предыдущем разделе здесь мы используем макрос library , который определён следующим образом:

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

Таким образом, макрос library создаёт заголовок таблицы импорта, вначале записывая смещение названия библиотеки DLL, а затем смещение, с которого начинаются имена импортируемых функций.

Далее следуют макросы import , определённые следующим образом:

Он создаёт тело таблицы импорта для каждой из импортируемых библиотек.

Вначале создавая таблицу смещений имён импортируемых функций, а затем записывая имена импортируемых функций. Более подробно о структуре PE-файла Вы должны прочитать в соответствующей литературе (например в туториалах, которые написал Iczelion).

После таблицы импорта создаётся таблица ресурсов:

В нашем примере мы используем только одну иконку.

Динамические библиотеки (DLL)

Последним в данном разделе рассмотрим простую динамическую библиотеку.

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

Мы рассмотрим создание динамической библиотеки на примере процедуры, возвращающей строку, содержащую текущую дату. Мы создадим два модуля один файл динамической библиотеки (dll2.dll) и файл использующий созданную нами библиотеку (usedll.exe).

Вот файл динамической библиотеки:

Первые строки format PE GUI 4.0 DLL и entry DllEntryPoint указывают компилятору создать РЕ-файл динамической библиотеки с точкой входа на метке DllEntryPoint.

Как Вы могли заметить динамическая библиотека практически ни чем не отличается от обычной программы Windows, кроме того, что входная процедура вызывается системой в четырёх случаях:

• Когда динамическая библиотека загружается в адресное пространство процесса (параметр fdwReason = DLL_PROCESS_ATTACH = 1);

• Когда динамическая библиотека выгружается из адресного пространства процесса (параметр fdwReason = DLL_PROCESS_ DETACH = 0);

• Когда создается новый поток в рамках динамической библиотеки (параметр fdwReason = DLL_ THREAD_ATTACН = 2);

• Когда разрушается (прекращается) поток в рамках динамической библиотеки (параметр fdwReason = DLL_ THREAD_DETACH = 3).

В обработке стартовой процедуры мы определяем значение параметра fdwReason и если динамическая библиотека была загружена или выгружена выдаём соответствующее сообщение.

В конце файла мы создаём секцию экспорта нашей библиотеки:

В таблице мы задаём имя файла динамической библиотеки и имена экспортируемых процедур.

Макрос export определён следующим образом:

Сперва, объявляются локальные метки и подсчитывается количество экспортируемых процедур:

Затем заносится смещение RVA имени библиотеки:

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

Далее объявляется метка начала массива смещений экспортируемых функций и создаётся массив их смещения:

Следом объявляется метка начала массива смещений имён экспортируемых функций и создаётся сам массив:

Затем объявляется метка начала массива смещений ординалов функций и создаётся массив ординалов экспортируемых функций:

Ну и в конце макроса записывается имя динамической библиотеки и создаётся массив имен экспортируемых функций:

Для более подробного ознакомления со структурой секции экспорта необходимо читать специальную литературу по структуре РЕ - файлов.

Теперь давайте посмотрим, на программу вызывающую нашу динамическую библиотеку:

Обычное графическое приложение не имеющее своего окна и ресурсов размером 2 кБ. Импортирует только три функции две предоставляемые системой Windows и одна написанной нами динамической библиотекой. Как видите подключение созданной нами динамической библиотеки, ничем не отличается от подключения стандартных библиотек Windows. В этом и заключается вся прелесть использования ФАСМ-а, он не берёт на себя слишком много, что в купе с гибким макроязыком позволяет сделать очень многое максимально просто.

Формат исполняемых файлов MS COFF (obj - файлы)

Использование obj-файлов в ФАСМ, лично мне, не кажется жизненно необходимым, однако использование этого формата возможно понадобится при создании проектов на С/С++. Именно на таком примере мы и рассмотрим формат файлов MS COFF.

Для примера напишем программу, выводящую МессаджБокс с текущей датой. Модуль на ассемблере будет составлять строку символов, а модуль на С++ будет выводить эту строку в МессаджБокс.

Вот модуль на ассемблере:

Обратите внимание на строку 2, где закомментировано определение точки входа в программу (_WinMainCRTStartup)если эту строку раскомментировать, то точка входа в программу будет именно в модуле на ассемблере. Результат работы функции записывается в переменную _outs и адрес (указатель на строку) возвращаем в регистре еах. В этом модуле используются макросы копирования строки в строку (StringCopyHTML ebx,day). Этот макрос не входит в поставку компилятора и содержится в файлах strings.mac и strings.asm он просто копирует строку (не включая нулевой символ), указатель на которую передаётся вторым параметром, в строку, указатель которой передаётся вторым параметром, после его выполнения в регистре еах количество скопированных символов. Эта процедура выдаёт строку типа: "День: 28 Месяц: 10 Год:2003". Для использования объектного модуля созданного на ассемблере необходимо в проект на С++ добавить созданный нами объектный файл (Project->Add to project->Files. . . в появившемся окне необходимо выбрать тип файлов obj и указать используемый файл). Теперь рассмотрим текст программы на MS Visual C++ 5.0:

Здесь ничего сложного: подключаем файл «windows.h», затем объявляем внешнюю процедуру, возвращающую указатель на строку символов с нулём в конце, объявляем переменную dat, как указатель на строку символов, и наконец функция WinMain в которой вызываем нашу функцию (Wind) на ассемблере и выводим результат в мессаджбокс. Внимательный читатель скажет: "Стоп, но в модуле на ассемблере функцию мы объявили как ?Wind@@YAPADXZ, а в модуле на С++ вызываем Wind". Всё правильно. Просто MS Visual C++ 5.0, к объявленным внешним (находящимся в скомпилированных модулях) процедурам добавляет дополнительные символы, для контроля соответствия типов передаваемых результатов из процедуры и переменных в процедуру. Вот краткая структура имени функций формируемых MS Visual C++:

Причём постфикс изменяется в зависимости от наличия передаваемых в функцию параметров. Если параметры передаются, то постфикс "@Z", а если параметры не передаются то просто "Z".

Типы вызова процедуры следующие:

Типы результата и передаваемых переменных имеют одинаковые обозначения:

Причём если передаётся (получается) не параметр, а его адрес (например char *) то перед обозначением переменной добавляется PA. Если параметры, получаемые из процедуры или передаваемые в процедуру, отсутствуют, вместо них ставится X.

Читатель может сказать: "Это как же нужно мозг морщить, чтобы всё запомнить и не перепутать ничего при составлении имени процедуры?". Такая работа имеет основное свойство: она не особо интеллектуальна, но муторна и действия при её решении вполне укладываются в рамках алгоритма. Отсюда вывод: компьютер на то и создан, что бы выполнять подобные задачи так пусть сам, и добавляет все эти префиксы, постфиксы и т.п. Напишем макрос, который будет объявлять процедуру составляя её имя из имени которое мы ему передаём и добавляя к нему все необходимые префиксы.

Использовать переменные длиннее 4 байт мы не будем, но думаю Вы сами сможете модернизировать макросы под свои нужды если понадобится.

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

Далее следует определение макроса:

В первой строке мы очищаем временную символьную константу, далее следует указание препроцессору обработать строку "dr fix dr#type" для всех значений параметров type начиная с первого. Эта строчка, просто создаёт константу содержащую все символы соответствующие всем получаемым процедурой параметрам. Например если в процедуру передаётся два параметра типа int, то dr будет эквивалентно HH. Далее следует указание препроцессору следующие строки обработать только один раз (common) в этих строках мы делаем видимой из других модулей программы метку (название) нашей процедуры и собственно следует содержимое макроса proc, рассмотренного ранее.

Полагаю, этот макрос не должен вызвать затруднений. Сложности в понимании может вызвать только строка "?#name#@@Y#calltype#returns#dr#@Z", объясню её более подробно. Сперва стоит знак вопроса (посмотрите табличку со структурой имени процедуры), после которого, значок номера (#), он говорит препроцессору, что далее следует символьная константа, которую следует склеить в одну метку с предыдущим текстом. Если константы с указанным именем не существует, то она включается, как есть. Рассмотрим последовательность действий препроцессора. Метка состоит из вопросительного знака, затем (без разделителей) добавляется, передаваемая макросу переменная name, после неё добавляется текст @@Y,после текста добавляется передаваемая макросу переменная calltype, затем переменная returns, потом составленная нами константа dr, и наконец постфикс @Z (или просто Z, если в процедуру не передаются параметры).

Всё. Макрос создан. Однако это ещё не всё. С таким определением процедуры не всегда можно использовать стандартные макросы enter и return т.к. тип вызова __cdecl предполагает, что стек после завершения работы процедуры будет очищаться вызывающей процедурой т.е. модулем написанным на С++, а стандартный макрос return сам очищает стек. Вот макрос, содержащий эпилог процедуры для типа вызова __cdecl:

Но не только эпилог нужно изменить, но и пролог тоже:

Полагаю эти два коротеньких макроса не вызовут затруднений.

Ну и пример использования данных макросов:

Функция IntToString преобразует 32-х битное без знаковое число (второй параметр) в строку (адрес строки передаётся первым параметром).

Модуль на С++ будет выглядеть следующим образом:

Думаю больше пояснений не нужно.

_Формат исполняемых файлов MS DOS

Формат исполняемых файлов MZ_

Программирование под ДОС в ФАСМ в принципе почти ничем не отличается от программирования под ДОС в любом другом компиляторе.

Вот простейший пример программы:

Как видите ничего сложного.

Формат исполняемых файлов СОМ

Если директива format не указана создаются файлы формата *.сом. Вот пример:

Думаю здесь всё понятно.

Этой функции нет в Win95, поэтому вам следует вначале выяснить, существует ли она, и работает только с отладчиками уровня приложения (таким как TD32). Она работает прекрасно. Давайте посмотрим, что написано о ней в справочнике по Win32 API.

Функция IsDebuggerPresent показывает, запущен ли вызывающий ее процесс в контексте отладчика. Эта функция экспортируется из KERNEL32.DLL.

• Аргументы

У этой функции нет аргументов.

• Возвращаемое значение

• Если текущий процесс запущен в контексте отладчика, возвращаемое значение не равно нулю.

• Если текущий процесс не запущен в контексте отладчика, возвращаемое значение равно нулю.

Пример, демонстрирующий эту функцию очень прост. Вот он:

Не правда ли, это красиво? Micro$oft сделал эту работу за нас :). Но, конечно, не ждите, что этот метод будет работать с SoftIce'ом, богом отладки.

Если вы смотрели статью "Wub95 Structure and Secrets", которая была написана Murkry/iKX, и опубликована в Xin-3, вы сообразите, что в регистре FS находится очень крутая структура. Давайте взглянем в поле FS:[20h]... Это 'DebugContext'. Всего лишь сделаем следующее:

<--- делайте, что хотите, нас отлаживают :)

Потому, если FS:[20h] равен нулю, нас не отлаживают. Наслаждайтесь этим маленьким и простым методом для обнаружения отладчиков! Конечно, это не сработает против SoftICE...

Я не знаю почему, но отладчики уровня приложения умирают, если программа использует SEH. Эмуляторы код, если мы делаем ошибки, умирают тоже :). SEH, как я писал в своей статье для DDT#1, используется для многих интересных целей. Хорошо, так как я не хочу рассказывать все это заново, я просто скопирую и вставлю мое старое описание :).

--[DDT#1.2_6]--------------------------------------------------------------- Хорошо, это очень простой туториал о Structured Exception Handler. Когда я увидел SEH, реализованный в вирусе, я подумал "Хорошо, это большая работа. Наверное, это было сложно реализовать". Поэтому я просто пропустил это. Но, как только мой Destiny сделал General Protection Fault'ы под NT, я понял, что я должен сделать что-то. И SEH - это единственный путь. Хорошо, мы можем сделать этоу очень сложным или очень простым для понимания. Конечно, я предпочитаю сделать это попроще :). % Установка фрейма SEH %

Сначала мы сохраняем его для нашей собственной безопасности простой строкой кода.

А теперь надо установить указатель на наш обработчик (например, представьте, что мы используем call для вызова настройки SEH, а наш обработчик идет непосредственно после этой инструкции call: мы можем использовать смещение ret).

Ок, просто как только возможно. Что насчет восстановления исходного SEH. Еще проще. Просто вызовите инструкцию, обратную первой.

Удивительно, что может сделать эта простая для реализации вещь для наших вирусов. Для меня (и мне было важно именно это использование SEH) наиболее главным было то, что я смог избежать всех этих отвратительных голубых экранов, когда мы запускаем наш Win95-вирус в среде NT.

% Пример использования SEH %

Мы можем скомпилировать данный пример следующим образом:

[...]

--[DDT#1.2_6]---------------------------------------------------------------

Я надеюсь, что вы поняли все это. Если нет... Ладно, забудьте об этом :). Также как и другие методы, представленные выше, он не работает по отношению к SoftICE.

Здесь я должен поблагодарить Super/29A, потому что именно он рассказал мне об этом методе. Я разделил его на две части: в этой мы рассмотрим, как использовать его из вирусов Rin-0. Я не буду помещать здесь программу-пример целиком, потому что она займет лишнее место, но вы должны знать, что этот метод должен выполняться в Rin-0, а VxDCall должен быть восстановлен из-за проблемы обратного вызова (вы помните о ней?).

Ок, мы будем использовать сервис менеджера виртуальных машин (VMM) Get_DDB, поэтому сервис будет 00010146h (VMM_Get_DDB). Давайте посмотрим, что говорится об этом сервисе в SDK.

• Определяет, установлен или нет VxD определенного устройства, и если установлен, возвращает DDB для этого устройства.

• Использует ECX, флаги.

• Возвращает DDB для определенного устройства, если функция была выполнена успешно.

• В противном случае возвращает ноль.

• Device_ID: Идентификатор устройства. Этот параметр может быть равен нулю для именованных устройств.

• Device_Name: Восьмибуквенное имя устройства, которое дополнено (в случае необходимости) пустыми символами. Этот параметр требуется только тогда, когда Device_ID равен нулю. Имя устройства чувствительно к регистру.

Ладно, вы наверняка удивляетесь, о чем идет разговор. Очень просто, поле Device_ID VxD SoftICE постоянно для всех программ, а так как оно зарегистрировано в Micro$oft'е, у нас есть оружие против этого отладчика. Его Device_ID всегда равно 202h. Поэтому мы можем использовать следующий код:

Где NotSoftICE должно быть продолжением кода вируса, а метка DetectedSoftICE должна обрабатывать тот случай, если наш враг жив :). Я не предполагаю здесь никакой деструкции, так как, например, на моем компьютере SoftICE всегда активен :).

Ладно, теперь идет другой метод для обнружения моего возлюбленного SoftICE'а, но основанный на той же самой идее, что и выше: 202h ;). Снова я должен поблагодарить Super :). Ладно, в Ralph Brown Interrupt list мы можем найти очень крутой сервис: прерывание 2Fh, функция 1684h.

Поэтому вы поместите 202h в BX, запустите эту функцию. А потом скажете... "Эй, Билли... Через какое место я могу использовать прерывания?". Мой ответ... ИСПОЛЬЗУЙТЕ VxDCALL0!!!

И наконец, чудесный трюк, которого вы ждали... Универсальный способ найти SoftICE и Win9x и в WinNT! Это очень просто, 100% основанно на API и без всяких "грязных" трюков, которые не идут на пользу совместимости. И ответ находится не так далеко, как вы думаете... ключ заключается в API, который вы уже использовали раньше: CreateFile. Да, именно эта функция... Разве это не прекрасно? Ладно, мы можем попытаться открыть следующее:

• SoftICE для Win9x : "\.\SICE"

• SoftICE для WinNT : "\.\NTICE"

Если функция возвращает нам что-нибудь, отличное от -1 (INVALID_HANDLE_VALUE), SoftICE запущен! Далее следует демонстрационная программа:

Это действительно работает, поверьте мне :). Тот же метод можно применить к "враждебным" драйверам, просто проведите небольшое исследование.

Ладно, вот я и рассказал о нескольких простых антиотладочных трюках. Я надеюсь, что вы сможете использовать их в своих вирусах без проблем. Пока!

Эта замечательная функция из ntdll.dll дает возможность добавить элемент (даже 2 элемента) в локальную таблицу дескрипторов. Вызов данной функции приводит к вызову функции PsSetLdtEntries в ядре. В этой функции производится довольно тщательная проверка дескриптора и селектора. Возможно, добавить дескриптор только если:

Его тип - ReadWrite, ReadOnly, ExecuteRead, ExecuteOnly, или Invalid.

Это не системный дескриптор (что автоматом лишает нас прорулить в ядро с помощью Callgate).

После этих проверок происходит вызов Ke386SetLdtProcess->Ki386LoadTargetLdtr->KiLoadLdtr-> asm lldt.

Антиэмуляция

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

Большинство считает, что, будучи выполненным в OS Windows, данный код сгенерирует исключение и произойдет вызов SEH. Но это так не во всех случаях. Ведь stosd эквивалентна паре инструкций:

В общем случае в пользовательской программе es=23h, указывает на 4ый дескриптор в LDT, который описывает сегмент с базой 0. Тогда обращение произойдет по нулевому линейному адресу и действительно возникнет исключение. Но если, например, добавить свой дескриптор с базой 401000h и в es поместить селектор, который содержит его номер, то в результате выполнения вышеприведенного кода произойдет обращение по адресу 401000h, где может находиться доступный для записи сегмент данных программы.

Приведу в качестве иллюстрации код, который вводит в заблуждение эмулятор NOD'a (на других АВ не проверял) и некоторых программистов.

Следует обратить внимание также на то, что перед вызовом АПИ следует обязательно восстановить значения сегментных регистров, так как обращение к какому-либо адресу приведет к тому, что на самом деле произойдет обращение по адресу бОльшему на базу, указанному в дескрипторе. Другими словами, если где-то в коде MessageBoxA встретится команда типа mov eax,es:[77d91234h], то на самом деле будет попытка записи в еах значения ячейки по адресу 78192234h, что, скорее всего, вызовет исключение.

Антиотладка

Основана на том же принципе, только с учетом того, что формируется дескриптор для сегмента кода. Всем известный отладчик OllyDbg при изменении значения cs путем выполнения дальнего вызова, либо перехода в сегмент с другой базой тихонько выпадает в осадок. Приведу код, иллюстрирующий данный подход.

Удачная комбинация

Также можно рассмотреть комбинацию двух данных подходов - добавить два дескриптора с одинаковой базой: один для кода, один для данных. После этого пройтись по всем модулям процесса, пофиксить релоки с учетом новой базы, да и сам PEB тоже, наткнутся на кучу "подводных камней", после чего спокойно, загрузив в сегментные регистры новые селекторы, вызывать АПИ, не восстанавливая оригинальные значения сегментных регистров.

На этом заканчиваю статью, wasm.ru forever :)