Je suis pas sur que le fait d'associer "Error" avec "ignored" soit vraiment un signe de fiabilité... C'est assez atroce comme message d'erreur. Y'a une erreur ou bien on te prévient que quelque chose est ignoré ? Ça peut être soit l'un soit l'autre mais pas les deux... Bref c dégueux. (Si tu informes l'utilisateur que quelque chose a été ignoré, c'est un
Attention !. Si c'est une erreur il te reste quoi à ignorer vu que tout le code va passer à la trappe ensuite ? Ça a aucun sens
)
Sinon tant que l'assembleur ne génère pas de code incorrect on ne peut pas vraiment le qualifier de pas fiable... Dans le cas d'accepter une instruction incorrecte (sémantiquement c'est juste le a qui est en trop), mais pas strictement invalide, et de la compiler comme il faut, il n'y a aucun problème (cela dit ça demande à être documenté). Le seul truc qu'il y a de non fiable là dedans après c'est la validation du code...
J'imagine que le comportement implémenté c'est une méta-instruction move (c'est ce que j'aurais fait en tout cas) puis une redirection de tous les move* dérivés (donc pas movep
) vers cette méta instruction, pour la compatibilité avec le code *valide* déjà existant... Après c'est pas comme si move et movea avaient un comportement totalement différent. Si tu écris <truc> <op1> <op2>, on peut supposer à priori que tu es sain d'esprit (enfin...), et que tu as pas tapé tes <op1> et <op2> au pif. Donc que si tu veux mettre #5 dans d0, c'est pas le fait d'écrire move ou movea qui va changer ton intention. Par contre si tu confonds add avec sub la c'est un problème cérébral
PS: J'adore faire chier les gens sur des détails à la con... À la con mais pas pour autant à prendre à la légère...
:
.
J'suis rarement plus d'une heure sur PC --"
)
C'est pire que A68k, ça. 
)
