[gull] Linux sur processeur Core Duo?

[Marc Mongenet]

Le 13/08/06, Marc SCHAEFER<schaefer at alphanet.ch> a écrit :
>
> Le code 128 bits et plus exécuté dans les processeur x86 ou x86_64 (very
> large instruction set) est-il vraiment public ?

Il n'est pas public.
Notons que cela n'aurait guère de sens puisque ce code
n'existe qu'à l'intérieur du microprocesseur. Il serait public
qu'on ne saurait qu'en faire, sauf comme inspiration si l'on
construit un microprocesseur concurrent.

Attention au vocabulaire : Le code x86 CISC est traduit en
code interne RISC-like qui est appelé MacroOps par AMD et
µops par Intel (Transmeta fait tout autre chose).

Le microcode est encore autre chose, de plus bas niveau,
qui existait surtout dans les 68000 et processeurs CISC de
cette époque. Il n'existait pas dans les premiers
microprocesseurs, ni dans les microprocesseurs RISC,
où tout est « câblé ».
Il en reste un peu dans les Intel et AMD actuels, mais pour des
tâches annexes (pour piloter le décodage des intructions x86
compliquées par exemple). La logique câblée est plus
rapide, le but est donc de se débarasser du microcode.

Le VLIW (very long instruction word) c'est encore un peu
autre chose (introduit par l'Itanium). Les MacroOps/µops
RISC-like ne sont pas des VLIW. L'idée du VLIW, c'est de
fournir au CPU un paquet d'instructions à exécuter un
parallèle « les yeux fermés ». Tandis que L'idée des µops
est de fournir des instructions que le processeur peut
analyser à loisir pour voir s'il peut les exécuter en
parallèle, voir dans le désordre.

Logiquement, chaque modèle de processeur Intel et AMD
a son propre code interne RISC-like. La largeur du code
RISC-like n'est pas publique, mais certainement fixe
(c'est un des buts du RISC). Elle ne me semble pas avoir
de raison d'être une puissance de 2 comme 128.

>  A ma connaissance --
> 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/.

> (ou, et c'est là peut-être
> 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
qu'il est réellement. J'ai du mal à faire sens de cette phrase.


Les processeurs Transmeta n'ont effectivement pas de matériel
de traduction x86->µops car c'est fait par logiciel. Ils n'ont pas
non plus de matériel pour réordonnancer les instructions,
c'est aussi fait par logiciel. En fait, un peu toute les optimisations
sont faites par logiciel. Un Transmeta exécute un JIT (Just in time
compiler), le code x86 étant les données du JIT.

Si le code natif du Transmeta était public, on pourrait compiler
des applications directement en code Transmeta.
Mais Transmeta change surement de format d'instruction avec
chaque modèle de processeur... C'est ce qui est fort: ils n'ont
pas besoin de garder la moindre compatibilité entre leurs
modèles de processeur, du moment qu'ils récrivent le
compilateur JIT.

On peut noter que les instructions Transmeta sont VLIW.

Marc Mongenet