[gull] Linux sur processeur Core Duo?

Marc Mongenet marc at mongenet.ch
Tue Aug 15 07:13:24 CEST 2006


> 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



More information about the gull mailing list