Tigcclib - Page 6

Baaaa
le monopole de preos on peut arranger sa rapidemend

On prend preos (les sources bien sur) on change le nom, on met VarkOS (tiens sa fait ) a la place de "PreOS" et pouf ta un nouveau kernel

Uther Lightbringer
a écrit : 2. Tu as fait une enquète ?

Ce n'est pas à moi de faire une enquète, c'est à vous de venir demander les fonctionnalités qui vous intéressent. Pour MIN_KERNEL, personne n'a proposé ça sur notre forum (partie "TIGCC Programming") ou par mail à l'équipe. Et même ici, il n'y a eu que PpHd et toi pour le proposer. Et toute proposition devra être suffisamment détaillée pour expliquer ce que vous voulez exactement et comment vous voulez que ce soit implémenté.

Et si aucun programme n'utilise scanf c'est surtout qu'il n'est pas disponible depuis très longtemps mais je suis sur qu'il sera bientot utilisé(peut-etre par moi-meme).

Si tu es paresseux, il ne faut pas t'étonner que ton programme soit gros. Comme toutes les fonctions de stdio.h, scanf n'est là que pour porter des programmes PC. Si vous les utilisez pour vos programmes, cela veut dire que vous êtes paresseux et que vous n'en avez rien à f**tre de la taille de vos programmes. Il y a des solutions nettement plus adaptées à la plateforme.

et dans ton cas il faut mettre a jour tous le programmes a la main! Dans un cas tu ne change que ta lib,

Non, tu changes toutes tes librairies et tes programmes. Il faut penser à une mise à jour globale, pas à une mise à jour ponctuelle pour cause d'un bogue précis. Les mises à jour globales sont beaucoup plus fréquentes. Il y a rarement des bogues suffisamment graves pour justifier une mise à jour immédiate. Et s'il y en a, ils se trouvent le plus souvent dans un programme, pas dans une librairie.

dans l'autre tous les programmes sans compter qu'il faut attendre que l'auteur ait mis a jour son programme

Tant mieux, comme ça, si le programme utilise plus d'une librairie, on profitera des mises à jour de plusieurs librairies en même temps plutôt que d'être obligé à les mettre à jour une par une.

et etre au courant qu'une version corigée existe.

C'est une responsabilité de l'auteur. Un auteur de programmes responsable se mettra au courant des mises à jour. Un auteur de librairies responsable se tâchera de signaler ses mises à jour aux programmeur desquels il sait qu'ils utilisent la librairie (pour une librairie avec peu d'utilisateurs, par mail, pour une librairie très utilisée comme TIGCCLIB, par des messages sur les forums). Et si les programmes ne sont pas faits par des auteurs responsables, franchement, il vaut mieux ne pas les utiliser, parce qu'ils auront de bonnes chances d'être bogués.

Certes mais ca peut arriver

Mais plus rarement que le cas de figure favorable aux librairies statiques et défavorable aux librairies dynamiques.

et puis un changement mineur de ROM ou de HW peut remener a devoir faire une MAJ de la lib aussi.

Pas un changement mineur. Un changement majeur. Et il n'y en a vraiment pas beaucoup. Un tous les 2-3 ans seulement.

Si par exemple il faut faire un changement a une section très utilisée de TIGCCLIB c'est sans doute énormément de progs à recompiler.

Et la version dynamique n'y change pas grand chose. Il y a pas mal de code dans les macros et dans tipatch.lib.

Avec stdlib, il suffit d'en mettre à jour une seule.

* Seulement pour les librairies qui font partie du bundle.
* stdlib gaspille de la place avec des librairies exotiques que presque personne n'utilise.
* Il faut attendre la prochaine mise à jour de PreOs. Cela veut dire:
- souvent pas de mise à jour rapide en cas de bogue grave.
- le moment de la mise à jour de la librairie dépend du cycle de développement de PreOs, pas du cycle de développement du programme. Le programmeur utilisant la librairie est donc contraint par le cycle de développement de PreOs, il perd toute son autonomie.

Et meme si on veut utiliser des lib séparées elles sont souvent dispo par packs donc facile a récupérer.

Alors là pas du tout. Les librairies qui ne sont pas dans stdlib sont toutes distribuées individuellement (et le "pack" tigcclib.9xz ne compte pas, ce n'est pas un vrai pack).

1.Certes mais ca cerait plus pratique

Pas du tout. Project / Options / Post-Build-Processing: Call after building:.

2.1 Oui mais oblige une appli externe a chaque lancement

Tu commence à me saouler avec cela! Tu n'as qu'à utiliser AutoStart si ça te gène vraiment. Ou alors utiliser un lanceur personnalisé sans venir râler que ça prend de la place: toute fonctionnalité prend de la place, un point c'est tout.

2.2 Intéret de décompresser un prog kernel si on n'a pas de kernel

Et si on a un kernel autre que PreOs?
Et puis il n'y a pas que les programmes kernel! Pour qu'une technologie soit acceptable pour TIGCC, il faut une compatibilité _nostub acceptable. Le fait qu'un programme _nostub compressé nécessite un kernel n'est pas acceptable.

Vark a écrit :
le monopole du _nostub ça te dérange pas par contre ?

Justement, le _nostub n'est pas un monopole, il empêche tout monopole d'un kernel parce qu'il marche quel que soit le kernel installé, et même sans qu'un kernel soit installé.

C'est de l'inefficacité gratuite que d'utiliser du regparm(2).

1) Donne moi un bench issu d'un prog déjà existant mettant clairement en défaut cette "inefficacité". Je parie sur moins de 0.5% en taille et en vitesse.
2) Elle n'est pas gratuite. Il n'y a pas que TIGCC. (tu dis toi-même que la portabilité est un critère important, mais tu sembles faire une exception pour les compilateurs...)

Je te signale qu'il faut un paquet de presque 4 MO (TIGCC) pour compiler PreOs.

Non, sans le linkage statique avec h220xtsr, il suffit d'a68k et makeprgm. Total : ~200 ko

Tout a fait d'accord, mais un seul pbm.. (malheureusement en faveur de KK... :/)

Il n'y a pas de raison qu'un argument en faveur de Kevin soit traité différement du mien, c'est ca un débat

si le prog qui utilise la lib utilise aussi TIGCCLIB... (la lib n'inclu pas tt les hacks de tigcc nan ?) il va falloir recompiler.. Mais je précise, PAS A CAUSE DE LA LIB ! mais a cause de TIGCC/TIGCCLIB !

d'ou l'interet de tigcclib dynamique.

Kevin Kofler a écrit :
Justement, le _nostub n'est pas un monopole, il empêche tout monopole d'un kernel parce qu'il marche quel que soit le kernel installé, et même sans qu'un kernel soit installé.

Pollux
a écrit : 1) Donne moi un bench issu d'un prog déjà existant mettant clairement en défaut cette "inefficacité". Je parie sur moins de 0.5% en taille et en vitesse.

Ça reste une inefficacité très facile à éviter.

2) Elle n'est pas gratuite. Il n'y a pas que TIGCC. (tu dis toi-même que la portabilité est un critère important, mais tu sembles faire une exception pour les compilateurs...)

Parce que tu es censé implémenter regparm correctement au lieu d'essayer de forcer tous les programmeurs à utiliser une convention moins efficace juste pour être compatible avec ton compilateur incomplet. C'est toi qui te fiches de la compatibilité avec TIGCC en:
* ne supportant pas l'intégrité des fonctionnalités du langage de TIGCC
* rajoutant des extensions incompatibles, pour la plupart tenues secrètes pour empêcher à l'équipe de TIGCC de les implémenter en même temps

Pollux a écrit :
Non, sans le linkage statique avec h220xtsr, il suffit d'a68k et makeprgm. Total : ~200 ko

Mais ce n'est pas une version complète de PreOs.

Uther Lightbringer
a écrit : Il n'y a pas de raison qu'un argument en faveur de Kevin soit traité différement du mien, c'est ca un débat

En effet, je trouve son "malheureusement" très mal placé.

d'ou l'interet de tigcclib dynamique.

Ça ne sert pas. Il y a pas mal de code dans les headers (sous forme de macros) et dans tipatch.lib.

>Vark #156
Je ne vois pas ce qu'il y a de drôle.

> Pollux a écrit :
> 1) Donne moi un bench issu d'un prog déjà existant mettant clairement en défaut cette "inefficacité". Je parie sur moins de 0.5% en taille et en vitesse. Ça reste une inefficacité très facile à éviter.

Non, à moins que tu me trouves un algo d'allocation de registres aussi rapide et peu gourmand en mémoire que l'actuel, et qui permette le regparm(n) avec n>=4.

> 2) Elle n'est pas gratuite. Il n'y a pas que TIGCC. (tu dis toi-même que la portabilité est un critère important, mais tu sembles faire une exception pour les compilateurs...)
Parce que tu es censé implémenter regparm correctement au lieu d'essayer de forcer tous les programmeurs à utiliser une convention moins efficace juste pour être compatible avec ton compilateur incomplet. C'est toi qui te fiches de la compatibilité avec TIGCC en:
* ne supportant pas l'intégrité des fonctionnalités du langage de TIGCC * rajoutant des extensions incompatibles, pour la plupart tenues secrètes pour empêcher à l'équipe de TIGCC de les implémenter en même temps

Ah bon, je suis "censé implémenter regparm correctement" ? Si je faisais une version de regparm totalement compatible avec TI-GCC, les résultats en matière de code généré seraient absolument horribles (et largement inférieurs à ceux du stkparm). Je ne vois pas qui devrait obliger mon compilateur à être 3 fois plus lent ou faire du code 2x plus gros à cause de ça. Je crois sincèrement que c'est le meilleur compris adapté à une plate-forme on-calc. Mais si tu trouves mieux, informe-moi

