120

Kevin Kofler (./118) :
Tu as 3 plateformes. GCC en a des dizaines

Il manque la moitié des plateformes des TI, y a le 68k mais pas le z80 -->poubelle direct :P

Non, mais sinon ok. Ce que je propose now, c'est que je fournisse les spécs du langage en me plongeant dans les cartons de la photo que j'ai postée, et on fait un backend optionel pour le z80 par exemple.
Tout ce qui passe pas par le port 80, c'est de la triche.

121

oula... Pourquoi poubelle!

pas si vite grin

commencons par les specs oui

122

Squalyl > cross, dsl. Je suis ok pour tout ça. Si d'autres s'y mettent, ca me motivera à m'y mettre autant que je peux aussi.

Sinon pour les testcases, j'ai mis "?" car c'est à vu d'oeil. Des que l'environnement de tests sera mis en place, on pourra comparer des programmes similaires, mais peut-etre que ca sera pas nécessaire si on a le meme backend. Ceci dit, pour rappel, les test en vitesse ont été effectué et meme le vieux compilo d'ETP écrit en VB était entre 70 et 90% de la rapidité de tigcc avec une boucle for qui affiche la variable de ce for.

edit: cross:
"oula... Pourquoi poubelle! " --> non non pas poubelle, j'ai mis un ":P" wink
Tout ce qui passe pas par le port 80, c'est de la triche.

123

squalyl (./119) :
Mais comment peut on comparer un code dans deux langages sources différents? c'est pas forcément représentatif!

Les langages ETP version 1 et C se ressemblaient beaucoup sur le fond (mais je n'ai pas encore vu ce que donne ou va donner la version 2), c'était juste la syntaxe qui était très différente, et le fait que ETP n'a pas de pointeurs.
Je pense m'associer à ce projet, car il présente pour moi plusieurs intérets: backend gcc, ton expérience en maintenance de projets opensource, développement de compilateurs, etc...

Attends, pour l'instant le backend GCC n'existe pas! Quant à ma participation, il ne faut pas oublier que je suis aussi très occupé, que je ne suis intéressé que si je vois que ça vaut le coup d'y investir mon temps limité (donc pour l'instant j'attends de voir l'évolution du frontend). Et je précise aussi que mon intérêt ne se trouve que dans l'intégration avec GCC, les autres backends ne m'intéressent personnellement pas.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

124

125

onur (./122) :
Ceci dit, pour rappel, les test en vitesse ont été effectué et meme le vieux compilo d'ETP écrit en VB était entre 70 et 90% de la rapidité de tigcc avec une boucle for qui affiche la variable de ce for.

Et je rappelle que cette boucle passait presque tout son temps dans les ROM_CALLs d'affichage, la différence en nombre de cycles du code généré par les compilateurs, c'était un facteur, pas un pourcentage. (Je sais, le testcase venait de moi, mais c'était quand-même un mauvais testcase, je m'en suis rendu compte en regardant les résultats.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

126

Lol le testcase était finalement mauvais parce que ca disait pas ce que tu voulais que ca dise wink
Tout ce qui passe pas par le port 80, c'est de la triche.

127

> D'autre part, ici, nous parlons d'ETP studio, et à moins que j'en sois totalement ignorant, tu n'y a pas participé, donc laisse nous discuter, et tes mails perso, tu sais, ils n'ont pas leur place ici.
Tu me mets en cause publiquement, avec raison, dans ./75.
Je réponds publiquement en ./117 que justement, je souhaite aller dans le même sens que ce que tu préconises. Mails perso à l'appui.
Tout ce que tu trouves à faire, c'est de ne réagir que sur un point de mon message non envoyé (qui est pourtant factuel... et pourquoi crois-tu que je n'aie pas envoyé ce message-là ? roll), et de m'indiquer que je suis off-topic ??
Oui, j'arrive en retard, et il y a eu des avancées entre Kevin et onur depuis. Et alors ? Ce matin, figure-toi que j'ai fait autre chose que regarder yAronet...

