Kernel vs Nostub? - Page 15

XDanger>
si on suppose que 33%<ratio<66%, et taille_entrée<=65000, abs(taille_entrée-2*taille_sortie)<10k << 40k, et en général ça fait bien moins (c quand même assez rare de compresser un fichier de 64 ko à 66% seulement...) Mon approximation est tout à fait satisfaisante, non?

Je croyais que tu étais en prépa ?

Que veux-tu, tout le monde n'est pas un boss en math comme toi


Uther> ce serait fort possible

Laisse tomber. J'ai mal lu ton message et je te présente mes excuses...
Un majorant de la mémoire que nécessite l'algorithme est 40 KO + 2 * 65520 octets, ce qui fait environ 168 KO. D'accord, il y aura très rarement besoin d'autant de mémoire.
Et je déduis de ce que tu dis, que l'algorithme ne fait donc pas de recopie supplémentaire en RAM si besoin est ?

> Que veux-tu, tout le monde n'est pas un boss en math comme toi
Note bien que je n'ai pas prétendu être un boss en maths...
J'aime de moins en moins les maths... D'une manière générale, quelle que soit la matière scientifique, plus ce qu'on apprend est abstrait et inutile, moins ça m'intéresse... Et encore, je suis en MIAS, pas en prépa...

> Et je déduis de ce que tu dis, que l'algorithme ne fait donc pas de recopie supplémentaire en RAM si besoin est ?
Oui

> > Que veux-tu, tout le monde n'est pas un boss en math comme toi
> Note bien que je n'ai pas prétendu être un boss en maths...
> J'aime de moins en moins les maths... D'une manière générale, quelle que soit la matière scientifique, plus ce qu'on apprend est abstrait et inutile, moins ça m'intéresse... Et encore, je suis en MIAS, pas en prépa...
Bon, c à moi de tes faire mes excuses à ce moment-là; disons que je n'avais pas trop apprécié le ton de ton post Ceci dit je ne voulais pas faire de l'amalgamme (hum hum personne n'est visé )

hum, en attendant, GTC n'est tjs pas là

Ton packer sortira avec GTC?

ou peut-être un petit peu après (en même temps que GT-Basic?)

et ce serat possible de l'utiliser avec GT-Basic ??

bien sûr de toute façon à la compilation tu peux compresser tes ressources (sprites, maps, texte, et même éventuellement programmes...) et il les décompressse dès que tu en as besoin

> ou peut-être un petit peu après (en même temps que GT-Basic?)
Personnellement, je serais pour que ce packer sorte le plus vite possible. Mais je ne suis pas représentatif de l'opinion de la communauté TI, n'attendant pas spécialement GT-Basic car je ne programme plus en BASIC, et ce même si GT-Basic semble avoir des fonctions intéressantes...

> Personnellement, je serais pour que ce packer sorte le plus vite possible
Il est pô fini... En plus il est seulement sur ma calc et g pas encore reçu mon câble TI-PC (il devrait arriver après-demain)
Et puis tant qu'il n'y a pas GT-VM pour avoir une lib de décompression, ça limite pas mal la diffusion.

> je ne programme plus en BASIC
A moins que ce ne soit par principe, je pense que tu risques de t'y remettre

Si t'as besoin de beta-testeur, je suis volontaire
enfin, c pas trop la peine de le préciser, je pense

Bon, j'ai pas mal de retard là (j'en suis à la page 12). On va essayer de rattrapper ça.

Uther Lightbringer
a écrit : Comme je l'ai déjà dit, une notation a partir d'un tableau est une maivaise idée car aucune note ne pourra vraiment représenter la réalité. Mais les commentaire a l'intérieur du tableau sont bons et représentent a peu près tous les avantages et inconvéniants. de chaque méthode.

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.

La c'est vrai mais une DLL Nostub n'est vraiment pas si simple a utiliser qu'une lib dynamique kernel

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.

C'est un gros avantage du kernel: c'est 64K/64K/64K pour tous les programmes y compris Nostub !

N'importe quoi. Tu connais les lanceurs?

Mais rien ne te permet d'affirmer que le kernel est dépassé. C'est une idée bien personelle sans véritable fondement.

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.

Volées sur un format prétendu dépassé mais qui a été bien plus visionnaire vu qu'il les gère depuis des années.

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.

Argument qui ne vaut pas le Kernel fait plus que l'anti crash de Kerno. Si tu fait la somme de tout ce que je t'ai cité comme TSR pour s'approcher du format kernel, tu le dépasse.

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.

gaspillage de place pour les multiples launchers

Personne ne t'empêche d'utiliser ttstart ou TICTEX pour tout.

et pour le code réemployé plusieurs fois. On en revient au même.

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.

TiMad a écrit :
MDR.
Mon affirmation est tout a fait juste, c'est un axiome des Ti68K, donc amuse toi a demontrer sons contraire.

LOL, un axiome!

Thibaut a écrit :


> Parle à Pollux de certaines techniques d'optimisation de GCC et il ne saura même pas ce que c'est...
Ce n'est pas parcequ'il ne connait pas les termes qu'il n'a pas eu l'idée d'intégrer les optimisations qu'ils désignent
J'ai bien codé un algo d'extraction de racines carrées sans savoir que ça s'appelait une recherche dichotomique, par exemple. C'est bien beau d'avoir de la culture (informatique), Kevin, mais je trouve que c'est bien mieux d'être capable de construire des algos.

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.

Pen^2 a écrit :
oui, oui. de toutes façons c un boss Pollux

Alors là carrément, c'est très objectif comme argument ça.

XDanger a écrit :
> Les routines de sprites de TIGCCLIB ne sont pas si lentes que ça. Vrai, mais elles sont plus lentes que celles d'ExtGraph (qui vont, je le répète encore une fois, être améliorées dans une des prochaines versions). C'est inhérent aux tests dûs à la gestion des trois modes dans la même routine.

C'est fait pour des raisons d'économie de place.