Ensuite je me "fiche de la compatibilité avec TIGCC" ? Ah bon, effectivement GTC n'est absolument pas compatible TIGCC J'ai implémenté une bonne partie des extensions de TI-GCC, pas toutes, en particulier les nested functions (utilité limitée, plutôt complexe à intégrer à un compilo on-calc), les fonctions inline (quasiment impossible vu la mémoire disponible on-calc) et l'arguments pour les fonctions ASM inline (qui devrait venir tôt ou tard, mais qui risque dans certains cas de relever plus de l'émulation qu'autre chose - ex. l'appel direct de genlib sans passer par genclib ne sera pas efficace).

"rajoutant des extensions incompatibles, pour la plupart tenues secrètes pour empêcher à l'équipe de TIGCC de les implémenter en même temps"
Personne ne me l'a jamais demandé. A ce jour :
1) déclarations au milieu d'un bloc (mais qui sont en faites implémentées dans le standard C-99, donc TI-GCC les gère)
2) #macro, syntaxe provisoire :

#macro afficher_tout(param,x,y...)
  afficher(param,x);
  #ifndef __IS_EMPTY__##y
    afficher_tout(param,y);
  #endif
#endm

ce qui permet pas mal de nouvelles choses
3) grâce à l'intégration du préprocesseur dans le compilateur, on peut faire

#if !cdefined(MON_TYPE)
  typedef struct {
    ...
  } MON_TYPE;
#endif

Tu me diras qu'ici on peut passer outre avec un #define, mais dans d'autre cas (ex : variable à portée locale), on ne peut pas.
4) modifications des options de compilation au milieu d'un code source

Donc 1) est déjà implémenté et je ne pense pas que tu puisses implémenter 2) 3) 4) (et en tout cas certainement pas 3) )

Ce n'est pas à moi de faire une enquète, c'est à vous de venir demander les fonctionnalités qui vous intéressent. Pour MIN_KERNEL, personne n'a proposé ça sur notre forum (partie "TIGCC Programming") ou par mail à l'équipe. Et même ici, il n'y a eu que PpHd et toi pour le proposer. Et toute proposition devra être suffisamment détaillée pour expliquer ce que vous voulez exactement et comment vous voulez que ce soit implémenté.

Mea culpa. J'y ai pensé parceque ca tombait bien dans ce débat mais en pratique kernel.h me suffit. Et puis pour ce qui est d'aller sur votre forum j'aurais trop peur que tout le monde me tombe dessus dès que j'emploierai le mot kernel. Et enfin l'anglais je le lis relativement bien mais pour l'écrire .

Si tu es paresseux, il ne faut pas t'étonner que ton programme soit gros. Comme toutes les fonctions de stdio.h, scanf n'est là que pour porter des programmes PC. Si vous les utilisez pour vos programmes, cela veut dire que vous êtes paresseux et que vous n'en avez rien à f**tre de la taille de vos programmes. Il y a des solutions nettement plus adaptées à la plateforme.

Je ne me fait pas de souci: des paresseux, il y en a. Je ne me suis jamais plein de la taille je sais très bien ce qu'utiliser ces fonctions coutent.

>et dans ton cas il faut mettre a jour tous le programmes a la main! Dans un cas tu ne change que ta lib, Non, tu changes toutes tes librairies et tes programmes. Il faut penser à une mise à jour globale, pas à une mise à jour ponctuelle pour cause d'un bogue précis. Les mises à jour globales sont beaucoup plus fréquentes. Il y a rarement des bogues suffisamment graves pour justifier une mise à jour immédiate. Et s'il y en a, ils se trouvent le plus souvent dans un programme, pas dans une librairie.

Je parle bien sur de bogues de lib et non de programmes.

Tant mieux, comme ça, si le programme utilise plus d'une librairie, on profitera des mises à jour de plusieurs librairies en même temps plutôt que d'être obligé à les mettre à jour une par une.

Oui et si l'auteur a disparu ou tarde. Plus le temps que les archives des sites se mettent à jours(si elles le font). Et les vieilles versions qui resterons encore longtemps sur des sites perdus
[cite]C'est une responsabilité de l'auteur. Un auteur de programmes responsable se mettra au courant des mises à jour. Un auteur de librairies responsable se tâchera de signaler ses mises à jour aux programmeur desquels il sait qu'ils utilisent la librairie (pour une librairie avec peu d'utilisateurs, par mail, pour une librairie très utilisée comme TIGCCLIB, par des messages sur les forums). Et si les programmes ne sont pas faits par des auteurs responsables, franchement, il vaut mieux ne pas les utiliser, parce qu'ils auront de bonnes chances d'être bogués.

Pas un changement mineur. Un changement majeur. Et il n'y en a vraiment pas beaucoup. Un tous les 2-3 ans seulement.

et pourquoi il ne pourait pas y avoir de changement mineur qui provoque des erreurs dans tigcclib et oblige une update des grays par exemple? Et meme si ca arrive que tous les 2-3 ans c'est trop

Et la version dynamique n'y change pas grand chose. Il y a pas mal de code dans les macros et dans tipatch.lib.

Grr je deteste la programation a coup de macro.

* Seulement pour les librairies qui font partie du bundle.

Certes mais toutes celles qui n'en font pas partie ne sont pas utilisées pour plus de 1 ou 2 prog

* stdlib gaspille de la place avec des librairies exotiques que presque personne n'utilise.

C'est vrai que certaines lib n'ont pas grand chose a y faire

* Il faut attendre la prochaine mise à jour de PreOs. Cela veut dire:
- souvent pas de mise à jour rapide en cas de bogue grave. - le moment de la mise à jour de la librairie dépend du cycle de développement de PreOs, pas du cycle de développement du programme. Le programmeur utilisant la librairie est donc contraint par le cycle de développement de PreOs, il perd toute son autonomie.

Tout comme TI-GCC et s'il y a une update importante a faire je pense bien que PpHd saura se dépecher.

Tu commence à me saouler avec cela! Tu n'as qu'à utiliser AutoStart si ça te gène vraiment. Ou alors utiliser un lanceur personnalisé sans venir râler que ça prend de la place: toute fonctionnalité prend de la place, un point c'est tout.

He t'énerve pas. Je t'ai déja répondu a cela mais c'est pas grave va pas t'énerver pour ca.

2.2 Intéret de décompresser un prog kernel si on n'a pas de kernel Et si on a un kernel autre que PreOs?

tu l'avais déjà sité en 1.

Et puis il n'y a pas que les programmes kernel! Pour qu'une technologie soit acceptable pour TIGCC, il faut une compatibilité _nostub acceptable. Le fait qu'un programme _nostub compressé nécessite un kernel n'est pas acceptable.

Bien sur mais dans ce cas on distribue une en kernel l'autre en nostub comme ca tout le monde est content

Pollux a écrit :
2) #macro, syntaxe provisoire :

#macro afficher_tout(param,x,y...)
  afficher(param,x);
  #ifndef __IS_EMPTY__##y
    afficher_tout(param,y);
  #endif
#endm

ce qui permet pas mal de nouvelles choses

Ça, c'est probablement implémentable. Mais c'est certainement lourd à implémenter. Et tant que la syntaxe est provisoire, je ne vais pas perdre mon temps à essayer de l'implémenter juste pour voir que la syntaxe a changé.

3) grâce à l'intégration du préprocesseur dans le compilateur, on peut faire

#if !cdefined(MON_TYPE)
  typedef struct {
    ...
  } MON_TYPE;
#endif

Tu me diras qu'ici on peut passer outre avec un #define, mais dans d'autre cas (ex : variable à portée locale), on ne peut pas.

Peut-être que c'est faisable avec GCC 3.3, qui utilise un préprocesseur intégré à cc1.exe. Mais je ne suis pas sûr qu'il fasse les choses dans le bon ordre pour qu'on puisse faire ça. Je pense plutôt que non. À vérifier.

4) modifications des options de compilation au milieu d'un code source

Ça, c'est souvent demandé pour GCC, mais beaucoup trop compliqué à implémenter. Si on change n'importe quoi comme options au milieu du code, ça fera tout planter, et puis GCC n'est pas un compilateur totalement séquentiel comme GTC (ce qui veut aussi dire qu'il optimise nettement mieux qu'un compilateur totalement séquentiel!).

Donc 1) est déjà implémenté et je ne pense pas que tu puisses implémenter 2) 3) 4) (et en tout cas certainement pas 3) )

On verra. Je suis un peu plus optimiste que toi, mais pas trop.

Maintenant, ce que je pense de l'utilité de tes extensions:
2) C'est du n'importe quoi, ça. Des options pour le préprocesseur au plein milieu d'une macro! Ça complique l'expansion des macros pour très peu de bénéfices. Voilà comment je coderais ton exemple:

#define afficher_tout(param,x,y...) ({\
typeof(x) a[]={x,y...};\
int i;\
for(i=0;i<sizeof(a)/sizeof(x);i++) afficher(param,a[i[b][/b]]);})

3) On peut mettre #define HAVE_MON_TYPE pour obtenir exactement la même chose. Et donne-moi un exemple avec une variable à portée locale. Je suis certain qu'il y a une solution qui ne nécessite pas tes extensions.
4) C'est un hack grossier qui:
* ne marche pas correctement avec un vrai compilateur optimisant (non séquentiel).
* ne sert à rien: si on a un problème avec l'optimisation, on utilise des volatile ou des attributs comme may_alias. Sinon, il faudra m'expliquer pourquoi on voudrait changer un flag du compilateur en plein milieu du code.
Et le simple fait que tu implémentes ces extensions alors que tu penses toi-même qu'elles ne sont pas implémentables dans GCC me montre clairement ce que tu penses de la compatibilité avec TIGCC. Donc je penserai exactement la même chose de la compatibilité avec GTC: je m'en fiche. Si toi, tu ne comptes pas abandonner ces extensions, je ne vois pas pourquoi les programmeurs TIGCC devraient abandonner leurs regparm(4). Désolé, mais la compatibilité est quelque chose de réciproque.

Et pour finir, ta liste n'est pas complète: par exemple, les regparm(x,y) n'y sont pas et pourtant tu en as déjà parlé.

Uther Lightbringer
a écrit : Je parle bien sur de bogues de lib et non de programmes.

