pointeur de fonction - Page 1

j'ai une librairie statique dans laquelle j'ai une fonction qui a besoin en parametre d'une fonction d'affichage :
void fct_comp(...args..., TypeFctDraw fct_draw) {
...
if (fct_draw!=NULL)
fct_draw(...params...);
...
}

ensuite, dans un autre prog, j'utilise cette lib et je fais un appel de cette fonction :

void fct_draw(...param...) {
DrawStr(x1,....);
}

void _main() {
fct_comp(...,fct_draw);
}

et la, c'est plantage assuré...
et si je mets un DrawLine a la place de DrawStr, c'est pareil.
Mais si je mets juste un printf, ca marche nickel...???

Si qq'un sait d'ou ca peut venir ?

j'ai pas les sources la, donc je peux pas les mettre. Quand a la version de tigcc, ca doit etre la 94 SP4
je peux pas passer a la 95 car j'ai pas le net chez moi, et le seul moyen de récupérer des données depuis mon ecole (la ou j'accede a internet) sont les disquettes....

C'est quoi la methode pour appeller les romcalls ? OPTIMIZE_ROM_CALLS ?

je peux pas passer a la 95 car j'ai pas le net chez moi, et le seul moyen de récupérer des données depuis mon ecole (la ou j'accede a internet) sont les disquettes....

Ben ça tient sur deux disquettes non ? c'est pas la mort...
Sinon, oui, si ton programme est compilé avec OPTIMIZE_ROM_CALLS et pas la bibliothèque, ça pourrait expliquer...

normalement, ca y est dans les deux....
mais je vais veriifier

De toute façon OPTIMIZE_ROM_CALLS est vraiment un hack sale, qui peut facilement être source de plantages... Et le gain est vraiment très faible.

très faible ? ça dépend, non ?

Oui, ça dépend. Mais pour un certain nb de fonctions, ça ne fait que gaspiller un registre.

Normalement, OPTIMIZE_ROM_CALLS est un gain assez important.

Quand a la version de tigcc, ca doit etre la 94 SP4 je peux pas passer a la 95 car j'ai pas le net chez moi, et le seul moyen de récupérer des données depuis mon ecole (la ou j'accede a internet) sont les disquettes....

Tu peux toujours utiliser un programme qui découpe les fichiers en plusieurs morceaux. Je peux te passer mon programme : il peut produire des morceaux de fichiers de la taille d'une disquette à l'octets près et en plus il est tout petit.
Mais sinon tu peux facilement en trouver d'autres sur Internet.

Y'a WinZip qui fait ça très bien

Normalement, OPTIMIZE_ROM_CALLS est un gain assez important.

Ou alors, c'est GCC qui optimise mal sans

c'est bien un pb d'OPTIMIZE_ROM_CALLS
si je compile la fonction que "j'envoie" en parametre en OPTIMIZE_ROM_CALLS, ca plante

Kevin>faut-il que je fasse un bug report ? pour que ce soit au moins mis dans la doc....

LaFilleKadoreOGG>le pb c'est que mon ecole n'utilise pas winzip mais un autre truc totalement inconnu sur les station windows. pour les sations sun, je sais pas faire si jamais ca existe....
la solution la plus facile est que je demande tout simplement a un pote de me telecharger et qu'il le mette sur un cdrw que je lui aurait passé...

sous unix : fais man dd

la syntaxe, ça donne dd if=larchivequetuveuxdecouper of=lepremiermorceau bs=1k count=1350 (ou peut-être un peu plus je ne sais pas combien exactement tient sur une disquette)
puis dd if=larchivequetuveuxdecouper of=lautremorceau bs=1k skip=1350

et pour reconstituer : cat lepremiermorceau lautremorceau > larchivereconstituée

hibou
: Kevin>faut-il que je fasse un bug report ? pour que ce soit au moins mis dans la doc....

C'est documenté. Tu ne peux pas passer une fonction compilée avec OPTIMIZE_ROM_CALLS en callback à une fonction qui ne l'est pas (cela comprend les fonctions de AMS). Exception: qsort, pour laquelle on a explicitement réservé le registre a5.

Workaround:
void callback(void)
{
void *olda5=__jmp_tbl;
__jmp_tbl=*(void**)0xc8;
...
__jmp_tbl=olda5;
}

... et je te conseille accessoirement de faire :

void callback(void)
{
#ifdef OPTIMIZE_ROM_CALLS
  void *olda5=__jmp_tbl;
  __jmp_tbl=*(void**)0xc8;
#endif
  ...
#ifdef OPTIMIZE_ROM_CALLS
  __jmp_tbl=olda5;
#endif
}

comme ça tu es compatible avec GTC et tu pourras aussi éventuellement enlever ça dans le futur. GTC 1.0 sera probablement assez intelligent pour mettre $C8 dans un registre lorsque c'est utile, et utiliser le registre dans le cas contraire (ce qui permet aussi d'éviter les problèmes de callback). Si on ne vérifie pas que OPTIMIZE_ROM_CALLS n'a pas été enlevé, ce n'est pas compatible avec ces optimisations "intelligentes".

Évidemment que ça ne marche que avec OPTIMIZE_ROM_CALLS, mais je trouve d'assez mauvais goût de polluer un programme avec des #ifdef alors que la variable testée est obligatoirement définie (soit plus haut dans le même fichier, soit en ligne de commande).

Quant à GTC, s'il existait...

