Reprise du message précédent :
le code dans des boucles c'est comme les données : c'est mieux quand c'est aligné. Et sur les proc récents, le top c'est aligné sur 16 octets. Un pentium se contente de 4 octets mais 16 ça satisfait tt le monde.
Quand à la présevation ça se fait entre l'appel et le retour. Là je parle de pop et push dans le corps d'une fonction. En pushant esi, edi, ebp et ebx au début on peut bosser sur 7 registres tranquilement. Faut juste les poper avant le ret. En assembleur MASM c'est automatisable (directive USES). Les compilo ont tendance à faire des pop et des push plusieurs fois sur le même registre.
La baisse de perfs est masquée par le goulot d'étranglement mémoire. Perso qd je bench je le fait sur un vieux proc où le bus mémoire sature le bus procésseur : un pmmx avec de la PC100 en 2-2-2. Là on voit la diff entre c compilé et assembleur manuel !

j'ai jamais vu des push/pop surnuméraire, parfois meme ils ne sont pas placé en tete de fonction mais que vraiment la ou c'est nécéssaire (ca a un nom cette optimisation...code hoisting, vala)

Moi ce qui me prend le choux dans les compilo en ligne c'est ça :
Les Jxx remplacé par des Jnxx/Jmp car la distance est trop importante. Je préfèrai pouvoir paramétrer ce genre de chose : auto ou manuel.
Up> Je parle pour VC6

 
ehhh oohh doucement .. c'est jesus_christ quand même  

 
huh ? tu peux donner un exemple ?

chrisbk> Petit exemple

Très simple me direz-vous ?
Mais non ! Car la ligne $loop est trop loin du jnz (qui ne peut se déplacer que de +127 et -128 octets !)
Donc le compilateur se charge lui-même de faire une modification (et sans notre accord):

Oui ça marche, mais c'est plus long en consommation de cycles.

 
non y'a des deplacement relatifs codé sur 4 octets

extrait :

 
 
et donc :
 

 
bref y doit etre un brin vieux et poussiereux le compilo qui sort un truc pareil (ou etre dans un mode de compatibilité pour un vieux cpu)

Exact, et c'est bien vrai !
Merci les gars, je n'avais plus revu le codage de jxx depuis que j'ai débuté l'asm sur mon feu 8086.
Et le déplacement peut donc être sur 8bits en mode relatif ou 32 en mode direct.

chris_d13 > mis a part cette petite erreur tu m'as l'air bien callé en asm. Tu sais si il y a moyen d'effectuer un branchement sur une comparaison effectué par la FPU sans passer par le FNSTSW ax / test ax, truc des familles?

 
non, lis bien, 16/32 en relatif aussi (REL 16/32)

En fait j'avais tellement programmé sur 8086, 8088 et surtout 286... J'avais même remplacé un 386 par un 286 car ce dernier pouvait tourner plus vite. Donc les saut jxx était toujours en mode relatif 8bits.

chisbk> Je viens de revoir mes docs (intel, amd et cyrix) aux pages jcc :
Le déplacement est soit relatif 8bits uniquement,
Soit relatif : 16 bits en mode Réel et V86 ou 32 bits en mode Protégé.

 
je proteste violemment, ma page pour les opcodes (j'ai que la version sur mon DD, je te recherches l'adresse) m'indique bien un deplacement relatif de 32bits, et la pratique aussi (mon compilo emet des jcc avec deplacement relatif de 32bits (et aucun de 8 bits parce que je suis une niasse))

Vla : http://www7.informatik.uni-erlange [...] ml/Jcc.htm
 
edit : ah ben tiens j'avais jamais lu la suite :
 
If the given condition is true, a jump is made to the location provided as the operand. Instruction coding is most efficient when the target for the conditional jump is in the current code segment and within -128 to +127 bytes of the next instruction's first byte. The jump can also target -32768 thru +32767 (segment size attribute 16) or -2^(31) thru +2^(31) -1 (segment size attribute 32) relative to the next instruction's first byte. When the target for the conditional jump is in a different segment, use the opposite case of the jump instruction (i.e., JE and JNE), and then access the target with an unconditional far jump to the other segment. For example, you cannot code--
 
JZ FARLABEL;
 
You must instead code--
 
   JNZ BEYOND;
   JMP FARLABEL;
BEYOND:
 
ptet ca ton histoire ?

Tu as tout compris. D'après mes docs, ce genre de problème ne se posait donc que pour les cpu ne pouvant lire les jcc avec saut relatif supérieur à 8 bits.
PS: J'ai fait une erreur également, les saut en 16 ou 32 bits sont également en relatif mais en mode natif 16bits ou 32bits suivant le mode du processeur.
Up> Je corrige mes posts.

 
jme reponds tout seul : FCOMI (depuis le P6)
par contre ca pue fo que les deux operandes soient sur la stack