Bon, alors disons-le dans l'autre sens: Les bogues dans une librairie sont rarement (attention, je n'ai pas dit "jamais") suffisamment graves pour justifier une mise à jour immédiate. Ça revient au même, mais sans parler de bogues dans les programmes.

Oui et si l'auteur a disparu ou tarde.

C'est ce que je classe parmi les "auteurs non responsables". Sauf en cas d'accident imprévisible (et je parle de vrais accidents là, par exemple d'accidents de voiture, d'avion, d'attentats terroristes, ...), un auteur responsable n'est pas censé disparaître sans laisser des traces et sans appointer un nouveau mainteneur pour ses programmes. Les vieux programmes non maintenus, ben, on ne les utilise pas tout simplement.

Plus le temps que les archives des sites se mettent à jours(si elles le font).

Un utilisateur responsable va directement sur le site de l'auteur quand il cherche une mise à jour.

Et les vieilles versions qui resterons encore longtemps sur des sites perdus

C'est le problème de l'utilisateur, ça.

et pourquoi il ne pourait pas y avoir de changement mineur qui provoque des erreurs dans tigcclib et oblige une update des grays par exemple?

Il "pourrait", mais c'est vraiment très improbable.

Et meme si ca arrive que tous les 2-3 ans c'est trop

2-3 ans, c'est looooong pour un logiciel.

Certes mais toutes celles qui n'en font pas partie ne sont pas utilisées pour plus de 1 ou 2 prog

Si tout le monde mettait tout en librairie dynamique comme tu le proposes, ça changerait très vite!

Tout comme TI-GCC et s'il y a une update importante a faire je pense bien que PpHd saura se dépecher.

Quand il y a un bogue vraiment important (le critère étant: pouvant causer des plantages) dans TIGCC, nous sortons une mise à jour le plus vite possible, généralement en moins d'une semaine. PpHd est loin de réagir aussi rapidement. Exemple: compatibilité de SMA avec h220xTSR.

tu l'avais déjà sité en 1.

Où ça?

Kevin Kofler a écrit :
Et enfin, je ne vois pas l'intérêt de rajouter le support des packs archive PreOs à TIGCC sachant que:
1. il suffit d'utiliser kpack.exe sur les programmes produits par TIGCC pour en faire des packs archive.
2. TIGCC permet déjà la compression ExePack qui:
2.1. compresse mieux et
2.2. est plus portable (compatible avec les anciens kernels et avec l'absence de kernel).

Bien sur mais dans ce cas on distribue une en kernel l'autre en nostub comme ca tout le monde est content

Je ne vois pas l'intérêt de faire une version kernel. Avec la version _nostub, "tout le monde est content" également vu que le _nostub marche très bien même avec un kernel.

>>>Et enfin, je ne vois pas l'intérêt de rajouter le support des packs archive PreOs à TIGCC sachant que:
>>>1. il suffit d'utiliser kpack.exe sur les programmes produits par TIGCC pour en faire des packs archive.
>>>2. TIGCC permet déjà la compression ExePack qui:
>>>2.1. compresse mieux et
>>>2.2. est plus portable (compatible avec les anciens kernels et avec l'absence de kernel).
>>2.2 Intéret de décompresser un prog kernel si on n'a pas de kernel
>tu l'avais déjà sité en 1.

Où ça?

Pardon c'était tard j'ai pas vérifié exactement la position:tu l'avais déja cité dans la meme ligne: compatible avec les anciens kernels et avec l'absence de kernel.

Bon, alors disons-le dans l'autre sens: Les bogues dans une librairie sont rarement (attention, je n'ai pas dit "jamais") suffisamment graves pour justifier une mise à jour immédiate. Ça revient au même, mais sans parler de bogues dans les programmes.

Peu importe si c'est très important ou pas un bogue doit ce corriger. Et c'est justement pour les bogues pas trop grave que l'auteur va hésiter a faire une mise a jour.

C'est ce que je classe parmi les "auteurs non responsables". Sauf en cas d'accident imprévisible (et je parle de vrais accidents là, par exemple d'accidents de voiture, d'avion, d'attentats terroristes, ...), un auteur responsable n'est pas censé disparaître sans laisser des traces et sans appointer un nouveau mainteneur pour ses programmes. Les vieux programmes non maintenus, ben, on ne les utilise pas tout simplement.

Certes mais malheureusement le autre aussi consciencieux que toi ne sont pas nombreux et il y a toujours le risque comme tu l'as dis de l'accident. Total Destruction n'est plus mis a jour mais ca me ferait vraiment mal qu'il soit abandonné.

Un utilisateur responsable va directement sur le site de l'auteur quand il cherche une mise à jour.

tu voudrais presque nous imposer de faire du "idiot proof" et maintenant tu attends de tes utilisateurs qu'il soient responsables au point de ne pas télécharger sur les archives!

>Et les vieilles versions qui resterons encore longtemps sur des sites perdus C'est le problème de l'utilisateur, ça.

idem

Il "pourrait", mais c'est vraiment très improbable.

Je vois vraiment pas pourquoi ca serait improbable et je t'ai cité un example au hasard parmi tant de possibilités.

Si tout le monde mettait tout en librairie dynamique comme tu le proposes, ça changerait très vite!

Attends je ne pronne pas le 100% dynamique si tu ne te sert de tes routines que pour 1 ou 2 programmes persos, je conseille de rester en statique.

>Bien sur mais dans ce cas on distribue une en kernel l'autre en nostub comme ca tout le monde est content Je ne vois pas l'intérêt de faire une version kernel. Avec la version _nostub, "tout le monde est content" également vu que le _nostub marche très bien même avec un kernel.

Pour les avantage cités plus haut soit tu n'as pas PreOS et tu devra te coltiner un lanceur soit l'as et tout tiends en un seul fichier

Uther Lightbringer
a écrit : Peu importe si c'est très important ou pas un bogue doit ce corriger. Et c'est justement pour les bogues pas trop grave que l'auteur va hésiter a faire une mise a jour.

Si le bogue n'est pas trop grave, je ne vois pas le problème d'attendre la mise à jour 2 ou 3 semaines. Sachant que pour moi, plantage => bogue grave.

Certes mais malheureusement le autre aussi consciencieux que toi ne sont pas nombreux et il y a toujours le risque comme tu l'as dis de l'accident. Total Destruction n'est plus mis a jour mais ca me ferait vraiment mal qu'il soit abandonné.

Il n'est plus mis à jour, donc il est abandonné. Et le site officiel a l'air d'avoir carrément disparu.

tu voudrais presque nous imposer de faire du "idiot proof" et maintenant tu attends de tes utilisateurs qu'il soient responsables au point de ne pas télécharger sur les archives!

Ceux qui veulent avoir la version la plus récente, oui.
Et puis penses-tu vraiment que ceux qui ne sont pas capables d'aller faire un tour sur le site de l'auteur seront capables de mettre à jour une librairie dynamique? Moi en tout cas, je ne pense pas que ce soit le cas.

Je vois vraiment pas pourquoi ca serait improbable

Tu ne le vois pas parce que tu es un programmeur inexpérimenté. Désolé, mais je sais de quoi je parle, moi. Nos routines n'utilisent pas des adresses absolues à tord et à travers. Elles appellent des ROM_CALLs, et de la manière prévue.

et je t'ai cité un example au hasard parmi tant de possibilités.

C'est un mauvais exemple. Je ne vois pas ce que changerait une mise à jour logicielle pour nos routines de niveaux de gris. Quant à une mise à jour matérielle majeure, à la limite, mais TI ne change pas radicalement son matériel chaque semaine...

Pour les avantage cités plus haut soit tu n'as pas PreOS et tu devra te coltiner un lanceur soit l'as et tout tiends en un seul fichier

Franchement, tu m'énerves avec ça.
C'est la faute de PpHd qui a refusé de mettre un support transparent du format PPG dans PreOs. Utilise AutoStart qui est là pour ça. Je ne vois pas le problème.

2) C'est du n'importe quoi, ça. Des options pour le préprocesseur au plein milieu d'une macro! Ça complique l'expansion des macros pour très peu de bénéfices. Voilà comment je coderais ton exemple:

#define afficher_tout(param,x,y...) ({\
typeof(x) a[]={x,y...};\
int i;\ for(i=0;i<sizeof(a)/sizeof(x);i++) afficher(param,a[i]);})

Tiens, tu te mets à parler de "complication pour pas grand chose" ? C'est pourtant pas ton genre (chaque extension GNU devrait être supportée par GTC, aussi inutile soit-elle, selon toi)

Pour ce qui est de cet exemple, il y a clairement un pb de vitesse et de taille (si je fais afficher_tout(param,x,y), une bonne partie du temps sera passée dans la boucle for, sans parler de la taille...)
Et il y a plein d'autres choses qu'on peut faire (déroulage "intelligent" de code ASM, etc...)

Mais rien n'empêche de mettre :

#ifdef __GTC__
  #macro afficher_tout(param,x,y...)
    afficher(param,x);
    #ifndef __IS_EMPTY__##y
      afficher_tout(param,y);
    #endif
  #endm
#else
  #define afficher_tout(param,x,y...) ({\
    typeof(x) a[]={x,y...};\
    int i;\
    for(i=0;i<sizeof(a)/sizeof(x);i++) afficher(param,a[i]);})
#endif

... et il y a encore pas mal d'autres exemples qui permettent de faire un prog plus optimisé, et aussi plus lisible.

3) On peut mettre #define HAVE_MON_TYPE pour obtenir exactement la même chose. Et donne-moi un exemple avec une variable à portée locale. Je suis certain qu'il y a une solution qui ne nécessite pas tes extensions.

#macro format(f,a...)
  sprintf(
#if !cdefined(__format_buf)
    (char __format_buf[100])
#else
    __format_buf
#endif
  ,f,a),__format_buf;
#endm

Bon courage pour me trouver une solution sans ces extensions
Par contre je ne sais pas si la déclaration "char __format_buf[100]" est incluse dans le standard C-99 ou si c'est une spécificité de GTC?

