Привет всем.

Идея следующая:
есть инструкции

TEST  EAX,imm32
TEST  r/m32, imm32

При условии, что опренд находится в диапазоне 0..7Fh, они полностью эквивалентны соответственно таким инструкциям (единственная разница - меньший размер):

TEST  AL,imm8
TEST  r/m8, imm8

Учитывая, что существуют официально рекомендованные и документированные intel'ом короткие варианты jmp/push & sign extended and/add/or/xor, было предложено производить подобную оптимизацию и для инструкции TEST компилятором FASM.

(Privalov высказал уже предварительное согласие..)

Да, для TEST отсутсвует SIGN EXTENTION через бит S.
Возможно для тех кто не видит эквивалентности (slappy coders) и стоит это делать в FASM на уровне компиляции.
Но подобных случаев вообще много.
Можно решать их просто на уровне макросов.
Правда, для случая с регистрами макрос будет громоздким,
и нужен спец по опкоду для такого макроса. Я так понимаю что нужно будет из имя регистра преобразовать в код и сгенирировать опкод уже в макросе с битом w = 1. При этом учесть не является ли код 000 чтобы в случае EAX,AX кодировать как A8 imm 8 а не F6 /0 imm8.

The Svin
Но подобных случаев вообще много.

А какие собственно? Даже для TEST есть полная еквивалентность только потому что результат операции AND никуда не записиваеться.

Между прочим, ИМХО, етот вариант для TEST будет в следующей версии FASMа.

The Svin
Возможно для тех кто не видит эквивалентности (slappy coders) и стоит это делать

Тут дело немного в другом..
Иногда эту эквивалентность очень сложно заметить.
Значение 2-го операнда может быть зарыто в *.inc файлах для win API.
Все же этот API писали Си программисты..
А если не win API, то тогда можно зачастую и совсем без TEST.

На FASM, макрос не очень сложный будет, но в данном случеа, это не совсем тот вариант, как извесные случай оптимизации MOV.
Можно сказать, попытка узаконить некий аналог SAL/SHL.


johnfound
етот вариант для TEST будет в следующей версии FASMа.

Хорошо, если так.
Надеюсь, tom tobias отвлеченными от темы рассуждениями не испугал Privalov'а :)

S_T_A_S_
Надеюсь, tom tobias отвлеченными от темы рассуждениями не испугал Privalov'а :)

Томаш сам может каждого испугать. :D Вопрос только в том насколько он занят сейчас. A мне кажеться что он уже получил книги об AMD64. :)

Пока.

А какие собственно? Даже для TEST есть полная еквивалентность только потому что результат операции AND никуда не записиваеться.


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

Надеюсь это понятно.
Что до определённого приёма, а именно в данном случае выполения лишь над частью операнда какого-то действия, то разумеется ты не прав если считаешь, что только в test и только из-за того что операнд незаписывается есть эквивалентность.
что
xor eax, 1
что
xor al,1
приведут к одному и тому же результату в eax.
тоже касается и например
что
or eax,0ff00h
что
or ah,offh
приведут к тому же результату в eax
причём во втором случае опкод будет на 3и байта короче.
Подобные случаи и имелись ввиду под "многими"

S_T_A_S,
По поводу API - хороший аргумент, я как-то неподумал когда писал про slappy coders :)

The Svin

or eax,0ff00h
or ah,offh 

Эти команды не эквивалентны все же.
По разному влияют на флаги SF & PF.

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


А по поводу API хорошо получилось :D


johnfound
Томаш сам может каждого испугать. :D

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

S_T_A_S_

Момент. А почему они эквивалентны?

TEST  EAX,imm32
TEST  r/m32, imm32

--------------------------------

The Svin

Кстати, я недавно набрасал интересную таблицу для разбора опкодов. Это понадобилось кое-кому для дизассемблера.
Ты сейчас на каком мыле доступен?
А то я тебя не слышу в Эхе.

The Svin

or eax,0ff00h
or ah,offh
Эти команды не эквивалентны все же.
По разному влияют на флаги SF & PF.


