[gull] Linux sur processeur Core Duo?

[Marc SCHAEFER]

On Mon, Aug 14, 2006 at 01:20:11AM +0200, Marc Mongenet wrote:
> >mais je n'ai pas vérifié et je ne me considère pas du tout comme un
> >expert de x86 ou x86_64 -- le code *public* c'est le jeu d'instruction
> >x86 et x86_64 (merci AMD), il est transcrit par le "matériel" en code
> >VLIS, qui est lui exécuté par le processeur
> 
> Oui, c'est exactement cela, avec s/code VLIS/µops/.

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)

cas Transmeta
   x86 -> VLIW  (via une couche logicielle, en pratique un peu un
microcode dans le processeur; 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é)

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; donc plus de matériel pour cette
partie, par contre la conversion va à grande vitesse, prédictible)
   
> >la nuance avec Transmeta, il *interprète* le code CISC x86/x86_64 depuis
> >un microcode VLIS).
> 
> Il me semble que tu ne t'imagines pas le fonctionnement tel

non, effectivement, et c'est heureux, car sinon la performance `perdue'
sur Intel/AMD serait énorme. Avec un traducteur matériel en µops la
perte est moindre. Mais on regrette quand même ne pas avoir accès plutôt
à cette couche RISC directement.

Quelques informations supplémentaires:
   http://en.wikipedia.org/wiki/Microprogram#Microcode_versus_VLIW_and_RISC
(où l'on voit la convergence CISC/microcode/RISC/VLIW)

> 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. Peut-être un jour
offriront-ils une option `dump' de leur `mémoire cache d'instruction'
pour augmenter la performance ? :)

> On peut noter que les instructions Transmeta sont VLIW.

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.

Il y a longtemps il y avait de drôles de machines qui exécutaient le
code LISP `compilé' (byte-code probablement) directement, y compris avec
typage de chaque mot de donnée de 32 bits (avec des bits en plus), les
machines Symbolics (http://en.wikipedia.org/wiki/Symbolics)

PS: c'est intéressant de voir que les processeurs ont une évolution
    similaire au développement: on a accéléré le cycle
    codage/compilation/exécution(*) au prix d'un peu de perte de
    performance.  

(*) imaginez que plutôt que d'avoir un IDE à votre disposition (édition,
    développement, compilation, exécution, debugger, etc) vous
    développez sur une carte perforée en FORTRAN et que la
    fenêtre d'exécution c'est le jeudi de 10h à 10h15. Je sais c'est
    dur à imaginer.