Mon second programme en C - Page 10

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 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 ?

cross -> Ximoon

Sally > sauf s'il n'utilisait pas cette variable en dehors de la fonction où elle était déclarée

Sally (./270) :
Par contre si tu n'avais aucune déclaration globale non-extern de ta variable tu aurais dû avoir une erreur au linking, c'est ça que je ne comprends pas.

Oh t'inquiète pas, il y en avait 32

Ximoon -> ch'ui un noob, mais ptêt pas à ce point

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.

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.

Bah oui, le compilateur optimise ton code redondant. 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 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.

Ok ok

Mort de rire les constructions qu'on peut faire !
C'est valide ça ?

	ScrRectFill(&(SCR_RECT){{(char)(LCD_WIDTH-MenuWidth)/2,(char)(LCD_HEIGHT-MenuHeight)/2,(char)(LCD_WIDTH+MenuWidth)/2,(char)(LCD_HEIGHT+MenuHeight)/2}},
	&(SCR_RECT){{0,0,239,127}},A_REVERSE);

Le tout en une ligne, il en faudrait bien 50 en assembleur ^^ Ca va devenir rapide de faire quelques graphismes

d'un autre côté, question maintenabilité

Ben je vais pas passer par la construction d'une variable (SCR_RECT) pour le plaisir quand même, si ?

Au fait, si en 10 instructions, j'utilise 5 fois LCD_WIDTH/2, le compilateur sait optimiser le calcul (une seule fois), ou alors va-t-il recalculer tout à chaque occurence du calcul demandé ?

Folco (./279) :
Ben je vais pas passer par la construction d'une variable (SCR_RECT) pour le plaisir quand même, si ?

ce serait un peu plus lisible quand même:

SCR_RECT a= &(SCR_RECT){{
(char)(LCD_WIDTH-MenuWidth)/2,
(char)(LCD_HEIGHT-MenuHeight)/2,
(char)(LCD_WIDTH+MenuWidth)/2,
(char)(LCD_HEIGHT+MenuHeight)/2
}};
SCR_RECT b= &(SCR_RECT){{0,0,239,127}};

ScrRectFill(a,b,A_REVERSE);

Folco (./278) :
Au fait, si en 10 instructions, j'utilise 5 fois LCD_WIDTH/2, le compilateur sait optimiser le calcul (une seule fois), ou alors va-t-il recalculer tout à chaque occurence du calcul demandé ?

perso j'attendrais qu'il le fasse, je pense que c'est le cas, mais je sais pas quelle option garantit que c'est bon (Os? O3? -fmachin?)

&b, A_REVERSE);

non... plutôt :static SCR_RECT a = {{ 
  (char)(LCD_WIDTH-MenuWidth)/2, 
  (char)(LCD_HEIGHT-MenuHeight)/2, 
  (char)(LCD_WIDTH+MenuWidth)/2, 
  (char)(LCD_HEIGHT+MenuHeight)/2 
}}; 
static SCR_RECT b = {{0,0,239,127}}; 
 
ScrRectFill (&a, 

Enfin c'est comme ça que je le vois . Le & sur une constante littérale, c'est quand même particulièrement crade... (à vrai dire ça me surprend que ça passe, d'ailleurs ^^)

Ah en effet. ^^
Et le static + le passage du pointeur, ça fait quoi docteur ?

sally a mieux écrit en effet ^^

le static ça empêche que ta variable soit visible dans les autres fichiers (le symbole se retrouve pas de le fichier .o)

le & dans l'appel de fonction c'est plus propre.

./281 > alors le static, ça dépend, ce que dit squalyl c'est vrai pour une déclaration globale (variable ou fonction), mais ici c'est pas le cas (bienvenue dans le C, le langage où les mots-clefs ont des significations différentes suivant le contexte ).

Pour une variable locale, dans une fonction, "static" indique que la variable n'est pas créée à chaque appel de la fonction mais une fois pour toute, et conserve sa valeur entre deux appels de la fonction.
Concrètement¹, si tu déclares ta variable normalement (sans static), elle va être recopiée sur la pile² au début de la fonction, et &a sera un pointeur sur la pile. Avec static, il n'y a pas de recopie, et &a pointe directement sur l'endroit de ton programme où sont les données ; je pense que c'est ce que tu voulais faire en prenant l'adresse d'une valeur littérale.

edit : il vaut mieux ajouter const après static si ton initialiseur ne doit pas être modifié ^^ (ça n'a aucun effet concret à part générer une erreur si tu essayes de le modifier, mais ça peut aider à trouver des bugs éventuels )

¹au moins sur 68k, ça a peut-être un effet différent sur des architectures tordues
²ou éventuellement dans un registre si c'est possible, mais bien sûr si tu veux récupérer son adresse par &a ça l'est pas ^^

Folco (./276) :
C'est valide ça ?

	ScrRectFill(&(SCR_RECT){{(char)(LCD_WIDTH-MenuWidth)/2,(char)(LCD_HEIGHT-MenuHeight)/2,(char)(LCD_WIDTH+MenuWidth)/2,(char)(LCD_HEIGHT+MenuHeight)/2}},
	&(SCR_RECT){{0,0,239,127}},A_REVERSE);

Oui, tout à fait, mais tu devrais mettre &(const SCR_RECT).

Sally (./280) :
Le & sur une constante littérale, c'est quand même particulièrement crade... (à vrai dire ça me surprend que ça passe, d'ailleurs ^^)

C'est valide avec un compound literal. D'ailleurs, normalement le littéral est recopié sur la pile de façon à ce qu'on ne puisse pas écraser l'original, sauf s'il est marqué const (parce que dans ce cas, il y a au minimum un warning le moment où tu essaies de l'écraser). Ce n'est que pour ne pas pessimiser le vieux code qui utilisait &(SCR_RECT) de partout que TIGCC ne respecte pas cette partie du standard par défaut (l'ancien GCC ne copiait jamais les compound literals sur la pile, donc beaucoup de programmeurs TI ont pris l'habitude d'écrire &(SCR_RECT){{0,0,239,127}}), il y a une option -f(no-)global-compound-literals pour ça dans TIGCC. Cette option est actuellement activée ( -fglobal-compound-literals) par défaut, mais ça pourrait changer, donc je conseille de prendre l'habitude d'écrire &(const SCR_RECT) pour éviter la recopie.

