PControl beta 3 - Page 3

Folco (./57) :
M'enfin bon, on doit avoir le même âge

Lionel est pas plus jeune ?

[cite]M'enfin bon, on doit avoir le même âge,
Je pense que je suis un peu plus jeune que toi:

et j'étais bien content de jouer aux jeux kernels bourrés de hacks en 98 et toi aussi.

Non, pour deux bonnes raisons
* je n'avais pas de TI-68k en 1998
Je l'ai acheté dans l'été 2000, en fin de seconde.
* je n'étais pas content d'utiliser les programmes kernel-based bourrés de hacks parce que l'expérience que j'en avais, c'est que ça ne faisait que de planter.

Quand je m'y connaissais encore moins que mes camarades en utilisation de TI-68k, j'ai installé DoorsOS II 0.98, parce qu'ils disaient que ça permettait de faire tourner des programmes. A l'époque, je n'avais pas encore de link et donc pas de possibilité de backup.

Sous DoorsOS II 0.98, j'ai subi l'instabilité monstre de txtrider (j'avais déjà raconté mes malheurs avec: je n'ai jamais réussi à voir un texte avec sans que ça se termine par un STO+ON/ESC+ON, sur plusieurs HW2 AMS 2.xx... et j'ai aussi vu, une fois, une splendide corruption de mémoire, dont j'ai retrouvé la description sauvegardée sur mon HDD ces jours-ci) et d'autres programmes (je me souviens en particulier d'un petit jeu de quelques KB qui plantait toujours avec Address Error au bout de quelques secondes d'utilisation). Pour ces deux programmes-là, c'était probablement plus la faute du programme kernel-based que du kernel lui-même, mais bon, à l'époque, je n'étais pas du côté programmeur et je mettais tout ça dans le même panier.

Plus tard, j'ai essayé UniOS 1.14, qui était la version courante à l'époque d'un truc censé être mieux que DoorsOS. C'était encore BEAUCOUP moins stable: ce n'étaient même plus les programmes en ASM qui se plantaient et qui étaient récupérables par ESC+ON, c'étaient des hard crashes dans des programmes en TI-BASIC... Plusieurs en quelques jours. J'ai donc effacé définitivement UniOS et tous les programmes kernel-based de ma calculatrice.
Ca a à peu près coïncidé avec ma découverte de TIGCC (printemps-été 2001) et donc du fait qu'on pouvait faire des programmes sans utiliser ces foutus kernels qui ne faisaient que planter (c'était l'expérience que j'en avais à l'époque, hein ). J'ai définitivement arrêté d'utiliser des "kernels", et un certain nombre de calculettes autour de moi aussi (notamment à cause de l'instabilité de txtrider).


Ce que je viens d'écrire n'est que la version civilisée, écrite avec le recul, appartenant à un topic pacifique (et non pas dans un gros flame lancé par un des plus gros trolls de ce forum) de mon premier post (écrit en tant que "XDanger") sur yAronet, dans un topic de cette section Software, le jour de mon inscription, dans le contexte suivant:
* persistance de ma récente mauvaise expérience utilisateur du kernel/kernel-based;
* récente découverte du fait qu'il n'était pas obligatoire de programmer en kernel-based;
* méconnaissance technique;
* méconnaissance totale de la réalité du comportement de Kevin, que je n'ai sue qu'à l'été 2004;
* enfin, et ce n'est pas le moindre des éléments de contexte, incapacité à se comporter convenablement dans une discussion, fût-elle houleuse, sur un forum ("le nouveau qui n'y connaît rien, qui se croit malin et se montre agressif"). C'est largement ici que j'ai appris ce qu'il ne faut pas faire.
Je ne suis fier ni de mon comportement ni de mon incompétence de l'époque, mais c'est un _fait_ que j'ai été comme ça, sur un forum public. Heureusement pour vous et pour moi que j'ai compris ce qui n'allait pas dans mon comportement et que j'ai changé.

Sinon SetupCharSet c'est quoi, ya rien dans tigccdoc

SetupCharSet (faststr.h et autres) / InitFastDraw (TI-Chess) est la routine qui permet d'avoir les adresses des fonts brutes. L'équivalent des RAM_CALLs dont je ne me souviens pas du nom.
Ces adresses sont utilisées par une routine de dessin, dont le code et le nom varient là aussi grandement entre les programmes de TICT et les programmes non TICT (différents modes de dessin, C ou ASM, etc.).

Ces routines "faststr", comme celles de la série "fastitoa" et aussi quantités d'updates non mergés (notamment parce que "ça prend beaucoup de temps à retester"... rappelons que Kevin a mon programme de tests...), ont été faites pour l'intégration à TIGCC. Mais c'était du temps où il y avait encore Sebastian.
Tu penses que depuis que Kevin est le seul mainteneur de TIGCC, on peut y faire rentrer un ensemble de routines qui prend plus de place par rapport à DrawStr (sauf nombre très élevé d'appels, puisque la convention d'appel est plus efficace), même si en l'utilisant, l'affichage de chaînes de caractères est 10 fois plus rapide (de mémoire, c'est l'ordre de grandeur sur AMS 2.xx) ? Allons donc

