Les compilateurs natifs traduisent directement les instructions de la machine abstraite ou les instructions de langage intermédiaire en instruction du processeur cible. Ensuite ce code produit est soit lié à des bibliothèques pour créer un exécutable, soit directement chargé dans un environnement interactif qui met à jour table des symboles et zone de code. On peut imaginer ainsi obtenir l'exécution optimale de son programme.

Mais c'est rarement le cas. La traduction instruction par instruction n'est pas optimale. La répétition de séquence arrive souvent, ce qui entraîne un code assez long. Les optimisations possibles ne se font que sur le code de la machine abstraite et après il est souvent trop tard pour en effectuer d'efficaces sur la production d'instructions machine.

En fait pour obtenir de bonnes optimisations, il faut rester au niveau du langage évolué tout en ayant une bonne connaissance du processeur cible. C'est assez difficile car cela nécessite un compilateur spécifique par machine. Et surtout rend inutile tout le travail de formalisation de passage par une machine abstraite ayant de bonnes propriétés pour le langage à compiler.

Le langage Caml V2-6 utilise cette technique. Après différentes phases d'analyse, l'arbre de syntaxe abstraite de la phrase du langage à compiler est traduit en code CAM. Celui-ci est après optimisation traduit en code LAP (langage intermédiaire), assembleur de la machine virtuelle LLM3 . Enfin le code LLM3 est expansé en instructions machine puis chargé. Les résultats sont bons, mais on est loin d'une efficacité optimale que l'on aurait pu espérer.

La partie à réécrire pour chaque nouveau processeur est réduite à l'expanse ur du code intermédiaire. Le problème d'efficacité provient de l'architecture de cette machine intermédiaire entre la machine abstraite du langage fonctionnel et le processeur cible. Elle n'est pas toujours conçue pour les architectures nouvelles des processeurs. Typiquement, les gains