[gull] x86_64

Marc SCHAEFER schaefer at alphanet.ch
Mon Jun 5 13:47:29 CEST 2006


On Mon, Jun 05, 2006 at 12:56:41PM +0200, Marc Mongenet wrote:
> Il y a malgré tout encore beaucoup d'innovations.
> Par exemple il me semble que les processeurs de
> Transmeta exécutaient leurs propres instructions et
> faisaient en fait fonctionner un émulateur
> (de x86 puisque c'était le plus grand marché).

C'est `vieux' ... 2000 ou 2001.  Effectivement, leur principal atout
était le `code-morphing', une interprétation de code CISC Intel par un
processeur VLIW (very-large-instruction-word, style 128 bits ou plus par
instruction) simplifié, donc économique.

Mais cela n'était pas en soit révolutionnaire (cela ressemble en fait
beaucoup à un microcode VLIW ou RISC interprétant du code CISC/RISC). Ce
qui était révolutionnaire, j'avais cru comprendre à l'époque, c'était
que l'optimiseur de code pouvait améliorer sa sortie pour une code donné
et le garder dans un cache de code.

En bref, plus un bout de code était exécuté souvent, plus son
optimisation en code VLIW était grande.  Un peu comme le fameux langage
Self et son auto-optimisation, mais à un autre niveau.

> Peut-être va-t-on aussi voir arriver des processeurs sans
> horloge?

`c'est prêt quand c'est prêt' :)

> Pour les années à venir, c'est la guerre au niveau des fondeurs
> (Intel vs AMD-IBM) pour réduire la tailles du gravage (Intel a de l'avance).
> Mais il me semble qu'il y a de moins en moins de fondeurs
> indépendants, à cause du prix des usines ("only real men have fabs")

C'est un problème général dans notre monde actuel: ceux qui font
réellement le travail (p.ex. raffineries de pétrole, fondeurs, etc) sont
de moins en moins nombreux, le profit étant plus intéressant dans le
marketing (cf Cailler WENGER) que dans le produit réel.

> Logiquement (en fait j'en sais rien :-), les micro-instructions VLIW
> internes sont adaptées à chaque noyau, donc incompatibles d'une
> génération de processeur à l'autre.

oui, c'est un avantage de la couche CISC.

tu précèdes ma pensée:

> C'est même peut-être un avantage des CISC :
> un jeu d'instruction compacte qui n'encombre
> pas les mémoires (disque, RAM, cache), et qui est transformé
> en des instructions parfaitement adaptées au noyau de chaque
> processeur. Bref, le code x86 n'est plus qu'un bytecode. D'ailleurs
> le Pentium 4 a un cache L1 de micro-instructions, on peut donc
> dire qu'il fait de la compilation JIT (just-in-time). :-)

J'avais tendance à penser que le C était le langage compact portable.
:->

Ce que tu décris, c'est donc une partie de la technologie Transmeta,
non? Je suis d'ailleurs surpris de voir que Transmeta existe toujours,
apparemment grâce à Sony (et grâce à de l'embarqué/spécialisé pour
le tiers monde via Microsoft, il semblerait).

> Il faut encore noter à propos du JIT que le travail fait à l'avance
> (par un compilateur) n'est pas forcément toujours plus efficace.

C'est juste!  Les deux sont complémentaires.

(tout cela rend relativement incompréhensible tout code sortant d'un
compilateur aujourd'hui. C'était tellement simple avec le SPARC et ses
instructions dans le pipeline avant un BRANCH :->)




More information about the gull mailing list