Fonction attendre(); - Page 5

Les __need_in_use_bit ne sont plus que dans les headers, il y en a aussi dans tigcc.a maintenant (parce que tigcc.a a été recompilée avec les headers à jour).

Kevin Kofler (./100) :
cf. TitaniK et Iceberg qui ont été nécessaires parce que PpHd a mis trop de temps pour mettre à jour PreOs pour la Titanium).

Tout çà parce que j'ai voulu faire une release de qualité et pas à la va-vite. Surtout que la deadline réelle du point de vue utilisateur, c'était septembre, et il est sorti début septembre.

Kevin Kofler (./100) :
C'est une extension propriétaire de PreOs, donc TIGCC ne peut pas conseiller son utilisation.

Mais PreOS ne possède rien du tout. Il propose des services, c'est tout.
Si un nouveau kernel doit sortir le jour, parce que preos c'est has been, ben il supportera ces fonctionnalités.
C'est bien pour çà que je réfléchit à 2 x avant d'en ajouter.

Kevin Kofler (./102) :
Ben, parce que manque de chance, c'était une spécification préliminaire et PpHd a choisi de ne pas l'implémenter.

Je vais finir par l'implanter même si ca double la taille de preos ce truc. Plus sérieusement, je ne l'ai pas fait parce que ca double pratiquement la partie résidente de preos (en plus de lui faire dépasser 8K ce qui est le maximum possible pour un kernel).

Lionel Debroux (./105) :
PedroM-native ou Pedrom-only ? Dans le deuxième cas, tu t'amuses peut-être, mais il n'y a pas beaucoup mieux à faire si tu veux que tes programmes soient utilisés par pas bien plus que 0% des calculettes (quelques centaines au maximum ?)

Bof PedroM only, ou pas, ca reste 0% de nos jours.

Kevin Kofler (./107) :
En revanche tes programmes sont PreOs-only, ils utilisent les extensions propriétaires de PreOs au format kernel.

Sur Titanium, ca ne pose aucun problème. Sur les autres machines aussi.

Jyaif (./114) :
Pas besoin d'installer un kernel, ni d'installer de libs.

C'est vrai. PedroM a tout çà d'intégrer d'office.

Kevin Kofler (./118) :
Un jeu n'a pas de raison d'avoir besoin du HW3Patch!

Et les plug-ins permettant de faire évoluer les fonctionnalits ?

PpHd (./122) :
Tout çà parce que j'ai voulu faire une release de qualité et pas à la va-vite. Surtout que la deadline réelle du point de vue utilisateur, c'était septembre, et il est sorti début septembre.

La Titanium était sortie aux USA en juillet et le semestre commence à la mi-août dans beaucoup d'états US.

Si un nouveau kernel doit sortir le jour, parce que preos c'est has been, ben il supportera ces fonctionnalités.

Peut-être, peut-être pas...

Je vais finir par l'implanter même si ca double la taille de preos ce truc. Plus sérieusement, je ne l'ai pas fait parce que ca double pratiquement la partie résidente de preos (en plus de lui faire dépasser 8K ce qui est le maximum possible pour un kernel).

Hmmm, serait-il possible de déléguer une partie du travail de décompression et relogement à stdlib comme pour la décompression des packs archives?

Mais je ne comprends pas trop pourquoi ça pose tellement de problèmes de place dans PreOs alors que cette décompression est suffisamment compacte pour aller dans le code de démarrage de certains programmes _nostub (grands avec beaucoup de relogements) et économiser quand-même de la place. Et aussi dans la petite mémoire de la TI-92 I (Fargo).

Sinon, des relogements au format MLink peut-être? Le dernier ld-tigcc gère ça pour les programmes _nostub, ça compresse un peu moins bien, mais le code de décompression est nettement plus petit.

Et les plug-ins permettant de faire évoluer les fonctionnalits ?

Une architecture à plug-ins sur TI, ça ne fait que des fichiers de plus à envoyer, il vaut mieux tout linker dans l'exécutable, et comme ça on évite aussi les problèmes de protection.

Et sinon, il est possible de faire une application scriptable en TI-BASIC (en exportant des fonctions C/ASM aux scripts TI-BASIC), ce qui ne crée pas de problèmes de protection et ce qui permet de coder les scripts on-calc. Le désavantage, c'est qu'il faut là aussi des fichiers externes et que le TI-BASIC est lent.

