Face à une problématique aussi complexe que l'on découvre au fur et à mesure, il peut être tentant de faire des assomptions afin de pouvoir avancer ou bien parce que cela semble nous arranger.
Par exemple, j'ai eu beaucoup de mal à comprendre le fonctionnement de l'octet ModR/M, en particulier parce que la première instruction est un peu l'exception à la règle. Le ModR/M permet de déterminer deux opérandes : un registre et une adresse mémoire provenant d'un registre, du displacement ou encore d'une combinaison des deux. Cependant j'avais assumé que le registre était toujours la destination alors que l'adresse la source or il s'avère que c'est faux : le ModR/M ne permet que de déterminer des couples registre/adresse, qui est source ou destination est laissée à la discrétion de l'instruction.
Ainsi l'instruction 89 transfère le contenu du registre à l'adresse alors que son pendant 8B fait le contraire.
Du coup à l'origine les deux premières instructions donnaient ça :
MOV DX 0x027E
MOV DX, CS:[0x02C4]
Ce qui ne semblait pas très logique car du coup la première valeur positionnée était écrasée par la seconde instruction (et en plus les descriptifs de DCC me disaient clairement que les opérandes étaient dans l'autre sens) mais bon j'ai mis sur ça le compte de l'optimisation du compilateur qui peut-être se servait de la première valeur pour autre chose. Et j'ai eu tort.
Du coup il va falloir que j'apporte des corrections à mon explication du ModR/M.
C'est la même chose pour les instructions ADD, SUB, OR, ... ce n'est pas parce qu'il n'y a qu'une seule mnémonique qu'il y a qu'un seul encodage. Fort heureusement l'encodage est le même pour la même "famille" d'instructions.