Bon moi je vais arrêter de passer mon temps à dégrader l'ambiance un peu plus en te faisant chier avec ça ! En espérant que tu vas aussi faire plus attention à ne pas constamment nous bassiner avec ton nostub, ta TICT, etc
Blue_Z a écrit :
Et encore t'as pas tout vu : son nouveau topic intitulé "Lib kernel", créé il y a une semaine à peine, totalise déjà 5 pages. Ce type est un génie !
Kevin Kofler a écrit :
Justement non, PpHd s'amuse à mettre du "No" partout dans _nostub avec un "but ..." en dessous. Alors que ça devrait être "Yes because", pas "No but". Ça rend les commentaires très subjectifs.
C'est tout aussi simple à condition qu'on l'utilise pour ce pour quoi elle est prévue (dépasser les 64 KO), pas pour du partage de code.
N'importe quoi. Tu connais les lanceurs?
1. Va donc demander sur n'importe quel forum international...
2. J'ai déjà expliqué pourquoi le kernel est dépassé: les raisons pour lesquels les kernels existent sont:
a) pas de support d'assembleur natif. Ce n'est pas le cas ici.
b) support d'assembleur natif mal documenté. Ce n'est plus le cas depuis la sortie de TIGCCLIB et de sa documentation en janvier 2000.
c) compatibilité avec les vieux programmes pour des kernels pour d'autres calculatrices. En l'occurence avec les programmes pour Fargo. Ça n'a plus beaucoup d'importance, vu le nombre de programmes natifs à être développés.
Et les kernels l'ont copié sur Fargo.
Et franchement, notre système est mieux fait que celui des kernels: il permet tout type de données, pas seulement les commentaires. Et il est extensible: on peut rajouter toutes sortes de types de données.
Parce que ces TSRs sont séparés, pas unifiés. Prends PreOs et supprime le support pour le format kernel et tu verras que tu auras gagné rapidement 2 KO ou presque.
Personne ne t'empêche d'utiliser ttstart ou TICTEX pour tout.
L'utilisation de place par le code linké statiquement plusieurs fois n'approche même pas le gaspillage de place pour les routines inutilisées des librairies dynamiques.
Si on veut construire un compilateur optimisant, le minimum à faire est de jeter un coup d'œil sur les optimisations employées par GCC. C'est quand-même la référence en termes de compilateurs optimisants open-source. Son ignorance des termes techniques utilisés par GCC me montre qu'il n'a pas fait ce travail-là. Ça ne me laisse pas présager de bonnes choses au sujet de l'optimisation de GTC. À mon avis, c'est du bidouillage avec des tonnes de "peepholes", et aucune optimisation à un niveau global.
En effet. Je ne pense même pas à programmer exclusivement pour Pedrom.
Kevin Kofler a écrit :
Bon, code-moi ça en BASIC:
J'en doûte.
Non. fprintf dépendrait de printf etc. Donc la taille de chaque routine d'accès aux fichiers de stdio.h doublerait.
Parce que les kernels les mettaient dans leurs headers.
Le plus fort, c'est que Rusty Wagner et Xavier Vassor n'ont même pas suivi les recommandations de la documentation de Fargo dans certains cas. Cf. la définition de FolderListHandle et MainHandle comme constantes, alors que David Ellsworth le déconseillait explicitement pour des raisons de compatibilité avec les ROMs futures. Le résultat: avec l'arrivée de AMS 2, c'était la catastrophe.
C'est surtout parce que Zeljko (l'auteur de CBlaster et de CReversi) ne s'amusait pas à aller traffiquer dans MainHandle pour y chercher des fichiers, alors qu'il y a des ROM_CALLs faits pour ça.
Plus complexe != technologiquement supérieur. Pour que ce soit supérieur, il faudrait que la complexité apporte quelque chose. Une complexité inutile est un signe d'infériorité technologique. Et c'est le cas ici.
_nostub = no stub = pas de stub. Le header des commentaires n'est pas un stub, donc c'est du _nostub.
La librairie est mal faite tout simplement. Comme la plupart des librairies statiques pour ordinateur d'ailleurs.Souvent, les développeurs développent ces libraires en ne pensant qu'au linkage dynamique, et voici le résultat. Commence par leur envoyer un bug report (avec un titre de style "Improper separation of functions for static linking". Sévérité: "Serious").
Non, un programme non-TSR qui installe un kernel ou n'importe quel autre TSR, ça s'appelle un leak de mémoire.
Essaye:
* d'appuyer sur [DIAMOND]+[ON] pendant l'exécution d'un jeu qui ne le gère pas explicitement
* d'appuyer sur [DIAMOND]+[ON] pendant qu'AMS dessine un graphique
et tu verras que AMS ne le gère pas de manière optimale. J'appréciais bien cette fonctionnalité de Universal OS (il y a longtemps, quand j'avais encore un kernel sur ma TI-89 HW1, maintenant je n'en ai plus) et je trouve que c'est une bonne idée de la part de KerNO de l'offrir.
Ce n'est pas bogué. Je cite J89hw.txt:
Ce n'est pas de la mauvaise foi. Le format kernel (et aussi le format Fargo d'ailleurs, mais j'ai pu réutiliser une grande partie du code du format kernel pour implémenter le format Fargo) a besoin de beaucoup plus de code dans ld-tigcc que le format _nostub.
Certes. Mais en voyant Chrono (qui n'utilise pas de masques), on ne dirait pas.
Franchement, je ne sais pas (malgré le fait que ce soit moi qui ais écrit le code pour lancer TICTEX). Mais je ne pense pas que ça pose problème.
Et si on modifiait bottom_estack temporairement, pour que HS_popEStack ne touche pas à ce qui y était déjà?
Kevin Kofler a écrit :
Parce que ce n'est pas une fonction de AMS. AMS est incapable de reloger ton format, donc tu ne respectes pas le format de AMS.
Non, c'est juste un cas exceptionnel.
En effet.
En _nostub non plus, sauf si on programme un shell. Et il y a déjà des shells en _nostub, donc il faudrait peut-être programmer autre chose...
Moi, j'appelle ça beaucoup de place pour une librairie graphique. ExtGraph prend au maximum 2 ou 3 KO dans le programme, et encore, le programme doit utiliser pratiquement toutes les fonctions offertes pour que ce soit le cas.
Non. 10 fps sont la limite à partir de laquelle on ne voit plus aucune différence. Donc 10 ou 20 fps reviennent exactement au même. La limite "à ne pas franchir" est encore en dessous. Je la mets à 3 ou 4 fps.
Tu n'as pas du tout compris. Ma question, c'est: pour choisir les librairies vraiment utilisées dans le pack, il fait comment? Parce que je te rappelle que c'est ça le but du jeu: pouvoir copier sur la calculatrice uniquement ce qui est vraiment utilisé. Et non pas "copier en RAM uniquement ce qui est vraiment utilisé", mais bien "copier sur la calculatrice (archive comprise) uniquement ce qui est vraiment utilisé"! Tu n'as pas l'air d'avoir compris ça.
Si, c'est un hack. Ce n'est plus une librairie, c'est un paquet de librairies. Et ça n'a aucun avantage en pratique par rapport à l'emploi d'une seule librairie dynamique. En particulier, tu es complètement passé à côté de ce qui était demandé: faire en sorte que seul ce qui est réellement utilisé se retrouve sur la calculatrice. Tu as donc bien confirmé que ce n'est pas possible de manière pratique avec des librairies dynamiques. CQFD. Jamais les librairies dynamiques ne pourront-elles offrir cette fonctionnalité des librairies statiques.
Inebranlable !
Ca pourrait etre marrant
Tu n'as pas encore plus compliqué?
Ça montre bien que le fait de se limiter à une DLL simplifie l'implémentation.
Qui?
Rien ne dit qu'un futur AMS n'empêchera pas à PreOs de fonctionner.
Ben, techniquement, c'est ce qu'elles sont.
Mais dans un cas, on a tous les décalages, masquages etc. à faire sur les sprites alors que dans l'autre, on n'a qu'une boucle de lsl ou lsr et de roxl ou roxr.
Pourquoi ça? put_plane n'est pas fondamentalement différent d'une double boucle à ce que je sache.
Ben, la définition du scrolling différentiel, c'est plusieurs fonds qui défilent à des vitesses différentes.
Oui, excellente idée!
Et pourquoi pas une routine d'effaçage des certificats en $34.l?
En _nostub aussi si on le met dans le lanceur personnalisé.
Comme déjà dit, réduire les lignes à la barbare ne donnera rien de lisible. Il faudra obligatoirement adapter le programme en partant de la source.
Tu ferais mieux d'utiliser cette place pour les ROM_CALLs AMS 2 les plus utiles.
On le sait: il faut utiliser la version qui est linkée dans le programme.
Ça reste une solution insatisfaisante à un problème lié directement aux librairies dynamiques. Mais apparemment, la seule solution satisfaisante est tabou pour toi. Elle s'appelle "linkage statique".
Kevin Kofler a écrit :
Ça n'a aucun rapport avec le problème dont on parle (fonctions inutilisées). N'essaye pas de passer à côté de l'argument que tu ne peux pas contrer.
Ben oui. Donc maintenant, fais pareil pour genlib et elle sera facile à passer en statique.
Il n'y a aucune raison de ne pas utiliser des variables globales dans genlib. Tu peux même mettre chacune dans son propre fichier objet quand tu passes en statique.
As-tu essayé GCC 3.3 (prerelease)?
Mais dans l'esprit "le kernel gère tout", ça serait au kernel de décompresser, pas à une librairie externe.
Ça serait encore plus transparent si c'était le kernel qui décompresse.
Pas du tout. Si on veut de la vitesse, on ne compresse pas. Si on compresse, on veut de la place.
Je ne sais pas, mais il n'y a pas que les licences au monde. Si tu fais quelque chose avec un programme qui est contraire à la volonté de son auteur, tu vas te faire démonter, que ce soit techniquement une violation de la licence ou pas.
Peux-tu élaborer?
Le problème est surtout que tu n'as pas lu ou pas compris les "consignes". Je parlais de copie sur la calculatrice des fonctions vraiment utilisées uniquement, et toi, tu parles de copie en RAM des fonctions vraiment utilisées uniquement. Ça n'a rien à voir. Ta solution proposée est totalement hors-sujet.
LOL, si je lis genlib__0030 dans une source, je n'ai aucune idée de ce que c'est! En revanche, si je lis genlib_make_coffee (
Aucun rapport avec ce de quoi on parle.
Tant pis, on garde le nom d'origine. Ou on propose le nom d'origine en "deprecated alias", à l'aide d'un simple #define. C'est la solution qu'on a choisi dans certains cas dans TIGCCLIB.
Moi, je mettrais le _nostub au début. Ensuite, entre FlashApps et kernel, j'hesite. Franchement, je n'aime ni l'un ni l'autre.
Adam Palmer, review de TI-Chess sur ticalc.org, 31 août 2000 (version 3.01).
Non, EM_twinSymFromExtMem doit être appelé sur un SYM_STR ou sur un HSym (au choix), donc quand on en est au HANDLE, on est censé avoir déjà fait ce travail. C'est ça l'ordre des choses prévu par AMS.
Parce que GCC est suffisamment intelligent pour copier de x(a6) vers y(a6) sans passer par un registre intermédiaire. As-tu essayé ce que ça donne en -O0?
Mais non. J'avais horreur de la syntaxe GNU et de ces % quand j'ai commencé (ce qui m'a motivé à maintenir A68k, ce qui m'a fait rentrer dans l'équipe de TIGCC
atof ne prend pratiquement pas de place. C'est push_parse_text qui fait le vrai travail.
D'exemples où on est obligés d'utiliser des listes chaînées énormes.
Est-il si grave que ça d'avoir un mélange de fontes prises à des endroits différents? Et dans 3 ou 4 programmes seulement?
Oui, laisse au programmeur le soin d'en decider, donc propose-lui une version statique.
Il y a des jeux assez variés qui l'utilisent. Par exemple un PacMan en 3D.
Tu es plus fou que je pensais...
Il te faut vraiment faire des cours d'utilisabilité, et rapidement!
Commence par lire ça et ça.
Mais pas le temps.
Ce n'est pas direct parce qu'il y a l'installation de PreOs.
C'est le prix à payer pour le comfort d'utilisation.
Kevin Kofler a écrit :
Mais consommée pour quelque chose d'utile.
Non, c'est moins flexible.
Pas vraiment. Le facteur limitant est la vitesse du port I/O, pas celle des routines.
On met le plan foncé en plan clair et on dégage le plan clair. Ça fait un bon effet de lumière ponctuelle, sans qu'on ait à se fatiguer.
Qui?
Il faudra que tu m'expliques alors, parce que pour moi, c'est exactement la même chose.
Comment fais-tu alors?
La plupart des programmes TIGCC n'utilisent pas plus de 1 ou au maximum 2 KO de tigcc.a. N'oublie pas que la plupart des routines déclarées dans TIGCCLIB proviennent directement de AMS.
Je parle de fonctions vraiment utiles. Et cela dans un contexte de jeu 2D, pas 3D.
Ben, sans les sources, il ne marchera plus, et genlib n'y changera strictement rien.
C'est bien ce que je leur reproche. Ces fonctions n'ont aucun intérêt!!! Il y a des ROM_CALLs qui font exactement la même chose!
Bref, ce n'est pas une bonne idée d'utiliser exit en cas d'erreurs.
Pour que ce soit intéressant, il faudrait au moins un facteur 3. Là, on tourne autour de 4/3, donc on est très loin d'un facteur 3.
Il faudra que tu m'expliques comment tu fais alors...
Ben, c'est dur de trouver une personne de confiance? Ben, un peu de logique:
* Dans l'équipe de TIGCC, nous avons souvent besoin de sources pour débogueur des problèmes du compilateur.
* Par conséquent, nous avons tout intérêt à ne pas diffuser les sources qu'on nous envoie sans la permission de l'auteur, parce que sinon, plus personne ne va nous envoyer les sources dont on a besoin pour déboguer GCC.
* Conclusion: On peut compter sur les membres de l'équipe de TIGCC pour ce genre de choses.
C'est de l'irrespect de format parce que tu utilises un autre format conteneur que celui prévu pour la technique de compression employée.
Déjà parce qu'il est extensible à d'autres types de données (on en offre déjà 7 dès le début). Ensuite, parce que notre header est mieux protégé contre les faux positifs que celui des kernels (signature plus longue, et le début de la signature est une instruction réellement exécutée et qui ne fait strictement rien à part changer quelques flags qu'un simple tst changerait de la même manière).
"evil" utilisé comme adjectif ne veut pas dire "diable", juste "méchant". Ce n'est que quand on utilise "evil" comme nom commun que c'est traduisible à peu près par "diable".
Donc pour toi DoorsOS est un produit du diable?
Faux. if (*(unsigned short *)0x32!=('R'<<8+'O')) return;
Ben oui, il s'y intéresse. La preuve: il travaille activement sur des "wrappers" pour pouvoir utiliser les ROM_CALLs exportés seulement sous AMS 2 aussi sous AMS 1. Ces wrappers se trouveront dans TIGCC 0.95.
Pour l'instant, Pedrom n'est pas supporté officiellement, vu que ce n'est même pas sorti officiellement. Quand ça sera sorti officiellement, on verra.
En effet.
Kevin Kofler a écrit :
Pas si les programmes eux-mêmes utilisent du 0x40000. Et il y en a un peu partout. Par exemple pour modifier les interruptions. Ça concerne de la même manière les programmes pour kernel que les programmes _nostub d'ailleurs.
Pour des programmes mathématiques, oui. J'en ai écrit un, et il est actuellement en MIN_AMS=204. Si Lionel fait bien son travail, je pourrai peut-être descendre MIN_AMS à 101 ou même à 100.
Donc PreOs deviendra encore plus gros...
Il ne faut pas rêver. Les programmes TIGCC utilisent en général très peu de routines dans tigcc.a. TIGCCLIB est avant tout une collection de déclarations de ROM_CALLs.
J'en doûte. ExtGraph est nettement plus facile à utiliser que genlib.
Sauf que les "assez doués" ne programmeront probablement qu'en _nostub.
Il permet une seule chose de plus: le format kernel. C'est cela qui bouffe toute la place que PreOs a en plus par rapport à KerNO!
Si on tronque, on n'a pas besoin de patches. Mais c'est une solution barbare. La seule solution propre est de porter le programme, qu'il soit en _nostub ou en kernel.
Tu utilises autre chose sur AMS 1.0x. Par exemple un prélèvement à l'intérieur de DrawStr. Et pour Pedrom, tu utilises encore autre chose. À toi de définir l'interface pour récupérer les adresses des fontes utilisées par Pedrom.
C'est un hack. Ça donne des programmes qui leakent de la mémoire. TIGCC ne permettra jamais ça.
Sachant que c'est moi qui ai pris sa place en tant que mainteneur de GCC (enfin, pas directement: d'abord Sebastian a remplacé Blue_Z, et puis j'ai remplacé Sebastian puisqu'il n'avait plus le temps de s'occuper de GCC), je prends cela comme une insulte personnelle envers moi. 
