format PE console
use32   ; x86_32
entry start 

include 'win32a.inc'

struct PNT 
        x dd ? 
        y dd ?
        z dd ?
        q dd ? 
ends

struct IPV4 
        union
                struct
                        a db ?
                        b db ?
                        c db ?
                        d db ?
                ends 
                addr dd ?
        ends 
ends 
; This is the data section:
; =======================================================
section '.data' data readable writeable 
        lhost     IPV4 <127, 0, 0, 1>

; =======================================================
section '.text' code readable executable 

start:
        ; Your program begins here
        mov eax, 0 ; Clear eax 
        mov ah, byte [lhost.a] ; Output -> 7f00
        mov eax, 0 ; Clear eax 
        mov ah, byte [lhost.b] ; Output -> 0
        mov eax, 0 ; Clear eax 
        mov ah, byte [lhost.c] ; Output -> 0
        mov eax, 0 ; Clear eax 
        mov ah, byte [lhost.d] ; Output -> 100
        mov eax, 0 ; Clear eax 
        mov eax, dword [lhost.addr] ; Output -> 100007f 
        ; Also getting the same output if I use only lhost 

        ; Exit the process: 
        push 0
        call [ExitProcess]
    

They don't share the same value in C either. They're wrapped in a struct inside the union. The struct is "one element" and contains four elements itself (but the union sees it as one element).

The struct is shared with the 'addr' member though.

EDIT: The final result 100007f is because it's little endian -- it stores the least significant byte first in memory. (this actually makes far more sense since we read left to right -- our numbers, by default, are written the wrong way around; we just got used to it, but it's not logical at all, since we write words left-to-right but read numbers right-to-left since you can't even pronounce how high a number is without seeing how deep it goes first)

format PE console
use32   ; x86_32
entry start 

include 'win32a.inc'

; This is the data section:
; =======================================================
section '.data' data readable writeable 
        num     dd 1 dup(0)

; =======================================================
section '.text' code readable executable 

start:
        ; Your program begins here
        mov dword [num], 18693h
        mov eax, [num] ; Output -> 18693

        ; Exit the process: 
        push 0
        call [ExitProcess]
    

The data stored in memory is little endian. The first byte is 0x93, the next is 0x86, etc.

0x18693 is stored as four bytes: 0x93, 0x86, 0x01, 0x00. And is read back the same way, so 0x93 is put into the lowest byte of eax.

Edit: Cross post with Furs.

section '.bss' readable writeable
        num dd 1 dup (?)
section '.text' code readable executable  

start: 
        ; Your program begins here   
        mov [num], 1034fh
        mov eax, [num] ; Output -> 1034f 

        ; Exit the process:  
        push 0 
        call [ExitProcess] 
    

The assembler converts and stores your number in little endian format. You see it in the source code as big endian, but if you disassemble the code and look at the hex output it is little endian. So it is only an optical illusion tricking you.

So when I write code I must think in Big Endian way and when I read the code from hex editor I must think in Little Endian way ?

The_Unknown_Member wrote:

So when I write code I must think in Big Endian way and when I read the code from hex editor I must think in Little Endian way ?

Yes. But only for writing numbers larger than one byte. Normal English number rules use big endian, so our source code tends to follow this convention.

db 1, 2, 3, 4  ; 4 bytes in this order
dd 0x04030201  ; assembles to the exact same thing, but because we store the "dword" at once, in source code it's "big endian" so it's reversed