Pb avec Genlib... - Page 6

> Si, parce que ça pourrait aussi (éventuellement) breaker des programmes en C.
Je veux bien que tu m'expliques pourquoi. (à condition bien sûr que tu ne modifies que EXTGRAPH_FUNC_ATTRIBUTES et que tu n'utilises pas -mregparm)

> Je veux bien que tu m'expliques pourquoi.
Ben, je ne sais pas bien pourquoi...
Mais je sais que le fait de mettre dans les options de compilation de tthdex -mregparm faisait tout planter, il y a quelques mois de cela. Le fait de passer tout en __regparm__ par défaut au lieu de __stkparm__ pourrait donc éventuellement breaker des programmes (improbable, OK).
On ne peut pas être sûr de ne pas faire de casse, quand on fait des modifications aussi importantes...

On a décidé de ne pas breaker la compatibilité antérieure. Les noms actuels des fonctions désigneront les fonctions __stkparm__, les mêmes noms avec "_R" à la fin désigneront les fonctions __regparm__.

La librairie sera mécaniquement deux fois plus grosse, c'est bête, OK. Mais ça permettra à un programmeur d'utiliser les versions qu'il veut des routines, de pouvoir mélanger les deux types (presque aucun intérêt, je sais...)

C ce que je disais, il n'y a pas besoin de forcer -mregparm (sinon il met en regparm TOUTES les fonctions, pas que Ext), il suffit de modifier __EXTGRAPH_FUNC_ATTRIBUTES__ (ou un truc comme ça)

Eux, il voulaient forcer le passage par registres de toutes les fonctions, que ça soit un comportement par défaut. La seule solution était -mregparm.
Ce que dit XDanger, c'est que, malheureusement, ça fait planter certains programmes.

J'ai bien compris ?

