Donc, pour résumer:
x86 et x86_64 (appelons cela le jeu public)
µops (le jeu d'instruction RISC interne au processeur)
VLIW (le jeu d'instruction RISC interne au processeur, a exécuter
immédiatement sans aucun réordonnancement, etc)
Le code VLIW n'est pas particulièrement interne.
C'est simplement le type de code des processeurs VLIW
(Itanium, Transmeta).
cas Transmeta
x86 -> VLIW (via une couche logicielle, en pratique un peu un
microcode dans le processeur;
Mh, j'aurais tendance à penser qu'il n'y a pas le moindre
microcode dans un processeur VLIW (comme le Transmeta).
Le but du VLIW, c'est tout de même que le travail soit encore
plus prémâché par le compilateur que pour le RISC.
En l'occurrence, c'est le travail de "super-scalairisation" que
le compilateur doit faire en plus.
pourrait aussi être un compilateur mais
les empêcherait de changer facilement le VLIW et la structure du
processeur; le processeur Transmeta lui-même n'a que peu de support de
réordonnancement, et donc est très simple et peu aller vite sans
chauffer; l'étape de traduction est gourmande: intérêt de cacher le code
généré)
Le code généré est effectivement stocké, en RAM par exemple.
Il peut y avoir plusieurs passes d'optimisation, s'il est dans une
boucle souvent réexécutée. Il me semble que ce principe de
passes d'optimisations multiples existent aussi avec les JIT Java.
cas Intel/AMD
x86/x86_64 -> µops (via du matériel, un générateur d'instruction
RISC; mais une fois les instructions générées, le processeur peut, par
hardware, réordonnancer certaines, etc;
Oui, en sortant du décodeur, les µops sont stockées dans un
tampon de réordonnancement qui peut en contenir jusqu'à
plusieurs dizaines.
donc plus de matériel pour cette
partie, par contre la conversion va à grande vitesse, prédictible)
Oui, il y a du matériel pour la traduction x86 -> µops.
Et surtout, il y a un matériel extrêmement complexe pour
trouver à chaque coups d'horloge un maximum de µops
à envoyer en parallèle dans les ALU, unité load/store, FPU,
branchement, etc.
> Si le code natif du Transmeta était public, on pourrait compiler
> des applications directement en code Transmeta.
En fait ils livrent le compilateur dans le processeur.
Non non, le compilateur est dans un BIOS, chargé avant
le BIOS classique du PC.
Ok. Merci des explications complètes. Transmeta a-t-il développé un
processeur à exécution d'autres `langages' que x86? Je pense p.ex. au
LISP, Perl, Python, Java, etc. Ou à d'autres jeux d'instruction.
Pas que je sache. Mais, c'est seulement
le compilateur (c'est un émulateur pour être précis) qu'il faudrait
développer. A moins que le CPU ait quelques particularité qui vont
bien seulement pour faire tourner un émulateur de x86?
Marc Mongenet
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