>>>Ah, je vois (c'est dans le ZIP de Pedrom que tu m'as envoyé pour le problème avec A68k ). Il y a pas mal de trucs qui pourraient nous intéresser (pour la documentation de TIGCC) dans ton Note.txt.
>>C'est fait pour
>Mais il faudra que quelqu'un (probablement moi, ou peut-être Lionel) traduise tout ça du Français raccourci à l'Anglais complet.
Probablement toi, en effet. Il serait improbable que j'aie du temps pour faire autre chose que le strict minimum pour TICT, avant les grandes vacances. En revanche, toi, tu nous démontres brillamment dans ce topic que tu as du temps... Et bien sûr, il ne faut pas oublier de remercier PpHd pour ce boulot de documentation qu'il fait.

Évidemment. Nous remercions toujours ceux qui contribuent à TIGCC.

> Et puis, "programmer en _nostub" ne veut pas forcément dire "programmer seulement pour AMS". La preuve: Backgammon marche très bien sous Pedrom Oui, mais programmer spécifiquement pour PedROM veut dire programmer pour une petite minorité de gens...

En effet. Je ne pense même pas à programmer exclusivement pour Pedrom.

PpHd a écrit :
>Il est non seulement tout à fait possible de coder des programmes mathématiques en C sous AMS, ça permet aussi de faire plein de choses qu'on ne peut pas faire en BASIC. Par exemple, rechercher des sous-expressions d'un certain type dans une expression et faire des manipulations sur les sous-expressions trouvées.
On ne dit pas que c'est impossible. Mais plus difficile qu'en basic, pour un avantage pas si evident que ca.

Bon, code-moi ça en BASIC:

// Traverse the current expression to find all subexpressions of the form (...)!
// and expand the contents of (...). This is done because AMS will simplify
// (2n+2)!/(2n)!, but not (2(n+1))!/(2n)! for some reason.
// Binomial sums such as gosper89(4^k/nCr(2k,k),k,0,n-1) would fail without this
// function, and this is unacceptable since binomial sums are the main use of
// the Gosper algorithm.
void expand_factorial_contents(ESI p)
{
  ESI o=p,q=next_expression_index(p);
  while (p>q) {
    if (*p==FACTORIAL_TAG) {
      ESI newq=top_estack;
      push_between(q,next_expression_index(p));
      ESI newp=top_estack;
      push_expand(--p,NULL,0);
      push_between(p,o);
      o=top_estack;
      p=newp;q=newq;
    } else if (is_variable(p)||*p==USERFUNC_TAG
               ||(*p>=ARB_REAL_TAG&&*p<=STR_TAG)) {
      p=next_expression_index(p);
    } else if (*p==EXT_TAG||*p==EXT_INSTR_TAG||*p==EXT_SYSTEM_TAG) {
      p-=2;
    } else p--;
  }
  push_internal_simplify(top_estack);
}

(Cette routine est en principe sous GPL. Étant l'auteur, je me permets de la poster ici sans poster une copie de la licence, mais vous êtes quand-même tenus à respecter la GPL si vous utilisez cette routine.)

>Mais il n'y a quand-même pas de fortes chances que sprintf change de manière imprévue.
Une simple recompilation en changeant les flags suffira a casser votre hack

J'en doûte.

>Mais bonjour la taille des routines qui permettent cela [stdin, stdout, stderr]... Je suis sur que tu es capable de le faire en moins de 500 octets.

Non. fprintf dépendrait de printf etc. Donc la taille de chaque routine d'accès aux fichiers de stdio.h doublerait.

>De toute façon, la compatibilité binaire parfaite est illusoire. Par exemple, les kernels ont été incapables de garantir la compatibilité binaire entre AMS 1 et 2, il y a eu besoin de changements dans les kernels et de recompilations, de réassemblages, voire de portages assez complexes pour les programmes. Les programmes accedaient a des variables absolus.

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.

Le format du kernel a bien evolue depuis.

Ben, heureusement pour lui, sinon il n'existerait plus.

>Alors que les premiers programmes _nostub (on les comptait sur les doigts d'une main à l'époque) n'avaient pas besoin de portage du tout d'ailleurs (sauf pour basiclib qui utilisait des adresses absolues toutes les 3 lignes ). C'est surtout parce qu'ils ne faisaient rien et qu'ils se comptaient sur les doights d'une main.

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.

>Ça ne veut pas dire qu'il n'est pas dépassé! Comme j'ai déjà dit: il y a toujours des nostalgiques pour faire évoluer les systèmes totalement dépassés! Pour qu'il soit depassee, il faudrait qu'il soit technologiquement inferieur au nostub. Ce qui est absolument le contraire. Technologiquement parlant, le kernel est bien superieur au nostub. La preuve est simple : EX_patch en _nostub, seul suffit. Un kernel de 3Ko (Et bien etudie en taille) est necessaire et suffit pour le mode kernel.

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.

>Le format de base ne change pas parce qu'il n'a pas besoin de changer. Il est très bien comme il est. Et il y a des évolutions à l'intérieur de ce format de base. Par exemple le format de commentaires et autres données qui est en développement.
Ca ne fera jamais parti du format _nostub. Le format _nostub c'est : SIZE + CODE + TABLE_DE_RELOGEMENT + TAG

_nostub = no stub = pas de stub. Le header des commentaires n'est pas un stub, donc c'est du _nostub.

>- Même si c'est le cas, ce n'est pas une raison à elle toute seule de ne pas utiliser les librairies statiques. Déjà, les librairies statiques ont aussi leur manière d'économiser de la taille (ne pas linker les fonctions inutilisées). Et ensuite, même dans le cas très improbable où la librairie statique prendrait plus de place, les avantages des librairies statiques justifient nettement le sacrifice minimal en taille.
Je connais une lib statique qui s'appelle allegro. Et qui meme lorsqu'on ne fait appel qu'aux fonctions d'initialisation/quit prend 400Ko sur ton programme... Elle est ou l'economie ?

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").

>- impossible de lancer un programme sans installation préalable d'un programme tiers. Le programme tiers peut l'installer lui-meme.

Non, un programme non-TSR qui installe un kernel ou n'importe quel autre TSR, ça s'appelle un leak de mémoire.

>- gaspillage de place en utilisant une surcouche d'émulation par dessus AMS (pour une estimation de la place gaspillée, comparez la taille de PreOs avec celle de KerNO).
+KerNO: 2949 bytes. PreOS: 6657 bytes. (3706 bytes)

Voilà. Le chiffre entre parenthèses ne s'applique pas, parce que KerNO inclut également h220xTSR. C'est tout ce que j'ai demandé. Le reste est hors-sujet.

+KerNO: Diamond+ON turns off. PreOS: No. AMS does the job.

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.

+KerNO:Fixes (removes) the slowdown that happens in some games when the calc is turned back on after being turned off during game play PreOS: No. It is a buggy feature !

Ce n'est pas bogué. Je cite J89hw.txt:

$600003 -W ($FF) Bus waitstates
The TI89 hardware needs no waitstates. AMS messes with this port on
startup for compatibility with the TI92, but the battery checker will reset it to $FF within one second.

+KerNO:Checks the heap PreOS: Useless.

Non.

>- complique la vie aux développeurs d'outils de développement à cause de son format difficile à gérer pour le linker. On en a deja parler. Et c'est de la mauvaise foi.

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.

>C'est à ça que servent les masques. Ils sont aussi plus flexibles. Mais consomment plus en memoire.

Certes. Mais en voyant Chrono (qui n'utilise pas de masques), on ne dirait pas.

XDanger a écrit :
> PreOS: Can call any program at any-time by pressing SHIFT+ON (Even tictex). Sans jamais faire de bugs avec le bit in_use ou des trucs comme ça, quand on lance SHIFT+ON quand on édite un texte dans l'éditeur de texte, [je demande de l'info] ?

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.

PpHd a écrit :
>> PreOS: Can call any program at any-time by pressing SHIFT+ON (Even tictex).
>Sans jamais faire de bugs avec le bit in_use ou des trucs comme ça, quand on lance SHIFT+ON quand on édite un texte dans l'éditeur de texte, [je demande de l'info] ? Si tu veux des bugs, c'est tres simple. Prend un programme qui modifie l'EStack par un HS_popEStack, et ca plantera (un ER_throw).

