это баг или "фича"? о_О

А что ты ожидал? В ebp хранится указатель на фрейм:
http://en.wikipedia.org/wiki/Frame_pointer

Kallikanzarid, фрейма нету, какбэ
читай код в 1м посте полностью

GoldFinch, 
хм, реально баг получается

Точно, должно быть esp   
Попробуй поставить сервис пак, может, поможет.

все верно
в прологе esp сохраняется в ebp, и от ebp считаются аргументы
так что все правильно
неправильно в naked использовать аргумент - т.к. компайлер плюет, что вы отказались от пролога и эпилога

хм. здесь про аргументы ничего такого не сказано, однако упомянуто авто-отключение Frame pointer optimization для naked функций. т.е. компилер рассчитывает на то, что руками фрэйм таки будет создан, что он и демонстрирует.

GoldFinch, Если нет желания использовать фрейм, попробуй __fastcall. ЕМНИП, два двойных слова ты с его помощью без проблем передашь даже без фрейма. В принципе можно одним из них передавать указатель на объект, в котором хранятся остальные параметры.

Это сообщение отредактировал(а) Kallikanzarid - 7.12.2008, 08:54

ну прям лень фрейм выставить - 2 инструкции в начале и 2 в конце

Kallikanzarid, в msdn сказано что при __fastcall компилятор не гарантирует очередность параметров, т.е. неизвестно какой окажется в eax а какой edx. Кроме того, в большинстве случаев аргументы лежат в стеке.

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

GoldFinch, Если бы ты писал под мобильники, то юзал бы явно не студию. Уменьшение размера кода даже на килобайт абсолютно незаметно. Теоретик, блин 

ЗЫ: Зачем тебе нужны naked функции?

Кстати, если тебе так противен фрейм, можешь спокойно высчитывать расположение параметров сам.

Это сообщение отредактировал(а) Kallikanzarid - 7.12.2008, 14:28

Kallikanzarid, если бы ты писал на асме, ты бы знал зачем надо уменьшать код, зачем нужны naked функции
высчитывать расположение параметров самому глупо, этим должен заниматься компилятор, тем более что это асм встроенный в ЯВУ

О да, я такой глупый, просто оторопь берет!   Не желаю экономить 10 байт на функцию - просто кошмар!

Ты хоть профилировщик запускал прежде, чем прибегать к таким мерам? Или тебе 4мб L2-кэша заранее мало?


Писать пролог самому глупо, этим должен заниматься компилятор.

ЗЫ:

А тебе зачем это знать? Обращайся к параметрам по имени.

Kallikanzarid, вот есть у меня например такой код:

куда здесь воткнуть ebp фреймы?

Боюсь даже представить  А что делает этот код?

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

реализует "ленивые" импорты
да там же все понятно, что он делает, всего-то десяток строчек

dumb, это хорошо, что ты не понял этого кода. Он призван вызывать священный трепет, а то и ужас, перед асмом у тех ламеров, кто полезет с ИДА узнавать какие импорты юзаются в моей проге. Хотя код крайне тривиален, я думаю найдется немало людей которые испугаются увидев это, и не станут копать мою прогу.
=)

Главное, чтобы босс был не в их числе   

в документации оговорена спецификация naked - во-первых
во-вторых - как ты хочешь, что-бы компилятор посчитал аргументы? он же не знает твои манипуляции со стеком до использования аргументов - ИМХО вполне оправдано что расчет аргументов опирается на предположение, что фрейм установлен - иначе никак
если не нужен фрейм - считай аргументы сам - компилятор это сделать иначе не может

Добавлено через 3 минуты и 10 секунд

несколько противоречивое высказывание   

Это сообщение отредактировал(а) J0ker - 7.12.2008, 19:07

J0ker, впринципе логично, что компилятор не разбирает асм-код
хотя могли бы это и сделать... не бином ньютона =\

бином
предположим, ты выделяешь на стеке массив с размером, взятым из одного из параметров - в стиле C99


Это сообщение отредактировал(а) J0ker - 7.12.2008, 19:41

J0ker, хм... ну тогда стоило бы выдавать ошибку компиляции, или хотябы явно написать об этой "фиче" в документации %)

http://msdn.microsoft.com/en-us/library/5ekezyy2(VS.80).aspx
http://msdn.microsoft.com/en-us/library/4d12973a(VS.80).aspx


Это сообщение отредактировал(а) J0ker - 7.12.2008, 20:25

