В каком случае программа будет работать быстрее. #1: Код (Text): .IF ax == button1ID shr eax,16 ... .ELSEIF ax == button2ID ... #2: Код (Text): .IF ax == button1ID shr eax,16 ... .IF ax == button2ID ... Таких случаев много встречается. Знаю, что даже если в одном из случаев скорость выполнения программы увеличится, то она будет совсем незначительна, но все таки интересно было бы узнать.
Если представить эти masm32-макросы в виде чистого ассемблера, то получится примерно так: (кстати, во втором случае перед вторым .IF надо написать .ENDIF) ------------------------------- Код (Text): #1 .. if: cmp ax,button1ID jne button2 shr eax,16 ... elseif: cmp ax,button2ID jne exit ... ------------------------------- #2 .. if1: cmp ax,button1ID jne endif1 shr eax,16 ... endif1: jmp if2 if2: cmp ax,button2ID jne exit ... ------------------------------- т.е в конечном счёте макросы .if-.elseif-.endif просто делают приблизительно такую конструкцию: ------------------------------- .if p1==p2 ... .endif = if: cmp p1,p2 jneq endif ... endif: ------------------------------- .if p1==p2 ... .elseif p1==p3 ... .endif = cmp p1,p2 jne elseif ... elseif: cmp p1,p3 jne endif ... endif: ------------------------------- и это значит, что первый код более быстрый т.к там не генерируется дополнительная инструкция jmp. Вроде так.
Только все наоборот - дополнительный jmp будет именно в первом варианте, а во втором его не будет Код (Text): #1 cmp eax,button1ID jne _elseif shr eax,16 jmp _endif ;тут из-за elseif мы должны идти сразу на endif _elseif: cmp eax,button2ID jne _endif ... _endif: #2 cmp eax,button1ID jne _endif_1 shr eax,16 ;т.к. elseif нет, то в любом сл.идем на второй if _endif_1: cmp eax,button2ID jne _endif_2 ... _endif_2: Но именно первый вариант с безусловным jmp и является потенциально более быстрым При первом проходе кода рулит статическое предсказание переходов. В варианте #1 процессор обнаруживает jmp на выходе декодера и перескакивает на _endif, сбрасывая всего 5-6 стадий конвеера (от фетча блока инструкций до выхода декодера). В варианте #2 вместо jmp стоит условный переход jne вперед, который по правилам статического предсказания предполагается не выполняющимся и проц идет не в ту степь, продолжая спекулятивно декодировать и выполнять следующие инструкции. Пройдя весь конвеер (~10 стадий на P3,PM,атлонах, ~20 на P4 и ~30 на P4E) второй cmp и jne добираются до исполнительного блока и тут выясняется, что условие jne выполняется (т.к.eax=button1ID), проц.сбрасывает все стадии конвеера и начинает грузить код по адресу _endif_2. Т.е. при первом проходе вариант #1 платит штраф только 5-6 тиков, а вариант #2 все 10,20,30 тиков в завис-ти от проца. При повторных проходах рулит динамическое предсказание, поэтому на безусловном jmp теряется от силы 1 тик (на P4 м.б. 0 - смотря как посторена трасса в Т-кэше). А в варианте #2 все зависит от статистики выполнения перехода jne _endif_2 (т.е. от чередования eax = button1ID или 2ID). Если проц угадывает, то будет также не более 1 тика, если не угадывает, то опять получим штраф 10,20,30 тиков на сброс всего конвеера Вот такие пироги
leo я даже некоторых таких слов незнаю%))). Углубленные познания. А что надо читать, в какую сторону копать, чтобы тоже так детально уметь разбираться? Наверное знание дизассемблирования(отлаживания)+архитектуру процессоров...?
Насчет дизассемблирования трудно сказать, т.к. дизассемблировать код, имея исходник на ассемблере - это что-то типа масло масляное ИМХО лучше не пользоваться .if\.elseif, а писать самому ручками на чистом асме, тогда и вопросов не будет. Тем более, что для проверки на == 0 masm по непонятной причине использует OR EAX,EAX вместо TEST EAX,EAX, рекомендуемой Intel и AMD. На первый взгляд разницы никакой, а на самом деле OR переписывает содержимое регистра EAX, т.е. с точки зрения тупого процессора "изменяет" EAX и тем самым вносит ненужную зависимость по данным для следующих операций, использующих EAX Что касается переходов и вообще низкоуровневой оптимизации, то лучше всего изучать аглицкие мануалы по оптимизации от Intel и AMD, а также pentopt.pdf by Agner Fog. Правда, на wasm.ru в разделе Статьи\Оптимизация есть русский перевод предыдущего издания А.Фога (by Aquila). Но загвоздка в том, что большая часть первого издания посвящена устаревшим процам PPlain и PMMX, про которые вообще лучше не вспоминать, т.к. современные процы устроены совершенно иначе. Поэтому при недостаточно внимательном и критическом прочтении в башку может засесть ненужная каша и устаревшие представления о U и V-конвеерах, "спариваниях" и т.п.