(et ne me dis pas que cette routine n'est pas correcte sous prétexte qu'elle ne supporte pas 'char *a=format(s); char *b=format(t); disp(a),disp(b);', elle est simplement conçue pour un usage 'immédiat' i.e. gl_put_medium_string(screen,0,0,format(s)))

4) C'est un hack grossier qui:
* ne marche pas correctement avec un vrai compilateur optimisant (non séquentiel). * ne sert à rien: si on a un problème avec l'optimisation, on utilise des volatile ou des attributs comme may_alias. Sinon, il faudra m'expliquer pourquoi on voudrait changer un flag du compilateur en plein milieu du code.

On peut parfaitement avoir besoin de compiler une partie des fonctions en mode optimisation vitesse, d'autres en optimisation mémoire.

Et le simple fait que tu implémentes ces extensions alors que tu penses toi-même qu'elles ne sont pas implémentables dans GCC me montre clairement ce que tu penses de la compatibilité avec TIGCC. Donc je penserai exactement la même chose de la compatibilité avec GTC: je m'en fiche. Si toi, tu ne comptes pas abandonner ces extensions, je ne vois pas pourquoi les programmeurs TIGCC devraient abandonner leurs regparm(4). Désolé, mais la compatibilité est quelque chose de réciproque.

Il y a une différence majeure entre regparm(4) et ces extensions : si PpHd impose regparm(4) à l'ABI de tigcclib.9xz, alors aucun programme GTC ne pourra l'utiliser => perte de place ; alors que les extensions de GTC sont à la disposition du programmeur, et libre à lui de les utiliser ou non (d'autant plus qu'il sait parfaitement que TI-GCC ne les supporte pas).

Ensuite, si j'ai implémenté ces extensions, ce n'est certainement pas pour ennuyer la TI-GCC Team, c'est simplement parce que j'en avais personnellement besoin dans mes projets, et donc potentiellement d'autres personnes pourraient en avoir besoin.

Et pour finir, ta liste n'est pas complète: par exemple, les regparm(x,y) n'y sont pas et pourtant tu en as déjà parlé.

C'est vrai, autant pour moi. Mais je n'ai pas encore rédigé le fichier d'aide, donc il y a peut-être encore une ou deux choses que j'ai oubliées. Mais regparm(x,y) relève plus du détail qu'autre chose (s'implémente en 2 coups de cuillère à pot)

vas bosser GTC toi !!

Pollux
a écrit : Pour ce qui est de cet exemple, il y a clairement un pb de vitesse et de taille (si je fais afficher_tout(param,x,y), une bonne partie du temps sera passée dans la boucle for, sans parler de la taille...)

Le problème est surtout que ton optimiseur est pourri. GCC sait dérouler la boucle si on le lui demande (-funroll-loops).

Et il y a plein d'autres choses qu'on peut faire (déroulage "intelligent" de code ASM, etc...)

Là encore, c'est le boulot de l'optimiseur. Les extensions de langage, c'est de la triche.

Mais rien n'empêche de mettre :

#ifdef __GTC__
  #macro afficher_tout(param,x,y...)
    afficher(param,x);
    #ifndef __IS_EMPTY__##y
      afficher_tout(param,y);
    #endif
  #endm
#else
  #define afficher_tout(param,x,y...) ({\
    typeof(x) a[]={x,y...};\
    int i;\
    for(i=0;i<sizeof(a)/sizeof(x);i++) afficher(param,a[i[b][/b]]);})
#endif

Mais je veux voir les programmeurs qui travaillent avec GTC qui prennent le temps de faire ça.

D'ailleurs, attention, il y a une erreur dans mon code (je ne l'avais pas testé): [i]typeof(x) a[]={x,y...};[/i] devrait être [i]typeof(x) a[]={x,y};[/i]. Le reste est correct.

... et il y a encore pas mal d'autres exemples qui permettent de faire un prog plus optimisé, et aussi plus lisible.

Plus optimisé peut-être, surtout avec ton optimiseur défaillant. Plus lisible pas vraiment. Je ne vois pas l'intérêt de coder une simple boucle for par une substitution de macros récursive. En tout cas, je n'appellerais pas cela "lisible".

#macro format(f,a...)
  sprintf(
#if !cdefined(__format_buf)
    (char __format_buf[100])
#else
    __format_buf
#endif
  ,f,a),__format_buf;
#endm

Bon courage pour me trouver une solution sans ces extensions

Ah, en combinaison avec #macro... Alors là, c'est carrément illisible et totalement non-standard. Et c'est un abus total des macros.

Par contre je ne sais pas si la déclaration "char __format_buf[100]" est incluse dans le standard C-99 ou si c'est une spécificité de GTC?

C'est totalement non-standard. Et encore une extension stupide, illisible et sans intérêt de plus. Et une que tu n'as pas mise dans ta liste. Je suis sûr qu'il y en a pas mal... Pour moi, une extension non documentée est un bogue ("accepts-illegal"). Donc à ce rythme, il y a plein de bogues dans GTC.

Et je ne vois vraiment pas l'intérêt de ne pas soit faire 2 macros différentes, soit tout simplement faire en sorte que le programmeur déclare son buffer. Du point de vue sécurité (ce qui sur TI-89/92+/V200 veut surtout dire: stabilité), une taille arbitraire de 100 n'est pas une bonne idée (et je sais, notre printf_xy n'est pas beaucoup mieux de ce point de vue-là, mais bon).

On peut parfaitement avoir besoin de compiler une partie des fonctions en mode optimisation vitesse, d'autres en optimisation mémoire.

Pour ça, on utilise plusieurs fichiers C. Si GTC ne permet toujours pas ça, ben désolé, ce n'est pas un compilateur C.

Il y a une différence majeure entre regparm(4) et ces extensions : si PpHd impose regparm(4) à l'ABI de tigcclib.9xz, alors aucun programme GTC ne pourra l'utiliser => perte de place ;

Tant pis soit pour toi, soit pour PpHd.

alors que les extensions de GTC sont à la disposition du programmeur, et libre à lui de les utiliser ou non (d'autant plus qu'il sait parfaitement que TI-GCC ne les supporte pas).

Si les extensions sont là, les programmeurs vont certainement s'en servir.

Ensuite, si j'ai implémenté ces extensions, ce n'est certainement pas pour ennuyer la TI-GCC Team, c'est simplement parce que j'en avais personnellement besoin dans mes projets, et donc potentiellement d'autres personnes pourraient en avoir besoin.

C'est parce que tu utilises des macros pour plein de trucs pour lesquels ils ne sont tout simplement pas prévus. J'ai déjà remarqué ça quand on a travaillé ensemble sur A68k: tu voulais aller jusqu'à permettre à un programme A68k de lancer n'importe quel exécutable en plein assemblage. Proposition que j'ai évidemment refusée pour des raisons de sécurité évidentes.

C'est vrai, autant pour moi. Mais je n'ai pas encore rédigé le fichier d'aide, donc il y a peut-être encore une ou deux choses que j'ai oubliées. Mais regparm(x,y) relève plus du détail qu'autre chose (s'implémente en 2 coups de cuillère à pot)

Oui, ça c'est le genre d'extensions vraiment utiles et que je pense pouvoir implémenter dans GCC. Ça ne sera pas aussi simple que tu as l'air de croire (le patch pour rajouter regparm à GCC est assez complexe), mais je suis presque sûr que ce soit faisable.


PS: Je suis en général en faveur des extensions de langage, mais là tu bastardises tellement le langage C avec des extensions totalement inutiles et fortement dépendantes de la structure interne de ton compilateur que c'est totalement en dehors de ce que je considère acceptable.

Kevin Kofler a écrit :
Je sais, mais si on ne veut pas créer un monopole, on n'a pas d'autre choix que de continuer à supporter les kernels qui ne sont pas à jour.

Je sens que je vais mettre a jours les autres kernels justent pour vous embeter...

C'est de l'inefficacité gratuite que d'utiliser du regparm(2).

Hum... Reflechis 7 fois dans ta tete avant de dire cela.

Tu repasseras à au moins 12 KO quand les nouvelles fonctions sur lesquelles je travaille seront rajoutées à TIGCC 0.95.

Mais qui te dis que je les ajouterais ?

Si nous ne supportons pas certains RAM_CALLs, c'est parce qu'ils sont inutiles et encouragent la programmation sale. C'est le cas de Heap, FolderListHandle, MainHandle etc. Et aussi des fontes du boot. Déjà, la méthode de XDanger est à la limite de l'acceptable (personnellement, je trouve toujours qu'il faut utiliser DrawStr et DrawChar et rien d'autre), mais le fait de prendre les premières fontes qu'on trouve dans l'ordre numérique des adresses de la ROM est vraiment inacceptable.

La methode de recherche importe peu. On pourra toujours la modifier.
Et je comptes rajouter vcbprintf, push_internal_simplify, ... tous vos hacks en ram_calls pour etre plus propre (disons pour concentrer la salete en un seul point).

Oui. Il y a un mode natif, et c'est le mode à utiliser. Tout le reste n'a pas lieu d'être.

Si jeune, et deja si ........


>PpHd est loin de réagir aussi rapidement. Exemple: compatibilité de SMA avec h220xTSR.
j'estimais pas ca tres grave car on pouvait le faire fonctionner neanmoins.

>Avec la version _nostub, "tout le monde est content" également vu que le _nostub marche très bien même avec un kernel.
C'est faux. moi je suis pas content

>Nos routines n'utilisent pas des adresses absolues à tord et à travers. Elles appellent des ROM_CALLs, et de la manière prévue.
Ex: vcbprintf.

>C'est la faute de PpHd qui a refusé de mettre un support transparent du format PPG dans PreOs. Utilise AutoStart qui est là pour ça. Je ne vois pas le problème.
Parce que le format PPG etait trop limite : un seul fichier, compression imposee, pas executable.

