Où est CC ? - Page 12

Pollux a écrit :
> Assembler Instructions with C Expression Operands
Ca devrait arriver. Mais il faut que je trouve une syntaxe logique (enfin bon les ':' de TI-GCC ne sont pas très logiques non plus )

Si tu utilises une syntaxe incompatible, ça ne sert strictement à rien, autant ne pas les mettre du tout!
Il faudra vraiment que tu adaptes ta syntaxe asm pour la faire correspondre à celle de GCC!

> Variables in Specified Registers
Euh j'en vois pas trop l'utilité? A part pour émuler de manière très inefficace "Assembler Instructions with C Expression Operands" puisque les registres seront monopolisés dans toute la fonction

Pour les variables locales, il est vrai que l'utilité est limitée, même si le registre n'est pas forcément monopolisé dans toute la fonction, on peut aussi déclarer une "local register variable" dans un bloc! Mais les "global register variables" sont quand-même utilisées assez souvent.

> est-ce que tu pourrais rajouter le support des nombres binaires comme dans TIGCC
C'est fait

D'ailleurs, je me demande où tu as pris ta liste d'extensions, parce que dans la documentation actuelle de TIGCC, il y a: "Binary Numbers". Ça manque dans ta liste. Il manque aussi "Multi-Line String Literals" dans ta liste. Ça a été retiré dans FSF GCC 3.3, mais je l'ai remis dans le patch TIGCC, et nous n'avons aucune intention de le retirer, donc ça devrait figurer sur ta liste. Et je n'ai pas vérifié qu'il n'y ait pas d'autres omissions dans ta liste.

Uther Lightbringer a écrit :
il me semble que les prototypes du style: fonction(short x asm("d0"), short y asm("d1")) sont suportés non? Car ca c'est vraiment indispensable

Justement non! C'est une des raisons pour lesquelles je dis que GTC sera inutilisable!

Uther Lightbringer a écrit :
l'argument facile: mathématiquement Mathématiquement la probabilité d'y arriver et très proche de 0

Peut-être, mais elle n'est pas égale à 0, et c'est ce qui compte!

Bof, de toute facon ca prendra 5 minute a un programmeur d'adapter ca.

Pas si c'est vraiment utilisé de manière systématique. S'il suffit de 5 minutes pour supprimer l'utilisation d'une extension, autant ne pas utiliser cette extension dès le départ, et donc autant ne pas la permettre dans le compilateur!

arète ta mauvaise foi la. Tu sais très bien que compiler nécéssite de la RAM,

On charge (et décharge) le code au besoin. (Tu devrais connaître ça sous le terme de "librairies conditionnelles", qui est celui utilisé par PpHd. Mais c'est aussi possible avec le système de DLLs de TIGCC.) Je n'ai jamais dit qu'on met tous les 200 KO dans la RAM en même temps!

un code source et de la place pour l'exectutable, si on a en plus on a d'autre prog sur ca calc, ca commence a faire limité.

Ben, si on veut développer un gros projet on-calc, on ne devrait pas s'étonner de ne pas avoir la place pour d'autres programmes. C'est une des raisons pour lesquelles je dis que la programmation on-calc n'est pas une bonne idée en pratique.

> Sauf que tellement de choses manquent à CC que ça n'en vaut pas le coup.
Oui, mais s'il te paraît si évident que certaines de ces extensions que je n'ai pas implémentées sont implémentables en un coût raisonnable, ça peut en valoir le coup, quitte à ce que je l'implémente après dans GTC

> Le rapport, c'est que si on est dans l'esprit closed-source, on ne pense pas du tout à ce que des personnes puissent avoir envie de recompiler du code écrit par d'autres (et pas forcément avec le même compilateur).
Bien sûr que si! D'ailleurs le premier programme sur TI que j'ai publié était un portage de BasicLib pour ROM 2.0x

> Ce n'est pas parce qu'on peut coder une fonctionnalité en 10 fois moins de code qu'on peut coder tout en 10 fois moins de code!
Ben excuse-moi mais il doit pas y en avoir bcp des fonctionnalités de CC qu'on peut recoder en 10x moins de code

> Ben évidemment...
> Mais pour recompiler n'importe quel logiciel, il te faudra forcément un compilateur (ou du moins un assembleur)!
Oui, mais pour recompiler TIGCC, il ne faut pas n'importe quel compilo

> Pour moi, ce n'est pas "optimiser" que de recopier un code 100 fois avec une macro. Ça prendra 100 fois plus de place!
On voit que tu ne sais pas ce que c'est qu'une routine critique au point de vue vitesse. Programme un moteur 3D, et tu verras
D'ailleurs même le dieu vivant Thomas Nussbaumer fait du code généré automatiquement à outrance (FAT-Lib) [et oui, je sais, il les génère avec un prog externe et pas avec les fonctions de macro de l'assembleur, mais il y a de nombreux cas où il faut faire des tables bcp moins grosses mais bcp plus nombreuses et le support des macros par l'assembleur s'avère alors indispensable]
Si tu veux tu peux lui envoyer un mail lui disant que ça ne sert à rien et qu'il ferait bien mieux de faire *une* routine pour tous les zooms, mais je crois pas qu'il t'écoutera

> > > Là, c'est une déclaration, pas des instructions, et c'est pour montrer qu'il n'y a pas de nom de variable dans la déclaration. Ça n'a aucun rapport avec asm.
> > > Et d'ailleurs, la syntaxe asm(""); résout cette ambiguïté.
> > Oui, mais asm("") est bien adapté parce que l'argument est une chaîne. Dans GTC, l'argument est du code
> Il n'y a aucune bonne raison pour que ce soit le cas. Tu fais exprès de traîter ça différemment que GCC sans aucune raison valable!
Là tu me fais une critique sur le fait que GTC ait un parser commun au C et à l'ASM (question à laquelle j'ai d'ailleurs répondu 100 fois, donc j'estime que le débat est clos), alors que ma réponse portait sur le ; après les accolades. Ne mélange pas tout

> Oui, en plus, tu t'alignes sur M$!
lol! Et moi je pourrais dire que tu t'alignes sur Microsoft à faire des progs pour PC sans version 89 alors que moi j'en ai une

> Ben, il faut bien trouver une syntaxe, et je trouve ça plutôt logique de mettre des parenthèses autour pour en faire une expression.
Ben oui, moi aussi il faut bien que je trouve une syntaxe pour l'ASM.

> Thibaut> Arrête d'affirmer sans aucune argumentation et de croire que tout le monde qui ne croit pas à tes affirmations infondées se "trompe".
S'il fallait réargumenter à chaque fois qu'on te rappelle quelque chose que tu as "oublié"...

> Tout le monde ici disait qu'il était "évident" qu'un émulateur de Game Boy pour TI-89/92+/V200 était impossible
Pas moi Et puis ça reste lent.

> Ben, que le compilateur fasse 100 KO ou 200 KO, peu importe. Il y a au minimum 576 KO de mémoire archive sous toutes les versions raisonnablement récentes de AMS.
Tout le monde n'a pas une calc vide. Il y a une différence de 27% entre 476 ko et 376 ko, ça fait la différence entre une calc avec les programmes vitaux + GTC et une calc avec les programmes vitaux + GTC + le code source d'un programme.

(et ne me dis pas que les seuls programmes vitaux sont h220xtsr et autoclbr et je ne sais quel autre TSR, ça dépend des besoins de l'utilisateur)

> Demande à XDanger s'il trouve que je suis de mauvaise foi.
Nom choisi au hasard bien sûr

> Peut-être que son pseudonyme mythologique t'en donne l'impression, mais Paul Froissart n'est pas un dieu.
LOL bien sûr que non, mais je ne vois pas où est le problème

> Ben, tant pis. Tu ne t'attends quand-même pas à pouvoir compiler un gros projet en 1 seconde sur un processeur à 10 ou 12 MHz. Si c'est le cas, ben évidemment
> que le compilateur sera pourri, il n'a pas le temps de travailler. Un temps de compilation d'une minute est beaucoup plus réaliste!
Ben non, justement on peut compiler un gros projet en 20 secondes sans que le compilateur ne soit pourri. Je n'ai pas envie de faire passer ce temps à une minute juste pour supporter 2-3 extensions utilisées par certains programmes TIGCC. GTC est conçu principalement pour être un compilateur de développement, et le but est non pas de compiler n'importe quel programme en téléchargeant le zip original qui peut dater d'il y a 3 ans, mais de pouvoir porter facilement un programme (s'il n'est pas compilé d'origine par GTC) pour pouvoir après continuer son développement on-calc, sans avoir à attendre 3x plus de temps pour la compilation. C'est un choix, tu peux ne pas être d'accord avec lui, et à ce moment-là n'utilise pas GTC