Oui (enfin, si j'ai bien compris )

Mais personnellement, je ne suis pas trop d'accord.
Si on ne compile pas en -mregparm, mais qu'on déclare bien les prototypes : Sprite8_OR(register short asm("%d0"),register short asm("%d1"),register short asm("%d2"),register short asm("%a1"),register short asm("%a0")); par exemple, il n'y aura pas de problème à la compilation.

C ce que je dis dans #152. D'ailleurs c pas une très bonne idée d'utiliser asm("d0") dans les prototypes puisque GTC ne les supporte pas (mais on peut utiliser regparm quand même...)

Ben ouais, mais si je compile en -mregparm avec le prototype suivant ça ne marchera pas : void Sprite8(short x,short y,short h,char *sprt,void *dest); parce que sprt se retrouvera dans a0 et dest dans a1 alors que ma fonction (en asm) a besoin que dest soit dans a0 et sprt dans a1

Ben tu choisis des registres consistants (ça facilite l'utilisation de ces fonctions en ASM d'ailleurs...)

Si vraiment tu tiens à utiliser ça (mais c pas une très bonne idée...), tu peux faire :
void __attribute__((regparm(3,2))) _Sprite8(short x,short y,short h,void *dest,char *sprt);
#define Sprite8(x,y,h,sprt,dest) _Sprite8(x,y,h,dest,sprt)

C'est quand même mieux d'utiliser la convention standard

(j'en profite pour dire que GTC ne supporte pas au-delà de regparm(3,2), et encore mieux vaut pour la qualité du code utiliser regparm(2), donc ça peut qd même être une bonne idée de garder les versions stkparm )

Ben oué, mais j'avais commencé à faire mes fonctions sans penser qu'elles iraient dans ExtGraph, donc je m'en foutait que le proto ne soit pas compatible extgraph...

Je ne te reproche rien, je te dis juste que si tu comptes les publier c mieux de respecter le standard (si quelqu'un connaît l'ordre des args dans le prototype C, il pourra utiliser la fonction en ASM sans pb, sinon avec le 'register' il va avoir des pb puisqu'il faudra voir à quel registre correspond chaque argument)

Pollux
a écrit : C ce que je dis dans #152. D'ailleurs c pas une très bonne idée d'utiliser asm("d0") dans les prototypes puisque GTC ne les supporte pas

Ben, GTC n'a qu'à les supporter. J'en ai marre des "c pas une très bonne idée d'utiliser XYZ puisque GTC ne le(s) supporte pas" alors que tu trouves apparemment une bonne idée d'utiliser les extensions que tu as rajouté à GTC et que TIGCC ne comprendra pas (normal, tu les as rajoutés après). La compatibilité dans un sens, c'est une attitude typique de M$.

Je ne t'empêche pas de dire "c'est pas une très bonne idée d'utiliser #macro" (et je ne pense pas que tu t'en priveras )

Pollux a écrit :
Ben tu choisis des registres consistants (ça facilite l'utilisation de ces fonctions en ASM d'ailleurs...)

Tant pis, GTC ne supportera jamais scanf alors. Mon implémentation utilise des asm("an"). Et d'ailleurs aussi avec des registres qui ne sont pas call-clobbered.

Si vraiment tu tiens à utiliser ça (mais c pas une très bonne idée...), tu peux faire :
void __attribute__((regparm(3,2))) _Sprite8(short x,short y,short h,void *dest,char *sprt); #define Sprite8(x,y,h,sprt,dest) _Sprite8(x,y,h,dest,sprt)

C'est un hack. Ça donne du code moins efficace quand on a besoin de passer un paramètre en %d0 et un en %d2, en sautant %d1. Et puis TIGCC ne comprend pas __attribute__((regparm(3,2))) (du moins pas pour le moment).
Et je rappelle que la méthode de passage par registres conseillée pour TIGCC est la spécification explicite. Nous ne supportons les attributs et switches regparm que parce qu'ils étaient implémentés par le même patch.

C'est quand même mieux d'utiliser la convention standard

Non, le mieux est d'utiliser la convention qui donne le code le plus efficace.

Et je rappelle que la méthode de passage par registres conseillée pour TIGCC est la spécification explicite.

Ah bon?
Moi je trouve que c'est plus beau un prototype comme:
__attribute__((regparm(4)))
void spr8(short x, short y, void *screen, void *spr8);

plutôt que:
void spr8(short x asm("%d0"), short y asm("%d1"), void *screen asm("%a0"), void *spr asm("%a1");

De toute façon, les 2 sont supportés maintenant, donc tu choisis ce que tu préfères.

Je me contre-fiche qu'ExtGraph ne fonctionne pas sous GTC... Nous prototyperons nos routines comme nous l'entendons, et tant pis pour GTC s'il ne le supporte pas...
Je trouve que ça commence à faire beaucoup de manques à GTC...
L'absence de support de l'ASM inline avec (et sans, je ne sais plus ?) opérandes C, si regrettable qu'elle soit, ne touchera pas tous les programmeurs (tiens, d'ailleurs, ExtGraph ne fonctionne déjà pas sous GTC pour cette raison...); en revanche, le fait de ne pas pouvoir spécifier les registres est à mon sens une horreur, et bien plus de monde utilise le passage par registres que l'ASM inline avec/sans opérandes C.

Tu te rappelles de ce que j'ai dit, Pollux ? Interdiction de ne pas mentionner les trucs que TIGCC fait mais pas GTC... Et là, ça commence à faire lourd pour GTC...

C'est vrai que c'est dommage. C'est pas possible quand les versions à venir (pas celle que tuvas distribuer d'ici quelques jours) tu gères ça ? Ce serait bien pratique

Non, ou si je le supportais, ce serait un "mode d'émulation" qui générerait un code complètement horrible => très mauvaise idée...

tiens, d'ailleurs, ExtGraph ne fonctionne déjà pas sous GTC pour cette raison...

Si si, j'ai porté les 2/3 routines qui l'utilisent.

Tant pis, GTC ne supportera jamais scanf alors. Mon implémentation utilise des asm("an"). Et d'ailleurs aussi avec des registres qui ne sont pas call-clobbered.

Tant pis, je le porterai

Alalala....
On voit qu'heuresement je passe par la....
Bon PortSet marche nickel...
POur faire un porset il faut indiquer quel memoire video prendre Donc tu prend ton DSCREEN
Ensuite un DSCREEN est constitué de deux SCREEN
Le gris clair et le gris foncé!
Donc pour le gris clair:
PortSet(dscreen,239,127);

Et pour le gris foncé
PortSet((unsigned char *)dscreen+SCREEN_SIZE,239,127);
vla!
Mais je te conseille gl_put_large_string avec sprintf....
Sinon je trouve ca un peu hallucinant tes bench!!!!
Même Kevin la deja dit que genlib etait plus rapide.....
Je pense que soit tu confond certain truc soit tu te trompe...
Vla

Pour moi, il se plante et bench des routines NB avec des routines 4G. J'attend la prochaine release d'extgraph pour voir.

Qui se plante ? Raphaël ou moi ?
Si tu veux, je te passe ma source et tu fais le bench toi-même.
Ou si tu veux, je te passe la source du bench.

Disons que les noms des fonctions HLine_OR me laisse supposer que c'est du NB. C'est tout.

Oui, HLine_OR est une fonction NB.
Mais je t'ai demandé à plusieurs reprise si gl_draw_bwhline_b était équivalent à HLine_OR et tu ne m'as pas répondu (ou bien je n'ai pas vu le post, dans ce cas, je m'excuse), mais d'après la doc de genlib ça a l'air d'être équivalent.

En plus du clipping, je crois que cette fonction est equivalente (Du moins avec le titre). Cf + haut.

La mienne aussi, je l'avais modifiée pour qu'elle soit clippée, donc c'est bon...

Pollux a écrit :
Tant pis, je le porterai

Bonne chance.

> Tant pis, je le porterai
A ta guise...
Pour moi, c'est stupide d'essayer de rendre moins inintéressant un compilateur inférieur à TIGCC (tous les manques de GTC n'ont d'ailleurs peut-être pas encore été dévoilés)...

Par curiosité: comment fais-tu pour émuler les macros d'ExtGraph qui utilisent de l'ASM inline avec opérandes C correctement (FYI, je veux en ajouter au moins 4*3 autres...) avec un compilateur qui ne supporte pas l'ASM inline avec opérandes C ?

D'après les 2-3 exemples que j'ai vus, il le supporte, mais avec une autre syntaxe (incompatible évidemment).