ETP Studio Open Source - Page 4

Jyaif (./76) :

Lionel Debroux (./73) :
Mais IL EST UN FAIT que le comportement de certains, largement toi-même, a contribué à mener à l'état actuel de la communauté.

Si presque tous les programmeurs pour TI ont arrêtés de programmer pour TI, c'est parceque ça ne les interessaient plus. Faut être stupide/faible pour arrêter un hobby à cause d'autres personnes

Euh si, quand tu essaies de faire un truc bien fichu et que le seul commentaire que tu as c'est « kernel-based => poubelle direct » ou « c'est pas libre => poubelle direct », ça ne donne pas envie de continuer à programmer

Flanker (./91) :

Jyaif (./76) :

Lionel Debroux (./73) :
Mais IL EST UN FAIT que le comportement de certains, largement toi-même, a contribué à mener à l'état actuel de la communauté.

Si presque tous les programmeurs pour TI ont arrêtés de programmer pour TI, c'est parceque ça ne les interessaient plus. Faut être stupide/faible pour arrêter un hobby à cause d'autres personnes

Euh si, quand tu essaies de faire un truc bien fichu et que le seul commentaire que tu as c'est « kernel-based => poubelle direct » ou « c'est pas libre => poubelle direct », ça ne donne pas envie de continuer à programmer

il suffit d'être assez intélligent pour ignorer les gens qui disent ça (même si dans le cas présent, ils ont raison: kernel sux)

Ça se voit que tu n'es pas concerné

Kevin Kofler (./85) :
Ce n'est pas de l'optimisation ça, c'est de l'allocation de registres, et seulement pour les valeurs temporaires en plus, pas pour les variables locales. Mais je t'ai déjà dit ça.

C'est koi alors l'optimisation? Tu veux que je fasse un algo de coloration de graphe pour gerer au mieux les dépendances variables <-> registres? oui,ca serait mieux. Mais avec ce code généré tu peux pas dire que c'est du bidouillage, le résultat est largement convaincant, mais tu preferes fermer les yeux et continuer à cracher sur le projet. Tu fais pitié.

Jyaif (./92) :

Flanker (./91) :

Jyaif (./76) :

Lionel Debroux (./73) :
Mais IL EST UN FAIT que le comportement de certains, largement toi-même, a contribué à mener à l'état actuel de la communauté.

Si presque tous les programmeurs pour TI ont arrêtés de programmer pour TI, c'est parceque ça ne les interessaient plus. Faut être stupide/faible pour arrêter un hobby à cause d'autres personnes

Euh si, quand tu essaies de faire un truc bien fichu et que le seul commentaire que tu as c'est « kernel-based => poubelle direct » ou « c'est pas libre => poubelle direct », ça ne donne pas envie de continuer à programmer

il suffit d'être assez intélligent pour ignorer les gens qui disent ça (même si dans le cas présent, ils ont raison: kernel sux)

Bah voyons, il suffit d'etre intelligent et d'écouter les gens qui disent que opensource et nostub c'est bien.

Pour moi intelligent != mouton, mais bon chacun sa définition.

Je dis justement de ne pas écouter les gens (quand on a une bonne raison bien sur, ça sert à rien d'ignorer les gens sans raison (n'est ce pas Onur?))

Si je devais écouter les gens (le gens?) qui ont (qui a?) raison, etpstudio => poubelle direct?

Je me dis que tu ne comprends surement pas les propos de K² parce que tu ne sais programmer que des jeux et par conséquent tu penses qu'il a raison. Mais le code actuel est super avancé même si on ne peut pas faire des jeux avec.

Je pense qu'il y a quelque chose à en tirer de ce bout de code, c'est pourquoi je l'offre à la communauté, maintenant tout le monde fait ce qu'il en veut.

Jyaif (./96) :
Je dis justement de ne pas écouter les gens (quand on a une bonne raison bien sur, ça sert à rien d'ignorer les gens sans raison (n'est ce pas Onur?))

tout le monde n'apprécie pas de voir un ****** poster partout où il peut que tu ne fais que de la merde parce que tu refuses les règles qu'il souhaite imposer…

onur (./94) :
C'est koi alors l'optimisation?

Une passe qui prend une représentation intermédiaire en entrée, la même représentation intermédiaire en sortie, et fait des transformations dessus visant à rendre le code plus efficace. GCC a des dizaines de passes comme ça!

Tu veux que je fasse un algo de coloration de graphe pour gerer au mieux les dépendances variables <-> registres? oui,ca serait mieux.

De loin. Ça serait toujours de l'allocation de registres, pas de l'optimisation, mais de la vraie allocation de registres!

Kevin Kofler (./99) :
Une passe qui prend une représentation intermédiaire en entrée, la même représentation intermédiaire en sortie, et fait des transformations dessus visant à rendre le code plus efficace. GCC a des dizaines de passes comme ça!