[EDIT: onur, n'en rajoute pas toi non plus wink ]
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

128

onur (./126) :
Lol le testcase était finalement mauvais parce que ca disait pas ce que tu voulais que ca dise wink

Il ne testait pas la bonne chose, il est évident que les fonctions de TI sont les mêmes dans les 2 cas, donc si tout le temps est passé là-dedans, on n'a pas mesuré la bonne chose!

Malheureusement, tu as refusé à l'époque de faire un autre test qui met en cause uniquement le code généré par le compilateur, par exemple du Fibonacci ou de l'Ackerman.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

129

J'explique pourquoi un frontend GCC m'intéresse tellement:

Un frontend GCC ETP permettrait de distribuer ETP avec TIGCC comme une solution intégrée. Enfin bon, il faudrait aussi rajouter le syntax highlighting ETP BASIC à KTIGCC 2, mais ce n'est pas un travail immense. Donc on pourrait écrire en C ou ETP BASIC au choix, et même mélanger les deux.

Enfin, il restera(it?) probablement quelques tensions parce que Onur veut imposer la portabilité dans le langage (accès aux fonctions natives uniquement à travers son runtime), alors que pour ce que je compte faire, il faut pouvoir interfacer avec du code C arbitraire. AMHA, la meilleure solution serait d'implémenter le runtime ETP en termes de l'interface avec le code C/ASM. Genre avoir un header automatiquement inclus, par exemple system.inc, qui contient quelque chose comme:
Declare Sub Locate Alias "_ROM_CALL_1A9" (x As Integer, y As Integer, str As Const String, Attr As Integer)
(le compilateur pourra éventuellement traîter _ROM_CALL_* de manière particulière, mais s'il ne le fait pas, ce serait quand-même suffisant au moins pour les ROM_CALLS F-Line) et de même pour les fonctions de la lib runtime. Comme ça, la lib runtime sera utilisable en C facilement (il suffit de faire un .h équivalent au .inc), donc on pourrait écrire du code tout aussi portable en C aussi si on préfère le C, et dans l'autre sens les fonctions C (ROM_CALLs, librairies etc.) seraient utilisables en ETP, ce qui augmenterait de beaucoup l'expressivité du langage.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

130

Kevin Kofler (./112) :
Pollux (./106) :
Si il avait envie de déléguer la génération de code le plus simple serait plutôt de transformer son code en code C

C'est de la bidouille, ça.

Il y a 2 manières de s'y prendre, les deux ont des problèmes:
* conversion haut-niveau, où le code reste reconnaissable dans la version C:
- impose un langage très proche du C (=> Où est l'intérêt d'un tel langage?)
- délègue une partie de la vérification sémantique (et éventuellement même syntaxique) au compilateur C, donc les messages d'erreur sont moins clairs (parce qu'ils portent sur du code déjà prétraîté)
* conversion bas-niveau, où le C est utilisé comme un "assembleur portable":
- donne du code C illisible, donc difficile à déboguer
- utilise le C comme un langage intermédiaire, ce qui n'est pas idéal (par exemple, on n'a pas accès aux caractéristiques du target à moins de dupliquer les informations que GCC a dans le convertisseur frontend)
- donne à GCC du code qui a déjà perdu de l'information, par exemple GCC ne voit plus les boucles, donc il ne peut pas faire des optimisations de boucles là-dessus!

Non, ta dichotomie est fausse. Il suffit de parser le fichier entièrement (transformer en AST, se souvenir des types, etc), et de générer non pas un "assembleur portable" mais un code C équivalent.

Exemple :
Public statusbar as String

Function LongueurNom(name as String) as Integer
    Local n as Integer
    n = Dim name
    If n > 10 Then
        statusbar = "Attention, chaîne '"+name+"' trop longue!"
        Return 10
    EndIf
    Return n

=>
string *statusbar = NULL;

int LongueurNom(string *name) {
    static string chaines[] = {{-1, "Attention, chaîne '"}, {-1, "' trop longue!"}};
    int n;
    n = strlen(name->content);
    if (n > 10) {
        string_delref(statusbar);
        statusbar = string_concat(string_concat(&chaines[0],string_addref(name)),&chaines[1]);
        string_delref(name);
        return 10;
    }
    string_delref(name);
    return n;
}


C'est parfaitement lisible, ça génère du code efficace, ça ne dépend pas du compilateur. Que demander de plus ? Pourquoi s'embêter avec des AST spécifique à un compilateur et même à une version d'un compilateur ?

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