Kevin Kofler a écrit :
Ce n'est pas à moi de faire une enquète, c'est à vous de venir demander les fonctionnalités qui vous intéressent. Pour MIN_KERNEL, personne n'a proposé ça sur notre forum (partie "TIGCC Programming") ou par mail à l'équipe. Et même ici, il n'y a eu que PpHd et toi pour le proposer. Et toute proposition devra être suffisamment détaillée pour expliquer ce que vous voulez exactement et comment vous voulez que ce soit implémenté.

Tres simplement. Aucun test de verification n'est a faire.
Tous les kernels verifient si la ram_call est defini.
MIN_KERNEL serait alors egal a la ram_call maximale defini dans le prototype.
Et si vous pourrez toujours la definir en statique si ca vous amuse.

Si tu es paresseux, il ne faut pas t'étonner que ton programme soit gros. Comme toutes les fonctions de stdio.h, scanf n'est là que pour porter des programmes PC. Si vous les utilisez pour vos programmes, cela veut dire que vous êtes paresseux et que vous n'en avez rien à f**tre de la taille de vos programmes. Il y a des solutions nettement plus adaptées à la plateforme.

Et si on aime la portabilite de code ? C'est tres euphorisant de se rendre compte que son code compile pour tout et n'importe quoi. D'ailleurs je comprends pas pkoi _main au lieu de main.

Non, tu changes toutes tes librairies et tes programmes. Il faut penser à une mise à jour globale, pas à une mise à jour ponctuelle pour cause d'un bogue précis. Les mises à jour globales sont beaucoup plus fréquentes. Il y a rarement des bogues suffisamment graves pour justifier une mise à jour immédiate. Et s'il y en a, ils se trouvent le plus souvent dans un programme, pas dans une librairie.

Encore une fois genlib est un parfait contre exemple.

Tant mieux, comme ça, si le programme utilise plus d'une librairie, on profitera des mises à jour de plusieurs librairies en même temps plutôt que d'être obligé à les mettre à jour une par une.

On tourne en rond.

C'est une responsabilité de l'auteur. Un auteur de programmes responsable se mettra au courant des mises à jour. Un auteur de librairies responsable se tâchera de signaler ses mises à jour aux programmeur desquels il sait qu'ils utilisent la librairie (pour une librairie avec peu d'utilisateurs, par mail, pour une librairie très utilisée comme TIGCCLIB, par des messages sur les forums). Et si les programmes ne sont pas faits par des auteurs responsables, franchement, il vaut mieux ne pas les utiliser, parce qu'ils auront de bonnes chances d'être bogués.

N'importe quoi ! Qui se preocuppe des programmes qu'il a fait il y a 3 ans ?
Toi, a la rigueur, mais c'est tout.

Mais plus rarement que le cas de figure favorable aux librairies statiques et défavorable aux librairies dynamiques.

Moi je dirais le contraire.

Pas un changement mineur. Un changement majeur. Et il n'y en a vraiment pas beaucoup. Un tous les 2-3 ans seulement.

Rien que pour ca cela justifie la lib dynamique.
Tous les progs kernels fonctionnant sous 92+ ams 2.05, fonctionnent sous V200 sans aucun patch !
Et en plus, la mise a jour de genlib a permis de mettre a jour le joypad (adapte a la calc), sans aucun changement dans les programmes !
C'est un enorme avantage !

Et la version dynamique n'y change pas grand chose. Il y a pas mal de code dans les macros et dans tipatch.lib.

Moui...

* Seulement pour les librairies qui font partie du bundle.
* stdlib gaspille de la place avec des librairies exotiques que presque personne n'utilise.

Tu peux recompiler TA version en enlevant les libs exotiques. Rien te t'y empeche.

* Il faut attendre la prochaine mise à jour de PreOs. Cela veut dire:
- souvent pas de mise à jour rapide en cas de bogue grave.

Y'a pas encore eu de bogue grave. S'il y en avait eu, la mise a jour aurait etre immediate.

- le moment de la mise à jour de la librairie dépend du cycle de développement de PreOs, pas du cycle de développement du programme. Le programmeur utilisant la librairie est donc contraint par le cycle de développement de PreOs, il perd toute son autonomie.

... Forcement, pour les libs integrees dans PreOS. Mais les autres ? C'est faux.