Super précis (y). 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.

La coloration de graphe pour les registres, c'est le plus important, car c'est l'endroit critique. Personne ne code une affectation à l'intérieur d'une boucle alors qu'elle pourrait etre à l'extérieur.

S'il faut coder 5 ans pour gagner 3 octets, compte pas sur moi, ni les autres.

Plutot, je dirais que maintenant, vous devriez planifier ce qui est immédiat à faire, et ce qui est "mieux" mais pas critique.

personnellement, il me semble qu'en effet, gcc a plusieurs fichiers dont le nom commence par "tree" et qui agissent directement au niveau de l'AST.

Pourquoi ne pas faire un "frontend" modulaire, qui permette de l'intégrer dans GCC d'une part, mais de garder d'autres options de génération derrière, comme celles codées par Onur? cela permettrait de tester/développer chaque partie séparément.

et pour la génération z80? et nspire?

onur (./100) :
Super précis (y). Ca se voit que tu connais bien la génération de code pour en parler.

Euh, c'est censé être ironique? Si oui, tu as tort. J'ai donné une définition aussi précise que possible. Les passes d'optimisation font toutes des transformations différentes. Par exemple, il y a de la Dead Code Elimination (DCE), de la Partial Redundancy Elimination (PRE) etc. Cf. http://gcc.gnu.org/onlinedocs/gccint/Tree_002dSSA-passes.html et http://gcc.gnu.org/onlinedocs/gccint/RTL-passes.html.

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.

Et là, c'est toi qui montres ton ignorance. Aucun compilateur moderne ne travaille sans aucune représentation intermédiaire. L'assembleur fini est très difficile à optimiser convenablement (surtout quand l'allocation des registres a déjà été faite), il est beaucoup plus efficace d'optimiser une représentation intermédiaire en forme Static Single Assignment (SSA). GCC 4 a aussi introduit une telle représentation SSA, en plus de la représentation intermédiaire bas-niveau qu'ils avaient, c'était la grande nouveauté qui a marqué le passage à la version 4, et ils font des optimisations sur les deux représentations maintenant (d'abord sur la SSA, puis sur le code bas-niveau (mais la plupart des passes d'optimisation se passent avant l'allocation des registres)).

L'idée de la SSA:
* Chaque variable n'est affectée qu'une et une seule fois.
* Pour représenter les boucles, il y a une affectation spéciale, le "nœud phi": x=PHI(<BB1,a>,<BB2,b>,<BB3,c>) veut dire: x=a si l'exécution provient du basic block BB1, x=b si elle vient de BB2, x=c si elle vient de BB3.
Pour transformer une représentation classique en SSA, il suffit de numéroter les variables pour que chaque affectation affecte à un numéro particulier. Maintenant, pour les pointeurs et les tableaux, c'est plus compliqué (il y a des bidouilles genre les VDEF et VUSE de GCC), j'ai juste expliqué l'idée de base.

Ce qui est fait dans les compilateurs optimisés pour une machine particulière, c'est de faire en sorte que la représentation intermédiaire corresponde le mieux possible à l'architecture de la machine, alors que dans GCC, il y a un tradeoff entre modeler le target actuel ou l'abstraire. (Et non, les représentations intermédiaires de GCC et les passes d'optimisation qui opèrent là-dessus ne sont pas totalement indépendantes de la machine visée.)

La coloration de graphe pour les registres, c'est le plus important, car c'est l'endroit critique.

C'est le plus visible actuellement, mais quand tu auras fait ça, on verra plus clairement les déficiences (ou plutôt l'absence totale ) des optimisations.

Personne ne code une affectation à l'intérieur d'une boucle alors qu'elle pourrait etre à l'extérieur.

