[Ramcalls et PedroM] Deux questions sur leur utilisation en C - Page 3

C'est un unrolling, c'est censé être une optimisation vitesse, mais ça a l'air mal fichu ici en effet. Essaie avec -fno-unroll-loops.

Bon, vu que ça commence à me lasser de coder pour TI (manque de motivation, moins de temps, seul dans mon coin, plus de majs des kernels/OS/toolchains, je poste ici mon dernier patch pour tigcc, qui permet d'avoir les ramcalls en fline en C : http://www.mirari.fr/0xTz
Les rares qui comprennent ce que ça veut dire en feront ce qu'ils veulent

(Tu veux une mise à jour kernel ?)

Non, j'ai rien sous le coude, mais je veux dire que tout est un peu mort ^^

Si encore il y avait des choses à écrire pour PedroM, des reviews à faire, des patches à soumettre et des tests à faire, ça serait pas mal, mais j'ai grand peur que tu sois pas dans cette optique depuis toutes ces années.

Et la toolchain commence à être vraiment vieille, avec un gcc4 bien vieux (4.1.2), jamais d'IDE dédié à la hauteur (même si j'ai commencé un truc de mon côté, mais pour qui ??), pas d'éditeur de sprites/maps digne de ce nom, etc... Bref, j'y ai passé d'excellents moments, mais cette fois je crois uqe c'est bien la fin ^^

(Ben moi, j'attends toujours les retours des tests de la 0.83).

QUOI ??
Ben écoute, j'ai pas plus de bugs que ceux déjà signalés, dont les problèmes de link avec Ti-Connect et la cli qui ne s'adapte pas avec la taille de la fonte courante. Hormis ça, t'as mergé les patchs de Lionel et moi (ramcalls fline et(c'est là depuis la 0.82 RC7 de mémoire) file system en ce qui me concerne), donc question features je suis satisfait.

Patch refusé: il y a un espace dans le nom du fichier ZIP et du répertoire qu'il contient, et de plus, les fichiers patch sont +x

Plus sérieusement:
* vu que la détection des F-Line ROM_CALLs est changée (ajout d'une virgule), dans quelles conditions as-tu re-testé le patch des F-Line ROM_CALLs ?
* vu que tu codes sous Linux, j'imagine que tu ne comptes pas modifier le code du patcher Delphi ?
Les RAM_CALLs en F-Line étant une spécificité "kernel", il ne faut pas modifier la partie du code de startup qui s'occupe de l'émulateur interne de F-Line, déjà.

Avec des sources C compilés avec -DUSE_FLINE_EMULATOR -DUSE_FLINE_ROM_CALLS -DUSE_FLINE_RAM_CALLS.
Les romcalls et les ramcalls que j'ai utilisés sont correctement appelés avec ça.

L'ajout de la virgule, c'est lors de l'identification de la ligne qui active la fonctionnalité, pour distinguer .set _F_LINE,0xF800 de .set _F_LINE_RAM_CALL,0xF000. Sinon, activer les RAM_CALLs en F-Line activerait aussi les ROM_CALLs en F-Line, et sans la constante définie, ça foirerait.

Folco (./64) :
un gcc4 bien vieux (4.1.2)

Libre à toi de le mettre à jour, ça serait enfin une contribution utile majeure à TIGCC.

jamais d'IDE dédié à la hauteur (même si j'ai commencé un truc de mon côté, mais pour qui ??)

Qu'est-ce qui ne va pas dans KTIGCC? Tu es libre de l'améliorer, aussi. Tout le monde crache sans arrêt sur KTIGCC, mais personne n'a fait quoi que ce soit pour l'améliorer.

(À mon avis, il faudrait surtout 1. finaliser la version KDE 4 dans le CVS HEAD et 2. songer à un portage KF5.)

pas d'éditeur de sprites/maps digne de ce nom

