2017-10-12 7 views
1

J'utilise l'extension de signe pour modifier une variable 32 bits en une variable 64 bits. Toutefois, lorsque j'utilise le décalage logique laissé sur la variable 64 bits, il perd des bits comme s'il était encore 32 bits.décalage logique gauche perdant bits après signe étendre dans l'assembly ARMv8

Je veux pouvoir éventuellement tout déplacer de ma variable d'origine vers le haut de la variable 64 bits. (0xFFFFFFFF00000000 est le résultat que je me attends)

Le code ci-dessous montre un décalage de 8 bits pour montrer où les bits sont perdus:

str_fmt:.string "\nWord Value: 0x%08x \nWord Extended to 64-bit: 0x%016x\nLSL: 0x%016x\n\n" 

     .balign 4 
     .global main  

main: stp  x29, x30, [sp, -16]!  
     mov  x29, sp   

     mov  w19, 0xFFFFFFFF 
     sxtw x20, w19 

     lsl  x21, x20, 8 

results: 
     adrp x0, str_fmt  
     add  x0, x0, :lo12:str_fmt 
     mov  w1, w19    
     mov  x2, x20 
     mov  x3, x21 
     bl  printf 

done: ldp  x29, x30, [sp], 16 
     ret 

La sortie se présente comme suit:

Mot Valeur: 0xffffffff Mot extension à 64 bits: 0x00000000ffffffff LSL: 0x00000000ffffff00

Qu'est-ce que je manque dans mon code pour permettre le passage logique laissé entraîner 0xFFFFFFFF00000000?

Répondre

2

Le spécificateur de formatage x imprime un argument unsigned qui est un type 32 bits sur les ABI ARM que je connais. Cela provoque printf pour ignorer les 32 bits élevés de l'argument. Utilisez llx pour imprimer un argument long long unsigned; est au moins un type 64 bits.

+0

Essayé votre solution, il change le format d'impression, mais ne résout pas le problème de décalage logique laissé perdre des bits – Sarchwalk

+0

@Sarchwalk Vous êtes sûr que vous avez corrigé les deux instances? – fuz

+0

Je reçois une quantité incessante de zéros suivi de ffffffff et ffffff00 dans le dernier cas @fuz – Sarchwalk