Comments 28
eax+edx*N (так ведь?), но ЧТО это значит?А вообще, это действительно интересно, я видел, что компиляторы применяют инструкцию
lea вместо арифметики, когда нужно что-то умножить и сложить, но не знал, что один-единственный mov тоже умеет вычислять такую арифметику.
PS Берется текущее содержимое 32-разрядных регистров EDX и EAX, над ними проводятся соответсвующие арифметические манипуляции. Получившийся результат используется как адрес памяти по которому нужно взять значение и положить в регистр AL. Но не все 32 бита, а только 8. Потому что AL — это младшие 8 разрядов регистра EAX. Вроде ничего не перепутал.
Естественно это все происходит на этапе выполнения с использованием тех значений, которые оказались в регистрах на данный конкретный момент.
результат вычисляется на стадии компиляции?
Компиляция — не вполне правильно.
В большинстве диалектов ассемблера для x86..64 есть макроподстановка и непосредственная трансляция в машинный код (плюс, связывание, конечно).
А это — вариант базово-индексной адресации.
Т.е., это не constexpr в C++ и не вычисление транслятором, а компоновка из данных значений нужной команды: транслятор не вычисляет ничего.
Так а транслятор переведет эти mov в разные инструкции в машинном коде же?
В зависимости от типа операндов машинный код будет разным для инструкций.
Тогда это не татак интересно уже, хоть и забавно.
Эта программа переводит .c код (или обычный машинный код) в машинный код, который состоит только из одной команды move но с разными аргументами.
И штука реально прикольная )
И про обычный (а не макро) ассемблер, у которого каждая мнемоника имеет вполне четкий байт-код, т.е. мнемоника (ну или команда, или инструкция) — это просто название для соответствующей кучки кодов, в которую она всегда однозначно превращается, и по которой и работает процессор.
Поэтому мнемоника mov имеет вполне четкое отражение 1-в-1 в машинном коде.
Если взять код программы уже в mov-ах, то там будет постоянно повторятся один и тот-же код каждую новую строчку — это и есть код мнемоники mov, а дальше будут идти ее аргументы.
Это если просто, а если сложно, то код mov в x86 тоже не постоянный и варьируется, т.к. это указывает на тип mov операции, например «88» это «mov [di],dl» а «89» это «mov [si],cx» (коды по памяти, могу ошибаться с точным значением).
Т.е. в обычном асме одна команда = одному набору кода + коды аргумента.
Просто конкретно для mov — это интервал кодов, т.к. туда зашит тип mov — пересылка ли из регистра в регистр, или, например, косвенная пересылка и тд.
Обычный асм — только для конкретной системы, пример — аналог команды асма «mov» x86 для Z80 будет «ld» с абсолютно другим кодом — т.е. и код будет отличаться и мнемоника.
А вот макро-ассемблеры и тд — там уже да, может быть и под разные системы и т.д.
Вот такая вот штука.
Ну, в целом, это примерно то же самое что я и говорил, но тем не менее, машинный код инструкции — это не просто число — это адрес в таблице соответствия инструкции в процессоре. И mov с кодами 88-89 (я тоже не помню уже коды по памяти) — это две разных команды, которые пойдут на разные группы транзисторов в процессоре.
И, кстати, вы же рассматриваете всерьез идею перейти только на mov-инструкции по причинам, которые перечислены в статье? В статье есть замечание что это просто игрушка. Выглядит забавно, доказывает что-то, но новые инструкции вводят в процессор не просто так. Если новая инструкция может сэкономить полтакта на частых операциях — это уже один из поводов ее добавить. По крайней мере на CISC так точно было (привет, Pentium MMX).
И mov с кодами 88-89 (я тоже не помню уже коды по памяти) — это две разных команды, которые пойдут на разные группы транзисторов в процессоре.Группа команд одинаковая «mov», а вот тип команды да — разный. Как уж там куда в процессоре пойдет — зависит от того, как конвеер сделан, например mov для регистр-в-регистр, ЕМНИП, будет выполнятся одинаковым конвеером (ну или транзисторами :))
А Долан как раз про это и писал — по сути группа mov — это отдельный ассемблер в ассемблере )
И, кстати, вы же рассматриваете всерьез идею перейти только на mov-инструкции по причинам, которые перечислены в статье?Я это рассматривал как один из вариантов обфускации ну и просто как забавный факт.
Неужели неинтересно посмотреть производительность такого кода?
Да, про сравнение тоже не понял. Но сравнение предполагает условный переход, а, вроде бы, было заявлено, что программа получается вообще без ветвлений.
Сравнение делается через вычитание, а вычитание через сложение и представление в дополнительном коде.
Для 11 и 100:
mov в ячейку памяти #11 значение 0
mov в ячейку памяти #100 значение 1
mov в регистр данные из ячейки #11
Если бы числа которые мы сравниваем были одинаковые, то в регистре оказалась бы 1, в нашем же случае в ячейке так и лежит 0.
А вот, видимо, нет там jmp.
Код выполняется без ветвлений
Согласно идее Стивена, правильно написанный блок кода может либо что-то делать, либо не делать, в зависимости (только!) от исходного состояния системы. То есть ветвление отсутствует как класс, если абсолютно все инструкции исполняются последовательно.
Случайно нашёл компиляцию Doom: github.com/xoreaxeaxeax/movfuscator/tree/master/validation/doom
Но:
The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.
M/o/Vfuscator2, безумный компилятор