GTC : un TIGCC sur votre calculatrice ? - Page 22

Pollux a écrit :
> Je trouve le projet de GTC très interessant mais le top serait de réunir TIGCC et GTC pour faire un compilateur de tonnerre avec des fonctions avancés... C'est extrêmement difficile. GTC et TIGCC fonctionnent très différemment

Et voilà. J'espère que ceux comme Thibaut qui ne me croient pas à moi te croieront à toi au moins.

> Sur GTC, la vitesse de compilation est peut-être plus élevée (on verra les benchs...) Tu peux dire "certainement"...

GCC est connu pour être lent en effet. Mais c'est le prix des optimisations élaborées.

> mais est-ce que ces arguments tiennent vraiment debout (à moins d'être sur des PC totalement dépassés depuis au moins 4 ans) ?
La vitesse de compilation est utile pour le débogage, après rien n'interdit de finaliser avec TI-GCC. Mais par contre la taille on s'en fout effectivement

Tu t'en fous, toi? Nous, on compile TIGCC avec -Os...

Et je le répète, GTC n'est pas principalement destiné à être on-PC.

Répète-le plus fort pour que Thibaut comprenne.

GTC n'est pas du "tout en une passe"
GTC utilise des arbres pour se réprésenter les expressions et les structures de contrôle, puis fait tout un tas d'optimisations sur les arbres (ça fait plein de passes ), génère un code intermédiaire à partir de ces arbres, puis génère de l'ASM à partir de ce code un intermédiaire.

Ah bon? Désolé. Je n'avais pas cette impression d'après tes descriptions vagues du fonctionnement.
GCC fonctionne aussi plus ou moins comme ça (mais la plupart des optimisations sont faites sur la "représentation intermédiaire", pas sur les arbres; ça va probablement changer avec les versions futures, cf. http://gcc.gnu.org/projects/tree-ssa/).

Et tu as l'air de dire que "plus il y a de passes, mieux c'est" - mais il n'y a pas que le nombre de passes, il y a aussi la qualité des algos.

Évidemment. Mais le nombre de passes est quand-même un facteur important.

> création d'un format de .tpr commun pour améliorer la portabilité (je dirais que c'est à Pollux de s'aligner sur votre format)
Bonne idée

Oui, parce que la limitation à un seul fichier .c à la fois, c'est quand-même assez contraignant.

> On lui en fait depuis des mois, des suggestions. Mais il ne les écoute pas. Ça fait longtemps que je lui dis:
> * d'arrêter de rajouter des extensions de langage à GTC qu'il pense lui-même être inimplémentables dans GCC (et de retirer celles qui y sont déjà) Ces extensions sont présentes depuis pas mal de temps.

Vive l'implémentation d'extensions en secret... (C'est ironique, évidemment. )

Par contre, #macro et le changement au cours d'un fichier des options de compilations sont vraiment utiles et sont à mon avis parfaitement implémentables dans TI-GCC (même si je ne connais pas vraiment les détails de la structure interne de GCC).

"Tu m'énerves, Pollux, à tjs vouloir parler de ce que tu ne sais pas!"
Mais je dois avouer que moi non plus, je ne peux pas dire si facilement de manière définitive si c'est implémentable facilement ou non. GCC est très complexe et je ne m'y retrouve toujours pas parfaitement.

J'ajoute que le changement d'options de compilation ne constitue pas une incompatibilité puisqu'on peut très bien faire en sorte que TIGCC les ignore.

Sauf si ça donne du mauvais code quand on l'ignore. Par exemple changement du nombre de registres du passage par registres.

#macro permet, entre autres, d'éviter plein de hacks sales.

Mais c'est difficile à implémenter sans mettre un autre préprocesseur par dessus celui de GCC.

> de passer le temps qu'il passe à rajouter ces extensions à implémenter les fonctionnalités de TIGCC qui manquent à GTC
> mais il s'en fiche.
Je ne m'en fiche pas. Je fais tout ce qui est en mon pouvoir pour avoir un compilo rapide et léger qui puisse fonctionner sur calculatrice, tout en maintenant une bonne compatibilité avec TIGCC. Je suis désolé, mais certaines extensions de TIGCC ne seront jamais dans GTC (à moins que les TI passent à 1 Mo de RAM et un 68k à 30 MHz )

Même pas si quelqu'un les implémente pour toi?

> Nous avons toujours documenté toutes nos extensions de langage. Pollux, lui, m'a pondu une liste largement incomplète à ma demande explicite il y a quelques jours.
Je n'ai pas eu le temps de rédiger une doc complète

Ça aurait dû être fait depuis longtemps. Quand on rajoute une extension, on la documente!

Pour ce qui est des extensions de langage, je ne trouve pas la doc du 'register var asm("rn")' dans TI-GCC.

http://tigcc.ticalc.org/doc/gnuexts.html#SEC99a
(C'est sous "GNU C Language Extensions" / "Variables in Specified Registers" / "Specifying Registers for Function Parameters".)

De même, je ne vois nulle part à quels registres sont affectées les variables pour __regparm__ (mais j'ai peut-être mal cherché...)

Les registres de données dans l'ordre pour les données, les registres d'adresses dans l'ordre pour les pointeurs.
C'est un peu logique, mais tu as raison que je devrais rajouter ça à la documentation.

> Je vous laisse imaginer ce que ça va donner si on implémente ces extensions stupides élaborées en secret par Pollux sans jamais discuter de la faisabilité pour d'autres compilateurs avec les mainteneurs de ces autres compilateurs. Tu crois sincèrement que le préprocesseur de GCC va évoluer fondamentalement?

Oui! Il évolue constamment! Par exemple:
* GCC 3.1 a modifié la manière de laquelle le préprocesseur "revient en arrière" dans certaines situations. J'ai été obligé de réécrire complètement notre code pour SYMSTR.
* cpp1.exe a été intégré à cc1.exe dans GCC 3.3
* GCC 3.4 rajoutera le support pour les headers précompilés, donc encore des changements énormes au préprocesseurs. Une partie de ces changements a déjà été rajoutée à GCC 3.3, mais beaucoup ont été rajoutés seulement pour GCC 3.4.

#macro ne demande a priori que des légères modifications dans le préprocesseur.

Je veux voir le patch alors.

MacIntoc
a écrit : L'ancienneté n'est pas une preuve de standart, en informatique, ce serait plutot même le contraire, à la limte.

L'ancienneté est une preuve de standard dans le sens où les nouvelles choses devraient être compatibles avec les anciennes.

je suis d'accord sur ce point. Mais ça aurait ralentis beaucoup l'avancement de la programmation (déjas qu'on l'attend depuis un moment) s'il av fallut parler de chaques extensions pendant 2 mois sur 10 forums (pour que tous le monde soit au courant).

Il aurait suffi d'en parler sur le forum de la TICT. Tous les développeurs de TIGCC le lisent, et je ne suis pas au courant d'autres compilateurs qui essayeraient d'être compatibles avec TIGCC et/ou GTC.

Il doit y avoir une raison valable [au non-support des déclarations dans le for]?

Non, juste ces 2 excuses-là (je cite à chaque fois l'excuse et ma réponse):

>1) ça incite à utiliser des boucles for dans le sens positif
C'est faux. Il n'y a aucune différence de ce point de vue-là entre:
for (int i=1;i<3;i++);
et:
int i;
for (i=1;i<3;i++);
ni entre:
for (int i=2;i>0;i--);
et:
int i;
for (i=2;i>0;i--);

>2) ça incite à déclarer plus de variables-compteur que nécessaire (on déclare une variable par boucle)
Et c'est le boulot de ton allocateur de registres de réutiliser le même registre.

Rien ne vous empèche de rattraper le temps perdu, au lieu de dire que c extensions sont stupide.

Le problème est que ces extensions sont nettement plus difficiles à implémenter dans GCC que dans GTC. C'est pour ça que je dis qu'elles sont mal réfléchies. ("Stupide" n'était peut-être pas le bon mot, je le reconnais.)

> Mais c'est difficile à implémenter sans mettre un autre préprocesseur par dessus celui de GCC.
Je ne crois pas. La seule chose qui change a priori, c'est la possibilité d'avoir des sauts de ligne dans un #define. Dans le pire des cas, tu peux toujours faire un pseudo fgetc(), mais je suis quasiment sûr que GCC peut le supporter sans trop de changements (la gestions des #define ISO impose presque la structure du préprocesseur )

> Même pas si quelqu'un les implémente pour toi?
Non. Ou en tout cas pas on-calc.

Les registres de données dans l'ordre pour les données, les registres d'adresses dans l'ordre pour les pointeurs. C'est un peu logique, mais tu as raison que je devrais rajouter ça à la documentation.

Et surtout s'il y a des arguments en plus, on les rajoute dans l'autre catégorie de registre jusqu'à ce qu'il n'y en ait plus. J'ai dû faire une série de test à GCC pour voir comment il faisait

> GCC 3.1 a modifié la manière de laquelle le préprocesseur "revient en arrière" dans certaines situations. J'ai été obligé de réécrire complètement notre code pour SYMSTR.
? tu peux expliquer?

> cpp1.exe a été intégré à cc1.exe dans GCC 3.3
Et ça change qqch au niveau de la manière de faire le preprocessing?

> GCC 3.4 rajoutera le support pour les headers précompilés, donc encore des changements énormes au préprocesseurs. Une partie de ces changements a déjà été rajoutée à GCC 3.3, mais beaucoup ont été rajoutés seulement pour GCC 3.4.
Ah oui. Mais je ne vois pas ce qui pourrait faire des incompatibilités avec #macro

Pollux a écrit :
> Mais c'est difficile à implémenter sans mettre un autre préprocesseur par dessus celui de GCC. Je ne crois pas. La seule chose qui change a priori, c'est la possibilité d'avoir des sauts de ligne dans un #define.

Ce qui change aussi, c'est de pouvoir avoir des directives du préprocesseur dans l'expansion des macros! Et ça, je pense que ce n'est pas du tout prévu dans GCC!

Et surtout s'il y a des arguments en plus, on les rajoute dans l'autre catégorie de registre jusqu'à ce qu'il n'y en ait plus.

Ah bon... Je ne savais pas ça. Le patch tel que nous l'avons récupéré était très mal documenté. Mais ce n'est pas vraiment de notre faute.

> GCC 3.1 a modifié la manière de laquelle le préprocesseur "revient en arrière" dans certaines situations. J'ai été obligé de réécrire complètement notre code pour SYMSTR. ? tu peux expliquer?

S'il devait vérifier ce qu'était le prochain token pour savoir comment interpréter un token (par exemple, vérifier si le prochain token est une '('), GCC 3.0 faisait un "lookahead", puis jetait le "lookahead" à la poubelle. GCC 3.1 et 3.3 lisent le prochain token normalement, puis font un "back out" de ce token pour revenir en arrière.

> cpp1.exe a été intégré à cc1.exe dans GCC 3.3 Et ça change qqch au niveau de la manière de faire le preprocessing?

Oui. Mais je ne connais pas plus de détails que ça. Les changelogs sont longs.

> GCC 3.4 rajoutera le support pour les headers précompilés, donc encore des changements énormes au préprocesseurs. Une partie de ces changements a déjà été rajoutée à GCC 3.3, mais beaucoup ont été rajoutés seulement pour GCC 3.4.
Ah oui. Mais je ne vois pas ce qui pourrait faire des incompatibilités avec #macro

Que tout changera et que ça me risque de me faire recoder le patch depuis le début.

> Ce qui change aussi, c'est de pouvoir avoir des directives du préprocesseur dans l'expansion des macros! Et ça, je pense que ce n'est pas du tout prévu dans GCC!
L'expansion de macros est censée expander la ligne entière, et il suffit dans le pire des cas de détecter le '\n', de couper la ligne en cours à cet endroit, et de stocker le reste dans un buffer, puis de faire croire à la fonction de lecture de ligne que la ligne suivante est ce qu'il y a dans le buffer. Je ne vois pas comment GCC pour savoir que tu as triché

> Ah bon... Je ne savais pas ça. Le patch tel que nous l'avons récupéré était très mal documenté. Mais ce n'est pas vraiment de notre faute.
Heureusement que je suis là pour vous apprendre comment fonctionne TIGCC

> S'il devait vérifier ce qu'était le prochain token pour savoir comment interpréter un token (par exemple, vérifier si le prochain token est une '('), GCC 3.0 faisait un "lookahead", puis jetait le "lookahead" à la poubelle. GCC 3.1 et 3.3 lisent le prochain token normalement, puis font un "back out" de ce token pour revenir en arrière.
Y a même pas de relecture dans GTC, juste un buffer. Mais ça ne change rien à #macro.

> Que tout changera et que ça me risque de me faire recoder le patch depuis le début.
Ben écoute tu fais comme tu veux
Mais à mon avis c'est parfaitement implémentable...

Pollux a écrit :
> Ce qui change aussi, c'est de pouvoir avoir des directives du préprocesseur dans l'expansion des macros! Et ça, je pense que ce n'est pas du tout prévu dans GCC! L'expansion de macros est censée expander la ligne entière,

Stop, erreur. Le préprocesseur de GCC:
1. traverse le stream de tokens
2. rencontre un token "identifiant"
3. reconnaît l'identifiant comme une macro
4. récupère les arguments de la macro
5. lance le prescan sur les arguments récupérés (ce qui peut entraîner d'autres expansions de macros)
6. copie la définition de la macro en remplaçant les identifiant correspondant aux arguments par les arguments prescannés ci-dessus
7. considère qu'il a fini de traîter la macro et passe au token suivant la ')'.
Pour qu'il comprenne les directives du préprocesseur à l'intérieur de la macro, il faut faire un autre passage du préprocesseur sur les tokens qu'on vient d'insérer. Je doûte fort de la faisabilité de cela.

Et cette fois-ci, je ne pense pas me tromper, vu que j'ai regardé tout ça assez en détail pour implémenter SYMSTR dans GCC 3.1 (l'implémentation de Sebastian ayant cessé de marcher à cause de la modification des lookaheads).

> Ah bon... Je ne savais pas ça. Le patch tel que nous l'avons récupéré était très mal documenté. Mais ce n'est pas vraiment de notre faute.
Heureusement que je suis là pour vous apprendre comment fonctionne TIGCC

Le préprocesseur de GCC:
1. traverse le stream de tokens
2. rencontre un token "identifiant"
3. reconnaît l'identifiant comme une macro
4. récupère les arguments de la macro
5. lance le prescan sur les arguments récupérés (ce qui peut entraîner d'autres expansions de macros)
6. copie la définition de la macro en remplaçant les identifiant correspondant aux arguments par les arguments prescannés ci-dessus 7. considère qu'il a fini de traîter la macro et passe au token suivant la ')'.

Tiens c'est exactement ce que fait GTC (cf "la gestion des #define ISO impose presque la structure du préprocesseur ")
Pas besoin de passe supplémentaire, il suffit que GCC, s'il tombe sur un '\n' au milieu de la ligne en cours, fasse l'opération de buffering que j'ai expliquée plus haut.

Tu placerais ça où dans ces 7 étapes et tu modifierais les étapes existantes comment???

tu t planter de temps, Kevin

Non. J'ai mis un conditionnel parce que c'est du conditionnel. Malgré la remarque de Pollux, le fonctionnement de GCC n'est pas exactement celui de GTC ici. Relis-bien ma description de ce que fait GCC pour voir où est le problème.

bah... j'y connait rien, mais d'aprés la description, le buffering peut intervenir aprés l'étape 4, nan ??

Tu veux couper les lignes avant le prescan, toi? Ça ne m'a pas l'air d'être une bonne idée à première vue.
EDIT: Et surtout c'est faux! On veut couper la définition de la macro en plusieurs lignes, pas les arguments.

Et tiens, je viens d'identifier une ambiguité dans le système de #macro: #identifiant pourrait être:
- une "stringification"
- une directive pour le préprocesseur
Comment exactement faire la différence?

bah... le préscan implique une modification des argument, je suppose, donc pour intervenir, c trop tard.

arf... c koi une stringification ???

MacIntoc
a écrit : bah... le préscan implique une modification des argument, je suppose, donc pour intervenir, c trop tard.

Le prescan modifie en effet les arguments. Mais ce qu'il faut couper en plusieurs lignes, c'est la définition, pas les arguments. Et cela seulement après avoir inséré les arguments dans la définition. Problème: si je me rappelle bien, GCC copie la définition directement en insérant les arguments au fur et à mesure sans moyen de revenir en arrière. Je ne vois pas de moyen de faire repasser le préprocesseur sur ce qu'on vient d'insérer.

arf... c koi une stringification ???

Arf, tu es carrément mal placé pour participer à cette discussion si tu ne sais pas ce que c'est...
http://tigcc.ticalc.org/doc/cpp.html#SEC17

on va dire que je suis pas placé du tous, même

oui, en effet, la stingification peut-être problématique, mais ça doit pouvoir se résoudre relativement facilement.

Pour le reste, par contre, je suis complètement largué

MacIntoc
a écrit : oui, en effet, la stingification peut-être problématique, mais ça doit pouvoir se résoudre relativement facilement.

Tu as l'air d'être complètement passé à côté de l'ambiguité que j'ai faite remarquer. Ce n'est pas la stringification en soi qui est problématique, mais le fait que ça utilise une syntaxe #identifiant. Avec une macro multi-ligne, quand on est en début de ligne, comment distinguer le #identifiant d'une stringification de celui d'une directive de préprocesseur? Et c'est ce que je demande à Pollux (pas à toi, parce que tu vas encore me pondre du non-sens ).

je sais quand même me débrouiller un minimum quand il faut
Et je psense avoir saisis que le problème était de différencier deux écriture identique qui font des choses différente (la stringification (transformé une macro en chaine, c bien ça grosso modo???) et envoyé une directive au préprocesseur), et je continus à penser que ce n'est pas le plus difficile
(et puis lis ma signature).

Je le mettrais dans l'étape 1. "traverser le stream de tokens".

Tu as l'air d'être complètement passé à côté de l'ambiguité que j'ai faite remarquer. Ce n'est pas la stringification en soi qui est problématique, mais le fait que ça utilise une syntaxe #identifiant. Avec une macro multi-ligne, quand on est en début de ligne, comment distinguer le #identifiant d'une stringification de celui d'une directive de préprocesseur?

En principe ce n'est pas ta fonction de lecture du stream initial qui développe la syntaxe #identifiant... (sinon de toutes façons il y aurait des problèmes d'ordre de développement) C ce que j'ai expliqué #636, il suffit, lors de l'appel à internal_getc() (lecture dans le buffer de ligne - je suppose que tu en as un...), lorsqu'on rencontre '\n' de faire un buffering pour tronquer le buffer de ligne et mettre le reste dans un buffer virtuel qui sera lu en lieu et place d'un appel à fgetc()/fgets().

il faut un "s" au conditionnel ?
je croyais que ct "placerai"

(mais je garanti pas...)

Oui, il faut un 's' au conditionnel. Sans 's', c'est du futur.
"Je serai devant mon PC toute la journée demain" -> futur
"C'est dommage, je serais bien allé au cinéma, s'il n'était pas fermé" -> conditionnel

ah merde
dsl

Pollux
a écrit : Je le mettrais dans l'étape 1. "traverser le stream de tokens".

Impossible. Désolé, mais je pense que tu n'as strictement rien compris au fonctionnement du préprocesseur de GCC. À l'étape 1, on ne sait même pas qu'on est devant une macro! Comment veux-tu couper la définition de la macro en plusieurs lignes avant même de savoir que tu as une macro devant toi?

(lecture dans le buffer de ligne - je suppose que tu en as un...)

GCC ne lit rien dans le "buffer de ligne"! Il tokénise les lignes et puis lit tout dans le stream de tokens.

Et visiblement tu n'as pas répondu à ma question: comment distingues-tu entre:

#macro abc(x,y,z)
#include "ijk.h"
#endm

et:

#macro abc(x,y,z)
#x "ijk.h"
#endm

Dans le premier cas, c'est une directive de préprocesseur. Dans le deuxième cas, c'est une stringification.

Et il y a pire: le suivant est du C totalement valide!
#define abc(include) #include
Ça stringifie le paramètre qui comme par hasard s'appelle include. Aucun rapport avec la directive #include. Tu fais quoi avec:

#macro abc(include)
#include "ijk.h"
#endm

??? Visiblement, il y a une ambigüité! Je ne comprends pas comment on peut inventer des extensions sans vérifier qu'elles n'apportent pas d'ambigüités!

Kevin Kofler a écrit :
Impossible. Désolé, mais je pense que tu n'as strictement rien compris au fonctionnement du préprocesseur de GCC. À l'étape 1, on ne sait même pas qu'on est devant une macro! Comment veux-tu couper la définition de la macro en plusieurs lignes avant même de savoir que tu as une macro devant toi?

Arrête de dire encore n'importe quoi

C'est toi qui n'as rien compris : il suffit de rajouter une surcouche à la lecture de caractères dans une ligne, et ce qu'il y ait un #define ou non...

GCC ne lit rien dans le "buffer de ligne"! Il tokénise les lignes et puis lit tout dans le stream de tokens.

Il tokenize tout? Et pendant l'expansion d'une macro, il manipule aussi des tokens?
Enfin bon de toutes façons ça n'empêche pas de faire ce que j'ai dit en remplaçant '\n' par TOKEN_NEWLINE.

Et visiblement tu n'as pas répondu à ma question: comment distingues-tu entre:

#macro abc(x,y,z)
#include "ijk.h"
#endm

et:

#macro abc(x,y,z)
#x "ijk.h"
#endm

Dans le premier cas, c'est une directive de préprocesseur. Dans le deuxième cas, c'est une stringification.

Oui, je le fais comme ANSI le prévoit.
Dans le premier cas,
abc(u,v,w) => #include "ijk.h"
Dans le deuxième cas,
abc(u,v,w) => "u" "ijk.h"

Et il y a pire: le suivant est du C totalement valide!
#define abc(include) #include
Ça stringifie le paramètre qui comme par hasard s'appelle include. Aucun rapport avec la directive #include. Tu fais quoi avec:

#macro abc(include)
#include "ijk.h"
#endm

???

Ton #define donne :
abc(toto) => "toto"
Et ton #macro :
abc(toto) => "toto" "ijk.h"

Visiblement, il y a une ambigüité! Je ne comprends pas comment on peut inventer des extensions sans vérifier qu'elles n'apportent pas d'ambigüités!

Pas d'ambiguïté. Si qqun veut utiliser une macro, c'est évidemment à lui de faire attention à ne pas appeler ses paramètres 'include' ou 'define' s'il veut les utiliser pour des directives préprocesseur. Et comme la stringification n'arrive que pour des paramètres, il n'y a aucun risque d'interférence avec des variables globales. (i.e. même avec #define include error (),

#macro abc()
#include "ijk.h"
#endm

incluera le fichier "ijk.h", comme on pouvait s'y attendre)

Je ne comprends pas comment on peut inventer des extensions sans vérifier qu'elles n'apportent pas d'ambigüités!

Bien sûr que si... Tu vois, tu te permets de juger ces extensions alors que tu n'as pas encore compris comment elles fonctionnent

Pollux
a écrit : C'est toi qui n'as rien compris : il suffit de rajouter une surcouche à la lecture de caractères dans une ligne, et ce qu'il y ait un #define ou non...

Pourrais-tu détailler?

Il tokenize tout? Et pendant l'expansion d'une macro, il manipule aussi des tokens?

Oui et oui.

Pas d'ambiguïté.

Si, il y a une ambigüité...

Si qqun veut utiliser une macro, c'est évidemment à lui de faire attention à ne pas appeler ses paramètres 'include' ou 'define' s'il veut les utiliser pour des directives préprocesseur.

... et cela est la résolution de l'ambigüité.

Pollux a écrit :
Bien sûr que si... Tu vois, tu te permets de juger ces extensions alors que tu n'as pas encore compris comment elles fonctionnent

Le fait est qu'en décrivant ton extension, tu n'as pas décrit la résolution de cette ambigüité est une omission, donc une erreur de documentation.

Ta résolution n'est pas la seule possible. Une autre résolution possible serait que #include en début de ligne est toujours la directive du préprocesseur et qu'il faut mettre des parenthèses ou renommer le paramètre pour utiliser la stringification. Mais les 2 résolutions sont possibles et tu en as choisi une, jusque là pas de problème. Le problème, c'est que tu n'as visiblement pas documenté ce choix.

Quelqu'un porte make on-calc. C'est mieux que le format TPR.

Non. Les .tpr sont beaucoup plus simples.

C'est le standard mon cher

huhu ...

PpHd a écrit :
C'est le standard mon cher

Les makefiles sont le standard de facto sous *nix. Pour les TI-89/92+/V200, le standard de facto, ce sont les .tpr. Désolé.