Librairie dynamique - Page 2

Surement kernel.h

Et bien voilà, en une après-midi, j'ai écrit autant qu'en 3 jours d'asm...

C'est grâce à tout l'expérience de ces 3j que tu as pu tout refaire en un après midi

Spa si faux remarque, j'ai repompé les noms de variables, sprites et map etc

Il y a une info que je n'ai pas trouvée : que se passe-t-il si gl_main échoue (mémoire) ? Ca quitte tout seul proprement ? Toute façon, on prend pas la main dans ce cas j'imagine.

Est-ce que gl_quit est appelé à la fin de gl_main ? Peut-on l'appeler soi-même si on veut, par exemple pour afficher un message d'erreur dans home avant de quitter ?

Chais pas, chais plus. L'a-t-il déjà été ? spécifié

Bon j'ai compris, je plonge dans genlib::quit

=> genlib.asm, line 293

	lea	InitQuitFlag(Pc),a1
	tst.b	(a1)			; Test if install ?
	beq.s	\no_deinstall

Comme quoi, c'était écrit. Mais c'est garanti ? Par contre, je suis pas assez bon pour voir ce que fait gl_main, c'est du C. Désolé.

Sinon, ya moyen d'avoir -Wextra avec tigcc ?

Folco (./28) :
En plus, quand je compile avec "-Wa,-l", il me dit
1. Que j'ai encore de l'espace à gagner avec le switch -l de GAS !!2. Que les ramcalls peuvent pas être relatifs (sans blague) et qu'il les passe en absolu.

Les RAM_CALLs, ROM_CALLs et lib calls relogés (format kernel) ne sont pas comptés correctement dans ce calcul.

-Wa,-l ne peut pas être utilisé avec un programme kernel (ni avec un programme nostub de plus de 32 KO ou avec une section BSS ou …, il y a plein de limitations; ce n'est pas sans raisons que c'est désactivé par défaut!). Laisse le linker faire son travail et ignore le calcul d'octets que tu pourrais gagner avec -Wa,-l qui n'est qu'une approximation, parfois mauvaise.

Folco (./32) :
Et bien voilà, en une après-midi, j'ai écrit autant qu'en 3 jours d'asm...

Depuis le temps que je te dis que le C permet de coder beaucoup plus rapidement…

L'assembleur a bien sa place, GCC est loin d'être aussi bon à optimiser comme un bon développeur en assembleur pour une machine comme le 68k et risque de ne jamais l'être, mais pour la vitesse de développement, le C est loin devant.

Très bien, merci. Et pour -Wextra, pas moyen ? J'aime bien essayer de faire les choses proprement.
Je compile maintenant avec ça : "tigcc -v -O2 -Wall --cut-ranges --optimize-code --remove-unused --optimize-relocs --merge-constants --reorder-section

-Wextra est le nouveau nom de l'option -W
Avec GCC 4.3, `man gcc` indique

-Wextra
This enables some extra warning flags that are not enabled by -Wall. (This option used to be called -W. The older name is still supported, but the newer name is more descriptive.)

Anéfé, merci !

W
Print extra warning messages for these events: [...]

Une question encore :

	FuncPtr = kernel_LibsPtr(MapDesc , MAP_Dim);
	SizeLog2 = *(short *) FuncPtr++;

FuncPtr est un void*, SizeLog2 un short.
FuncPtr va bien être augmenté de 2 après ça ?

ps -> ouééééééééé j'affiche plus le Groenland, mais la map kivabien \o/

FuncPtr ne va pas etre augmenté de 2, du moins ça va dépendre de l'implementation/paltforme, si j'ai bonne mémoire, ça va augmenter de la taille d'un mot natif a la platforme (et la logique voudrai que ça soit de 32bits, sur un CPU 32, donc 4 octets)

Mais bon, le void* est un type spéciale

C'est compliqué ce truc. Je lis deux octets et je post-incrémente. Je pensais pointer sur les deux octets suivants.

Là c’est ambigu, je ne sais pas si le transtypage est réalisé avant la post incrémentation ou non. Mais quand tu ajoutes quelque chose à un pointeur de type void * tu ajoutes un nombre d’octets. Donc le transtypage en short * doit être réalisé avant l’incrémentation.

Oui c'est ambigu, donc la solution quand c'est ambigu c'est de rajouter des parenthèses
*((short *) FuncPtr)++

Bon, alors s'il n'y a pas d'objections, je vais faire comme Sally a dit alors. Merci à tous.
J'aurais quand même aimé savoir ce que ça fait. Je ferai un test à l'occasion.

Bon, autre question.
J'ai écrit ça :
Ce n'est que la réimplémentation de ce que j'avais écrit en assembleur, ça sert à scroller une map en fonction du perso, et à réajuster la map sur l'écran si elle a trop scrollé.

Ce qui m'intéresse ici est le label. En assembleur, j'avais mis un bra pour éviter l'affectation et le test de débordement de l'autre côté, si l'on avait déjà débordé d'un côté. La, j'ai mis un goto, je trouve pas ça très chouette.
J'aimerais faire ça sans goto, pour être plus propre (pas de troll...). Comment faire ?

pourquoi tu trouve pas sa chouette ?
ya plein de bon soft en C qui utilisent les goto, c'est souvent utile pour aller directement en fin de fonction par exemple

non rien, j'ai lu trop vite

Heu... ton code n'est pas équivalent à un "else" qui engloberait toute la partie que tu sautes avec ton goto ?

