optimisation de boucle - Page 2

-

tu peux faire subq #5/bcc plutôt que subq #4/dbf (-2 octets à chaque fois)

oui mais j'ai des parties en C que je n'arrive pas a ecrire en asm et qui sont vraiment largement optimisable quand on regarde le -S

Certainement, d'où l'intérêt du asm qui permet de pallier à des déficiences du compilo. Le problème, c'est que qd le compilo s'améliore, le code du compilo peut devenir meilleur que celui du programmeur

déja fait

Ah oui j'avais déjà oublié ce topic OK

Pollux :
Non, comme je l'ai dit la version actuelle de GTC génère du code moins bon que ton asm de départ. Je parlais de versions futures

Mais je ne comprends pas pourquoi tu me parles de GTC
Tu n'as pas d'idée pour optimiser le code d'Orion ?

-

Optimisé v1 (j'ai une autre méthode, faut voir laquelle est la mieux) :

	movea.l	objdata1(pc),a4	; (pas de lea, objdata1 contient un pointeur)
	moveq	#-14,d3
	moveq	#15,d5		; k
Next1k:
	moveq	#15,d6		; j
Next1j:
	moveq	#15,d7		; i
Next1i:
	movem.w	d5-d7,(a4)+
	bsr	checkloadbar
	subq.w	#5,d7
	cmp.w d3,d7
	bcc	Next1i
	subq.w	#5,d6
	cmp.w d3,d6
	bcc	Next1j
	subq.w	#5,d5
	cmp.w d3,d5
	bcc	Next1k

Euh sinon je me permets d'émettre de gros doutes sur l'optimisation de ce truc, mais bon

le pire c quand je reprend un code genere par TIGCC en -S
que je copie colle dans un .asm avec la syntaxe traduite pour a68k que je compile et que sa ne donne absolument pas le même resultat

tu veux dire au niveau de la syntaxe?

-

Bah tu dois faire une erreur dans la traduction de syntaxe GNU ASM -> A68k à mon avis...

-

J'imagine A moins que GCC génère sciemment des "bra" tout court, parce que AS ne va pas les optimiser en bra.s alors que A68k oui, mais ce n'est pas le cas et je vois difficilement une autre incompatibilité qui pourrait ne pas donner d'erreur

non j'ai juste remplacer les 0x par $ et les % par rien

Peut-être que dans un autre fichier tu as une fonction qui s'appelle Parse0xNumber et une autre qui s'appelle ParseNumber, que tu appelles Parse0xNumber à partir du fichier converti en A68k et que donc l'appel est converti en ParseNumber
Bon c'est tordu mais je vois pas ce qui pourrait foirer. Et j'imagine que tu fais d'autres conversions, style jbra->bra.

-

Ha merde Bon ben t'as qu'à stocker à l'envers si checkloadbar ne dépend pas de l'ordre d'appel Sinon c pas grave, tu perds que 2 octets.

Et sinon pour tes pbs de conversion, si tu pouvais poster ce qui foire... Soit c'est un bug d'a68k ou gcc (peu probable, mais si c le cas il faut le corriger), soit c'est une erreur de ta part

-

-

Si t'utilises pas les conventions d'appel standard

Et comment checkloadbar était censé connaître nvertex? Il est dans d4?

-

Pkoi tu gardes nvertex alors?

Et non, d3 n'est pas détruit par une fonction C (d0-d2/a0-a1)

-

Voilà, mais c **3, pas *3 (à moins que j'ai vraiment rien compris au truc )

-

Non, pas en C. (C'est du C++.)

heu vous lisez jamais mes msg apparemment..
ca fait un baille que je vous dit que subi dbf c'est de la daube (tout comme le -15 en C) et seul pollux a reagit..

Oui, mais ça va plus vite que d'écrire "puissance". Et de toutes façons c'est pour a68k, donc << il ne connaît pas non plus

-

heu le but de ce topic c'est de te donner des idées d'optimisations ou de te donner un code source tout fait..
je suis contre la deuxieme idée...

-