Discussion :

[Kannagi]

Après , il faut se méfier du x86 entre le code écrit et comment il fonctionne en interne , y'a un monde :p

Maintenant il y a aussi d'autre architecture où cela sera fait autrement … tout simplement parce que d'autres architectures pourraient proposer un opcode qui fait d'un coup ce que ton code source demande (un peu à la BSWAP du x86).

Même si c'est peu probable vu que de nos jours on est plus sur une logique RISC , il faudrait vraiment une analyse sérieuse pour rajouter ce type d'instruction (qui serait de l'utilisé souvent).
En général , on laisse les instruction SIMD et autre spécialisé pour gérer des calculs lourd si besoin.
(Mais 90% du code ,c'est du load/store/add/branchement )

[Guesset]

Bonjour Kannagi,

...Même si c'est peu probable vu que de nos jours on est plus sur une logique RISC , il faudrait vraiment une analyse sérieuse pour rajouter ce type d'instruction (qui serait de l'utilisé souvent).
En général , on laisse les instruction SIMD et autre spécialisé pour gérer des calculs lourd si besoin...

Comme pshufb qui promène les octets et les mets éventuellement à 0 ? Ce qui plombe ce type d'instructions est qu'il faut aussi charger l'argument de ventilation des octets. Si ce n'est pas vraiment intéressant ici, c'est idéal pour, par exemple, changer (très) rapidement l'ordre des composantes couleurs d'une image.

Pour l'instant, les processeurs CISC restent très largement majoritaires sur ordinateur (et absents des smartphones et de la plupart des tablettes). Cela changera peut être si l'initiative d'Apple fait des émules. Mais Apple nous a habitué à changer régulièrement de processeur sans s'occuper réellement de la rétrocompatibilité.

Salut

[Kannagi]

Bonjour Kannagi,
Pour l'instant, les processeurs CISC restent très largement majoritaires sur ordinateur (et absents des smartphones et de la plupart des tablettes). Cela changera peut être si l'initiative d'Apple fait des émules. Mais Apple nous a habitué à changer régulièrement de processeur sans s'occuper réellement de la rétrocompatibilité.

*sur PC
Pourquoi pour les processeurs CISC ?
A ma connaissance y'en a qu'un seul c'est le x86 (tout les autres processeurs CISC ont disparu de la circulation).
Et si il est majoritaire (pour le PC) ,c'est plus pour des raisons historique (rétrocompatibilité) que par un avantage quelconque niveau ISA.

[Guesset]

Bonjour Kannagi,

*sur PC

Sur PC et serveurs (non Personal Computer ).

Pourquoi pour les processeurs CISC ?

Par complétude avec les RISC par définition.

A ma connaissance y'en a qu'un seul c'est le x86 (tout les autres processeurs CISC ont disparu de la circulation). Et si il est majoritaire (pour le PC) ,c'est plus pour des raisons historique (rétrocompatibilité) que par un avantage quelconque niveau ISA.

Il ne faut pas confondre processeurs (i7, Zen5...) et ISA (x86, x64...) et il y a des différences d'ISA entre Intel et AMD (par exemple SSE 4). La concentration industrielle est toujours à l'œuvre. A part ARM, y a t'il d'autres ISA RISC non marginales (y compris ISA open source V) ?

Ceci étant je n'ai pas de chapelle. Je n'ai avancé que des faits. La rétrocompatibilité est effectivement un moteur important et appréciable pour x86 comme ARM. La profusion d'instructions a des avantages mais également des défauts. Notamment, les compilateurs peinent à tirer partie des instructions non élémentaires. Mais réduire les avantages putatifs à l'ISA ne me semble pas légitime car cela ne définit en rien les performances et cela induirait plutôt un avantage CISC (richesse du jeu d'instructions) en masquant le potentiel d'optimisation des jeux d'instruction réduits (implémentation, compilateurs plus efficients, moindre surface silicium etc.)

Salut

[Kannagi]

Il ne faut pas confondre processeurs (i7, Zen5...) et ISA (x86, x64...) et il y a des différences d'ISA entre Intel et AMD (par exemple SSE 4). La concentration industrielle est toujours à l'œuvre. A part ARM, y a t'il d'autres ISA RISC non marginales (y compris ISA open source V) ?

Je ne les confonds pas et il n'ya rien sur mon message qui laisse interprétation que je confond les deux , je parlais bien des processeurs avec design CISC.
Il y'a beaucoup de processeur RISC , mais pour le moment seul ARM et RISC-V ont le vent au pourpre (et avant PowerPC et MIPS).
Et le Atmel AVR qui équipe pas mal d'Arduino sont RISC eux aussi.

Ceci étant je n'ai pas de chapelle. Je n'ai avancé que des faits. La rétrocompatibilité est effectivement un moteur important et appréciable pour x86 comme ARM. La profusion d'instructions a des avantages mais également des défauts. Notamment, les compilateurs peinent à tirer partie des instructions non élémentaires. Mais réduire les avantages putatifs à l'ISA ne me semble pas légitime car cela ne définit en rien les performances et cela induirait plutôt un avantage CISC (richesse du jeu d'instructions) en masquant le potentiel d'optimisation des jeux d'instruction réduits (implémentation, compilateurs plus efficients, moindre surface silicium etc.)

Le soucis de la rétrocompatibilité est :

"Adapter de vieux programmes à de nouvelles machines signifie habituellement adapter les nouvelles machines pour qu'elles se comportent comme les anciennes."
Alan Jay Perlis

Sinon un mauvais ISA peut réduire les perfs oui (genre un décodage complexe , ou une mauvaise gestion des branchements ).

Pour les hautes performances, ça y joue moins mais justement le x86 consomme et coûte bien plus chère à produire , c'était mon message d'origine pour cela qu'il n'apporte aucun avantage tangible.
Les instructions CISC vu qu'elle sont convertis en RISC en interne (sur Intel/AMD) , ne gagne que le facteur "place" , mais techniquement la moyenne des opcode du x86 n'est pas plus grande qu'un ARM ou RISC-V.