несколько вопросов о стeке

REX - Register-EXtention
R8-R15 - дополнительные регистры (registers)
R0-R7 - раширенные EAX-EDI (они же AX-DI), поэтому для них логично использовать мнемонику RAX-RDI )

 

RuAsm

Код (Text):

1.          push MB_OK;0
2.          push szDlgTitle
3.          call @f
4.          db "1234567890",0
5. @@:   push 0    ;hWnd=0
6.           call _imp__MessageBoxA@16

 

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

 

Сглупил, но можно push '09'/push '8765'/push '4321'
или так

Код (Text):

1. string db "1234567890",0
2. ....
3. mov esi,offset string
4. mov edi,esp
5. mov ecx,10
6. rep movsb
7. add esp,10

 

Ясно. Спасибо.
Было би прикольно если б сделали что-нить типа MEAX, MEBX, MECX.
Mega Extended AX
А ещё такой вопрос - кто как думает, чем обосновано пожертвование в х64 однобайтовыми inc/dec.
Мне просто не сильно понятно, потому как есть по моему гораздо более бестолковые команды типа lahf/sahf.
А убрали так горячо всеми любимые inc и dec

 

cppasm
Ну, во-первых inc/dec - это 16 кодов (40-4F), а lahf/sahf - только два.
Во-вторых lahf/sahf пожертвовали просто так. Т.е. не гарантируется, что эти команды поддерживаются процом в 64-м режиме и определить сие можно по cpuid 80000001 ecx.0.
В-третьих, инструкции inc/dec Intel применять не рекомендует из соображений оптимизации, как создающую ложную зависимость по флагам и советует заменять их соответственно add xx,1/sub xx, 1. (странно, вообще-то считается, что х86-64 придумали AMD, у которых такой особенности в процессорах нет - подозрительно! )
Ну а в четвертых, и самых главных - пожертвовали только ОДНОБАЙТНЫМИ кодами для inc reg/dec reg, а двухбайтную форму FF /0 и FF /1 никто не отменял. Так что ничего страшного, пользуйтесь и дальше, просто код inc eax будет не 40, а FF C0.

скажи спасибо, что не R64EAX, R64ECX и т. д. а EAX переименовать в R32EAX в целях совместимости

 

С чего это они бестолковые. Иногда прикольно сделать sahf а не pushf/pop ax

 

Ну про это я в курсе - я поэтому и спросил.

Это я так и не понял
inc/dec и add/sub на флаги влияют одинаково за исключением CarryFlag. В чём тогда такой большой негатив inc/dec.

О, вот этого я и не заметил.
Т.е. я знал что пожертвовали однобайтными - а про альтернативную форму забыл.
Постепенно начинают убирать неоднозначности в кодировании типа add reg/mem,reg и add reg,reg/mem
С таким раскладом там если пошариться по add, sub и так далее ещё и на 128 бит расширение насобирать можно

Ну во первых я написал не совсем уж бестолковые, а БОЛЕЕ бестолковые чем inc/dec.
А во вторых - ну иногда удобно. Но сам ты часто используеш?
Я например только для переноса состояния fpu использовал.
Типа

Код (Text):

1. fstsw ax
2. sahf
3. jcc

Но легко заменяется на push ax/popf.
А inc/dec гораздо чаще используется.

 

нет :P

 

n0name

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

 

Quantum
такой изврат затрудняет отладку =\
думаешь, что вызов подпрограммы, а обломись - всего лишь извращенный push

 

cppasm

Ustus

Вот именно, не каких попало 16 кодов, а в непрерывном диапазоне 40-4F, что упрощает их декодирование

cppasm

Вот именно, поэтому inc\dec в отличие от add\sub вынуждены ждать завершения предыдущей операции, изменяющей флаг CF, т.е. add\sub зависимы только по регистрам, а inc\dec еще и по флагам. По сути это спец.операции, которые нужно использовать только там, где нужно сохранить CF, а народ из-за симпатичности\компактности использует их повсюду вместо add\sub 1
Ustus

