Stratégie registeresque et autres habitudes - Page 3

(en C on gagne énormément avec freg-relative-an (et en assembleur y'a sûrement moyen de gagner en utilisant une stratégie équivalente ))

C'est quoi ce switch Ximoon ?

Et ça ne marche pas dans tous les cas (callbacks, handlers d'interruptions, ...), c'est pour ça qu'il y a l'avertissement "it is not fully supported" et que c'est désactivé par défaut.

... mais on peut faire marcher -freg-relative-an en rajoutant quelques lignes de code simple
D'une façon générale, si on choisit bien ce qu'on met dans les registres, les variables globales (dont fait partie -freg-relative-an) dans les registres sont très efficaces. Entre bien d'autres exemples, Greg Dietsche et Samuel Stearley en ont introduit avec bonheur (baisse de la taille, augmentation de la vitesse) dans ttunpack (du moins, la version rapide).

Je suis assez d'accord avec ./4: GCC fait du code suboptimal, en particulier sur la target m68k qui nous intéresse. Ce n'est pas facile d'écrire un bon compilo, et je ne sais pas faire, mais GCC n'est pas très bon, même si TIGCC est meilleur que GCC mainline.
Par exemple, dans un projet que j'avais fait pour le Magistère en L3 (dans un labo), dont les sources (LGPL + permission de redistribution en forme binaire non modifiée) sont accessibles à http://opensvn.csie.org/LGC , les nombreux "register ENTRY * const outentry asm("%a2")" de trunk/lgclib_ti68k.c sur les fonctions qui s'appellent les unes les autres sont une tentative infructueuse (et concertée avec Kevin et PpHd, qui n'ont rien trouvé non plus) de forcer GCC à laisser ce p*** de pointeur là où il est sans en faire une sauvegarde sur la pile, le copier dans un autre registre, mettre autre chose à la place, et finalement restaurer le registre (!).

Au fait, il y a une beta dispo pour le fameux programme que tu fais en ce moment ? Je suis curieux et j'aimerais bien voir ce que donne ton gestionnaire de clavier !

Je veux bien le binaire Je sais pas si j'ai ce qu'il faut pour compiler/assembler. Les seul trucs que j'ai sur mon ordi c'est TIGCC et GTC.

J'ai une 92+. Ca ne tourne pas dessus ?
Je ferai sur TIEmu alors

Martial Demolins (./48) :

Pollux (./45) :
le must en vitesse étant de passer l'adresse de retour dans un registre d'adresse et pas sur la pile

Mais non voyons, j'ai mieux : move.l (%sp)+,%pc

intuitivement, je dirais que non, vu ça fait un accès mémoire

Thibaut -> si je me souviens bien, en ARM7, c'est comme ça qu'on fait un RTS

OK Ca me paraît à moitié crade mais bon, ça marche

Martial : Je vais essayer ça Tu sais où tu veux arriver à terme ?

quand tu dépiles quoi ?
j'ai peut être mal lu, mais ce que j'ai compris c'est qq chose du style

_main:
  lea suiteDuCode(pc),ax
  bra.s func
suiteDuCode:
  rts



func:
  ;du code
  bra.s ax ; retourne au code appelant

du coup, tu n'as pas d'accès mémoire (après si tu as besoin de tous les registres, c'est sur qu'il faudra bien les sauvegarder à un moment ou à un autre)

edit : qq détails dans le code

Intéressant et bien vu

Mais bon, on gagne quoi ? 4 cycles ? C'est négligeable devant le nombre de cycles que prend une fonction (disons 80 cycles minimum : appel, retour, sauvegarde et restauration des registres, création du frame, et code de la fonction lui-même). On gagne moins de 5% de temps d'exécution (et beaucoup moins pour les fonctions de taille un peu plus classique, du genre 5-10 lignes de C).

Si t'as une fonction qui fait moins de 80 cycles c'est autant faire une macro je trouve

pour le gain de *seulement* quatre cycles : pour ma fonction, c'est loin d'être négligeable (bon, y'a moyen de faire la même chose en zéro cycle, certes)

Thibaut (./79) :
Intéressant et bien vu

Mais bon, on gagne quoi ? 4 cycles ? C'est négligeable devant le nombre de cycles que prend une fonction (disons 80 cycles minimum : appel, retour, sauvegarde et restauration des registres, création du frame, et code de la fonction lui-même). On gagne moins de 5% de temps d'exécution (et beaucoup moins pour les fonctions de taille un peu plus classique, du genre 5-10 lignes de C).

Si t'as une fonction qui fait moins de 80 cycles c'est autant faire une macro je trouve

On gagne 8 cycles, c'est pas beaucoup mais c'est mieux que rien : dans les cas où la fonction est rapide à exécuter mais prend quand même trop de place pour pouvoir en faire une macro, ça peut servir

(plus précisément, si la fonction prend plus de 18 octets alors l'appel via lea+jmp n'est pas dans l'enveloppe convexe de l'appel via jsr et de l'appel inliné, donc ça peut réellement être une optimisation utile même si elle ne va pas faire gagner 80% en vitesse ^^)

((bon mais là je me fais un peu l'avocat du diable, c'est très très anecdotique et on s'en passe très bien [mieux vaut commencer par appliquer les optimisations qui peuvent faire gagner 80% en vitesse ], je dis juste que c'est possible ))

Le deuxième paragraphe en langage humain, ça donne quoi ?

Pen^2 (./78) :
bra.s ax ; retourne au code appelant

Ça n'existe pas, ce truc. C'est jmp (%an) qu'il faut mettre.

Martial Demolins (./84) :

Pen^2 (./78) :
lea suiteDuCode(pc),ax

Flemme de vérifier, mais ça doit être encore plus rapide d'avoir un relogement que de faire du pc-relatif

Non, le PC-relatif est plus rapide (parce que ça doit lire seulement 2 octets dans la mémoire et pas 4, je suppose).

./86 est exact

J'ai essayé ton programme Martial Pas mal ! ça change du curseur habituel !

Je trouve que ça aurait été beaucoup plus simple en C En une après midi, le codage aurait été bouclé

(dsl pour les erreurs, j'ai pas fait du 68k depuis des lustres )