[gull] Linux sur processeur Core Duo?

Marc SCHAEFER schaefer at alphanet.ch
Sun Aug 13 15:48:15 CEST 2006


On Fri, Aug 11, 2006 at 05:47:02PM +0200, Marc Mongenet wrote:
> plusieurs architectures, alors qu'un 68060 offrait le même modèle
> programmeur qu'un 68000...

pas de MMU dans le 68000, et de légères différences techniques de zone
d'adressage, mais sinon, je pense que tu as amplement raison (je me suis arrêté au
68040. Excellent processeur CISC).

> x86. Les processeurs Transmeta exécutent du code Transmeta et
> rien d'autre. Le code Transmeta n'est pas public.

Le code 128 bits et plus exécuté dans les processeur x86 ou x86_64 (very
large instruction set) est-il vraiment public ?  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 (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 est clair -- et cela a été dit ici -- que cela a un avantage
indéniable d'offrir aux développeurs une interface inamovible (x86 et
x86_64) alors que les détails d'implémentation (code VLIS, appelons-le
microcode pour simplifier) peuvent changer ainsi que la performance
et l'adéquation à l'architecture réelle d'implémentation.

Par exemple, je pense que le processeur X d'Intel a une centaine de
registres, qui mappent à un instant donnés les registres dont tu as
parlés (ceux de l'architecture x86 ou x86_64), avec un système de
dépendance sur le pipeline, aliasing de registres, coloring,
prédictions, etc, etc. Et un autre processeur Y, compatible x86 et
x86_64 de la même manière a un autre microcode.

> Ce qui rend un processeur Transmeta compatible x86, c'est un
> émulateur logiciel écrit en code Transmeta (forcément). Théoriquement,
> un processeur Transmeta pourrait donc aussi bien être compatible
> SPARC, MIPS, etc. c'est juste une question du logiciel d'émulation.
> Bien sûr, Transmeta visait le marché x86.

La différence n'est-elle pas que ce qui tourne sur un processeur
x86/x86_64 est un petit programme appelé microcode écrit en code VLIS
spécifique au matériel (processeur), qui interprète un byte-code 
(désolé) en code x86/x86_64; alors que sur le Transmeta une
unité logique (émulateur logiciel) transformait le code x86/x86_64 en
code Transmeta, stocké temporairement dans un cache de code ?

En bref, où Transmeta fait/faisait du `code translating', Intel et AMD font
toujours du `code interpretation'. La différence de performance est
peut-être non négligeable.

Si c'est bien cela la différence, alors un processeur Core moderne
d'Intel ou un AMD64 utilisent toujours les bons vieux principes des
processeurs CISC des années 70 au niveau de l'exécution de code
d'architecture!




More information about the gull mailing list