раз уж речь пошла о пользе naked, подскажите как тут избавиться от асма:

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

GoldFinch, ur crazy   
Пожалуйста, скажи, что это профайлер показал, что необходимо вручную передавать параметр через регистр. Или использовать глобальную переменную. Или вручную расчитывать смещение поля в объекте (ничего, кстати, что это нарушает инкапсуляцию?). Не говоря уже о том, что рекомендуется передавать объекты по ссылкам, а не по указателям. Я начинаю боятся за будущее Земли. 

ЗЫ: твой код неэффективен. Ты два раза заносишь в стек один и тот же параметр. Настоящий Программист бы сделал так, чтобы функция Render после вызова оставляла его в стеке, а функция OnRender - использовала повторно. Ты неэффективен!

Это сообщение отредактировал(а) Kallikanzarid - 8.12.2008, 11:08

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

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

mes, Kallikanzarid, вы не учитываете того, что работа идет с готовым бинарным кодом. товарищ путем предоставления обрывков информации по сути провоцирует нас на такие бессмысленные(в конечном счете) комментарии.

Чьорт, меня затроллил закомплексованный труъ-ассемблерщег   *ушел пить йад*

Прикинь, я пишу под WinMobile и использую-таки студию

Вместо того чтоб учитывать все возможные предположения, которых в действительности может и не быть (так как в другом топике этого же автора вроде (может и ошибаюсь) подразумевалось о том что исходники на руках) лучше было бы если бы автор описал бы свою ситуацию. Без этого будет имхо затруднительно ответить на вопрос:

Kallikanzarid, "рекомендуется передавать объекты по ссылкам, а не по указателям" я кнешно не силен в С++, но какая между ними разница? о_О

dumb, какая разница, для чего нужен код? хуки они и есть хуки... а использование ЯВУ вместо такого асма позволит значительно повысить читаемость:



ЗЫ: а та "примитивная защита" не хуже, чем популярное криптование символьных имен или импорты по хешам. К тому же ей гораздо удобнее пользоваться, т.к. функции(методы) вызываются нормально, а не по указателям.

Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 13:07

Поди еще .NET используешь  Я имел ввиду настоящие мобильники, с низкими вычислительными мощностями.

Добавлено через 7 минут и 25 секунд
GoldFinch, ссылка на протяжении своей жизни гарантированно указывает на один и тот же объект, то позволяет компилятору включить множество оптимизаций, которые он (справедливо) боится применять к указателям.
http://www.tantalon.com/pete/cppopt/main.htm - устаревший ресурс, но многое все еще справедливо.

Защита дефайнами и вставками элементарно ломается с помощью препроцессора.

Не, чисто на С++.

как это? какого препроцессора? о_О

GoldFinch, Препроцессора С/С++. Прогоняешь через него файлы, и дефайны со вставками волшебным образом исчезают  

ksili, как я понимаю, речь идет о смартфонах? Я имел ввиду, что экономить 10 байт может иметь смысл лишь с очень ограниченными платформами, вроде старых мобильников.

Да, смартфоны, КПК, ... это наш клиент ))


Не понял. Ломают обычно бинарник. Как ты его прогоняешь через препроцессор?

Тогда я ничего не понимаю  Может, я неправильно истолковал слово "дифайны"?

имелось ввиду несколько другое :

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

по контексту речь идет о некоторых программистах, которые "портят" (с какой целью можно только предполагать) исходный код : 

Kallikanzarid, речь шла от такой защите дефайнами и асм вставками

после автоанализа в ИДА бинарник выглядит весьма неплохо, на 1й взгляд, да и на 2й взгляд там будет немало возни с восстановлением импортов. и это еще самый простейший вариант)

  а сколько возни автору коду с подержкой всей этой ..ммм.. защитой. )  интересно в чем прелесть такой овчинки и стоит ли она выделки ?
только ради (мнимой) надежды что код не взломают ?  В принципе могут и не взломать.. это если как в анекдоте про неуловимого Джо... ;)

Короче мы (GoldFinch, Kallikanzarid, mes и я) в этой теме - лебедь, рак и щука, и ёщё кто-то четвёртый     

mes, возни мало, зато куча преимуществ.
статический импорт не работает, т.к. для него надо иметь заголовочные (.h) файлы идентичные тем что были использованы при компиляции длл, иначе возникает несоответствие таблиц методов.
динамические импорты через getprocaddress неудобны изза использования указателей на методы (obj->*met)() вместо obj->met()
а такими приятно пользоваться в коде + их можно генерить скриптом