> Non. Il a été invalidé par ISO en 1999. Le C99 le remplace en tant que standard ISO.
Si tu veux jouer sur les mots, on peut dire que sans l'option --std=std99, TIGCC n'est pas un compilateur C puisque ({0;}) n'est pas du C99 correct. Donc il n'y a aucune source sur ticalc.org qui n'utilise un compilateur C par défaut

> Pas de long long??? C'est totalement inutilisable ce truc alors!
> Et je te signale que long long est prévu par le standard ISO C99!
lol C'est loin d'être indispensable, et on peut toujours utiliser des routines de manipulations de structures.

> Complex Numbers
Ca c'est franchement inutile, même si c'est du C99. Je me refuse à implémenter un truc aussi inutile.

> Arrays of Variable Length
Tu as vu ce que c'est? C'est pas tableau[] dans la déclaration d'une structure (qui est effectivement utile, et implémenté dans GTC), c'est une sorte de alloca pretty-printé et illisible.

> Hex Floats non
> C'est prévu par le standard ISO C99, ça! Ce n'est pas du tout de la compatibilité antérieure, c'est une nouveauté!!!
g pas dit que c'était de la compatibilité antérieure, mais c'est un truc complètement inutile.

> Euh, GTC comprend-il au moins __func__ comme prévu par le standard ISO C99?
Non. Quel est l'intérêt? (__FUNC__ suffit, ou puisque je suis sûr que tu vas le dire : char funcname[]=__FUNC__, et si tu me parles de assert, je te dirais que 1] personne s'en sert sur TI 2] de toutes façons ça prend plein de place donc pas la peine d'optimiser 3] tu peux utiliser #macro si tu veux vraiment implémenter __func__ [avec bien sûr un #ifndef __GNUC__] et 4] de toutes façons si tu utilises plusieurs fois la même chaîne GTC le détecte évidemment donc pas la peine de se prendre la tête )

> Comment ça, "N/A"?
Ca ne s'applique pas à GTC, soit parce qu'il ne génère pas un code source .s, soit parce qu'il n'utilise pas certains attributs (qui ne sont pas nécessaires à la génération du code, par exemple les directives d'alignement qui ne sont pas conçues pour le 68000 puisqu'il n'y a pas de compromis alignement/vitesse)

Pollux a écrit :
> Ce n'est pas parce qu'on peut coder une fonctionnalité en 10 fois moins de code qu'on peut coder tout en 10 fois moins de code!
Ben excuse-moi mais il doit pas y en avoir bcp des fonctionnalités de CC qu'on peut recoder en 10x moins de code

Je pense plutôt aux fonctionnalités qui n'y sont pas parce que tu n'as pas trouvé d'implémentation compacte, pas aux fonctionnalités qui y sont. (Cf. contexte de la citation.)

> Ben évidemment...
> Mais pour recompiler n'importe quel logiciel, il te faudra forcément un compilateur (ou du moins un assembleur)!
Oui, mais pour recompiler TIGCC, il ne faut pas n'importe quel compilo

En effet, il faut GCC 2.95 ou supérieure. Ou alors il faut d'abord bootstrapper un GCC natif avant de compiler TIGCC, et bonne chance pour bootstrapper MinGW GCC à partir de M$VC, sachant que ça n'a plus été testé depuis des années.

> > > Là, c'est une déclaration, pas des instructions, et c'est pour montrer qu'il n'y a pas de nom de variable dans la déclaration. Ça n'a aucun rapport avec asm.
> > > Et d'ailleurs, la syntaxe asm(""); résout cette ambiguïté.
> > Oui, mais asm("") est bien adapté parce que l'argument est une chaîne. Dans GTC, l'argument est du code
> Il n'y a aucune bonne raison pour que ce soit le cas. Tu fais exprès de traîter ça différemment que GCC sans aucune raison valable! Là tu me fais une critique sur le fait que GTC ait un parser commun au C et à l'ASM

Même avec un parser commun, tu pourrais t'arranger pour accepter l'assembleur dans une chaîne de caractères si la compatibilité avec TIGCC t'intéressait vraiment.

> Ben, il faut bien trouver une syntaxe, et je trouve ça plutôt logique de mettre des parenthèses autour pour en faire une expression. Ben oui, moi aussi il faut bien que je trouve une syntaxe pour l'ASM.

Tu en as déjà une: asm("")!

> Peut-être que son pseudonyme mythologique t'en donne l'impression, mais Paul Froissart n'est pas un dieu.
LOL bien sûr que non, mais je ne vois pas où est le problème

Il n'y a pas de "problème". C'est juste que quelqu'un pourrait avoir un algorithme efficace auquel tu n'as pas pensé pour implémenter une extension.

> Non. Il a été invalidé par ISO en 1999. Le C99 le remplace en tant que standard ISO. Si tu veux jouer sur les mots, on peut dire que sans l'option --std=std99, TIGCC n'est pas un compilateur C puisque ({0;}) n'est pas du C99 correct.

1. Ce n'est pas --std=std99, mais -std=c99.
2. Il faut aussi préciser -pedantic-errors ou du moins -pedantic pour que GCC n'accepte pas les extensions GNU.
3. Aucun de ces switches n'est supporté par TIGCC. Il y a des extensions GNU de partout dans nos headers.
4. C'est quand-même un compilateur C parce que le C GNU contient le C standard en sous-ensemble (du moins c'est l'idée - ce n'est pas le cas dans certains exemples bien particuliers pour l'ISO C90 et les commentaires C++, mais vu que les commentaires C++ sont dans le standard ISO C99, ce problème-là n'existe plus).

> Pas de long long??? C'est totalement inutilisable ce truc alors!
> Et je te signale que long long est prévu par le standard ISO C99!
lol C'est loin d'être indispensable,

Tu n'as jamais programmé quoi que ce soit qui nécessite beaucoup de calculs apparemment. Par exemple, si on veut de la virgule fixe avec une grande précision, les long longs sont indispensables.

et on peut toujours utiliser des routines de manipulations de structures.

Beurk! Vive le code extrèmement inefficace... À titre d'exemple, au lieu d'avoir un add.l et un addx.l pour faire la somme, on aura une demi-douzaine d'instructions pour tester le débordement du long de poids faible.

> Complex Numbers Ca c'est franchement inutile, même si c'est du C99. Je me refuse à implémenter un truc aussi inutile.

Donc tu refuses d'implémenter le standard C, donc ton compilateur n'est pas un compilateur C. Appelle-le comme tu veux, mais pas "compilateur C".

> Arrays of Variable Length Tu as vu ce que c'est? C'est pas tableau[] dans la déclaration d'une structure (qui est effectivement utile, et implémenté dans GTC), c'est une sorte de alloca pretty-printé et illisible.

Je sais bien ce que c'est! Et je sais aussi que c'est dans le standard ISO C99! Et que j'utilise ça dans mes programmes.

Variable-length automatic arrays are allowed in ISO C99, and as an extension GCC accepts them in C89 mode.