131

Pollux (./130) :
Non, ta dichotomie est fausse. Il suffit de parser le fichier entièrement (transformer en AST, se souvenir des types, etc), et de générer non pas un "assembleur portable" mais un code C équivalent.

Exemple :
[snip]
C'est parfaitement lisible, ça génère du code efficace, ça ne dépend pas du compilateur. Que demander de plus ?

Ton exemple est une conversion haut niveau. Tous mes points s'appliquent: ce n'est pratiquable que pour un langage qui est suffisamment proche du C, et il y a des problèmes sémantiques qui ne seront forcément visibles que pour le compilateur C (certains cas de variables non initialisées par exemple).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

132

Je suppose qu'ETP-Basic est censé être robuste, et donc il ne devrait pas y avoir de variables non initialisées, ni aucune autre forme de warning ou d'erreur visible par le compilo C (puisque sinon risques de plantages si un pointeur n'est pas initialisé), non ?

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

133

Hum... si.
Perso, je préferais que toute la vérif sémantique soit fait au niveau du "compilo" (enfin de ce qu'il en restera) ETP. Il faudrait rien laisser au compilo C comme on ne laisserait rien à l'assembleur quand on génère de l'asm.
Tout ce qui passe pas par le port 80, c'est de la triche.

134

onur (./133) :
Hum... si.

Tu peux préciser ? Dans quels cas il faudrait laisser des sources de warnings pour le compilateur C ?

(et je suis bien d'accord pour que la vérif sémantique soit faite au niveau d'ETP, c'est bien ce que je dis)

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

135

Pollux (./134) :
Dans quels cas il faudrait laisser des sources de warnings pour le compilateur C ?

Dans aucun cas. Dsl de pas avoir été clair.
Tout ce qui passe pas par le port 80, c'est de la triche.

136

[HS] Kevin, t'as toutes mes escuses pour le troll completement HS d'hier (Il était vraiment si gros ? magic ); squalyl, t'as bien réagit ^^[/HS]
"De l'Art de faire des Posts qui ne servent a Rien." (c) Ximoon

15:13 @Ximoon - 29-11-2005
"C'est débile ce sondage, une fois de plus Dude, tu ne sers à rien #hehe#" #love# Il est collector celui là ^^

18:56 @Ximoon - 09-10-2010
"Mince Dude sert à quelque chose %) (pas taper :D )" Owii xD #trilove#

137

Kevin Kofler (./129) :
Enfin, il restera(it?) probablement quelques tensions parce que Onur veut imposer la portabilité dans le langage (accès aux fonctions natives uniquement à travers son runtime), alors que pour ce que je compte faire, il faut pouvoir interfacer avec du code C arbitraire.


mieux que ça, le code généré par etpc pour ses instructions peut faire des appels à des fonctions implémentées en C. Donc meme pas besoin d'include au niveau d'etp, ça peut se faire à l'édition de liens, genre avec une libetp68k.a, elle même implémentée en C, assembleur, etc.

en effet, une spécification du langage (en cours quoi magic) va dire que le langage n'a pas un accès explicite aux romcalls, pour s'affranchir de l'implémentation bas niveau, genre si on veut tester sur PC, on fournit une fonction Locate lig,col,text pour console, etc..
A nous de définir l'API qui fera la liaison entre les appels de fct générés par etpc et les fonctions elles mêmes, ie quelles seront nécessaires, etc...

désolé de présenter tout ça si mal, on a en effet besoin de spécifs claires. smile

138

Il faudra certainement un moyen de définir des prototypes de fonctions externes. Idéalement aussi avec passage par registres, sinon il faudra des wrappers pour les fonctions TIGCCLIB.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

139

[HS]
onur (./100) :
Ca se voit que tu connais bien la génération de code pour en parler. Je ne les connais pas non plus, il me semble que c'est justement ces representations intermédiaires qui font que gcc est super portable, mais moins efficace que les compilos d'intel et microsoft.

Pour info, d'après ma propre expérience. Si ICC fait 100, GCC fait 105-110 et MSVC++ fait 120-130.
[/HS]

140

Kevin> oui sans doute. Pour nous, ce sera d'ailleurs l'occasion de se familiariser avec les internals de tigcc hehe