Alors là pas du tout. Les librairies qui ne sont pas dans stdlib sont toutes distribuées individuellement (et le "pack" tigcclib.9xz ne compte pas, ce n'est pas un vrai pack).

Elles sont dans le zip de PreOS. Et on peut les extraire de stdlib si on le souhaite.

Pas du tout. Project / Options / Post-Build-Processing: Call after building:.

et si on pas l'ide ?

Et si on a un kernel autre que PreOs?

On met a jour.

Et puis il n'y a pas que les programmes kernel! Pour qu'une technologie soit acceptable pour TIGCC, il faut une compatibilité _nostub acceptable. Le fait qu'un programme _nostub compressé nécessite un kernel n'est pas acceptable.

Et si vous laissiez le choix au programmeur ?

>>Il y a une différence majeure entre regparm(4) et ces extensions : si PpHd impose regparm(4) à l'ABI de tigcclib.9xz, alors aucun programme GTC ne pourra l'utiliser => perte de place ;
>Tant pis soit pour toi, soit pour PpHd.
J'ai mis regparm(2).

Tu commence à me saouler avec cela! Tu n'as qu'à utiliser AutoStart si ça te gène vraiment. Ou alors utiliser un lanceur personnalisé sans venir râler que ça prend de la place: toute fonctionnalité prend de la place, un point c'est tout.

Je croyais que ce qui faisait la supériorité du _nostub c'était justement que l'on n'avait besoin de rien d'autre que le programme pour l'utiliser (pas de librairies à copier ou de kernel à installer).

C'est contradictoire et pas du tout à l'avantage du _nostub. Il faudrait que tu choisisses.
Si tu utilises l'argument du lanceur personnalisé, soit cohérent et ne critique pas l'obligation de copier des libs et d'installer un kernel (ce qui n'est plus nécessaire avec l'autoinstallation)


Indépendemment de tout ça, j'ai du mal à donner de la valeur à tes arguments sur la facilité d'utilisation: être utilisateur d'une calculatrice scientifique donc niveau 1ère-terminale et ne pas être capable de récupérer 3 fichiers et de lancer l'installation d'un kernel...

Je suis sûr que ça existe mais est-ce que ça vaut la peine de se préoccuper de ce genre d'utilisateurs ? On peut se demander comment ils ont réussi à envoyer le fichier sur la calculatrice déjà ? Ils ont réussi à télécharger tigraphlink (ou leur truc récent), à l'installer, à relier le cable à la ti, à quitter les programmes lancés dessus, à aller chercher le zip sur un site, le sauver, l'extraire, le sélectionner et l'envoyer à la ti.
Et maintenant envoyer le reste du contenu du zip ou un autre fichier leur parait impossible !!!!!

Mais un intégrale, une dérivé, la manipulation de matrices ou de complexes, ça va, pas de problème.
Dis moi, des utilisateurs comme ça, tu en connais beaucoup ? Des amis peut-être ?


Petite question annexe: tu es vraiment pour l'utilisation unique des librairies statiques sur ordinateur ? Tu considère également les librairies dynamiques inutiles et inappropriés, ou c'est uniquement lié à la plate-forme (calculatrice)
(je dirais oui d'après tes commentaires sur la façon dont tu compiles GCC, mais j'aimerais être sûr...)

PpHd
a écrit : Je sens que je vais mettre a jours les autres kernels justent pour vous embeter...

Mais qui te dis que je les ajouterais ?

Si tu ne le fais pas, ta librairie dynamique sera incomplète.

Et je comptes rajouter vcbprintf, push_internal_simplify, ... tous vos hacks en ram_calls pour etre plus propre (disons pour concentrer la salete en un seul point).

Pour vcbprintf, je comprends encore, mais pour push_internal_simplify, je ne vois vraiment pas l'intérêt. C'est exporté depuis AMS 2.00, donc ce n'est plus un problème. Et pour Pedrom, 2 solutions:
* soit la fonction y est, alors exporte-la!
* soit elle n'y est pas, et alors ton RAM_CALL ne changera rien au problème.

>PpHd est loin de réagir aussi rapidement. Exemple: compatibilité de SMA avec h220xTSR. j'estimais pas ca tres grave car on pouvait le faire fonctionner neanmoins.

Mais avec des fonctionnalités réduites (pas d'ennemis).

>Avec la version _nostub, "tout le monde est content" également vu que le _nostub marche très bien même avec un kernel.
C'est faux. moi je suis pas content

Mais tu devrais l'être.

>Nos routines n'utilisent pas des adresses absolues à tord et à travers. Elles appellent des ROM_CALLs, et de la manière prévue. Ex: vcbprintf.

Bon, d'accord, tu as trouvé l'exception qui confirme la règle. Il y a aussi HS_pushEmptyFIFONode malheureusement.
Mais sinon, les fonctions qu'on utilise sont toutes (à moins que je n'en aie oubliée une ou 2) exportées, du moins depuis une certaine version d'AMS.

>C'est la faute de PpHd qui a refusé de mettre un support transparent du format PPG dans PreOs. Utilise AutoStart qui est là pour ça. Je ne vois pas le problème. Parce que le format PPG etait trop limite : un seul fichier, compression imposee, pas executable.

Ça ne t'empêche pas d'être compatible aussi avec ce format, qui, je le rappelle, est le standard de-facto. Mais bon, heureusement qu'on peut toujours installer AutoStart séparément ou utiliser un lanceur (personnalisé ou non) tout simplement.

PpHd a écrit :
Tres simplement. Aucun test de verification n'est a faire. Tous les kernels verifient si la ram_call est defini.

Sauf TeOS.

Et si on aime la portabilite de code ? C'est tres euphorisant de se rendre compte que son code compile pour tout et n'importe quoi. D'ailleurs je comprends pas pkoi _main au lieu de main.

Parce que de toute façon la signature n'est pas compatible (void _main(void) et pas int main(int argc, char **argv)). Si tu veux un main ANSI, tu dois récupérer les arguments sur la pile d'expression dans _main et les passer à ton main ANSI. Et en principe, tu dois gérer la valeur de retour de main, même si en pratique, ce n'est normalement pas nécessaire.

Encore une fois genlib est un parfait contre exemple.

Parce qu'elle est trop complexe. Et je me demande comment tu testes tes fonctions, vu qu'il y a des bogues qui devraient être visibles en testant (cf. clipping des lignes horizontales apparemment défaillant - je mets "apparemment" parce que je n'ai pas vérifié).

N'importe quoi ! Qui se preocuppe des programmes qu'il a fait il y a 3 ans ? Toi, a la rigueur, mais c'est tout.

* Thomas Nussbaumer:
Je cite l'historique de TI-Chess:
21/02/2000: Release 0.91 finished and distributed (first playable version)
NEW in TI-Chess 4.00 FINAL (11/11/2002)
2 ans et 9 mois entre la première version et la plus récente.
* toi-même: Fer3C 0.50 est sorti presque 4 ans après la première version.

Moi je dirais le contraire.

On tourne en rond. Et surtout il s'agit de données empiriques difficiles à prouver.

Rien que pour ca cela justifie la lib dynamique. Tous les progs kernels fonctionnant sous 92+ ams 2.05, fonctionnent sous V200 sans aucun patch !

Mais les programmes _nostub fonctionnent aussi. Oui, certains ont eu besoin d'un nouveau lanceur. Oui, certains ont eu besoin du V200 Executables Patcher. Mais ils marchent!

Et en plus, la mise a jour de genlib a permis de mettre a jour le joypad (adapte a la calc), sans aucun changement dans les programmes ! C'est un enorme avantage !

Mais ça n'a été possible que parce que tu as limité l'usage des touches par les programmes à un très petit nombre de touches.

Y'a pas encore eu de bogue grave. S'il y en avait eu, la mise a jour aurait etre immediate.

Il y a eu pas mal de bogues pouvant donner des plantages (cf. historique...) Mais apparemment, on n'a pas la même définition de "grave".

... Forcement, pour les libs integrees dans PreOS. Mais les autres ? C'est faux.

Mais je parle de celles intégrées à stdlib là.

Elles sont dans le zip de PreOS. Et on peut les extraire de stdlib si on le souhaite.

Là par contre, je parlais justement des librairies qui ne sont pas dans stdlib. Relis bien le contexte des 2 citations ci-dessus.

et si on pas l'ide ?

Ben, on rajoute l'appel à son fichier .bat, à son shellscript ou à son makefile. On est bien obligés d'appeler tigcc(.exe) d'une manière ou d'une autre. Et la raison pour laquelle je n'ai pas parlé de la ligne de commande est qu'il est tout bête de rajouter un appel à kpack.exe si on est en ligne de commande.

Et si on a un kernel autre que PreOs? On met a jour.

Et vive le monopole.

Et si vous laissiez le choix au programmeur ?

Il a déjà le choix: s'il veut un pack archive, il utilise kpack.exe. Nous, on propose une technique de compression, ça suffit.

>>Il y a une différence majeure entre regparm(4) et ces extensions : si PpHd impose regparm(4) à l'ABI de tigcclib.9xz, alors aucun programme GTC ne pourra l'utiliser => perte de place ;
>Tant pis soit pour toi, soit pour PpHd. J'ai mis regparm(2).

Merci de soutenir Pollux et son "embrace, extend & extinguish" microsoftien qu'il essaye d'utiliser contre TIGCC.

bah koi? pour l'instant, a propos de tigcc, on peux reprendre ta propre phrase a propos de PreOs:

"Et vive le monopole."

Parce que de toute façon la signature n'est pas compatible (void _main(void) et pas int main(int argc, char **argv)). Si tu veux un main ANSI, tu dois récupérer les arguments sur la pile d'expression dans _main et les passer à ton main ANSI. Et en principe, tu dois gérer la valeur de retour de main, même si en pratique, ce n'est normalement pas nécessaire.

ca serait vraiment un main ANSI surtout que les paramètres passeé sont à 99% des chaines. On pourait faire une petite marco qui gère ca.

* Thomas Nussbaumer:
Je cite l'historique de TI-Chess:
21/02/2000: Release 0.91 finished and distributed (first playable version)
NEW in TI-Chess 4.00 FINAL (11/11/2002)
2 ans et 9 mois entre la première version et la plus récente. * toi-même: Fer3C 0.50 est sorti presque 4 ans après la première version.

Oui mais ce sont des programmes qui ont évolués en permanence.

Mais les programmes _nostub fonctionnent aussi. Oui, certains ont eu besoin d'un nouveau lanceur. Oui, certains ont eu besoin du V200 Executables Patcher. Mais ils marchent!

Certes mais il fallu recourir a des manipulations alors que avec PreOS c'est absolument tansparent.

Il a déjà le choix: s'il veut un pack archive, il utilise kpack.exe. Nous, on propose une technique de compression, ça suffit.

Oui mais la pluspart des programmeurs ne seront meme pas au courant qu'il existe une alternative aux Exe-pack.

Uther Lightbringer a écrit :
ca serait vraiment un main ANSI surtout que les paramètres passeé sont à 99% des chaines. On pourait faire une petite marco qui gère ca.

Je pense aussi que proposer un main ANSI en option serait une bonne idée. Mais en option seulement, pas en standard. Beaucoup de programmes n'utilisent pas les arguments, donc pas besoin du code supplémentaire. D'autres veulent autre chose que des chaînes (par exemple des entiers, des expressions formelles etc.). Mais il faut qu'on discute de l'implémentation exacte. (Je vais discuter de ça avec Sebastian.)

Oui mais ce sont des programmes qui ont évolués en permanence.

Pas Fer3C. La version 0.50 est un "maintenance release" seulement. Il n'y a plus eu de vraies nouveautés depuis longtemps.

Certes mais il fallu recourir a des manipulations alors que avec PreOS c'est absolument tansparent.

Non. Un programme kernel compressé avec une ancienne version de ExePack doit lui aussi avoir son lanceur remplacé. Et ça aurait été le cas même si ttstart était en mode kernel, vu que c'était un bogue dans ttstart. Et puis il y a même eu des programmes pour kernel avec des problèmes de détection de modèle. Cf. PCT98.

Oui mais la pluspart des programmeurs ne seront meme pas au courant qu'il existe une alternative aux Exe-pack.

Tant pis. TIGCC n'est pas un espace publicitaire sur lequel n'importe qui peut coller ses affiches. Ce n'est pas à nous de rendre le système de packs archive connu.

Je pense aussi que proposer un main ANSI en option serait une bonne idée. Mais en option seulement, pas en standard. Beaucoup de programmes n'utilisent pas les arguments, donc pas besoin du code supplémentaire. D'autres veulent autre chose que des chaînes (par exemple des entiers, des expressions formelles etc.). Mais il faut qu'on discute de l'implémentation exacte. (Je vais discuter de ça avec Sebastian.)

Je parlais bien sur en option aussi. Pour l'implémentation a mon avis c'est simple si on a parmi les paramètres d'autres types que les chaines alors, on considère qu'il n'y a pas de paramètres. Je ne voit par pourquoi il faudrait permettre d'autres types vu que le C ANSI ne le permet pas. Et puis on peut toujours utiliser l'estack si l'on y tiends a faire avec d'autres types.

Cite oui mais pour un programme réelement maintenu combien d'autres se perdent!

Non. Un programme kernel compressé avec une ancienne version de ExePack doit lui aussi avoir son lanceur remplacé. Et ça aurait été le cas même si ttstart était en mode kernel, vu que c'était un bogue dans ttstart. Et puis il y a même eu des programmes pour kernel avec des problèmes de détection de modèle. Cf. PCT98.[/cite] Un avantage des PackArchives il aurait suffit de prendre la dernière version de skrnlib lib fournie avec PreOS et c'etait réglé. Et pour PCTools c'est justement parcequ'il n'utilise pas le kernel pour la détèction, et le problème est mineur.

Tant pis. TIGCC n'est pas un espace publicitaire sur lequel n'importe qui peut coller ses affiches. Ce n'est pas à nous de rendre le système de packs archive connu.

Non c'est un espace de pub réservé à la TICT

Uther Lightbringer
a écrit : Je parlais bien sur en option aussi. Pour l'implémentation a mon avis c'est simple si on a parmi les paramètres d'autres types que les chaines alors, on considère qu'il n'y a pas de paramètres. Je ne voit par pourquoi il faudrait permettre d'autres types vu que le C ANSI ne le permet pas. Et puis on peut toujours utiliser l'estack si l'on y tiends a faire avec d'autres types.

Ce n'est pas du tout ce que je voulais dire par "implémentation". Je veux dire: comment exactement on activerait l'usage d'un main ANSI (une option en #define, un #include ou une idée top-secret qui m'est venue, mais dont je dois parler avec Sebastian pour voir si c'est faisable). Et je n'ai pas besoin de suggestions, c'est à Sebastian et à moi (et éventuellement à Zeljko) d'en décider.

Quant à ce qui est à faire quand on passe autre chose que des chaînes, ça n'a jamais été en discussion: ER_throw(ER_ARG_MUST_BE_STRING); (ou à la limite ERD_dialog si ENABLE_ERROR_RETURN n'est pas défini). Toute autre réaction serait un non-respect des normes d'AMS.

oui mais pour un programme réelement maintenu combien d'autres se perdent!

Ce problème des auteurs qui disparaissent en est vraiment un. J'en ai vraiment marre des auteurs qui se fichent du reste du monde en se cassant complètement sans laisser des sources. Soit on maintient ses programmes, soit on appointe un autre mainteneur, soit on laisse les sources sous une licence qui permet les modifications pour qu'un autre mainteneur puisse s'auto-appointer. Toute autre solution est égoïste, stupide et inacceptable. Mais le problème ne doit pas être résolu du côté du format des exécutables, mais là où il est vraiment.

Un avantage des PackArchives il aurait suffit de prendre la dernière version de skrnlib lib fournie avec PreOS et c'etait réglé.

Non, il aurait fallu changer le kernel si le bogue y avait été. L'appel de EX_patch n'a aucun rapport avec la compression. Mais le système ExePack fonctionne différemment, et le fait d'utiliser ExePack ou non n'a rien à voir avec le format kernel.

Et pour PCTools c'est justement parcequ'il n'utilise pas le kernel pour la détèction, et le problème est mineur.

C'est un exemple parfait pour montrer comment le format kernel à lui seul ne résout pas tous les problèmes de mise à jour.

Non c'est un espace de pub réservé à la TICT

Le format ExePack a été choisi parce qu'il était le premier. Pour le remplacer par un autre format, il faudrait qu'il y ait une bonne raison, par exemple:
* compression meilleure
* meilleure portabilité
* licence plus permissive
Pour les packs archive, c'est exactement le contraire:
* Ils compressent moins bien.
* Ils ne marchent qu'avec PreOs. Alors que ttstart, lui, est très portable: il n'a pas besoin de kernel, et il marche avec toutes les versions de AMS, TI-92+ AMS 1.00 compris. Et il marche même avec Pedrom (testé avec Backgammon).
* La licence n'est pas spécifiée explicitement, donc on ne peut rien faire sans demander la permission des auteurs (pas seulement PpHd, mais aussi David Kühling pour la compression).

Ce n'est pas du tout ce que je voulais dire par "implémentation". Je veux dire: comment exactement on activerait l'usage d'un main ANSI (une option en #define, un #include ou une idée top-secret qui m'est venue, mais dont je dois parler avec Sebastian pour voir si c'est faisable). Et je n'ai pas besoin de suggestions, c'est à Sebastian et à moi (et éventuellement à Zeljko) d'en décider. Quant à ce qui est à faire quand on passe autre chose que des chaînes, ça n'a jamais été en discussion: ER_throw(ER_ARG_MUST_BE_STRING); (ou à la limite ERD_dialog si ENABLE_ERROR_RETURN n'est pas défini). Toute autre réaction serait un non-respect des normes d'AMS.

