Kernel vs Nostub? - Page 5

d/ler le pack de TIGCC en même temps avec une petite connection par exemple (c'est mon cas). L'est gros le pack, m'offre pas ça souvent moi.

> L'est gros le pack, m'offre pas ça souvent moi.
C'est la même chose pour moi. J'en suis toujours à la 0.94 Beta 20, et la prochaine version que je downloaderai sera probablement une bêta de TIGCC 0.95.

>>Arrête de changer d'avis tous les 6 mois et d'insulter tout le monde qui ne partage pas ton avis de la saison. Il y a quelques mois, tu disais exactement le contraire. C'est quoi qui t'a fait changer d'avis?
>LOL. Tu connais pas encore Timad ?
Malheureusement si, on commence à le connaître sur certains points...

>>2 * la taille de genlib - la taille du kernel de différence.
>+ La taille de ttstart
Parfaitement d'accord; mais ttstart n'est pas très gros par rapport à GenLib ou à PreOS...

>>genlib n'est pas du tout optimisée en taille,
>Faux. Genlib est optimise en taille et en vitesse. Sinon je vois pas pkoi je ferais du self modifing code pour reduire la taille.
Tiens, toi aussi tu fais du self-modifying code ? Plusieurs routines d'ExtGraph vont aussi en avoir.

>>Une librairie statique gaspillera nettement moins de place.
>Avec un programme, avec une librarie, oui.
>Mais avec 2 programmes, la non.
>(Tu fais toujours la meme erreur, c'est lassant).
Avec deux programmes ou plus, pas trop. Mais peu de monde a deux programmes ou plus, tous programmés avec GenLib, en même temps, sur la même calculette (cf la liste que tu donnes ci-dessous: plusieurs de ces programmes sont excellents, sans équivalent; mais prennent une place monstre !)...

>>il y a une tentative de rajouter un support pour du double-buffering de manière sale, en permettant au programme de changer les adresses des plans, de la part de PpHd, mais seulement dans PreOs, et puis ce n'est pas du double-buffering automatique
>Faux. C'est dans Teos, DoorsOs et Unios aussi. C'est TRES standard.
C'est peut-être très standard dans les kernels, mais ça n'est pas forcément très propre (ça dépend ce qu'on considère propre, évidemment; mais je suis de l'avis de celui qui a écrit ça, c'est probablement Kevin)...


> [A propos de KerNO]
>+ Il fait un Heap Check pour verifier si la Heap est corrompu apres un plantage et t'avertir (Interet reel ?)
Intérêt réel: te dire si la table de handles a été piétinée par le plantage, donc si tu vas avoir des ennuis rapidement après le plantage... Un bon reset est de toute façon toujours recommandé après un plantage que l'anticrash a récupéré, après, si possible, avoir sauvegardé les données qu'on veut sauvegarder.
Peut-être que tu considères que la vérification de la Heap n'a pas d'intérêt; mais c'est plus facile à implémenter qu'une synchro pour les grayscales...

>Et je te rappelle que la plupart des programmes nostub sont :
+ compresse : donc il faut un lanceur, donc ce n'est plus autonome.
+ >24K : Donc il faut un lanceur sur AMS 2.0x.
Peu de personnes programment en _nostub avec des programmes > à 24 KO, étant donné que la compression existe, et que peu ne la connaissent pas...

> Ca tombe bien Preos recupere meme les bogues d'AMS.
Personnellement, je n'ai jamais vu AMS planter tout seul, si un programme en ASM (_nostub ou kernel) n'a pas fait n'importe quoi. Peut-être que toi, tu l'as vu; mais pas moi.

> Pour moi, c'est le format _nostub, le truc archaique. Y'a rien dans ce format.
Oui, ce format est assez faible (pour TI, les programmes ASM sont visiblement une erreur dans AMS...). Mais c'est le format natif d'AMS, i.e. LE STANDARD...

> Qui a rajoute les DLL parce qu'il bavait devant les brillantes libraries kernels ?
Qui n'a rien compris au but des DLL _nostub, dont le but n'est pas de faire des DLL pour rien (les 68kL pour stocker les données des jeux, ça c'est des DLL pour rien, et ça existe) à la façon kernel, mais de dépasser la limite des 64 KO ? On savait depuis longtemps que TiMad, Thibaut et d'autres, n'avaient rien compris. Mais je ne savais pas que toi non plus, tu n'avais visiblement pas bien compris...

>Et puis perso j'utilise aussi extgraph de temps en temps, donc je ne la critique pas.
On te remercie vraiment (ce n'est pas de l'ironie) de ne pas faire comme les deux autres #$&%...

>Tu fais un OSSetSR(0x500); avant puis un OSSetSR(0x0000);
Moi, je fais asm("move.w #0x0400,%%d0; trap #1" : : : "d0","d1"); qui est exactement pareil, qui détruit exactement les mêmes registres, mais qui prend moins de place et de temps. Faire cela n'est actuellement possible qu'avec TIGCC.

Pourquoi d1 ?

Kevin > Ce qui veut dire qu'à chaque fois qu'on rajoute quelque chose, tu devras également mettre à jour GraphX...

Pfff Je suis dans le cas de n'importe quel programmeur qui doit recompiler son programme s'il veut profiter d'une amélioration d'ExtGraph, TIGCClib, etc.


> regarde comment fait le swap-double-buffering de TIGCCLIB (du swap-triple-buffering n'est autre que du gaspillage de RAM, d'ailleurs)

A moins que je me trompe, votre système oblige à attendre une synchronisation == perte de temps. Le système exclusif de GX permet de demander un affichage et de poursuivre immédiatement le programme, GX se chargeant d'attendre la synchro en tâche de fond.
Bref, le TSB (appelons-le comme ça, c'est plus court) a un avantage. Mais je suis bien sûr d'accord qu'un inconvénient est la place demandée en RAM.


XDanger : Votre "self-modifying code", GraphX en comporte pour les fonctions de scrolling. Xlib aussi en a.

> Mais c'est le format natif d'AMS, i.e. LE STANDARD...
Figure-toi que je suis d'accord. A ce propos, je ne suis ni un extrémiste anti-kernel ni un extrémiste anti-nostub, contrairement à certains. C'est débile de faire la guerre au camp adverse pour si peu et parcequ'on a la prétention de soutenir le meilleur format...


> On te remercie vraiment (ce n'est pas de l'ironie) de ne pas faire comme les deux autres #$&%...

Réfléchit avant de causer espèce de #$&%. Quand ai-je insulté ta chérie d'EG ? quiconque ne la chérit pas (ou qui est objectif en disant dans un débat qu'elle a des défaut -lenteur...) est un #$&% ? en clair ceux qui ne pensent pas comme toi sont des abrutits ?
Je vais m'autocensurer parceque là ...

PpHd
a écrit : Je rappelle juste que je boycotte les programmes 'nostub' sur ma calc (sauf un).

Raison?

>Une librairie dynamique est une perte de place, pas un gain de place, par rapport à une librairie statique. Tiens en furetant sur le net j'ai trouve la secte des adeptes des libraries statiques dont voici le gourou : Richard A. Burgess

Je n'ai pas compris là...

>Ceux qui prétendent que c'est un gain oublient que la taille des librairies fait partie de la taille du programme, qu'elles soient statiques ou dynamiques. Et toi tu oublies toujours qu'on ne les compte qu'une et seule fois.

Mais pour faire cela, il faut avoir une estimation du nombre de programmes qui utilisent cette librairie et qui seront présents en même temps sur la calculatrice de l'utilisateur, pour savoir par combien diviser la taille à rajouter à la taille du programme. Et en l'absence d'une telle estimation, 1 (donc compter la taille de la librairie dynamique entièrement) est une approximation bien meilleure que l'infini (donc ne pas compter la taille de la librairie dynamique du tout).

>Arrête de changer d'avis tous les 6 mois et d'insulter tout le monde qui ne partage pas ton avis de la saison. Il y a quelques mois, tu disais exactement le contraire. C'est quoi qui t'a fait changer d'avis? LOL. Tu connais pas encore Timad ?

Ben justement, je sais bien que ce n'est pas la première fois qu'il change radicalement d'avis, d'où le "tous les 6 mois".

>Avec une librairie statique, seules les fonctions réellement utilisées se retrouveront sur la calculatrice.
Faux. Seuls les fichiers objets rellement utilises sont sur la calculatrice

Et si la librairie statique est codée correctement, chaque fonction sera dans son propre fichier objet. Donc ça revient au même.

Donc ca obblige au passage a faire des sauts longs entre les fichiers objets.

Sauf si la librairie statique fait moins de 32 KO de code et qu'on présuppose que les fichiers objet de la librairie statique seront adjacents (ou presque), ce qui sera souvent le cas en pratique. Ou alors si le programme entier fait moins de 32 KO. Mais il est vrai qu'une librairie statique codée proprement ne devrait pas dépendre de cela.

Une autre solution, plus propre, est de mettre les fonctions qui sont toujours utilisées ensemble dans le même fichier objet, ce qui permet les références PC-relatives communes. C'est la solution utilisée dans TIGCCLIB pour LoadDLL et UnloadDLL, par exemple.

Et en tout cas, l'overhead des relogements absolus dans les librairies statiques sera pratiquement toujours plus petit de l'overhead des librairies dynamiques (table d'importation, table d'exportation, relogeur (kernel par exemple), ...).

>2 * la taille de genlib - la taille du kernel de différence. + La taille de ttstart

Et la taille du décompresseur utilisé en mode kernel (shrnklib par exemple), tu ne la comptes pas?

>genlib n'est pas du tout optimisée en taille, Faux. Genlib est optimise en taille et en vitesse. Sinon je vois pas pkoi je ferais du self modifing code pour reduire la taille.

Certes, mais tu as bien optimisé la vitesse au détriment de la taille à pas mal d'endroits.

>PpHd dit que "de toute façon il n'y a qu'une copie, donc on se fiche de la mémoire gaspillée" Je n'ai jamais dit ca. Genlib fait partis des libs consommant le moins de memoire (contrairement a Xlib ou GraphX) contrairement aux idees recues. (Mais plus qu'extgraph, ca te va ?).

Mais ExtGraph est l'exemple à suivre.

>Une librairie statique gaspillera nettement moins de place.
Avec un programme, avec une librarie, oui. Mais avec 2 programmes, la non.

Non, tes routines de sprites 16×16 choisissent parmi 3 boucles différentes. ExtGraph utilise une seule. Donc il faut 3 programmes avec ExtGraph (pas 2) pour prendre la même place pour la routine de sprites que genlib.

>Il n'y a pas de double-buffering automatique HumHum. Il manque le timer... Et c'est tout pour que ca soit niquel.

Il est où graphlib::gray_dbuf_toggle_sync alors?
Ce sont les fonctions en GrayDBuf* que j'appelle "double-buffering automatique".

>il y a une tentative de rajouter un support pour du double-buffering de manière sale, en permettant au programme de changer les adresses des plans, de la part de PpHd, mais seulement dans PreOs, et puis ce n'est pas du double-buffering automatique Faux. C'est dans Teos, DoorsOs et Unios aussi. C'est TRES standard.

Désolé, j'aurais dû vérifier. Mais c'est un hack quand-même.

>pas de synchronisation Tu en veux ? En 1 minute je te l'ajoute.

Ben, il faudra m'expliquer alors pourquoi ce n'est pas déjà fait depuis longtemps...

>Plus de la moitié de ses fonctions ne sont que des wrappers autour de ROM_CALLs ou des réimplémentations de ROM_CALLs. Les fonctions bitmap/ligne sont au moins 8x plus rapide que les fonctions Bitmap/ligne d'AMS.

Tu m'expliqueras pourquoi tu as besoin d'une telle vitesse pour les lignes. Pour les sprites, je comprends encore (BitmapPut est quand-même excessivement lent, même si c'est tout à fait utilisable pour pas mal d'applications), mais pour les lignes, il ne faut pas exagérer. Et quant à l'utilité de graphlib::clr_scr et graphlib::clr_scr2 par exemple, je ne la vois pas du tout. ScreenClear et ScrRectFill(ScrRect,ScrRect,A_REVERSE) respectivement font ce travail très bien. On n'a pas besoin d'effacer l'écran des milliers de fois par seconde.

>c'est une implémentation médiocre des niveaux de gris En bon francais, on dit Implantation

En bon français, on écrit "français" avec une cédille.

PpHd a écrit :
>Mais bon, l'anticrash _nostub de PreOs marche très bien. (Normal, ce sont ExtendeD et moi qui avons codé la moitié. PpHd n'était pas très motivé là-dessus. Moi si. ) Hum... Tu es de mauvaise foi. Tu as fait la restauration des TSR apres le crash. Extended a fait la liberation des DupScreens. J'ai fait tout le reste ce qui n'est pas rien.

OK, OK, j'ai exagéré un peu. Je voulais juste dire que tu n'as pas codé ça tout seul.

>Enfin, j'avoue que je ne sais pas exactement ce qu'il fait, ni ce qu'il ne fait pas. Donc peut-être qu'il a des trucs que PreOS ne fait pas. Mais dans le cas contraire, je ne vois vraiment pas pourquoi ce programme existe (et ne réponds pas : "pour gagner 5 ko") + Il fait la remise a jour du timing de la RAM apres le trap #4 (Source de plantage a mon avis, car il ne teste pas l'etat des piles).

Et puis ce n'est pas quelque chose qu'un TSR devrait faire à mon avis. (C'est le boulot du programme utilisateur.)

+ Il fait un Heap Check pour verifier si la Heap est corrompu apres un plantage et t'avertir (Interet reel ?)

Ça par contre, c'est très utilie. Si le heap est corrompu, tu as intérêt à faire un vrai reset tout de suite, sinon tu risques de te retrouver avec un gros plantage et/ou avec des variables corrompues.

>Le résultat est simple : dans un cas le programme est autonome, dans l'autre il ne l'est pas. Je peux te pondre du kernel qui s'execute directement !

En installant automatiquement PreOs? Dans ce cas, c'est un hack, pas une solution propre. Pourquoi te faire tellement ch**r à essayer de rendre le mode kernel pseudo-autonome s'il suffit d'utiliser le mode natif (_nostub) pour obtenir l'autonomie.

Et je te rappelle que la plupart des programmes nostub sont : + compresse : donc il faut un lanceur, donc ce n'est plus autonome.

D'où les lanceurs personnalisés qui font que le programme n'apparaisse que comme un simple fichier de données et que le lanceur apparaisse comme un programme autonome. C'est très pratique et assez intuitif. Il y a beaucoup moins de personnes à avoir des difficultés à lancer des programmes _nostub compressés (en admettant que le lanceur soit à jour pour AMS 2.08) que des programmes kernel.

+ >24K : Donc il faut un lanceur sur AMS 2.0x.

D'où la compression avec lanceur personnalisé.

>La calculatrice peut planter à tout moment, même avec un anticrash! Il faut donc toujours archiver les fichiers qu'on veut garder!
Meme avec AMS seulement. Ca tombe bien Preos recupere meme les bogues d'AMS. Et parfois on modifie sans arret un fichier. donc on n'a pas interet a l'archiver tout le temps.

On archive une copie. Et pour qu'il y ait toujours une copie archivée à tout moment, on fait:
:Archive fichier
:Unarchiv copie
:DelVar copie
:CopyVar fichier,copie
:Archive copie
:Unarchiv fichier
quand on veut mettre à jour la copie.

>La seule fonctionnalité en moins, c'est le support pour un format de programmes dépassé (émulation Fargo, appelée aussi "mode kernel"). Desole de te contredire, mais "l'emulation fargo" comme tu l'appelles n'emule aucun programme ecrit pour Fargo.

Si, il peut émuler des programmes écrits pour Fargo et réassemblés ("recompilés"), dans beaucoup de cas sans modifications. Tu as tendance à ne pas faire la différence entre "compatibilité" et "compatibilité binaire". Il y a aussi la compatibilité source.
Et puis, PlusShell 1.00 alpha était livré avec un convertisseur capable de convertir les binaires Fargo en binaires kernel (mais compatibles AMS 1.00 seulement).

>>de plus su tu ajoute la compression, il faut ajouter le decompresseur...
>Pour les 2 versions (_nostub, kernel), donc ça s'annule quand on fait la différence.
Pas tout a fait.
Le decompresseur kernel peut etre lui meme compresse par une autre lib plus petite

Ce qui fait 2 librairies à la place d'une. Je ne pense vraiment pas que ce soit un gain.

>Des librairies comme XLib ou genlib ne sont pas suffisamment flexibles pour convenir pour tous les usages.
Je n'ai jamais dit que genlib servait a autre chose qu'a faire des jeux !
Liste des jeux/programmes sortis avec genlib :
+ SMA
+ CF
+ Total Destruction.
+ Pokered
+ Kirby
+ Mapmaker
+ sprmaker + Small

Total: 2 programmes d'auteurs tiers (Total Destruction, Small). Tous 2 jamais sortis de bêta (Small n'est même pas sorti en bêta publique!). Tout le reste est produit comme par hasard () par l'équipe Time To Team, et également sous état de bêta.

Et y'a encore plein de jeux qui ne sont pas encore sortis mais qui l'utilisent (megaman, seiken, Super Monster anhiliation, ...)

Je ne discute pas de vaporware, désolé. (Cf. aussi la réponse précédente.)

>Le meilleur jeu de tous les temps existe déjà et n'a pas besoin de kernel. Tout le monde n'a pas les memes gouts.

J'ai déjà répondu à cette objection (cf. #58).

>ce n'est pas dépassé, puisque c'est encore utilisé
>et c'est encore moins dépassé, vu que c'est encore en évolution Clap Clap.

J'ai déjà répondu à ça aussi (cf. #58 pour ça aussi).

>>ça risque pas dendommager la flash que d'archiver sans cesse ?
>Non. Je ne suis pas sur. Le segment de Garbage risque d'avoir une usure bien superieure aux autres segments...

Je ne pense pas. La réorganisation des archives n'est pas si fréquente que cela.

>>ce n'est pas dépassé, puisque c'est encore utilisé
>DOS est encore utilisé, donc DOS n'est pas dépassé???
>Ce n'est pas parce que quelque chose est encore utilisée que ce n'est pas dépassé. Si on recherche un systeme ne consommant pas de ressources pour rien, alors non, DOS n'est pas depasse.

Peut-être, mais si on recherche un systeme ne consommant pas de ressources pour rien, alors on n'utilise pas de kernel sur sa TI-89/92+/V200.

>>et c'est encore moins dépassé, vu que c'est encore en évolution
>DOS est encore en évolution, donc DOS n'est pas dépassé???
>Il y aura toujours des nostalgiques (comme PpHd, ou comme les développeurs de FreeDOS) qui
>feront évoluer les systèmes totalement dépassés.
Pour moi, c'est le format _nostub, le truc archaique. Y'a rien dans ce format. De la relocation ! C'est tout. La belle affaire.

Il y a dans ce format:
- que c'est le format natif de AMS.
- qu'on n'a pas besoin d'écrire ses propres routines pour le reloger, parce que EX_patch le fait.
- que c'est nettement plus facile à gérer pour le linkeur.
- qu'on n'a pas besoin de déreloger un programme avant de le reloger avec une nouvelle adresse.
...

Et la tigcc team doit rajouter des disaines de patche pour faire le loader 'nostub'....

Ça s'appelle du "startup code". Ce genre de code fait partie intégrante de tout programme sous pratiquement n'importe quel système d'exploitation, même Unix ou Windows. Le grand avantage du format _nostub est que le "startup code" est facultatif. On n'est pas obligés de mettre un code d'initialisation (contrairement au format kernel et à son stub obligatoire d'ailleurs). On peut dire à TIGCC d'en mettre pour implémenter des fonctionnalités. Il est normal que des fonctionnalités supplémentaires nécessitent du code supplémentaire. Mais on peut aussi écrire des programmes sans aucun startup code (sauf un bra _main, mais c'est dû à la manière dont les fonctions C sont organisées dans un exécutable, pas au format _nostub).

Qui essaye de faire evoluer son format vers le format kernel ?

On n'essaye pas du tout de faire évoluer le _nostub vers le format kernel. Au contraire, c'est toi qui copies en rajoutant à PreOs l'équivalent de tous nos patches (SET_FILE_IN_USE_BIT etc.). D'ailleurs, SET_FILE_IN_USE_BIT par exemple marche très bien avec un programme pour kernel (comme quoi le "startup code" de TIGCCLIB n'est pas une exclusivité du mode _nostub). Certes, ce n'est pas nécessaire avec PreOs 0.64 (parce que tu nous as copié), mais la version la plus récente de PreOs n'est pas le seul kernel, que tu le désires ou non.

PpHd
a écrit : Qui a rajoute les DLL parce qu'il bavait devant les brillantes libraries kernels ?

Pas parce qu'on "bavait devant les brillantes libraries kernels" (au contraire, on ne veut pas que les DLLs _nostub soient utilisées comme ça), mais pour permettre de faire des programmes >64 KO.

>Le système de kernels et de librairies dynamiques a été créé:
>- pour remplacer les ROM_CALLs, mal documentés à l'époque. Ce n'est plus le cas depuis
>janvier 2000 (sortie de la documentation de TIGCC).
>- pour faciliter le portage des vieux programmes Fargo.
C'est COMPLETEMENT FAUX ! Le kernel a ete cree : + Pour le support des libs dynamiques.

... qui lui a été créé parce que c'était ce que les programmeurs TI 68k avaient l'habitude d'utiliser à l'époque puisque Fargo marchait comme ça, et parce que les ROM_CALLs équivalents à des fonctions comme graphlib::clr_scr n'étaient pas documentés. Donc c'est bien pour les 2 raisons que j'ai citées.

+ Pour eviter d'avoir ce support dans chaque programme.

Traduction: pour éviter d'avoir l'émulation du fonctionnement de Fargo dans chaque programme. C'est une solution vraiment sale au problème qui était que les programmeurs de l'époque avaient l'habitude (et étaient en partie forcés par le manque de documentation des ROM_CALLs) de coder comme pour Fargo plutôt que nativement.

+ Pour mettre a jour facilement le kernel.

Traduction: pour mettre à jour facilement l'émulateur du format non-natif et inspiré de Fargo qu'est le format kernel.

Ta réponse ne contredit en rien ce que j'ai dit.

>Il n'y a vraiment pas de raison de le ressortir pour lui faire faire plein d'autres choses pour lesquelles il n'est pas prévu et pour lesquelles il y a des solutions meilleures (librairies statiques, fichiers de données externes etc.). Developpe plus.

Bon, je développe les 2 exemples que j'ai cités:
* Rajout de fonctionnalités aux librairies dynamiques, comme par exemple les numéros de version. Une solution bien meilleure au problème de compatibilité des versions est le linkage statique. Comme ça, le programme a toujours la version de la librairie pour laquelle il est prévu.
* Flag "read-only". C'est inutile, les fichiers de données de type personnalisé marchent très bien pour cela.

C'est clair là?

>Je ne vois pas la différence fondamentale entre les 2 classes de librairies que tu distingues. La seule différence est que ExtGraph est plus flexible et que ses fonctions sont suffisamment bien conçues pour ne pas être interdépendantes. On peut faire un jeu avec exactement la même facilité qu'on utilise une librairie de style ExtGraph ou une librairie de style genlib. Justement. C'est ca le probleme. Tu ne vois pas.

Tu retournes pas mal ce que je voulais dire, là.

>Une librairie conçue de la même manière que ExtGraph (statique, fonctions indépendantes entre elles), mais avec des routines clippées, serait suffisamment flexible pour convenir pour pratiquement tous les jeux que j'ai vus. Les routines de sprites clippées sont la seule chose qui manque à ExtGraph. Faux. Demande a squale. Faudrait supporter les ecrans virtuels de differentes tailles en plus.

Avec des fonctions clippées, on n'a pas besoin d'écrans virtuels plus grands que l'écran.

>Ce ne sont pas des programmes DOS, ce sont des programmes console Win32.
Les programmes console win32 sont plus chiants que les programmes dos. Au moins, les progs dos n'effacent pas automatiquement la fenetre texte apres leur fin.

Tu veux dire quoi là? Qu'ils ferment la fenêtre quand ils ont fini? Ben, ouvre une fenêtre console (ou "fenêtre DOS" si tu préfères, ce sont 2 termes pour la même chose, mais "fenêtre console" est plus exact) si c'est ça qui te gène.

PpHd a écrit :
>genlib essaye un peu de "faire le café" et ce n'est pas vraiment une bonne idée. Pour l'allocation de mémoire, les fonctions de la ROM marchent très bien si on les utilise correctement (c'est-à-dire si on n'alloue pas 10000 nœuds de listes chainées dans des blocs séparés). Ben oui. Mais dans le cas contraire, lorsqu'on A BESOIN de faire des allocations/desallocations de maniere tres intensives, genalib est LA solution a vos problemes. Je vous rappelle que Nitro/Dark Angel ont boostes les performances de leurs programmes de 50% juste en remplacant malloc par geanlib__alloc (attention il ne s'agissait pas dee programmes de bench mais de vrais programmes)... ce qui laisse imaginer le gain de vitesse reel entre les deux fonctions.

Ben, ils abusent de l'allocation de mémoire dans ce cas. Une solution bien meilleure au problème est d'optimiser l'allocation de mémoire. Donc:
- supprimer les listes chaînées! Les remplacer par des tableaus. Quand il n'y a plus de place, il suffit d'utiliser HeapRealloc ou realloc.
- mettre plusieurs variables dans le même bloc. (Les structures sont pratiques pour ça.)
etc.

>Et il y a plein de solutions pratiques pour gérer le clavier (_keytest de TIGCCLIB par exemple.
Le Joypad est bien plus pratique. Sur V200, le joypad de genlib a ete adapte suivant la config de touches pour ne pas utiliser F1...F8, mais des touches bien plus pratiques. Et cela, tout en restant compatible avec la premiere version de genlib qui date de plus de 3 ans.

Toi, tu considères cela comme pratique. Moi, je trouve ton système beaucoup trop inflexible pour être pratique. Le programmeur ne peut tester que les touches que tu choisis, toi. Alors que c'est à lui de choisir ses touches!

>Là, c'est un effet purement matériel, et je ne vois pas en quoi l'utilisation de genlib y changerait quelque chose. Peut etre un choix des touches judicieux qui empechent l'apparition de touches fantomes...

Et il y a quoi qui empêche au programmeur de faire le même choix lui-même?

>Et ben, tu le rediriges. Mais tu ne peux pas utiliser une lecture de clavier bas niveau quelle qu'elle soit avec l'AI5 de AMS qui tourne, sinon les bogues sont garantis (le curseur vers le haut est pris pour [ESC] et des trucs du genre). Si tu peux. Tu fais un OSSetSR(0x500); avant puis un OSSetSR(0x0000); apres.

Et cela ne risque-t'il pas de bloquer l'horloge?

>_keytest et les pseudo-constantes RR_... de compat.h sont faits pour ça. Bonjour la taille du code genere.

La taille n'est pas trop grosse depuis le rajout de la détection de modèle au début du programme. Ce sont juste des tst.w __calculator, voire des move.w __calculator,%d1;beq ... suivis de tst.w %d1 plus tard. Et si on est dans les premiers 32 KO de _main, ou alors si on utilise le switch spécial pour les programmes <32 KO (le switch -l de GNU as), GNU as en fera automatiquement une référence PC-relative (__calculator(%PC)).

>Mais XLib et genlib sont loin d'être des librairies de jeux complètes. Ce sont juste des librairies graphiques auxquelles on a rajouté quelques fonctions par ci, par là pour "faire le café", alors qu'il y a des solutions meilleures pour la même chose (test de touches par exemple - il y a plusieurs méthodes, toutes plus flexibles que le joypad de genlib).
Demande a PAD s'il ne pense pas que genlib est une librarie de jeux. Bon une librarie graphique orientee jeux, ca te va ?

Oui.

Et je prefere 100x le joypad de genlib a ton keytest.

Moi non. _keytest est plus flexible, et j'aime bien les solutions flexibles.

Pen^2 a écrit :
Tu ne trouves ça pas genant du tout d'habitude que les codeurs soient forcés de recompiler

Mais là, il ne s'agit pas juste de recompiler, mais aussi de mettre en commun les sources. (Ça s'appelle du "merging".) Et la mise en commun de sources incorporant des modifications différentes par rapport à une même source de départ n'est pas un problème simple. Ce n'est pas résoluble automatiquement dans le cas général. (Les programmes automatiques ne peuvent qu'aider, mais il y a souvent des "conflits" à résoudre, et parfois aussi des erreurs faites par les logiciels de "merging", genre un patch appliqué au mauvais endroit, ou alors un patch appliqué alors qu'il n'est plus nécessaire, chose qu'un programme de "merging" ne peut pas déterminer.)

Blue_Z a écrit :
Pro-kernel : oui, mais c'est la même chose avec les librairies statiques, si une fonction exportée change de nom, on doit mettre à jour tous les programmes qui l'utilisent.
Pro-nostub : non, car quand une fonction est définie comme exportée, elle ne change jamais de nom (c'est la règle)
Pro-kernel : avec les librairies kernel on n'a pas ce problème si on utilise les ordinaux

Et si l'ordinal change?
Là aussi, c'est tout simplement un truc qu'on "ne fait pas", comme pour le changement de nom dans les librairies statiques. Je ne vois pas la différence.

squale92 a écrit :
erf... quel courage pr lire tout ça...

Pour répondre, c'est pire. J'ai mis presque 2 heures pour répondre au message monstre de PpHd.

ExtendeD a écrit :
d/ler le pack de TIGCC en même temps avec une petite connection par exemple (c'est mon cas). L'est gros le pack,

C'est une demi-heure de téléchargement en modem 56k. Il y a bien pire.

XDanger a écrit :
>>2 * la taille de genlib - la taille du kernel de différence.
>+ La taille de ttstart Parfaitement d'accord;

Tu t'es fait avoir. Il n'a pas tenu compte du fait qu'il faut un décompresseur aussi en mode kernel.

mais ttstart n'est pas très gros par rapport à GenLib ou à PreOS...

En effet.

>>genlib n'est pas du tout optimisée en taille,
>Faux. Genlib est optimise en taille et en vitesse. Sinon je vois pas pkoi je ferais du self modifing code pour reduire la taille. Tiens, toi aussi tu fais du self-modifying code ?

Tu ne connais pas bien PpHd. Il est le spécialiste pour ça.

>>Une librairie statique gaspillera nettement moins de place.
>Avec un programme, avec une librarie, oui.
>Mais avec 2 programmes, la non.
>(Tu fais toujours la meme erreur, c'est lassant). Avec deux programmes ou plus, pas trop. Mais peu de monde a deux programmes ou plus, tous programmés avec GenLib, en même temps, sur la même calculette (cf la liste que tu donnes ci-dessous: plusieurs de ces programmes sont excellents, sans équivalent; mais prennent une place monstre !)...

Entièrement d'accord.

>>il y a une tentative de rajouter un support pour du double-buffering de manière sale, en permettant au programme de changer les adresses des plans, de la part de PpHd, mais seulement dans PreOs, et puis ce n'est pas du double-buffering automatique
>Faux. C'est dans Teos, DoorsOs et Unios aussi. C'est TRES standard. C'est peut-être très standard dans les kernels, mais ça n'est pas forcément très propre (ça dépend ce qu'on considère propre, évidemment; mais je suis de l'avis de celui qui a écrit ça, c'est probablement Kevin)...

Oui, c'est moi qui ai dit que c'est un hack.

> Ca tombe bien Preos recupere meme les bogues d'AMS. Personnellement, je n'ai jamais vu AMS planter tout seul, si un programme en ASM (_nostub ou kernel) n'a pas fait n'importe quoi. Peut-être que toi, tu l'as vu; mais pas moi.

Tu n'as jamais vu AMS 2.04. Avec la bonne séquence d'actions, on pouvait le faire précipiter dans une boucle infinie de "Protected Memory Violation" systématiquement. Mais c'est corrigé dans AMS 2.05.

> Pour moi, c'est le format _nostub, le truc archaique. Y'a rien dans ce format. Oui, ce format est assez faible (pour TI, les programmes ASM sont visiblement une erreur dans AMS...).

Ah, tu trouves? Moi, je l'aime bien ce format. J'aime les choses simples. Les autres formats d'exécutable que j'ai vus (DoorsOS, Windows, ELF etc.) sont lourds.

Mais c'est le format natif d'AMS, i.e. LE STANDARD...

En effet.

>Tu fais un OSSetSR(0x500); avant puis un OSSetSR(0x0000); Moi, je fais asm("move.w #0x0400,%%d0; trap #1" : : : "d0","d1"); qui est exactement pareil, qui détruit exactement les mêmes registres, mais qui prend moins de place et de temps. Faire cela n'est actuellement possible qu'avec TIGCC.

C'est de toute façon le seul compilateur C sérieux (je ne parle pas des alphas comme CC, ni des compilateurs prévus presque exclusivement pour les FlashApps comme TI-FlashStudio) disponible pour TI-89/92+/V200 actuellement.

ExtendeD a écrit :
Pourquoi d1 ?

Parce que le trap #1 le détruit, je suppose.

Thibaut a écrit :
Kevin > Ce qui veut dire qu'à chaque fois qu'on rajoute quelque chose, tu devras également mettre à jour GraphX...

Pfff Je suis dans le cas de n'importe quel programmeur qui doit recompiler son programme s'il veut profiter d'une amélioration d'ExtGraph, TIGCClib, etc.

Tu n'as pas compris la différence entre une simple recompilation et une mise en commun des sources (cf. ma réponse à Pen^2 un peu plus haut).

> regarde comment fait le swap-double-buffering de TIGCCLIB (du swap-triple-buffering n'est autre que du gaspillage de RAM, d'ailleurs)
A moins que je me trompe, votre système oblige à attendre une synchronisation == perte de temps.

On n'est pas à la microseconde près.

Tu as passé 2 heures à répondre à tous ces messages !

Kevin Kofler
a écrit : Tu m'expliqueras pourquoi tu as besoin d'une telle vitesse pour les lignes.

Pour faire une routine de remplissage de polygones, c'est vraiment très important, la vitesse des lignes.

zZ²

Pour remplir des polygones avec des ROM_CALLs, tu triangules et tu utilises FillTriangle, pas DrawLine.

Et puis il y a plus rapide pour le remplissage de polygones qu'une boucle de DrawLine.

Oui, mais pour programmer un FillTriangle, il faut bien faire d'abord une routine de tracé de lignes horizontales rapide. Et puis moi, dans mon cas, mes polygones ne sont pas des triangles, donc FillTriangle n'est pas ce qu'il y a de mieux.

jackiechan
a écrit : Oui, mais pour programmer un FillTriangle, il faut bien faire d'abord une routine de tracé de lignes horizontales rapide.

Mais un appel d'une fonction DrawLine n'est pas une bonne idée, quelle que soit l'implémentation de DrawLine. On recalcule des offsets pour rien. Il vaut mieux intégrer le traçage des lignes à la routine de remplissage de polygones.

Oui, je suis d'accord.

Donc la fonction de traçage de lignes de graphlib ne sert à rien dans ton cas.

J'imagine bien un moteur 3D utiisant les rom_calls pour le traçage et remplissage

>>Je rappelle juste que je boycotte les programmes 'nostub' sur ma calc (sauf un).
>Raison ?
Aucune si ce n'est mon plaisir personnel. Je detaille ?

>Je n'ai pas compris là...
Tu ne veux pas t'inscrire ? Son e-mail : richard@iarmusic.com

>Mais pour faire cela, il faut avoir une estimation du nombre de programmes qui utilisent
>cette librairie et qui seront présents en même temps sur la calculatrice de l'utilisateur,
>pour savoir par combien diviser la taille à rajouter à la taille du programme. Et en
>l'absence d'une telle estimation, 1 (donc compter la taille de la librairie dynamique
>entièrement) est une approximation bien meilleure que l'infini (donc ne pas compter la
>taille de la librairie dynamique du tout).
Entre 1 et l'infini, il y a de la marge, tu ne crois pas ? Et 2, 4 ou 5 ? Ou meme 10 ?

>Et si la librairie statique est codée correctement, chaque fonction sera dans son propre
>fichier objet. Donc ça revient au même.
Pas forcement. Elle peut etre tres bien codee mais n'avoir qu'un seul fichier objet.

>Sauf si la librairie statique fait moins de 32 KO de code et qu'on présuppose que les
>fichiers objet de la librairie statique seront adjacents (ou presque), ce qui sera souvent
>le cas en pratique. Ou alors si le programme entier fait moins de 32 KO. Mais il est vrai
>qu'une librairie statique codée proprement ne devrait pas dépendre de cela.
Tu reponds toi meme a la question. C'est tres sale de faire cela.

>Une autre solution, plus propre, est de mettre les fonctions qui sont toujours utilisées
>ensemble dans le même fichier objet, ce qui permet les références PC-relatives communes.
>C'est la solution utilisée dans TIGCCLIB pour LoadDLL et UnloadDLL, par exemple.
Mais pas pour votre surcouche flottante autour d'AMS.
Quand je pense qu'il y a 6 appels de routines successifs (3 par vous, 3 par AMS)...
qui ne font juste que changer
la position des parametres. C'est halucinant, meme si ces routines sont bien lentes.

>Et en tout cas, l'overhead des relogements absolus dans les librairies statiques sera
>pratiquement toujours plus petit de l'overhead des librairies dynamiques (table
>d'importation, table d'exportation, relogeur (kernel par exemple), ...).
"pratiquement" ? Detaille un peu plus, s'il te plait.
Je voudrais connaitre les fois ou ca pourrait etre plus grand, selon toi.

>Et la taille du décompresseur utilisé en mode kernel (shrnklib par exemple), tu ne la
>comptes pas?
skrnklib < ttstart.

>>Faux. Genlib est optimise en taille et en vitesse. Sinon je vois pas pkoi je ferais du
>>self modifing code pour reduire la taille.
>Certes, mais tu as bien optimisé la vitesse au détriment de la taille à pas mal d'endroits.
J'ai optimise en vitesse lorsque c'etait necessaire. En taille, ailleurs.
Il me semble que c'est le mieux non ?

>>>Une librairie statique gaspillera nettement moins de place.
>>Avec un programme, avec une librarie, oui.
>>Mais avec 2 programmes, la non.
>Non, tes routines de sprites 16×16 choisissent parmi 3 boucles différentes. ExtGraph
>utilise une seule. Donc il faut 3 programmes avec ExtGraph (pas 2) pour prendre la même
>place pour la routine de sprites que genlib.
Je ne comprends pas ta reflexion. Enfin si je la comprends, mais je ne comprends pas pourquoi tu me reponds cela.

>Il est où graphlib::gray_dbuf_toggle_sync alors?
>Ce sont les fonctions en GrayDBuf* que j'appelle "double-buffering automatique".
Ok, je les ajoute mon cher.

>Ben, il faudra m'expliquer alors pourquoi ce n'est pas déjà fait depuis longtemps...
J'ai autre chose a faire qu'a mettre a jour graphlib.

>Tu m'expliqueras pourquoi tu as besoin d'une telle vitesse pour les lignes. Pour les
>sprites, je comprends encore (BitmapPut est quand-même excessivement lent, même si c'est
>tout à fait utilisable pour pas mal d'applications), mais pour les lignes, il ne faut pas
>exagérer. Et quant à l'utilité de graphlib::clr_scr et graphlib::clr_scr2 par exemple, je
>ne la vois pas du tout. ScreenClear et ScrRectFill(ScrRect,ScrRect,A_REVERSE)
>respectivement font ce travail très bien. On n'a pas besoin d'effacer l'écran des milliers
>de fois par seconde.
Tu n'as jamais fait de programmation oriente temps reel a ce que je vois.
Une piste: meme si on n'a pas pas besoin d'effacer l'ecran des centaines de fois par seconde,
le gain obtenu permets de gagner des cycles la, pour afficher plus d'elements ailleurs.

>En bon français, on écrit "français" avec une cédille.
Je n'ecris qu'avec les caracteres "azerty" < a 128.

>Ça par contre, c'est très utilie. Si le heap est corrompu, tu as intérêt à faire un vrai
>reset tout de suite, sinon tu risques de te retrouver avec un gros plantage et/ou avec des
>variables corrompues.
Pourquoi ne resete-t-il pas tout de suite alors ?
Pourquoi afficher une fenetre suceptible de faire tout planter irremediablement ?

>En installant automatiquement PreOs?
Pas exactement.

>Pourquoi te faire tellement ch**r à essayer de rendre le mode kernel pseudo-autonome s'il
>suffit d'utiliser le mode natif (_nostub) pour obtenir l'autonomie.
Parce que le format nostub est trop limite. Le format kernel est bien plus evolue et flexible.

>D'où les lanceurs personnalisés qui font que le programme n'apparaisse que comme un simple
>fichier de données et que le lanceur apparaisse comme un programme autonome. C'est très
>pratique et assez intuitif.
1. Le programme ne devient plus "autonome". Il y a 2 fichiers.
2. Combien de personnes ont grace a cela, plusieurs lanceurs de fichiers type 'ttstart' ?
Des milliers ? Surement.

>Il y a beaucoup moins de personnes à avoir des difficultés à lancer des programmes _nostub
>compressés (en admettant que le lanceur soit à jour pour AMS 2.08) que des programmes
>kernel.
Je n'ai jamais pretendu que le kernel etait pour les noeudnoeuds.
Mais je suis sur qu'on peut trouver des personnes capables de vouloir lancer le PPG
directement.

>On archive une copie. Et pour qu'il y ait toujours une copie archivée à tout moment,
>:Archive fichier
>:Unarchiv copie
>elVar copie
>:CopyVar fichier,copie
>:Archive copie
>:Unarchiv fichier
>quand on veut mettre à jour la copie.
Tu utilises beaucoup ta FlashRom. Trop a mon gout. Mais c'est ton choix.

>Si, il peut émuler des programmes écrits pour Fargo et réassemblés ("recompilés"),
>dans beaucoup de cas sans modifications.
...
Pourquoi je m'embete a faire des versions Fargo de mes programmes si c'est compatible source ? A je suis nul parfois.
...

>Tu as tendance à ne pas faire la différence entre "compatibilité" et "compatibilité
>binaire". Il y a aussi la compatibilité source.
Tu as parle d'emulation. Pas de compatibilite source, je te rappelle.

>Et puis, PlusShell 1.00 alpha était livré avec un convertisseur capable de convertir les
>binaires Fargo en binaires kernel (mais compatibles AMS 1.00 seulement).
Il marchait tres mal. En fait je ne me souviens pas qu'il est marchait une seule fois lorsque je l'ai utilise.

>Ce qui fait 2 librairies à la place d'une. Je ne pense vraiment pas que ce soit un gain.
Tout depend de la compression des libraries successives.

>Total: 2 programmes d'auteurs tiers (Total Destruction, Small). Tous 2 jamais sortis de
>bêta (Small n'est même pas sorti en bêta publique!). Tout le reste est produit comme par
>hasard ( ) par l'équipe Time To Team, et également sous état de bêta.
Et ?
Au fait j'ai oublie Zenith Saga Mea culpa.

>Je ne discute pas de vaporware, désolé. (Cf. aussi la réponse précédente.)
J'ai eu des versions de ces programmes entre les mains, donc ce n'est pas du vaporware.

>Je ne pense pas. La réorganisation des archives n'est pas si fréquente que cela.
Cela depend. Moi je fonctionne avec 95-97% de mes archives pleines.
Dans ces cas la, l'archivage d'un simple fichier peut me faire faire plusieurs garbesh successifs.

>Peut-être, mais si on recherche un systeme ne consommant pas de ressources pour rien, alors
>on n'utilise pas de kernel sur sa TI-89/92+/V200.
Donc toi meme tu dis que DOS = nostub ?

>Il y a dans ce format:
>- que c'est le format natif de AMS.
Ok.
>- qu'on n'a pas besoin d'écrire ses propres routines pour le reloger, parce que EX_patch le
>fait.
Ok. Mais le format est lourd.
>- que c'est nettement plus facile à gérer pour le linkeur.
? Et alors ?
>- qu'on n'a pas besoin de déreloger un programme avant de le reloger avec une nouvelle
>adresse.
On a quand meme besoin de le delocker et de libere la copie archivee...
Et quand bien meme ce n'est ni lourd, ni penible.

>Ça s'appelle du "startup code". Ce genre de code fait partie intégrante de tout programme
>sous pratiquement n'importe quel système d'exploitation, même Unix ou Windows.
Je dirais plutot : de tout programme tournant en C ou avec un langage de meme niveau.
Mais c'est mon avis personnel.

>Le grand avantage du format _nostub est que le "startup code" est facultatif.
>On n'est pas obligés de mettre un code d'initialisation (contrairement au
>format kernel et à son stub obligatoire d'ailleurs). On peut dire à TIGCC
>d'en mettre pour implémenter des fonctionnalités. Il est normal que des
>fonctionnalités supplémentaires nécessitent du code supplémentaire.
>Mais on peut aussi écrire des programmes sans aucun startup code
Bravo ! (Est-ce ironique ? Je ne sais plus.)
Mais c'est surtout la facon donc c'est implante que je critique.
Et puis une fonctionnalite = un ajout.
A la base, il ne devrait y en avoir aucun.

>(sauf un bra _main, mais c'est dû à la manière dont les fonctions C sont
>organisées dans un exécutable, pas au format _nostub).
En kernel, ce bra _main est facultatif.

>On n'essaye pas du tout de faire évoluer le _nostub vers le format kernel.
>Au contraire, c'est toi qui copies en rajoutant à PreOs l'équivalent de
>tous nos patches (SET_FILE_IN_USE_BIT etc.). D'ailleurs, SET_FILE_IN_USE_BIT
>par exemple marche très bien avec un programme pour kernel (comme quoi le
>"startup code" de TIGCCLIB n'est pas une exclusivité du mode _nostub).
>Certes, ce n'est pas nécessaire avec PreOs 0.64 (parce que tu nous as copié),
>mais la version la plus récente de PreOs n'est pas le seul kernel, que tu le désires ou non.
Qu'est-ce que je rajoute tant ? Je m'apercois en lisant votre doc qu'AMS a un bug
(bug dont je m'etait rendu compte en lisant EV_eventLoop il y assez longtemps mais
qui etait tellement visible que je croyais avoir tord face au code de Zj).
Je le corriges donc ! En quoi vois-tu une copie quelconque ? Je n'est meme pas regarde
votre code. Cette correction s'applique ainsi a TOUS les programmes kernels... qui se trouve
automatiquement corriges pour l'occasion. Voila l'enorme avantage du format kernel compare
au format nostub. 'Doors Explorer' (victime de ce bug) s'en trouve donc corrige.
Existe-t-il un patch pour corriger les programmes nostub 'closed-source' ?
Et quels sont les autres patches que j'ai rajoute ? Qu'est ce qui se cache derriere 'etc' ?
Ensuite libre a l'utilisateur de choisir son kernel, ok. Mais libre au programmeur aussi de
choisir un kernel suceptible d'offrir les fonctionnalites dont il a besoin.
Pourquoi ne faites-vous pas aussi un 'MIN_KERNEL' et un 'NO_KERNEL_DETECT' pendant que vous y etes ?

>Pas parce qu'on "bavait devant les brillantes libraries kernels"
>(au contraire, on ne veut pas que les DLLs _nostub soient utilisées comme ça),
> mais pour permettre de faire des programmes >64 KO.
Il y avait des methodes plu elegantes quand meme. Plus difficiles aussi.
(En cachant totalement 'LoadDLL' du programmeur et le rajouter dans votre startup code
tout en ajoutant une table de relogement, bref comme un kernel).
Ca aurait fait exactement ce que vous vouliez, sans en avoir les desavantages.

>qui lui a été créé parce que c'était ce que les programmeurs TI 68k avaient
>l'habitude d'utiliser à l'époque puisque Fargo marchait comme ça,
>et parce que les ROM_CALLs équivalents à des fonctions comme graphlib::clr_scr
>n'étaient pas documentés. Donc c'est bien pour les 2 raisons que j'ai citées.
Et pourquoi Fargo a-t-il implante des libs dynamiques alors ?

>>+ Pour eviter d'avoir ce support dans chaque programme.
>Traduction: pour éviter d'avoir l'émulation du fonctionnement de Fargo dans chaque programme.
>>+ Pour mettre a jour facilement le kernel.
>Traduction: pour mettre à jour facilement l'émulateur du format non-natif et inspiré de Fargo qu'est le format kernel.
T'es lourd la. Tres lourd.
Ok je rajouterais peut etre si j'ai le temps un vrai support 'Emulation Fargo' dans preos.
Tu seras content la ?

>Ta réponse ne contredit en rien ce que j'ai dit.
Si tu veux.

>* Rajout de fonctionnalités aux librairies dynamiques, comme par exemple les numéros de version.
>Une solution bien meilleure au problème de compatibilité des versions est le linkage statique.
>Comme ça, le programme a toujours la version de la librairie pour laquelle il est prévu.
Et si on veut mettre a jour la lib, il faut recompiler le programme, ok je connais.
Mais si on veut mettre a jour les touches d'un jeu qui ne sont pas parfaitement choisis sur une
machine ? Il suffit de mettre a jour genlib, et tu utiliseras les touches optimales pour ta
machine. Avec une lib statique, il aurait fallu recompiler chaque programme.

>* Flag "read-only". C'est inutile, les fichiers de données de type personnalisé marchent très bien pour cela.
Tellement plus pratique et simple d'emploi.
Tellement transparent aussi.

>Avec des fonctions clippées, on n'a pas besoin d'écrans virtuels plus grands que l'écran.
Faux.

>Tu veux dire quoi là? Qu'ils ferment la fenêtre quand ils ont fini? Ben, ouvre une fenêtre console
>(ou "fenêtre DOS" si tu préfères, ce sont 2 termes pour la même chose, mais "fenêtre console"
> est plus exact) si c'est ça qui te gène.
Je prefere qu'ils ne se ferment pas c'est tout. Mais on digresse la.

>Ben, ils abusent de l'allocation de mémoire dans ce cas. Une solution bien meilleure au problème est d'optimiser
>l'allocation de mémoire. Donc:
>- supprimer les listes chaînées! Les remplacer par des tableaus. Quand il n'y a plus de place, il suffit d'utiliser
>HeapRealloc ou realloc.
Et pour supprimer dans un tableau tu fais comment ? Ca prend beaucoup de temps...

>- mettre plusieurs variables dans le même bloc. (Les structures sont pratiques pour ça.)
Et rajouter une gestion suppression/insertion par forcement evidente a faire.

Tu n'y connais pas grand chose en allocation memoire a ce que je vois

>Toi, tu considères cela comme pratique. Moi, je trouve ton système beaucoup trop inflexible
>pour être pratique. Le programmeur ne peut tester que les touches que tu choisis, toi.
>Alors que c'est à lui de choisir ses touches!
Mais s'il veut les choisir, il les choisit ! Je n'impose pas le joypad !
Je le recommande, c'est tout !
Par exemple, Total ne passe pas exclusivement par le joypad.

>Et il y a quoi qui empêche au programmeur de faire le même choix lui-même?
Le temps de reflexion peut etre.

>Et cela ne risque-t'il pas de bloquer l'horloge?
Non. La lecture des touches ne va pas bloquer l'int 3 pendant plus d'une seconde.
Ou alors c'est un plantage.

>La taille n'est pas trop grosse depuis le rajout de la détection de modèle au début du programme.
>Ce sont juste des tst.w __calculator, voire des move.w __calculator,%d1;beq ...
>suivis de tst.w %d1 plus tard. Et si on est dans les premiers 32 KO de _main, ou alors si on utilise
>le switch spécial pour les programmes <32 KO (le switch -l de GNU as),
>GNU as en fera automatiquement une référence PC-relative (__calculator(%PC)).
Faut que je dises a Sebastian de rajouter _IS89_xxxx_yyyy pour le format kernel.
Ca pourra vous etre utile aussi en plus (Ne critiques pas : ce n'est pas un ajout au format,
c'est une autre maniere bien plus pratique d'utiliser les EXTRA_RAM_CALLS).

>Moi non. _keytest est plus flexible, et j'aime bien les solutions flexibles.
Tu aimes faire le cafe toi meme. C'est ton choix.
Il y a aussi le keyboard encore plus flexible.

>Et si l'ordinal change?
>Là aussi, c'est tout simplement un truc qu'on "ne fait pas", comme pour le changement de nom dans les librairies statiques.
>Je ne vois pas la différence.
Sauf que les noms de fonctions sont beaucoup plus suceptibles de changer que les ordinaux.
Exemple: zlib2.
On peut changer les noms sans changer les ordinaux.

>C'est une demi-heure de téléchargement en modem 56k. Il y a bien pire.
Le faire tous les jours... Heu non.

>Ah, tu trouves? Moi, je l'aime bien ce format. J'aime les choses simples.
>Les autres formats d'exécutable que j'ai vus (DoorsOS, Windows, ELF etc.) sont lourds.
Donc tu ne dois pas t'aimer toi meme : je te trouve lourd parfois.

>Qui n'a rien compris au but des DLL _nostub, dont le but n'est pas de faire des
>DLL pour rien (les 68kL pour stocker les données des jeux, ça c'est des DLL pour rien,
>et ça existe) à la façon kernel, mais de dépasser la limite des 64 KO ?
1. Ca s'appelle pas DLL, mais LIB.
2. Pourquoi une DLL ne contiendrait-elle pas exclusivement des donnees ?
3. C'est tres mal implante.
4. Ca pousse a faire des DLL de fonctions offerte comme c'est.

> On savait depuis
> longtemps que TiMad, Thibaut et d'autres, n'avaient rien compris. Mais je ne savais pas
> que toi non plus, tu n'avais visiblement pas bien compris...
5. J'ai jamais utilise de DLL qui est un format encore plus batard que le _nostub que je critique
ouvertement et sans moderation.

PpHd a écrit :
>>Je rappelle juste que je boycotte les programmes 'nostub' sur ma calc (sauf un).
>Raison ? Aucune si ce n'est mon plaisir personnel. Je detaille ?

Ben, s'il n'y a pas de raison, c'est du fanatisme... Ce n'est pas bien.

>Mais pour faire cela, il faut avoir une estimation du nombre de programmes qui utilisent
>cette librairie et qui seront présents en même temps sur la calculatrice de l'utilisateur,
>pour savoir par combien diviser la taille à rajouter à la taille du programme. Et en
>l'absence d'une telle estimation, 1 (donc compter la taille de la librairie dynamique
>entièrement) est une approximation bien meilleure que l'infini (donc ne pas compter la
>taille de la librairie dynamique du tout). Entre 1 et l'infini, il y a de la marge, tu ne crois pas ? Et 2, 4 ou 5 ? Ou meme 10 ?

Franchement, vu la taille du jeu moyen qui utilise genlib, 1 est beaucoup plus proche de la réalité que 10 dans le cas de genlib (comme l'a déjà dit XDanger, d'ailleurs).

>Et si la librairie statique est codée correctement, chaque fonction sera dans son propre
>fichier objet. Donc ça revient au même. Pas forcement. Elle peut etre tres bien codee mais n'avoir qu'un seul fichier objet.

Non. C'est une erreur de conception que d'utiliser un seul fichier objet pour une librairie statique. Mais il est vrai j'aurais probablement dû être plus précis et mettre "conçue correctement" plutôt que "codée correctement".

>Une autre solution, plus propre, est de mettre les fonctions qui sont toujours utilisées
>ensemble dans le même fichier objet, ce qui permet les références PC-relatives communes.
>C'est la solution utilisée dans TIGCCLIB pour LoadDLL et UnloadDLL, par exemple.
Mais pas pour votre surcouche flottante autour d'AMS.
Quand je pense qu'il y a 6 appels de routines successifs (3 par vous, 3 par AMS)...
qui ne font juste que changer la position des parametres. C'est halucinant, meme si ces routines sont bien lentes.

Pour les appels explicits, il y a un seul wrapper dans TIGCCLIB (__BC).
Pour les appels implicits, il y a 3 appels, mais un est un "sibling call" (un bra, pas un bsr), donc ce n'est pas un vrai appel de fonction. Et les 2 appels à l'intérieur de TIGCCLIB sont PC-relatifs.
Et donc: oui, fadd(x,y) donnera du code légèrement plus efficace que x+y si x et y sont des nombres à virgule flottante.

>Et en tout cas, l'overhead des relogements absolus dans les librairies statiques sera
>pratiquement toujours plus petit de l'overhead des librairies dynamiques (table
>d'importation, table d'exportation, relogeur (kernel par exemple), ...).
"pratiquement" ? Detaille un peu plus, s'il te plait. Je voudrais connaitre les fois ou ca pourrait etre plus grand, selon toi.

Par exemple dans le cas où une cinquantaine de fonctions est implémentée en termes d'une même fonction de base. Mais ce ne sont que des cas exceptionnels.

>Et la taille du décompresseur utilisé en mode kernel (shrnklib par exemple), tu ne la
>comptes pas? skrnklib < ttstart.

Certes, mais sizeof(shrnklib)>0.

>>Faux. Genlib est optimise en taille et en vitesse. Sinon je vois pas pkoi je ferais du
>>self modifing code pour reduire la taille.
>Certes, mais tu as bien optimisé la vitesse au détriment de la taille à pas mal d'endroits.
J'ai optimise en vitesse lorsque c'etait necessaire. En taille, ailleurs. Il me semble que c'est le mieux non ?

Le mieux, c'est de toujours optimiser en taille. On n'est pas à 1 ms près.

>>>Une librairie statique gaspillera nettement moins de place.
>>Avec un programme, avec une librarie, oui.
>>Mais avec 2 programmes, la non.
>Non, tes routines de sprites 16×16 choisissent parmi 3 boucles différentes. ExtGraph
>utilise une seule. Donc il faut 3 programmes avec ExtGraph (pas 2) pour prendre la même
>place pour la routine de sprites que genlib. Je ne comprends pas ta reflexion. Enfin si je la comprends, mais je ne comprends pas pourquoi tu me reponds cela.

C'est un exemple pour montrer qu'une librairie statique bien optimisée en taille ne prend pas nécessairement plus de place qu'une librairie dynamique qui n'est pas optimisée en taille au maximum, même si on l'utilise en même temps dans 2 programmes différents, contrairement à ce que tu avais dit.

>Tu m'expliqueras pourquoi tu as besoin d'une telle vitesse pour les lignes. Pour les
>sprites, je comprends encore (BitmapPut est quand-même excessivement lent, même si c'est
>tout à fait utilisable pour pas mal d'applications), mais pour les lignes, il ne faut pas
>exagérer. Et quant à l'utilité de graphlib::clr_scr et graphlib::clr_scr2 par exemple, je
>ne la vois pas du tout. ScreenClear et ScrRectFill(ScrRect,ScrRect,A_REVERSE)
>respectivement font ce travail très bien. On n'a pas besoin d'effacer l'écran des milliers
>de fois par seconde.
Tu n'as jamais fait de programmation oriente temps reel a ce que je vois.
Une piste: meme si on n'a pas pas besoin d'effacer l'ecran des centaines de fois par seconde, le gain obtenu permets de gagner des cycles la, pour afficher plus d'elements ailleurs.

Vu qu'on n'a pas besoin d'effacer l'écran très souvent, le nombre de fps ne changera pratiquement pas en fonction de la vitesse de la routine d'effaçage de l'écran.

>Ça par contre, c'est très utilie. Si le heap est corrompu, tu as intérêt à faire un vrai
>reset tout de suite, sinon tu risques de te retrouver avec un gros plantage et/ou avec des
>variables corrompues.
Pourquoi ne resete-t-il pas tout de suite alors ? Pourquoi afficher une fenetre suceptible de faire tout planter irremediablement ?

Là, tu n'as pas tord. Mais au moins il fait l'effort de détecter la condition problématique.

>Pourquoi te faire tellement ch**r à essayer de rendre le mode kernel pseudo-autonome s'il
>suffit d'utiliser le mode natif (_nostub) pour obtenir l'autonomie. Parce que le format nostub est trop limite. Le format kernel est bien plus evolue et flexible.

Traduction: le format kernel est bien plus complexe et lourd.

Et puis il y a quoi qui est plus flexible? Tout ce qu'un programme kernel peut faire, un programme _nostub peut le faire également. La preuve: le kernel est un programme _nostub.

>D'où les lanceurs personnalisés qui font que le programme n'apparaisse que comme un simple
>fichier de données et que le lanceur apparaisse comme un programme autonome. C'est très
>pratique et assez intuitif. 1. Le programme ne devient plus "autonome". Il y a 2 fichiers.

Il est "autonome" dans le sens qu'il peut être lancé directement sans qu'il y ait besoin d'installer quoi que ce soit avant.

2. Combien de personnes ont grace a cela, plusieurs lanceurs de fichiers type 'ttstart' ? Des milliers ? Surement.

Et le problème est où? Ils ont le droit de trouver ça plus pratique. Si tu n'aimes pas, personne ne t'empêche de n'utiliser que ttstart ou TICTEX.

>Il y a beaucoup moins de personnes à avoir des difficultés à lancer des programmes _nostub
>compressés (en admettant que le lanceur soit à jour pour AMS 2.08) que des programmes
>kernel. Je n'ai jamais pretendu que le kernel etait pour les noeudnoeuds.

C'est une des choses que je critique le plus. Ça représente une attitude élitiste et un manque de respect pour l'utilisateur.

Mais je suis sur qu'on peut trouver des personnes capables de vouloir lancer le PPG directement.

Évidemment. Il y en a aussi qui ne savent pas lancer un programme BASIC. Mais c'est quand-même nettement plus rare que ceux qui ne savent pas lancer des programmes en mode kernel.

PpHd a écrit :
>On archive une copie. Et pour qu'il y ait toujours une copie archivée à tout moment,
>:Archive fichier
>:Unarchiv copie
>:DelVar copie
>:CopyVar fichier,copie
>:Archive copie
>:Unarchiv fichier
>quand on veut mettre à jour la copie. Tu utilises beaucoup ta FlashRom. Trop a mon gout. Mais c'est ton choix.

Ne t'inquiète pas, j'édite rarement des fichiers on-calc. (Je ne fais presque plus de BASIC.) Et je n'utilise cette précaution-là que si je n'ai pas une copie récente sur PC, ce qui est rarement le cas.

>Si, il peut émuler des programmes écrits pour Fargo et réassemblés ("recompilés"),
>dans beaucoup de cas sans modifications.
...
Pourquoi je m'embete a faire des versions Fargo de mes programmes si c'est compatible source ? A je suis nul parfois. ...

Bah, si tu appelles tios::EM_twinSymFromExtMem, c'est normal que ça ne compile pas pour Fargo.
Mais beaucoup de programmes Fargo peuvent être compilés pour DoorsOS et compatibles avec pas ou très très peu de changements.

>Tu as tendance à ne pas faire la différence entre "compatibilité" et "compatibilité
>binaire". Il y a aussi la compatibilité source. Tu as parle d'emulation. Pas de compatibilite source, je te rappelle.

C'est de l'émulation parce que les fonctionnalités compatibles sont implémentées en grande partie en temps d'exécution.

Et même si le mode kernel n'est pas tout à fait de l'émulation Fargo (parce que, comme tu l'as fait remarquer, ce n'est pas compatible de manière binaire), c'est de l'émulation d'une plateforme imaginaire qui lui ressemble beaucoup. C'est pour ça que je parle d'émulation Fargo. Et je dis que c'est de l'émulation d'une plateforme parce que le kernel utilise son propre format d'exécutables, pas celui du système d'exploitation, et que c'est une plateforme imaginaire parce qu'il n'existe pour l'instant (en attendant la sortie officielle de Pedrom) aucun système d'exploitation qui utilise ce format d'exécutables nativement.

>Et puis, PlusShell 1.00 alpha était livré avec un convertisseur capable de convertir les
>binaires Fargo en binaires kernel (mais compatibles AMS 1.00 seulement). Il marchait tres mal. En fait je ne me souviens pas qu'il est marchait une seule fois lorsque je l'ai utilise.

N'empêche que ça montre que PlusShell avait été écrit avec comme but la compatibilité avec Fargo.

>Ce qui fait 2 librairies à la place d'une. Je ne pense vraiment pas que ce soit un gain. Tout depend de la compression des libraries successives.

Pas du tout. Ça dépend de si:
sizeof(librairie plus petite) + sizeof(librairie plus grande compressée par la librairie plus petite) < sizeof(librairie plus grande non compressée)
ou pas. Je ne pense pas que ça ait de bonnes chances d'être le cas.

>Total: 2 programmes d'auteurs tiers (Total Destruction, Small). Tous 2 jamais sortis de
>bêta (Small n'est même pas sorti en bêta publique!). Tout le reste est produit comme par
>hasard ( ) par l'équipe Time To Team, et également sous état de bêta.
Et ?
Au fait j'ai oublie Zenith Saga Mea culpa.

Lui aussi jamais sorti de l'état de "Demo Release". genlib m'a l'air de ne pas être une librairie pour jeux, mais une librairie pour bêtas éternelles.

>Je ne discute pas de vaporware, désolé. (Cf. aussi la réponse précédente.) J'ai eu des versions de ces programmes entre les mains, donc ce n'est pas du vaporware.

C'est du vaporware parce que ce n'est pas sorti officiellement.

>Je ne pense pas. La réorganisation des archives n'est pas si fréquente que cela.
Cela depend. Moi je fonctionne avec 95-97% de mes archives pleines. Dans ces cas la, l'archivage d'un simple fichier peut me faire faire plusieurs garbesh successifs.

Moi aussi. J'ai 94,7% d'archives pleines sur ma TI-92+ là. J'en étais déjà à 99,9% à un moment. Voilà aussi pourquoi j'édite rarement des fichiers on-calc en ces derniers temps. Mais ce n'est pas le cas moyen.

>Peut-être, mais si on recherche un systeme ne consommant pas de ressources pour rien, alors
>on n'utilise pas de kernel sur sa TI-89/92+/V200. Donc toi meme tu dis que DOS = nostub ?

"ne consommant pas de ressources pour rien" ne veut pas forcément dire "dépassé" ni "qui manque de fonctionnalités". Le DOS est dépassé et manque de fonctionnalités par rapport à Windows ou Linux. Le _nostub n'est pas du tout dépassé et ne manque pas du tout de fonctionnalités par rapport aux alternatives (DoorsOS, FlashApps).

et c nettement plus rare les personnes qui programme en ASM qu'en C, ou en C et en basic, ça veut pas dire que le basic est mieux que le C ou que le C est mieux que l'ASM.

PpHd a écrit :
>Il y a dans ce format:
>- que c'est le format natif de AMS.
Ok.
>- qu'on n'a pas besoin d'écrire ses propres routines pour le reloger, parce que EX_patch le
>fait. Ok. Mais le format est lourd.

Il est lourd en quoi??? Il est très léger! C'est le format kernel qui est lourd!

>- que c'est nettement plus facile à gérer pour le linkeur. ? Et alors ?

Ben, Sebastian et moi, on travaille sur un linkeur, donc ça nous concerne quand-même un peu.
Personnellement, j'avais très envie de supprimer le support pour le format kernel avec TIGCC 0.95. Mais pour te calmer: Sebastian l'a déjà implémenté maintenant.

>- qu'on n'a pas besoin de déreloger un programme avant de le reloger avec une nouvelle
>adresse. On a quand meme besoin de le delocker et de libere la copie archivee...

Certes.

Et quand bien meme ce n'est ni lourd, ni penible.

Si, le dérelogement peut toujours être une source d'ennuis supplémentaire. Je retiens qu'il vaut mieux avoir une source d'ennuis possible de moins qu'une de plus.

>Ça s'appelle du "startup code". Ce genre de code fait partie intégrante de tout programme
>sous pratiquement n'importe quel système d'exploitation, même Unix ou Windows.
Je dirais plutot : de tout programme tournant en C ou avec un langage de meme niveau. Mais c'est mon avis personnel.

Tu n'as peut-être pas tord, mais le "startup code" de TIGCC n'est lui aussi utilisé que pour les programmes en C.

>Le grand avantage du format _nostub est que le "startup code" est facultatif.
>On n'est pas obligés de mettre un code d'initialisation (contrairement au
>format kernel et à son stub obligatoire d'ailleurs). On peut dire à TIGCC
>d'en mettre pour implémenter des fonctionnalités. Il est normal que des
>fonctionnalités supplémentaires nécessitent du code supplémentaire.
>Mais on peut aussi écrire des programmes sans aucun startup code
Bravo ! (Est-ce ironique ? Je ne sais plus.) Mais c'est surtout la facon donc c'est implante que je critique.

Je te signale que c'est déjà nettement mieux que ce qui est fait d'habitude dans les compilateurs C sur PC: ils incluent toujours tout le "startup code", même celui qui ne sert à rien, et il y a rarement un moyen de le désactiver. Nous, on vous laisse le choix de désactiver notre "startup code".

Et puis une fonctionnalite = un ajout. A la base, il ne devrait y en avoir aucun.

La logique est que, si c'est un ajout indispensable pour éviter un plantage dans certains cas, il est mis par défaut. J'aurais d'ailleurs mis SET_FILE_IN_USE_BIT, et peut être aussi EXECUTE_IN_GHOST_SPACE, par défaut également puisqu'ils remplissent aussi ce critère. Mais Sebastian était contre pour la raison que ces 2 directives prennent beaucoup de place et ne sont nécessaires que rarement. Quant au support pour exit et fonctions liées, il est mis par défaut parce qu'il ne prend presque pas de place et qu'il est nécessaire pour faire fonctionner certaines fonctions de la librairie C standard.

Et puis, on ne va pas changer les directives mises par défaut pour des raisons de compatibilité. Donc arrêtez de nous le demander, ça ne sert à rien.

>(sauf un bra _main, mais c'est dû à la manière dont les fonctions C sont
>organisées dans un exécutable, pas au format _nostub). En kernel, ce bra _main est facultatif.

Mais le stub obligatoire prend déjà plus de place, même sans parler du header.

>On n'essaye pas du tout de faire évoluer le _nostub vers le format kernel.
>Au contraire, c'est toi qui copies en rajoutant à PreOs l'équivalent de
>tous nos patches (SET_FILE_IN_USE_BIT etc.). D'ailleurs, SET_FILE_IN_USE_BIT
>par exemple marche très bien avec un programme pour kernel (comme quoi le
>"startup code" de TIGCCLIB n'est pas une exclusivité du mode _nostub).
>Certes, ce n'est pas nécessaire avec PreOs 0.64 (parce que tu nous as copié),
>mais la version la plus récente de PreOs n'est pas le seul kernel, que tu le désires ou non.
Qu'est-ce que je rajoute tant ? Je m'apercois en lisant votre doc qu'AMS a un bug
(bug dont je m'etait rendu compte en lisant EV_eventLoop il y assez longtemps mais
qui etait tellement visible que je croyais avoir tord face au code de Zj).
Je le corriges donc ! En quoi vois-tu une copie quelconque ? Je n'est meme pas regarde votre code.

Il n'était pas nécessaire de corriger ça dans le kernel parce que c'est déjà corrigé dans TIGCC.

Cette correction s'applique ainsi a TOUS les programmes kernels... qui se trouve
automatiquement corriges pour l'occasion. Voila l'enorme avantage du format kernel compare au format nostub. 'Doors Explorer' (victime de ce bug) s'en trouve donc corrige.

Je considère le fait que le Doors Explorer ne marque pas sa variable comme en utilisation (cachée) lui-même comme un bogue grave, vu que ça permet les appels récursifs, qui peuvent facilement être source d'ennuis. TICTEX a toujours marqué ses variables comme étant en utilisation. Bref, les explorateurs codés correctement n'ont jamais été victimes du problème en question.

Existe-t-il un patch pour corriger les programmes nostub 'closed-source' ?

Il suffit de rajouter le "startup code" en question au début, et de rajouter l'offset dans les entrées de la table des relogements. Un patch pour cela est tout à fait faisable. Si suffisamment de personnes y voient un intérêt réel, je peux faire un "startup code adder" automatique, capable de rajouter automatiquement des patches comme SET_FILE_IN_USE_BIT, EXECUTE_IN_GHOST_SPACE, ENABLE_ERROR_RETURN, vérification de la version de AMS et du modèle et même SAVE_SCREEN.

Et quels sont les autres patches que j'ai rajoute ? Qu'est ce qui se cache derriere 'etc' ?

En fait, il n'y en a pas tellement. Certaines étaient déjà là avant (SAVE_SCREEN, EXECUTE_GHOST_SPACE qui est géré par h220xTSR). Un qui me vient à l'esprit: Vérification du modèle. Il y a d'autres kernels qui ne font pas ça. TeOS par exemple. Mais bon, il est vrai que tu n'as pas vraiment copié ça sur nous. Et aussi l'émulateur Line1111.

Ensuite libre a l'utilisateur de choisir son kernel, ok. Mais libre au programmeur aussi de choisir un kernel suceptible d'offrir les fonctionnalites dont il a besoin.

C'est encore cette attitude-là. Nous sommes pour la compatibilité, nous. Je trouve que c'est du manque de respect pour l'utilisateur de demander un kernel très spécifique. Il n'y a pas de fonctionnalités vraiment indispensables parmi celles que tu as rajoutées. (Je t'ai déjà dit ça plusieurs fois.)

Pourquoi ne faites-vous pas aussi un 'MIN_KERNEL' et un 'NO_KERNEL_DETECT' pendant que vous y etes ?

Pour l'instant, nous maintenons la compatibilité avec tous les kernels, et nous ne rajoutons rien qui est incompatible avec les anciens kernels.

MacIntoc
a écrit : et c nettement plus rare les personnes qui programme en ASM qu'en C, ou en C et en basic, ça veut pas dire que le basic est mieux que le C ou que le C est mieux que l'ASM.

Là, il ne s'agit pas de facilité de programmation, mais de facilité d'utilisation!

mdr ce topic
ça se balance des posts qui font des pages entières

bravo TiMad t'as réussis

PpHd a écrit :
>Pas parce qu'on "bavait devant les brillantes libraries kernels"
>(au contraire, on ne veut pas que les DLLs _nostub soient utilisées comme ça),
> mais pour permettre de faire des programmes >64 KO.
Il y avait des methodes plu elegantes quand meme. Plus difficiles aussi.
(En cachant totalement 'LoadDLL' du programmeur et le rajouter dans votre startup code tout en ajoutant une table de relogement, bref comme un kernel).

Encore des trucs du côté du linker. Personnellement, je déteste ça. Et à l'époque, on n'avait pas de système de linking auquel on peut rajouter des trucs du genre facilement. Maintenant, avec le nouveau linker de Sebastian, c'est peut-être faisable. Tu peux le lui suggérer si tu veux.

Ca aurait fait exactement ce que vous vouliez

Mais ça aurait été très difficile à implémenter, surtout avec l'infrastructure de l'époque.

sans en avoir les desavantages.

Tiens, tu viens de dire que les librairies dynamiques pour le partage du code sont un désavantage là. C'est la première fois que je t'entends dire cela.

>qui lui a été créé parce que c'était ce que les programmeurs TI 68k avaient
>l'habitude d'utiliser à l'époque puisque Fargo marchait comme ça,
>et parce que les ROM_CALLs équivalents à des fonctions comme graphlib::clr_scr
>n'étaient pas documentés. Donc c'est bien pour les 2 raisons que j'ai citées. Et pourquoi Fargo a-t-il implante des libs dynamiques alors ?

Parce qu'il n'y avait:
- pratiquement pas de ROM_CALLs
- pas de linker supportant les librairies statiques
Les librairies dynamiques étaient donc la seule solution pour rajouter des fonctions indispensables. Maintenant:
- les ROM_CALLs sont exportés et documentés.
- on a un linker supportant les librairies statiques.
Donc les librairies dynamiques ne sont plus nécessaires.

>>+ Pour eviter d'avoir ce support dans chaque programme.
>Traduction: pour éviter d'avoir l'émulation du fonctionnement de Fargo dans chaque programme.
>>+ Pour mettre a jour facilement le kernel.
>Traduction: pour mettre à jour facilement l'émulateur du format non-natif et inspiré de Fargo qu'est le format kernel.
T'es lourd la. Tres lourd.
Ok je rajouterais peut etre si j'ai le temps un vrai support 'Emulation Fargo' dans preos. Tu seras content la ?

J'ai déjà expliqué plusieurs fois ce que je voulais dire. Et ici, j'ai bien dit "émulation du fonctionnement de Fargo", pas "émulation de Fargo". Je pense que ce que je voulais dire est clair ici.

Et bonne chance pour l'émulation binaire de Fargo. Tu en auras besoin.

>* Rajout de fonctionnalités aux librairies dynamiques, comme par exemple les numéros de version.
>Une solution bien meilleure au problème de compatibilité des versions est le linkage statique.
>Comme ça, le programme a toujours la version de la librairie pour laquelle il est prévu.
Et si on veut mettre a jour la lib, il faut recompiler le programme, ok je connais.
Mais si on veut mettre a jour les touches d'un jeu qui ne sont pas parfaitement choisis sur une
machine ? Il suffit de mettre a jour genlib, et tu utiliseras les touches optimales pour ta machine. Avec une lib statique, il aurait fallu recompiler chaque programme.

Ah, parce que ça arrive si souvent que ça que TI sort une nouvelle variante de la machine avec les touches à un endroit différent.
Il n'y a eu que 2 telles mises à jour depuis la sortie de la TI-92+:
- TI-89 (1998). Et il n'aurait pas suffi de changer les touches dans ta libraire pour que les programmes soient compatibles, vu qu'il y a aussi l'écran qui est plus petit.
- Voyage 200 (2002, 4 ans plus tard).
Statistiquement, la prochaine mise à jour avec un changement important des touches n'est à attendre qu'en 2006.

>* Flag "read-only". C'est inutile, les fichiers de données de type personnalisé marchent très bien pour cela. Tellement plus pratique et simple d'emploi.

Mais alors là pas du tout. Avec un fichier de données de type personnalisé, tu obtiens rapidement un pointeur sur les données (avec les ROM_CALLs de vat.h - ça prend 4 lignes de C avec les vérifications de non-nullité), et tu peux faire tout le reste avec des x(an). Si tu n'arrives pas à te rappeller des offsets, utilise des equates. Tu as aussi besoin d'equates pour les "libs read-only" de toute façon.

Tellement transparent aussi.

Tu appelles ça "transparent" d'avoir des fichiers de données avec une extension "ASM"? Pas moi. L'extension "ASM" est faite pour les programmes lançables directement. Les DLLs kernel sont déjà un abus du format, et si on commence par les utiliser pour des fichiers de données, c'est encore pire.

>Avec des fonctions clippées, on n'a pas besoin d'écrans virtuels plus grands que l'écran. Faux.

Pourrais-tu développer? Parce que là, je ne vois pas du tout pourquoi on en aurait besoin.

PpHd a écrit :
>Tu veux dire quoi là? Qu'ils ferment la fenêtre quand ils ont fini? Ben, ouvre une fenêtre console
>(ou "fenêtre DOS" si tu préfères, ce sont 2 termes pour la même chose, mais "fenêtre console"
> est plus exact) si c'est ça qui te gène. Je prefere qu'ils ne se ferment pas c'est tout. Mais on digresse la.

echo progw32.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 >progw32.bat

>Ben, ils abusent de l'allocation de mémoire dans ce cas. Une solution bien meilleure au problème est d'optimiser
>l'allocation de mémoire. Donc:
>- supprimer les listes chaînées! Les remplacer par des tableaus. Quand il n'y a plus de place, il suffit d'utiliser
>HeapRealloc ou realloc. Et pour supprimer dans un tableau tu fais comment ? Ca prend beaucoup de temps...

Soit tu utilises memmove, soit tu écris une valeur réservée par dessus. Soit encore tu fais 2 tableaux: un tableau de données et un tableau de pointeurs, et tu laisses les données dans le tableau de données, et tu fais un memmove (ou un remplacement par NULL) dans le tableau des pointeurs.

>- mettre plusieurs variables dans le même bloc. (Les structures sont pratiques pour ça.) Et rajouter une gestion suppression/insertion par forcement evidente a faire.

Je ne vois pas le rapport avec la phrase que tu as citée. Je parlais de structures dans la phrase citée, pas de tableaux. Mais j'ai déjà répondu ci-dessus.

Tu n'y connais pas grand chose en allocation memoire a ce que je vois

Je connais suffisamment le système de handles des TI-89/92+/V200 pour savoir que les longues listes chaînées sont totalement inadaptées à cette plateforme.

>Et il y a quoi qui empêche au programmeur de faire le même choix lui-même? Le temps de reflexion peut etre.

Ben, moi je présuppose que le programmeur est une personne intelligente, renseignée et diligente. Toi, tu as l'air de présupposer cela même de l'utilisateur, donc le fait que tu ne présupposes pas cela du programmeur m'étonne un peu.

>Et cela ne risque-t'il pas de bloquer l'horloge?
Non. La lecture des touches ne va pas bloquer l'int 3 pendant plus d'une seconde. Ou alors c'est un plantage.

OK.

>La taille n'est pas trop grosse depuis le rajout de la détection de modèle au début du programme.
>Ce sont juste des tst.w __calculator, voire des move.w __calculator,%d1;beq ...
>suivis de tst.w %d1 plus tard. Et si on est dans les premiers 32 KO de _main, ou alors si on utilise
>le switch spécial pour les programmes <32 KO (le switch -l de GNU as),
>GNU as en fera automatiquement une référence PC-relative (__calculator(%PC)).
Faut que je dises a Sebastian de rajouter _IS89_xxxx_yyyy pour le format kernel.
Ca pourra vous etre utile aussi en plus (Ne critiques pas : ce n'est pas un ajout au format, c'est une autre maniere bien plus pratique d'utiliser les EXTRA_RAM_CALLS).

C'est pire qu'un ajout au format, c'est un ajout du côté du linkeur.
Tu peux en parler à Sebastian. Le problème est que ça ne marche qu'avec les constantes. Mais pour la plupart de compat.h, ça devrait en effet marcher.

D'ailleurs, actuellement, en mode kernel, on ne teste pas __calculator, mais le RAM_CALL correspondant.

>Moi non. _keytest est plus flexible, et j'aime bien les solutions flexibles.
Tu aimes faire le cafe toi meme. C'est ton choix. Il y a aussi le keyboard encore plus flexible.

Évidemment, on peut aussi utiliser _rowread directement, mais c'est compliqué, alors que _keytest est très simple.

>Et si l'ordinal change?
>Là aussi, c'est tout simplement un truc qu'on "ne fait pas", comme pour le changement de nom dans les librairies statiques.
>Je ne vois pas la différence.
Sauf que les noms de fonctions sont beaucoup plus suceptibles de changer que les ordinaux.
Exemple: zlib2. On peut changer les noms sans changer les ordinaux.

Ben, il y a quand-même une solution simple: on ne change pas les noms, ou alors on supporte les 2 (un #define en C ou un equate en assembleur suffisent pour cela).

>C'est une demi-heure de téléchargement en modem 56k. Il y a bien pire. Le faire tous les jours... Heu non.

Pas tous les jours. Il n'y a pas une mise à jour par jour.

>Ah, tu trouves? Moi, je l'aime bien ce format. J'aime les choses simples.
>Les autres formats d'exécutable que j'ai vus (DoorsOS, Windows, ELF etc.) sont lourds. Donc tu ne dois pas t'aimer toi meme : je te trouve lourd parfois.

>Qui n'a rien compris au but des DLL _nostub, dont le but n'est pas de faire des
>DLL pour rien (les 68kL pour stocker les données des jeux, ça c'est des DLL pour rien,
>et ça existe) à la façon kernel, mais de dépasser la limite des 64 KO ? 1. Ca s'appelle pas DLL, mais LIB.

DLL = librairie dynamique. C'est la même chose. Même si on sous-entend souvent "DLL" = DLL _nostub et "librairie dynamique" = DLL kernel, ce n'est pas strictement compris dans le sens des mots.

2. Pourquoi une DLL ne contiendrait-elle pas exclusivement des donnees ?

Parce que c'est un abus du format. Et parce qu'une DLL _nostub est toujours copiée en RAM (il n'y a pas de flag "read-only"), et qu'il serait donc vraiment stupide de faire cela.

3. C'est tres mal implante.

Ben, alors, comment l'implanterais-tu (sans changer le linker radicalement - ce n'était pas possible de manière pratique quand le format DLL _nostub a été introduit)?

4. Ca pousse a faire des DLL de fonctions offerte comme c'est.

Si on ne lit pas la documentation ou si on s'appelle TiMad et veut faire exprès d'embêter le monde, alors oui. Mais sinon, non. La documentation dit clairement qu'il ne faut pas faire ça.

Mais je me dis quand-même qu'on aurait vraiment dû mettre la restriction que le programme et la DLL doivent tous les 2 être >32 KO. Sebastian et Zeljko étaient contre, malheureusement.

> On savait depuis
> longtemps que TiMad, Thibaut et d'autres, n'avaient rien compris. Mais je ne savais pas
> que toi non plus, tu n'avais visiblement pas bien compris...
5. J'ai jamais utilise de DLL qui est un format encore plus batard que le _nostub que je critique ouvertement et sans moderation.

On ne t'accuse pas d'avoir abusé du format, mais juste de ne pas avoir compris l'intérêt. Tu n'as pas l'air d'avoir lu la documentation. Et puis, il faudra m'expliquer ce qui est "bâtard" dans le format.

Ben, Sebastian et moi, on travaille sur un linkeur, donc ça nous concerne quand-même un peu. Personnellement, j'avais très envie de supprimer le support pour le format kernel avec TIGCC 0.95. Mais pour te calmer: Sebastian l'a déjà implémenté maintenant.

Attends la sortie de GTC avant de supprimer le support du Kernel s'il te plait. De toute facon si jamais il sort une version de TIGCC sans kernel je garderai l'ancienne.

Ah, parce que ça arrive si souvent que ça que TI sort une nouvelle variante de la machine avec les touches à un endroit différent.
Il n'y a eu que 2 telles mises à jour depuis la sortie de la TI-92+:
- TI-89 (1998). Et il n'aurait pas suffi de changer les touches dans ta libraire pour que les programmes soient compatibles, vu qu'il y a aussi l'écran qui est plus petit.
- Voyage 200 (2002, 4 ans plus tard). Statistiquement, la prochaine mise à jour avec un changement important des touches n'est à attendre qu'en 2006.

C'est quand même trop si d'ici la des programmeur ont disparu, on est bon pour convertir les programme a coup d'éditeur hexadécimal voire completement dans la merde si les modifications sont plus importantes. et puis ca peut serir a corriger des bogue aussi

Pourrais-tu développer? Parce que là, je ne vois pas du tout pourquoi on en aurait besoin.

Tu ne fais pas beaucoup de jeux avancés, moi je vais sans doute m'en servir pour un projet que j'ai encore au fond d'un placard. Ca peut par exemple servir a faire des scrollings simplement(dans certain cas particuliers).

Ben, moi je présuppose que le programmeur est une personne intelligente, renseignée et diligente. Toi, tu as l'air de présupposer cela même de l'utilisateur, donc le fait que tu ne présupposes pas cela du programmeur m'étonne un peu.

Vu le nombre de question auquel tu réponds tu devrais savoir que ce n'est pas le cas

>comptes pas?
>skrnklib < ttstart. Certes, mais sizeof(shrnklib)>0.

je resumerai:
0<shrnklib<ttstart<<ttstart*nombre de programes utilisant un lanceur comme c'est le plus souvent le cas