Такая "особенность" есть у всех out-of-order процев, начиная с PPro. Просто в P4 Intel задрали частоты сверх меры, в результате чего у них 1) установка флагов производится не в том же такте, а (как минимум) в следующем, и 2) операции, использующие или частично изменяющие флаги (adc, sbb, setcc, cmovcc, cld и т.п.) намного более тормозные, чем в других процах, и сравнительно быстрые inc\dec тут скорее исключение, чем правило.
PS: Кстати латентность add\sub в 0.5 такта в Northwood'ах это в некотором роде фикция, т.к. за 0.5 такта складываются\вычитаются только 16 бит, полный результат готов только через 1 такт, а флаги через 1.5 такта. Ну а в Prescott'ах вообще фиг знает когда )

 

leo

Немного разная - согласно Фогу (и пока не противоречит моим личным наблюдениям) на процах AMD (по крайней мере, K8) флаги обрабатываются не как единое целое, а как четыре независимые группы - 1: ZF, SF, PF, AF; 2: CF; 3: OF; 4: остальные. Поэтому (пример из того же Фога:

Поэтому ЛОЖНОЙ зависимости по CF у них в принципе быть не может. Но так как при оптимизации приходится закладываться на максимальное количество закидонов наших кремниевых друзей... Тем более, что стоит это всего два байта на x86 и один на x64, а для eax и вовсе - один байт на x86 и ничего на x64.

Хмм... вот в таком аКСепте я как-то даже... Но ведь при грамотном построении более важно troughput, оно же вроде 1/4? или меня здесь тоже обманули?

 

Ustus

Мда, отстаю от жизни В качестве жалкого оправдания могу сказать, что скромные мануалы AMD умалчивают как об этой фиче, так и о наличии\отсутствии особенностей inc\dec и это ес-но вызывает некие подозрения, но на вскидку мне казалось, что особые манипуляции с переименованием регистра флагов выглядят достаточно сложными и не вписывются в простую как валенок архитектуру AMD Но с разбивкой флагов на группы все становится на свои места, за что тебе и Фогу большой сенкс

Я не о том, что важно, а что нет и в каких ситуациях. А о том, что Intel просто умалчивают о смысле латентности 0.5 такта и что эта латентность рулит только для операций fast ALU, которые могут работать по принципу конвеера с половинками операндов. А если результат fast-операции нужно передать в slow ALU или в load address, то они вынуждены ждать готовности всего операнда - отсюда и additiоnal latency, о которой говорит Фог. Ну а флаги для setcc\cmovcc и т.п. будут готовы еще позже. Вот такая хитрая латентность - 1 пишем, 2 в уме

 

Вчера не успел выложить. В аттаче exe под XP

Код (Text):

1. .686P
2. .model flat
3. include windows.inc
4. includelib user32.lib
5. extern _imp__MessageBoxA@16:dword
6. .code
7. start:  push 000373635h
8.     push '4321'
9.     mov edi,esp
10.     push MB_OK or MB_ICONASTERISK
11.     push edi
12.     push edi
13.     push eax;hWnd=0
14.     call _imp__MessageBoxA@16
15.     pop eax
16.     pop eax
17.     ret
18. end start

 

Растолкуйте плз вот это:

Код (Text):

1. add eax,1 ; Modifies all arithmetic flags
2. inc ebx ; Modifies all except carry flag. No false dependence
3. jc L ; No false dependence on EBX   << Вот здесь у Intel ложная зависимость по CF :(

Откуда на jc может появиться ложная зависимость по флагам на Intel?
Или там комментарии неправильные?
По моему jc не будет дожидаться выполнения inc ebx как раз из-за того что она CF не меняет (по крайней мере это было бы не логично).
Или процессор дожидается установления всего регистра флагов несмотря на то что в условном переходе используется только CF?

 

cppasm

Вот именно. 4-6 тактов на PentiumM, 7 на Core2, если верить Фогу. (сам проверить сейчас не могу, в радиусе эн метров не одного Конро ) У Intel-процессоров (точно для PIII-PM-Core2, не знаю точно для NetBurst) - происходит flag stall при чтении немодифицированой части регистра флагов. Почему это не пофиксили в Conroe и вроде и не собираются фиксить в Penryn - фиг его знает... Возможно потому, что фича очень старая и все компилеры уже заточены ее обходить, а раз так - зачем напрягаться? Да и не думаю, что это технологически просто - это же регистровый файл ковырять придется...
leo

Цинично скромничаешь мне бы так отставать просто я совсем недавно этим интересовался. ))