comment on appeller un programme externe en c ? - Page 4

matthieu
: d'ailleurs g une question, y'a t-il un moyen de supprimer la restauration automatique de l'ecran que force tigcc?

#undef SAVE_SCREEN ou alors (plus propre) tu décoches la case dans les options du projet (Project / Options / Compilation / Program Options).

hibOu
:

matthieu :
euh Mr kofler, vous pourriez m'expliquer pkoa tigcc ne reconnait pas cette fonction ?
short push_parse_text (const char *str);
alors qu'explicitement ds estack.h on trouve : #define push_parse_text ({__need_in_use_bit;_rom_call(short,(const char*),3CA);})

tu as deja eu ce genre de pb, et je t'ai deja donné la solution

hibOu
:

matthieu :
euh Mr kofler, ca fait dix minutes que j'essaie mais mon tigcc ne reconnais pas push_zstr bien qu'il figure ds la doc

dans la doc, il y a écrit :
AMS 1.01 or higher
Cela veut dire qu'il faut que tu déclares que tu utilisera un AMS au moins supérieur a la 1.01
=> faut mettre
#define MIN_AMS 101

Ça aussi, ça se règle dans les options du projet normalement.

Pour ton "invalid relocation data in ASM program": le code tel que je l'ai posté marche (j'ai vérifié), donc tu n'as pas dû essayer le code tel que je l'ai posté, mais tu as dû faire des modifications foireuses.

matthieu
: franchement le code que tu proposais Mr Kofler est 1000 fois + compliké