Évidemment que ça ne marche que avec OPTIMIZE_ROM_CALLS

Donc que avec TIGCC.

cje trouve d'assez mauvais goût de polluer un programme avec des #ifdef alors que la variable testée est obligatoirement définie (soit plus haut dans le même fichier, soit en ligne de commande).

#include <tigcclib.h> fait un #undef (justement pour qu'on puisse détecter que le compilo l'a enlevé).
Et ne me dis pas que c'est sale, TIGCC lui-même fait comme ça pour _GENERIC_ARCHIVE.

Pollux
:

Évidemment que ça ne marche que avec OPTIMIZE_ROM_CALLS

Donc que avec TIGCC.

Si ton compilateur ne supporte pas OPTIMIZE_ROM_CALLS, c'est ton problème. Les programmes ont le droit de s'attendre à ce que ça fonctionne. Par exemple en utilisant a5 dans leur assembleur inline.

cje trouve d'assez mauvais goût de polluer un programme avec des #ifdef alors que la variable testée est obligatoirement définie (soit plus haut dans le même fichier, soit en ligne de commande).

#include <tigcclib.h> fait un #undef (justement pour qu'on puisse détecter que le compilo l'a enlevé).

Il n'a pas le droit de faire ça. Ton header ne correspond pas à la documentation de notre header, donc tu as tort de lui donner le même nom.

#13 Kevin>ah ca veut dire ca callback.... j'avais vu mais je pensait pas que c'est ce que je faisait. mea coulpa.

Pollux>si j'ai bien compris, la solution que tu me donne est pour le programme, pas pour la librairie. Car mon prog est juste la pour tester la librairie. Ce sera donc a l'utilisateur de la lib de savoir ce qu'il fait...

Ton header ne correspond pas à la documentation de notre header, donc tu as tort de lui donner le même nom.

C'est pour avoir un minimum de modifications à faire quand on passe de TIGCC à GTC.
Toutes les fonctions marchent pareil avec le tigcclib.h de GTC. Je n'ai rien eu à changer de ce côté là quand j'ai porté Einstein.

Ben non, OPTIMIZE_ROM_CALLS ne suit pas la documentation (parce que ce n'est pas du tout supporté), et ne marche donc pas pareil.

Sauf que 80% des progs qui définissent OPTIMIZE_ROM_CALLS n'utilisent pas le registre a5, et ne le définissent que parce que TIGCC génère du code meilleur avec, akirs que ce n'est pas forcément le cas pour tous les autres compilos. Donc non, je trouve ça normal de le désactiver si le compilo juge ça meilleur. D'ailleurs OPTIMIZE_ROM_CALLS est plutôt destiné à optimiser, non? Alors je ne vois pas le problème si GTC le désactive parce qu'il y arrive mieux comme ça

Au fait, est-ce que -fomit-frame-pointer permet d'utiliser a6 pour faire ce qu'on veut (par exemple y mettre une variable globale) ?

Je pense (et je me demande même si GCC ne compile pas silencieusement même sans -fomit-frame-pointer ).

Enfin bon, les variables globales c'est pas bien (cela dit je suis d'accord que dans certains cas, c'est pour l'instant la seule solution efficace).

Oui ben je me vois mal me passer de variables globales dans foblub...
(remarque qu'à l'origine c'était du code que j'ai récupéré, et j'ai bien éliminé les deux tiers des variables globales... mais il en reste plein)

Oui pour un interpréteur c'est assez mal barré effectivement

Et de toutes façons un compilo intelligent devrait l'être assez pour mettre les variables globales qu'il veut dans des registres. Et ce n'est pas le boulot du programmeur de décider quelle variable doit aller dans quel registre, parce que
1) il ne peut faire ça que sur tout le programme, résultat code inefficace (cf OPTIMIZE_ROM_CALLS), et qui risque de planter dans certains cas, et :
2) la fréquence d'utilisation de chaque variable varie avec le temps, résultat on a vite fait de se retrouver avec des réglages qui étaient optimaux dans une vieille version mais qui ne le sont plus du tout dans la dernière version.

Sally
: Au fait, est-ce que -fomit-frame-pointer permet d'utiliser a6 pour faire ce qu'on veut (par exemple y mettre une variable globale) ?

Non. En pratique, la réponse est souvent "oui", mais pas toujours! Il y a des cas où le "frame pointer" ne peut pas être éliminé, donc il est fortement déconseillé d'utiliser a6 pour autre chose.

Pollux > Oui, mais quand tu compiles en plusieurs fichiers objets, tu n'aurais pour tous sauf un qu'une déclaration extern... donc si le compilateur peut décider suivant les fichiers de ne pas mettre les mêmes variables dans des registres, ça signifie qu'à chaque fois que l'un d'eux appelle une fonction d'un autre il faut préalablement qu'il copie la variable en mémoire, et que la fonction appelée doit aller chercher celles qu'elle veut, elle, mettre dans des registres ?
Bon, évidemment, le problème ne se pose que pour les vraies variables globales, pas pour les "static".

Vu que GTools Compiler ne gère pas la compilation séparée (beurk!), Pollux ne s'est apparemment jamais posé cette question...
Pollux est le spécialiste des extensions mal réfléchies et complètement inadaptables à un compilateur qui n'a pas la même structure interne que le sien, ce qui risque de lui retomber dessus quand il voudra modifier cette structure interne.

Jalousie...