Linux est mort !! Vive SkyOS ! - Page 5

Miles :
A part sur les PCs, tout le reste est en RISC maintenant. La seule raison pour laquelle Intel est encore en RISC est la compatibilité ascendante qu'ils veulent. Ca n'a rien à voir avec le traitement du signal - voit pas le rapport avec le TS sur un 8051 de chez Philips, par ex -

Intel est en CISC plutot nan ?

LizDog
:

Miles :
A part sur les PCs, tout le reste est en RISC maintenant. La seule raison pour laquelle Intel est encore en RISC est la compatibilité ascendante qu'ils veulent. Ca n'a rien à voir avec le traitement du signal - voit pas le rapport avec le TS sur un 8051 de chez Philips, par ex -

Intel est en CISC plutot nan ?

pardon, lapsus de ma part, c'est le seul à être encore en CISC, merci d'avoir noté cette erreur.

RISC = années 80, non ? Et ce n'est pas inhérent à l'archi RISC, c'est toujours plus compliqué, les pipelines, il faut modifier le chemin de données, et le séquenceur en câblé est plus dur, au début, à gérer avec des pipelines.

- Le principe du recouvrement d'instructions remonte à 1960
- Le CDC6600, fabriqué par Control Data en 1964 utilisait déjà une architecture RISC à recouvrement d'instructions

A part sur les PCs, tout le reste est en RISC maintenant. La seule raison pour laquelle Intel est encore en RISC est la compatibilité ascendante qu'ils veulent. Ca n'a rien à voir avec le traitement du signal - voit pas le rapport avec le TS sur un 8051 de chez Philips, par ex -

Non, ça n'a rien à voir avec le traitement du signal. L'implication marche dans l'autre sens. Et c'est pour ça que je suis d'accord sur le fait que Intel est encore en RISC pour garder la compatibilité.
=> j'en reviens donc au point de départ : les x86 ne s'orientent pas vers une architecture RISC. Si Intel devait sortir une architecture RISC en tant que successeur aux x86, cette architecture ne serait plus un x86. En attendant, ils essaient de pallier aux déficiences du CISC en ajoutant des instruction superspécialisées et faisant du SIMD comme le SSE.

réputés pour le traitement audio, surtout. Au fait, par rapport au post précédent, les RISC sont très orientés SIMD - pas les DSPs, hein, les autres RISC qu'on conçoit pour des applis particulières comme la compression/décompression audio/vidéo sur nos lecteurs mp3, divx, ... par ex -

Suis d'accord. Mais les même différences qui différencient un RISC et un CISC pour les instructions normales s'appliquent pour les instructions SIMD.

pardon, lapsus de ma part, c'est le seul à être encore en CISC, merci d'avoir noté cette erreur.

J'avais corrigé à la volée, en lisant

Quel est le rapport entre recouvrement d'instruction et RISC ? Le RISC, c'est un changement de mentalité au niveau du séquenceur...

D'ailleurs, t'as fait la même erreur que moi dans ton post

1) Ben justement, ce changement de mentalité au niveau du séquenceur EST celui de la séparation des différentes étapes de traitement des instructions (pipeline d'exécutions) visant à garder actifs les différents éléments du processeur à un instant donné.
Le RISC et le recouvrement d'instructions sont intimement liés.
- Notamment, un point très important sans lequel le recouvrement d'instructions serait infaisable est que seules les intructions Load et Store (ou équivalents, selon le proc) accèdent à la mémoire. Et c'est une caractéristique essentielle des architectures RISC.
- L'autre point important est que les opérations entre les registres s'effectuent toujours en un seul cycle de calcul, ce qui est également essentiel pour pouvoir pratiquer le recouvrement d'instructions (toutes les étapes du traitement d'une instruction devant faire le même nombre de cyles pour ça). Les opérations nécessitant plus de temps sont reléguées à un coprocesseur/calculateur/équivalent pour ne pas bloquer le traitement (ainsi le calcul se fait en "tâche de fond").

2) ah oui. Pas grave, tu m'avais quand même compris