TIGCC suggestions - Page 4

GoldenCrystal :
pourquoi ne pas simplement remplacer tigcc par un gcc68k classique ?

Et pourquoi utiliser une bidouille préhistorique quand on peut utiliser une toolchain qui représente 5 ans de travail? Surtout quand la toolchain fonctionne très bien. Encore une "suggestion" inutilisable et inutile de GoldenCrystal.

Ton toolchain de 5 ans de travail il sux
A part le travail d'adaptation du début (que ce n'est pas toi qui a fait) il n'y a rien de bien là dedans

bon, un peu de calme, svp, qd même !

Bah perso nan...
Je trouve que le système du linker custom est une énorme régression ainsi que l'implémentation de la lib qui devient de plus en plus complexe à chaque nouvelle calculatrice

D'un autre côté, retomber à gcc68k serait bien régressif aussi ...
Mais on parle du make à la base

Et surtout en utilisant des outils custom et des extensions custom, ça ferme la porte à l'opérabilité avec les outils existants et/ou standards, bref du beau "embrace & extend" typique.

Et vous avez quoi comme alternative à proposer? GTC? C'est au moins aussi "custom" que TIGCC.
Nos outils "custom" sont sous GPL au moins (à part A68k qui n'est pas de nous).

et ?
ça se forke ?
soit

Sinon:

GoldenCrystal
: Je trouve que le système du linker custom est une énorme régression

Pourrais-tu être plus explicit et constructif? Pourquoi ld-tigcc ne te convient-il pas? Parce qu'il n'y a pas écrit "GNU" devant (sachant qu'il est quand-même sous GPL)? Ou parce qu'il lui manque une fonctionnalité concrète dont tu as besoin (laquelle)? Et ne trouves-tu pas que les fonctionnalités supplémentaires de ld-tigcc par rapport à GNU ld (optimisation des relogements, réagencement des sections, mise en commun des constantes tout en travaillant avec du COFF, importations globales, meilleure gestion des sections de taille impaire etc.) soient utiles?

ainsi que l'implémentation de la lib qui devient de plus en plus complexe à chaque nouvelle calculatrice

Hein? Les changements qu'on a effectués pour la Titanium:
* EXECUTE_IN_GHOST_SPACE gère les HW >=3 par un test du HW3Patch.
* dll.c gère HW_VERSION!=2 correctement.
* Hack +0x40000 pour les interruptions remplacé par du bclr/bset.b #2,0x600001.
* 0x600000 remplacé par 0xE00000 dans les calculs de ROM_base.
* CALCULATOR a été redéfini en mode kernel pour tenir compte de la décision unilatérale de PpHd de mettre CALCULATOR==-1 sur Titanium.
Rien de cela ne rend la lib "plus complexe".

nitro
: Et surtout en utilisant des outils custom et des extensions custom, ça ferme la porte à l'opérabilité avec les outils existants et/ou standards, bref du beau "embrace & extend" typique.

Hein? Lesquels? make (la question d'origine) marche très bien avec l'exécutable tigcc.

Kevin Kofler
:

nitro
: Et surtout en utilisant des outils custom et des extensions custom, ça ferme la porte à l'opérabilité avec les outils existants et/ou standards, bref du beau "embrace & extend" typique.

Hein? Lesquels? make (la question d'origine) marche très bien avec l'exécutable tigcc.

Non je parle surtout du "C" qui n'est plus vraiment du C (constantes en binaire par exemple, et autres extensions GNU et ex-GNU) donc les compilateurs C standards pour compiler des sources écrites avec TIGCC doivent être modifiés, du format "COFF" qui n'est plus non plus du COFF, du coup les outils d'analyse sur les .o ne marchent plus, les débuggeurs non plus (cassé TI-GDB), les linkers des autres compilos 68k/COFF ne peuvent plus utiliser les .o de TIGCC.

Kevin Kofler :
Sinon:

GoldenCrystal
: Je trouve que le système du linker custom est une énorme régression

Pourrais-tu être plus explicit et constructif? Pourquoi ld-tigcc ne te convient-il pas? Parce qu'il n'y a pas écrit "GNU" devant (sachant qu'il est quand-même sous GPL)? Ou parce qu'il lui manque une fonctionnalité concrète dont tu as besoin (laquelle)? Et ne trouves-tu pas que les fonctionnalités supplémentaires de ld-tigcc par rapport à GNU ld (optimisation des relogements, réagencement des sections, mise en commun des constantes tout en travaillant avec du COFF, importations globales, meilleure gestion des sections de taille impaire etc.) soient utiles?

ld-tigcc ne me convient pas parce que c'est un outil non standard, parce qu'il utilise des symbboles pour dfinir son fonctionnement, parce que c'est une dll, parce qu'il traffique le code, parce qu'il ne génère rien si tu ne définis pas de symbole _ti*** ou _v200, parce que tu n'as pas accès à un stub standard en asm sans définir des symboles au nom immonde... etc...

ainsi que l'implémentation de la lib qui devient de plus en plus complexe à chaque nouvelle calculatrice

Hein? Les changements qu'on a effectués pour la Titanium:
* EXECUTE_IN_GHOST_SPACE gère les HW >=3 par un test du HW3Patch.
* dll.c gère HW_VERSION!=2 correctement.
* Hack +0x40000 pour les interruptions remplacé par du bclr/bset.b #2,0x600001.
* 0x600000 remplacé par 0xE00000 dans les calculs de ROM_base.
* CALCULATOR a été redéfini en mode kernel pour tenir compte de la décision unilatérale de PpHd de mettre CALCULATOR==-1 sur Titanium. Rien de cela ne rend la lib "plus complexe".

3 - Une macro n'est pas la bonne solution.

nitro
: Et surtout en utilisant des outils custom et des extensions custom, ça ferme la porte à l'opérabilité avec les outils existants et/ou standards, bref du beau "embrace & extend" typique.

Hein? Lesquels? make (la question d'origine) marche très bien avec l'exécutable tigcc.

ça s'adresse pas à moi, mais -> l'éxécutable tigcc n'est pas standard.

nitro
: Non je parle surtout du "C" qui n'est plus vraiment du C (constantes en binaire par exemple, et autres extensions GNU et ex-GNU)

Et en quoi GCC est-il différent?
Et TIGCC n'est pas le seul compilateur qui accepte les 0b..., TCC les accepte aussi (http://fabrice.bellard.free.fr/tcc/tcc-doc.html#SEC9).

du format "COFF" qui n'est plus non plus du COFF, du coup les outils d'analyse sur les .o ne marchent plus, les débuggeurs non plus (cassé TI-GDB), les linkers des autres compilos 68k/COFF ne peuvent plus utiliser les .o de TIGCC.

L'utilisation des extensions TIGCC peut être désactivée:
* ne pas utiliser le mode all-relocs (ne pas passer --cut-ranges suffit)
* ne pas utiliser -freg-relative-an (qui a besoin des relogements négatifs - le fonctionnement des versions précédentes était un hack)
* -fno-merge-constants

GoldenCrystal
: ld-tigcc ne me convient pas parce que c'est un outil non standard,

Bon, c'est comme je disais alors: "parce qu'il n'y a pas écrit 'GNU' devant". C'est malin... Newsflash: GTC n'a pas non plus écrit "GNU" devant, c'est aussi un "outil non standard". Et pourtant tu me sembles bien être de son côté (même remarque pour nitro, d'ailleurs).

parce qu'il utilise des symbboles pour dfinir son fonctionnement,

Où est le problème?

parce que c'est une dll,

Pas seulement. Il peut être compilé en exécutable aussi.

parce qu'il traffique le code,

That's not a bug, it's a feature. Et c'est complètement optionnel et désactivable!

parce qu'il ne génère rien si tu ne définis pas de symbole _ti*** ou _v200,

Les linkers précédents faisaient de même.

parce que tu n'as pas accès à un stub standard en asm sans définir des symboles au nom immonde...

C'est quoi un "stub standard" selon toi?

3 - Une macro n'est pas la bonne solution.

"pas la bonne solution" pour quoi et pourquoi?

ça s'adresse pas à moi, mais -> l'éxécutable tigcc n'est pas standard.

Il est compatible avec gcc du point de vue de l'invocation.

Kevin Kofler
:

nitro
: Non je parle surtout du "C" qui n'est plus vraiment du C (constantes en binaire par exemple, et autres extensions GNU et ex-GNU)

Et en quoi GCC est-il différent?

Il n'est pas différent, mais c'est moins génant car les extensions sont en voie de disparition, et un grand nombre de programmes (surtout ceux qui sont multiplateforme) ne les utilise pas. Néanmoins c'est bien embêtant car les compilateurs qui veulent être compatibles avec les programmes qui utilisent ces extensions (ICC par exemple) sont obligés d'accepter ce dialecte de C.

Et TIGCC n'est pas le seul compilateur qui accepte les 0b..., TCC les accepte aussi

Ah, si TCC les accepte alors, ça change tout.

L'utilisation des extensions TIGCC peut être désactivée:
* ne pas utiliser le mode all-relocs (ne pas passer --cut-ranges suffit)
* ne pas utiliser -freg-relative-an (qui a besoin des relogements négatifs - le fonctionnement des versions précédentes était un hack)
* -fno-merge-constants

Ok donc on se retrouve avec du code de merde.
Et est-ce le cas pour toutes les libs statiques dans la nature ?

Bon, c'est comme je disais alors: "parce qu'il n'y a pas écrit 'GNU' devant". C'est malin... Newsflash: GTC n'a pas non plus écrit "GNU" devant, c'est aussi un "outil non standard". Et pourtant tu me sembles bien être de son côté (même remarque pour nitro, d'ailleurs).

GTC justement est un exemple de compilateur qui doit se plier à vos extensions si il veut pouvoir compiler les sources disponibles actuellement, et ça complique pas mal les choses.

[HS]
topics/42464-tigcc-suggestions/3#77
Et moi, comme un con, j'ai fait "man steack", pensant qu'il y avait une fonction que je ne connaissais pas
[/HS]

Je me traine des bugs de l'IDE de ya 50 ans

ce sont des bugs connus et documentés
=> ce sont des features
cqfd

nitro
: Il n'est pas différent, mais c'est moins génant car les extensions sont en voie de disparition,

1. Pas toutes.
2. Justement, je conçois ça comme une grave erreur de retirer à GCC ses avantages importants sur les autres compilateurs.
3. Est-ce vraiment en l'intérêt de la FSF de permettre de compiler les sources écrites pour GCC avec des compilateurs non-libres? Je ne crois pas. Tout ce que ça apporte, c'est de permettre la migration de GCC vers les compilateurs non-libres, bref ça encourage l'utilisation de logiciels non-libres.

et un grand nombre de programmes (surtout ceux qui sont multiplateforme) ne les utilise pas.

TIGCC est multi-plateforme et nous utilisons pas mal d'extensions de GCC.

Néanmoins c'est bien embêtant car les compilateurs qui veulent être compatibles avec les programmes qui utilisent ces extensions (ICC par exemple) sont obligés d'accepter ce dialecte de C.

Tant pis pour eux. Cf. mon "3." ci-dessus.

Ah, si TCC les accepte alors, ça change tout.

Bah, ça veut dire que ce n'est pas aussi bizarre que ça comme idée.

L'utilisation des extensions TIGCC peut être désactivée:
* ne pas utiliser le mode all-relocs (ne pas passer --cut-ranges suffit)
* ne pas utiliser -freg-relative-an (qui a besoin des relogements négatifs - le fonctionnement des versions précédentes était un hack)
* -fno-merge-constants

Ok donc on se retrouve avec du code de merde.

1. Pas plus "de merde" qu'avant.
2. D'où l'ajout de ces extensions.

Et est-ce le cas pour toutes les libs statiques dans la nature ?

Les libraries statiques closed source ne sont pas notre problème.

en même temps, quand tu apprend à programmer sous GCC, et que, ensuite, tu te retrouve sur un compilateur qui n'a pas les extensions GNU, tu perds pas mal de temps à prendre des habitudes de codage ANSI...
et pour ce qui est des softs libres... j'en ai pas regardé bcp de sources... Bash est pas codé en C K&R, encore ? (m'a semblé qd j'ai survolé les sources l'année dernière... mais j'ai pas trop cherché en fait ; me trompe peut-être)

Kevin Kofler
: Est-ce vraiment en l'intérêt de la FSF de permettre de compiler les sources écrites pour GCC avec des compilateurs non-libres? Je ne crois pas. Tout ce que ça apporte, c'est de permettre la migration de GCC vers les compilateurs non-libres, bref ça encourage l'utilisation de logiciels non-libres.

Donc c'est ce que je disais, "embrace & extend", doublé d'une belle mentalité de merde.
Tu remplaces "compilateurs non-libres" par "compilateurs libres alternatifs", et on comprend mieux pourquoi on se traine encore avec gcc.

squale92 :
et pour ce qui est des softs libres... j'en ai pas regardé bcp de sources... Bash est pas codé en C K&R, encore ? (m'a semblé qd j'ai survolé les sources l'année dernière... mais j'ai pas trop cherché en fait ; me trompe peut-être)

La plupart des vieux logiciels libres sont en vieux C, et la plupart des nouveaux logiciels libres sont en C++ ou en langage de script.

Nitro, tu n'as pas répondu à une grande partie de mon message. C'est fait exprès parce que tu ne sais plus quoi répondre?
GoldenCrystal, tu n'as pas répondu du tout. C'est fait exprès parce que tu ne sais plus quoi répondre?

(c'est peut-être qu'ils ne vivent pas pour ça ou qu'ils sont lassés ?)

>Bash est pas codé en C K&R, encore ? (m'a semblé qd j'ai survolé les sources l'année dernière... mais j'ai pas trop cherché en fait ; me trompe peut-être)
>La plupart des vieux logiciels libres sont en vieux C, et la plupart des nouveaux logiciels libres sont en C++ ou en langage de script.
Le standard de la FSF est le C-89 : tous ses programmes doivent etre compilees avec un compilateur C89, MAIS il faut que l'outil ansi2knr fonctionne
donc il faut aussi rajouter du code de gestion K&R pour les fonctions a arguments variables.
Bref le minimum de la FSF est le C K&R.
Avec la condition que sizeof(long) >= sizeof(void*), et int au moins 32 bits.

Nil
: (c'est peut-être qu'ils ne vivent pas pour ça ou qu'ils sont lassés ?)

Ah, tiens... Et pourtant, dès que je ne réponds pas à quelque chose, c'est le scandale. Il faudrait peut-être arrêter d'avoir 2 mesures différentes pour tout...

(oui pour nitro qui n'a pas répondu à tout, mais golden n'est même pas passé ici, alors pourquoi lui en vouloir, vu que si ça se trouve il n'a même pas lu ton post :[)

Kevin Kofler :
Nitro, tu n'as pas répondu à une grande partie de mon message. C'est fait exprès parce que tu ne sais plus quoi répondre? GoldenCrystal, tu n'as pas répondu du tout. C'est fait exprès parce que tu ne sais plus quoi répondre?

Tu fais ça tout le temps, et tu t'énerves quand on te rappelle que tu as évité la question, alors ne va pas faire la même chose avec eux... "Il faudrait peut-être arrêter d'avoir 2 mesures différentes pour tout"...

Demande à Sebastian.