Si oui, alors effectivement dans ce cas précis le goto est mal venu, mais comme l'a dit Godzil il y a aussi des cas où c'est la meilleure solution. Si tu pars avec des idées préconçues genre "les goto c'est mal" véhiculées par des andouilles, tu risques de passer à coté de pas mal de trucs

Mais pour ton cas particulier, tu peux juste faire un

	if(CharY < 30) 
	{ 
		offset = 30 - CharY; 
		CharY = 30; 
		PlanePtr->ys -= offset; 
		if((signed) PlanePtr->ys < 0) 
		{ 
			CharY -= PlanePtr->ys; 
			PlanePtr->ys = 0; 
		} 
	} 
        else
        {
        	limit = LCD_HEIGHT - 30; 
        	if((unsigned) CharY > limit) 
        	{ 
        		offset = CharY - limit; 
        		CharY = limit; 
                		PlanePtr->ys += offset; 
	        	if(PlanePtr->ys > ScrollMaxY) 
        		{ 
        			CharY -= PlanePtr->ys; 
        			PlanePtr->ys = ScrollMaxY; 
        		} 
                }
	} 

Comme le dit bob, j'avais un apriori sur les gotos a l'origine, apriori véhiculé par des idiots du C, c'est vrai, et en fait j'ai découvert la puissance du goto, et j'en abuse now

int bla()
{
 int ret = 0;
 int blabla;

 printf(">>%s()", __func__);

 blabla = do_that();

 if (blabla == fail)
 {
   ret = -1;
   goto exit:
 }
  do_these();

exit:
 printf("<<%s() = %d", __func__, ret);
 return ret;
}

La ça peut paraitre ridicule, mais le code est beaucoup plus lisible, il n'est pas bloaté par des printf a chaque return etc...

Autre cas on c'est utile (tres utilisé dans linux par exemple)

int func()
{
 int ret = 0;
 FILE *fp;
 char *toto;
 toto = (char*)malloc(128);
 if (!toto)
   goto bad_exit;
 if (!(fp = fopen("thefile.txt", "rt")))
   goto free_toto:
 
 do_whatever_we_want();
 fclose(fp);
 goto exit;

free_toto:
  free(toto);
bad_exit:
  ret = -1;
exit:
  return ret;
}

(par exemple)

Godzil (./51) :
La ça peut paraitre ridicule, mais le code est beaucoup plus lisible

Euh à part que comme dans l'exemple précédent tu as juste représenté un else par un goto, ça reste un peu débile non ?

Normalement, -Wextra devrait aussi passer avec TIGCC!

Sally (./52) :

Godzil (./51) :
La ça peut paraitre ridicule, mais le code est beaucoup plus lisible

Euh à part que comme dans l'exemple précédent tu as juste représenté un else par un goto, ça reste un peu débile non ?

dans ce cas précis oui, mais il était fait pour rester simple

Je ne suis pas non plus convaincu par le dernier exemple

int func() 
{ 
 FILE *fp; 
 char *toto; 
 toto = (char*)malloc(128); 
 if (toto) {
  if (fp = fopen("thefile.txt", "rt")) {
    do_whatever_we_want(); 
    fclose(fp);
    return 0;
  }
  else free toto;
 }
 return -1;
}

Bon évidemment le problème c'est que tu veux prendre des exemples simples et que goto n'est utile que dans des cas compliqués, je comprends bien, mais bon

oui mais la avec des else c'est moche au moins le label des goto est explicite

./55 : avec cette version tu ne libères pas toto quand ton traitement a été effectué sans erreur, c'est très mal (surtout sur Ti) ^^

mais effectivement, autant ça se fait très bien avec des if imbriqués, autant si y'a 10 erreurs imbriquées à rattraper ça devient vite un bordel d'indentation illisible et la proposition de Godzil a son avantage :

allocation mémoire 1;

if (ok allocation 1)
{
    ouverture fichier 1;

    if (ok fichier 1)
    {
        allocation mémoire 2;

        if (ok allocation 2)
        {
            ouverture fichier 2;

            if (ok fichier 2)
            {
                la seule partie utile de cette horrible pyramide de gestion d'erreurs;

                fermeture fichier 2;
            }

            libération mémoire 2;
        }

        fermeture fichier 1;
    }

    libération mémoire 1;
}

Tu peux enlever le else si tu veux, il n'est là que pour faire joli en fait (j'ai hésité mais je trouvais ça plus clair comme ça)

Sally (./46) :
Oui c'est ambigu, donc la solution quand c'est ambigu c'est de rajouter des parenthèses *((short *) FuncPtr)++

Attention quand-même, ce truc est un lvalue cast, ce n'est pas du C standard et ce n'est plus géré par le GCC officiel (mais celui de TIGCC est patché pour le permettre).

Quant aux goto, ce qui est intéressant, c'est qu'on peut aussi rentrer dans les blocs avec, ce qui permet d'éviter pas mal de répétitions. Cf. par exemple cette fonction (c'est du C++, mais on peut faire la même chose en C): http://tigcc-linux.cvs.sourceforge.net/viewvc/tigcc-linux/ktigcc/mainform.cpp?revision=1.101&view=markup#l_1372.

Hey oh je voulais pas déchainer la polémique justement. La solution du Else est en effet ce qui convient ici. Je n'ai rien contre les goto à priori, je voulais savoir si dans ce cas, je pouvais l'éviter tout en gardant mon optimisation. De toute façon, en assembleur, on fait des goto à la pelle, donc je suis le roi du goto.

Kevin Kofler (./53) :
Normalement, -Wextra devrait aussi passer avec TIGCC!

Ah, il est pas dans la doc. Et comme je n'avais pas de warnings supplémentaires, je pensais qu'il ne marchait pas.