X86-assembly, a small entity (is not it?) (Linux)

Question

I am new to assembly language programming and I wrote a small program to print an integer using the sys_write system call. Here is my code:

section .data N: dw 216 chr: dw ,0,0,0,0x0a section .bss section .text global _start _start: xor ax, ax mov ax, word [N] mov cx, 10 mov ebx,4 shift_while: div cx add dx, 0x0030 mov word [chr+ebx],dx sub ebx, 2 xor dx, dx cmp ax, 0 jne shift_while call printchar exit: mov eax, 1 mov ebx, 0 int 80h printchar: pushad mov eax, 4 mov ebx, 1 mov ecx, chr mov edx, 8 int 80h popad ret 

I have hard code 216, the print number, and I get the correct output. However, I am confused by the fact that this is the instruction "mov word [chr + ebx], dx". dx contains 0x0032 in the first iteration, so at the address [chr + ebx] this value should be saved as 32 00 (hexadecimal). But when I studied chr memory with gdb, it showed:

 (gdb) x /5hx 0x80490d2 0x80490d2 <chr>: 0x0032 0x0031 0x0036 0x000a 

what I expected was 0x3200 0x3100 0x3600 x0a00 , and I thought that I would have to do further memory manipulations to get the correct result. I’m doing something wrong with this. There are things that I cannot see. I would really appreciate a little help here. This is my first first post on stackoverflow.

Answer 1

This is just an idea - what you have in mind from a byte-wise point of view,

 32 00 31 00 26 00 0a 00 

but when you consider it as 16-bit values, this

 0032 0031 0026 000a 

Similarly, if you viewed it as 32-bit values, this would be:

 00310032 000a0026 

Such is the strangeness of a small entity .; -)

Answer 2

gdb helps you here.

You requested the h ( halfword ) format on the little-endian platform, so it decodes the memory as 16-bit minimum values ​​for you.

If you use the b format, you will see something more as you expected.