Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Actualité : Pourquoi Transmeta ?
(Article écrit par Didier Levet et extrait d'ANews - septembre 1999)
|
|
A l'heure des spéculations sur le microprocesseur choisi pour l'Amiga NG, un nom revient très souvent : Transmeta.
Cette société, fondée en 1995, travaille sur quelque chose de révolutionnaire dans le plus grand secret et a embauché bon
nombre d'ingénieurs venant de Sun (Sparc), MIPS et IBM. Sans parler de Linus Torvalds, papa de Linux. La lecture de brevets
d'invention déposés par Transmeta (US 5832205, US 5905855 et US 5926832) permet néanmoins de cerner un peu mieux ce qui pourrait
devenir le microprocesseur du futur...
Sur le marché des microprocesseurs, les places sont chères. C'est en partant de cette simple constatation que Transmeta a eu
l'idée de concevoir les choses autrement, étant entendu qu'il est impossible à une jeune société de construire un microprocesseur
plus performant et moins cher que les autres en utilisant les mêmes techniques.
La viabilité commerciale d'un tel produit exige les caractéristiques suivantes :
- Le nouveau microprocesseur doit pouvoir exécuter toutes les applications de la plate-forme visée (x86, dans un premier temps,
puisque c'est la base la plus large).
- Il doit pouvoir exécuter ces applications au moins aussi rapidement que le microprocesseur de référence (en l'occurrence Intel).
- Il doit coûter moins cher que ce microprocesseur de référence.
- Enfin, il doit proposer quelque chose de plus afin de contourner l'appréhension des acheteurs potentiels, qui préfèrent
généralement privilégier les choix éprouvés.
Pour Transmeta, ces objectifs peuvent être atteints en développant ce qu'on pourrait appeler un microprocesseur polymorphe. Plutôt
que de chercher à surpasser les concurrents potentiels dans leurs propres domaines, ce qui serait assez présomptueux, ils travaillent
activement sur un microprocesseur spécialement optimisé pour émuler tout autre microprocesseur.
L'objectif de Transmeta est clair et sans appel : fournir un microprocesseur capable d'exécuter n'importe quelle application,
développée pour n'importe quel système d'exploitation, compilée pour n'importe quel microprocesseur et qui soit plus rapide et
moins cher que le système original.
On peut appeler ça l'arme absolue...
De fait, l'architecture de Transmeta est à la fois révolutionnaire et très surprenante. Elle est articulée autour d'un
microprocesseur débarrassé des raffinements superflus, associé à une gestion matérielle accélérant notablement la phase d'émulation
et chapeauté par une partie logicielle chargée de l'émulation proprement dite (ce logiciel faisant partie intégrante du processeur).
Le microprocesseur de base ("natif") peut-être de n'importe quel type. Néanmoins, Transmeta semble privilégier l'architecture VLIW
(Very Long Instruction Words) qui offre de nombreux avantages.
Techniquement, l'ensemble fonctionne à peu de chose près comme un microprocesseur CISC (Complex Instruction Set Computer) où
chaque instruction de haut niveau (assembleur) est convertie en interne en une séquence de microcode.
Dans le cas du Transmeta, cette conversion est effectuée par la partie logicielle, ce qui offre un certain nombre d'avantages,
mais aussi d'inconvénients.
Parmi les avantages et non des moindres, la couche logicielle permet une plus grande liberté d'action que la solution matérielle.
Ainsi, il est possible d'ordonner le microcode correspondant à plusieurs instructions successives de haut niveau et même de
l'optimiser (ce qui est impossible à réaliser de façon matérielle, ou à un coût exorbitant). D'autre part, il n'est plus nécessaire
d'avoir plusieurs millions de transistors pour gérer les dépendances entre les différentes unités d'exécution fonctionnant en
parallèle, ou encore pour gérer l'exécution des instructions dans le désordre, ou bien pour prédire les branchements avant qu'ils
n'aient effectivement lieu.
Et qui dit moins de transistors, dit coût réduit et fréquence de fonctionnement supérieure...
Côté inconvénients, la vitesse d'exécution semble en être un de taille. En pratique, grâce à l'utilisation d'un tampon spécifique
(une sorte de cache), la traduction des instructions "cibles" en instructions "natives" n'est effectuée qu'une seule fois. En
simplifiant un peu, cela revient à dire que le microprocesseur apprend à exécuter les instructions cibles au fur et à mesure
qu'il les rencontre et finit par exécuter un programme constitué d'une suite ininterrompue d'instructions natives, dans un ordre
optimal, synonyme de performance maximale.
Un exemple d'implémentation revient à plusieurs reprises dans les brevets mentionnés plus haut. Selon Transmeta (je rappelle aux
sceptiques que ceci est mentionné clairement dans des brevets d'invention officiels), un prototype comprenant quatre fois moins
de transistors qu'un Pentium Pro est capable d'exécuter n'importe quelle application compilée pour les processeurs de la série
x86 et plus rapidement qu'un Pentium Pro !
C'est déjà une belle référence...
En résumé, voilà un microprocesseur passe-partout, faisant fi de tout problème de compatibilité entre plates-formes. La fin des
portages ?
Pour autant, le processeur ne peut pas tout prendre en charge de façon totalement transparente. Être capable d'exécuter une
application est une chose, mais encore faut-il pouvoir faire la relation entre le système d'exploitation attendu par cette
application et le système d'exploitation de la machine hôte. Les solutions à ce problème ne sont pas légion. Si on se contente
de convertir les appels vers le système d'exploitation émulé en des appels vers le système d'exploitation hôte, il faut fournir un émulateur spécifique pour chaque OS
hôte différent. L'autre solution, simplificatrice, est de n'avoir qu'un seul OS hôte, quelle que soit la machine. Cette dernière
solution permet d'améliorer grandement les performances de l'émulation.
Un OS multiplate-forme ? Il y a bien Linux.…Bizarrement, Transmeta a embauché Linus Torvalds, père de Linux. Comme c'est étrange...
Tout ceci nous conduit à un faisceau de présomptions menant tout droit au choix de Transmeta pour l'Amiga MCC (indépendamment du
fait que le nom de Transmeta ait été mentionné sur une vidéo-projection pendant le salon WoA, bien que cette mention soit
aussi un indice supplémentaire).
Parmi les informations fournies par la fiche technique, publiée le 16 juillet, on peut retenir :
- Que le processeur fera partie de la future génération (VLIW ou Media-computer ?). Le Transmeta rentre dans cette catégorie.
- Choix du noyau Linux, au détriment de QNX. Or, Linux et Transmeta ont quelque chose (ou plutôt quelqu'un) en commun :
Linus Torvalds. D'autre part, le noyau du système d'exploitation sera intimement lié à une architecture spécialisée et très performante.
- Amiga Inc. a choisi un processeur "enthousiasmant". On savait que ce ne serait pas un microprocesseur de la famille x86.
Maintenant, on peut penser que les PowerPC sont hors course, sauf à considérer qu'ils sont "enthousiasmants".
- Le processeur choisi permet de tirer les meilleures performances de Linux et des applications Java. Il permet aussi d'exécuter
les applications Amiga Classic, le tout avec une assistance matérielle. Ici, le Transmeta est tout indiqué puisqu'il est
capable d'émuler un Pentium Pro, il est aussi capable d'exécuter du "byte-code" Java et à fortiori du code 68k, pour les
mêmes raisons.
Si on ajoute à tout cela le fait que le prix de vente du MCC ne devrait pas dépasser les 500 $, cela laisse peu de place pour
les microprocesseurs les plus puissants du moment, d'autant plus que ces microprocesseurs font partie des vieillissantes
familles CISC (Pentium) et RISC (PowerPC, entre autres).
Évidemment, ce ne sont que des présomptions. Mais avouez que ça commence à en faire beaucoup, non ?
|