> Les __need_in_use_bit ne sont plus que dans les headers, il y en a aussi dans tigcc.a maintenant (parce que tigcc.a a été recompilée avec les headers à jour).
Oui, je sais (même si je l'avais oublié).
Je ne pense pas qu'il y ait trop de __need_in_use_bit spurious induits dans tigcc.a. Ce ne sera pas forcément nécessaire de reconstruire tigcc.a (ce qui est l'affaire d'une dizaine de secondes au plus... ExtGraph est un projet nettement plus gros, et prend une quinzaine de secondes sur une machine moins puissante...).

"tictex" a NEED_IN_USE_BIT, et c'est nécessaire car c'est un programme qui en lance d'autres.
"tictexpl" ne l'a pas, sauf éventuel import (probablement) spurious.
Mais quand les headers non patchés de TIGCCLIB infligent le workaround du bug d'AMS à mon implémentation d'un delta² d'Aitken, petit programme d'un peu plus de 400 octets, augmentant sa taille d'un quart environ, sans que personne soit capable de donner une raison logique à ce que les fonctions du CAS nécessitent __need_in_use_bit (et sachant que les callgraphs ont été réalisés avec un outil dont on a perdu les sources, et dont j'ai trouvé et reporté au moins un bug faussant le callgraph, sur OSVRegister/FreeTimer...), je ne suis pas satisfait.

[EDIT: cross.
> > Et les plug-ins permettant de faire évoluer les fonctionnalits ?
> Une architecture à plug-ins sur TI, ça ne fait que des fichiers de plus à envoyer, il vaut mieux tout linker dans l'exécutable, et comme ça on évite aussi les problèmes de protection.
+1. On est en embarqué assez dur, ici, et c'est sympa de profiter du linking statique et des références d(pc) si la source et la cible ne sont pas trop loin)...
]

Kevin Kofler (./123) :
La Titanium était sortie aux USA en juillet et le semestre commence à la mi-août dans beaucoup d'états US.

Désolé. Je ne savais pas.

Kevin Kofler (./123) :
Peut-être, peut-être pas...

Mais si. Tiens : www.yaronet.com/t3

Kevin Kofler (./123) :
Hmmm, serait-il possible de déléguer une partie du travail de décompression et relogement à stdlib comme pour la décompression des packs archives?

Mais je ne comprends pas trop pourquoi ça pose tellement de problèmes de place dans PreOs alors que cette décompression est suffisamment compacte pour aller dans le code de démarrage de certains programmes _nostub (grands avec beaucoup de relogements) et économiser quand-même de la place. Et aussi dans la petite mémoire de la TI-92 I (Fargo).
Sinon, des relogements au format MLink peut-être? Le dernier ld-tigcc gère ça pour les programmes _nostub, ça compresse un peu moins bien, mais le code de décompression est nettement plus petit.

Le problème n'est pas la routine de relogement, mais ce qu'il y a autour en terme de vérification, de controle.

PpHd (./125) :

Kevin Kofler (./123) :
Peut-être, peut-être pas...

Mais si. Tiens : www.yaronet.com/t3

C'est un peu le mauvais moment de l'année pour un poisson d'Avril.

ExpOS, the kernel of the experts!

Sasume (./117) :
./114 Ben franchement, pas mal de programmes _nostub sont sous la forme de plusieurs fichiers (pour les niveaux, etc.) et nécessitent hwxpatch pour tourner alors ça revient quasiment au même niveau complexité...

Moi le problème qui m'a dégouté du kernel, c'était que presque systématiquement les lib n'étaient pas fournies avec le jeu, et qu'il fallait les télécharger autre part.
Quand tu connais rien aux calculettes, c'est vraiment galère.
Tu te retrouve à chercher sur internet des libraries pour calculettes... Quand en plus tu t'y connais pas trop en informatique, les prog "kernels" tu leur dis =>
Avec un prog nostub, tu balance avec ti-connect les fichier du zip que tu as téléchargé de ticalc.org, et pof ça marche (ou ça plante, mais ça c'est une autre histoire).

Seulement pour les libs dites "courantes" (qui pour la plupart sont obsolètes, dupliquent les fonctionnalités des ROM_CALLs et n'évoluent pratiquement pas).

Surtout pour conflib et Hib-View. Ça fait juste 36000000 fois que la question "où trouver conflib pour Hib-View" est tombée. Heureusement qu'il y a une version de Hib-View qui n'en a pas besoin (mon fork _nostub). (L'utilisation de cette librairie est d'ailleurs totalement inutile et sans intérêt, mon code est plus simple, plus compact et crée des fichiers de sauvegarde plus petits.)

Je parle de conflib là, pas de hiblib, qui effectivement ne sert à rien parce que c'est une lib utilisée par un seul programme , mais qui au moins est distribuée avec le logiciel.

PpHd (./125) :

Kevin Kofler (./123) :
Peut-être, peut-être pas...

Mais si. Tiens : www.yaronet.com/t3

Extait de expos.txt :

------------
X-Thanks to
------------

- Kevin Kofler <email enlevé>. Without him, there wouldn't be ExpOS!

J'avoue que ça faisait longtemps que les programmes sur TI ne m'avaient pas fait rigoler comme ça

LOL, un nouveau kernel
Pas sûr que ce soit une super idée pour ne pas confondre les utilisateurs qui n'y connaissent rien (c'est PreOS ou ExpOS qui est le mieux ?) ^^

C'est PxpOS pardi ! et ErpOS suxxxxx

Aaahhh ce bon vieux débat qui ressort Ca faisait au moins 2 jours