A priori le truc des #imm est aussi valide pour ADD, SUB & compagnie (enfin j'ai pas vérifié en détail mais normalement oui), vu que de toutes façons ce sont toutes des opérations arithmétiques au même titre (donc construites de la même manière à 2-3 exceptions près)
Dans ce cas là tout au moins je pense que c'est très simple, c'est de l'optimisation.
En fait CMPI s'applique partout où la source est un immédiat (et le destination est "ce que tu veux sauf un registre d'adresse"), et CMP s'applique partout où la destination est un registre de données (et le destination est "ce que tu veux").
Le cas de CMPA étant encore une autre histoire (seulement .w ou .l pour les adresses, donc un opcode à part), mais ça permet de donner quelques indices supplémentaires
En fait le coup du CMP[I] #imm, Dn est simplement le point de réunion de deux opcodes. Vu que CMPA #imm, An est possible (et pas CMPI #imm, An), tu ne veux pas forcément
rajouter des transistors pour interdire d'utiliser le mode #imm sur l'instruction "juste à côté", c'est à dire CMP <ea>, Dn
Le seul truc c'est que si tu es logique, tu pourrais appliquer plus simplement certaines optimisations (au niveau du CPU principalement ^^) aux instructions avec source immédiate (CMPI/...) car tu sais d'avance que l'opcode est toujours suivi d'une valeur immédiate, et il ne te reste qu'à traiter la composante "variable" qu'est la destination... Quand à savoir ce qu'il en est réellement...
Et puis si tu regardes, il y a plein d'instructions qui font la même chose que d'autre dans des conditions précises, mais en général ce n'est qu'un recoupement de fonctionnalités. (Bon après il y a le cas des instructions "non prévues pour" qui sont plus rapides que les instructions "prévues pour" mais c'est une autre histoire
)
Mais ton assembleur révolutionnaire vaut bien ça !
) http://goldencrystal.free.fr/M68kOpcodes-v2.2.pdf
).
le fond d'écran 
)
