NASM - The Netwide Assembler

NASM Forum => Programming with NASM => Topic started by: andoram on August 29, 2015, 12:15:47 PM

Title: Immediate data -> memory location. In what position to put size specifier?
Post by: andoram on August 29, 2015, 12:15:47 PM
Learning Assembly language with Nasm I've just found that when I want to put immediate data to a memory location I can specify the size with either one of the operands, or with both of them. Example:

Code: [Select]
mov [num_i], word 0x5678
mov word [num_i], 0x5678
mov word [num_i], word 0x5678

And all of them generate the same thing (viewing in GDB):

Code: [Select]
mov    WORD PTR ds:0x80490e0,0x5678
Is there any difference between these three variants? Which way is the standard?
Title: Re: Immediate data -> memory location. In what position to put size specifier?
Post by: Rob Neff on August 29, 2015, 03:28:35 PM
To ensure proper behavior at all times I personally use
Code: [Select]
mov word [num_i], 0x5678

I always specify the expected size of data when using indirect memory references.
It is a form of documentation that I've ensured I do not overwrite any additional memory.

Additionally, this works for other things as well.
For example, this generates valid code with no warning:
Code: [Select]
mov dword [num_i], eax
but this causes nasm to issue a warning:
Code: [Select]
mov word [num_i], eax

Seeing the warning message should cause you to pause and re-examine your code.
Title: Re: Immediate data -> memory location. In what position to put size specifier?
Post by: Frank Kotler on August 29, 2015, 04:32:21 PM
As Andoram observes, it generally makes no difference whether the size specifier goes with the destination or source operand. However:
Code: [Select]
; movzx byte eax, [foo] ; error!
movzx eax, byte [foo] ; okay
So you might - maybe - want to put it in the second place always... just for consistency.

I personally usually put it in the first place, just to "get it over with". I really don't think it makes any difference when it doesn't make any difference. Programmer's choice. It is good to be programmer. :)

Best,
Frank