Et si on modifiait bottom_estack temporairement, pour que HS_popEStack ne touche pas à ce qui y était déjà?

PpHd a écrit :
>Tu ne le respectes pas. Déjà, tu n'utilises pas la table de relogements prévue par le format. Et ensuite, tu mets des trucs dans le fichier sans mettre du code pour les gérer, juste un stub pour appeler un TSR (le "kernel"), dans l'espoir qu'il soit installé. S'il ne l'est pas, ça ne marche pas. Ce n'est pas ce que j'appelle "respecter le format natif". En quoi ne pas utiliser la table de relogements du format n'est pas le respecter ? Il existe des _nostub qui ne l'utilisent pas aussi.

C'est quand-même à la limite du respect du format.

En quoi faire appel a une fonction externe non-documentee n'est pas respecte le format d'AMS ?

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.

>CC utilise un nombre excessif de relogements absolus! Il y a beaucoup trop de variables globales partagées entre plusieurs fichiers source. Un programme conçu spécifiquement pour TI-89/92+/V200 n'utilisera jamais autant de relogements.
>Et puis, CC n'utilisait aucune librairie dynamique, donc ça n'a aucun rapport avec les librairies dynamiques ou statiques. C'est juste une question de relogements. Et alors ? Justement, cela prouve le caractere technologiquement depasse de ce format.

Non, c'est juste un cas exceptionnel.

>1. C'est tout bête. Il suffit de mettre #define EXECUTE_IN_GHOST_SPACE.
Et cette astuce foirera lorqsue TI mettra plus de 256Ko de RAM. Remarque, ce sera pas les seuls programmes a ne pas fonctionner.

En effet.

>2. Cette "astuce" n'est nécessaire que si on programme un shell ou un programme de ce style. Pour tous les autres programmes (jeux, programmes mathématiques, ...), on n'a besoin d'aucune "astuce". Et en kernel, on n'en a besoin d'aucune.

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...

>Tu appelles 9 KO "pas tant de place"? Et pas toi ?

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.

>J'avais dit cela de manière totalement objective. Ça ne sert à rien parce que au moins 95% des jeux sur TI-89/92+/V200 n'ont aucune difficulté à atteindre les 10 fps nécessaires pour obtenir la fluidité. ExtGraph est suffisamment rapide. 10fps sont LA limite a ne pas franchir. Pour avoir un bon confort d'utilisation, il faut etre a plus de 20 au moins.

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.

>- le b*rdel que ça va être pour le programmeur (ou pour l'utilisateur) de choisir les bonnes DLLs parmi la centaine disponible pour son pack archive, alors que pour les librairies statiques, le linker s'occupe de cela pour lui. Faux. Les includes headers mettront cela de maniere transparente, et la lib complete est distribuee sous la forme d'une pack.

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.

>Donc c'est une très mauvaise idée (en plus d'être un hack ). Ce n'est pas un hack.

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.

>Comment veux-tu pouvoir choisir la DLL à laquelle appartient la fonction que tu veux appeler si tu charges plusieurs DLLs en même temps et que tu ne les numérotes pas? Faire une base commune et lors du loading, on charge dans la base commune l'ensemble des adresses.

Tu n'as pas encore plus compliqué?
Ça montre bien que le fait de se limiter à une DLL simplifie l'implémentation.

>Donc plus de kernel en développement? Non. J'ai un remplacant.

Qui?

>Dans ce cas, il suffira que TI sorte une mise à jour qui empêche à PreOs et Universal OS de fonctionner, Meme AMS 2.07 n'a pas empecher Preos de fonctionner sans changement des sources.

Rien ne dit qu'un futur AMS n'empêchera pas à PreOs de fonctionner.

Seul hw2tsr posait probleme
Les kernels survivront ne serait-ce que grace a toi

LOL.

>Mais "Extended Assembly file" ne veut rien dire. Contrairement à toi, nous n'aimons pas les néologismes. Je sais. Tres terre, a terre. Mais avoue que DLL est un TRES MAUVAIS CHOIX de nom, pour ce qu'elles sont censees faire.