je pensait tout simplement si l'on a main utiliser la norme ANSI et si l'on a _main le système classique. Cela posarait des problèmes a implémenter simplement?

Le format ExePack a été choisi parce qu'il était le premier. Pour le remplacer par un autre format, il faudrait qu'il y ait une bonne raison, par exemple:
* compression meilleure
* meilleure portabilité
* licence plus permissive
Pour les packs archive, c'est exactement le contraire:
* Ils compressent moins bien.
* Ils ne marchent qu'avec PreOs. Alors que ttstart, lui, est très portable: il n'a pas besoin de kernel, et il marche avec toutes les versions de AMS, TI-92+ AMS 1.00 compris. Et il marche même avec Pedrom (testé avec Backgammon). * La licence n'est pas spécifiée explicitement, donc on ne peut rien faire sans demander la permission des auteurs (pas seulement PpHd, mais aussi David Kühling pour la compression).

Oui mais ils ont l'énorme avantage de pouvoir contenir plusieurs fichiers et de ne pas nécésiter de programmes externes(a part le kernel). C'est par cela que je dis qu'ils ont leurs avantages et leurs inconvéniant est qu'il serait sympa de laisser les deux aux choix.

Uther Lightbringer
a écrit : je pensait tout simplement si l'on a main utiliser la norme ANSI et si l'on a _main le système classique. Cela posarait des problèmes a implémenter simplement?

Tu as deviné mon idée "top secret". Je vais devoir discuter avec Sebastian pour voir si c'est faisable. C'est du boulot pour le linker.

Oui mais ils ont l'énorme avantage de pouvoir contenir plusieurs fichiers et de ne pas nécésiter de programmes externes(a part le kernel). C'est par cela que je dis qu'ils ont leurs avantages et leurs inconvéniant est qu'il serait sympa de laisser les deux aux choix.

Tu as déjà le choix. Ce n'est pas une bonne idée de vouloir intégrer tout et n'importe quoi à TIGCC. Et je n'ai pas envie de continuer à discuter de cela. C'est à nous de choisir ce qu'on met dans notre paquet, pas à toi.

> Pollux a écrit :
> Pour ce qui est de cet exemple, il y a clairement un pb de vitesse et de taille (si je fais afficher_tout(param,x,y), une bonne partie du temps sera passée dans la boucle for, sans parler de la taille...) Le problème est surtout que ton optimiseur est pourri. GCC sait dérouler la boucle si on le lui demande (-funroll-loops).

Justement, comme GCC ne supporte pas la modification des options de compilation juste pour une seule fonction, on est obligé de compiler tout le fichier en -O3 (en plus je suis sûr que GCC n'optimise pas a[1] en son contenu, donc le code généré est bel et bien bcp moins efficace)

> Et il y a plein d'autres choses qu'on peut faire (déroulage "intelligent" de code ASM, etc...) Là encore, c'est le boulot de l'optimiseur. Les extensions de langage, c'est de la triche.

Relis mon post. Je parle de code ASM, c'est bcp plus propre (et bcp plus simple à modifier) avec des #macro qu'avec des dizaines de copier-coller.

> Mais rien n'empêche de mettre :
> #ifdef __GTC__
> #macro afficher_tout(param,x,y...)
> afficher(param,x);
> #ifndef __IS_EMPTY__##y
> afficher_tout(param,y);
> #endif
> #endm
> #else
> #define afficher_tout(param,x,y...) ({\
> typeof(x) a[]={x,y...};\
> int i;\
> for(i=0;i<sizeof(a)/sizeof(x);i++) afficher(param,a[i]);})
> #endif Mais je veux voir les programmeurs qui travaillent avec GTC qui prennent le temps de faire ça.

Ben ça permet quand même de porter pour TI-GCC

> ... et il y a encore pas mal d'autres exemples qui permettent de faire un prog plus optimisé, et aussi plus lisible. Plus optimisé peut-être, surtout avec ton optimiseur défaillant. Plus lisible pas vraiment. Je ne vois pas l'intérêt de coder une simple boucle for par une substitution de macros récursive. En tout cas, je n'appellerais pas cela "lisible".

