A mon avis la seule chose à exiger formellement doit être l'adresse email, pour prendre contact avec le reporteur et lui demander plus d'infos...
Si les gens savent pas remplir des formulaires, je pense pas qu'on puisse y faire grand chose

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
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
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.
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)
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?))
onur (./94) :
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.
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!
onur (./100) :
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.
onur (./102) :
et pour la génération z80?
et nspire?
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...
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".
-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!
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) :
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)).
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.
![]()
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.
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.
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.
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.
Kevin Kofler (./107) :
Tu entends quoi par "gros stubs"?
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.
onur (./109) :
LIS CE P***** DE FICHIER GEN68K.CPP
onur (./110) :
tu as l'air d'avoir de la m**** dans les yeux
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
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
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.
>> > > 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) ?
> > 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".
onur (./109) :
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++
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
onur (./114) :
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.
Lionel Debroux (./117) :
Moi non plus, mais je suis plus "souple" que toi.
Kevin Kofler (./118) :
Tu as 3 plateformes. GCC en a des dizaines