ah mais en fait MenuWidth est sans doute une variable, donc la valeur du truc n'est pas connue en temps de compilation... (j'ai été induit en erreur par le fait que ça ressemble à une constante littérale, en fait c'est pas une constante )
Donc ça sert à rien de mettre static, du moins pas pour le premier (d'ailleurs tu auras peut-être une erreur si tu essaies, vu qu'il ne pourra pas calculer la valeur à la compilation), autant pour moi.

Kevin > ah ok. Mais un truc comme "int *n = &(int) 257;" ne marcherait pas, donc ?

Sally (./285) :
ah mais en fait MenuWidth est sans doute une variable, donc la valeur du truc n'est pas connue en temps de compilation...

Oui, et donc le compound literal sera créé automatiquement sur la pile (même quand il est marqué const).

Kevin > ah ok. Mais un truc comme "int *n = &(int) 257;" ne marcherait pas ?

Non, mais int *n = (int[]){257}; marche et fait exactement ce que tu as essayé d'écrire.

Bon, ben là je rentre encore à nouveau dans une nouvelle dimension :
Quand je trace ce code :

/***************************************************
*	alloc 4 planes : 2 for grays + 2 tmp
*	clear them and enable grays
***************************************************/

	void* PlanesHdPtr;											//points to the planes handle
	void* PlanesPtr;											//ptr to the planes in the handle
	if ((PlanesHdPtr = HeapAllocPtr(LCD_SIZE*4+8)) == NULL)		//try to alloc planes to save work
	{
		ST_helpMsg("Not enough RAM to run GrayTool");			//else display a message,
		ngetchx();												//wait for a key,
		return;													//and quit
	}
	PlanesPtr = ((void*)((long)(PlanesHdPtr + 7) & ~7));		//8x alignment for HW1
	memset(PlanesPtr,0,LCD_SIZE*4);								//clear planes
	GribOn(PlanesPtr+LCD_SIZE,PlanesPtr);						//and set up grays


/***************************************************
*	Init some vars to draw
***************************************************/

	Datat DrawingData =											//default value.
	{
		{LCD_WIDTH/2,LCD_HEIGHT/2,LCD_WIDTH/2,LCD_HEIGHT/2},
		A_XOR,A_XOR,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,
		A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,
		TOOL_DOT,CURSOR_0,FLAGS_DEFAULT,CIRCLE_RADIUS,ELLIPSE_AXE_1,ELLIPSE_AXE_2,{{0,0,239,127}}
	};
	short OrgInitDelay = OSInitKeyInitDelay(40);				//keyboard speed. AMS settings are to slow
	short OrgRepeatDelay = OSInitBetweenKeyDelay(20);

L'affectation de DrawingData est purement et simplement zappée... Et dans la liste des variables (dans GDB), tous les membres de la structure sont à 0, rien n'a été initialisé.
Encore une merde de déclaration foireuse ?

C'est juste ça ton code ou tu as mis autre chose après ?
si tu t'es arrêté là, c'est possible que comme DrawingData n'est pas utilisée il la vire (optimisation). Essaie d'ajouter une utilisation de la variable...

Non, je l'utilise un peu partout (ie dans main et 5-6 fonctions très similaires appelées depuis main). Le binaire fait 2,6 ko, le source 3 fichiers .c et deux headers, si qqun veut y voir de plus près, qu'il se manifeste.

Tu ne peux pas l'utiliser dans plusieurs fonctions, tu fais une déclaration locale là... donc si tu ne l'utilises pas dans cette même fonction c'est normal qu'il la vire purement et simplement.

