Итак, давайте более подробно рассмотрим «динамическую рекомпиляцию»
Как я уже писал ранее, скорость достигается за счет того, что создается «кеш» ранее откомпилированного кода, любая программа это в конечном итоге цикл, т.е. например при загрузке уровня в каком-нибудь файтинге наступает момент когда весь код, используемый в данный момент времени становится откомпилированным т.е. происходит только его исполнение, из этого стоит сделать вывод чем лучше откомпилирован код, тем выше скорость его исполнения:
Ну для начала рассмотрим пример из PCSX:



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

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



Если компилятор встретит такой код он загрузит регистр r2 в случае x86-проца, например в EAX, далее r3 в ECX, потом сложит регистры и загрузит результат сложения в EDX, далее при компилировании второй инструкции сложения уже EDX сложит с EAX, и в конце блока измененные регистры и только измененные загрузит обратно в память, заметьте R1 в EDX ни разу из памяти не был считан ибо его значение нас не интересует:

Далее пример кода откомпилированного кода:



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

Кроме, «регкешинга» при компиляции кода применяется также сверстка констант, дело в том что за постоянную длину команд необходимо платить и зачастую высокую цену, не соизмеримую с выгодой от постоянной длины команды, т.е. чтобы загрузить 32бита в регистр в MIPS необходимо обычно две команды:


Что же сделает компилятор кода встретит такой кусок кода,
На первой команде он пометит регистр R1 как константу и присвоит ему значение IMM_HIGH, на второй команде он проверит R1 не константа ли он и соответственно убедившись что да, прибавит к константе IMM_LOW, и только на третьей команде он впервые что-то запишет в память для последующего исполнения:

Итог весь код будет представлен одной инструкцией:



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

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

Бывают иные более сложные способы оптимизации, но они уже узкоспециализированы, например: при оптимизации фпу команд, можно попробовать отслеживать, а нет ли однотипных парных команд сложения, вычитания, умножения и т.д. т.е. пробывать собирать эти пары и выполнять нашими любимыми SSE1,2,3…, но это довольно сложно и крайне сложно отлаживаемо, но возможность такая существует

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

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

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

Да конечно, напрямую в машиные коды, по общепринятым правилам, нельзя изменять ebx, esi, edi, ebp регистры, соответственно их обычно сохраняем еще на входе в "recExecute".

-- 06 дек 2010, 07:30 --



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

Признаться, я тоже "поплыл".
Wind, а может есть возможность как-то на картинках изобразить что и откуда берется?)

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

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




Ну и ф-ии для создания, сброса карты памяти:



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

Я "плыву" ещё дальше. =)
Wind, вот лично мне в твоих примерах не хватает самих простых примеров. Т.е. тот же регкешинг был бы понятнее, если бы ты написал, что вот в исходном состоянии было то-то, применяем такую-ту функцию, алгоритм которой построен так-то (сначала алгоритм на псевдо языке, а потом уже пример на с++) и в итоге получаем вот это. Вот так мне было бы понятнее (думаю, не только мне). А в приведённом тобой примере нет ни исходного положения, ни цели, ни вывода. Только куски кода, которые не всем будет легко понять.
Хотелось бы объяснения как для "самых маленьких".

Сильно заинтересовался темой эмуляции. Получилось написать эмулятор Chip-8(но там уж до безобразия всё просто, всё-таки не "настоящая" система). Сейчас пробую написать эмулятор GameBoy, и возник вопрос - для чего процессору флаги(Carry, Zero, Overflow и т.д.), как они работают, как и для чего они применяются? Может быть, кто-нибудь может описать или дать ссылку на описание.
P.S. А чего забросили данную тему, я думаю она была бы полезна очень многим в завершённом виде.

Флаги процессора это ключевые свойства АЛУ и нужны для управления поведением. Т.е., если процессор будет только что-то вычислять, то получается обычный калькулятор. А вот если процессор будет менять свое поведение в зависимости от результата вычислений - это уже другое. Сами флаги это просто признаки свойства полученного результата после арифметической или логической операции АЛУ над операндами. Например, если результят вдруг стал равен 0, то взводится флаг Z, а значит процессор может распознать эту ситуацию командой условного перехода и изменить свое поведение (перейдет по другой ветке программы). Ну вот как-то так, на пальцах.

Спасибо за разъяснение, действительно помогло.