exact, je l'avais même oublié.

chrisbk> Et oui la fpu, avec sa super-pile que peux de programmeurs savent réellement exploiter.
Personnellement, je me régale à travailler avec la FPU. C'est un pur bonheur pour l'optimisation !
Les SIMD à côté, c'est trop simple. Et puis je développe (au boulot) des appli pour les écoles, et tous n'ont pas forcément des machines avec SSE, 3DNow ou même MMX...

 
tu veux que jte dise ce que j'en pense de cette $ù^$^é de pile ?
 
 

 
Stun ot probleme ca. Moi vu que je dev pour ma tronche, c'est MMX/3dnow (un jour j'upgraderais mon cpu, un jour...)
 

chrisbk> Et oui, on se demande toujours pourquoi et comment intel a réussi à avoir une idée aussi stupide ce jour là...
S'il n'y avait que ça...
 
A mon goût, le pire fut l'adresse 20bits sous forme de segment : offset.
Pour le MMX, c'est pas bcp mieux (même si c'est pratique)... Le 3DNow! à vraiment apporté qq chose ! Comme le SSE d'ailleurs.

oué j'aimerais comprendre pkoi ils ont choisi une pile alors que le reste c'est du reg stdart
(c'est quand meme la bonne misere les cpu intels)
(et encore, je me plains, je suis arrivé au pentium, directement en mode protegé)

bah les 80x86, mais l'itanium est assez sympa.

sais pas, pas regardé, et vu que j'en verrais ptet jamais un en vrai, ben vala quoi

T'as bien de la chance, sur 286, fallait se taper la routine pour faire un retour au mode réel sachant que intel avait soit-disant oublier de cabler l'instuction. Mon oeuil ! La fonction était buggée.
Pour ma part, j'ai vraiment apprécier l'optimisation lors du passage 486=>Pentium.
 
Pour les pseudo-registres de la FPU, il a eu des tas de rumeurs...
Mais la version officielle semble la plus crédible (pour moi) : économie !
En effet, faire une multiplication ou un sinus demandait au 8087 énormément de temps ! Alors bidouiller les registres ne posait pas trop de problème de ralentissement. Juste des problème de développement. Mais la FPU était un tel gain !
Je me rappelle même de cyrix qui faisait des FPU équivalente 4 ou 10 fois plus rapide que celle d'intel (eh oui!) alors qu'avec le 6x86, c'était une vraie daube.

très franchement: regarde.
c'est très très très interressant. c'est le contre-pied de l'archi 80x86.
 
c'est démoralisant de voir Intel pousser le réformé P4, et de laisser crever l'Itanium (dont une certaine forme d'échec est probable si il n'est pas introduit sur le marché grand public).

J'ai développé sur des plusieurs CPU et DSP et franchement le pire, c'est bien l'archi x86.

 
et on va encore se la trimballer encore pendant des millénaires cette archi de merde, cf les nouveaux athlon 64...
 

et oui  

De toute façon les cpu seront tellement puissant que plus personne (sauf l'élite) ne programmera en ASM.
Et puis les prochains CPU ne se programmerons plus en ASM mais dans des langages de plus haut niveau. On parle déjà de CPU java.
Il existe également les composants reprogrammables permettant de créer des CPU de toute pièce ! Les CPU reprogrammable, c'est l'avenir ! C'est pas demain, c'est aujourd'hui !
OpenHardware Power !

(cpu java ca fait des lustres que j'en entends parler quand meme)

Il y avait eu un article sur présence-pc...
http://www.presence-pc.com/article-112-1.html

c'est vrai mais le rapport performances/prix risque d'être toujours avantageux vers des CPU à jeu d'instruction plustôt fixe.

ce n'est pas tout à fait juste.
L'histoire nous a montré que l'on préfère un élément souple à un fixe : Le calculateur contre le processeur.
Le premier ne pouvait éffectuer que des tâches fixes.

pour le fpu (gestion par pile), deja l'une des raisons, ca doit peut-etre du au fait qu'au debut le coproc etait separé (8087), d'ailleurs les proc arithmetiques marchaient tous comme ca, avec des piles, meme le petit 74181
et pi je pense que surtout quand on regarde une operation arithmetique avec des parentheses partout, les piles c'est super pratique

prorel> tu la programmes souvent la FPU ?

D'où l'instruction wait.

vi vi, bien sur ! amuse toi à réaliser une itération de Mandelbrot avec la FPU du premier coup, sans te chier dessus avec les différents empilements

 
non c'est de la merdasse
je le crierais sous tous les toits jusqu'a ma mort

 
ché pas ceci dit, un CPU hautement programmable peut être une passerelle pour sortir du jeu d'instruction du 80x86.

bjone> Non pas programmable, mais plutôt re-programmable

yep (mais j'ai précisé hautement)