Исходник:

// first.cpp
int main(void)
{
return 0;
}


Скомпилировано cl /MD first.cpp и скормлено IDA:
[Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86]

.text:00401000 sub_401000 proc near ; CODE XREF: start+13Ep
.text:00401000 push ebp
.text:00401001 mov ebp, esp
.text:00401003 xor eax, eax
.text:00401005 pop ebp
.text:00401006 retn
.text:00401006 sub_401000 endp


Скомпилировано icl /MD first.cpp и скормлено IDA:
[Intel(R) C++ Compiler for 32-bit applications, Version 7.0 Build 20021018Z]

.text:00401000 sub_401000 proc near ; CODE XREF: start+13Ep
.text:00401000 push ebp
.text:00401001 mov ebp, esp
.text:00401003 sub esp, 3
.text:00401006 and esp, 0FFFFFFF8h
.text:00401009 add esp, 4
.text:0040100C xor eax, eax
.text:0040100E mov esp, ebp
.text:00401010 pop ebp
.text:00401011 retn
.text:00401011 sub_401000 endp

Для чего Intel Compiler добавил шаманство с sub esp, 3 / and esp, 0FFFFFFF8h / add esp, 4?
Может это выполняется за меньшее число тактов? И еще тогда ворпос - как замерить, сколько
тактов требует тот или иной фрагмент кода (asm) не прибегая к расчетам?

Спасибо

По виду кода оптимизирован он вроде для Pentium4, должен выполниться быстрее. Замерить можно через VTune.

cmpw
Наверное, чтобы "хитро" выровнять указатель стека.

Похожий вопрос вопрос по листингу асма

Количество тактов можно посчитать с помощью инструкции RDTSC.
Поищи в форуме. Подобных вопросов было уже много.

Спасибо за ответы. Но вопросы еще есть.

2dragon
А как объяснить, что больший по размеру код будет работать быстрее на P4? Спасибо за инфо про VTune.

2q_q
А зачем его сначала менять (sub esp, 3), а потом выравнивать?

2SolidCode
Спасибо за инфо о RDTSC, я начну с VTune - может оно проще.

cmpw
зачем его сначала
Стек "растет" от старших адресов к младшим, вычитают чтобы "железно" не испортить его "нижнее" содержимое.

как объяснить, что больший по размеру код будет работать быстрее на P4
спариванием инструкций, разворачиванием циклов, отсутствием условных переходов, etc...

Стек "растет" от старших адресов к младшим, вычитают чтобы "железно" не испортить его "нижнее" содержимое.

Ну это понятно. Я про то, что нахера вычитать и тут же прибавлять обратно?

спариванием инструкций, разворачиванием циклов, отсутствием условных переходов, etc...

Это я и сам написал. Интересует конкретно - как в данном случае это положительно сказывается. На пальцах объяснить.

cmpw
вычитать и тут же прибавлять
Чтобы решить задачу выравнивания как можно эффективнее сточки зрения скорости, проверки типа "надо - не надо" - это ветвление. Пусть в стеке будет неиспользованное место (в худшем случае 2 байта).

2q_q

Ты походу прикалываешся.

А кто сказал что интеловски вариант будет быстрее? Он будет медленнее! Но зато он быдет следить чтобы стэк был выровнян до 4х байт, а выравнивание мог испортить левый инит в crt. Так штааа это просто аллергия на слово main - назови функцию по другому и получишь обычное xor eax,eax / retn

cmpw
прикалываешся
Нет. Пытаюсь пояснить, что выравнивание esp должно повысить скорость доступа к стеку. И что вариант ic достаточно эффективен.

Dr.Golova
Он будет медленнее!
По сравнению с чем? С кодом, в котором нет выравнивания?