@tf1Groupie :

salut tf,

bah l’onformatique au lycée ca doit etre sommaire qd meme, je peut te reprendre sur un truc (t’y voit pas d’inconvénients)

en fait c’est pire que ca (enfin pour moi) si je reprends ta phrase :

« Il y aussi d’autres bêtises dans votre article notamment quand vous essayez de réduire l’informatique à 10 instructions comme réduire les mathématiques à 10 chiffres et 4 opérations ou bien le langage à 26 lettres. »

non la le langage c’est pire il te le reduit à 5 ou 6 lettres, c’est la ou je ne suis pas d’accord avec lui.

De plus aussi la partie ou il traite le temps d’exec d’un microcode (nbre de cycles), c’est vrai que c’est important, mais pas que (certains vonts comprendre ce que je vais expliquer)

On prends certaines instructions qui bouffent bcp de code genre mul et div , et apres soit on ré-ecrit la fonction en entier en code archi optimisé (et la c’est déja pas gagné), bon ca va rajouter du code exec (du binaire), ou pire on se cree à la patos une « macro » en asm qui va regénerer l’ensemble du code (en ligne) à chaque fois que derrier le mot macro (nommeé div_ x,y) par ex, le compilo va regénerer l’ensemble du code avec les vars x,y de la fonction macro optimisée précédement codée.

Ce qui va se passer dans le proc, c’est vrai que lorsqu’il ne sera pas « en pleine charge » dans son cache L1 (8k), ben ca va dépoter plus, sauf que des que le segment du code va un peu s’etaler (un « call » par exemple qui reprends un autre segment plus bas ou plus haut), ben la paf !

tu sort de la memoire L1 (donc du gestionnaire de cache L1du proc qui devra la placer au mieux dans L2 (le second niveau) et la bilan de l’histoire, tu te retrouve avec une ramure vu que le proco passera son temps a basculer les segments L1 L2 (et pire la ram ensuite si ca tient plus dans L2) donc les perfs... badabom tsoin tsoin

En plus à vouloir économiser (éviter) les opcodes lents, tu tombes sur un 2eme problème, ben wouii, il te faut des registres dispos (pour ta fonction de division optimisée) ca veut dire que d’abord tu devra backuper tes registres qui seronts utilisées par ta fonction optimisée (soit sur la pile, donc par projection sur L1 ou ca sera empilé vu que sp n’est que le descripteur (le pointeur en c pour illuster) sur la zone mémoire a atteindre), soit sur de la variabe fixe que tu aura défini par un segment mémoire (donc toujours au mieux qui sera projeté dans L1, et en esperant qu’elle y soit (meme bloc que le segment db xxxx(adresse mémoire spécifiée avant) qui s’y réfères ).

Bref à vouloir chipoter on gagne pas toujours au bout

Apres dans le chipotage on peut aller meme dans le code automodifiable (c’est terrible en efficacité pour des blocs en copie rapide sur le 68000 sur de la boucle) sauf que (et le hic est la, c’est que lorsque tu passe apres en mode « trace » sur le proc (le mode debug des outils) ben le proc il comprends plus rien, il ne peut plus débugguer le code automodifiable vu que le cache interne du proco n’est plus dans un mode de « préfetch » normal (essaye un jour si tu ne l’a pas fait tu comprendra), j’ai pris le 68xxx mais la punition est la meme sur les autres procs.

Ca sert a quoi (ce genre de code) bah par exemple lorsque qd tu by-pass l’os dans la zone mémoire écran et te faire un CLS ultra rapide (lorsque tu basules en mode page écran de reconstruction de l’un par rapport à l’affiché pour éviter le « clipping » et recontruire au plus vite l’image, vu que le chiffre du nombre d’octets de la couverture écran (x,y) ne correspondra jamais aux nombres de mov D0, (a0)+, D1((A1)+, (etc jusqu’a 6, donc les 7 registres, parce qu’il faut garder au moins un Dx pour gerer la boucle), et avant bien sur tu aura placé d0 a d6 avec la valeur 0 (ou la serie d’opcode avec leurs valeurs dans la zone ou juste apres tu lance (enfin décales) PC (program conter) en relatif bien sur, c’est de la grosse bidouille de barbabare, mais j’ai pas trouvé d’exemple plus simple pour mieux expliquer (désolé) les optimisation et ce que ca peut entrainer comme dérives parfois.

ca sert aussi pour eviter te te faire tracer ton programme dans un systeme anti debugguer, ou d’autres trucs  (rhahemm...) 

Non ne pense pas le faire en deroutant la pile en sequence copie du contenu (vide) vs l’adresse écran, parce que simplement le temps d’exec (nb cycle r/w memoire) est dans ce cas plus lent (moins rentable en termes de mov de blocs de memoire vs vitesse vu que ca ne passe plus d’un registre de données, mais d’une adresse mémoire (enfin de son contenu) à travers L1 (au mieux)), enfin ca c’est au coup par coup, faut regarder tous les opcode et le nombre de clk / opcodes pour choisir la meilleure solution sur le proco donné (ou le chipset programmable), ici l’exemple est pris pour du 68000.

Pt1 va expliquer rien que ca (qui est bon assez simple) à un etudiant d’un lycée en france

je ne parles pas de paris 6 ou l’annexe 1 de Balard (si elle existe toujours), j’espere qu’ils ont un peu modernisé le matos pour l’assembleur ^^