faststr et fastitoa ont été rejetés entièrement, pas repoussés (de même que ta réecriture de LOC_formatDate des AMS récents pour les anciens AMS, parce qu'elle utilise fastitoa), ils ne sont plus dans le ZIP actuel des mises à jour en attente.

j'ai eu la meme expérience que toi en manière de programmes Kernel: c'était de la merde (compliquée) qui plantait tout le temps.

./63: j'imagine que tu le précises pour les autres. Moi, je ne sais que trop bien qu'une partie du boulot que j'ai fait, parce que ça m'amuse, sert moins que s'il était intégré à TIGCC (ou ne sert plus du tout car il n'a plus d'intérêt pratique 5-6 ans après, déjà dit plus haut). Tout ça par suite de tes convictions personnelles et de ta mauvaise volonté.
Ca n'est pas une nouveauté que ton inertie et ton sale caractère (entre bien d'autres: tu nous as déjà écrit que plus on insiste, moins tu mets la priorité sur ce qu'on te demande) sont des causes de la faible absence d'avancement de TIGCC. Non, d'un point de vue _utilisateur_, KTIGCC N'est PAS une nouvelle fonctionnalité, et ne corrige pas, pour des raisons de compatibilité, les limitations des TPR.


Techniquement, je ne peux pas être d'accord avec ton choix de ne pas mettre faststr et fastitoa dans TIGCC, puisqu'il n'est pas à démontrer qu'il y a des situations où ces routines ont une utilité. Même si tu ne vois pas l'intérêt, d'autres le voient:
* faststr n'est qu'une généralisation et amélioration (pas besoin d'allocation mémoire + PortSet + DrawChar en boucle) d'une méthode qui existait déjà (ebook, pour éviter de passer plus ou moins une seconde à afficher une page de texte...);
* un embryon de fastitoa est utilisé dans le Game Of Life de FL, pour diminuer la part de temps CPU qui n'est pas passée dans le moteur de calcul (le but de FL, comme écrit dans le README, était d'aller plus vite que l'implémentation du Game Of Life par un copain, pas de gagner quelques malheureux octets - des octets, il est possible d'en gagner pas mal en n'utilisant aucun lanceur spécifique);
* d'une façon plus générale: le problème de faire des choses plus vite qu'AMS, pas seulement sur ces deux aspects, se présente souvent sur les forums.

Mais personne (à part toi) ne peut changer cet état de fait. Du moins, dans le TIGCC officiel dont tu es depuis des années le dictateur... sur l'autre, tu n'as pas de contrôle. Il faudrait déjà que tu saches où il est, et ceux qui sont au courant ne vont probablement pas te révéler l'info comme ça ^^


Voilà, ça aussi était une précision sur la précision.
[avec des EDITs qui ont essentiellement rajouté et déplacé des choses]

Il faut quand même reconnaitre les énormes progrès réalisés à ce niveau-là

Je les reconnais, puisque c'est un fait
Certaines des capacités du kernel-based ont été intégrées au linker de TIGCC 0.95+, et parmi celles-ci, certaines sont objectivement de bonnes idées en taille/vitesse: c'est donc que le kernel-based ne fait pas que des conneries

Non
Une capacité du kernel-based, universalisée par le linker de TIGCC 0.95+, est le support des BSS. Bon, en fait, c'est une mauvaise idée, surtout en taille.

Mais le linker de TIGCC 0.95+ apporte beaucoup plus que ça (optimisation, sections de startup, constructeurs&destructeurs, etc.) - et l'optimisation profite aussi aux programmes kernel-based.

Tu veux parler du micro-kernel qui contient autant de hacks que le kernel je suppose ?

Tu fais semblant de mal connaître le contenu du code de startup des programmes AMS native, hmm ?
C'est vraiment pas tous les programmes AMS native qui ont un code de startup contenant des hacks

Une autre capacité du kernel-based, universalisée par le linker de TIGCC 0.95+, est les relocations au format kernel. Le code de relogement/dérelogement étant petit, et les relocations étant plus efficaces, il y a gain de place par rapport aux relocations AMS native dès qu'il y a un nombre assez faible de relocations. Même si la bonne solution est de se débarrasser du maximum de relocations (optimisation par le linker, optimisation par le programmeur, -freg-relative-an, suppression des BSS, etc.).

Le format kernel sux, le format MLink est nettement plus efficace. Même le vieux format Fargo (le premier format compressé géré par ld-tigcc, c'est pour ça que c'est ce que vous avez en choisissant "compressed") est plus efficace que le format kernel, mais le code de décompression est relativement grand, donc c'était le bon choix pour Fargo qui a la décompression centralisée dans le kernel, mais pour ld-tigcc, le format MLink est meilleur dans la plupart des cas. Mais le format kernel qui n'est pas du tout compressé est clairement le pire.

Je n'ai pas écrit que les relocations au format kernel étaient les meilleures dans tous les cas, puisque c'est un fait que ce n'est pas vrai. J'ai une assez bonne idée des capacités des différents formats de relocation, puisque c'était un des changements que je faisais souvent lorsque j'optimisais des projets.
J'ai juste écrit qu'elles étaient, à partir d'un nombre assez faible de relocations (je ne le sais plus de mémoire, mais il est facile à estimer), plus efficaces que les relocations natives d'AMS. Ca, c'est un fait.