|
[Commentaire n°1] | ||
| Posté par sasume le 02/04/2005 Pour le 3, si il est important que les 32 bits du registre soient affectés, plutôt que de garder le move.l #255,dn, on peut faire : moveq.l #0,dn ; st.b dn [10 : 4] (on gagne 2 cycles et 2 octets)  Pour le 16, il est possible d'écrire directement movea.l #WWXXYYZZ,(an) [20:6] (et le code que tu as écrit toi est incorrect d'ailleurs) Pour le 17, ma table de cycle me dit que c'est 6, pas 8. Mais j'avoue que ça me paraît bizarre. Pour le 20, on peut même, si le contexte l'autorise, remplacer le lea.l Adresse,an par un lea.l Adresse(pc),an, qui sauve 2 octets et 4 cycles ! Pour le 22, il faut rectifier, cela n'est possible que si DATA est compris dans l'intervalle [-127;128], et puis ça bouffe un registre supplémentaire. Pour le 23, c'est btst.l #k,dn ; pas k-1 Je me suis arrêté là, je n'ai pas le temps de lire la suite. Je le ferai plus tard. Ce tuto est une bonne idée, j'ai appris des petites astuces dedans Par contre, il y a quelques erreurs ou imprécisions, c'est dommage.
|
|
Commentaires :: [Commentaire n°2] | ||
| Posté par Kevin Kofler le 03/04/2005 Pour le 2, GCC utilise neg.b ou not.b plutôt que tas.b et ça marche aussi, en la même taille et vitesse. Le 16 est incorrect, je pense que ça décrivait movep, pas movea, et ça ne marche pas exactement comme ça. Le code tel qu'il est est faux, movea ne marche qu'avec un registre d'adresses en destination. Et les dernières (à partir du 26) sont nulles, ce sont des optimisations vitesse qui pessimisent la taille.
|
|
[Commentaire n°3] | ||
| Posté par sasume le 03/04/2005 Pour le 31, je me demande si on ne peut pas améliorer encore avec l'instruction DBcc... Je vais réfléchir à ça
|
|
[Commentaire n°4] | ||
| Posté par sasume le 03/04/2005 Après relecture, il y a une petite erreur sur le 31, au niveau de l'instruction bpl. Voici ce que devrait être la ligne : bpl.s DIVISE_1 ; [10:2] ou [8 :2] Et voici ma version au fait. Peut-être encore optimisable : moveq.l #-1,dr ; [4:2] DIVISE_1: sub.w dn,dm ; [4:2] dbpl dr,DIVISE_1 ; [10:4] ou [12:4] addq.w #1,dr ; [4:2] not.w dr ; [4:2] add.w dn,dm ; [4:2] Soit un total de [16+(quotient+1)*14+2:14] Ce qui donne un gain pour les quotients inférieurs à 7. Mais ma solution prend plus de place que celle proposée, pour pas grand chose de mieux. Mais je pense qu'il doit être possible de simplifier les traitements autour de la boucle...
|
|
[Commentaire n°5] | ||
| Posté par sasume le 03/04/2005 Nouvelle version : moveq.l #-1,dr ; [4:2] sub.w dn,dm ; [4:2] DIVISE_1: sub.w dn,dm ; [4:2] dbpl dr,DIVISE_1 ; [10:4] ou [12:4] not.w dr ; [4:2] add.w dn,dm ; [4:2] Cette solution prend 14 octets, et offre un gain si le quotient est inférieur à 8. edit:correction de balise
|
|
[Commentaire n°6] | ||
| Posté par geogeo le 03/04/2005 Pour le 17, ma table de cycle me dit que c'est 6, pas 8. Mais j'avoue que ça me paraît bizarre. C'est bien 8 et non 6. Pour le 20, on peut même, si le contexte l'autorise, remplacer le lea.l Adresse,an par un lea.l Adresse(pc),an, qui sauve 2 octets et 4 cycles ! Mon exemple est un cas général, bien entendu qu'on peut ajouter (PC) mais sous certaines conditions. Pour le 2, GCC utilise neg.b ou not.b plutôt que tas.b et ça marche aussi, en la même taille et vitesse. Le 16 est incorrect, je pense que ça décrivait movep, pas movea, et ça ne marche pas exactement comme ça. Le code tel qu'il est est faux, movea ne marche qu'avec un registre d'adresses en destination. Et les dernières (à partir du 26) sont nulles, ce sont des optimisations vitesse qui pessimisent la taille. Corrigé, en effet s'était movep et non movea se qui était logique mais movep n'est pas fait pour les TI68K. Ensuite t'es jamais content, y a tout d'afficher, nombre de cycles et taille du code, au programmeur de choisir, mais perso si j'économise 48 cycles et que je perd 4 octets je prend tout de suite cette optimisation.
|
|
[Commentaire n°7] | ||
| Posté par sasume le 03/04/2005 C'est bien 8 et non 6. Quelle est ta source ?Mon exemple est un cas général, bien entendu qu'on peut ajouter (PC) mais sous certaines conditions. Oui, mais précise le tout de même parce que c'est très souvent le cas.
|
|
[Commentaire n°8] | ||
| Posté par sasume le 03/04/2005 Euh, pour le 31, tu as mis n'importe quoi  Voilà le code exact : [31] moveq.l #-1,Dr [4:2] sub.w Dn,Dm [4:2] DIVISE_1 : sub.w Dn,Dm [4:2] dbpl.w Dr,DIVISE_1 [10:4] ou [12:4] not.w Dr [4:2] add.w Dn,Dm [4:2] Total [16+(14*quotient)+2 :14) L'exécution de ce code varie entre 18 cycles (quotient = 0) et 130 cycles (quotient = 8), tandis que le temps d'exécution d'un divu se situe entre 126 et 140 cycles. Cet algorithme divise les 16 bits de poids faible de Dm par les 16 bits de poids faible de Dn. Pour réaliser une division sur 32 bits, il faut modifier les opérations portant sur Dn et Dm pour les faire porter sur des longword, et dans ce cas, le temps d'exécution est de 24+18*quotient+2, donc il ne devient intéressant que pour des quotients <= 5. Si le reste de la division n'est pas utilisé, la dernière ligne du code peut être omise.
|
|
[Commentaire n°9] | ||
| Posté par geogeo le 06/04/2005 http://www.grid.unina.it/Didattica/CE/CEI/INFORMATICA/68k/68000um.pdf Rapport avec suba An,An. Je vais ajouter ta précision sur PC mais (PC) n'est plus valide quand le programme dépasse 24 Ko? Encore merci pour ton aide, je vais essayer quand j'aurai du temps de faire la partie "optimisations des structures (sauts...)".
|
|
[Commentaire n°10] | ||
| Posté par sasume le 07/04/2005 Pour le suba, effectivement, j'utilise la même doc que toi et je l'avais mal lue Pour l'adressage en pc-relatif, ça peut être inutilisable si le prog dépasse 32ko, mais ce ne sera pas forcément le cas.
|
|
[Commentaire n°11] | ||
| Posté par sasume le 07/04/2005 Au fait, tu t'es encore trompé pour le 31, le calcul du temps d'exécution est 16+14*quotient+2, pas 16+14*(quotient+2)
|
|
[Commentaire n°12] | ||
| Posté par sasume le 07/04/2005 Et en fait, mon code est complètement faux  Il faut mettre un dbmi à la place du dbpl et remplacer le not par un neg.
|
|
[Commentaire n°13] | ||
| Posté par geogeo le 07/04/2005 Corrigé et ajout aussi d'une bref explication de PC. Merci
|
|
[Commentaire n°14] | ||
| Posté par sasume le 08/04/2005 Il reste encore une faute dans l'expression du calcul du temps d'exécution ! Et puis ton explication sur l'adressage PC-relatif n'est pas placée au bon endroit, et est de toute façon complètement fausse. L'adressage #DATA(pc) ne veut strictement rien dire... Et c'est faux que ça ne marche que pour les prog < 32ko. Des problèmes peuvent survenir dans le cas de programmes de plus de 32ko, mais c'est assez rare, et en général on peut très bien les éviter. Franchement je n'en reviens pas que tu fasses autant de fautes geogeo, on dirait que tu n'as jamais codé en ASM !
|
|
[Commentaire n°15] | ||
| Posté par geogeo le 08/04/2005 Il reste encore une faute dans l'expression du calcul du temps d'exécution ! Corrigé! Et puis ton explication sur l'adressage PC-relatif n'est pas placée au bon endroit, et est de toute façon complètement fausse. L'adressage #DATA(pc) ne veut strictement rien dire... Viré et j'avoue que j'ai fait n'importe quoi là, surtout avec un PC après un #DATA  Viré j'ajouterai ça plus tard!Et c'est faux que ça ne marche que pour les prog < 32ko. Des problèmes peuvent survenir dans le cas de programmes de plus de 32ko, mais c'est assez rare, et en général on peut très bien les éviter. Je ne connais pas en détail tout ça donc oui j'ai fait une erreur et je l'admet! Franchement je n'en reviens pas que tu fasses autant de fautes geogeo, on dirait que tu n'as jamais codé en ASM ! J'avoue, je prend ta remarque mais je te laisse deviner combien de temps il faut pour faire un tel article aussi nase qui ne sera lu que par 4 personnes. Alors j'estime que mes erreurs sont minimes vu l'article. Surtout que cet article se base aussi sur le travail de Daniel Fournier dont tu as critiqué certaines parties (et c'était des bonnes critiques!). Mais bon soit je ne fais pas d'article et on ne pourra plus me faire des remarques genre je sais pas coder soit j'en fait et je m'en prend plein la gueule. Je vise la dernière solution. 
|
|
(PC) :: [Commentaire n°16] | ||
| Posté par Kevin Kofler le 09/04/2005 Ne codez pas (PC) en dur dans vos programmes, laissez le linker décider si c'est possible ou non! (Et il réordonnera même les sections pour que ce soit possible au maximum d'endroits.)
|
|
[Commentaire n°17] | ||
| Posté par geogeo le 09/04/2005 Bof j'viens de tester et TIGCC n'optimise pas au maximum. Dans quel cas un problème peut arriver quand on utilise (PC)? La variable se trouve 32 Ko plus loin que la valeur actuelle du PC???
|
|
[Commentaire n°18] | ||
| Posté par sasume le 10/04/2005 Kevin> ld-tigcc ne permet pas de produire des fichiers utilisables sur Atari ST.
|
|
Réponses :: [Commentaire n°19] | ||
| Posté par Kevin Kofler le 10/04/2005 Bof j'viens de tester et TIGCC n'optimise pas au maximum. C'est-à-dire? Exemples? Compiles-tu bien avec les optimisations du linker activées (--optimize-code --cut-ranges si tu compiles en ligne de commande, et aussi --reorder-sections, éventuellement)? Et es-tu sûr que l'adressage en (PC) soit permis en cet endroit? (PC) n'est permis que pour les opérandes source, pas pour les opérandes de destination. Dans quel cas un problème peut arriver quand on utilise (PC)? La variable se trouve 32 Ko plus loin que la valeur actuelle du PC??? Oui. Kevin> ld-tigcc ne permet pas de produire des fichiers utilisables sur Atari ST. Oui, mais là, on parle de TIs. L'article d'origine aurait pu en parler, en effet. Et sinon, ld-tigcc est un logiciel libre, rien ne t'empêche de coder un export Atari ST. On a déjà comme exports possibles: exécutable AMS (_nostub ou kernel), DLL _nostub, fichier de données externe, Fargo, Flash OS (TIB), infos de débogage (COFF avec stabs ou DWARF 2). Donc notre linker est flexible sur ce point.
|
|
[Commentaire n°20] | ||
| Posté par geogeo le 10/04/2005 C'est-à-dire? Exemples? Compiles-tu bien avec les optimisations du linker activées (--optimize-code --cut-ranges si tu compiles en ligne de commande, et aussi --reorder-sections, éventuellement)? Et es-tu sûr que l'adressage en (PC) soit permis en cet endroit? (PC) n'est permis que pour les opérandes source, pas pour les opérandes de destination. Oui toutes les options sont activées sauf --reorder-sections car je fias une initialisation de variables au début de mon programme. Et enfin je n'utilise que (PC) pour les opérandes sources.
|
|
Poster un commentaire |