Domanda Risolto Come si comportano le double word su processore con paralellismo su 16bit

[mattstack]

Scusate il titolo non è dei migliori, comunque stavo facendo un paio di prove con il debugger quando mi accordo di una cosa, per quale motivo se memorizzo in AX la word meno significativa di una double word contenente 65536, quindi la word meno significativa conterrà 65535 e quella più significativa 1, in AX viene memorizzato un valore diverso da 65535?

Come si può vedere in AX viene caricato il contenuto dell'indirizzo fisico DS : 0000 che corrisponde all'indirizzo fisico del primo byte della double word e quindi del primo byte della word meno significativa, in poche parole l'indirizzo della word meno significativa che però apposto di "contenere" 65535(10) FFFFF(16) contiene il valore 0, mentre la word più significativa contiene il valore che ovviamente non è stato possibile allocare nella word meno significativa che è quel 1 di troppo.
Ecco il codice:

stack SEGMENT PARA STACK

        db      ?

stack ENDS

data SEGMENT PARA PUBLIC

        var1    dd      65536

data ENDS

code SEGMENT PARA PUBLIC

        ASSUME ss: stack, ds: data, cs: code

_start:
        mov     ax, data
        mov     ds, ax

        ;bx = word meno significativa    ax = più significativa
        mov     ax, WORD PTR var1
        mov     bx, WORD PTR var1+2

code ENDS
        END _start

Come si può vedere ho inizializzato la double word con il valore 65536, quindi la word meno significativa dovrebbe contenere 65536 e quella più significativa 1, allora perché il debugger mostra alto, inoltre i dati vengono gestiti il litle endian quindi credo sia ancora più probabile che nella word meno significativa ci sia 65535.
Perché Questo? Grazie

EDIT:
Mi sono reso conto che se nella word più significativa viene memorizzato 1 la word meno significativa si azzero, infatti seguendo la "sequenza" binaria:

65536 = 1111111111111111 => FFFFH
1 = 0000000000000001 = > 1H

Quindi l'intera double word conterrà:

0000000000000001 | 0000000000000000

tutti i bit vengono forzati a 0.
Era per caso questo il motivo, perché ciò non accade anche con i registri?

 

[DispatchCode]

Devo essere sincero, non ho capito molto di ciò che intendi (forse è perchè ho solo letto di fretta)... tu stai usando registri a 16bit, quindi il valore massimo è 65535. Se assegni 65536 ovviamente vedi il valore 0.
Non ho capito perchè guardi registri a 32bit, immagino tu abbia compilato e linkato con link16. Giusto?

Comunque no:

65536 = 1111111111111111 => FFFFH

65536 = 10000h

FFFFh è 65535, che è il massimo valore rappresentabile in 16bit (ricordati che sono 65536 valori, ma inizi da 0).

 

[mattstack]

Devo essere sincero, non ho capito molto di ciò che intendi (forse è perchè ho solo letto di fretta)... tu stai usando registri a 16bit, quindi il valore massimo è 65535. Se assegni 65536 ovviamente vedi il valore 0.
Non ho capito perchè guardi registri a 32bit, immagino tu abbia compilato e linkato con link16. Giusto?

Comunque no:

65536 = 1111111111111111 => FFFFH

65536 = 10000h

FFFFh è 65535, che è il massimo valore rappresentabile in 16bit (ricordati che sono 65536 valori, ma inizi da 0).

In pratica perche ciò non accade con i registri, se memorizzo 256 in al, perché va in overflow anche se ci sono ancora a disposizione i 16bit del registro ah.

 

[DispatchCode]

Perchè stai operando su un registro a 8bit, quindi è corretto che non venga alterato il valore del registro AH. AL è "mappato" nella parte bassa di AX, quindi AX riflette il cambiamento.

Piuttosto ci sono alcuni comportamenti che potresti non aspettarti, ma li vedrai meglio usando poi 32 e 64bit.
Ad esempio (32bit):

mov   ax, bx

non modifica la parte alta di EAX.

Ma se fai (64bit):

mov    eax, ebx

viene posta a 0 la parte alta di RAX.

 

[mattstack]

Grazie : )