Il y a plusieurs raisons pour lesquelles cette logique ne convient pas. Citons juste un exemple: l'inlining. Certes, on peut s'en passer, mais du coup, si on optimise en vitesse (en taille, l'inlining est souvent contreproductif), on se retrouve à faire du copier-coller plutôt que d'écrire une fonction, ce qui donne vite du code absolument impossible à maintenir. Et l'inlining seul aboutit souvent à du code sous-optimal, comme justement les affectations à l'intérieur d'une boucle, si elles faisaient partie de la fonction inline! Donc les autres optimisations deviennent utiles rien que pour ça. Et il y a d'autres cas où les optimisations servent. Si tu veux que le programmeur fasse le boulot du compilateur, autant écrire directement en assembleur.

Et j'ai l'impression que le concept de maintenabilité t'échappe complètement. Ce qui me donne cette impression, c'est à la fois la tête de ton propre code et des remarques naïves comme celle-ci.

S'il faut coder 5 ans pour gagner 3 octets, compte pas sur moi, ni les autres.

Et hop, donc tous tes discours sur l'optimisation "prévue pour plus tard" et puis "prévue pour la réecriture en C++" quand j'ai montré tous les endroits sous-optimaux dans l'ancien ETP en VB étaient du vapor, merci de confirmer. Enfin, il faut dire que tu ne savais apparemment pas ce que c'est (cf. ton premier paragraphe), mais ça commence à devenir ridicule, quelqu'un qui travaille sur un compilateur pendant 2 années et ne sait pas ce qu'est une passe d'optimisation!

Déjà il ne s'agit pas de gagner 3 octets (sauf sur un Hello World ), mais des centaines d'octets, tu as l'air de sous-estimer de beaucoup l'importance des optimisations. Et ensuite, tu profiterais automatiquement de toutes ces optimisations (et aussi d'une allocation de registres prête à l'emploi) si tu transformais ton frontend en un frontend GCC. Ça te donnerait aussi une version PC presque en cadeau, il n'y aurait que la librairie runtime à coder en version PC. Ça ne fait "que" des mois que je te dis ça...

onur (./102) :
et pour la génération z80?

Il faudrait un backend Z80 pour GCC, ça ferait aussi profiter les développeurs C de ce travail. Malheureusement, tous ceux commencés ont été abandonnés (Halifax a aussi laissé tomber l'idée aux dernières nouvelles). Et puis, si c'est pour viser une VM comme tu comptes le faire actuellement, ce n'est pas la peine.

et nspire?

On ne peut pas faire tourner autre chose que du TI-BASIC dessus actuellement, donc c'est totalement vapor. Mais pour quand on pourra faire tourner du code machine: GCC a un backend ARM bien maintenu, qui donne certainement du code meilleur que ce que ton bidouillage pourra sortir!

allez, arrêtez de vous envoyer des amabilités

est on d'accord au moins sur le fait qu'un code maintenable sera plus agréable pour tous?

Laissons les fonctionnalités de coté, j'ai l'impression que toi, Kevin, tu joues au "tu l'as dit et pas fait". On sait bien que les optimisations sont indispensables mais n'oublie pas que
-le projet est en train de naitre
-il se base sur un projet universitaire de quelques mois, développé par des étudiants en train d'étudier, qui n'ont aucune expérience.
-il a été fait dans le but de *comprendre* un compilo, pas d'avoir un outil de production

je pensais publier mon début de machine virtuelle java embarquée, mais bon, je vais pas le faire, si je dois subir autant de pression! sois cool! il a été sympa de partager son code, il aurait pu ne rien faire aussi!

Et pour le Z80, le but n'est pas d'avoir une VM mais des "gros stubs" si tu préfères.

Et pourquoi les backends Z80 ont été abandonnés? La machine est trop simple pour pouvoir en tirer quelque chose?

(ah j'avais pas vu, tu donnes l'exemple de l'inlining, mais sois honnête, c'est pas le genre de choses qu'on met en place dans un projet de compilation du niveau de celui fait à l'ENSIMAG (je dirai pas 'dans une école d'informatique')

Kevin Kofler (./103) :
Déjà il ne s'agit pas de gagner 3 octets (sauf sur un Hello World ), mais des centaines d'octets, tu as l'air de sous-estimer de beaucoup l'importance des optimisations. Et ensuite, tu profiterais automatiquement de toutes ces optimisations (et aussi d'une allocation de registres prête à l'emploi) si tu transformais ton frontend en un frontend GCC. Ça te donnerait aussi une version PC presque en cadeau, il n'y aurait que la librairie runtime à coder en version PC. Ça ne fait "que" des mois que je te dis ça...

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, comme ça 1) il ne serait pas dépendant de GCC (mais je suppose que de ton point de vue c'est un avantage ) 2) il n'aurait pas à prendre en compte toute l'usine à gaz qu'est GCC, ni à faire de modifications significatives à chaque nouvelle version de GCC...
D'après le peu que j'ai vu d'ETP-Basic ça m'a l'air faisable en tout cas, mais peut-être que j'ai pas vu toutes les features du langage ^^



Sinon je ne comprends pas pourquoi tu dis que l'allocation de registres n'est pas une optimisation... C'est une optimisation comme les autres, elle transforme un code où les variables sont toutes sur la pile en un code où les variables sont placées au mieux dans les registres Peut-être que c'est pas toujours implémenté comme les autres passes d'optimisation, mais conceptuellement ça en reste une ^^

squalyl (./105) :
Laissons les fonctionnalités de coté, j'ai l'impression que toi, Kevin, tu joues au "tu l'as dit et pas fait".

Non, je joue au "tu l'as dit, maintenant tu dis que ce n'est pas/plus prévu", cf. les 2 dernières phrases de son ./100.

Et lui, il a l'air de jouer au "tout ce que je n'ai pas encore fait / ne compte pas faire (selon le contexte) n'est pas important", c'est de la mauvaise foi, ça. D'autant plus qu'il montre clairement qu'il ne sait pas de quoi il parle.

-il a été fait dans le but de *comprendre* un compilo

C'est faire les choses à l'envers ça, il faut savoir ce qu'on fait avant de commencer à coder. Il y a des moyens de se documenter.

pas d'avoir un outil de production

Le problème est qu'il n'a pas l'air de comprendre ça, ou s'il le comprend, qu'il ne fait pas clairement passer le message à des personnes comme Thibaut ou Yoshi Noir, ni à ses utilisateurs potentiels.

je pensais publier mon début de machine virtuelle java embarquée, mais bon, je vais pas le faire, si je dois subir autant de pression!

Si tu écris quelque chose comme: "ATTENTION! CECI EST UN PROJET DE RECHERCHE EN ÉTAT PRÉ-ALPHA. EN SON ÉTAT ACTUEL, IL EST TOTALEMENT INUTILISABLE EN PRATIQUE." (ce qui serait honnête), le feedback obtenu sera différent.

Et pour le Z80, le but n'est pas d'avoir une VM mais des "gros stubs" si tu préfères.

Tu entends quoi par "gros stubs"?

Et pourquoi les backends Z80 ont été abandonnés? La machine est trop simple pour pouvoir en tirer quelque chose?

La machine est:
* peu adaptée au C (et aux autres langages compilés du même type, ce qui comprend aussi l'ETP) en général,
* trop bizarre pour être bien gérée par GCC (registres spécialisés comme l'accumulateur A etc.).

(ah j'avais pas vu, tu donnes l'exemple de l'inlining, mais sois honnête, c'est pas le genre de choses qu'on met en place dans un projet de compilation du niveau de celui fait à l'ENSIMAG (je dirai pas 'dans une école d'informatique')

Je sais bien, j'ai fait un compilateur jouet dans un cours à l'université aussi! Mais je n'ai pas la prétention de considérer un tel compilateur jouet comme utilisable en pratique.

Bon, puisque l'approche "aimez-vous svp" de squalyl ne semble pas être très efficace :

Maintenant qu'à peu près tout le monde a compris ton point de vue, pourrais-tu faire l'effort d'être un peu plus respectueux envers le travail d'Onur ? Je ne compte plus le nombre de fois où tu as associé ETP à quelque chose de "totalement inutilisable", "jouet" ou autre, mais comme ça a été souligné à plusieurs reprises, tu peux faire des suggestions utiles tout en étant un peu moins insultant, au lieu comme en ce moment de descendre son projet en apportant à peine une remarque constructive tous les 10 posts.

Merci.

Kevin Kofler (./103) :
GCC 4 a aussi introduit une telle représentation SSA, en plus de la représentation intermédiaire bas-niveau qu'ils avaient, c'était la grande nouveauté qui a marqué le passage à la version 4, et ils font des optimisations sur les deux représentations maintenant (d'abord sur la SSA, puis sur le code bas-niveau (mais la plupart des passes d'optimisation se passent avant l'allocation des registres)).

je sais tout ca... j'avais lu à la sortie du 4...
Mais de quoi tu parles exactement? Le code sorti par la nouvelle version est bon bon sang! Voilà les rapports je dirais (en taille):

version VB d'ETP compiler / tigcc = 300%
version C++ d'etp compiler / tigcc = 110% ?

Un conseil, je sais que tu n'es pas super fort en C++ mais, LIS CE P***** DE FICHIER GEN68K.CPP !!!!!

En plus, il y a un dossier méthode général si on veut à tout prix génerer du code pseudo-asm intermédiaire et faire joujou dessus. Donc maintenant soit tu dis quelque chose d'utile, soit tu la fermes.

Kevin Kofler (./107) :
La machine est:
* peu adaptée au C (et aux autres langages compilés du même type, ce qui comprend aussi l'ETP) en général, * trop bizarre pour être bien gérée par GCC (registres spécialisés comme l'accumulateur A etc.).

Kevin Kofler (./104) :
Il faudrait un backend Z80 pour GCC, ça ferait aussi profiter les développeurs C de ce travail. Malheureusement, tous ceux commencés ont été abandonnés (Halifax a aussi laissé tomber l'idée aux dernières nouvelles). Et puis, si c'est pour viser une VM comme tu comptes le faire actuellement, ce n'est pas la peine.

Donc on n'est pas pret de voir une version z80 dans tigcc.. d'autant qu'il y a de milliers de codeurs qui ont écrit des programmes 68k-dependent vu que les rom_call sont appelés directement...
Regarde bien dans les sources, tu as l'air d'avoir de la m**** dans les yeux, il y a un répertoire genz80, ce n'est pas une chanson de pascal obispo. lol

Kevin Kofler (./107) :
Non, je joue au "tu l'as dit, maintenant tu dis que ce n'est pas/plus prévu", cf. les 2 dernières phrases de son ./100.

Et lui, il a l'air de jouer au "tout ce que je n'ai pas encore fait / ne compte pas faire (selon le contexte) n'est pas important", c'est de la mauvaise foi, ça. D'autant plus qu'il montre clairement qu'il ne sait pas de quoi il parle.

D'accord. Dans ce cas, ne t'inquiete pas. Qui peut dire définitivement qu'un feature est prévu ou pas? En général, on code ce qu'on peut, on reporte à plus tard ce qui est le plus difficile et/ou moins indispensable à court terme, etc...
N'oublie pas que notre expérience dans le développement collaboratif, à Onur et moi, est très mince. Tu as de la chance d'être impliqué dans le développement de gcc, c'est une expérience que tout le monde ne possède pas (hélas peut être, mais c'est comme ça)

Kevin Kofler (./107) :
C'est faire les choses à l'envers ça, il faut savoir ce qu'on fait avant de commencer à coder. Il y a des moyens de se documenter.

Je connais l'organisation de l'ENSIMAG pour avoir suivi les mêmes cours qu'Onur à très peu de choses près, et, encore hélas, je peux t'affirmer que c'est impossible, car les cours, TD et projets se font quasiment en même temps. Personne n'a matériellement le temps d'accumuler de l'expérience avant de commencer les projets d'école. Que ce soit en compilation ou autre. J'ai moi même dirigé l'organisation de notre projet de compil, et j'ai passé mon temps à expliquer aux autres (on peut les considérer comme des développeurs, donc) ce qu'ils n'avaient pas compris.

Kevin Kofler (./107) :
Le problème est qu'il n'a pas l'air de comprendre ça, ou s'il le comprend, qu'il ne fait pas clairement passer le message à des personnes comme Thibaut ou Yoshi Noir, ni à ses utilisateurs potentiels.

Ha , la la, le problème de la communication Eh oui, c'est dur, et évidemment, quand on code soi même, ce qu'on fait en dernier, c'est écrire la doc mauvaise habitude, je le reconnais, mais hélas encore

Kevin Kofler (./107) :
Si tu écris quelque chose comme: "ATTENTION! CECI EST UN PROJET DE RECHERCHE EN ÉTAT PRÉ-ALPHA. EN SON ÉTAT ACTUEL, IL EST TOTALEMENT INUTILISABLE EN PRATIQUE." (ce qui serait honnête), le feedback obtenu sera différent.

Je comprends parfaitement ce que tu attends, et c'est légitime, mais dans ce processus, c'est aussi la fierté et l'envie de montrer le plus vite possible ce qu'on a réussi qui prime Donc parfois, ça pousse à des choses que les gens très rationnels, comme toi, (je critique pas , d'accord?) trouvent choquantes

Kevin Kofler (./107) :
Tu entends quoi par "gros stubs"?

Ben moi je voyais des bouts de code natifs qui remplacent les fonctions manquantes. Même s'il s'agit de fonctions dont les effets de bord ne sont pas 100,000% identiques à la version 68k. C'est à envisager, n'est ce pas? Cela peut être gratifiant pour certains programmeurs débutants, d'avoir des programmes simples portables nativement entre les calculatrices Je ne pense pas qu'il s'agisse de porter des choses évoluées, mais des fonctions de base. Quitte à signaler à l'utilisateur "portage impossible" etc... si on demande des choses trop compliquées.

Kevin Kofler (./107) :
Je sais bien, j'ai fait un compilateur jouet dans un cours à l'université aussi! Mais je n'ai pas la prétention de considérer un tel compilateur jouet comme utilisable en pratique.

Encore une fois, OK, je vois où tu veux en venir. C'est plutot une histoire de mots que de fonctions j'ai l'impression. Il doit être possible de vous mettre d'accord.

Zephyr > peut être que certaines critiques sont justifiées, j'ai l'impression que c'est plus sur la forme que sur le contenu que ce concentrent les critiques.

onur (./109) :
LIS CE P***** DE FICHIER GEN68K.CPP

onur (./110) :
tu as l'air d'avoir de la m**** dans les yeux

courage, résiste à l'envie de péter les plombs, on va vous mettre d'accord j'en suis certain.

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!

Et dans les 2 cas, des concepts qui peuvent être exprimés en assembleur, mais difficilement en C, sont forcément implémentés soit de manière très inefficace, soit pas du tout.

Sinon je ne comprends pas pourquoi tu dis que l'allocation de registres n'est pas une optimisation... C'est une optimisation comme les autres, elle transforme un code où les variables sont toutes sur la pile en un code où les variables sont placées au mieux dans les registres

Dans GCC, elle transforme des pseudo-registres en registres ou en stack slots. Donc c'est une transformation obligatoire.

squalyl (./111) :
Zephyr > peut être que certaines critiques sont justifiées, j'ai l'impression que c'est plus sur la forme que sur le contenu que ce concentrent les critiques.

Bien sûr qu'elles peuvent être justifiées, mais seulement si il y a au moins une proposition d'amélioration à coté. Tant que les posts ne sont que destructifs, ils n'ont aucun intérêt (et vu le ton employé, je ne peux que conseiller à KK de rectifier rapidement le tir).

Squalyl > Non je suis pas trop d'accord. Toi tu as fait 2 années de cours de l'Ensimag en condensé, mais moi j'avais plus de temps en général les premières année et eu le temps de m'y intéresser avant même d'avoir des cours de compilation. Les cours de compilation et le projet m'ont permis d'apporter les optimisations dans la génération que Kevin veut dissimuler en disant "gcc est mieux bla bla bla.." j'ai envie de dire heureusement que cest mieux! si un étudiant pouvait faire mieux que l'équipe de gcc en 20 ans, ca craindrait un peu quand meme. Donc remarque inutile.

Ce que je lui reproche là, c'est que ses critiques ne servent strictement à rien, ni sur la forme ni sur le fond. Il veut uniquement mettre de l'ombre pour que personne ne contribue au projet, et c'est pas acceptable. De plus, il ferme les yeux sur les plus que le projet a par rapport à tigcc => multiplateform target.

Pour en revenir au sujet, je pourrais continuer/finir la partie 68k seul ou avec des gens motivés ici. Et pour la partie z80, la communauté anglophone est, parait-il, assez actif, et je suppose qu'il y aura des gens interessé par ce projet multiplateforme.

Au fait, les brouillons, c'est quelque part la dedans:

donc il va falloir attendre un peu avant que je les post :P

donc patience à tous les impatients

(squalyl)
> Lionel > je ne pense pas que ces radotages servent à améliorer la situation présente non plus. Ton opinion ne regarde que toi, tu ne postes qu'avec le but de montrer à tout le monde que t'as fait des trucs pour te défendre, mais on ferait mieux d'avancer, la rancune ne sert à rien.
Tout à fait d'accord sur le fait qu'on ferait mieux d'avancer. Et c'était (pour moi) l'objectif de mon mail du 1er septembre à Kevin. Voici son contenu, à vous de juger si le mail était écrit correctement pour faire passer ce message:

>> > > et de l'autre côté, je me souviens d'un ajout de
>> > > modification dans le peephole optimizer de TIGCC
> > Et c'est qui qui m'a demandé de mettre ces peepholes? ;-)
Le pape, ou Obi Wan Kenobi, au choix :P


>>> > > > Il me faut copier-coller-éditer une dizaine-vingtaine de
>>> > > > fichiers HSF, et rajouter des "See Also" dans la doc des
>>> > > > routines à 2 plans aussi.
>> > > -"me faut" +"faut que quelqu'un s'attelle à ".
> > Faut pas rêver, ce sera certainement sur moi que ça va
> > retomber comme d'habitude.
Je te sens moyennement motivé, là...
Il est vrai que ce copier-coller-éditer prend quelques heures (je ne
sais pas vraiment estimer combien, et ça dépend des personnes), et c'est
fastidieux. Mon binôme indique parfois, pour un travail répétitif, une
phrase du genre ~"a trained monkey could do at least half of my current
job".

Pour ce travail de copier-coller-éditer, la connaissance préalable du
système HSF (assez facile à apprendre, de toute façon) n'est pas un
prérequis. Cela élargit à plusieurs dizaines le champ des personnes de
la communauté qui _peuvent_ faire ce travail à peu près convenablement.
MAIS il ne doit pas y avoir bien plus d'une personne (autre que toi) qui
_est disposée à_ faire ce travail...


La plupart d'entre nous (les anciens de la communauté) ont perdu une
partie de leur motivation au fil des années. De plus, nous sommes moins
libres: nous avons vieilli depuis 2001-2002, et beaucoup ont maintenant
un boulot à temps plein. J'en fais maintenant partie, même si j'aurai
quelques jours entre la fin du stage de fin d'études et le début de mon
premier emploi.

La sortie de la Nspire, sur laquelle on ne sait pour le moment
pas encore tourner des programmes assembleur (BASIC, c'est encore un
poil tôt pour le dire, mais si "Prgm" et "EndPrgm" sont apparus dans la
dernière mise à jour, ça peut être un début...), fournit une occasion de
terminer d'intégrer le gros du travail en attente sur les
TI-68k (docs d'ExtendeD sur les fonctions AMS 2.07+; grayscale 3 plans;
mes contributions; etc.). Sans oublier d'éventuelles réécritures
d'outils pour rendre TIGCC plus portable.
Je pense qu'il faut saisir cette occasion de finir le gros du boulot (si
les anciens qui sont toujours dans la communauté ne le font pas, qui le
fera ?), et puis passer à autre chose (Nspire, ou bien d'autres projets).

Quelles sont tes idées sur les raisons qui feraient que tu es quasiment
tout seul sur TIGCC, depuis que Sebastian est parti vers d'autres
horizons (OOSys, par exemple) ?

Pour savoir comment on avance, il est normal de poser le diagnostic de pourquoi ça n'avance pas bien, et d'en discuter. Ce qui est fait dans ce topic. Après, quand on sait pourquoi ça n'avance pas, on peut discuter de solutions possibles.




Si j'avais voulu ne pas faire un mail constructif, j'aurais envoyé du premier coup à Kevin quelque chose de similaire à ce que j'ai posté hier soir en haut de page 3, avec un résultat très prévisible.
Le processus d'écriture du mail que j'ai posté ci-dessus m'a permis de sentir plusieurs façons de présenter les choses, et notamment celles qu'il NE fallait PAS utiliser. Pour que Kevin réagisse dans le bon sens. il n'est pas bien de l'attaquer sur sa contribution (réelle, lui et moi avons découragé au moins un programmeur sur le forum de TIGCC/TICT...) à l'état de la communauté et de TIGCC. Il est plus efficace de lui demander pourquoi, selon lui, ça ne va pas. Ca garde une ouverture de discussion, plutôt que de la fermer. Ce que je fis donc.

MAIS j'ai également gardé un brouillon de l'autre façon de présenter les choses, que voici:

> > et de l'autre côté, je me souviens d'un ajout de
> > modification dans le peephole optimizer de TIGCC
> Et c'est qui qui m'a demandé de mettre ces peepholes? ;-)
Le pape :P


> > > Il me faut copier-coller-éditer une dizaine-vingtaine de
> > > fichiers HSF, et rajouter des "See Also" dans la doc des
> > > routines à 2 plans aussi.
> > -"me faut" +"faut que quelqu'un s'attelle à ".
> Faut pas rêver, ce sera certainement sur moi que ça va
> retomber comme d'habitude.
Pour ce travail de copier-coller-éditer une vingtaine de fichiers, la
connaissance préalable du système HSF (assez facile à apprendre, de toute façon) n'est pas un prérequis.
Cela élargit à plusieurs dizaines le champ des personnes de la
communauté qui _peuvent_ faire ce travail à peu près convenablement.
Mais je suis d'accord, il ne doit pas y avoir bien plus d'une personne (autre que toi) qui _est disposée à_ faire ce travail...

Certes, ce travail prend un certain nombre d'heures, et est fastidieux. Mon binôme indique parfois, pour un travail répétitif, une phrase du genre ~"a trained monkey could do at least half of my current job".
Et nombre de ceux qui sont dans la communauté de manière plus ou moins continue depuis 2001 ont maintenant un boulot à temps plein, j'en fais maintenant partie (même si j'aurai quelques jours en septembre, entre le stage et mon premier emploi).
Mais _à mon avis_, ces raisons pratiques ne sont pas les seules raisons pour lesquelles la contribution extérieure à TIGCC est faible...


Le fait est que depuis que Sebastian est parti vers d'autres horizons (OOSys ?), il y a maintenant plus de deux ans, tu es le seul mainteneur de TIGCC, et presque le seul contributeur. Et il est aussi un fait que dans la communauté TI-68k, tu n'es vraiment pas la personne qui accepte le mieux le compromis... Moi non plus, mais je suis plus "souple" que toi.
Tu as ta part de responsabilité dans cette situation dans laquelle toute la maintenance de TIGCC, y compris de la relecture / amélioration simple de docs, te retombe dessus.

Je pense (et je doute être le seul à penser cela) qu'il est peu utile (et peu motivant) de faire un travail, alors que je sais très bien, après avoir constaté nos désaccords lors de discussions plus ou moins musclées (et éventuellement répétées plusieurs fois, sans que rien n'avance...), que tu ne l'intégreras pas dans TIGCC.
Et vu que c'est toi qui dois tout faire, ça te prend du temps, et ça ne te motive pas non plus...


Avoir un seul mainteneur qui contribue au blocage, c'est un mode de
fonctionnement perdant-perdant, comme le libéralisme et (souvent) le logiciel propriétaire. Le travail communautaire / collaboratif - et la vie réelle, d'ailleurs - sont beaucoup plus efficaces et agréables pour la communauté dans son ensemble (même si certains individus sont moins
riches) quand le mode de fonctionnement est gagnant-gagnant.
En logiciel ouvert, certains blocages sont parfois résolus (temporairement ou définitivement) par des forks. Pour TIGCC, je pense que ce serait plutôt du perdant-perdant. [voir le bas de la page 3 de ce topic !]

La sortie de la Nspire, sur laquelle on ne sait pour le moment
pas encore tourner des programmes, fournit une occasion de
terminer d'intégrer le gros du travail en attente sur les
TI-68k (docs d'ExtendeD sur les fonctions AMS 2.07+; grayscale 3 plans; mes contributions; etc.).
Je pense qu'il faut la saisir (si les anciens qui sont toujours dans la communauté ne le font pas, qui le fera ?), et puis passer à autre chose (Nspire, ou bien d'autres projets).
Mais pour finir ce qui attend (depuis jusqu'à cinq ans...), il faut du manpower... et (à mon sens), pour avoir plus de manpower, il faut que tu sois un peu plus "souple".

Pas tout à fait le même style, hmm ?
Toujours parce que je n'avais pas envie de fermer la discussion, j'ai mis du temps (15 jours, avec ce flame à propos d'ETP Studio / TIGCC, et le fait que Kevin n'ait pas répondu à mon mail, ce qu'il a maintenant fait) avant de poster un contenu proche de celui de ce brouillon.


./91, ./98 (Flanker): +1...

onur (./109) :
Voilà les rapports je dirais (en taille):

version VB d'ETP compiler / tigcc = 300%version C++ d'etp compiler / tigcc = 110% ?

Test cases?
Parce que là, ton chiffre porte un point d'interrogation, et je ne sais pas d'où tu le sors.

Un conseil, je sais que tu n'es pas super fort en C++

KTIGCC est écrit en quoi à ton avis? SmallTalk?

onur (./110) :
Regarde bien dans les sources, tu as l'air d'avoir de la m**** dans les yeux, il y a un répertoire genz80, ce n'est pas une chanson de pascal obispo. lol

Fonctionne-t'il déjà?

onur (./114) :
Il veut uniquement mettre de l'ombre pour que personne ne contribue au projet, et c'est pas acceptable.

Ce n'est pas vrai! Ce que je veux, c'est:
* que tu indiques clairement à tes utilisateurs et codéveloppeurs potentiels l'état du projet et
* que tu continues à travailler là-dessus, parce que je crains que le projet va mourir si tu ne comptes que sur d'autres personnes pour le continuer en son état actuel.

Et ensuite, je te conseille fortement de regarder du côté "frontend GCC", je suis prêt à t'aider si tu prends ce chemin. Squalyl propose de faire un pseudo-backend pour ton frontend qui l'interface au middle-end de GCC, un peu comme le backend "code intermédiaire" que tu as actuellement, mais on devra linker directement à GCC. Je pense que ce chemin est probablement faisable, il y a d'autres frontends GCC qui passent par leur propre représentation intermédiaire (ASTs frontend) avant de la convertir en ASTs GCC, ça te rend aussi moins dépendant des modifications internes à GCC.

De plus, il ferme les yeux sur les plus que le projet a par rapport à tigcc => multiplateform target.

Tu as 3 plateformes. GCC en a des dizaines.

Ce que tu veux faire, c'est une librairie qui abstrait les différences des plateformes. Mais une telle librairie serait aussi envisageable en C, et ta librairie sera probablement aussi utilisable en C d'une manière ou d'une autre! (Si tu prends le chemin "frontend GCC", elle le sera forcément parce que tu devras créer un .a linkable avec du code GCC en n'importe quel langage.)

Lionel Debroux (./117) :
Moi non plus, mais je suis plus "souple" que toi.

Ce genre de remarque est vraiment blessant pour qui la reçoit, je pense qu'avant d'être souple tu devrais revoir ta copie toi aussi. 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.

Ce que dit Kevin est largement plus "positif" et intéressant.

Tu demandes des Test case, c'est légitime. Mais comment peut on comparer un code dans deux langages sources différents? c'est pas forcément représentatif! T'as testé comment Onur?

D'autre part, merci beaucoup d'expliciter clairement tes revendications. La première, je pense qu'Onur peut s'en charger. La deuxième, c'est bien ce que tu dois comprendre, c'est qu'Onur (nous en avons souvent discuté) a peu de temps maintenant, et il a publié le code actuel d'ETPc pour que d'autres le reprennent. Il m'a dit être à la recherche des spécifications, pour ne pas avoir à réinventer la roue, et les distribura quand il les aura retrouvées. A partir de là nous pourrons travailler.

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...

donc voici la situation: Onur a des graphes d'état de son analyseur. J'attends qu'il me les envoie pour en faire une grammaire EBNF en bonne et due forme. Elle sera représentative de l'état actuel du langage. En même temps, j'invite Onur à prendre un peu de temps pour mettre sur le papier quelques idées de "cahier des charges" définissant clairement ce qu'il veut obtenir, et à indiquer sur le site du projet l'état du développement, quitte à être un peu plus pessimiste que d'habitude. Cela devrait être possible sans dépenser beaucoup de temps.

D'après ce que j'ai compris, le langage ETP Basic serait indépendant de la plate-forme, et les fonctions non implémentées seraient ajoutées à l'édition de liens depuis un .a ou .o, dans le genre de libgcc.

Kevin et Onur, qu'en pensez vous?

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.