Ну давай поподробней рассмотрим данный случай.
1. Оговорюсь для общего случая замены, - да, действительно, эквивалентность при других константах будет в том случае, если идёт проверка на наличие бит в test. Т.е. важно состояние флага ZF а остальные по барабану.
Это наиболее распространённый случай использования тест.
Есть возможность, действительно, комплексной проверки, когда после одного test строится сложный управляющий бранч, где сразу обрабатывается несколько показателей во флагах тогда твоё замечание имеет резон.

2. Далее перейдём к "простым" проверкам на SF, PF
Во первых о чём мы говорим?
Об замене оригинала на эквивалент. В данном случае
or eax,00FF00h - оригинал.
or ah,0FFh - эквивалент.
И в том и в другом случае результат абсолютно известен уже на стадии написания программы. Флаги SF и PF использовать после такой операции - типа какая то специфичная экзотика.
Поскольку без всякого выполнения видно что
а) в обоих случаях PF будет равен 1.
б) в первом случае SF будет 0 а во втором 1.
Это ясно и так. Чего их проверять то?

По поводу мыла - оно то же.

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

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

The Svin

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

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

Скажу тебе только:

1. Главное, чтобы этом плохое закончилось
2. Купи себе новый диск
3. Мыло напишу.

The Svin
И ещё.

Совет: Забей. Забей и не мучся.

Если это таки твоё, оно тебе надо, то пройдёт время и ты к этому возратишься. Я думаю пока так. Из своего опыта.

The Svin

"Миллиард лет до конца света" - значит что-то действительно стоящее выходит. Присоединяюсь к Edmond'y - Don't give up! Диск, резак для бэкапа и побольше оптимизма.

xzazet

Гм...
Получается, что если например ты придумываешь то, к чему шёл, тебя убирают.

Тогда мне не долго ещё жить осталось :/

Edmond
А почему они эквивалентны?

TEST  EAX,imm32	эвивалентна по результату	TEST  AL,imm8
TEST  r/m32, imm32	эвивалентна по результату	TEST  r/m8, imm8

В случае если операнд находится в пределах 0..7Fh
Результат работы этих инструкций, а именно - флаги, полностью одиаковы в 2х случаях. Размер опкода, конечно, разный.

На примере EAX/AL:

 byte 0    byte 1   byte 2   byte 3 
01234567   01234567   01234567   01234567
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX  --  аккумулятор
YYYYYYY0   00000000   00000000   00000000  --  2nd
ZZZZZZZ0 00000000   00000000   00000000  --  "временный результат"

(Zi = Xi AND Yi)

ZF = BitwizeAND(Zi[0..7])
SF = bit 31 = 0
PF = BitwiseXNOR(Zi[0..7])
CF = 0
OF = 0


 byte 0    byte 1   byte 2   byte 3 
01234567   01234567   01234567   01234567
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX  --  аккумулятор
YYYYYYY0   ........           ........           ........  --  2nd
ZZZZZZZ0 ........           ........           ........  --  "временный результат"

(Zi = Xi AND Yi)

ZF = BitwizeAND(Zi[0..7])
SF = bit 7 = 0
PF = BitwiseXNOR(Zi[0..7])
CF = 0
OF = 0

Вот если 2й операнд 80h..FFh, то тогда получаем случай, о котором пишет The Svin, т.к. состояние SF будет различаться, и это надо уже учитавыть при написании программы (конечно, он редко используется)



The Svin

И в том и в другом случае результат абсолютно известен уже на стадии написания программы. Флаги SF и PF использовать после такой операции - типа какая то специфичная экзотика.

Тут я согласен про экзотику и со всеми остальными вещами.
Но если это сделать на уровне компилятора, то что из этого получится - сказать трудно.

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

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


Т.е. это несколько другой случай все же.
А при TEST, в данном варианте, можно просто тупо менять опкоды - это будет совершенно прозрачно для программы/человека.
Конечно, это будет видно в отладчике, и в случае хитрого мутирующего кода то же надо учитывать.
Но для таких целей можно будет использовать явное указание размера операнда.
Т.е. данные пары команд ведет себя точно так же, как другие варианты с короткими/длинными опкодами.
Единственная разница - про возможность такой замены явно не написано в документации буквами. Только цифрами.
Понятное дело в MASM так сделать нельзя уже, а вот FASM - развивается :)