Ben, techniquement, c'est ce qu'elles sont.

>Pourquoi? Il y a juste une rangée à redessiner plutôt que l'écran entier, et je pense bien que le scrolling lui-même soit plus rapide que de réafficher l'écran entier, vu qu'il y a beaucoup moins de calculs à faire. En matiere de lecture/ecriture, y'a autant de lectures / ecritures dans l'un que dans l'autre.

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.

>Non. Dans les 2 cas, il y a juste une paire de coordonnées par plan à changer. C'est exactement la même chose. Mais ta double boucle for sera bien plus lente que put_plane !

Pourquoi ça? put_plane n'est pas fondamentalement différent d'une double boucle à ce que je sache.

>Pourquoi? Je ne fais qu'appliquer la définition du scrolling différentiel. Ben je crois que l'on n'a pas la meme definition.

Ben, la définition du scrolling différentiel, c'est plusieurs fonds qui défilent à des vitesses différentes.

>Aucun intérêt. TI réussira certainement à détruire les choses beaucoup plus que ce que je pourrais imaginer.
On change de processeur. Ou mieux. On installe un vecteur a la con en $30.l

Oui, excellente idée!
Et pourquoi pas une routine d'effaçage des certificats en $34.l?

>Comment ça? En changeant le code du programme? On peut faire la même chose en _nostub.
Ca serait totalement transparent en mode kernel

En _nostub aussi si on le met dans le lanceur personnalisé.

>Comme la taille horizontale a diminué dans mon exemple, ça ne donnera rien de lisible. L'int se chargerait de reduire la ligne.

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.

>Probablement non. Et je parie que tu as encore oublié de compter la taille du kernel.
Et toi tu as oublie que le kernel de ma calc est en ROM

Tu ferais mieux d'utiliser cette place pour les ROM_CALLs AMS 2 les plus utiles.

>Il n'y a aucun problème justement. Chaque programme utilise la version pour laquelle il est prévu. Il n'y a aucun conflit! Et lorsqu'on ne sait meme pas laquelle il faut utiliser ?

On le sait: il faut utiliser la version qui est linkée dans le programme.

>N'importe quoi. Ton attitude "si les fonctions sont inutilisées, le programmeur n'a qu'à les utiliser" est arrogante et stupide. Si les fonctions ne lui servent pas, pourquoi devrait-il les utiliser juste pour qu'elles soient utilisées?
1. C'est en dynamique parce que ca permet de centraliser toutes les versions en une seule, d'ou une simplicite de mise a jour pour l'utilisateur qui n'est pas dependant du bon vouloir du programmeur.
2. Donc ces fonctions que le programmeur le veuille ou non, y sont.
3. Pourquoi ne pas rajouter alors un petit bonus pas trop gros qui les utilise ? C'est un 'Pourquoi pas', pas un 'n'a qu'a'.

Ç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".

PpHd a écrit :
> Et tout ceci alors que la solution au problème est très simple: utiliser une librairie statique, comme ça, quand le programmeur n'utilise pas certaines fonctions, l'espace mémoire sera économisé. Ton "Mais elles y sont !" est exactement le problème, auquel tu n'as pas donné de solution parce qu'il n'y en a pas en restant dans le domaine des librairies dynamiques. Il n'y a aucun probleme si les libs dynamiques sont a jour. Et en plus, c'est tres facile maintenant de les avoir a jour.

Ç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.

>Tu as bien réussi à te passer de code auto-modifiant dans PedRom! Bien obblige, non ?

Ben oui. Donc maintenant, fais pareil pour genlib et elle sera facile à passer en statique.

Mais :
1. La plupart des constantes sont vraiment constantes. 2. Le reste, c'est des vars globales.

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.

>En d'autres mots, tu es trop paresseux pour faire de l'allocation de registres. Dans ce cas, utilise un compilateur, il s'occupera de ça pour toi. GCC compile mal. Je passe beaucoup de temps a lui expliquer mon code C de telle facon qu'il est traduit de maniere optimale.

As-tu essayé GCC 3.3 (prerelease)?

>Mais ce n'est pas du tout dans ton esprit "le kernel gère tout",
Le format est bien evoultif puisqu'il autorise a autoriser ttpack

Mais dans l'esprit "le kernel gère tout", ça serait au kernel de décompresser, pas à une librairie externe.

> ce n'est pas pratique. Totalement transparent au niveau utilisateur.

Ça serait encore plus transparent si c'était le kernel qui décompresse.

> et shrnklib compresse nettement moins bien que ttpack Pas tant que ca. Et elle decompresse bien plus vite.

Pas tant que ça.

Ce qui est plus important.

Pas du tout. Si on veut de la vitesse, on ne compresse pas. Si on compresse, on veut de la place.

>En le compilant en une librairie dynamique? Thomas va te tuer si tu fais ça. Pourquoi ? La licence me l'interdit ?

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.

>Ce qui n'est pas vraiment le cas pour les programmes pour TI-89/92+/V200 normalement. J'aimerais le faire. Mais Tigcc m'en empeche.

Peux-tu élaborer?

>Et ne me ressors pas la blague des packs archive avec une DLL par fonction, j'ai déjà montré que ça ne tient pas du tout la route. Tu n'as rien demontre du tout. Au contraire, tu parlais de quelques inconvenients mineurs, mais en aucun cas que ca ne pouvait pas marcher.

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.

>Tout le monde ne connaît pas par cœur les numéros de la centaine de fonctions de genlib. Je pense d'ailleurs que même toi, tu ne les connais pas par cœur. Je n'ai jamais dit que c'etait facile. Mais lisible.

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 (), je sais ce que c'est.

>Et pourquoi? Un nom est suceptible de changer a cause de la langue (TI-basic),

Aucun rapport avec ce de quoi on parle.

ou de mises en conformite sur ce que fait reellement la fonction.

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.

>Parce que chez nous, la discussion n'est plus entre _nostub et kernel, mais entre _nostub et FlashApps.
Je sais. C'est bien ce que je disais. Franchement kernel rulez ! kernel >> nostub >> FlashApps

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.

