Discussion:Microprocesseur à jeu d'instructions étendu

Est ce qu'on déplace vers microprocesseur à jeu d'instruction étendu ? ça reflete la réalité et c'est un titre en français. Greudin (Discuter)

Pour, en conservant la redirection CISC --> nouveau titre et Complex instruction set computer vers nouveau titre, de même pour RISC phe

Au fait, pourquoi traduire Complex par Etendu ? Je propose de concerver 'complexe'. Je vais essayer de voir comment cela a ete traduit dans les articles qui vont bien. D'accord pour le titre en francais avec CISC pointant vers icelui. Stéphane 3 jun 2005 à 01:59 (CEST)

Cet etendu me gêne de plus en plus :-) Certes, les instructions complexes des CISC (genre AOJE Add One and Jump if Equal, et al.) ont disparu. Mais c'est surtout le nombre de modes d'adressage qui a fortement diminue : 7 modes sur le PDP-11, 1 sur le MIPS R2000/R3000. ADD (R1)+, 1000(R2), @(R3) a la VAX, c'etait fini, mais le ADD est toujours la ... On devrait donc garder le 'Complex' tel quel et pas le traduire par 'etendu', qui sous entend qu'il y a beaucoup d'instruction, or, aujourd'hui, on peut faire du RISC aussi avec beaucoup d'instructions (*), mais toujours aussi peu de modes d'adressage... Votre avis ? Stéphane 4 jun 2005 à 16:12 (CEST) (*) http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/2EF555D341769CE787256E470077DD3D/$file/750gx_um_pub.pdf

Du moment que les redirs existent je n'ai pas de préférence, sur le net en français les deux sont aussi peu utilisé l'un que l'autre, tout le monde utilise RISC et CISC :) phe 4 jun 2005 à 16:26 (CEST)

massacre de l'article

Je ne comprends les suppressions de "Poil". C'est limite du saccage d'article. j'aimerais bien des explications avant de remettres les informations supprimés.

voir ma page de discussion. J'y explique pourquoi j'ai supprime les imprecisions de l'article. Jusqu'a present je n'ai pas ete contredit. Stéphane 3 jun 2005 à 01:02 (CEST)

Par exemple le passage suprimmé sur les mémoires lentes « Dans les années 70, les mémoires étaient très lentes (RAM et ROM). Aller chercher une instruction prenait du temps par rapport à la vitesse des processeurs. »' Il me semble que ce problème se posait beaucoup plus lors de l'utilisation de mémoires ferro magnétiques donc plutôt dans les années 50 que 70 et que la principal motivation de réduire l'empreinte mémoire venait du peu de capacité mémoire des machines des années 70. phe 4 jun 2005 à 16:37 (CEST)

Les 2 devaient jouer. Mais on peut toujours jouer sur des appels de fonction pour réduire la taille d'un code. C'est plus difficile d'accélérer un temps d'acces.

qu'est ce que ca veut dire "on peut toujours jouer sur des appels de fonction pour réduire la taille d'un code" svp ? Merci.

Phe à raison : les machines avaient peu de mémoire centrale, ce qui en faisait une ressources critique. Proposer un processeur dont les instructions offraient une faible empreinte en mémoire centrale était un atout. Sauf, évidement, dans le monde des superordinateurs, où là tout était permis ;-)

Comme Phe me l'avait signalé lors d'une discusion sur la taille de l'espace d'adressage, on à jamais assez de mémoire (puisque visiblement certains problèmes demandent plus de 2^64 octets de mémoire... cf. Phe pour plus d'infos, j'ai oublié son example ;-) ).

Stéphane

"on peut toujours jouer sur des appels de fonction pour réduire la taille d'un code" signifie que tu peux optimiser un binaire pour en réduire sa taille.

Optimiser un binaire ?

je pensais optimisation à la compilation.

Aujourd'hui, la plus part des optimisations sont orienté performances plutot que empreinte mémoire (sauf cpu pour l'embarqué). La taille d'un code est interrescant aujourd'hui pour limiter la taille des caches internes au cpu (L1 typiquement). L'itanium d'intel a une telle expention de code qu'il a besoin de caches énormes. Si on regarde l'usage de la mémoire de façon global, la conso mémoire devait, même à l'époque, surtout venir des données plutot que le code.

L'emploi du conditionel n'est - a mon avis - à proscrire dans un article encyclopedique. Moi j'aime bien les machines IBM a base de POWER5 : 36 Mo de cache L3 ! (deja la L2 (on chip) est "10-way associative 1.9 MB" !

Mais d'un point de vue financier... ou energétique, c'est pas top :)

Je ne pense pas que des problèmes "réel" puissent utiliser aujourd'hui 2^64 octets de mémoires. Rien que le fait de lire ses données doit prendres des jours avec les performances en lectures des mémoires actuelles.

???? Lire une donnée dans un espace de 2^64 ne doit pas etre significativement plus long que dans un espace de 2^32...

Evidement, mais si on a besoin de 2^64 octets de donnés c'est pour les lire en grandes parti. Pas pour accéder seulement à une fraction.

Enfin, bref, tout ça pour dire que j'ai lu et entendu parler plusieurs fois du fait de la différence de vitesse entre ROM et RAM de l'époque (~1970) qui a amener au vax.

citez vos references donc ! A propos, vous disiez ne pas connaitre le vax... Stéphane 18 jun 2005 à 01:00 (CEST)

Pas en détail. Mais le VAX est un des derniers "gros" ordinateur CISC.