Pb de compilation - Page 1

J'ai dl récemment preos sur mon pc, car je pensais y trouver un a68k.exe.
J'en ai pas vu, alors j'ai pris celui de tigcc, et j'ai fait un fichier.bat de la forme :

a68k abc.asm
makeprgm abc

Deux questions :
1° A quoi servent les paramètres -g -t que j'ai parfois vu dans des compilateurs ???
2° Pourquoi quand je lance ce fichier, le compilateur m'affiche en dessous de xdef _ti89 le message : unknown character ou invalid character, un truc du genre.

Merci !!!!!!!

1. Tiré de la doc de tigcc partie a68k

-g 
  Causes any undefined symbols to be treated as if they were externally defined (XREF), rather than being flagged as errors.

-t 
  Allows tabs in the source file to be passed through to the listing file, rather than being expanded. In addition, tabs will be generated in the listing file to skip from the object code to the source statement, etc. This can greatly reduce the size of the listing file, as well as making it quicker to produce. Do not use this option if you will be displaying or listing the list file on a device which does not assume a tab stop at every 8th position. 

2. .include "os.h" ?

1-> lol ça veut dire que fo que je mette -g -t vu que j'ai des tabs dans mon source, et que le compilo me fait des undefined symbols


2->non g un include tios.h et un userlib.h


Au fait dsl g mêmepas pensé à regarder la doc dsl

et puis pkoi include os.h vu que g pas vu de header os dans preos ?????

c'est dans les libs de tigcc
lis un peu l'aide de tigcc ça ne te fera pas de mal

Utilise aussi l'IDE de tigcc ça facilite la vie.

même pour coder en asm ????????????

Et puis chui habitué au bloc note et à la simplicité, je comprends pas grand chose à la fenêtre de gauche de leur IDE. Je pense rester au bloc notes.
Quand à l'aide de TIGCC, promis je vais aller jeter un coup d'oeil !!!!!!!!!!!!!!

même pour coder en asm ????????????

Tu peux avec TIGCC même en GNU A68K.

Et puis chui habitué au bloc note et à la simplicité, je comprends pas grand chose à la fenêtre de gauche de leur IDE. Je pense rester au bloc notes.

Avec ça coloration syntaxique... TIGCC est 100% mieux, en plus de ça pas besoin de ce casser la tête pour compiler et tester un programme.

ok merci je vais essayer.
En fait je m'étais pas intéressé à TIGCC parce que je pensais que ça ne compilait que du C, que la coloration syntaxique ne s'appliquait qu'au c, etc.
Merci bien ud conseil, je vais tester et je te donnerai des nouvelles. Personnellement, c'est ce que tu utilises ?????????

Bas au départ, j'utilisait le bloc note mais franchement ça donne pas envie de programmer surtout que tu te casse la tête pour compiler... Y a rien de mieux pour que tu soit déçu si tu débute.

Mais réellement TIGCC est vraiment bien et surtout pour l'aide, la coloration syntaxique qui t'aide à relire ton code très facilement et la compialtion très très facile et peformante.

J'utilise TIGCC et j'en suis très content.

OK.
Et le débuggueur de VTI, est-ce qu'il estbien ou pas???
J'ai vu ce matin qu'il y en avait un.

Le débuggueur de VTi est très bien mais malheuresement VTI n'a pas était mis à jours depuis très longtemps ce qu'il fait qu'il émule pas à 100% une calculatrice et surtout que le débuggeur ne fonctionne pas avec les programmes nostub...

ok, c'est domma ge paske il y a du avoir plein de nouvelles ROM depuis.
Quand à moi, je programme avec un kernel

le debugguer, deja, faut la version de VTI modifiée par JM, pour qu'il marche avec les ROM2.0x il me semble

geogeo :
Le débuggueur de VTi est très bien

jusque là ça va

mais malheuresement VTI n'a pas était mis à jours depuis très longtemps ce qu'il fait qu'il émule pas à 100% une calculatrice

mais pour l'utilisateur moyen ça change rien, c'est très largement suffisant pour développer un prog

et surtout que le débuggeur ne fonctionne pas avec les programmes nostub...

Ca c'est carrément n'importe qui.

Quand à moi, je programme avec un kernel

Tu sais il st aussi possible de programmer en nostub en ASM. Le seul inconvénient du nostub en ASM c'est qu'on ne peux accéder facilement au ROM_CALLS et on est obliger de coder beaucoup de choses.

Ce post n'a pas pour but de te faire changer mais juste pour te dire de réfléchir avant de coder et prendre le meilleur fomat suivant ton programme.

Ca c'est carrément n'importe qui.

Ce que je dis n'est pas faux à 100%, d'ailleurs le debuggeur ne reconnais pas aussi certain programme kernel.

mais pour l'utilisateur moyen ça change rien, c'est très largement suffisant pour développer un prog

Bien entendus, mais ce que je veux dire par là c'est que certaine interruption ne sont pas émulé correctement sur VTI, donc un programme peut fonctionner parfaitement sur VTI est bien planter sur Real-TI.

Le seul inconvénient du nostub en ASM c'est qu'on ne peux accéder facilement au ROM_CALLS et on est obliger de coder beaucoup de choses.

c surtout qu'on n'a pas acces aux librairies kernels qui aident pas mal, surtout en prog on-calc
(la prog asm on-calc etant bcp plus réaliste à me syeux que la prog c on calc)

geogeo
:

Quand à moi, je programme avec un kernel

Tu sais il st aussi possible de programmer en nostub en ASM. Le seul inconvénient du nostub en ASM c'est qu'on ne peux accéder facilement au ROM_CALLS et on est obliger de coder beaucoup de choses.

Pour plus d'informations, cf. http://members.chello.at/gerhard.kofler/kevin/ti89prog/asmnstbf.htm.
Et l'accès aux ROM_CALLs n'est pas si difficile que ça.

En kernel, l'accès aux ROM_CALLs se fait comment ?

En kernel:
jsr _ROM_CALL_123

En _nostub:
ROM_CALL $123
(mais ce n'est pas la solution la plus optimisée, cf. le lien du message n°18).

Comment ça marche en kernel ?
Au lancement, le kernel fait des relogements et écrit la bonne adresse ?
Si c'est ça, c'est bien mieux qu'en _nostub !
Et puis l'exemple que tu donnes est une macro, je suppose, il faudrait avoir le code réel pour comparer objectivement

geogeo :
Bas au départ, j'utilisait le bloc note mais franchement ça donne pas envie de programmer surtout que tu te casse la tête pour compiler... Y a rien de mieux pour que tu soit déçu si tu débute.

Mais réellement TIGCC est vraiment bien et surtout pour l'aide, la coloration syntaxique qui t'aide à relire ton code très facilement et la compialtion très très facile et peformante.
J'utilise TIGCC et j'en suis très content.

Je suis pas d'accord avec toi. Moi je ne programme qu'avec le bloc note et je n'ai jamais eu a m'en plaindre. Je n'aime pas l'IDE de tigcc et je ne l'utilise pas. Un des gros avantage du bloc note c'est qu'il est léger. Et puis la compilation est très facil, il suffit juste d'un batch et c partie. Moi personnelement c'est comme cela que j'opere depuis que je programmes en asm sur ti. Donc c'est tout a fait faisable.

Mais bon, je pense que nous avons tous notre methode pour programmer tranquillement. Le tout est de la trouver.

jackiechan :
Comment ça marche en kernel ? Au lancement, le kernel fait des relogements et écrit la bonne adresse ?

OK, je pense que j'ai trouvé la réponse à ma question en lisant la doc de PreOS, pour ceux que ça intéresse :

The next part of the kernel header is a dynamic variable part.
It is always composed of 4 linked sections :
+ Libraries import table : list of the used libraries and some info about the relocation process.
+ RomCalls import table.
+ RamCalls import table (Kernel variables and functions).
+ Program's Relocation table : a kernel program do not use EX_patch.
[...]
SECTION 2 Import table of the RomCalls.
IsRomCall 2 0 if there is no RomCall, otherwise 1.
NumRomCall 2 Number of used RomCalls minus 1.
????? Number of RomCalls times:
+ 1 word : Number of the used RomCall. + A reloc table.

EagleLIONHEART
: Et puis la compilation est très facil, il suffit juste d'un batch et c partie.

Mais avec l'IDE il suffit d'un clic. c'est quand même plus simple. Et on peut envoyer directement le prog à VTI.
Je ne comprends pas qu'on puisse préférer une autre méthode.

jackiechan
: Je ne comprends pas qu'on puisse préférer une autre méthode.

je ne te demande pas de comprendre....Surtout que c en'est pas spécialement à toi que je parlais. Et puis j'ai deja dit pourquoi je n'utilisais pas l'IDE de tigcc, je ne l'aime pas. Deja graphiquement beurk, mais y'a aussi le fait que bin je prefere ne pas utiliser l'IDE. Et puis je v te dire, c po un click en plus et un glisser-deposer qui tue...

Tiens au fait, nounoun, il y a un a68k dans la version 0.67 de PreOs en tout cas

jackiechan :
Comment ça marche en kernel ? Au lancement, le kernel fait des relogements et écrit la bonne adresse ?

Oui.

Si c'est ça, c'est bien mieux qu'en _nostub !

Pas vraiment. L'entrée dans la table de relogements prend aussi de la place. C'est 6 octets en OPTIMIZE_ROM_CALLS contre 8 (ou 12 pour le premier appel) en kernel.
Mais si tu veux absolument le système de relogements, tu pourras aussi l'avoir sans kernel avec TIGCC 0.95.

Et puis l'exemple que tu donnes est une macro, je suppose, il faudrait avoir le code réel pour comparer objectivement

Sauf que je parlais de la facilité de programmation, pas de la qualité du code produit.

jackiechan
: Tiens au fait, nounoun, il y a un a68k dans la version 0.67 de PreOs en tout cas

La version livrée avec TIGCC est souvent plus récente. (Mais actuellement, c'est la même. La plus récente se trouve actuellement là, en attendant TIGCC 0.95 bêta 1.)

Kevin Kofler :
Pas vraiment. L'entrée dans la table de relogements prend aussi de la place. C'est 6 octets en OPTIMIZE_ROM_CALLS contre 8 (ou 12 pour le premier appel) en kernel.

Ah oui, j'avais oublié ce détail.

Mais si tu veux absolument le système de relogements, tu pourras aussi l'avoir sans kernel avec TIGCC 0.95.

Quelque chose m'échappe alors. Comment se feront les relogements sans kernel ? Vous ne pouvez pas utiliser EX_PAtch pour ça je pense.

Sauf que je parlais de la facilité de programmation, pas de la qualité du code produit.

OK, autant pour moi