забываете о прокси-классах типа умного указателя. 


под одну платформу, определенный тип компилятора и небольшой плясочки, чтоб привести целевой бинарник к удобному виду. )

кроссплатформенность С++ зачастую приводит к очень плохой кодогенерации.
лучше уж генерить хороший код под одну платформу чем *плохой* но чтоб можно было под любую.
когда я пишу код который будет работать внутри готового win32 приложения, мне эта кроссплатформенность *не нужна*

GoldFinch, [citation needed]

???

Мне не кажется очевидным, что кроссплатформенный исходный код приводит к генерации "плохого" бинарного кода.

Kallikanzarid, из-за "кроссплатформенности", в С(++) нет способа средствами языка сгенерить некоторые x86-87 команды, например загрузку констант в FPU. 
Т.е. в некроссплатформенном паскале есть оператор(функция) Pi который генерит fldpi, а в кроссплатформенном С(++) оператора Pi() нет, и способа сгенерить fldpi (и другие константы) тоже нет.
Впрочем код C++ для FPU местами ужасен %) Ни один нормальный программист такого бы не писал.

Троллинг перерастает в холивар...   
1) Чем плохи заранее обсчитанные константы?
2) Паскаль - не кроссплатформенный?   Да что ви говогите!
3) Меня ты продавишь только цифрами, так как плевать я хотел на красоту бинарного кода  Хочу бенчмарк, в котором те или иные мат. расчеты выполняются сначала в С++, а потом - в асме.
4) А ты можешь вручную оптимизировать расположение инструкций, чтобы минимизировать простой конвеера?

бред
никакой связи тут нет
вопрос лишь в поддержке компилятора


не существует "кода C++ для FPU"
качество кода, сгенерированного компилятором зависит от качества компилятора
оценка качества оптимизированного кода неподготовленными субъектами обычно неадекватна, т.к. понять что оптимально а что нет на уже 2-х процессорных платформах способен только специалист

и вообще на 2-х последних страницах столько бреда, что ужасть   

Kallikanzarid,
1) тем что аппаратные константы много лучше программных
2) паскаль - я имел ввиду турбопаскаль, дельфи
3) цифры: 
   fldpi - 2байта
   pi dt 3.14.... / fld [pi] - 10+6 байт
4) если бы ты видел код который те генерит твой компилятор, ты бы не говорил о "минимизации простоя конвеера"
какбэ вот такой код при конфигурации "релиз" - это реальность
.text:1000122F                 mov     eax, dword ptr [g_hEngine]
.text:10001234                 mov     dword ptr [eax+56F5D8h], offset Hook_ALineagePlayerController_PlayerCalcView(AActor *,FVector *,FRotator *)
.text:1000123E                 mov     ecx, dword ptr [g_hEngine]
.text:10001244                 mov     dword ptr [ecx+57B968h], offset loc_10001190
.text:1000124E                 mov     edx, dword ptr [g_hEngine]


J0ker, ок, будет говорить исключительно о компиляторе MSVC. так вот у него кодогенератор - гуан*

насчет кода для FPU - вот так вот в MSVC передаются 32-разрядные значения float
.text:10001344                 fld     [esp+18h+arg_4]
.text:10001348                 fstp    [esp+18h+var_14]
.text:1000134C                 fld     dword ptr [eax+4]
.text:1000134F                 fstp    [esp+18h+var_18]
.text:10001352                 call    FCanvasUtil::DrawLine(float,float,float,float,FColor,int)
видимо те кто писали кодогенератор малость не учли, что dword'ы в стек можно запихивать командой push, а не через стек FPU %)


Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 20:08

GoldFinch, объясняю еще раз для самых одаренных. Мне. Плевать. На. Красоту. Ассемблерного. Кода. Если бахвалишься своей труъ-ассемблерностью, подтверди свое превосходство, представив реализацию какого-нибудь численного алгоритма на С++ и на асме. И время, за которое эти реализации выполняются.

Kallikanzarid, вот тебе какбэ алгоритм получения 80-разрядной константы Pi, разница в размере - в 8 раз, разница в быстродействии в единицы - десятки раз, в зависимости от расположения константы в кеше или нет.
Не нравится - выбери другой алгоритм, метод, условия измерения и представь свой труъ С++ код, ато я на С++ меньше месяца пишу, могу true с false через strlen() сравнивать.

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

