onur Le 15/09/2007 à 15:01 Je crois que tu as pas regardé de près. Ca compile en asm 68k, il reste des trucs qui sont écrits dans todo.txt.
Ceci dit, c'est surtout pour les autres cibles que c'est intéressant de rendre ce projet open source, car ca profite à tout le monde et moi je n'ai plus le temps.
Tout ce qui passe pas par le port 80, c'est de la triche.
onur Le 15/09/2007 à 15:12 il y a des fichiers .etp dans TestFiles.
Je me souviens plus exactement moi non plus, je vais me replonger. Regarde dans Gen68k.cpp fonction CodeInstr, ca a l'air de coder affectation, return (oui bon cest le plus simple le return), call (appel de procédure, les appels de fonctions sont dans la génération d'expression je crois), boucle for, boucles do loop while, boucle do while, les if (pas évident du tout), bien sur tout ceci avec la génération d'expression arithmétique et expression booléennes avec placement dans les registres ou en mémoire géré par une pile etc..
Ca permet déjà de compiler pas mal de chose. Par contre, j'ai pas du tout fait de lib a part un truc pour afficher un entier: etplib.elib est un fichier de définition (similaire à un .h) qui dit les noms de fonctions dans la lib standart et qu'il faut donner à l'assembleur par la suite.
Tout ce qui passe pas par le port 80, c'est de la triche.
il y a un site regroupant les programmes ETP existants, histoire de voir à quoi ça ressemble ?
« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)
onur Le 15/09/2007 à 15:50 Oui possible, c'est un problème dans la lib pure.
Tout ce qui passe pas par le port 80, c'est de la triche.
Kevin, tu sais ce qu'on va te répondre si tu lances des flames hein... Si t'es pas content tu vas débugger tigcc, mais tu évites de critiquer négativement.
Un projet tel que celui d'Onur a le mérite d'exister, il offre un langage alternatif qui ne menace pas l'avenir de tigcc. Il serait plus intéressant d'offrir tes commentaires pour l'améliorer au lieu de le descendre.
Imagine ça comme du basic compilé qui a pour but d'être compilable sur plusieurs plate formes.
Au lieu de regarder ce qui n'est pas fait, regarde ce qui est fait, par un seul homme largement occupé par ailleurs.
Nan mais il veut pas "qu'ETP soit un succès" ©, donc il essaiera de démonter par tous les moyens le programme d'Onur...
Écoutez, regardez vous-mêmes ce qu'il y a, je ne "démonte" pas, je constate.
Comment peut on reprocher à un aussi jeune programme de ne pas avoir toutes les fonctionnalités de son concurrent développé depuis des années?
Onur est étudiant et il a bcp de projets plus importants à gérer avant un amusement. Il a dit qu'il allait se replonger dans le code, ce qui laisse supposer qu'il l'a laissé dormir longtemps, non? patience!
onur Le 15/09/2007 à 17:33 Euh.. en fait, j'ai fait ca surtout les premières années d'écoles d'ingé. Mais j'ai du mettre de coté avec le double-cursus etc..
Justement je ne sais pas si j'aurais le temps de l'avancer beaucoup et rapidement. Mais je vais me replonger dans le code pour me rapeller exactement de où ca en était.
Le plus gros avantage que je vois à ce projet à l'heure actuelle, c'est le multi-plateforme target. Si avec un seul programme les gens pouvaient avoir du z80,68k et qui sait du nsprire.. ca serait super. Pour le z80 je pense qu'il y aura des gens motivés pour faire la lib et améliorer/finir la génération code z80.
Une chose que dit K² est vrai: il suffit de regarder... pour voir le boulot qu'il y a eu. Moi même j'étais assez étonné quand j'ai regardé à nouveau tout le code ce matin.
Tout ce qui passe pas par le port 80, c'est de la triche.
Kevin > Pourquoi se plaindre du travail d'une minorité de la communauté alors que celle-ci n'est plus active du tout ? tu devrais encourager le développement de n'importe quel programme !
+1 geogeo, évidemment...
J'ajouterai qu'en tant qu'un des responsables (principaux - "cause racine", cf. un de mes messages sur TICT HQ) du rétrécissement de la taille de la communauté, il est assez mal placé pour se plaindre de ce rétrécissement. Et il faut être plusieurs pour s'engueuler et décourager les autres: il est un fait que d'autres personnes que Kevin, à commencer par moi, ont également participé à ce rétrécissement de la taille de la communauté.
Lionel: tes trolls ad hominem, tu peux les garder pour toi. Les facteurs qui ont mené à l'état actuel de la communauté n'ont rien à voir avec le comportement d'une personne, que ce soit moi ou même toi d'ailleurs.
Quant à la vitesse à laquelle j'intègre les contributions, ben les contributions que je reçois se classent en 2 catégories:
* documentation, souvent pas prête à être mergée telle quelle (cf. cross-references, mais il y a aussi souvent des fautes de grammaire, des imprécisions, des address hacks qui ne fonctionnent pas, des versions minimales de AMS incorrectes (genre 1.01 quand 1.00 suffit) etc.). Donc le merge d'un tel fichier de documentation nécessite de:
1. tester les address hacks (sur tous les AMS concernés), les corriger si nécessaire,
2. tester la version minimale de AMS nécessaire pour le address hack, la corriger si nécessaire,
3. relire le texte de la documentation, corriger les fautes d'anglais et de contenu et harmoniser la mise en forme avec le style de la documentation existante
4. mettre à jour les cross-references dans toute la documentation
J'estime environ 1 heure de travail (par fichier, c'est-à-dire par fonction!) pour les tests (1. et 2.), 1 heure pour la relecture et les corrections (3.) et 1 heure pour les cross-references (4.), donc 3 heures de travail par fonction! C'est loin d'être négligeable.
Et souvent les fonctions qui sont documentées dans ces contributions sont déjà utilisables avec leur prototype de unknown.h, donc c'est un pur ajout de documentation. Je retiens que les améliorations au compilateur lui-même sont beaucoup plus importantes. Pour la documentation manquante, on peut consulter celle de TIFS et/ou la version qui est dans contrib.zip.
* optimisations minimes, qui gagnent 2 octets sur une fonction en ASM de TIGCCLIB (intérêt quasiment nul), et en général l'optimisation n'a même pas été testée par celui qui l'envoie (ou alors il n'est pas précisé si, comment et avec quoi ça a été testé, donc c'est comme si les tests n'avaient pas été faits), donc il faut là aussi un temps non-négligeable pour les tests de régressions.
Je ne reçois quasiment aucune contribution vraiment utile:
* corrections de bogues! (De loin les plus importantes!) Il reste des bogues dans A68k par exemple, personne ne s'en occupe.
* optimisations majeures (sur une fonction ASM, c'est 10 octets strict minimum (et encore), mais l'idéal, c'est d'améliorer les optimisations dans le compilateur parce que du coup toutes les fonctions C en profitent, y compris toutes les fonctions en C de TIGCCLIB), idéalement testées par le contributeur (je ne vois pas pourquoi ce serait à moi de tester les patches qu'on m'envoie - et pour que je puisse éviter de tester moi-même, il me faut un report précis des tests effectués).
onur Le 16/09/2007 à 02:46
Mais toi aussi cest du ad hominem non stop k².
Les tests livrés avec le projet ne sont pas representatifs, tu te doutes bien que j'ai testé a chaque fois avec des trucs différents. Maintenant, il faut un environnement de test je suis ok, cest pour ca que je trainais pour lancer le truc en open source, mais je mettrai des tests comme il faut quand il y aura des contributeurs.
Tout ce qui passe pas par le port 80, c'est de la triche.
KK> Oué bah quand on te signale un bug, soit tu l'ignores parce que c'est pas dans un zouli <FORM></FORM> envoyé dans ta boîte mail, soit tu flames celui qui a découvert le bug, donc bon...
les noms de variables en français. Et encore, je suppose que je dois être content qu'ils ne sont pas en turc. 
)
