7c6f:   ec   in     (%dx),%al

Here my doubt is due to ()

Many places I wrote code this worked as take the value inside (%dx) and use it as memory location and value located there is value needed.

But here it should be doing just in %dx,%al ; and %dx hold port no Just like in 0x000,al

CodePudding user response：

in %dx, %al assembles to the same 0xEC byte of machine code, which objdump -d disassembles to in (%dx),%al as you've found.

llvm-objdump -d does use the syntax you expected: inb %dx, %al ; inb $128, %al

AT&T syntax's use of (%dx) for the IO port number in in / out is misleading since it's not a normal addressing mode; DX being the only option. Presumably the designers of AT&T syntax wanted to represent the fact that you're reading or writing I/O address space. But they did a bad job because it's inconsistent with their use of in $0x80, %al for immediate port numbers (as opposed to 0x80 for the port number using the same syntax as an absolute memory address). GAS and LLVM don't even accept in 0x80, %al, so no, not "Just like in 0x000,al".

The in / out instructions access IO space, not memory address space.
The "addresses" in IO space are called port numbers.
IO space is still a thing in modern PCI-express, but most modern devices only have MMIO registers in device memory regions, not IO ports, because IO ports are slower to access.

objdump -drwC -Mintel disassembles to the same syntax Intel uses in their manual entry for the only form of in that has a port in DX and byte operand-size. Note the lack of [dx] brackets.

   0:   ec                      in     al,dx
   1:   e4 80                   in     al,0x80

(%dx) is not one of the valid 16-bit addressing modes, so that specific addressing mode is never valid for any other instruction. But yes, (%reg) such as (