Index
> Main > LEA EAX,[EAX + 0] // 8D 40 00 |
| Author |
|
|
MCD 12 Feb 2007, 10:06
DOS386 wrote:
|
|||
12 Feb 2007, 10:06 |
|
|
vid 12 Feb 2007, 10:17
search for "multi byte nop", it was recent topic here
|
|||
|
12 Feb 2007, 10:17 |
|
|
r22 13 Feb 2007, 02:17
1- If you don't know what a NOP is its a 'null operation'. The instruction doesn't perform any task just takes up space.
2- When I compile LEA EAX,[EAX+00h] in FASM and decompile it its 8D 00 if you want FASM to compile the three byte version just make a MACRO called NOP3 with the db in it. |
|||
|
13 Feb 2007, 02:17 |
|
|
DOS386 13 Feb 2007, 03:22
Quote: search for "multi byte nop", it was recent topic here OK, found even 3 
http://board.flatassembler.net/topic.php?t=3331 http://board.flatassembler.net/topic.php?t=5745 http://board.flatassembler.net/topic.php?t=5524 Quote: When I compile LEA EAX,[EAX+00h] in FASM and decompile it its YES, that's what I want - impossible (except db) 
The compiler produces other cool stuff also: Code:
mov eax,eax
Even worse, there are even multiple encodings for such "offensive" (most of them) instructions: Code: ; Redu Code: 00 0AE4 OR AH,AH ; compare with 0 02 08E4 OR AH,AH 04 0BC0 OR EAX,EAX 06 09C0 OR EAX,EAX 08 29C0 SUB EAX,EAX ; zeroize 0A 2BC0 SUB EAX,EAX 0C 33C0 XOR EAX,EAX 0E 31C0 XOR EAX,EAX 10 89C3 MOV EBX,EAX ; "serious" instructions 12 8BD8 MOV EBX,EAX 14 89E5 MOV EBP,ESP 16 8BEC MOV EBP,ESP 18 89C0 MOV EAX,EAX ; NOP's Is there any benefit of all those useless "NOP" instructions or the compiler only wants push me to buy a bigger HD and more RAM ?  _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
13 Feb 2007, 03:22 |
|
|
f0dder 13 Feb 2007, 07:27
Instruction alignment for caching issues... go read agner fog's material.
|
|||
|
13 Feb 2007, 07:27 |
|
|
kandamun 13 Feb 2007, 09:47
Another use of nops is to fix somebody's mistake by replaceing some of his instructions with nops. Recently I have used
Code: 8D2424 lea esp,[esp] 8D2424 lea esp,[esp] Now I realize the following would be much nicer: Code: 8D80 00000000 LEA EAX,[EAX+0] "Multiple encodings" can be usefull also. One can hide information in his binaries by giving different bit values 0/1 to different encodings that have the same meaning. |
|||
|
13 Feb 2007, 09:47 |
|
|
Madis731 13 Feb 2007, 10:56
FASM was designed to support all kinds of optimal and other not that optimal encodings of instructions
Code: use32 lea eax,[eax+0] ; 8D 00 - you can also use byte/word prefix lea eax,[dword eax+0] ; 8D 80 00 00 00 00 lea ax,[eax+0] ; 66 8D 00 - also byte/word prefix lea ax,[dword eax+0] ; 66 8D 80 00 00 00 00 There you have it - read the FASM manual and you can clever your way out of your problem without db and macros... |
|||
|
13 Feb 2007, 10:56 |
|
|
DOS386 14 Feb 2007, 03:25
Quote: FASM was designed to support all NOT all
Quote: lea eax,[eax+0] ; 8D 00 - you can also use byte/word prefix No effect
Code: use32 mov eax,eax ; 2 bytes nop lea eax,[eax] ; 2 bytes nop lea eax,[eax+0] ; No effect nop lea eax,dword [eax+0] ; No effect nop lea eax,word [eax+0] ; No effect nop lea eax,byte [eax+0] ; No effect nop lea eax,[dword eax+0] ; BOOM from 2 bytes to 6 bytes nop ;lea eax,[word eax+0] ; Compile failure nop ;lea eax,[byte eax+0] ; Compile failure Quote: read the FASM manual and you can clever your way out of your problem without db and macros No 3-byte LEA EAX,[EAX+0]
Quote: "Multiple encodings" can be usefull also. One can hide information in his binaries by giving different bit values 0/1 to different encodings that have the same meaning. WOW
Quote: Instruction alignment for caching issues... go read agner fog WOW ... including garbage to save some picoseconds on some CPU's _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
14 Feb 2007, 03:25 |
|
|
f0dder 14 Feb 2007, 11:54
NTOSKRNL_VXE wrote:
Consider an innerloop that is run a lot - including a couple of "garbage" bytes for alignment most likely won't affect the disk nor memory usage (since that's generally done in 4k chunks), but it can affect performance a lot. _________________  - carpe noctem |
|||
|
14 Feb 2007, 11:54 |
|
|
Borsuc 14 Feb 2007, 13:21
f0dder is correct. If you need high-speed real-time application, loops are very common and slow -- better make them as fast as possible.
But for those which you probably mean it's better to save memory, even if it's worthless, at least it's measurable, while speed varies between processors (i.e you never know the optimal solution for ALL of them). Of course, algorithms that require a lot of computational time are better off with a speed optimization, if it's a loop don't avoid caching, otherwise size is just fine. |
|||
|
14 Feb 2007, 13:21 |
|
< Last Thread | Next Thread > |
Forum Rules:
|