Уважаемые медитирующие! Подскажите, пожалуйста, наивному чукотскому монаху. Пишу для MASM, использую je, jne. Загружаю дебаггер msdevenv.exe (VS 7.0) получаю в disassembly непонятно откуда взявшийся jp ... Объясните доходчиво, пожалуйста.
некоторые условия дублируются для удобства программера: je и jz имеют одинаковый опкод, иначе, есть одно и тоже, а отладчик не знает ход мысли программиста, и выводит тот опкод, который решили разработчики отладчика. просто это нужно учитывать. а вот почему jp вместо je - не могу сказать точно, но масм может оптимизировать прогу, то есть, ты можешь увидеть в отладчике не то, что писал. но с этим я пока не сталкивался, может, кто другой расскажет больше.
Упс! Вот это переглючило мои рецепторы! На самом деле я все наврал.... Привожу код. Пишу: cmp [esi], dl jpe EndOfParsing Получаю: 00401064 cmp byte ptr [esi],dl 00401066 jp 004010A2 То есть JPE превращается в JP, что вполне нормально. А я то думал, я пишу JE....... вот как оно бывает то, с непривычки...
Quantum Если память не изменяет FASM не оптимизирует код. Единственное, что он делает это проставляет ближние и дальние переходы так, что бы код получился меньше. ИМХО.
Любой нормальный ассемблер оптимизирует код по размеру. Одно- и 2х- проходные не в состоянии, конечно, выбрать короткие варианты инструкций переходов. Но для арифметики выбирается минимальныё опкод: Код (Text): 81C0 22000000 add eax, 22 05 22000000 add eax, 22 83C0 22 add eax, 22 С test конечно несколько сложнее, поскольку есть три взаимно противоречивые вещи: оф.документация, правила математики и здравый смысл ))) ЗЫ: Не так давно обнаружил, что intel C++ compiler "не догадывается" заменить команды вида Код (Text): 8D0424 lea eax, [esp] на Код (Text): 8BC4 mov eax, esp
Кстати, я тут интересную вещь обнаружил, Olly при ассемблировании оптимизирует по размеру, т.е. делает несколько тестов ассемблирования и выбирает наименьший по размеру вариант.
