Voici une autre façon d’exprimer mon idée :

Dans ton cas, les fichiers source à assembler sont des suites d’expression correspondant soit à des directives d’assemblage (xdef label), soit à des instructions (move.w d0,d1), soit à des données (dc.w $C8, mais on peut considérer que ces expressions sont équivalentes à des instructions en fait). Les instructions sont formées d’un opcode (move, add, etc.), éventuellement de l’opérateur « . » suivi de la taille des opérandes, et des opérandes. Ces derniers peuvent être des noms de registre (a0, d7, etc.), des adresses absolues, des données, etc.
Bref, il faut procéder ainsi pour décrire formellement la totalité du langage que ton assembleur sera capable de lire.
Dans cette description, les opcodes, opérateurs, noms de registres, etc. sont les différentes classes de lexèmes que tu devras identifier. Par exemple, dans la langue française on utilise des noms, des adjectifs, des verbes, etc. et bien là on a affaire à des opcodes, opérateurs, etc. Le rôle de ton assembleur sera dans un premier temps d’identifier si ces lexèmes mis bout à bout correspondent à une « phrase » correcte. Pour ce faire, il est plus simple de manipuler directement ces lexèmes plutôt que le code source, d’où l’intérêt d’un analyseur lexical qui transforme le fichier source (texte) en une suite de lexèmes qui seront mis à disposition de l’analyseur syntaxique.