Bon, je vais récapituler. La syntaxe du C est moisie mais en gros :[ul][li]<identifiant> = <expression>; a pour effet d'évaluer <expression> et d'affecter le résultat à la variable nommée <identifiant>, qui doit avoir été préalablement déclarée. Si plusieurs variables portent ce nom (c'est tout à fait possible), on prend celle qui est la plus locale.[/li][li]<type> <identifiant> = <expression>; a pour effet de créer une nouvelle variable, appelée <identifiant>, et initialisée avec la valeur de <expression>. La variable sera locale si on est dans une fonction, globale sinon.[/li][li]<type> <identifiant>; a le même effet que le précédent sauf que la variable n'est pas initialisée.[/li][li]extern <type> <identifiant>; n'a pas d'effet, il déclare qu'il existe une variable nommée identifiant et que son type est celui indiqué.[/li][/ul]
Ici tu as utilisé la syntaxe correspondant au deuxième point, il s'agit donc d'une création de variable, et comme tu es dans une fonction cette variable est locale. C'est ce que j'essayais d'expliquer en ./257.

RAAAH MAIS JE VAIS Y ARRIVER A LA FIN JE TE JURE, DUSSE-JE BOUFFER GCC BIT PAR BIT !!!!!!!!!!!!!!!!!!!!

En fait, dans mon main (ce que j'ai posté au-dessus), j'ai déclaré et initialisé à la fois DrawingData, dans main(), donc c'est local, malgré le "extern Datat DrawingData;" dans le header inclus et le "Datat DrawingData;" en début de fichier (hors de main)

Alors pour créer la varible globalement, je fais :
1. "extern Datat DrawingData;" dans le header
2. "Datat DrawingData;" dans le fichier source, avant le début de main(), ie en-dehors de toute fonction
Pour l'initialiser, ou lui affecter quoi que ce soit, je fais quoi ?
Quand j'écris ça dans main, après avoir fait les étapes 1. et 2., j'ai un magnifique Expected expression before token {
Pourtant, ma variable est déclarée, elle est globale et tout et tout, qu'est-ce qui m'empêche de faire une affectation ?

	DrawingData =							//default value.
	{
		{LCD_WIDTH/2,LCD_HEIGHT/2,LCD_WIDTH/2,LCD_HEIGHT/2},
		A_XOR,A_XOR,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,
		A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,
		TOOL_DOT,CURSOR_0,FLAGS_DEFAULT,CIRCLE_RADIUS,ELLIPSE_AXE_1,ELLIPSE_AXE_2,{{0,0,239,127}}
	};

C'est parce que tu dois utiliser la syntaxe indiquée par Kevin (le compound literal), celle qui ressemble à un typecast : DrawingData = (Datat) { blablabla };

En fait le pseudo-cast (Datat) sert à indiquer au parseur quoi faire avec ce qui suit, parce qu'il n'est pas capable de deviner tout seul (c'est ce que dit le message d'erreur : il ne comprend pas pourquoi il y a une accolade ouvrante.)Sinon :

Folco (./291) :
En fait, dans mon main (ce que j'ai posté au-dessus), j'ai déclaré et initialisé à la fois DrawingData, dans main(), donc c'est local, malgré le "extern Datat DrawingData;" dans le header inclus et le "Datat DrawingData;" en début de fichier (hors de main)

Voilà, c'est ça

J'ai bien essayé, mais suite à ça je me tape 14 erreurs de relogements to far for size 2 at 0xF*CKGCC

Ah, ça recompile sans -mpcrel... mais j'ai 21 sdf à reloger ... Faut que je trouve un truc... quitte à n'utiliser qu'un pointeur global sur cette p****n de structure.

Au fait, je peux avoir un pointeur global pointant sur une variable locale à main ?

Oui
C'est simple : en C, tu peux faire presque tout ce que tu veux, après, c'est à tes risques et périls

Mais j'imagine que la variable, si elle est déclarée dans main(), ne devrait être détruite qu'à la sortie, donc ça devrait le faire

Oui, la variable sera sur la pile

En effet, c'est cool nan ? (mais 0% propre )

Le pire c'est qu'après il va vouloir optimiser son pointeur en utilisant une global register variable, et au bout du compte ça reviendra exactement au même que de passer le pointeur en paramètre à toutes les fonctions qui en ont besoin (en utilisant regparm)

Super justement ! Ximoon, pourquoi ça serait sale ? Tout les bons codeurs asm passent leur temps à faire ça ?

Et ya un truc que je comprends pas, je vous ai toujours lu dire que la connaissance de l'asm aide à faire du C, parce qu'on comprend ce que fait la machine et ce qu'on lui demande. Pourquoi serait-ce un tort de vouloir coller à peu près à ce que je fais en asm, sachant que mes techniques sont pas trop mauvaises ? Ok pour le moment j'y passe certainement un temps fou, mais c'est le temps de trouver mes marques, perso ça me dérange pas et c'et pourquoi je perds ces verres.