Почему не используется команда ENTER

кто-нибудь знает почему не используется команда ENTER, а вместо неё используются push ebp/ mov ebp, esp ??

 

Вопрос в том, где не использутеся....
Многие HLL, компиляторы её используют.

И, моё мнение, потому же, почему не используют loop (хотя его тоже используют и не только недо-ассемблерщики)

 

rpy3uH
Leo когда-то писал, что она довльно медленная, 'push ebp/mov ebp', esp быстрее. А ее "парная" команда leave довольно часто используется gcc.

 

скачал отсюда таблицу опкодов. ENTER выполняется как минимум за 17 тактов, инструкции push ebp; mov ebp, esp; sub esp, 4 выполняются за 3 такта

 

И если внутри вашей процедуры есть вызов практически любой API-функции, а тем более операции с файлами (чтение-запись) или ожидание какого-то события, эти такты НИКАКОГО значения не имеют. Ни малейшего. Поэтому прежде чем оптимизировать, или гнуть пальцы против loop'а и заявлять о "недоасемблерщиках" (подразумевая свою немеряную крутизну, не иначе ), неплохо бы подумать - а есть ли смысл в оптимизации? Может один шут тут будет недуровая задержка, от вас не зависящая? Может, вы один шут будете крутиться в цикле, ожидая каких-то действий пользователя? В этом случае лишние 10-20-30 тактов никак не влияют.

 

лучшая оптимизация подпрограммы - это ее инлайн (встраивание в место вызова).
тогда вообще не будет прологов\эпилогов

 

Спасибо, конечно, что вы мне обьяснили когда надо делать оптимизацию, а то не в одной из книг или статей, которые я читал об этом не было ни слова .

Вы просто перевернули всю мою жизнь!

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

Луп может применяться, если это удобно, насколько я помню он применяется даже в фасме, и точно применяется в тулзе listing.


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

P.S.
В каком куске текста предыдущего поста я гнул пальцы. Разве я упоминал, что мой код исключительно крут???

 

FatMoon

Вы это компилятору скажите.

 

Нафига вообще придумали этот луп и прочее подобное, если оно только тормозит и захламляет систему команд?

 

потому что это cisc

 

n0name
Некоторая догадка: раз сейчас внутренне процессоры всё равно risc, то возможно это как-то отражается на производительности некоторых команд.

 

потому, что гладиолус!

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

 

maybeZ3N

Что там оптимизировать-то? Интел похлеще навороты реализует, а тут несколько команд не оптимизировать. На это должны быть объективные причины. Если от этого ускоряется декодирование других команд, то понятно. Ещё не понятно со строковыми командами, тут вообще есть неслабый простор для оптимизации, а они также сливают.

 

Эта тема что провокация что ли ?
Тут же на васме не рас уже говорили: все это устаревшие команды в старину (и получается сейчас) призванные сократить размер кода сейчас поддерживаются только для совместимости.

 

FLASH300
Официальный источник, со списком устаревших команд, пожалуйста в студию.

 

Посмотрите начало мбров от микрософта, там есть луп, что за бред ? Я юзаю луп ибо он короче в два раза.

 

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

 

В юзермоде(WIN32 раздел ?) не имеет значения пролог. Без разницы что замена на аналоги, что непосредственно инструкция.

 

Booster
Я хз на счет списка но есть.

В общем интуиция подсказывает что их реализацию засунули куда-нить на обочину кристалла и налепили чтоб только работали упростив при этом реализацию дешифратора команд (сократив количество транзисторов и соответственно тепла в нужном месте и пр) увеличив производительность в целом.

Вспоминаются дискуссии о скорости add x,1 | inc x и все из той-же оперы.

Не удивлюсь если эти команды будут работать более оправданно если рассматривать древние процессоры с маленьким кэшем.

ЗЫ=PS:Вообще-то мне ща некогда кому-то что то доказывать, есть желание ищите истину. Вдруг выясняется что это на самом деле происки инопланетного разума

 

Вобще то кроме оптимизации по скорости есть и оптимизация по размеру