Problème avec Extgraph - Page 1

J'ai un problème avec ExtGraph 2.00 et TIGCC

Avec la fonction GrayClipSprite32_OR_R : elle ne clippe pas justement !!

Quelqu'un a une solution ???

extgraph 2.00 ?

Ah, ça me rappelle quelque chose ce problème...

Essaye avec cette routine-là, je ne suis pas sûr que ça soit avec elle que j'ai eu un problème, mais si oui alors elle a du être modifiée par Sasume et elle devrait marcher.

(je ne garantis rien, si ça se trouve elle n'est même pas différente de la tienne, mais ça vaut le coup d'essayer)

Euh.... je la mets dans un header ?

tu peux recompiler extgraph sinon

Soit tu recompile extgraph comme dit liquid, soit tu extrait les fonctions dont t'as besoin depuis les sources pour les ajouter à ton proj, et tu en profite pour utiliser celle là à la place de celle contenue dans le zip.

Ah ouais on est pas obligé de mettre toute la lib et l'archive c'est bien ça prendre moins de place je suppose
Merci à tous les deux !

Warcraft : Battles c'est pour bientôt !

heu, ca prends pas plus de place de mettre toute la lib, vu que c statique, seules les fonctions utilisees ds ton prgm seront ajoutees, les autres seront pas incluses, a l´inverse d´une lib dynamique

Rising Sun
: Ah ouais on est pas obligé de mettre toute la lib et l'archive c'est bien ça prendre moins de place je suppose

Non, ça ne copie dans ton code que les fonctions que tu utilise (c'est l'avantage d'une bibliothèque statique). Mais l'autre méthode fonctionne exactement pareil, du moment que tu le modifie pas le .c ou tu as mit les fonctions d'Extgraph, il n'y aura pas non plus besoin de le recompiler

[edit] et hop, un 2eme cross post

Tu as quelle version précisément ?
Je n'ai que ExtGraph 2 beta 1, mais la routine qui est dedans est clippée (enfin, normalement). En tout cas, elle a l'air d'être très proche de celle de Vertyos.

De toutes façons, cette routine est de toi. Mais je ne sais pas si c'est une version corrigée ou si elle vient directement d'Extgraph. Tout ce dont je me rappelle c'est qu'une des fonctions de sprites d'Extgraph 2.00 était buggée et que tu m'as envoyé une correction, mais la version dispo sur le site tict ne doit pas être à jour -> y'a des chances pour que ce soit cette routine-là, autant essayer.

Moi, il me semble que toutes les routines clippées que j'avais écrites avaient le même bug (un if(a<b) au lieu de if(a<=b)), et que ça provoquait une écriture en dehors du buffer de destination. Il me semble que la routine que tu avais était une vieille qui serait la future routine d'extgraph, mais qu'entretemps, j'ai corrigé le bug de celle qu'on a mise dans extgraph.
Ce que je viens d'écrire est incompréhensible, le plus simple est de vérifier. Je le fais tout de suite.

OK, c'est bon, je viens de vérifier avec diff, et les fichiers sont les mêmes (sauf la première ligne qui est un commentaire).

Ok, alors c'était une autre, mais il y a une des routines que j'utilise que tu as modifié par rapport à la version du zip.

Ca n'a absolument rien changé

Que faire ?

Ah, donc c'est un autre bug.
Tu peux m'envoyer un source compilable qui montre le bug (si possible sans trop de code inutile autour) ?

non ca revient pas au meme de complier avec un *.a et d'ajouter le code dans le fichier *.c ... si tu ajoute les fonctions dans le fichier *.c le compilo optimisera les bcc contrairement au *.a et a u fait de mettre du code dans plusieurs fichiers *.c

Ouch...
Euh oui merci JackosKing (hoche la tête en ayant l'air d'avoir compris)

JackosKing
: non ca revient pas au meme de complier avec un *.a et d'ajouter le code dans le fichier *.c ... si tu ajoute les fonctions dans le fichier *.c le compilo optimisera les bcc contrairement au *.a et a u fait de mettre du code dans plusieurs fichiers *.c

Si tu le mets dans un .a, c'est le linker qui optimisera ça, donc ça revient au même!
Mais arrêtez de penser en les termes de TIGCC 0.94!

Un linker ne peut jamais optimiser aussi bien qu'un compilo (optimisation du flux de données, etc...)

Tu n'as visiblement pas compris. Relis mieux! Il dit que GCC "optimisera les bcc" (bsr en l'occurrence) et le linker fait ça très bien. (D'ailleurs, même à l'intérieur d'un fichier source, ce n'est pas GCC qui fait ça, mais GNU as.)

GCC 3.3 n'optimise rien du tout intraprocéduralement, il n'y a que les optimisations des branchements faits par l'assembleur, donc le linker peut optimiser tout aussi bien.

