Author Topic: How to distinguish m16 from m32 or r16 from r32?  (Read 7138 times)

Offline oldefoxx

  • Jr. Member
  • *
  • Posts: 3
How to distinguish m16 from m32 or r16 from r32?
« on: September 03, 2012, 06:45:33 AM »
I ran into this problem with HotBasic's Inline Assembler.  I turned to the real assemblers (MASM32, NASM, and FASM) for an answer,
Unfortunately, they don't agree on what the answer should be, and they can't all be right.

This invoves memory 16 or 32 bit references as well as register 16 or 32 bit references.  All the Assembler sources show that when you
are talking about "w", as in movsw, you are talking about a word (16 bits) as opposed to "d", where you are talking about a dword (32
But the Hex codes listed for "w" and "d" are exactly the same, like for ADD, they are both represented by 05 hex.  That can't be right.  There has to be a distinction between them.  And there is,  The inclusion of 66 hex as a prefix in one case so that you have 66 05.  But
this is not covered in any Assembler Language source that I can find, and the three major compilers do not agree on which case holds
true.  Is that 66 05 to represent Adding 16-bits, or does 66 05 represent Adding 32-bits?  Generally, NASM and FASM agree when to use
the 66, but both of these are exactly opposite what MASM32 choses to use.  Somebody has got to be wrong here.

Now I can play with it until I get it figured out for myself, but I figure the difference is important enough to open a thread on the matter
first.  When you think you are using ecx as an example, are you really using ecx or are you only using cx?  It can make a bid difference in
your results.

Offline Keith Kanios

  • Full Member
  • **
  • Posts: 383
  • Country: us
    • Personal Homepage
Re: How to distinguish m16 from m32 or r16 from r32?
« Reply #1 on: September 03, 2012, 12:31:17 PM »
I think an assembler is at least one level of abstraction too high for the information you seek. A good assembler will abstract such subtleties away to provide a more consistent syntax.

You are best off looking at the opcodes/mnemonics. The Intel/AMD processor manuals have all the information you want, including pseudo-code descriptions that illustrate how the processor state/mode comes into play and what flags are affected for each instruction.

For example, such manuals would explain what the 0x66 opcode is -- operand size override -- an opcode specifically meant to override the defaults for the current processor mode, i.e. change from a default 16/32-bit to a 32/16-bit operation.

If you want to study this with precision in NASM, you'll want to make sure you are explicitly defining the expected processor mode with the BITS directive. The following example should help you along.

Code: [Select]
;filename: test.asm
;build: nasm -f bin -o test.o test.asm
;16-bit dump: ndisasm -b16 test.o
;32-bit dump: ndisasm -b32 test.o
[BITS 16]