>Il n'y a pas que les jeux genlib à être "concus pour etre beaus, riches et complexes", et pourtant les autres ont bien réussi à sortir des versions 1.00 (TI-Chess, Duke68k, ...). Ti-Chess est un jeu d'echec, donc les graphismes c'est a part.

What a great game of chess. There's nothing more to it than that. This latest version features an improved menu, some of the best graphics on a calc
, and an unbeatable AI (for me at least). For its time, this program is unbeatable.

Adam Palmer, review de TI-Chess sur ticalc.org, 31 août 2000 (version 3.01).

>Ce n'était pas le seul problème qu'il avait. Il y avait pas mal de bogues. Il a toujours fallu avoir la dernière version de genlib pour chaque version de Total Destruction. Et ou est le probleme ? Faire une mise a jour est elle une operation si difficile ?

Le fait est qu'il y a eu des bogues.

>2. Quand j'en suis déjà au handle, je m'attends à ce que tout le travail sur les HSym et SYM_ENTRY ait déjà été fait, et EM_twinSymFromExtMem en fait partie. Quelle idée que de passer un bloc archivé à une fonction d'exécution! kernel::exec ne devrait pas accepter cela (je sais, c'est trop tard pour changer etc., pas la peine de me dire ça). La méthode propre est d'appeler EM_twinSymFromExtMem avant d'essayer d'obtenir le handle. Pourquoi ? C'est a elle de se rendre compte que le fichier est archive et necessite un traitement particulier.

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.

>Donc tes jeux ne sont pas si complexes que tu prétends.
Je code en ASM de maniere optimise (en taille et en vitesse).
Et eux en C,

Je ne pense pas que ça influe tant que ça.

>Bon, je répète en accentuant la locution importante: "Ils ont retiré quelques fonctions isolées (une douzaine), mais en général, ils rajoutent des fonctions, ils n'en retirent pas." Et que fais-tu de ceux retires ?

On les réimplémente dans tigcc.a. De toute façon, comme j'ai déjà expliqué 2 fois, c'est très rare.

>Ou que l'offset ne change pas. Il n'y a que 8 instructions devant celle qui nous intéresse, et elles ont toutes peu de chances de changer à moins que TI ne se mette à utiliser l'équivalent de -fomit-frame-pointer.
Moi qui est fait un sprintf avec gcc, je suis obblige de rajouter a la main 2 'nop', pour que ca marche

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?

PpHd a écrit :
>Il suffit de le mettre dans ttstart. Puis on recompile un nouveau lanceur personnalisé à partir de la mise à jour de ttstart et c'est bon.
Et ttstart deviendrait un kernel non-installable

Sauf que personne ne le remarquerait.

>Bah, j'ai codé *scanf (source de 11 KO, routine de 1 KO) en assembleur GNU et je n'ai pas trouvé ça si lourd que ça. Peut etre, mais a t'entendre, un peu quand meme.

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 ), mais maintenant, j'ai pris l'habitude et ça ne me dérange plus du tout. Et puis, je te rappelle qu'il y a toujours --register-prefix-optional.

Par ailleurs, il faudrait verifier si le code que j'ai fait de lecture des nombres reels (PedroM / EStack.asm) ne permettrait pas de reduire encore la taille du code (Plus d'appel a Atof).

atof ne prend pratiquement pas de place. C'est push_parse_text qui fait le vrai travail.

>>>C'est justement ça ton erreur, à mon avis.
>>Tu veux donc un exemple ou c'est impossible de faire autrement ?
>Si tu en as un, poste-le. On parle de quoi ?

D'exemples où on est obligés d'utiliser des listes chaînées énormes.

>Est-il si grave que les 3 ou 4 programmes (je ne pense pas qu'il y en ait plus que ça) qui utilisent les 3 RAM_CALLs maintenant reçoivent un mélange de fontes du boot et de fontes de la ROM?
Je perdrais mon honneur

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?

>Pourquoi en aurait-il besoin puisque, vu qu'il utilise la version actuelle, le programme doit forcément être adapté à la vitesse de la version actuelle? Laisse au programmeur le soin d'en decider.

Oui, laisse au programmeur le soin d'en decider, donc propose-lui une version statique.

>>>Les jeux avec FAT Engine ou d'autres techniques 3D tournent souvent autour des 10 FPS. Les jeux en 2D ont des framerates nettement plus élevés.
>>Ils sont plus interressants aussi.
> Hein ? Ben le FAT engine, ca va 2s.

Il y a des jeux assez variés qui l'utilisent. Par exemple un PacMan en 3D.

>Ah tiens, tout d'un coup. Sur un jeu de 33 KO ou plus, les routines de niveaux de gris font 3% ou moins. Donc si tu n'es pas à 3% près, arrête de te plaindre du fait qu'ils utilisent les routines de niveaux de gris en librairie statique. Oué, sauf que ca me pose des problemes pour faire fonctionner des vieux jeux nostub qui utilisent vos vieilles routines de gray, qui marchent pas sur PedroM ! Et y'a pas les sources !

On en a discuté par mini-messages et en fait, c'est un problème de VTI (il émule une HW1 même s'il est détecté comme une HW2), pas de Pedrom ni de nos routines. Les routines récentes détectent VTI et le traîtent comme une HW1, ce qui résout ce problème.

>Quelle idée stupide!
>Crois-tu vraiment qu'un nag screen de style shareware au début de chaque programme juste pour parler de ttstart à l'utilisateur soit une idée intelligente? Oui, sans aucune hesitation.

Tu es plus fou que je pensais...
Il te faut vraiment faire des cours d'utilisabilité, et rapidement!
Commence par lire ça et ça.

>Je n'ai pas le temps d'essayer, mais je pense bien que CF ou SMA pourraient très bien fonctionner avec ExtGraph.
>Et SMA est trop rapide de toute façon.
Ok. Tu as les sources de SMA en plus

Mais pas le temps.

>Non, il faut installer un kernel, donc on ne peut pas les lancer directement. Une fois installe PreOS, tout se lance directement.

