TIGCC 0.95 Beta 8 - Page 3

Moué.... bon ok, je le publierai sous licence BSD (et je giclerai le code PedRom quand j'aurai le
temps). En attendant, pour la prchaine beta de TIGCC, faudrait que je commence l'export
.??u. Et puis je vais essayer de compiler TIGCC avec Interix pendant que j'y suis.

Pourquoi compiler avec Interix? Win32/MinGW ne te va pas?

C'est juste pour déconner...
Quoique A68k pèse 3 Ko de moins après compilation sous Interix...
soit environ 5% de moins qu'avec MinGW, qui pourtant utilise la même version de GCC...
C'est parceque ça exploite le format PE Posix (MinGW compile en PE Windows)

je me demande si j'ai pas trouvé un bug (), et c'est la 2e fois que ça m'arrive
quand je fais F9 comme d'hab pour assembler mon programme, il me trouve pas moins de 510erreurs et je trouve que ça fait un peu beaucoup, sachant que je n'ai modifié que 2-3 lignes de codes depuis le précédent assemblage.
entre autres, j'ai pass 1/ pass 2 phase error, des duplicate symbols pour tous mes labels (), des undefined symbols pour tous mes labels locaux, des relocatability error pour tous les bsr, ...

j'avais déjà eu un truc de ce genre, et dans les 2 cas j'avais fermé tigcc sans avoir assemblé mon projet (et j'avais eu la demande d'enregistrement pour les fichiers non enregistrés)

tu as plus de 32k lignes de code ?

Comme dit Sebastian dans ces cas: 3 words: "Send The Source". Je ne peux rien faire sans la source exacte qui est à l'origine du problème.

À moins que ce ne soit une erreur d'utilisateur connue: Ton programme dépasserait-il par hasard les 32767 lignes après expansion des includes et macros?

une erreur d'utilisateur connue

Ce n'est pas parce qu'elle est connue que c une erreur d'utilisateur... Et je t'ai dit comment le corriger, alors bon

je pense pas, assemblé il fait 8ko.

mail envoyé

OK, merci. C'est un problème dans ton code. Faute de frappe à la ligne 369 de hex_3.h. Les 2 points à la fin sont en trop. Si je supprime ces 2 points, tout marche.

c'est moi qui avait fumé

ça n'a rien à voir, mais serait-il possible que quand il y a un "unresolved reference" à un label qui n'existe pas, on aille directement à la référence quand on clique sur l'erreur ? pour l'instant on va au fichier principal

Pollux
:

une erreur d'utilisateur connue

Ce n'est pas parce qu'elle est connue que c une erreur d'utilisateur...

Si, parce que:
* la restriction est documentée et l'a toujours été.
* TIGCC supportant la compilation séparée, il n'y a aucune raison de tout inclure dans le même fichier. À mort les include de fichiers contenant du code!

Et je t'ai dit comment le corriger, alors bon

Je vais voir pour une version future.

Flanker
: ça n'a rien à voir, mais serait-il possible que quand il y a un "unresolved reference" à un label qui n'existe pas, on aille directement à la référence quand on clique sur l'erreur ? pour l'instant on va au fichier principal

Le problème est que l'erreur n'est détectée qu'en temps de linking. Je peux voir si on peut faire quelque chose. Avec l'ancien système (TIGCC 0.94), on ne pouvait rien faire, mais le linker de TIGCC 0.95 arrive bien à identifier le fichier objet fautif, donc on devrait pouvoir faire quelque chose.

Ben non, en fait, on ne peut pas faire mieux qu'aller au fichier principal: Le linker ne donne que le fichier objet fautif. Ceci permet au mieux d'aller vers le fichier de source principal correspondant à ce fichier objet (ce qui est déjà fait). Or, tu inclus tout dans le fichier source principal, donc le résultat est celui-ci. Désolé.