Это сообщение отредактировал(а) J0ker - 8.12.2008, 20:45

J0ker, и где же ты там преобразование увидел? я тольк увидел преобразование m32real->m80real->m32real. там какбэ fld а не fild

Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 20:48

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

а это не решение? о_О
pushd     [esp+18h+arg_4]
pushd     [eax+4]
call    FCanvasUtil::DrawLine(float,float,float,float,FColor,int)

битовое представление floata равного n не  не соответствует битовому представлению этого числа в dword/int (дополненого нулями)

нет

mes, я струдом догадываюсь что такое битовое представление, тем более дополненное нулями О_о, и причем тут это
команда push [mem32] копирует 4 байта по адресу mem32 в стек, и она не обращает внимания на "битовое представление" этих байт.
J0ker, и в каком же месте это не решение?

Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 21:22

в месте преобразования типа - размещение значений с плавающей точкой в памяти и обратная операция сопряжено с преобразованием типов
нельзя корректно положить на стек число с плавающей точкой иначе чем через стек FPU

сейчас набросаю пример почему не явлется решением :



Добавлено @ 21:33
вот примерно что получится в результате вашго решения :


Это сообщение отредактировал(а) mes - 8.12.2008, 21:35

J0ker, mes, жжоте... какие громкие заявления) какая уверенность в правоте своих слов... вы не правы. 
Потому что черное это черное, а белое это белое. Есть много способов премещать значения в памяти, и если вы этого не знаете это не значит что эти способы неверны) Курите документацию к процу и вам откроется истина)

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

upd:
mes, нет, Ваш код ниразу не соответствует той ситуации.

Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 21:43

никакой громкости.. Вам был представлен пример, который показывает что участок памяти трактованный как int, числено не равен этому же участку памяти но трактованному как float.
жаль что Вы даже не захотели этого понять ;)


И ночью тоже ?


а кто нибудь оспаривал ? речь не о перемещении а о трактовке значения.


А вот это действительно громко. Записал бы, но .... я думаю Вы догадались )

так..... тут было потерто обкидывание оппонента какашками   

Это сообщение отредактировал(а) J0ker - 8.12.2008, 22:20

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

mes, что за бредовый пруфкод вы пишете? то что мы обсуждаем выглядит так:

в строчке "push dword ptr [arg]" float значение передается в стек через push а не через пару fld/fstp
что характерно прога выводит "8/7==8/7"

Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 22:20

GoldFinch, я вам объясняю... совершенно спокойно, вот...
преобразование из дабл во флоат - это ОПЕРАЦИЯ - она не может быть выполнена без привлечения FPU либо его эмулятора
если вы в своих примерах замените float на double вы сразу это поймете

A Вы схитрили .. перепешите код изменив эту срочку на
int Bar(int arg)

вот Вам каркас теста :


потом еше можете изменить int на double и посмотреть результат ) 

Это сообщение отредактировал(а) mes - 8.12.2008, 22:36

GoldFinch, вот, разберитесь уже наконец

J0ker, 

где Вы тут увидели double??? тот самый 64-разрядный double, а не 32-разрядный float?? надеюсь Вы понимаете что мы говорим о 32(тридцатидвух)-разрядных значениях??

но специально для Вас, я перепишу код для double, и даже уберу там баги которых Вы не заметили)))

какбэ 64-разрядные значения запихиваются в стек двумя push [mem32]

более того, пиши я под x64, там был бы один push [mem64]

Добавлено @ 22:44
J0ker, Вас в вашем коде строчки
00401658  fstp        dword ptr [esp+4] 
0040165C  fld         dword ptr [esp+4] 
не смущают?
и вообще, как эта муть относится к теме?


mes, медленно, вдумчиво, прочитайте еще раз этот код, и Вы поймете что Вы пишите не по теме.
.text:10001344                 fld     [esp+18h+arg_4]
.text:10001348                 fstp    [esp+18h+var_14]
.text:1000134C                 fld     dword ptr [eax+4]
.text:1000134F                 fstp    [esp+18h+var_18]
.text:10001352                 call    FCanvasUtil::DrawLine(float,float,float,float,FColor,int)
ну нету в этом коде ничего связанного с int, не-ту

Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 22:48

да я собстна не про этот код   
я его даже не читал


а вас смущает? а что вас смущает?   


когда вы это поймете, дискуссия будет окончена