QUALITY ASM PROGRAMS

I CALL IT THE NOPINATOR
POST SOME OF YOUR QUALITY ASM

nop
nop
nop
nop
nop
section .data                       
str:     db 'Nop nop nop nop nop!', 0Ah       
str_len: equ $ - str               
nop
nop
nop
nop
nop
section .text                
global _start                          
_start:                             
mov    eax, 4                  
nop
nop
nop
nop
nop
mov    ebx, 1                  
mov    ecx, str               
nop
nop
nop
nop
nop
mov    edx, str_len            
int    80h                     
nop
nop
nop
nop
nop
mov    eax, 1                 
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nopmov    ebx, 0                   ; specify return code for OS (0 = everything's fine)
int    80h                      ; tell kernel to perform system call
nop
nop
nop

Anything compiled with tcc. It uses NOPs and 5-byte jumps with zero-length displacements.

>>2
why do compilers even waste space with NOPs?

from my understanding a nop does nothing and thus if removed, nothing will happen... right? or do compilers code in some stuff that requires distance between one thing and the next?

>>3
you will never get it
shits deep yo

>>3
It protects your computer in bad times

>>3
remove all the NOPs from a program and then place a magnet near your computer

>>3
For delays when accessing hardware.

>>3

lots of cpus use something called a pipeline, where they process more than one instruction in a single moment to speed things up. This creates some issues though and sometimes later instructions need to be stalled before the current one reaches a certain point in its reading/execution/writing/whatever it might be doing. Hardware can be used to detect when this happens, but it costs money, so there are architectures that don't have hardware to check, and instead, the compiler has to
insert NOPS to avoid that from happening.

for a more complete answer, check this out:

http://en.wikipedia.org/wiki/Classic_RISC_pipeline

And go to the Hazards, Data Hazards section, and read it all the way to the end until it mentions MIPS.

Also, memory alignment. Apparently, x86 executes instructions faster on even doubleword addresses.

seems like a classic case of a "leaky abstraction" where some implementation detail of a lower level that you shouldn't have to care about, does in fact, matter

>>10

yeap, it comes down to what's going on with the cpu thats executing the instructions.

>>9
True up until whatever the last CPU was that used a 64-bit data bus. The Nehalem family have 192-bit-wide busses and Sandy Bridge 256-bit-wide busses. Unless the instruction just happens to straddle the boundary and is in a tight loop, there's almost no difference.

>>8
The original Stanford RISC machine relied on the compiler to add the NOP instructions in this case, rather than having the circuitry to detect and (more taxingly) stall the first two pipeline stages. Hence the name MIPS: Microprocessor without Interlocked Pipeline Stages. It turned out that the extra NOP instructions added by the compiler expanded the program binaries enough that the instruction cache hit rate was reduced. The stall hardware, although expensive, was put back into later designs to improve instruction cache hit rate, at which point the acronym no longer made sense.
lol.