Pour faire mieux, il nous faut fichier source et numéro de ligne. Pour ceci, il faudrait:
1. que le linker gère les informations de débogage (ce qui n'est pas encore le cas) et
2. utiliser un assembleur qui gère les informations de débogage, donc l'assembleur GNU.

En attendant, avec la solution actuelle, le mieux que tu peux faire est utiliser la compilation séparée pour que tu ais au moins le bon fichier.

Kevin Kofler
:

Pollux
:

une erreur d'utilisateur connue

Ce n'est pas parce qu'elle est connue que c une erreur d'utilisateur...

Si, parce que:
* la restriction est documentée et l'a toujours été.
* TIGCC supportant la compilation séparée, il n'y a aucune raison de tout inclure dans le même fichier. À mort les include de fichiers contenant du code!

Ha tiens, je note ces deux points-là pour te les ressortir en temps utile, tu vas t'étonner de la portée de ce que tu as dit là

À mort les citations hors-contexte aussi...

T'inquiète, même avec le contexte ça marche très bien

eh eh eh...

Bon alors deux remarques sur tigcc tout fraichement installé (je sais meme pas vraiment pourquoi je l'ai installé mais bon, passons.)

Alors :

1 -> Putain mais on s'en bas les c****s de cette connerie de truc a commentaire de m***e au moment ou l'on creer le fichier. Si vous voulez le laisser cette chose, replacez au moins le wizard et/ou mettez une option pour virer cette chose c'est immonde et personne ne l'utilise !!

2 -> Vive la gestion des fichiers de tigcc-ide..

File -> New -> C file

la il highlight le nouveau fichier pour lui changer le nom

je met main.c et resultat j'ai un main.c.c #trigol#

Et pour le 2 ça le fait depuis des lustres avec cet ide et c'est plus chiant cette "feature"

2 -> Vive la gestion des fichiers de tigcc-ide..

File -> New -> C file

la il highlight le nouveau fichier pour lui changer le nom

je met main.c et resultat j'ai un main.c.c #trigol#

Et pour le 2 ça le fait depuis des lustres avec cet ide et c'est plus chiant cette "feature"

Ben tape 'main'...
A noter que ça te fait 2 caractères en moins à écrire,
et ce feature () n'est pénalisant que si tu as décidé d'appeler
tes sources avec une autre extension genre main.godzil,
et dans ce cas-là de toute manière il te faudra un coup
de switch -x, et c'est parfaitement débile.

1 -> Putain mais on s'en bas les c****s de cette connerie de truc a commentaire de m***e au moment ou l'on creer le fichier. Si vous voulez le laisser cette chose, replacez au moins le wizard et/ou mettez une option pour virer cette chose c'est immonde et personne ne l'utilise !!

Là par contre je suis d'accord...
J'aimerais bien voir revenir le wizard de TIGCC 0.94...

Et j'ai une autre réclamation à faire:
La Beta 7, bien qu'elle ne documente pas --falsh-os de ld-tigcc,
avait au moins la possibilité de l'utiliser dans les options du programme
(Sur le même écran que le type d'export: .??z, exepack .??y, etc...)

Cela a disparu dans la Beta 8....
Sans pour autant être incompatible avec les projets de la Beta 7
utilisant l'option de l'IDE (comme Pyrix).

Cela oblige l'utilisateur voulant exporter en TIB à compiler à la main
avec ld-tigcc en version binaire ou bien à mettre au début du fichier C principal
un 'asm(".xdef _flash_os");' bien moche...

Autres belle m*rde avec la 0.95, les options

T1 mais c'est quoi ces fenetres de merde ? on dirait qu'elle a été prévue pour un ecran en 320x240 !!

En plus question documentation "interne" c'est suepr bien recherché !!



Et n'obligez pas put1 toutes ces options de bases.... mettez au moins :

1-> Un wizard avec options poru choisir ce qu'on veux faire

2-> une possibilité pour ne pas utiliser cette m*rde par défaut


Billy: non dsl, mais je n'apelle pas ça une feature non, detecter si le nom du fichier termine par .c est le minimum a faire, et ne pas lui rajouter un .c si il fini deja par .c

*Billy: non dsl, mais je n'apelle pas ça une feature non, detecter si le nom du fichier termine par .c est le minimum a faire, et ne pas lui rajouter un .c si il fini deja par .c *
Ben oué mais si on veut des trucs comme ça on peut en trouver des tonnes
dans un IDE... C'est pas la priorité, vaut mieux que les 2 choses dont
tu parle soit appliquées d'abord, c'est le plus important...

Donc:

Et n'obligez pas put1 toutes ces options de bases.... mettez au moins :

1-> Un wizard avec options poru choisir ce qu'on veux faire

2-> une possibilité pour ne pas utiliser cette m*rde par défaut

3 -> une meilleur doc sur les options pas juste un tooltip avec le nom du #define

Ligne de commande powa !

Godzil> Arrête de t'exciter... Tu pourrais respecter un peu le boulot des autres même s'il ne te plaît pas...

yep je te trouve un peu hard aussi

moi je dis que PpHd a raison. En fait plustôt makefile powa

c'est sûr que le make de tigcc a tendace à recompiler un peu n'importe quoi dès qu'on touche à un header (exemple: je modifie un header C et ça recompile aussi les fichiers asm , y'a sûrement une très bonne raison mais j'avoue que ça me dépasse un peu)

il fait pas la différence entre les headers c et asm donc il recompile tout pour pallier à ça. (D'ailleurs, pkoi utiliser des .h pour de l'asm ? )