Code optimization issue

[nobody]

Good afternoon dear friends!
I found out that NASM is unable to optimize some kind of instruction even with -Ox option.
The problem is that NASM couldn't optimize a small-sized displacement to register if the displacement goven as an address.
Here is the brief sample code with detailed comments, plase have a look:

Code:

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

[Serge]

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.

[Keith Kanios]

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.

[Serge]

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.

[Cyrill Gorcunov]

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!

[Cyrill Gorcunov]

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".)

[Serge]

Are you talking about protected mode?
In real mode they are absolutely identical.

[Cyrill Gorcunov]

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.

[Serge]

Hmmm. I'll try to investigate this more.