Je te remercie, j'avais bien lu le message. Mais il n'empêche que son argument de fond reste valable, à savoir qu'un compilo optimise mieux s'il a un seul .c que s'il en a plusieurs... Si ce n'est pas encore le cas (<troll> parce que GCC n'est pas encore au point </>), ça le sera peut-être un jour.

Tout mettre dans un .c n'est pas une solution. C'est un hack pour un problème qui n'existe pas encore, et qui même s'il existra un jour ne sera que temporaire. GCC 3.4 permettra justement aussi de compiler plusieurs fichiers .c en même temps (oui, comme GTools Compiler ) pour résoudre ce problème, par exemple. Quant aux .a, il y aura certainement un moyen de mettre des trucs optimisables en temps de linking dedans. Va voir par exemple le projet LLVM.

Tiens c'est marrant ce projet Ils prévoient même d'exporter du code C portable, ce qui voudrait dire qu'on pourrait recompiler un prog Java ou C++ en prog C Cela dit, j'ai qd même certains doutes (dépendance vis-à-vis de l'endianness ou de la taille des types de bases ?)

Pour revenir à nos moutons :
- si tu me fais un front-end pour LLVM, tant mieux... (je pourrais te passer les sources du front-end pour relier le front-end de GTC au nouveau générateur de code)
- la moindre des choses serait qu'il y ait tjs un binaire compilé en plus du truc non-compilé
- pour l'instant LLVM balbutie : il ne compile pas (encore?) les nested functions, par exemple

Pollux :
Tiens c'est marrant ce projet

Il y a d'ailleurs pas mal de trucs qui marchent déjà. (Ils en sont à la release 1.1.)

Cela dit, j'ai qd même certains doutes (dépendance vis-à-vis de l'endianness ou de la taille des types de bases ?)

Contrairement aux fichiers objet traditionnels, leur langage intermédiaire est typé.

Pour revenir à nos moutons : - si tu me fais un front-end pour LLVM, tant mieux... (je pourrais te passer les sources du front-end pour relier le front-end de GTC au nouveau générateur de code)

Il y a déjà un frontend C pour LLVM.

- la moindre des choses serait qu'il y ait tjs un binaire compilé en plus du truc non-compilé

Évidemment. Si jamais un TIGCC du futur utilise LLVM, ce ne sera pas avec le JIT, mais avec un générateur de code. Soit leur générateur C, soit un générateur 68k (qui n'existe pas encore).

- pour l'instant LLVM balbutie : il ne compile pas (encore?) les nested functions, par exemple

Oui, mais bon, ce n'est pas du C standard, et puis TIGCC a aussi ses problèmes avec les "nested functions", surtout sur la "Titanic".

Kevin Kofler
:

Pollux :
Tiens c'est marrant ce projet

Il y a d'ailleurs pas mal de trucs qui marchent déjà. (Ils en sont à la release 1.1.)

Moui, g pas essayé en détail. Il compile des gros trucs ou pas?

Cela dit, j'ai qd même certains doutes (dépendance vis-à-vis de l'endianness ou de la taille des types de bases ?)

Contrairement aux fichiers objet traditionnels, leur langage intermédiaire est typé.

Voui, mais j'ai vu des déclaration d'endianness dans mes qques tests... ce qui laisserait entendre que le code généré peut en dépendre (à moins qu'il ne se débrouillent toujours avec des union & co, auquel cas c'est assez fort s'ils arrivent à faire un back-end pour n'importe quel langage).

Pour revenir à nos moutons : - si tu me fais un front-end pour LLVM, tant mieux... (je pourrais te passer les sources du front-end pour relier le front-end de GTC au nouveau générateur de code)

Il y a déjà un frontend C pour LLVM.

Ah, OK. Faudrait que j'essaye, alors (pour l'instant j'ai juste essayé leur "compilateur web", qui ne supportait pas l'option).

- la moindre des choses serait qu'il y ait tjs un binaire compilé en plus du truc non-compilé

Évidemment. Si jamais un TIGCC du futur utilise LLVM, ce ne sera pas avec le JIT, mais avec un générateur de code. Soit leur générateur C, soit un générateur 68k (qui n'existe pas encore).

Y a aussi un JIT

- pour l'instant LLVM balbutie : il ne compile pas (encore?) les nested functions, par exemple

Oui, mais bon, ce n'est pas du C standard, et puis TIGCC a aussi ses problèmes avec les "nested functions", surtout sur la "Titanic".

Arf, oui... Enfin bon ce que je veux dire c qu'on est pas près de recompiler KDE avec LLVM par exemple

Leur compilateur web te demande justement si ce que tu veux compiler est du C ou du C++.

Pollux
:

- la moindre des choses serait qu'il y ait tjs un binaire compilé en plus du truc non-compilé

Évidemment. Si jamais un TIGCC du futur utilise LLVM, ce ne sera pas avec le JIT, mais avec un générateur de code. Soit leur générateur C, soit un générateur 68k (qui n'existe pas encore).

Y a aussi un JIT

Oui, et leur serveur web tourne dessus! Ou du moins c'était le cas au départ, je ne trouve plus la référence maintenant.

Kevin Kofler
: Leur compilateur web te demande justement si ce que tu veux compiler est du C ou du C++.

Ah, tu parlais d'un frontend. Je croyais que tu parlais d'un backend... (ce qui aurait arrangé les choses question portabilité)

Il y a aussi un backend C. Mais en effet, la démo web ne le montre pas.