Ce n'est pas direct parce qu'il y a l'installation de PreOs.

>Mais non! C'est quoi cette arrogance de vouloir toujours imposer son choix à l'utilisateur?
ET LES LIBS STATIQUES C'EST PAS UN TRUC IMPOSE A L'UTILISATEUR ! Et si l'utilisateur a envie de mettre a jour son programme favori pour quelques corrections de bogues, il peut facilement mettre a jour la lib externe sans attendre le bon vouloir du programmeur !

C'est le prix à payer pour le comfort d'utilisation.

>(i) C'est un effet artificiel, pas beau.
>(ii) Les masques sont là pour ça. Et c'est un moyen plus flexible. Par exemple, en codant son propre masque, on peut choisir soi-même la largeur du halo. Plus de memoire consommee.

Mais consommée pour quelque chose d'utile.

>Pour le clavier, tu as _keytest, _keytest_optimized et _rowread dans TIGCCLIB. C'est mieux le joypad.

Non, c'est moins flexible.

>Pour le link, les ROM_CALLs marchent très bien si on les utilise correctement. Je dis pas le contraire. C'est juste plus rapide.

Pas vraiment. Le facteur limitant est la vitesse du port I/O, pas celle des routines.

>Il suffit d'utiliser OSContrastUp et OSContrastDn pour avoir des "effets de lumière". Et pour avoir des sources de lumieres ponctuelles ?

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.

>Mais [les effets d'ondulation par tables DHZ/HDZ] c'est juste un effet spécial dont on peut très bien se passer. Et y a-t'il d'autres personnes que toi à utiliser ça? Oué.

Qui?

>Si. Il y a bien des jeux "temps réel" codés avec ExtGraph! Entre "jeux temps reel" et "jeux d'actions". Il y a une marge importante.

Il faudra que tu m'expliques alors, parce que pour moi, c'est exactement la même chose.

>Bonne change pour le faire signer par TI.
Pourquoi le faire signer par TI ? Pas besoin

Comment fais-tu alors?

>Partout dans les discussions kernel vs. _nostub précédentes. Je n'ai jamais ete convaincus par ces calculs, surtout qu'avec la base tigcclib commune, beaucoup de programmes partagent les memes routines.

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.

>2. Comme dit plus haut, il n'y a pas tellement de fonctions utiles qui n'y sont pas. DrawFace ?

Je parle de fonctions vraiment utiles. Et cela dans un contexte de jeu 2D, pas 3D.

>1. On peut aussi mettre à jour ExtGraph pour d'autres machines. Il suffit de relinker.
>2. Si la taille d'écran change radicalement, le programme devra de toute façon être porté A condition d'avoir les sources.

Ben, sans les sources, il ne marchera plus, et genlib n'y changera strictement rien.

>Ça dépend de la librairie. Dans userlib et graphlib, il y en a plein qui le sont, ou devraient l'être puisqu'elles sont déjà dans AMS: userlib::idle_loop, graphlib::clr_scr etc. Elles sont utilisees par des programmes.

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!

>Et puis, tu fais comment en cas d'erreur? Tu appelles exit dans genaux_init? Et si le programme a alloué de la mémoire avant, il fait quoi? Obligé d'utiliser atexit? C'est tout sauf pratique. Il fait quoi ? Il utilise l'ancienne methode, c'est tout.

Bref, ce n'est pas une bonne idée d'utiliser exit en cas d'erreurs.

>Si. Ce n'est même pas un facteur 3/2! C'est loin d'etre negligeable.

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.

>Parce que tu utilises des lignes et des cercles plutôt que des sprites pour tes personnages. Faux. J'utilise des sprites pour mes personnages.

Il faudra que tu m'expliques comment tu fais alors...

>Solution plus simple: sors tes sources, comme ça on pourra les recompiler s'il y a un problème. Si tu ne veux absolument pas les publier, envoie-les à une personne de confiance et qui reste dans la communauté. C'est loin d'etre plus simple.

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.

>Je sens que Thomas ne va pas aimer. Et moi non plus d'ailleurs. Le format PPG est là pour être respecté! En quoi c'est de l'irrespect du format PPG ? Il n'a rien a voir la dedans.

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.

>Le standard de commentaires _nostub est plus propre et mieux défini que le "standard" imposé par l'usage des kernels. Je vois pas en quoi ca peut etre plus propre et mieux definis.

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).

>Et si le standard de commentaires _nostub est du vaporware, PedROM, c'est quoi ? Je n'ai jamais donne de date de sortie.

Moi non plus. J'ai juste dit fin janvier que sauf objections, je sortirai la spécification le 1^er février, et j'ai maintenu cette date.

>En effet. Allez voir les comments du thread qui parle de CC sur TI-Net, avant qu'il y en ait un qui se rende compte qu'il y a une version _nostub... Il y a des trucs du genre "I'm not going to put an evil shell on my calculator just for that" (écrit tel quel si je ne me suis pas trompé; le 'evil shell' est écrit, en tout cas), ce qui est somme toute assez clair... Oui. C'est un extremiste qui ne connait pas ce que le mot 'diable' signifie et qui l'utilise a tord et a travers.

"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".

Ou qui ne connait que Doorsos.

Donc pour toi DoorsOS est un produit du diable?

>Ca n'est pas sale. Ca fait gagner beaucoup de RAM, par contre... Du reste, XPort (un autre shell en grayscale), décharge aussi la plus grosse partie quand un programme est exécuté. C'est pas tres propre.

En quoi n'est-ce pas très propre?

>Oui, mais programmer spécifiquement pour PedROM veut dire programmer pour une petite minorité de gens...
Et ? De toute facon, pour le moment c'est impossible de programmer specifiquement pour lui.

Faux. if (*(unsigned short *)0x32!=('R'<<8+'O')) return;

>Et puis ça serait trop bête de se limiter aux AMS 2.xx, sur lesquelles un certain nombre de programmes kernel-based ne fonctionne pas du tout... Tiens ? Tu t'interresses a la compatibilite AMS 1.0x. Je croyais etre le seul.

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.

