273Fermer275
Kevin KoflerLe 22/04/2009 à 10:12
Folco (./268) :
J'ai des relogements quand je fais ça :
	if (TmpY0 > DrawingData.Curs.y1)
	{
		DrawingData.Curs.y0 = DrawingData.Curs.y1;
		DrawingData.Curs.y1 = TmpY0;
	}

J'essaye donc ce genre de ruse éléphantesque :
	short* TmpPtr;
	if (TmpX0 > DrawingData.Curs.x1)
	{
		TmpPtr = &(DrawingData.Curs.x0);
		*TmpPtr = DrawingData.Curs.x1;
		DrawingData.Curs.x1 = TmpX0;
	}

Malheureusement, j'arrive pas à berner le compilateur, j'imagine qu'il sucre tout simplement le pointeur TmpPtr. grin

J'ai essayé d'autres trucs, d'une finesse tout aussi étonnante :
	if (TmpY0 > DrawingData.Curs.y1)
	{
		*&(DrawingData.Curs.y0) = DrawingData.Curs.y1;
		*&(DrawingData.Curs.y1) = TmpY0;
	}

Pareil, il veut pas marcher le bougre. grin

Bah oui, le compilateur optimise ton code redondant. smile Donc les passes d'optimisation transforment les 2 derniers exemples en le premier.
Folco (./271) :
Bon, j'avais oublié le coup du -mpcrel, là ça marche, pas de relogement. Etrangement, je passe de 106 octets économisés par le range-cutting à 12 confus Pour une taille de programme de 30 octets inférieure. Une explication pour les sauts qui s'envolent ? Le fait qu'il puisse coder des distances de saut en dur du fait qu'il n'y ait pas de relogement, et donc de taille de code non connue à l'assemblage peut-être ?

Sans -mpcrel, le compilateur crée un relogement pour toute référence à ta variable globale, et c'est le linker qui optimise les lectures en des accès PC-relatifs. Avec -mpcrel, tout est déjà PC-relatif, il ne reste plus que l'optimisation branchements longs (.w) -> branchements courts (.s) pour le linker. Donc forcément l'optimisation linker travaille moins.