Ce n'est pas une question de défaillance de l'optimiseur (cf plus haut).
Plus lisible, cf plus haut aussi : c bcp plus propre pour dérouler du code ASM (évidemment c pas le genre de truc qu'il doit y avoir dans BackGammon )

> #macro format(f,a...)
> sprintf(
> #if !cdefined(__format_buf)
> (char __format_buf[100])
> #else
> __format_buf
> #endif
> ,f,a),__format_buf;
> #endm

> Bon courage pour me trouver une solution sans ces extensions Ah, en combinaison avec #macro... Alors là, c'est carrément illisible et totalement non-standard. Et c'est un abus total des macros.

En tout cas tu ne respectes pas ta propre parole : "Et donne-moi un exemple avec une variable à portée locale. Je suis certain qu'il y a une solution qui ne nécessite pas tes extensions."

> Par contre je ne sais pas si la déclaration "char __format_buf[100]" est incluse dans le standard C-99 ou si c'est une spécificité de GTC? C'est totalement non-standard. Et encore une extension stupide, illisible et sans intérêt de plus.

Illisible?

if ((FILE *in=fopen("data","rb"))
 && (FILE *out=fopen("save","w"))
 && (void *temp=malloc(TEMP_DATA_SIZE))) {
  ... suite du prog ...
} else ST_showHelp("Loading error");

(je suis sûr que tu vas critiquer parce qu'il n'y a qu'un seul msg d'erreur, mais rien ne t'empêche d'adapter pour en mettre plusieurs...)

Et une que tu n'as pas mise dans ta liste. Je suis sûr qu'il y en a pas mal... Pour moi, une extension non documentée est un bogue ("accepts-illegal"). Donc à ce rythme, il y a plein de bogues dans GTC.

Alors dis-toi qu'il y a plein de bugs et ne le télécharge surtout pas quand il sortira. Tant pis pour toi.

Et je ne vois vraiment pas l'intérêt de ne pas soit faire 2 macros différentes, soit tout simplement faire en sorte que le programmeur déclare son buffer. Du point de vue sécurité (ce qui sur TI-89/92+/V200 veut surtout dire: stabilité), une taille arbitraire de 100 n'est pas une bonne idée (et je sais, notre printf_xy n'est pas beaucoup mieux de ce point de vue-là, mais bon).

#undef FORMAT_SIZE
#define FORMAT_SIZE 300

ou, plus proprement, grâce à #macro :
SET_FORMAT_SIZE(300)

> On peut parfaitement avoir besoin de compiler une partie des fonctions en mode optimisation vitesse, d'autres en optimisation mémoire. Pour ça, on utilise plusieurs fichiers C. Si GTC ne permet toujours pas ça, ben désolé, ce n'est pas un compilateur C.

... et alors on ne profite pas du mode PC-relatif dans ces cas-là (et il n'y a pas de switch pour forcer ce mode pour les progs de plus de 32k)
A titre d'exemple, quel programme utilise les différents switch de compilation pour différentes parties du prog (menus, jeu...) ? Je pense que c vraiment négligeable, justement parce que c'est très chiant de devoir grouper les fonctions arbitrairement dans des fichiers différents juste parce qu'une fonction a besoin d'être plus rapide.

> > Tant pis soit pour toi, soit pour PpHd.
> Il y a une différence majeure entre regparm(4) et ces extensions : si PpHd impose regparm(4) à l'ABI de tigcclib.9xz, alors aucun programme GTC ne pourra l'utiliser => perte de place ;
> alors que les extensions de GTC sont à la disposition du programmeur, et libre à lui de les utiliser ou non (d'autant plus qu'il sait parfaitement que TI-GCC ne les supporte pas). Si les extensions sont là, les programmeurs vont certainement s'en servir.

Pourtant tu m'as assuré qu'elles étaient inutiles? Il faudrait savoir...

> Ensuite, si j'ai implémenté ces extensions, ce n'est certainement pas pour ennuyer la TI-GCC Team, c'est simplement parce que j'en avais personnellement besoin dans mes projets, et donc potentiellement d'autres personnes pourraient en avoir besoin. C'est parce que tu utilises des macros pour plein de trucs pour lesquels ils ne sont tout simplement pas prévus. J'ai déjà remarqué ça quand on a travaillé ensemble sur A68k: tu voulais aller jusqu'à permettre à un programme A68k de lancer n'importe quel exécutable en plein assemblage. Proposition que j'ai évidemment refusée pour des raisons de sécurité évidentes.

De sécurité? Si quelqu'un voulait exécuter un virus, il le nommerait MapMaker.exe, parce que franchement vu le nombre de programmeurs ASM... (et d'ailleurs les programmeurs ASM sont suffisamment expérimentés pour se rendre compte d'un fichier EXE)
Mais note que j'étais d'accord pour un switch de protection désactivable (on n'est jamais trop prudent)

> C'est vrai, autant pour moi. Mais je n'ai pas encore rédigé le fichier d'aide, donc il y a peut-être encore une ou deux choses que j'ai oubliées. Mais regparm(x,y) relève plus du détail qu'autre chose (s'implémente en 2 coups de cuillère à pot) Oui, ça c'est le genre d'extensions vraiment utiles et que je pense pouvoir implémenter dans GCC. Ça ne sera pas aussi simple que tu as l'air de croire (le patch pour rajouter regparm à GCC est assez complexe), mais je suis presque sûr que ce soit faisable.

"vraiment utile", OK, mais c'est vraiment idiot de se limiter à des extensions aussi simples.

PS: Je suis en général en faveur des extensions de langage, mais là tu bastardises tellement le langage C avec des extensions totalement inutiles et fortement dépendantes de la structure interne de ton compilateur que c'est totalement en dehors de ce que je considère acceptable.

"totalement inutiles" : cf plus haut
"fortement dépendentes de la structure interne de ton compilateur" : pas d'accord, même avec un préprocesseur "classique" on peut implémenter 'cdefined' (mais c'est effectivement "non trivial"). Quant à #macro, excuse-moi, mais c vraiment assez facile à implémenter, et le changement du mode de compilation doit quand même pouvoir se faire. (parce que côté optimisation globale, à part les fonctions inline et les variables statiques inutilisées qui disparaissent, franchement je vois pas)

> > > Il y a une différence majeure entre regparm(4) et ces extensions : si PpHd impose regparm(4) à l'ABI de tigcclib.9xz, alors aucun programme GTC ne pourra l'utiliser => perte de place ;
> > Tant pis soit pour toi, soit pour PpHd.
> J'ai mis regparm(2). Merci de soutenir Pollux et son "embrace, extend & extinguish" microsoftien qu'il essaye d'utiliser contre TIGCC.

Mais n'importe quoi! C'est vraiment impossible de faire un compilo efficace sur TI qui supporte le regparm(4) (ou sinon j'invite ceux qui me contredisent sur ce point à me montrer le contraire, ou tout au moins des algorithmes pour appuyer leur point de vue )
Donc je ne vois absolument pourquoi tigcclib.9xz serait incompatible avec les progs on-calc. Tu essayes simplement de semer la discorde (pour que GTC et/ou tigcclib.9xz perdent de l'influence - d'ailleurs je trouve vraiment détestable cette mentalité de "concurrence", mais bon ), mais manifestement ça n'a pas marché

D'ailleurs je ne vois pas comment je pourrais "extinguish"er quoi que ce soit en ce qui concerne TI-GCC par le simple fait de ne supporter que regparm(2)...

Pollux
a écrit : Justement, comme GCC ne supporte pas la modification des options de compilation juste pour une seule fonction, on est obligé de compiler tout le fichier en -O3

Pas nécessairement. -funroll-loops suffit.

Relis mon post. Je parle de code ASM, c'est bcp plus propre (et bcp plus simple à modifier) avec des #macro qu'avec des dizaines de copier-coller.

Tu mets un asm("") dans une boucle C et le dérouleur de boucles fait le reste du travail. Évidemment, cela sous-entend qu'il y a un dérouleur de boucles, mais tout compilateur optimisant qui se respecte en a un...

Ben ça permet quand même de porter pour TI-GCC

Sauf si la moitié de la source est constitué de #macro comme ça...

Ce n'est pas une question de défaillance de l'optimiseur (cf plus haut).

Si. (Et je n'ai pas dit que l'optimisation de GCC est parfaite.)

Plus lisible, cf plus haut aussi : c bcp plus propre pour dérouler du code ASM (évidemment c pas le genre de truc qu'il doit y avoir dans BackGammon )

Cf. plus haut (boucle C contenant asm("") à dérouler automatiquement avec -funroll-loops).

En tout cas tu ne respectes pas ta propre parole : "Et donne-moi un exemple avec une variable à portée locale. Je suis certain qu'il y a une solution qui ne nécessite pas tes extensions."

Je pensais à l'utilisation de cdefined seul, pas en combinaison avec #macro.

Illisible?

if ((FILE *in=fopen("data","rb"))
 && (FILE *out=fopen("save","w"))
 && (void *temp=malloc(TEMP_DATA_SIZE))) {
  ... suite du prog ...
} else ST_showHelp("Loading error");

C'est totalement illisible. Ton écriture est beaucoup trop chargée. Je préfère:

FILE *in,*out; void *temp;
if ((in=fopen("data","rb"))
 && (out=fopen("save","w"))
 && (temp=malloc(TEMP_DATA_SIZE))) {
  ... suite du prog ...
} else ST_showHelp("Loading error");

Et personnellement, j'utiliserais plutôt:

FILE *in=fopen("data","rb");
if (in) {
  FILE *out=fopen("save","w");
  if (!out) goto erreur;
  void *temp=malloc(TEMP_DATA_SIZE);
  if (!temp) goto erreur;
  // ...
} else {
  erreur: ST_showHelp("Loading error");
}

Les 2 solutions n'ont pas besoin de tes extensions et sont moins chargées.

#undef FORMAT_SIZE
#define FORMAT_SIZE 300

ou, plus proprement, grâce à #macro : SET_FORMAT_SIZE(300)

Mais pourquoi toute cette complexité quand il suffit d'une ligne pour déclarer ce f**tu buffer???

... et alors on ne profite pas du mode PC-relatif dans ces cas-là

Sauf en compilant en -Wa,-l.

(et il n'y a pas de switch pour forcer ce mode pour les progs de plus de 32k)

Normal, ce n'est pas possible pour les programmes de plus de 32 KO.

A titre d'exemple, quel programme utilise les différents switch de compilation pour différentes parties du prog (menus, jeu...) ?

TI-Chess.

Je pense que c vraiment négligeable, justement parce que c'est très chiant de devoir grouper les fonctions arbitrairement dans des fichiers différents juste parce qu'une fonction a besoin d'être plus rapide.

Si on programme proprement et que le programme dépasse une certaine taille, il est tout à fait normal de le couper en unités logiques. Et de ces unités logiques, il y en a qui ont besoin de vitesse et d'autres qui n'en ont pas besoin.

Pourtant tu m'as assuré qu'elles étaient inutiles? Il faudrait savoir...

Elles sont inutiles, mais les programmeurs vont quand-même les utiliser.

"vraiment utile", OK, mais c'est vraiment idiot de se limiter à des extensions aussi simples.

Ce n'est pas idiot, c'est penser à la portabilité.

"fortement dépendentes de la structure interne de ton compilateur" : pas d'accord, même avec un préprocesseur "classique" on peut implémenter 'cdefined' (mais c'est effectivement "non trivial").

En faisant faire au préprocesseur une partie du travail du compilateur, probablement oui. Mais c'est sale.

Quant à #macro, excuse-moi, mais c vraiment assez facile à implémenter,

C'est probablement faisable en traffiquant un paquet de trucs dans cpp*.c. À voir.

et le changement du mode de compilation doit quand même pouvoir se faire. (parce que côté optimisation globale, à part les fonctions inline et les variables statiques inutilisées qui disparaissent, franchement je vois pas)

Ça dépend où tu changes le mode de compilation. Entre 2 fonctions seulement ou au plein milieu d'une fonction. GCC ne compile pas instruction par instruction, il traduit la fonction entière en "trees", puis en "register transfer language", puis en assembleur.
Et puis, d'après les discussions que j'ai lues sur les archives de la mailing list de GCC, les versions futures de GCC compileront le programme entier à la fois (plus fonction par fonction) pour pouvoir faire des optimisations interprocédurales, donc ça devient encore compliqué.

Mais n'importe quoi! C'est vraiment impossible de faire un compilo efficace sur TI qui supporte le regparm(4) (ou sinon j'invite ceux qui me contredisent sur ce point à me montrer le contraire, ou tout au moins des algorithmes pour appuyer leur point de vue )

Revois ta routine d'allocation de registres. Il y a plusieurs algorithmes possibles. GCC 3.3 en connaît 2 différents (mais le nouveau ne fonctionne pas encore , du moins pas dans TIGCC, mais c'est normal parce qu'il est documenté comme "experimental").

Donc je ne vois absolument pourquoi tigcclib.9xz serait incompatible avec les progs on-calc. Tu essayes simplement de semer la discorde (pour que GTC et/ou tigcclib.9xz perdent de l'influence - d'ailleurs je trouve vraiment détestable cette mentalité de "concurrence", mais bon ), mais manifestement ça n'a pas marché
D'ailleurs je ne vois pas comment je pourrais "extinguish"er quoi que ce soit en ce qui concerne TI-GCC par le simple fait de ne supporter que regparm(2)...

Je dis qu'il ne faut pas se soucier de la compatibilité avec GTC parce que tu ne te soucies pas de la compatibilité avec TIGCC, mais qu'au contraire tu essayes exprès de rajouter des extensions pour que les programmes ne se compilent pas avec TIGCC.