Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation Assembleur 68K » kernel vs nostub ? (23 réponse(s))

./POST DE DEPART (post n°0) Marquer comme non lu.

Sasume

Ecrit le: Vendredi 20 août 2004 à 14:48

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Suite de la discussion qui a débuté dans le topic de limmt :

Lionel Debroux :
> Mais par exemple tichess prend plus de 30 ko et pourtant ça ne vous gêne pas.
Tu compare des choses qui ne sont pas comparables... On a ici un programme tout seul, pas un truc qui sert à en lancer d'autres

Le kernel ne prend que 6 ko je crois, c'est lui qui se charge de lancer les progs kernel. Le reste c'st du code partagé. C'est pour éviter de se retrouver avec plusieurs programmes de 30 ko justement.

- et qui doit se préoccuper de nombreux problèmes dus à des méthodes sales, son âge...

-> Il essaie de maintenir une compatibilité antérieure, c'est un avantage, non ?

> Mon post de base était que TIGCC 0.95 est loin de rendre obsolète le mode kernel puisqu'il ne permet pas de faire tout ce que fait le kernel, à moins de mettre l'équivalent d'un kernel en startup-code de chaque programme, mais c'est ridicule (bien que ce soit ce que vous avez déjà commencé à faire).
Comment ça, "ridicule" ? Le _nostub au sens strict n'a aucun intérêt, ça fait bien longtemps qu'on fait mieux (les features utiles du kernel - l'intérêt des libs dynamiques non natives n'est pas clair, l'anti-crash et surtout la protection des leaks de mémoire sont loin d'être indispensables - ça peut arriver à tout le monde de faire du code qui crashe, mais il est inadmissible qu'on fasse des leaks) tout en restant natif.

C'est une question de point de vue.
Tu préfères que tout ça soit inscrit dans du code de démarrage pour chacun de tes progs, plutôt que dans un seul programme.

./Post n°1 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 20 août 2004 à 15:30

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Le kernel ne prend que 6 ko je crois, c'est lui qui se charge de lancer les progs kernel. Le reste c'est du code partagé.
Oui.
> C'est pour éviter de se retrouver avec plusieurs programmes de 30 ko justement.
Tu exagères. Même si le gain en taille apporté par le shared-code est parfois indéniable (c'est un fait), il n'est pas important à ce point (c'est également un fait). Ca dépend énormément du contenu de chaque calculette, et de l'utilisation qu'en font les utilisateurs.
Peu de grosses routines sont communes à beaucoup de programmes. Je ne vois que les routines de grays et les routines "reinventing the wheel" de fichier de stdio.h, unknown.h (les horribles routines builtin AMS 2.xx), filelib, contre lesquelles je milite et que j'essaie - le temps me manque - d'enlever des programmes de TICT. Les libs kernel usuelles sont trop vastes, les gains de place (à nuancer par le fait que les accès - xxx.l relogé obligatoire - soient moins efficaces que les d(pc) ou d(an) habituellement utilisables en statique, surtout depuis TIGCC 0.95) ne compensent pas forcément les pertes (bouts de code inutilisés).

> > et qui doit se préoccuper de nombreux problèmes dus à des méthodes sales, son âge...
> -> Il essaie de maintenir une compatibilité antérieure, c'est un avantage, non ?
Oui et non. Ca peut être un avantage du point de vue utilisateur, mais c'est inefficace en taille et en vitesse de se préoccuper des saloperies faites par des inconscients, pour ne pas dire plus (utilisation de hacks tous plus sales les uns que les autres, non-respect des calling conventions, etc.).
Voir aussi la différence entre les Win9x/ME et les WinNT/2K/XP: les premiers ont un certain nombre de surcouches pour permettre l'utilisation de programmes DOS, que n'ont pas les seconds. On peut parfois s'en rendre compte dans l'utilisation quotidienne. Le debugger de TIEmu est particulièrement lent sur Win9x/ME, roms m'a expliqué que c'était à cause de nombreuses surcouches sur les fonctions graphiques utilisées, et qu'il n'y a rien à y faire...

> [deux posts sur l'existence de stubs]
> Tu préfères que tout ça soit inscrit dans du code de démarrage pour chacun de tes progs, plutôt que dans un seul programme.
Ce que je vois, c'est que les stubs des programmes AMS native prennent au plus quelques centaines d'octets (moins de 100 octets pour les programmes simples, quelques centaines d'octets pour les plus gros stubs qui sont ceux des plus gros programmes, qu'on ne peut pas mettre en nombre élevé sur une même calculette habituelle - = sans PedroM qui représente environ 0% des calculettes - c'est mathématique). Il faut donc un assez grand nombre de stubs des programmes AMS native avant d'approcher 10 KB de code (le kernel + quelques libs). Les stubs des programmes AMS native ne consomment jamais 4 KB de RAM - ce que consomme le kernel seul, et en permanence.
Je te l'accorde, depuis TIGCC 0.95 Beta 4, le stub est presque toujours ~130 octets trop gros, à cause du support quasi-systématique SET_FILE_IN_USE_BIT qui est presque toujours inutile. Je remodifie mes headers à chaque beta de TIGCC (suppression sur les fonctions de kbd.h, menus.h, dialogs.h, vat.h, unknown.h que j'utilise dans les programmes de TICT).

Lionel Debroux - membre de TICT.

./Post n°2 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 20 août 2004 à 16:19

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

À propos des libs dynamiques, il est évident que les vieilles lib du style filelib sont vraiment obsolètes et à éviter, mais les libs récentes comme genlib ou polysnd (je ne sais plus si geogeo a maintenu la version dynamique) sont vraiment intéressantes et apportent des gains de place pour les programmes les utilisant.
Mais le véritable avantage des libs dynamique n'est pas le gain de place qu'elles apportent (puisqu'il n'est pas toujours présent et que même lorsqu'il y est, il n'est pas vraiment grand) mais le fait qu'elles soient indépendantes des programmes qui les utilisent, donc on peut les optimiser, les débugger, et les améliorer sans avoir besoin de recompiler les programmes les utilisant (dans les cas où les sources du prog sont dispo...).
Bien sûr, cela implique une API (et une ABI) bien pensée pour ne pas entrainer de lourdeur dans la maintenance de la lib.

./Post n°3 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 20 août 2004 à 23:15

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Lionel, attention, au moins ERD_dialog utilise EV_eventLoop. Il faudra que je revérifie si ce sont tous les dialogues qui l'utilisent ou juste ceux avec des Requests et ERD_dialog.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°4 Marquer comme non lu.

Lionel Debroux

Ecrit le: Samedi 21 août 2004 à 10:22

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Mais le véritable avantage des libs dynamique n'est pas le gain de place qu'elles apportent (puisqu'il n'est pas toujours présent et que même lorsqu'il y est, il n'est pas vraiment grand) mais le fait qu'elles soient indépendantes des programmes qui les utilisent, donc on peut les optimiser, les débugger, et les améliorer sans avoir besoin de recompiler les programmes les utilisant (dans les cas où les sources du prog sont dispo...).
Voilà une position sage. Je préfère les discussions comme ça...
> Bien sûr, cela implique une API (et une ABI) bien pensée pour ne pas entrainer de lourdeur dans la maintenance de la lib.
C'est pour ça que je demandais une participation maximale de la communauté à une discussion sur une FlashApp contenant du shared-code utilisable en AMS native comme feature native d'AMS.

Les programmes de TICT ne sont pas vraiment censés utiliser ERD_dialog. S'ils l'utilisent, c'est qu'il y a un bug, donc de toute façon ça risque de crasher...

Lionel Debroux - membre de TICT.

./Post n°5 Marquer comme non lu.

Billy Charvet

Ecrit le: Jeudi 9 septembre 2004 à 10:07

Envoyer un message privé à Billy Charvet

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

C'est un débat duquel on ne peut pas sortir. Je ne présenterai qu'un argument:
comparez le nombre de problèmes que vous rencontrez avec les jeux NoStub et
ceux avec les jeux Kernel. Vous verrez tout de suite ce qui est le plus stable, le
moins compliqué et convient donc le mieux à tous les utilisateurs -> NoStub.

Ensuite, si on reproche au NoStub le fait d'être du code statique avec de lourdes
fonctions de tigcc.a, et bien programmez en assembleur, et vous obtiendrez les programmes
les plus légers. Ou bien fabriquez une version DLL Nostub de TIGCC Library.
(Ca existe déjà au fait ?)

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°6 Marquer comme non lu.

Folco

Ecrit le: Jeudi 9 septembre 2004 à 12:42

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Billy Charvet :
C'est un débat duquel on ne peut pas sortir. Je ne présenterai qu'un argument:
comparez le nombre de problèmes que vous rencontrez avec les jeux NoStub et
ceux avec les jeux Kernel. Vous verrez tout de suite ce qui est le plus stable, le
moins compliqué et convient donc le mieux à tous les utilisateurs -> NoStub.

Franchement, si le problème était si simple, tout le monde serait d'accord. Ca veut donc dire que tu n'a pas du cerner le problème, ou que tu le prends avec mauvaise foi.

Sasume-> Tu disais d'éviter filelib, pourquoi? C'est très vieux, certes, mais quoi prendre à la place alors??

Lionel-> Y a-t-il un topic sur cette app de shared-code, je serais très intéressé, merci

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°7 Marquer comme non lu.

Billy Charvet

Ecrit le: Jeudi 9 septembre 2004 à 14:06

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

*Franchement, si le problème était si simple, tout le monde serait d'accord. Ca veut donc dire que tu n'a pas du cerner le problème, ou que tu le prends avec mauvaise foi.*

Je ne m'attendais pas à me faire casser dès le post suivant. D'où le
"C'est un débat duquel on ne peut pas sortir".

Je ne poste plus dans ce topic, c'est un topic débile qui ne peut servir qu'à se troller,
et j'en ai pas la moindre envie, en tant qu'administrateur.

PS: NOSTUUUUUUUUUUUUUUUUUUUUB !!!!!!!!!

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°8 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 9 septembre 2004 à 16:59

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Martial Demolins>
1) Utilise les ROM_CALLs à la place de filelib
2) Il y a un topic ici (mais c'est parti en couille...) : http://pub26.ezboard.com/ftichessteamhqfrm13.showMessage?topicID=544.topic

./Post n°9 Marquer comme non lu.

Folco

Ecrit le: Jeudi 9 septembre 2004 à 18:28

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, merci sasume !!

Les RomCalls, je m'en doutais que je devrais bien passer par là, mais filelib est si simple... c'est dommage mais tant pis.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°10 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 9 septembre 2004 à 21:36

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

filelib n'apporte strictement rien par rapport à vat.h, je ne vois pas en quoi elle serait "plus simple".

./Post n°11 Marquer comme non lu.

Folco

Ecrit le: Vendredi 10 septembre 2004 à 13:27

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

lol, on balance juste un handle , et filelib fait l'opération demandée

Avec le TIOS, c'est moins facile, il faut faire plusieur opérations pour avoir un résultat de filelib.
-Edité le Vendredi 10 septembre 2004 à 13:41 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°12 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 11 septembre 2004 à 02:26

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

N'importe quoi, tu lui balances juste un HSym (ou même un SYM_NAME dans certains cas) et AMS fait l'opération demandée! Le système de filelib est loin d'être plus simple. Les paramètres pris par filelib sont en général exactement équivalents à HSym (elle veut folder et index, c'est exactement ce que contient un HSym). Et en plus c'est une librairie boguée dans tous les sens.
-Edité le Samedi 11 septembre 2004 à 02:29 par Kevin Kofler-

./Post n°13 Marquer comme non lu.

Folco

Ecrit le: Samedi 11 septembre 2004 à 02:36

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ah, PpHd ne la maintiens pas?

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°14 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 11 septembre 2004 à 02:37

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Oui, mais vu le nombre de bogues qu'elle avait, ça m'étonnerait qu'il n'y en ait plus.

./Post n°15 Marquer comme non lu.

Folco

Ecrit le: Samedi 11 septembre 2004 à 04:07

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, je lui demanderai ou en est cette lib.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°16 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 11 septembre 2004 à 10:20

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Mais pourquoi ne pas tout simplement arrêter d'utiliser cette lib redondante qui ne fait que wrapper ou réimplémenter des ROM_CALLs?

./Post n°17 Marquer comme non lu.

Sasume

Ecrit le: Samedi 11 septembre 2004 à 10:44

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Parce que son API est confortable ?
Je viens de regarder rapidement son code, et effectivement, il semblerait qu'on pourrait gagner un peu de place sur cette lib si elle ne réimplémentait pas de ROM_CALLs.
Je vais peut-être faire ça si j'ai du temps libre...

./Post n°18 Marquer comme non lu.

Folco

Ecrit le: Samedi 11 septembre 2004 à 15:03

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

merci sasume #love#

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°19 Marquer comme non lu.

Sasume

Ecrit le: Samedi 11 septembre 2004 à 22:54