impressions de montage sur pas la même réponse que le débogueur dit

Question

J'ai créé un programme d'assemblage 8086comme une mission de mon académie, qui imprime simplement en conséquence oui ou non, et l'assembleur TASM montre la mauvaise réponse, quand j'ai vérifié le débogueur pour voir comment cela se passe, il fait vraiment la bonne chose! que dites-vous que le problème est? le code est ci-dessous:

.model small 
.stack 100h 
.data 
    a dw 1101001001001011b 
    b db 'yes$' 
    d db 'no$' 
.code 
    mov ax, @data 
    mov ds, ax 
    mov dx,0 
    mov cl ,1 
    loop1: 
    mov ah,0 
    mov al,0 
    rol a,cl 
    adc ah,0 
    rcr a,cl 
    rcr a,cl 
    adc al,0 
    rol a,cl 
    cmp ah,al 
    jne outloop 
    inc cl 
    inc di 
    cmp di,7 
    jne loop1 
    mov dx ,offset b 
    mov ah,9 
    int 21h 
    jmp outt 
    outloop: 
     mov dx ,offset d 
     mov ah,9 
     int 21h 
     jmp outt 
    outt: 
.exit 
    end 

dans ce code que je avais besoin en fait de vérifier si le numéro (appelé par le nom un sur le segment de données) est symétrique ou non, et d'imprimer la réponse . et dans ce cas, la réponse devrait être oui, mais il imprime pas ..

Answer 1

Ce que Michael a dit, ainsi que quelques idées sur la façon de procéder si vous frappez le même problème à l'avenir:

Lorsque débogueur échoue, vous pouvez infester Ainsi, par exemple: si vous produisiez chaque cycle "* \ n" à l'écran, vous vous rendrez vite compte qu'il ne se termine pas après 7 cycles, mais en fait beaucoup plus.

Ensuite, vous pouvez vous concentrer sur la validation de toutes vos hypothèses sur les sorties de boucle possibles, comme les valeurs d'impression en ax (avant cmp ah,al) et di (avant cmp di,7).

C'est une mesure désespérée, mais aide parfois (pour le coût du temps).

Parfois, il est encore plus rapide de démarrer à nouveau, et d'écrire une fonction particulière complètement à partir de zéro. Utilisez le dépôt local git, et commettez souvent, chaque fois que vous avez terminé une petite tâche, puis débogué et fonctionne, ainsi vous pouvez facilement revenir à une version fonctionnelle et recommencer la modification. Ou au moins facilement comparer, quels changements vous avez fait au vieux code de travail. Ou pour éviter de fausses suppositions, mettez intentionnellement des valeurs comme 0xDEADBEEF dans tous les registres au début de votre application et un peu plus sur les tampons pile/mémoire ou après l'allocation de mémoire, ou avant qu'elle ne soit libérée, etc. (rendre le code facultatif pour la construction de débogage seulement par certains define-macro). Les versions de débogage C++ utilisent souvent divers marqueurs de mémoire CCCC.../DDDD.../FDFD../... pour remplir la mémoire non initialisée/libérée, de sorte que le code tape des valeurs «bizarres» au cas où il ferait quelque chose de mal.