Mon code est plus compliqué parce que celui de limmt (et aussi celui de PpHd d'ailleurs) ne marche(nt) que si on a un programme anti-protection (h220xTSR ou HW2Patch) installé.

Bref, ce cas vérifie un pbm que j'ai cité :

Soit la doc doit etre revue de fond en comble, soit il faut que cette boite d'option CHANGE..

je te remercie kevin mais je te promet que je n'ai fait aucune modif a ton code , vraiment aucune et ca ne marche pas
mais juste un truc, je n'ai pas de H2Wpatch installé, je n'ai qu'une AMS 2.09 et j'ai testé sans preos ca marche aussi (enfin pas avec txtrider evidemment)

en tout cas y dechire ce forum ca se trouve je vais avoir mon bac grace a lui ( limmt et hibou en particulier !!!!!!!!)

matthieu
: je te remercie kevin mais je te promet que je n'ai fait aucune modif a ton code , vraiment aucune et ca ne marche pas

Il marche ici, donc quelque chose doit être foireux de ton côté. Peut-être que ta copie de TxtRider est foireuse.

mais juste un truc, je n'ai pas de H2Wpatch installé, je n'ai qu'une AMS 2.09 et j'ai testé sans preos ca marche aussi (enfin pas avec txtrider evidemment)

PreOs installe h220xTSR si ni l'un ni l'autre n'est installé.

non non, ce que je dis c'est que sans kernel, sans rien du tout cette fonction marche parfaitement! toutefois, kan je dis qu'elle marche, tout est relatif , y fô vraiment la manier avec precaution mais si on fait pas trop de connerie autour ca marche a merveille !!!

matthieu
: non non, ce que je dis c'est que sans kernel, sans rien du tout cette fonction marche parfaitement!

Elle marche parfois, mais pas toujours! Il y a une différence entre marcher une fois par hasard et marcher de manière fiable!

toutefois, kan je dis qu'elle marche, tout est relatif , y fô vraiment la manier avec precaution mais si on fait pas trop de connerie autour ca marche a merveille !!!

Ben exactement, donc elle ne marche pas vraiment, tu as juste eu de la chance quand tu as essayé.

Kevin Kofler
:

matthieu
: d'ailleurs g une question, y'a t-il un moyen de supprimer la restauration automatique de l'ecran que force tigcc?

#undef SAVE_SCREEN ou alors (plus propre) tu décoches la case dans les options du projet (Project / Options / Compilation / Program Options).

hibOu
:

matthieu :
euh Mr kofler, vous pourriez m'expliquer pkoa tigcc ne reconnait pas cette fonction ?
short push_parse_text (const char *str);
alors qu'explicitement ds estack.h on trouve : #define push_parse_text ({__need_in_use_bit;_rom_call(short,(const char*),3CA);})

tu as deja eu ce genre de pb, et je t'ai deja donné la solution

hibOu
:

matthieu :
euh Mr kofler, ca fait dix minutes que j'essaie mais mon tigcc ne reconnais pas push_zstr bien qu'il figure ds la doc

dans la doc, il y a écrit :
AMS 1.01 or higher
Cela veut dire qu'il faut que tu déclares que tu utilisera un AMS au moins supérieur a la 1.01
=> faut mettre
#define MIN_AMS 101

Ça aussi, ça se règle dans les options du projet normalement.

je pense qu'il faut plutot privilégier les define, car un programme qui compile sous l'IDE doit aussi compiler sans l'IDE.
Faudra que j'envoie un feedback la dessus... parce que je trouve ca chiant.

Non, les #define sont obsolètes et "deprecated". La raison est simple: ce sont des options globales, donc il faut que tous les fichiers soient compilés avec les mêmes options. Il y a eu des tas de problèmes causés par les options inconsistentes. Si tu utilises #define, ce ne sera souvent pas le cas. En ligne de commande, il faut utiliser le switch -D.

à la fois c'est dommage qu'on ne puisse pas générer des switches différents pour chaque fichier.

Ben, des options comme OPTIMIZE_ROM_CALLS n'ont un sens que si elles sont définis dans tous les fichiers: le code de démarrage (le fichier principal dans les versions obsolètes de TIGCC) doit initialiser %a5, et le registre doit être réservé dans tous les fichiers pour que GCC ne le modifie pas. Et puis quel intérêt d'utiliser les ROM_CALLs optimisés dans certains fichiers et pas dans d'autres? Si on a la table des sauts en %a5, autant l'utiliser plutôt que de faire un move inutile!

Kevin Kofler :
Non, les #define sont obsolètes et "deprecated". La raison est simple: ce sont des options globales, donc il faut que tous les fichiers soient compilés avec les mêmes options. Il y a eu des tas de problèmes causés par les options inconsistentes. Si tu utilises #define, ce ne sera souvent pas le cas. En ligne de commande, il faut utiliser le switch -D.

certes. Pour les newb, c'est p-e vrai.
- mais quelqu'un qui programme corretement, met toutes les définitions dans un header, et met des includes dans chaque fichier source.
- un define est beaucoup explicite qu'un -D dans les options de compilation.
- si tu veux passer un fichier source à quelqu'un d'autre, pour par exemple faire du logiciel libre, il faut aussi lui présiser les options : c'est chiant, car on y pense pas forcément.

bref, moi j'aime pas.

Exemple encore plus frappant: SAVE_SCREEN. Cette option n'affecte que le code de démarrage, alors quel sens a-t'il de définir cette option dans certains fichiers et pas dans d'autres?

je parlais de switches pas de defines en fait, my bad
de toutes c'est pas le sujet

Kevin Kofler :
Ben, des options comme OPTIMIZE_ROM_CALLS n'ont un sens que si elles sont définis dans tous les fichiers: le code de démarrage (le fichier principal dans les versions obsolètes de TIGCC) doit initialiser %a5, et le registre doit être réservé dans tous les fichiers pour que GCC ne le modifie pas. Et puis quel intérêt d'utiliser les ROM_CALLs optimisés dans certains fichiers et pas dans d'autres? Si on a la table des sauts en %a5, autant l'utiliser plutôt que de faire un move inutile!

Pour OPTIMIZE_ROM_CALLS, je dis pas, car c'est une option qui peut s'apparentée aux -O...
Mais un MIN_AMS, devrait être propre à un fichier, quitte a ce que le linker vérifie entre les fichiers.

Kevin Kofler :
Exemple encore plus frappant: SAVE_SCREEN. Cette option n'affecte que le code de démarrage, alors quel sens a-t'il de définir cette option dans certains fichiers et pas dans d'autres?

justement, il n'affecte que le fichier ou il y a le _main....

alors pourquoi les options sont globales ?

(edit|cross: je parlait au #103 bien sur ^^)

hibOu
:

Kevin Kofler :
Non, les #define sont obsolètes et "deprecated". La raison est simple: ce sont des options globales, donc il faut que tous les fichiers soient compilés avec les mêmes options. Il y a eu des tas de problèmes causés par les options inconsistentes. Si tu utilises #define, ce ne sera souvent pas le cas. En ligne de commande, il faut utiliser le switch -D.

certes. Pour les newb, c'est p-e vrai. - mais quelqu'un qui programme corretement, met toutes les définitions dans un header, et met des includes dans chaque fichier source.

C'est encore pire, cette idée! J'ai en effet vu souvent des options cachées dans un header dans des programmes livrés avec les sources et j'ai horreur de ça! Il faut que j'épluche tous les headers pour trouver celui qui contient les options.

- un define est beaucoup explicite qu'un -D dans les options de compilation.

Non. Un -D, il y a un endroit où il peut se trouver (qui dépend du type du projet: l'appel à tigcc en ligne de commande, les options du projet dans l'IDE). Un #define peut se trouver dans n'importe quel header ou fichier source. Si je reçois un projet fait par quelqu'un d'autre, je trouverai beaucoup plus vite les options si elles sont définies en ligne de commande ou dans les options du projet.

- si tu veux passer un fichier source à quelqu'un d'autre, pour par exemple faire du logiciel libre, il faut aussi lui présiser les options : c'est chiant, car on y pense pas forcément.

C'est à ça que sert le fichier .tpr! Ou le batch, shell script ou makefile en ligne de commande! Tu ne vas quand-même pas me dire que tu comptes taper tigcc --optimize-code --cut-ranges -Os -fomit-frame-pointer -fno-if-conversion -DMIN_AMS=100 -DSAVE_SCREEN -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -DUSE_FLINE_JUMPS monfichier1.c monfichier2.c monfichier3.c monfichier4.c monfichier5.c monfichier6.c monfichier7.c monfichier8.c monfichier9.c monfichier10.c monfichierasm1.s monfichierasm2.s monfichierasm3.s monfichierasm4.s monfichierasm5.s malib1.a malib2.a malib3.a -o monprog à la main à chaque fois?!

hibOu
:

Kevin Kofler :
Ben, des options comme OPTIMIZE_ROM_CALLS n'ont un sens que si elles sont définis dans tous les fichiers: le code de démarrage (le fichier principal dans les versions obsolètes de TIGCC) doit initialiser %a5, et le registre doit être réservé dans tous les fichiers pour que GCC ne le modifie pas. Et puis quel intérêt d'utiliser les ROM_CALLs optimisés dans certains fichiers et pas dans d'autres? Si on a la table des sauts en %a5, autant l'utiliser plutôt que de faire un move inutile!

Pour OPTIMIZE_ROM_CALLS, je dis pas, car c'est une option qui peut s'apparentée aux -O... Mais un MIN_AMS, devrait être propre à un fichier, quitte a ce que le linker vérifie entre les fichiers.

Non, MIN_AMS est une propriété du programme entier, pas par fichier:
1. La vérification est faite dans le code de démarrage.
2. Si TIGCCLIB sait que ton programme a de toute façon besoin de AMS 2, elle ne va pas se fatiguer à utiliser des hacks pour utiliser certaines fonctions exportées seulement dans AMS 2 aussi sous AMS 1, elle va utiliser les fonctions directement. Donc définir un MIN_AMS différent dans des fichiers différents conduirait à un programme plus inefficace sans que le programmeur s'en rende compte.

hibOu
:

Kevin Kofler :
Exemple encore plus frappant: SAVE_SCREEN. Cette option n'affecte que le code de démarrage, alors quel sens a-t'il de définir cette option dans certains fichiers et pas dans d'autres?

justement, il n'affecte que le fichier ou il y a le _main....

Totalement faux. Tu en es encore à TIGCC 0.94! Dans TIGCC 0.95, le code de démarrage ne correspond à aucun de tes fichier source (il est dans tigcc.a). L'option SAVE_SCREEN génère une importation qui dit au linker de rajouter le code de démarrage correspondant. Et cela même si c'est défini dans un module autre que le module principal. (Donc si on change d'avis et on ne veut plus que l'écran soit sauvegardé automatiquement, dès qu'on oublie de changer ou recompiler un fichier, c'est râté. Et encore, c'est une option où les inconsistences ont peu d'effets. Avec d'autres, c'est le plantage direct si elles sont définies de manière inconsistente.)

Godzil :
alors pourquoi les options sont globales ?
(edit|cross: je parlait au #103 bien sur ^^)

Parce que le code de démarrage est global au programme et ne correspond à aucun fichier particulier. Toi aussi, tu dois être resté bloqué au mode de pensée dépassé du système de linking obsolète de TIGCC 0.94.

Kevin Kofler :
C'est encore pire, cette idée! J'ai en effet vu souvent des options cachées dans un header dans des programmes livrés avec les sources et j'ai horreur de ça! Il faut que j'épluche tous les headers pour trouver celui qui contient les options.

je suis sûr que tu préfèreras mes headers a des makefile codés comme un porc.

Les batches / shell scripts, tu connais?
Il faut un batch / shell script d'une ligne pour compiler un programme avec TIGCC, et il peut être exécuté comme batch ou comme shell script indifféremment (marque tigcc et pas tigcc.exe et c'est bon).

Kevin Kofler :
Totalement faux. Tu en es encore à TIGCC 0.94! Dans TIGCC 0.95, le code de démarrage ne correspond à aucun de tes fichier source (il est dans tigcc.a). L'option SAVE_SCREEN génère une importation qui dit au linker de rajouter le code de démarrage correspondant. Et cela même si c'est défini dans un module autre que le module principal. (Donc si on change d'avis et on ne veut plus que l'écran soit sauvegardé automatiquement, dès qu'on oublie de changer ou recompiler un fichier, c'est râté. Et encore, c'est une option où les inconsistences ont peu d'effets. Avec d'autres, c'est le plantage direct si elles sont définies de manière inconsistente.)

c'est louche. C'est pas de la mauvaise foi, mais je vois franchement pas le rapport entre le code de démarrage et d'autres fonctions qui seraint dans un fichier où il n'y a pas de _main...

Et moi, je ne vois franchement pas pourquoi le fichier qui a la chance ou le malheur de contenir _main devrait être spécial par rapport à un code de démarrage qui n'est pas dans quel fichier que ce soit (de ton projet). Les importations globales du nouveau linker marchent de manière tout à fait naturelle dans n'importe quel fichier, et TIGCCLIB s'en sert à certains endroits. Le fichier qui contient _main n'a plus rien de spécial, il peut aussi être n'importe où dans le fichier linké (plus besoin de le mettre au début en _nostub). Seule la fonction _main elle-même est spéciale parce qu'elle est appelée par le code de démarrage, mais le fichier autour n'a absolument rien de spécial.

Kevin Kofler :
C'est à ça que sert le fichier .tpr! Ou le batch, shell script ou makefile en ligne de commande! Tu ne vas quand-même pas me dire que tu comptes taper tigcc --optimize-code --cut-ranges -Os -fomit-frame-pointer -fno-if-conversion -DMIN_AMS=100 -DSAVE_SCREEN -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -DUSE_FLINE_JUMPS monfichier1.c monfichier2.c monfichier3.c monfichier4.c monfichier5.c monfichier6.c monfichier7.c monfichier8.c monfichier9.c monfichier10.c monfichierasm1.s monfichierasm2.s monfichierasm3.s monfichierasm4.s monfichierasm5.s malib1.a malib2.a malib3.a -o monprog à la main à chaque fois?!

Et si vous faisiez une section [Shell] dans le .tpr, qui donne la ligne de commande à exécuter ? (mais qui ne serait pas parsée par l'IDE, juste écrite) Ca permettrait de passer facilement en ligne de commande si on en a besoin...

tprbuilder, c'est pour les chiens?

et y a un switch pour lui dire de donner la ligne de commande sans l'exécuter ?

Pour quoi faire? tprbuilder projet.tpr, ça ne te va pas comme ligne de commande?

non, mais gtc --import-tigcc "`tprbuilder --print-command projet.tpr`" m'irait

Fais toi-même le boulot de parsing.