XDanger a écrit :
> Par ailleurs, il faudrait verifier si le code que j'ai fait de lecture des nombres reels (PedroM / EStack.asm) ne permettrait pas de reduire encore la taille du code (Plus d'appel a Atof).
Tu penses vraiment que le support pour PedROM sera ajouté dans TIGCC (à part peut-être pour détecter PedROM et ne pas exécuter le programme le cas échéant, autrement dit alourdir le code de startup pour un truc dont la majorité des personnes n'ont rien à faire) ? Moi, je ne suis pas dans la TIGCC Team, je n'ai pas pouvoir de décision là-dessus, mais ça m'étonnerait. Et en tout cas, je ne suis pas spécialement favorable à un tel ajout.

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.

>>Et si le standard de commentaires _nostub est du vaporware, PedROM, c'est quoi ?
>Je n'ai jamais donne de date de sortie. A ma connaissance, personne n'a donné de date de sortie pour le standard de commentaires _nostub.

En effet.

>>Oui, mais programmer spécifiquement pour PedROM veut dire programmer pour une petite minorité de gens...
>Et ? De toute facon, pour le moment c'est impossible de programmer specifiquement pour lui. Ca veut dire que ça va le devenir ? Incompatibilité power !

En effet.

PpHd
a écrit : Mais ca sera facile de corriger les kernels pour faire fonctionner le reste.

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.

Mais est-ce necessaire ?

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.

Mais non. Y'aura les kernels pour rajouter une couche d'emulation

Donc PreOs deviendra encore plus gros...

Uther Lightbringer
a écrit : c'est déjà ca! Imagine le gain de place si tigcclib était une lib dynamique .

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.

>Ben si, on peut aussi faire un jeu qui utilise ExtGraph sans savoir comment fonctionne genlib. L'inverse est aussi vrai!

J'en doûte. ExtGraph est nettement plus facile à utiliser que genlib.

Oui mais les 5% de jeux qui restent valent plus que tes 95% de jeux restants

C'est ton avis personnel.

PreOS est open-source non? N'importe qui d'assez doué pourra faire les modification nécéssaires.

Sauf que les "assez doués" ne programmeront probablement qu'en _nostub. Les derniers experts pro-kernel (PpHd par exemple) quittent la communauté petit à petit.

>Peut-être, mais la différence de taille ne vient pas de là. Bien sur le kernel permet bien plus de chose.

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!

tant pis dans le cas d'un écran plus petit(ce dont je doute fortement), il faudrait tronquer. Et en Nostub il faudrait rajouter un patch ou une des nombreuses TSR qu'il faut ajouter pour "approcher le format du kernel.

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.

XDanger a écrit :
> Mais est-ce necessaire ? Peu de programmeurs les utiliseront. Mais le but, c'est d'être une doc complète, la plus complète possible par les descriptions de fonctions et par le nombre de fonctions/variables. TIGCCLIB est très au-dessus de tiams.h/TIFS/la doc de TIFS là-dessus (sauf pour des topics qui n'intéressent presque personne dans TIGCC, notamment les FlashApps).

As-tu documenté les fonctions mathématiques, de style push_sum etc.? Sinon, je veux bien m'en occuper.

PpHd
a écrit : Marche pas sur AMS 1.0x

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.

L'avant-derniere version de PreOs supporte l'auto installation du kernel.

C'est un hack. Ça donne des programmes qui leakent de la mémoire. TIGCC ne permettra jamais ça.

Voilà, j'ai répondu à la page 12, reste les pages 13-15. Mais c'est pour une autre fois.

Tu es plus fou que je pensais...
Il te faut vraiment faire des cours d'utilisabilité, et rapidement! Commence par lire ça et ça.

Pour quelqu'un qui se plaignait du mépris de certains utilisateurs de ce forum, c'est pas mal...

What a great game of chess. There's nothing more to it than that. This latest version features an improved menu, some of the best graphics on a calc
, and an unbeatable AI (for me at least). For its time, this program is unbeatable.

LOL! Les meilleurs graphismes pour un jeu d'échec peut-être...
Mais bon les graphismes dans un jeu d'échec, il y en a pas bcp et en plus on s'en fout à la base, l'intérêt c'est l'IA.
C'est comme les jeux de stratégie tour par tour, même si il n'y a pas d'animations dans tous les sens et de 3D partout, si la profondeur de jeu est là, ça passe très bien (et ça permet de se concentrer sur le jeu )


Et j'aimerais savoir pour quelles raisons exactes (pas d'arguments d'autorité s'il te plait) l'auto-installation d'un kernel est un leak de mémoire ?

Beaucoup de programmes font un test de présence de dll à l'exécution (wmp par example) et téléchargent et installent les dlls manquantes. C'est un leak de mémoire ça ?

Littleboy
a écrit : Et j'aimerais savoir pour quelles raisons exactes (pas d'arguments d'autorité s'il te plait) l'auto-installation d'un kernel est un leak de mémoire ?

Parce que la mémoire libre avant l'exécution du programme est x, et la mémoire libre après l'exécution du programme est x-(taille du kernel). D'où un leak de (taille du kernel) octets de RAM.

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.

Ca rend les commentaire plus complets, mais la notation très mauvaise

N'importe quoi. Tu connais les lanceurs?

Oui et utiliser un lanceur ramène au même problème que d'installer un kernel avec un paquet de fonctionalités en moins

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.

Le fait d'être compatible est être dépase alors TIGCC est complètement dépassé puisse qu'il est compatible avec les vieilles ROM

> Volées sur un format prétendu dépassé mais qui a été bien plus visionnaire vu qu'il les gère depuis des années.
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.

He bien c'est normal puisse quye le kernel est la suite logique de Fargo. Ceci dis il est vrai que votre standard est plus étoffé.

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.

C'est bien ce que je dis on gagne a rassembler dans le kernel.
[/cite]Personne ne t'empêche d'utiliser ttstart ou TICTEX pour tout.[/cite]
Passer par une appli externe(lancer TICTEX ou ce taper une ligne de commande barbare) a chaque lancement du prog. Avec preos, un fois installé c'est fini