(Pour le "C89 mode", il s'agit évidemment du mode gnu89, pas du mode C89/C90 strict.)

> Hex Floats non
> C'est prévu par le standard ISO C99, ça! Ce n'est pas du tout de la compatibilité antérieure, c'est une nouveauté!!! g pas dit que c'était de la compatibilité antérieure, mais c'est un truc complètement inutile.

Tu l'as mis sous:

Et les extensions complètement inutiles, soit parce que ce sont des extensions de compatibilité très pointues avec les vieux standard (ce qui n'est pas nécessaire sur TI),

Ce n'est pas le cas ici.

soit parce qu'elles n'ont aucune signification dans GTC (N/A),

Ça non plus.

soit parce qu'elles n'ont jamais et/ou ne seront certainement jamais utilisées...

Et ça non plus. (Désolé, mais dès qu'une extension existe, il y a toujours quelqu'un pour l'utiliser.)

Donc cette extension n'a rien à faire dans cette liste.

> Euh, GTC comprend-il au moins __func__ comme prévu par le standard ISO C99? Non. Quel est l'intérêt?

Que c'est prévu par le standard.

> Comment ça, "N/A"? Ca ne s'applique pas à GTC, soit parce qu'il ne génère pas un code source .s, soit parce qu'il n'utilise pas certains attributs (qui ne sont pas nécessaires à la génération du code, par exemple les directives d'alignement qui ne sont pas conçues pour le 68000 puisqu'il n'y a pas de compromis alignement/vitesse)

Les directives d'alignement s'appliquent tout à fait! Par exemple, __attribute__((aligned(2))) char x[4]="toto"; qui permet d'utiliser un move.l pour lire les 4 octets. Et il y a aussi d'autres attributs qui s'appliquent. Par exemple __attribute__((may_alias)), qui a été introduit avec GCC 3.3, et qui se retrouvera de partout dans les nouvelles sources (y compris nos headers), parce que GCC 3.3 donne un warning quand on ne respecte pas les règles de "strict aliasing".

> Si tu utilises une syntaxe incompatible, ça ne sert strictement à rien, autant ne pas les mettre du tout!
N'importe quoi...

> Il faudra vraiment que tu adaptes ta syntaxe asm pour la faire correspondre à celle de GCC!
Je t'ai déjà expliqué pourquoi je ne le ferai pas, je ne le répèterai pas 100 fois

> on peut aussi déclarer une "local register variable" dans un bloc
OK.

> Mais les "global register variables" sont quand-même utilisées assez souvent.
Tu as des exemples autres que OPTIMIZE_ROM_CALLS? Franchement je trouve ça très très gore, et ça limite le compilo alors que ces registres pourraient être utilisées dans les fonctions n'utilisant pas cette variable (sauf à faire plusieurs fichiers, mais c vraiment pas top comme solution).

> D'ailleurs, je me demande où tu as pris ta liste d'extensions, parce que dans la documentation actuelle de TIGCC, il y a: "Binary Numbers".
TIGCC Lib 2.5 (celle de TIGCC 0.94 beta 18)

> Ça manque dans ta liste. Il manque aussi "Multi-Line String Literals" dans ta liste. Ça a été retiré dans FSF GCC 3.3, mais je l'ai remis dans le patch TIGCC, et nous n'avons aucune intention de le retirer, donc ça devrait figurer sur ta liste.
Les deux sont supportés (je ne suis pas entièrement sûr pour multi-line string literals, mais il n'y a pas de raison que ça ne marche pas)

> Et je n'ai pas vérifié qu'il n'y ait pas d'autres omissions dans ta liste.
Je n'en ai pas omis par rapport à ma version de la doc.

> > il me semble que les prototypes du style:
> > fonction(short x asm("d0"), short y asm("d1")) sont suportés non? Car ca c'est vraiment indispensable
> Justement non! C'est une des raisons pour lesquelles je dis que GTC sera inutilisable!
C'est indispensable de pouvoir mettre x dans d0 et y dans d1, effectivement. La syntaxe n'est pas supportée, mais il suffit de faire __attribute__((regparm(2,0))) pour que GTC le fasse automatiquement. GTC (comme TIGCC) alloue les registres par ordre croissant, dans les Dn pour les scalaires et dans les An pour les pointeurs, et continue dans l'autre type de registre s'il n'y a plus de place, et enfin s'il n'y en a plus du tout, il met sur la pile.

Par exemple :
void __attribute__((regparm(2,2))) fonction(int x,int y,void *port,int color,void *data);
=>
void fonction(int x asm("d0"),int y asm("d1"),void *port asm("a0"),int color asm("a1"),void *data /* sur la pile */);

Mais je vais voir si je ne vais pas supporter cette syntaxe pour les registres d0-d2/a0-a1.


> Peut-être, mais elle n'est pas égale à 0, et c'est ce qui compte!
Oui, et la probabilité pour que TIGCC 0.95 soit un fake, et qu'en réalité vous soyez une organisation occulte visant à prendre le contrôle de tigcc.ticalc.org, supprimer toutes les sources du serveur, et enfin faire une opération commando pour supprimer les sources de TIGCC de tous les ordinateurs la possédant - tout ça pour relancer les ventes de casio - est strictement positive. C'est vrai que ça aussi, c'est une hypothèse à ne pas écarter! Méfiez-vous...

> S'il suffit de 5 minutes pour supprimer l'utilisation d'une extension, autant ne pas utiliser cette extension dès le départ, et donc autant ne pas la permettre dans le compilateur!
Alors dans la prochaine version de TIGCC mettez un warning non désactivable si on utilise une extension qui n'est pas prévue d'être implémentée dans GTC

> Je n'ai jamais dit qu'on met tous les 200 KO dans la RAM en même temps!
Mais en archive...

> > un code source et de la place pour l'exectutable, si on a en plus on a d'autre prog sur ca calc, ca commence a faire limité.
> Ben, si on veut développer un gros projet on-calc, on ne devrait pas s'étonner de ne pas avoir la place pour d'autres programmes. C'est une des raisons pour lesquelles je dis que la programmation on-calc n'est pas une bonne idée en pratique.
Sauf que GTC ne prend que 100 ko donc c'est une bonne idée, d'où l'intérêt de ne pas avoir un compilo de 200 ko. Dommage, bien essayé


> Je pense plutôt aux fonctionnalités qui n'y sont pas parce que tu n'as pas trouvé d'implémentation compacte, pas aux fonctionnalités qui y sont. (Cf. contexte de la citation.)
Alors toutes les fonctionnalités déjà implémentées sont super-optimisées et celles qui ne sont pas programmées pourraient être implémenté de manière 10x plus petite? Bizarre...

> Tu en as déjà une: asm("")!
Sauf que si je mets de l'assembleur syntaxe GTC sous un asm("") vous allez pas être contents (et moi non plus d'ailleurs)

> Il n'y a pas de "problème". C'est juste que quelqu'un pourrait avoir un algorithme efficace auquel tu n'as pas pensé pour implémenter une extension.
J'attends les suggestions

> Tu n'as jamais programmé quoi que ce soit qui nécessite beaucoup de calculs apparemment. Par exemple, si on veut de la virgule fixe avec une grande précision, les long longs sont indispensables.
Oui. Alors on utilise TI-GCC, de l'assembleur ou des structures pour le développement on-calc en attendant de recompiler avec TIGCC Et puis il suffit de compiler le module qui nécessite ces calculs avec TIGCC, pas besoin de tout compiler avec TIGCC.

> À titre d'exemple, au lieu d'avoir un add.l et un addx.l pour faire la somme, on aura une demi-douzaine d'instructions pour tester le débordement du long de poids faible.
move.l (a0),d0
add.l d0,(a1)
move.l 4(a0),d0
addx.l d0,4(a1)
4 au lieu de 2, et de toutes façons c'est ce que TI-GCC fera s'il n'a pas assez de registres (2 registres par variable ça fait bcp...)

> Donc tu refuses d'implémenter le standard C, donc ton compilateur n'est pas un compilateur C. Appelle-le comme tu veux, mais pas "compilateur C".
TIGCC accepte ({0;}) qui est du code C invalide, donc ce n'est pas un compilateur C non plus (et le mode "compilateur C" comme tu dis ne fonctionne pas avec TIGCC)

> Et que j'utilise ça dans mes programmes.
Ca doit être loin d'être indispensable, et très facile à contourner. Ou alors donne-moi un exemple

> > soit parce qu'elles n'ont jamais et/ou ne seront certainement jamais utilisées...
> Ca non plus. (Désolé, mais dès qu'une extension existe, il y a toujours quelqu'un pour l'utiliser.)
Trouve moi un seul prog sur ticalc.org qui l'utilise (et qui ne soit pas de toi )

> > Non. Quel est l'intérêt?
> Que c'est prévu par le standard.
Désolé mais ça ne sert absolument à rien sur TI, donc je ne l'implémente pas. Je n'en ai rien à faire d'avoir le certificat "ISO C99". Tout ce que je veux c'est que ça soit facile de programmer sous GTC et de porter des programmes vers GTC.

> Les directives d'alignement s'appliquent tout à fait! Par exemple, __attribute__((aligned(2))) char x[4]="toto"; qui permet d'utiliser un move.l pour lire les 4 octets. Et il y a aussi d'autres attributs qui s'appliquent. Par exemple __attribute__((may_alias)), qui a été introduit avec GCC 3.3, et qui se retrouvera de partout dans les nouvelles sources (y compris nos headers), parce que GCC 3.3 donne un warning quand on ne respecte pas les règles de "strict aliasing".
Si tu veux je peux supporter __attribute__((aligned))
Et __attribute__((may_alias)) n'a aucun sens pour GTC (mais il a tout de même le comportement attendu)

Tiens, enfin, Pollux dévoile ce qu'il a fait et ce qui manque (et manquera visiblement toujours) à GTC...
Eh bien, je trouve que GTC ne va pas être très bon. Trucs du standard non implémentés, incompatilibilités volontairement ajoutées...
Je maintiens ma promesse d'annoncer GTC sur notre forum. Je posterai le message que Pollux m'enverra. Mais si c'est du n'importe quoi et qu'il n'y a pas moyen de lui faire dire la vérité sur son truc, on s'en chargera...


Actuellement, on a:
* système standard et compilateur standard: AMS et TIGCC.
* systèmes non standard, incompatibles avec le système standard, et compilateurs non standards, incompatibles avec le compilateur non standard: PedroM et GTC.
Le premier couple existe, le second pas (ni PedroM ni GTC n'ont été releasés).

> TIGCC Lib 2.5 (celle de TIGCC 0.94 beta 18)
Wow, une version encore plus ancienne que celle que j'ai...

"short itoa_ushort_10_extended(register unsigned char * asm("a1"), register unsigned short asm("d1"), register unsigned short asm("d2"), register BOOL asm("d3")) __attribute__((__regparm__(4)));"
Cette déclaration est donc invalide sous GTC ?

XDanger a écrit :
"short itoa_ushort_10_extended(register unsigned char * asm("a1"), register unsigned short asm("d1"), register unsigned short asm("d2"), register BOOL asm("d3")) __attribute__((__regparm__(4)));"

Oula que c moche, si on me montre des sources comme sa c direct

Pollux a écrit :
> Si tu utilises une syntaxe incompatible, ça ne sert strictement à rien, autant ne pas les mettre du tout! N'importe quoi...

Pas du tout.

> Mais les "global register variables" sont quand-même utilisées assez souvent. Tu as des exemples autres que OPTIMIZE_ROM_CALLS?

CalcRogue. http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=90.topic.

> D'ailleurs, je me demande où tu as pris ta liste d'extensions, parce que dans la documentation actuelle de TIGCC, il y a: "Binary Numbers". TIGCC Lib 2.5 (celle de TIGCC 0.94 beta 18)

Cette version est préhistorique, et en particulier la documentation de GCC n'y est pas du tout à jour.

> Et je n'ai pas vérifié qu'il n'y ait pas d'autres omissions dans ta liste. Je n'en ai pas omis par rapport à ma version de la doc.

Cf. ci-dessus.

> > il me semble que les prototypes du style:
> > fonction(short x asm("d0"), short y asm("d1")) sont suportés non? Car ca c'est vraiment indispensable
> Justement non! C'est une des raisons pour lesquelles je dis que GTC sera inutilisable!
C'est indispensable de pouvoir mettre x dans d0 et y dans d1, effectivement. La syntaxe n'est pas supportée, mais il suffit de faire __attribute__((regparm(2,0))) pour que GTC le fasse automatiquement. GTC (comme TIGCC) alloue les registres par ordre croissant, dans les Dn pour les scalaires et dans les An pour les pointeurs, et continue dans l'autre type de registre s'il n'y a plus de place, et enfin s'il n'y en a plus du tout, il met sur la pile.

Par exemple :
void __attribute__((regparm(2,2))) fonction(int x,int y,void *port,int color,void *data);
=>
void fonction(int x asm("d0"),int y asm("d1"),void *port asm("a0"),int color asm("a1"),void *data /* sur la pile */);
Mais je vais voir si je ne vais pas supporter cette syntaxe pour les registres d0-d2/a0-a1.

Fais ce que tu veux, mais en tout cas, avec ton passage par registres très limité que tu as actuellement (de par ton allocateur de registres pourri), tu ne pourras pas utiliser les versions récentes de TIGCCLIB. Il y aura des asm("d1") sans asm("d0") correspondant, et même des asm("d3"), asm("a6") etc. Le patch pour les routines elles-mêmes est déjà prêt, comme l'est la mise à jour correspondante du système d'autogénération des headers et de la documentation, donc ça sera introduit dès TIGCC 0.95 bêta 1 ou 2.

> Peut-être, mais elle n'est pas égale à 0, et c'est ce qui compte! Oui, et la probabilité pour que TIGCC 0.95 soit un fake, et qu'en réalité vous soyez une organisation occulte visant à prendre le contrôle de tigcc.ticalc.org, supprimer toutes les sources du serveur, et enfin faire une opération commando pour supprimer les sources de TIGCC de tous les ordinateurs la possédant - tout ça pour relancer les ventes de casio - est strictement positive. C'est vrai que ça aussi, c'est une hypothèse à ne pas écarter! Méfiez-vous...

> S'il suffit de 5 minutes pour supprimer l'utilisation d'une extension, autant ne pas utiliser cette extension dès le départ, et donc autant ne pas la permettre dans le compilateur!
Alors dans la prochaine version de TIGCC mettez un warning non désactivable si on utilise une extension qui n'est pas prévue d'être implémentée dans GTC

On n'y pense même pas. Tu n'as pas l'air de t'intéresser même un minimum de la compatibilité GTC->TIGCC, donc nous on s'en contrefiche de la compatibilité TIGCC->GTC. La compatibilité dans le sens TIGCC->GTC ne nous apporte rien (ce n'est qu'à toi qu'elle apporterait quelque chose), donc si tu ne coopères pas pour la compatibilité GTC->TIGCC qui est celle qui nous intéresse, tant pis pour toi.

> Je n'ai jamais dit qu'on met tous les 200 KO dans la RAM en même temps! Mais en archive...

Le contexte de la citation parlait de RAM, pas d'archive. Il y a suffisamment de place en archive.

> > un code source et de la place pour l'exectutable, si on a en plus on a d'autre prog sur ca calc, ca commence a faire limité.
> Ben, si on veut développer un gros projet on-calc, on ne devrait pas s'étonner de ne pas avoir la place pour d'autres programmes. C'est une des raisons pour lesquelles je dis que la programmation on-calc n'est pas une bonne idée en pratique. Sauf que GTC ne prend que 100 ko donc c'est une bonne idée, d'où l'intérêt de ne pas avoir un compilo de 200 ko.

Ce n'est pas la différence entre 100 KO et 200 KO qui y changera quoi que ce soit, désolé.

> Je pense plutôt aux fonctionnalités qui n'y sont pas parce que tu n'as pas trouvé d'implémentation compacte, pas aux fonctionnalités qui y sont. (Cf. contexte de la citation.) Alors toutes les fonctionnalités déjà implémentées sont super-optimisées et celles qui ne sont pas programmées pourraient être implémenté de manière 10x plus petite? Bizarre...

Pas bizarre du tout, sachant que les fonctionnalités qui y sont sont celles pour lesquelles tu as trouvé une implémentation efficace, et celles qui n'y sont pas sont celles pour lesquelles tu n'en as pas trouvé, et pour lesquelles on a donc une plus grande probabilité de pouvoir faire mieux que toi.

> Tu en as déjà une: asm("")!
Sauf que si je mets de l'assembleur syntaxe GTC sous un asm("") vous allez pas être contents (et moi non plus d'ailleurs)

Ce n'est quand-même pas la syntaxe de l'assembleur qui est la difficulté, j'espère. Ce n'est pas compliqué du tout de parser la syntaxe GNU.

> Il n'y a pas de "problème". C'est juste que quelqu'un pourrait avoir un algorithme efficace auquel tu n'as pas pensé pour implémenter une extension.
J'attends les suggestions

Sans les sources de ce qu'il y a déjà, il est difficile de suggérer un algorithme qui se place dans le contexte.

> À titre d'exemple, au lieu d'avoir un add.l et un addx.l pour faire la somme, on aura une demi-douzaine d'instructions pour tester le débordement du long de poids faible.
move.l (a0),d0
add.l d0,(a1)
move.l 4(a0),d0
addx.l d0,4(a1) 4 au lieu de 2, et de toutes façons c'est ce que TI-GCC fera s'il n'a pas assez de registres (2 registres par variable ça fait bcp...)

N'importe quoi! Il n'y a pas d'instruction "add with carry" en C, donc on est obligés de coder un truc du style:
z.lslong=(unsigned long)x.lslong+(unsigned long)y.lslong;
z.mslong=(unsigned long)x.mslong+(unsigned long)y.mslong+(((signed long)((unsigned long)x.lslong+(unsigned long)y.lslong)>0 && (signed long)x.lslong<0 && (signed long)y.lslong<0) || ((signed long)((unsigned long)x.lslong+(unsigned long)y.lslong)<0 && (signed long)x.lslong>0 && (signed long)y.lslong>0));
Je veux voir ton optimiseur convertir ça en les 4 instructions que tu as citées.

> Donc tu refuses d'implémenter le standard C, donc ton compilateur n'est pas un compilateur C. Appelle-le comme tu veux, mais pas "compilateur C".
TIGCC accepte ({0;}) qui est du code C invalide, donc ce n'est pas un compilateur C non plus (et le mode "compilateur C" comme tu dis ne fonctionne pas avec TIGCC)

Je ne suis pas d'accord. Ce qui compte vraiment, c'est qu'il accepte le code C valide. Bon d'accord, il devrait donner des diagnostics pour le code invalide (et GCC le fait avec -pedantic), mais ce n'est pas vraiment important.

> Et que j'utilise ça dans mes programmes.
Ca doit être loin d'être indispensable, et très facile à contourner. Ou alors donne-moi un exemple

http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=89.topic
ESI xnvars[degx+1];
Bon, on pourrait peut-être utiliser alloca ici, mais les variable-length arrays ont l'avantage:
* d'être standard (ISO C99). alloca n'est pas une fonction C standard (mais POSIX à ce qu'il me semble)!
* qu'on peut précisément contrôler quand ils sont désalloués (à la fin du bloc, donc on peut placer un bloc judicieusement). Les variables alloués avec alloca restent allouées jusqu'à la fin de la fonction.

> > soit parce qu'elles n'ont jamais et/ou ne seront certainement jamais utilisées...
> Ca non plus. (Désolé, mais dès qu'une extension existe, il y a toujours quelqu'un pour l'utiliser.)
Trouve moi un seul prog sur ticalc.org qui l'utilise (et qui ne soit pas de toi )

Ce n'est pas parce que ce n'est pas utilisé par un programme sur ticalc.org que ce n'est pas utilisé par un programme (qui n'est pas forcément un programme pour calculatrices). Tu as dit que personne ne l'utilise, et ce n'est certainement pas vrai.

> > Non. Quel est l'intérêt?
> Que c'est prévu par le standard. Désolé mais ça ne sert absolument à rien sur TI, donc je ne l'implémente pas. Je n'en ai rien à faire d'avoir le certificat "ISO C99". Tout ce que je veux c'est que ça soit facile de programmer sous GTC et de porter des programmes vers GTC.

Donc tu ne fais pas un compilateur C, mais un compilateur d'un sous-ensemble (subset) du C. Dis-le clairement au lieu de faire passer ton compilateur pour un compilateur C!

> Les directives d'alignement s'appliquent tout à fait! Par exemple, __attribute__((aligned(2))) char x[4]="toto"; qui permet d'utiliser un move.l pour lire les 4 octets. Et il y a aussi d'autres attributs qui s'appliquent. Par exemple __attribute__((may_alias)), qui a été introduit avec GCC 3.3, et qui se retrouvera de partout dans les nouvelles sources (y compris nos headers), parce que GCC 3.3 donne un warning quand on ne respecte pas les règles de "strict aliasing".
Si tu veux je peux supporter __attribute__((aligned))

Fais-le alors.

Et __attribute__((may_alias)) n'a aucun sens pour GTC (mais il a tout de même le comportement attendu)

Ignore-le alors, si GTC ne gère de toute façon pas l'aliasing, le fait d'ignorer la directive sans warning ou erreur ne dérangera personne (au contraire).

XDanger a écrit :
"short itoa_ushort_10_extended(register unsigned char * asm("a1"), register unsigned short asm("d1"), register unsigned short asm("d2"), register BOOL asm("d3")) __attribute__((__regparm__(4)));" Cette déclaration est donc invalide sous GTC ?

Oui.

> Je pense qu'il faut rapidement que tu prennes un cours de Mathématiques.
> Tu ne fais qu'affirmer, affirmer et réaffirmer sans aucun essai d'argumentation et encore moins de démonstration.

Sors de ta bulle, de ton petit monde idéal où tout est aussi simple et logique qu'en mathématiques. On dirait que tu ne communiques pas beaucoup dans la vraie vie :/


> Tu as vu la taille de TIGCC ? Tu crois qu'il est possible de la réduire à 100 ko en gardant toutes les fonctionnalités ???????
>> Je ne dis pas que c'est forcément possible, mais qu'il n'est pas du tout évident que ce soit impossible.


Pffff Même réponse que précédemment.


> Et puis tu sais bien que tu es réputé pour être quelqu'un de très mauvaise foi. Tout le monde le dis.
>> Non, il n'y a que toi à le répéter à longueur de journée. Demande à XDanger s'il trouve que je suis de mauvaise foi.

XDanger est tout le monde ? Tu sais bien que beaucoup de monde t'a déjà critiqué pour ta mauvaise foi (entre autres : moi, sBibi, PpHd, Pollux, Uther Lightbringer, godzil, et les nombreuses personnes qui avaient participé au topic "La vérité sur Kevin Kofler") et quand je discute de toi avec des membres du forum qui ne postent pas dans nos bagarres, ils le disent aussi.


> Tu préfères donc me traîter de débutant plutôt que d'avouer d'avoir tord.

Tout à fait, on a tort de penser que la taille d'une telle fonction ne peut pas être réduite de 90 %


> Tu peux trouver que Richard Stallman est "con", mais moi, je n'ai fait que le citer, donc je n'y suis pour rien.

T'as rien compris. Il as raison dans le contexte qu'il évoque : les logiciels de rediffusion illégale ("Cooperation is more important than copyright."). C'est toi que je trouve con à détourner son opinion pour parler des logiciels libres de diffusion (GTC).
J'espère que tu as un exemple clair de ta mauvaise foi, puisque tu en réclames depuis un moment. Celui là est des plus clairs


> Et Pollux qui refuse de reconnaitre que TIGCC est libre parcequ'il y a trop de logiciels a télécharger.
>> #rotfl#

Pour une fois que c'est toi qui peut rire de lui


> il me semble que les prototypes du style:
> fonction(short x asm("d0"), short y asm("d1")) sont suportés non?
> Car ca c'est vraiment indispensable
>> Justement non! C'est une des raisons pour lesquelles je dis que GTC sera inutilisable!

Et allez, il rajoute une couche supplémentaire de mauvaise foi
Puisque tu ne t'en rend pas compte, on va t'expliquer. Alors, mon petit, sache qu'une fonctionnalité en moins sur un programme ne rend pas inutilisable tout le reste. Ca rend le programme "moins utilisable", et non pas inutilisable pour tout. Ayé, il a compris ?


> Donc tu refuses d'implémenter le standard C, donc ton compilateur n'est pas un compilateur C

Tu as raison, c'est un compilateur Pascal...


> Et que j'utilise ça dans mes programmes.

Pas tout le monde. Il y a un moyen de s'en passer donc c'est pas indispensable.


> Quel est l'intérêt?
>> Que c'est prévu par le standard.

Génial
Il t'a expliqué que l'intérêt n'est pas absolu.


Kevin, je veux bien avoir tort sur certains points, c'est à dire que certaines de tes réponses sont justes, mais n'oublie pas que toi aussi tu peux avoir tort sur certains points (beaucoup à mon avis). Tu as l'air d'oublier ça, surtout quand on est plusieurs à te rabacher mille fois les même choses.



Pollux : il y a un seul point sur lequel j'approuve Kevin : la syntaxe asm {}; Je trouve qu'il vaudrait mieux avoir la syntaxe officielle asm ("");

> Oui, et la probabilité pour que TIGCC 0.95 soit un fake, et qu'en réalité vous soyez une organisation occulte visant à prendre le contrôle de tigcc.ticalc.org, supprimer toutes les sources du serveur, et enfin faire une opération commando pour supprimer les sources de TIGCC de tous les ordinateurs la possédant - tout ça pour relancer les ventes de casio - est strictement positive. C'est vrai que ça aussi, c'est une hypothèse à ne pas écarter! Méfiez-vous...

Je cherchais un bon moyen de montrer que son raisonnement mathématique appliqué au monde réel était insensé. Magnifique

> Tout ce que je veux c'est que ça soit facile de programmer sous GTC et de porter des programmes vers GTC.
Et tu as réussit. GTC rendra de grand services à plein de monde



XDanger > compilateurs non standards, incompatibles avec le compilateur standard
Compilateur avec certaines syntaxes non standard, mais il est compatible avec le compilateur standard dans l'ensemble.
Ca me semble plus juste. Je ne dis pas que c'est la description LA plus juste. Mais ça me semble un peu meilleur.
Sérieusement, Lionel, tu ne trouves pas ?

> Ce n'est pas la différence entre 100 KO et 200 KO qui y changera quoi que ce soit, désolé.
Bien sûr Ce n'est que 16 % de Flash en moins...


> de par ton allocateur de registres pourri

Mais quel blaireau ! Tu as quels problèmes pour être aussi con en ce moment ?
Avant d'insulter son travail, fais-en autant, et mieux. On n'arrête pas de te répéter qu'il n'est guère possibile de faire mieux
C'est quoi ta maladie ?
- La surdité intellectuelle (maladie que je viens d'inventer, qui se dit des personnes dont l'intelligence est sourde aux explications des autres)

Thibaut, tu passes les bornes. Il y a des trucs pour lesquels tu n'as visiblement aucune leçon à recevoir de personne, ce sont les attaques personnelles et la mauvaise foi !

>> Oui, et la probabilité pour que TIGCC 0.95 soit un fake, et qu'en réalité vous soyez une organisation occulte visant à prendre le contrôle de tigcc.ticalc.org, supprimer toutes les sources du serveur, et enfin faire une opération commando pour supprimer les sources de TIGCC de tous les ordinateurs la possédant - tout ça pour relancer les ventes de casio - est strictement positive. C'est vrai que ça aussi, c'est une hypothèse à ne pas écarter! Méfiez-vous...

> Je cherchais un bon moyen de montrer que son raisonnement mathématique appliqué au monde réel était insensé. Magnifique
N'importe quoi, mais vraiment n'importe quoi... Pollux n'a pas autre chose à faire (entre autres, rendre moins mauvais son compilateur) plutôt que de faire ça ?

Y'a des foit ou j'ai envie de faire /ignore Kevin Kofler, Thibaut, Timad, XDanger ca rendrait parfois les débats beaucoup plus clair et plus conviviaux quoique pour une fois Timad n'y est pas pour grand chose.
Alors je vais résumer ma pensée en 2 mots sur ce sujet.
GTC je le veut et vite qu'il soit en K&R, ANSI C ou presque GNU C ca sera une sacrée avancée.

Uther tu fait :

tigcc tigcc.c

sa ira plus vite

Thibaut a écrit :
> Je pense qu'il faut rapidement que tu prennes un cours de Mathématiques.
> Tu ne fais qu'affirmer, affirmer et réaffirmer sans aucun essai d'argumentation et encore moins de démonstration.
[smiley insolent supprimé] Sors de ta bulle, de ton petit monde idéal où tout est aussi simple et logique qu'en mathématiques. On dirait que tu ne communiques pas beaucoup dans la vraie vie :/

Si toi, tu communiquais suffisamment dans la vraie vie, tu te rendrais compte que personne ne te croira quoi que ce soit si tu affirmes sans arrêt et n'argumentes rien.

> Tu as vu la taille de TIGCC ? Tu crois qu'il est possible de la réduire à 100 ko en gardant toutes les fonctionnalités ???????
>> Je ne dis pas que c'est forcément possible, mais qu'il n'est pas du tout évident que ce soit impossible.


Pffff Même réponse que précédemment.

Évidemment que tu n'as pas cité l'argument qui suit, qui montrerait à quel point ton éclatement de rire est ridicule.
À des fins de référence, voilà ce que Thibaut a omis de la citation: "Tout le monde ici disait qu'il était "évident" qu'un émulateur de Game Boy pour TI-89/92+/V200 était impossible, et pourtant... Mais ça n'a pas fait réfléchir certains apparemment."
Et je revois à quel point ça n'a pas fait réfléchir un certain Thibaut...

> Et puis tu sais bien que tu es réputé pour être quelqu'un de très mauvaise foi. Tout le monde le dis.
>> Non, il n'y a que toi à le répéter à longueur de journée. Demande à XDanger s'il trouve que je suis de mauvaise foi.
XDanger est tout le monde ? Tu sais bien que beaucoup de monde t'a déjà critiqué pour ta mauvaise foi (entre autres : moi, sBibi, PpHd, Pollux, Uther Lightbringer, godzil, et les nombreuses personnes qui avaient participé au topic "La vérité sur Kevin Kofler") et quand je discute de toi avec des membres du forum qui ne postent pas dans nos bagarres, ils le disent aussi.

Les gens que tu cites, ce sont tous des fanatiques du mode kernel qui cherchent un "argument" facile pour ne pas me prendre au sérieux parce qu'ils n'ont aucune réponse valable à mes arguments. Je ne pense pas qu'ils me trouvent réellement de mauvaise foi.

> Tu préfères donc me traîter de débutant plutôt que d'avouer d'avoir tord.

Tout à fait, on a tort de penser que la taille d'une telle fonction ne peut pas être réduite de 90 %

Ben oui, si Pollux n'a pas pensé au bon algorithme, il est tout à fait possible qu'on en trouve un ("le bon") qui prend 10 fois moins de place que ceux qu'il avait en tête! Je ne parle pas d'optimiser une fonction existante sans changer l'algorithme, mais de la coder de manière totalement différente que ce qu'envisageait Pollux!

> Tu peux trouver que Richard Stallman est "con", mais moi, je n'ai fait que le citer, donc je n'y suis pour rien.

T'as rien compris. Il as raison dans le contexte qu'il évoque : les logiciels de rediffusion illégale ("Cooperation is more important than copyright."). C'est toi que je trouve con à détourner son opinion pour parler des logiciels libres de diffusion (GTC).
J'espère que tu as un exemple clair de ta mauvaise foi, puisque tu en réclames depuis un moment. Celui là est des plus clairs

Non, c'est toi qui détournes ses propos et qui te montres de mauvaise foi. Tu n'as pas du tout compris l'esprit GNU. Si tu avais lu le lien indiqué dans la citation, tu saurais que "Proprietary software" regroupe:

Proprietary software is software that is not free or semi-free. Its use, redistribution or modification is prohibited, or requires you to ask for permission, or is restricted so much that you effectively can't do it freely.

(emphasis mine). Ben oui, un logiciel où la source n'est pas donnée est un logiciel propriétaire, et rentre tout à fait dans la citation que j'avais donnée! Cf. aussi: http://www.gnu.org/philosophy/free-sw.html. Lis les propos en question avant de m'accuser de les détourner, et tu te rendras compte que c'est toi qui les détournes! Une des libertés fondamentales qu'un logiciel doit offrir pour être libre et pas propriétaire est:

The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

(emphasis mine). Compris?

> il me semble que les prototypes du style:
> fonction(short x asm("d0"), short y asm("d1")) sont suportés non?
> Car ca c'est vraiment indispensable
>> Justement non! C'est une des raisons pour lesquelles je dis que GTC sera inutilisable!

Et allez, il rajoute une couche supplémentaire de mauvaise foi Puisque tu ne t'en rend pas compte, on va t'expliquer. Alors, mon petit, sache qu'une fonctionnalité en moins sur un programme ne rend pas inutilisable tout le reste. Ca rend le programme "moins utilisable", et non pas inutilisable pour tout. Ayé, il a compris ?

Alors sache qu'il y a des fonctionnalités qui s'appellent "fonctionnalités fondamentales", l'absence desquelles rend un programme utilisable. Appellerais-tu un navigateur HTML qui ne comprend pas la balise <A> "utilisable"? Et pourtant, ce n'est qu'"une fonctionnalité en moins sur un programme".

> Donc tu refuses d'implémenter le standard C, donc ton compilateur n'est pas un compilateur C
Tu as raison, c'est un compilateur Pascal...

Non plus. Je ne sais pas si cette idée t'est déjà passée par la tête, mais sache qu'il y a aussi autre chose que les compilateurs C et les compilateurs Pascal au monde. En l'occurrence, il s'agit d'un compilateur d'un langage propriétaire qui se recoupe en partie avec le C.

> Et que j'utilise ça dans mes programmes.
Pas tout le monde. Il y a un moyen de s'en passer donc c'est pas indispensable.

Il y a peut-être un moyen de s'en passer, mais c'est dans le standard, et c'est réellement utilisé, donc c'est indispensable.

> Quel est l'intérêt?
>> Que c'est prévu par le standard.

Génial Il t'a expliqué que l'intérêt n'est pas absolu.

Ben, il n'a pas compris ce qu'est un standard alors. Un "compilateur C" qui ne comprend pas le C standard n'est pas un compilateur C. Si on a un compilateur qui ne comprend pas encore 100% du standard, il faut travailler dans ce sens comme le fait GCC pour l'ISO C99 plutôt que de traîter des fonctionnalités du standard d'"inutiles" comme le fait Pollux.

> Oui, et la probabilité pour que TIGCC 0.95 soit un fake, et qu'en réalité vous soyez une organisation occulte visant à prendre le contrôle de tigcc.ticalc.org, supprimer toutes les sources du serveur, et enfin faire une opération commando pour supprimer les sources de TIGCC de tous les ordinateurs la possédant - tout ça pour relancer les ventes de casio - est strictement positive. C'est vrai que ça aussi, c'est une hypothèse à ne pas écarter! Méfiez-vous...

Je cherchais un bon moyen de montrer que son raisonnement mathématique appliqué au monde réel était insensé. Magnifique

L'"argument" que tu cites est très loin d'être magnifique, il est totalement ridicule. Tu ne te rends même pas compte à quel point tu te ridiculises en traîtant cet argument ridicule de "magnifique".

> Tout ce que je veux c'est que ça soit facile de programmer sous GTC et de porter des programmes vers GTC.
Et tu as réussit. GTC rendra de grand services à plein de monde

Je ne pense pas. Il y a trop de limitations.

XDanger
> compilateurs non standards, incompatibles avec le compilateur standard Compilateur avec certaines syntaxes non standard, mais il est compatible avec le compilateur standard dans l'ensemble.

Pas du tout. Il y a même une grande partie du standard ISO C99 qu'il ne comprend pas. Et aussi pas mal d'autres extensions du compilateur "standard de facto" TIGCC.

Ca me semble plus juste. Je ne dis pas que c'est la description LA plus juste. Mais ça me semble un peu meilleur.

Pas du tout. Tu déformes complètement la réalité.

Thibaut a écrit :
> Ce n'est pas la différence entre 100 KO et 200 KO qui y changera quoi que ce soit, désolé.
Bien sûr Ce n'est que 16 % de Flash en moins...

Ce ne sont pas 100 KO qui feront la différence quand il manque plusieurs MO pour pouvoir travailler correctement. Par exemple, tu comptes faire comment pour les sauvegardes des anciennes versions? À titre d'exemple, le répertoire de travail de Backgammon fait plus de 6 MO.

> de par ton allocateur de registres pourri

Mais quel blaireau ! Tu as quels problèmes pour être aussi con en ce moment ?
Avant d'insulter son travail, fais-en autant, et mieux. On n'arrête pas de te répéter qu'il n'est guère possibile de faire mieux

Il est certainement possible de faire un allocateur de registres compatible avec le passage par registres en sa version complète. Celui de Pollux ne l'est pas, donc il est "pourri". Compris?

XDanger
a écrit : Thibaut, tu passes les bornes. Il y a des trucs pour lesquels tu n'as visiblement aucune leçon à recevoir de personne, ce sont les attaques personnelles et la mauvaise foi !

Et voilà. Comme quoi ce n'est pas moi qui suis de mauvaise foi ici.

vous pouvez pas faire des topic plus cours avec de veritables arguments...

Kevin Kofler a écrit :
Les gens que tu cites, ce sont tous des fanatiques du mode kernel qui cherchent un "argument" facile pour ne pas me prendre au sérieux parce qu'ils n'ont aucune réponse valable à mes arguments. Je ne pense pas qu'ils me trouvent réellement de mauvaise foi.

Merci de me traiter de fanatique, ainsi que sBibi et Uther...

Thibaut
a écrit : Mais quel blaireau ! Tu as quels problèmes pour être aussi con en ce moment ?

Contredisez vous autant que vous voulez dans des posts les plus longs possible, mais vous pouvez éviter ce genre d'insultes, d'autant plus qu'elles n'apportent pas grand chose dans l'argumentation, hmm ?
(je ne vise pas uniquement Thibaut, n'allez pas considerer ce post comme une quelconque prise de position)

> N'importe quoi! Il n'y a pas d'instruction "add with carry" en C, donc on est obligés de coder un truc du style
T'as entendu parler de l'asm inline?

> ce n'est pas vraiment important
Le fait de compiler sans problème les extensions inutilisées est, dans la perspective de GTC, pas vraiment important non plus. Et tant pis si tu n'es pas d'accord.

> qu'on peut précisément contrôler quand ils sont désalloués
Le compilo le fait avec quoi? link, ou bien il pushe la taille allouée sur la pile?

> Ce n'est pas parce que ce n'est pas utilisé par un programme sur ticalc.org que ce n'est pas utilisé par un programme (qui n'est pas forcément un programme pour calculatrices). Tu as dit que personne ne l'utilise, et ce n'est certainement pas vrai.
Mais justement, tout ce que je dis là n'est vrai que pour les calculatrice! Je m'en contrefous que la version actuelle de GTC compile pour les vieux macs, parce qu'en plus il génère un 89z. Certaines de ces extensions sont là uniquement pour certaines exigences sur PC, et sont inutiles sur TI. Je n'implémente pas celles-là. Et évidemment que toute extension a une utilité dans un contexte donné (sinon ils ne l'auraient pas rajouté ) mais ce contexte ne s'applique pas forcément aux TI.

> Donc tu ne fais pas un compilateur C, mais un compilateur d'un sous-ensemble (subset) du C. Dis-le clairement au lieu de faire passer ton compilateur pour un compilateur C!
Exactement, je n'ai jamais dit que GTC était un compilateur C 100% ANSI. D'ailleurs dans la docs de toutes les betas que j'ai distribué j'ai toujours dit que GTC était quasiment ANSI.

> Ignore-le alors, si GTC ne gère de toute façon pas l'aliasing, le fait d'ignorer la directive sans warning ou erreur ne dérangera personne (au contraire).
C'est ce que je fais Et c'est pour ça que je mets N/A plutôt que non.

> CalcRogue. http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=90.topic.
Les fichiers ne sont plus sur le serveur...

> Cette version est préhistorique, et en particulier la documentation de GCC n'y est pas du tout à jour.
OK, je vais d/l TIGCC 0.94 sp1

Apres le débat kernel vs nostub, Yaronet vous presente en exclusivité le débat TIGCC vs GTC

Toujours plus passionnant que jamais, des rebomdissement à vous couper le soufle, en un seul mot: grandiose...

PS: pour ceux qui aime la lecture, ils vont être servi
PS 2: Le topic parlait normalement de CC. C fou comme les dérapages sont fréquents ici...
PS 3: heu... j'avais juste envi de mettre un troisieme PS

Ceci était un communiqué du ACM (Au Chiote Microsoft)

Pollux a écrit :
> N'importe quoi! Il n'y a pas d'instruction "add with carry" en C, donc on est obligés de coder un truc du style T'as entendu parler de l'asm inline?

Oui, mais si un compilateur m'oblige à écrire de l'assembleur inline pour des fonctions fondamentales comme celle-ci, le compilateur ne sert à rien! L'intérêt d'un compilateur est justement de ne pas avoir à coder en assembleur!

> ce n'est pas vraiment important Le fait de compiler sans problème les extensions inutilisées est, dans la perspective de GTC, pas vraiment important non plus.

Ta perspective n'est donc pas la bonne.

> qu'on peut précisément contrôler quand ils sont désalloués Le compilo le fait avec quoi? link, ou bien il pushe la taille allouée sur la pile?

Il fait ce qu'il veut. Mais GCC fait du push/pop.

> Ce n'est pas parce que ce n'est pas utilisé par un programme sur ticalc.org que ce n'est pas utilisé par un programme (qui n'est pas forcément un programme pour calculatrices). Tu as dit que personne ne l'utilise, et ce n'est certainement pas vrai.
Mais justement, tout ce que je dis là n'est vrai que pour les calculatrice! Je m'en contrefous que la version actuelle de GTC compile pour les vieux macs, parce qu'en plus il génère un 89z. Certaines de ces extensions sont là uniquement pour certaines exigences sur PC, et sont inutiles sur TI. Je n'implémente pas celles-là. Et évidemment que toute extension a une utilité dans un contexte donné (sinon ils ne l'auraient pas rajouté ) mais ce contexte ne s'applique pas forcément aux TI.

Mais qui te dit que les "Hex Floats" ne sont pas intéressants pour un programme pour TI-89/92+/V200? Si tu veux coder, à titre d'exemple, 49/256, alors les "Hex Floats" te seront bien utiles.

> CalcRogue. http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=90.topic. Les fichiers ne sont plus sur le serveur...

http://www.gis.net/~wssddc/jimmy_b/

> Cette version est préhistorique, et en particulier la documentation de GCC n'y est pas du tout à jour. OK, je vais d/l TIGCC 0.94 sp1

On en est à la SP4 là!
Mais si tu télécharges sur ticalc.org ou sur notre site, c'est de toute façon ce que tu auras.

Oui, godzil, PpHd, sBibi, Uther Lightbringer, js/TiMad, Thibaut, Vark, RAGE2000 pour ne citer que les principaux (il se peut que j'en oublie quelques uns; ceux-là sont ceux avec lesquels je me suis le plus enguirlandé), sont des fanatiques.

> Y'a des foit ou j'ai envie de faire /ignore Kevin Kofler, Thibaut, Timad, XDanger ca rendrait parfois les débats beaucoup plus clair et plus conviviaux quoique pour une fois Timad n'y est pas pour grand chose.
Le "pour une fois" est très important...

> qu'il soit en K&R, ANSI C ou presque GNU C ca sera une sacrée avancée.
Le "presque" est très important. Pour la programmation on-calc, oui, GTC sera une avancée. Pour la programmation on-PC, pas du tout. Un compilateur techniquement inférieur au standard de facto et rendu volontairement incompatible avec le standard de facto n'est vraiment pas une avancée... C'est une reculade car ça crée des incompatibilités de façon parfaitement arbitraire et stupide.


> > N'importe quoi! Il n'y a pas d'instruction "add with carry" en C, donc on est obligés de coder un truc du style
> T'as entendu parler de l'asm inline?
La chose qui n'est pas gérée sur ton truc et dont on sait se servir et dont on a besoin, oui, on en a entendu parler...

> Et tant pis si tu n'es pas d'accord.
Et tant pis pour toi si tu fais n'importe quoi... Ca n'est certainement pas à TIGCC que ça va faire le plus de tort...

> Mais qui te dit que les "Hex Floats" ne sont pas intéressants pour un programme pour TI-89/92+/V200? Si tu veux coder, à titre d'exemple, 49/256, alors les "Hex Floats" te seront bien utiles.
En effet. Mais laisse tomber, tu vois bien qu'il ne veut visiblement pas comprendre...


Je n'ai lu que les messages jusqu'au #350 posté par Kevin.

XDanger a écrit :
Oui, godzil, PpHd, sBibi, Uther Lightbringer, js/TiMad, Thibaut, Vark, RAGE2000 pour ne citer que les principaux (il se peut que j'en oublie quelques uns; ceux-là sont ceux avec lesquels je me suis le plus enguirlandé), sont des fanatiques.

Surveille un peu tes propos toi ok ?

Tu a des arguments valables pour affirmer ça ?

Si ya des personnes qu'on peut traiter de fanatique toi et kevin vous en faites partit alors
Si je suis fanatique, tout le monde l'est...
Si je reagis a ses propos, c'est pasque je deteste plus que tout me faire insulter, surtout en public, surtout quand il n'y a aucune raison à cela

XDanger
a écrit : Oui, godzil, PpHd, sBibi, Uther Lightbringer, js/TiMad, Thibaut, Vark, RAGE2000 pour ne citer que les principaux (il se peut que j'en oublie quelques uns; ceux-là sont ceux avec lesquels je me suis le plus enguirlandé), sont des fanatiques.

tu m'expliques en quoi suis-je fanatique ?
je n'ai jamais fais un seul programme kernel, c con hein ?
alors après je suis anti anti-kernel (anti pro-nostub quoi) alors si tu réfléchissait un peu tu verrais que à part kevin et toi y'en a pas beaucoup de fanatiques ...

ah oui et puis que viens faire rage ds cette énumération alors qu'il n'a jamais rien programmé et que s'il a fait 3 posts ds les parties prog, voire même les parties ti ça tient du miracle ?

Oui, godzil, PpHd, sBibi, Uther Lightbringer, js/TiMad, Thibaut, Vark, RAGE2000 pour ne citer que les principaux (il se peut que j'en oublie quelques uns; ceux-là sont ceux avec lesquels je me suis le plus enguirlandé), sont des fanatiques.

Révises ta définition de fanatique. Etre fanatique c'est vivre, se battre pour quelque chose. Je ne pense pas que les personnes que tu cites soient prete à mourrir contre le kernel...

Je remarque que toutes les personnes avec qui tu t'es 'enguirlandé' sont classé dans les fanatiques, je trouce ça étrange :]

Je n'ai lu que les messages jusqu'au #350 posté par Kevin.

Normal, tu écris le 351... tu a des facultés pour voir le futur toi

> Surveille un peu tes propos toi ok ?
Et toi, "parle meilleur"...

> Tu a des arguments valables pour affirmer ça ?
Des posts antérieurs qui se trouvent sur ce forum doivent faire l'affaire, non ?
Petite remarque: ça serait des faits et non pas des arguments (il n'y a pas toujours des arguments dans les posts de ceux que j'ai cités; un des pires pour cela est TiMad, les faits sont là, sur le forum Assembleur TI)...
Insultes, provocations (bien entendu, tout ne vaut pas nécessairement pour tous ceux que j'ai cités)... Ca n'est pas valable, ça ?

XDanger
a écrit : Insultes, provocations (bien entendu, tout ne vaut pas nécessairement pour tous ceux que j'ai cités)... Ca n'est pas valable, ça ?

parce-que Kevin et toi vous ne provoquez pas ?

> Normal, tu écris le 351... tu a des facultés pour voir le futur toi
Et imagine que quelqu'un ait pu poster avant que je poste le #351, et qu'il y ait pu y avoir des choses à redire dans ce qui aurait été posté entretemps ?
C'est d'ailleurs exactement ce qui vient de se passer: le temps que je réponde à #352 (réponse postée en #355), #353 et #354 avaient été postés...
Au cas où tu ne le saurais pas, rédiger un message et le poster ne prend pas un temps nul...

[Lionel Debroux n'a vu que jusqu'au message #355; il se peut très bien que d'autres choses aient été postées entretemps]

et n'en profites pas pour esquiver les autres remarques du post, c'est trop facile

Tiens, qu'est-ce que je disais: #356 a été posté avant que je poste ma réponse (#357).

Idem, je n'ai lu que jusqu'au #357...