cpu 386
bits 16
[section .text]
org 0
Start:
; This instruction uses "Data" label as a displacement.
; But NASM doesn't recognize that the displacement is small enough to fit one byte.
; So even with -Ox option it is compiled to the non-optimal sequence.
cmp [bp+Data], cl ; Coded to 38 8E 16 00
; This instruction actually does the same, because the "Start" label is equal to 0.
; But since the difference between two addresses is non-address, NASM compiles it to the more optimal sequence
; The same result may be achieved if we write [bp+const] and define "const" to 7
cmp [bp+Data-Start], cl ; Coded to 38 4E 16
; The same situation is on the following two instructions. The first will not be optimized.
add dword [Data], Data ; Coded to 66 81 06 16 00 16 00 00 00
add dword [Data], Data-Start ; Coded to 66 83 06 16 00 16
Data: db 55h
Dear friends.
Since I've become constant user of NASM (at present really best assembler worldwide), I've registered at this forum.
I found another optimization issue.
INT 3 have special one-byte machine code 0CCh. But NASM always compiles it as 0CDh 03h.
Thank you for your attention.
INT 3 have special one-byte machine code 0CCh. But NASM always compiles it as 0CDh 03h.
Yes, the mnemonic used for it is INT3, in which is assembled to 0xCC.
Oh, really. Thank you.
But should it be considered as a term for optimization? I think NASM is better to code INT 3 as 0CDh 03 without -O and as 0CCh with -O option. May be even to use "int strict 3" syntax to prevent 0CCh generation whenever optimization is turned on.
The thing is separate "int3" mnemonics need to be known and kept in mind constantly.
Oh, really. Thank you.
But should it be considered as a term for optimization? I think NASM is better to code INT 3 as 0CDh 03 without -O and as 0CCh with -O option. May be even to use "int strict 3" syntax to prevent 0CCh generation whenever optimization is turned on.
The thing is separate "int3" mnemonics need to be known and kept in mind constantly.
Seems like a good idea! FWIW, gas compiles int 3 as 0xCC per-default, but I guess such an optimization is better to be done under one of -O level. Thanks for idea!
H. Peter Anvin has explained even more on INT3 vs INT 3 difference
"int 3" and "int3" are actually different
instructions with different semantics. "int 3" does an interrupt,
whereas "int3" actually launches a breakpoint exception (#BP). The
differences are subtle, but real. It would have been better if "int3"
had been called "brk" or something like that. ("int1" is a similar
situation, although "int1" is even more different than "int 1".)
Are you talking about protected mode?
In real mode they are absolutely identical.
Yes. And I "guess" this 0xcc opcode has a special target in decoder as well. All-in-one: they are different instructions.
You may use simple macro which redefine INT 3 to INT3 if you need, but I suppose this feature should not be changed in a sake of backward compatibility via optimization level.
Hmmm. I'll try to investigate this more.