>> Et puis, "programmer en _nostub" ne veut pas forcément dire "programmer seulement pour AMS". La preuve: Backgammon marche très bien sous Pedrom
>Oui, mais programmer spécifiquement pour PedROM veut dire programmer pour une petite minorité de gens... En effet. Je ne pense même pas à programmer exclusivement pour Pedrom.

De toute façon plein d'applis non prévues pour Pedrom tourneront dessus le Gros problème c'est le MIN_AMS que beaucoup définissent alors qu'il n'y en a pas besoin.

> Uther Lightbringer a écrit :
c'est déjà ca! Imagine le gain de place si tigcclib était une lib dynamique . 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.

ne serais ce que gray.h stdio.h que l'on retrouve dans un nombre énorme de programmes, feraient gagner pas mal de place

J'en doûte. ExtGraph est nettement plus facile à utiliser que genlib.

Et ExtraGraph est aussi bien plus limité. Genlib possède pas mal de fonction que tu n'a pas a réaliser toi même.

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!

Tu est de mauvaise fois. Je te referais pas toute la liste de tout ce que permet le PreOS parceque ca y est plusieurs fois déja dans ce topic. Et de toute façon le support du format kernel jutifie cela a lui tout seul amplement je plus cela ce grepropement dans un seul TSR permet de gagner de la place. cf plus haut

> Tu es plus fou que je pensais...
Il te faut vraiment faire des cours d'utilisabilité, et rapidement!
Commence par lire ça et ça. Pour quelqu'un qui se plaignait du mépris de certains utilisateurs de ce forum, c'est pas mal...

C'est vrai que le mot fou est en trop mais un nag screen

> Si on veut construire un compilateur optimisant, le minimum à faire est de jeter un coup d'œil sur les optimisations employées par GCC.
Moui, ça se devine. (et d'ailleurs il suffit de regarder le source généré)

> 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à.
cf ci-dessus

> Ç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.
Je ne vois pas ce qui te permet de dire ça. Evidemment, il y a plein d'optimisations que GTC ne peut pas se permettre de faire pour des raisons de conso de RAM et pour des raisons de vitesse (je pense par exemple au 'copy propagation' ou 'constant propagation' comme tu disais). Mais manifestement, au niveau du code généré, il se situe qd même à peu près au niveau de TI-GCC (à 5% près en vitesse et en mémoire), donc je ne vois pas pourquoi tu te permets de critiquer aussi vivement la qualité du code généré. De toutes façons, si GTC se contentait de faire du peephole il ne serait pas significativement plus performant que CC, donc tu as visiblement tort.

Littleboy a écrit :
Et j'aimerais savoir pour quelles raisons exactes (pas d'arguments d'autorité s'il te plait) l'auto-installation d'un kernel est un leak de mémoire ?
Parce que la mémoire libre avant l'exécution du programme est x, et la mémoire libre après l'exécution du programme est x-(taille du kernel). D'où un leak de (taille du kernel) octets de RAM.

lol
T'en as d'autres?

> N'importe quoi. Tu connais les lanceurs ?

Autant installer un kernel ! le kernel permet le lancement des progs kernel et l'anticrash (c'est un tout en un quoi) , contrairement au lanceur.


> Si on veut construire un compilateur optimisant, le minimum à faire est de jeter un coup d'œil sur les optimisations employées par GCC. (...) À mon avis, c'est du bidouillage avec des tonnes de "peepholes", et aucune optimisation à un niveau global.

Tu cherches les insultes ? J'ai du mal à me retenir face à un mec aussi chieur que toi !
1) GCC optimise très bien certains trucs, mais c'est aussi une vraie merde pour d'autres trucs.
2) GTC ne peut pas intégrer toutes les optimisations comme te l'a dit Pollux.
3) Pollux a pu avoir des cours de programmation à l'Université qui utilisent d'autres termes que ceux de GCC
4) Arrête de nous étaler ta culture, tu ne serais pas capable de faire ce qu'a fait Pollux. La culture c'est bien beau, mais...
5) Je me demande si t'as beaucoup d'amis


> Alors là carrément, c'est très objectif comme argument ça.

Pollux a visiblement plus de capacités (programmation et social) que toi, donc je suis d'accord avec Pen2 qui dit que c'est un boss.


> Parce que la mémoire libre avant l'exécution du programme est x, et la mémoire libre après l'exécution du programme est x-(taille du kernel). D'où un leak de (taille du kernel) octets de RAM.

Tu ferais mieux de dire "OK je me suis trompé" que de t'enfoncer un peu plus avec une telle connerie.


Tu me trouves méchant ?
Toi t'es insupportable.

> donc je ne vois pas pourquoi tu te permets de critiquer aussi vivement la qualité du code généré.
L'explication est claire : il a peur pour TIGCC (alors que GTC ne remplacera pas TIGCC tant qu'il n'optimisera pas aussi bien). Je pense aussi à une certaine jalousie de ne pas avoir su réaliser ce vieux rêve de la communauté (un TIGCC-like/light on-calc).

moi>oui, oui.
>de toutes façons c un boss Pollux

kevin>Alors là carrément, c'est très objectif comme argument ça.

ben c pas un argument..

Je repondrais plus tard.

PpHd et Kevin, pourquoi ne feriez-vous pas pendant votre temps libre tous deux des trucs plus importants pour la communauté TI que de passer une bonne partie de votre temps libre à répondre à ce p***** de débat lancé par l'autre con ?

ça c'est une très bonne question
d'ailleurs si Kevin passait autant de temps à améliorer TIGCC qu'a fouiller yN ds ses moindres recoins pour faire affirmer sa propagande, TIGCC serais impeccable depuis longtemps ....

Bien vu !

Ah, parce que selon vous, je ne travaille pas sur TIGCC? Alors:
* c'est qui qui a porté le patch TIGCC vers GCC 3.3 au moins 2 mois avant la sortie officielle de ce dernier (ce n'est toujours pas sorti officiellement)?
* c'est qui qui a rajouté le support pour Fargo au nouveau linker?
etc.

C'est qui qui passe son temps à dégrader l'ambiance en rabachant sa vision des choses partout ?
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