C'est une fonctionnalité désirée, ça aussi, qu'attends-tu pour en coder un? (J'avais d'ailleurs proposé ça comme projet GSoC en 2007, ça aurait été un followup à mon GSoC 2006 qui a donné un KTIGCC finalisé, mais Detached Solutions a préféré prendre 3 projets TI-83+/84+, et KDE n'a pas été intéressé par le projet non plus.)

Kevin Kofler (./72) :
Qu'est-ce qui ne va pas dans KTIGCC? Tu es libre de l'améliorer, aussi. Tout le monde crache sans arrêt sur KTIGCC, mais personne n'a fait quoi que ce soit pour l'améliorer.

J'ai jamais craché dessus, je pense juste qu'il aurait été sympa d'avoir quelque chose plus à la hauteur des éditeurs modernes, avec par exemple l'utilisation de clang pour le code-completion, et bien plus d'options qu'il n'y en a actuellement.

Clang? En 2006? LOL…

Et il ne faut pas oublier que Clang n'est pas compatible à 100% avec GCC (et encore moins avec les modifications TIGCC à GCC), j'ai bien peur qu'il ne va pas comprendre l'intégralité de TIGCCLIB (sans patcher aussi Clang, et là, ça commence à faire lourd, déjà le patch à GCC est énorme).

Mais libre à toi d'essayer.

Il faut dire que ça a toujours été un des facteurs les plus démotivants pour le développement de TIGCC: J'ai des utilisateurs qui sont à 100% des développeurs, mais quand on leur demande de contribuer au développement de l'outil lui-même, rien (du moins là où ça aurait vraiment été nécessaire, cf. le post précédent pour quelques exemples).

Je critique pas le fait que clang n'ait pas été utilisé en 2006, mais c'est quelque chose qui aurait pu être envisagé depuis ^^

Bah, si je devais me replonger sur TIGCC, il y a beaucoup d'autres choses qui auraient une priorité beaucoup plus élevée que de remplacer le système de complétion qui fonctionne très bien. La mise à jour de GCC par exemple.

En ce qui concerne la mise à jour de GCC, ce qui est triste, c'est que j'ai dit à Lionel dès le départ que c'est essentiel pour le long terme. L'équipe de GCC4TI n'en avait rien à faire. Maintenant, c'est "le long terme", GCC 4.1.x est devenu une antiquité, et GCC4TI est tout aussi obsolète que TIGCC. GCC4TI n'a été que du pur gaspillage d'effort à faire des modifications de détails sans intérêt (et qui n'étaient pas toutes des améliorations, non plus).

Bah c'est ça, le logiciel libre, chacun est libre de forker et d'en faire ce qu'il veut (et non pas ce que tu veux). Tu devrais être content !

Bah, ils ont le droit de faire ce qu'ils veulent, mais ils ont à plusieurs reprises essayé de vendre GCC4TI comme la "continuation" du projet TIGCC, ce qui est totalement déceptif, parce qu'en réalité le but primaire de GCC4TI a toujours été de changer certaines choses, pas de continuer quoi que ce soit. (La preuve, une seule modification a été apportée à GCC par le projet GCC4TI depuis son existence, un correctif pour un warning de l'assembleur sans aucun effet sur le binaire produit. (Le patch utilise d'ailleurs abusivement le nom "tigcc", ce n'est pas la version 4.1.2-tigcc-4 parce que ça ne vient pas du projet TIGCC!) Pas la moindre mise à jour de GCC n'a été effectuée.)

Et bien t'as raté plus d'un patch qui auraient fait du bien à TIGCC.

Exemples, et je te dis (si je m'en rappelle encore) pourquoi il n'a pas été mergé. Ça m'étonnerait que "t'as raté" soit l'explication la plus fréquente. J'ai été au courant de beaucoup de patches qui avaient des problèmes de conception fondamentale (l'idée était mauvaise dès le départ, les effets néfastes dépassant les effets bénéfiques), de conception de détail (algorithmie du patch concret) ou d'implémentation technique (par exemple des patches directement aux headers, sans documentation).

T'as mergé le patch de Lionel pour A68k en 64 bits ? Pour l'utilisation de fp dans A68k ? Les apports à tigcclib, ceux sur les niveaux de gris, ou pour SAVE_SCREEN en ce qui me concerne ? J'ai utilisé tous ces patches sans jamais le moindre souci.

Folco (./83) :
T'as mergé le patch de Lionel pour A68k en 64 bits ? Pour l'utilisation de fp dans A68k ?

Non, parce que d'un, ces modifications sont arrivées bien après le fork, quand je n'ai déjà plus eu le temps et la motivation de m'occuper de TIGCC, et de deux, A68k est déprécié depuis très longtemps et n'est livré plus que pour faire marcher les anciennes sources, donc des ajouts qui rajoutent du sucre syntaxique comme fp, bah, je ne vois vraiment pas du tout l'intérêt.

Les apports à tigcclib, ceux sur les niveaux de gris, ou pour SAVE_SCREEN en ce qui me concerne ?

Tu veux dire les optimisations qui économisent quelques octets? Je n'ai pas eu le temps de les tester, le code de démarrage est très compliqué à tester entièrement parce qu'il y a un nombre exponentiel de configurations possibles, et franchement pour 2 octets, ça ne vaut pas le coup. Et une modification qui change les registres détruits par une section du code de démarrage doit absolument être testée dans toutes les configurations possibles, parce qu'il y a des interdépendances (pour des raisons d'optimisation, justement – si chaque morceau de code de démarrage utilisait la convention d'appel C, la quantité de sauvegardes et restaurations de registres serait énorme!).

Franchement, si j'ai le temps, entre une amélioration de l'optimisation de GCC qui peut apporter >100 octets dans les grands programmes (ou l'adaptation d'une grosse mise à jour upstream comme l'était GCC 4.0 qui a économisé >1000 octets sur certains programmes!) et une optimisation du code de démarrage qui économise ≤ 10 octets à un seul endroit, j'ai vite choisi sur quoi passer mon temps.

Et je t'avais demandé à l'époque comment tu avais testé tes modifications au code de démarrage. De mémoire, tu as répondu quelque chose comme "pas besoin de tester, je suis sûr que ça marche", ça ne m'a pas vraiment inspiré de la confiance.

Je suis tout à fait d'accord avec toi quant à cette définition des priorités.
Par contre, quant aux tests, tu ne me feras pas croire que trois lignes en asm ultra-basique, qui détruisent deux registres, ont un comportement tellement complexe qu'il faille des années de tests avant de le valider. T'étais pas partisan de release early, release often, qui concrètement fait reposer les tests sur les utilisateurs ? Et pour des choses autrement plus complexes et casse-gueule. Et bien bien t'en as pris, car tu avais des retours, et grâce à ceux-là tu as avancé.
Il se pourrait que ce soit à cause de ce genre de différences de points de vue à répétition que ceratines collaborations ont eu du mal à s'installer

Folco (./85) :
Par contre, quant aux tests, tu ne me feras pas croire que trois lignes en asm ultra-basique, qui détruisent deux registres, ont un comportement tellement complexe qu'il faille des années de tests avant de le valider.

Dans le code de démarrage, il faut des heures de tests, heures que je n'ai tout simplement pas eues (et maintenant, si je devais me replonger sur TIGCC, il y aurait beaucoup d'autres trucs à faire avant, dont faire le tri de toutes les modifications de GCC4TI pour voir lesquelles sont acceptables pour TIGCC (beaucoup ne le sont pas, d'autres le seraient, mais pas de la manière de laquelle ça a été implémenté dans GCC4TI, donc faire ça proprement prendrait aussi du temps, et d'autres encore (dont les tiens) doivent être testés parce que je ne fais pas confiance à GCC4TI)).