TI-GCC Format des fichiers .a - Page 3

guigui17
a écrit : D'accord, un nosub prend plus de place qu'un kernel

Pas nécessairement. Le format kernel a besoin d'un stub et d'un header qui prennent de la place. Et il ne faut pas oublier de compter la taille du kernel et des librairies, qui font partie de la place requise par un programme pour kernel.

car il faut tout reprogrammer.

Non!
Il y a:
- les ROM_CALLs! Malgré le fait que TIGCCLIB a déjà éclairci le fait que presque toutes les fonctions dont un programmeur peut avoir besoin sont déjà dans la ROM en janvier 2000, même maintenant, beaucoup de personnes sous-estiment encore leur potentiel.
- les librairies statiques, qui contiennent presque toutes les fonctions dont on pourrait avoir besoin et qui manquent dans AMS. Et contrairement à ce que la propagande en faveur des librairies dynamiques proclame, les librairies statiques ne font pas perdre de la place, mais au contraire en économisent, parce que seules les fonctions réellement utilisées devront être transférées sur la calculatrice. Les défenseurs des librairies dynamiques oublient toujours de compter la taille de ces librairies dynamiques (avec toutes leurs fonctions non utilisées qui traînent dans la mémoire et gaspillent de la place) lorsqu'ils calculent la taille des programmes.

Par contre, pas besoin de kernel qui font plus planter les caltos qu'autre chose.

Le grand avantage.

Le mieux, ce serait d'offrir les 2 possibilités: kernel et nosub, comme TIGCC

L'idéal pour une nouvelle ROM est d'offrir les 2 modes, pour des raisons de compatibilité.
En revanche, l'idéal pour un nouveau logiciel de développement serait de n'offrir que le _nostub. Le mode kernel est une vieille technologie dépassée, et il faudrait enfin penser à le retirer de la circulation.

Perso, je préfère le nosub, désolé pour ceux qui n'aiment pas

Pim89 a écrit :
erf. non, sans rire, on dit que les progs kernels plantent, mais c'est juste car certain sont programmé en ASM pur et que les bugs sont plus dur à corriger.

Ce n'est pas la seule raison. Essaye de faire planter AutoClBr pour voir si tu y arrives. (C'est de l'assembleur, mais en _nostub.)

Mais un prog kernel en C/ASM bien programmé et le même prog nostub, ça sera la même chose au niveau des plantages !

À condition que le kernel ne soit pas bogué, oui.
Mais on introduit un logiciel en plus (souvent codé en assembleur d'ailleurs), et il y a toujours le risque d'un bogue dans un logiciel. D'où un risque de bogues et donc de plantages plus grand en mode kernel.
Et souvent un programme pour kernel ne sera pas codé de la même façon qu'un programme _nostub. Il aura tendance d'utiliser des librairies dynamiques codées de manière sale, ou des RAM_CALLs permettant l'accès de manière sale (trop directe) à des structures internes de AMS, comme la table des handles ou la VAT. Le programme _nostub, lui, aura tendance d'utiliser des ROM_CALLs officiels comme HeapDeref, ou comme les fonctions de vat.h pour l'accès aux fichiers, à la place, ce qui le rendra bien plus stable.

je resterais quand meme toujours sur ma position d'anti-nostub et de pro-kernel...

je vois vraiement pas ce ke peux vous posser les kernel comme probleme !
Les derniers né comme préos sont hyper stable, et si c le fait de lancer le progs apres chaque reset(ossi rare soit-il) vous avez ca utiliser auto-inst....

J'ai toujours tt les libs necessaire sur ma calc, et je les aurais toujours....deja que nos calc ne possedent pas une mémoire hors du commun, autent l'économiser le plus possible !!(Runc et libs compréssé pour moi)

Alors voila, je suis kerneleux, et je resterais kerneleux....


PpHd si tu as besoin de béta-tester ta rom, je suis volontaire, sur une vraie calc...si jamais il faut.....

Je n'ai jamais dit que je DETESTAIS le kernel. d'ailleur, j'ai Pros 0.56 et je le trouve vraiment sympa!
Vous voulez une critique sur le nosub: on peut pas appeler de Libs. Il faut donc tout reprogrammer à chaque fois! et au lieu d'avoir un petit prog de rien du tout, on arrive facilent au Ko

Content Squale92?

Etant donné qu'il est plus facile de programmé kernel (moin chiant et tout plein de fonctions existent déjà!) c pour cela (peut être) qu'il y a plus de prog kernel mal programmé que de nosub mal programmé.

Les newbies sont plus tentés par le kernel que par le nosub!

De toute facon, on peut faire EXACTEMENT la même chose dans les deux cas!

iceman a écrit :
je vois vraiement pas ce ke peux vous posser les kernel comme probleme ! Les derniers né comme préos sont hyper stable,

Est-ce que tu peux le prouver?

et si c le fait de lancer le progs apres chaque reset(ossi rare soit-il) vous avez ca utiliser auto-inst....

Et les malchanceux qui ont une V200 et qui ne peuvent pas patcher leur AMS, ils font quoi?
Et puis tout le monde n'a pas forcément envie de patcher son AMS.

J'ai toujours tt les libs necessaire sur ma calc, et je les aurais toujours....deja que nos calc ne possedent pas une mémoire hors du commun, autent l'économiser le plus possible !!

Tu viens de donner la raison pour laquelle je n'ai pas envie d'avoir toutes les librairies dynamiques possibles et imaginables sur ma calculatrice justement.
Arrête de te contredire!

Alors voila, je suis kerneleux, et je resterais kerneleux....

Argument très objectif...
Alors voila, je suis nostubien, et je resterai nostubien....

guigui17
a écrit : Je n'ai jamais dit que je DETESTAIS le kernel. d'ailleur, j'ai Pros 0.56 et je le trouve vraiment sympa!

Moi aussi, j'ai PreOs. Je le trouve sympa parce que:
- il sait lancer TICT Explorer avec SHIFT+ON (c'est moi qui ai codé ça d'ailleurs)
- il fournit un anti-crash pour les programmes _nostub (donc fini l'argument que le _nostub ne permet pas l'anticrash; la plupart des améliorations de l'anticrash _nostub de PreOs par rapport à sa première version sont d'ailleurs de moi)
- la fonction la moins importante, mais intéressante quand-même: il permet de lancer les vieux programmes au format DoorsOS (émulation Fargo, aussi appelée parfois "mode kernel")

Vous voulez une critique sur le nosub: on peut pas appeler de Libs.

Si, on peut appeler des librairies statiques! Et cela indépendamment du langage utilisé (assembleur ou C).
Et si vraiment on a besoin de librairies dynamiques (à cause de la limite de 64 KO), c'est également possible (cf. FAT Engine, et cf. les versions récentes de TIGCC).

Il faut donc tout reprogrammer à chaque fois!

Non!!!
Il y a les ROM_CALLs et les librairies statiques!!!
Lis la documentation de TIGCC, et si tu programmes en assembleur, lis aussi ce tutorial.

et au lieu d'avoir un petit prog de rien du tout, on arrive facilent au Ko

Déjà, 1 KO, ce n'est pas beaucoup. Et ensuite, tu n'utilises probablement pas assez les ROM_CALLs. (Il fait quoi ton "petit prog de rien du tout" qui prend 1 KO?)

guigui17
a écrit : Etant donné qu'il est plus facile de programmé kernel (moin chiant et tout plein de fonctions existent déjà!) c pour cela (peut être) qu'il y a plus de prog kernel mal programmé que de nosub mal programmé.

Je ne trouve pas que c'est plus facile de programmer kernel, c'est juste que beaucoup de tutoriaux assembleur sont écrits pour Fargo ou pour kernel, et c'est pour ça que les newbies en assembleur apprennent souvent le mode kernel en premier.
Et je ne pense pas vraiment que ce qui fait que les programmes kernel sont souvent mal programmés est le niveau des programmeurs kernel. Je pense plutôt que ce sont les interfaces sales proposées par les kernels. Par exemple:
- doorsos::Heap. HeapDeref, c'est pour les chiens?
- doorsos::FolderListHandle, doorsos::MainHandle. Il y a des ROM_CALLs (cf. vat.h) qui permettent l'accès aux variables sans aller traffiquer directement dans la VAT!
- doorsos::font_medium. DrawStr (et DrawChar), c'est pour les chiens?
etc.

je ne me contredit pas !!
j'ais pas toutes les libs, j'ai celle qui me sont necessaire !!!!

et puis avec runc cela prend quasiement rien comme place !!!!

Tu oublie runc ?!
et runcc ?!

> doorsos::Heap. HeapDeref, c'est pour les chiens?
... ou pour les progs qui n'ont pas besoin d'avoir des handles non lockés et une vitesse suffisamment élevée quand même

> doorsos::FolderListHandle, doorsos::MainHandle. Il y a des ROM_CALLs (cf. vat.h) qui permettent l'accès aux variables sans aller traffiquer directement dans la VAT!
Entièrement d'accord pour le coup, mais il s'agit plus du portage des vieux progs AMS1-only pour supporter tous les AMS...

> doorsos::font_medium. DrawStr (et DrawChar), c'est pour les chiens?
... ou pour les progs qui doivent être un tant soit peu rapide. Si tous les viewers de texte utilisaient DrawStr, bonjour la fluidité

Dernière chose. Voila peut être quelques raisons qui me font préférer le nosub:

- J'ai commencer à apprendre à programmer en nosub. De plus, j'ai appris avec CC et AS, donc nosub obligatoire!
- en ce qui concerne les jeux, j'ai la malchance de tomber sur plus de kernel qui plantaient que de nosub qui plantaient (aurai-je eu moi de bol que d'autres?)
- En kernel, j'ai commencé avec DoorOs 0.98 et 0.99. Je peut vous dire que ce m'a dégouté car pour moi, ca m'a fait faire quelques reset! Mais bon, avec Preos, ca va mieux!
- En clair, aurai-je été plus déçus par le kenel que par le nosub?

guigui17
a écrit : - J'ai commencer à apprendre à programmer en nosub. De plus, j'ai appris avec CC et AS, donc nosub obligatoire!

Moi, j'ai commencé en kernel (avec un seul petit programme: RUNPROG I), mais après je me suis lancé dans la programmation de TSRs, et là, _nostub obligatoire. Et je me suis rendu compte que le _nostub est tout aussi simple à programmer que le mode kernel, et bien plus pratique pour l'utilisateur. Et j'ai complètement abandonné le mode kernel (RUNPROG II, qui remplace RUNPROG I, est aussi en _nostub).

- en ce qui concerne les jeux, j'ai la malchance de tomber sur plus de kernel qui plantaient que de nosub qui plantaient (aurai-je eu moi de bol que d'autres?)

Non, c'est de la pure statistique. Les jeux pour kernel sont en général moins stables que les jeux _nostub, donc à moins d'avoir une chance énorme avec les jeux pour kernel et une malchance énorme avec les jeux _nostub, on remarquera la même chose que toi.

- En kernel, j'ai commencé avec DoorOs 0.98 et 0.99. Je peut vous dire que ce m'a dégouté car pour moi, ca m'a fait faire quelques reset! Mais bon, avec Preos, ca va mieux!

DoorsOS n'est même pas le pire. Le premier kernel que j'avais essayé d'installer, moi, était PlusShell 1.0 alpha. Résultat: plantage complet, aucune combinaison de reset ne marchait, obligé de retirer les 4 piles AAA et la pile de sauvegarde. Et tout cela alors que c'était une HW1 et que j'avais AMS 1.00, donc la plateforme prévue pour PlusShell. Après le reset, j'ai installé DoorsOS (I) 0.90 beta, et là, je n'avais "que" un plantage tous les 3 jours. Et ceci sur AMS 1, sans récupération de la mémoire archive! Je me suis donc souvent retrouvé avec tout effacé. Et tout par la faute des kernels et des programmes pour kernel...

vas y dit que driver est po stable

Eh oui, nous avons réussi à découvrir la vérité : tout petit déjà, il avait été la victime des plantages de 2 kernels, et, l'effet de cette névrose (couplée bien sûr au complexe d'Oedipe) lui a fait perdre la raison et vouer une haine incommensurable à tout ce qui ressemblait de près ou de loin à un kernel. Depuis, on le retrouve en train d'errer sur des forums, racontant toujours je ne sais quels bobards aux malheureux passants

perso, mon premier kernel a été doorsOS...
je l'utilisais sous ROM2.05, alors que c'était une version pas encore compatible...
cela dit, déjà avec cette version incompatible en partie, ça m'empéchait pas mal de bugs...
puis je suis passé à UniOS, encore plus stable, et encore moins de plantages...
puis, depuis que PreOS existe, à PreOS... et je ne suis pas du tout déçu !

Pollux a écrit :

Pourquoi Kevin déteste-t-il le nostub? Le mystère enfin élucidé

Déjà, c'est le mode kernel que je déteste, pas le _nostub.
Et enfin: les mauvaises expériences avec PlusShell et DoorsOS ne m'ont certainement pas fait aimer les kernels, mais ce n'est pas que pour ça que je n'aime pas le mode kernel. C'est aussi parce que c'est totalement illogique de ne pas pouvoir lancer un programme assembleur ou C comme un programme BASIC (c'est-à-dire: nom du programme, [(], [)], [ENTER], sans avoir à installer quoi que ce soit avant).


En ce qui concerne PreOs, il est mieux que les autres kernels surtout pour une raison: un programme ne doit pas nécessairement être au format DoorsOS pour tirer avantage de ses services (anticrash, possibilité de lancer un shell avec SHIFT+ON, ...). D'ailleurs, c'est en partie grâce à moi que c'est comme ça: J'ai écrit quelques routines pour PreOs, et, sauf une (calcul du RAM_CALL ROM_VERSION, que j'ai contribuée parce que je l'avais déjà écrite bien avant afin de pouvoir plus facilement porter des programmes kernel vers le _nostub), elles sont toutes dans ce domaine.

>> (...) ROM_VERSION, que j'ai contribuée parce que (...)

On dit "auquel j'ai contribué"

ou alors :

"que j'ai contribué à coder"

Bah moi j'ai eu Doorsos 0.99 sur ma calc (AMS 2.05) et HW2patch (installé en ROM ), bah il plantait pas trop encore, jusqu'au jour où j'ai enlevé une pile pour voir, et là crash de HW2patch, ça m'a saoulé, j'ai reflashé (j'avais ma TI depuis 2 semaines ), et pis j'ai mis UniOS comme kernel.
Puis j'ai arrêté de jouer sur TI car je me suis mis à bcp coder en BASIC d'abord, puis C ensuite, et je n'avais plus le temps (sauf qq fois en Bio). Bref, pas besoin des 11 Ko en RAM de UniOS, et un jour, après un crash (mes pile étaient trop faibles en cours de Bio, crash devant le prof , je passais pas pour un con à virer mes piles devant lui ), je n'ai rien réinstallé. J'ai du mettre qq jeu nostub comme Queue et Pheonix, et pis c'est tout.

Donc à part HW2patch et Doorsos sur ASM 2.05, rien dans les progs "kernel" et kernels eux même ne m'ont jamais vraiment embetté. J'ai tout viré plus part non-nécessité que par contrainte.

>Tu n'es pas obligé de tester quoi que ce soit! Tu dis juste que c'est supporté en théorie,
>mais que les programmes peuvent planter.
Je ne suis pas convaincu.

>>Et les variables systemes ?
>Si elles ne sont pas supportées, tu les pointe vers un endroit qui est totalement
>ignoré et tu le mets à 0 avant de lancer les programmes _nostub.
Pour top_estack, ok.
Et pour FirstWIn ?

>C'est une tentative de chantage, ça!
Non. Vu le peu de RomCalls qu'il y aura, faire des libs dynamiques sera une tres bonne
chose.

>Bon, si ta PreRom sort vraiment et si des gens sont suffisamment bêtes pour l'utiliser,
>quelqu'un (moi?) compilera ttstart en kernel. Ça permettra d'utiliser les programmes
>_nostub. Et pour la table en $c8, tu seras bien obligé de la mettre même pour les
>programmes kernel, parce que TIGCC l'utilise.
Tiens un dump de PreRom : $c8 = $0

>Et d'ailleurs, ton argument est faux: TIGCCLIB utilise des ROM_CALLs par la table
>en $c8 même en mode kernel, donc il n'y a aucun moyen de savoir si le programme
>n'utilise pas une fonction de TIGCCLIB qui appelle un ROM_CALL non supporté.
Certes. Mais ca vaut mieux que supporte les progs nostub directement.
Et puis avec votre proprogande, les progs tigcclib en kernel sont tres rare.
Surtout ceux en kernel necessitant un appel indirect par l'interieur d'une lib statique.

>Et je te signale aussi qu'un programme pour kernel peut aussi utiliser USE_FLINE_ROM_CALLS.
FLINE_... ne sera pas supporte par PreRom. Du moins au debut.
Ensuite je verrais.

>D'ailleurs, si tout le monde suit ton conseil (pas très intelligent d'ailleurs)
>d'abandonner la compatibilité avec tous les kernels sauf PreOs, tous les
>nouveaux programmes pour kernel (s'il y en a ) utiliseront des ROM_CALLs par
>ligne F parce que ça économise plein de place.
Si tu le dis. Mais je conseilles quand meme jsr tios::machin.

>Donc ton excuse est complètement bidon: même avec un programme pour kernel,
> il n'y a aucun moyen de savoir de manière certaine quels ROM_CALLs il utilise!
Si : un PROGRAMME KERNEL BIEN PROGRAMMER NE FAIT DES APPELS QUE PAR jsr tios::machintruc.
SINON c'est un programme sale.

>GTools et PreRom risque de sortir en meme temps....ca ca me fera super bien rire,
> le match du siecle !!
GTools vainqueur. Mon but est d'ecrire une rom minimaliste supportant les progs kernels.
C'est tout.

>Pas nécessairement. Le format kernel a besoin d'un stub et d'un header
>qui prennent de la place. Et il ne faut pas oublier de compter la taille
>du kernel et des librairies, qui font partie de la place requise par un
>programme pour kernel.
Mais pour plusieurs programmes partageant la meme librarie, on ECONOMISE de
la place. L'exemple le plus flagrant est les grayscale.
10 programmes l'utilisant = 10 * 1K de mem archive gaspille.
Contre 5K (Et encore 3.5K pour certains) de kernel + 2.5K de graphlib.
Et on peut meme compresser les programmes archives.

>- les ROM_CALLs! Malgré le fait que TIGCCLIB a déjà éclairci le fait que presque
>toutes les fonctions dont un programmeur peut avoir besoin sont déjà dans la ROM
>en janvier 2000, même maintenant, beaucoup de personnes sous-estiment
>encore leur potentiel.
Et qui sont chiantes a reprogrammer pour PreRom
Heureusement qu'il y a des programmes utilisant des libs, qui me feront pas chier.

>- les librairies statiques, qui contiennent presque toutes les fonctions
>dont on pourrait avoir besoin et qui manquent dans AMS. Et contrairement à ce que
> la propagande en faveur des librairies dynamiques proclame, les librairies statiques
> ne font pas perdre de la place, mais au contraire en économisent, parce que seules
>les fonctions réellement utilisées devront être transférées sur la calculatrice.

>Les défenseurs des librairies dynamiques oublient toujours de compter la taille de
>ces librairies dynamiques (avec toutes leurs fonctions non utilisées qui traînent
>dans la mémoire et gaspillent de la place) lorsqu'ils calculent la taille des programmes.
Et toi tu oublies toujours de compter le nombre de fois ou plusieurs programmes utilisent
ces libraries.
Pour UN programme, je suis d'accord.
Mais ca m'etonnerait qu'un utilisateur ne possede qu'UN SEUL programme.

10 programmes l'utilisant = 10 * 1K de mem archive gaspille.
Contre 5K (Et encore 3.5K pour certains) de kernel + 2.5K de graphlib.
Et on peut meme compresser les programmes archives.
Et ca ne compte pas l'anti-crash, et la gestion des libs des kernels.

>Par contre, pas besoin de kernel qui font plus planter les caltos qu'autre chose.
Avec Preos, c'est plutot le contraire.
Heureusement qu'il est la pour recuperer les crashs


>L'idéal pour une nouvelle ROM est d'offrir les 2 modes, pour des raisons de compatibilité.
Je ne prends que la technologie la plus evoluee.

>En revanche, l'idéal pour un nouveau logiciel de développement serait de n'offrir que
>le _nostub.
A quand pour Tigcc ?

>Le mode kernel est une vieille technologie dépassée, et il faudrait enfin penser
>à le retirer de la circulation.
J'hallucine grave.
Retourne a la prehistoire la.

>Perso, je préfère le nosub, désolé pour ceux qui n'aiment pas
Perso, je préfère le kernel, et j'emmerde ceux qui n'aiment pas mon avis.

>non, sans rire, on dit que les progs kernels plantent,
Forcement. Les progs kernels qui plantent sont ceux qui censes tourner que sur AMS 1.00.
C'est deja un EXPLOIT de les faire tourner sur AMS 2.0x !

>Mais un prog kernel en C/ASM bien programmé et le même prog nostub,
>ça sera la même chose au niveau des plantages !
Non. Le kernel intercepte certains crashs

>À condition que le kernel ne soit pas bogué, oui.
>Mais on introduit un logiciel en plus (souvent codé en assembleur d'ailleurs),
Tu sous-entends que l'assembleur est plus proprice a la proliferation de bogues ?

> et il y a toujours le risque d'un bogue dans un logiciel.
>D'où un risque de bogues et donc de plantages plus grand en mode kernel.
Moui, mais tu oublies le systeme anti-crash.

>Et souvent un programme pour kernel ne sera pas codé de la même façon qu'un programme
>_nostub. Il aura tendance d'utiliser des librairies dynamiques codées de manière sale,
>ou des RAM_CALLs permettant l'accès de manière sale (trop directe) à des structures
>internes de AMS, comme la table des handles ou la VAT.
La VAT et la Heap Table sont des structures parfaitement connus et saines.

>Le programme _nostub, lui, aura
>tendance d'utiliser des ROM_CALLs officiels comme HeapDeref, ou comme les
>fonctions de vat.h pour l'accès aux fichiers, à la place, ce qui le rendra
>bien plus stable.
Des exemples ?

>J'ai toujours tt les libs necessaire sur ma calc, et je les aurais toujours....
>deja que nos calc ne possedent pas une mémoire hors du commun,
>autant l'économiser le plus possible !!(Runc et libs compréssé pour moi)
Tu seras content de Preos 0.60 toi alors

>PpHd si tu as besoin de béta-tester ta rom, je suis volontaire, sur une vraie calc...si jamais il faut.....
Attend que la TIB fonctionne bien sur emu d'abord



>Et les malchanceux qui ont une V200 et qui ne peuvent pas patcher leur AMS, ils font quoi?
>Et puis tout le monde n'a pas forcément envie de patcher son AMS.
Ben ils patchent leur programme kernel avec mon AutoPreosPatcher
qui patche le header des progs kernels pour mettre l'auto-install de preos

>Tu viens de donner la raison pour laquelle je n'ai pas envie d'avoir toutes
> les librairies dynamiques possibles et imaginables sur ma calculatrice justement.
>Arrête de te contredire!
Pourtant c'est presque le cas (filelib/genlib/genalib/genclib/graphlib/userlib/ziplib/pk92lib/brwselib/ugplib/fargray/gray4lib/gray7lib/util/triglib/linelib/hufflib/hexlib sont dans ta calc -si tu as stdlib standard de preos 0.59-).

Et en plus, avec les libs dynamiques compressees, elles ne prennent plus rien comme place.

>Argument très objectif...
>Alors voila, je suis nostubien, et je resterai nostubien....
La c'est bien. Enfin quelque chose d'objectif.

>Moi aussi, j'ai PreOs. Je le trouve sympa parce que:
>- il sait lancer TICT Explorer avec SHIFT+ON (c'est moi qui ai codé ça d'ailleurs)

>- il fournit un anti-crash pour les programmes _nostub (donc fini l'argument que le
> _nostub ne permet pas l'anticrash; la plupart des améliorations de l'anticrash _nostub
> de PreOs par rapport à sa première version sont d'ailleurs de moi)
Mais il faut un kernel pour ca !
Et aussi d'Extended

>- la fonction la moins importante, mais intéressante quand-même: il permet de lancer
>les vieux programmes au format DoorsOS (émulation Fargo, aussi appelée
>parfois "mode kernel")


>Si, on peut appeler des librairies statiques! Et cela indépendamment du langage utilisé
>(assembleur ou C).
>Et si vraiment on a besoin de librairies dynamiques (à cause de la limite de 64 KO),
> c'est également possible (cf. FAT Engine, et cf. les versions récentes de TIGCC).
Mais bien plus complique. Et on NE PEUT PAS faire d'appel croise, pour vraiment
supporte les 128 K. alors qu'en kernel, en plus d'etre possible, c'est simple et QUASI-TRANSPARENT au niveau du code !
Et les kernels, la limite c'est la RAM maximale


>Il y a les ROM_CALLs et les librairies statiques!!!
>Lis la documentation de TIGCC, et si tu programmes en assembleur, lis aussi ce tutorial.
Mais les libs statiques prennent de la place dans le programme, place qui est gaspillee si plusieurs programmes les utilisent ! Et en plus, en cas de buggues il faut :
+ remettre a jour tous les programmes.
+ retransferer tous les programmes.


>et au lieu d'avoir un petit prog de rien du tout, on arrive facilent au Ko
Certes, mais le coefficient de la pente est bien plus faible.


>Je ne trouve pas que c'est plus facile de programmer kernel, c'est juste que beaucoup
>de tutoriaux assembleur sont écrits pour Fargo ou pour kernel, et c'est pour ça
>que les newbies en assembleur apprennent souvent le mode kernel en premier.

(1) jsr tios::ngetchx

Contre :

(2) move.l $C8,a0
move.l ngetchx*4(a0),a0
jsr (a0)

Je preferes le (1) plus elegant (Meme s'il y a une macro le faisant, ok).

>Et je ne pense pas vraiment que ce qui fait que les programmes kernel sont
>souvent mal programmés est le niveau des programmeurs kernel.
>Je pense plutôt que ce sont les interfaces sales proposées par les kernels.
>Par exemple:
>- doorsos::Heap. HeapDeref, c'est pour les chiens?
>- doorsos::FolderListHandle, doorsos::MainHandle.
>Il y a des ROM_CALLs (cf. vat.h) qui permettent l'accès aux variables
>sans aller traffiquer directement dans la VAT!
Si meme avec les romcalls, tu es obbliges de trafiquer dans la vat.
Sinon comment lire un handle ?

>- doorsos::font_medium. DrawStr (et DrawChar), c'est pour les chiens?
C'est fait pour afficher plus vite, ca prendre de la place pour une autre fonte.

Tous tes exemples sont des structures kernels qui marchent PARFAITEMENT !
Et qui n'entrainent aucun bogue.


>Non, c'est de la pure statistique. Les jeux pour kernel sont en général moins stables
>que les jeux _nostub, donc à moins d'avoir une chance énorme avec les jeux pour kernel
>et une malchance énorme avec les jeux _nostub, on remarquera la même chose que toi.
Les jeux kernels sont developpes pour AMS 1.00.
S'ils arrivent a tourner sur AMS 2.0x, c'est grace a la puissance de la technologie des kernels.
Et les jeux _nostub : 80 % a jeter direct Et le reste

>DoorsOS n'est même pas le pire. Le premier kernel que j'avais essayé d'installer,
>moi, était PlusShell 1.0 alpha. Résultat: plantage complet, aucune combinaison de
>reset ne marchait, obligé de retirer les 4 piles AAA et la pile de sauvegarde.
>Et tout cela alors que c'était une HW1 et que j'avais AMS 1.00, donc la plateforme
>prévue pour PlusShell.
??? Tiens. Remarque j'ai une idee du pourquoi.

>Après le reset, j'ai installé DoorsOS (I) 0.90 beta, et là, je n'avais "que" un plantage
>tous les 3 jours. Et ceci sur AMS 1, sans récupération de la mémoire archive!
>Je me suis donc souvent retrouvé avec tout effacé.
>Et tout par la faute des kernels et des programmes pour kernel...
Condoleances.

>Eh oui, nous avons réussi à découvrir la vérité : tout petit déjà, il avait été la
>victime des plantages de 2 kernels, et, l'effet de cette névrose (couplée bien sûr
>au complexe d'Oedipe) lui a fait perdre la raison et vouer une haine incommensurable à
>tout ce qui ressemblait de près ou de loin à un kernel. Depuis, on le retrouve en
>train d'errer sur des forums, racontant toujours je ne sais quels bobards aux
>malheureux passants



>Et enfin: les mauvaises expériences avec PlusShell et DoorsOS ne m'ont certainement
>pas fait aimer les kernels, mais ce n'est pas que pour ça que je n'aime pas le mode
>kernel. C'est aussi parce que c'est totalement illogique de ne pas pouvoir lancer
>un programme assembleur ou C comme un programme BASIC (c'est-à-dire: nom du programme,
>[(], [)], [ENTER], sans avoir à installer quoi que ce soit avant).
Tu connais l'auto-installation de preos 0.60. Elle est faite pour toi
Tu peux taper :
nom du programme, [(], [)], [ENTER], sans avoir à installer quoi que ce soit avant
Et ca marche ! C'est dingue hein

>En ce qui concerne PreOs, il est mieux que les autres kernels surtout pour une raison:
>un programme ne doit pas nécessairement être au format DoorsOS pour tirer avantage de ses
>services (anticrash, possibilité de lancer un shell avec SHIFT+ON, ...). D'ailleurs,
>c'est en partie grâce à moi que c'est comme ça: J'ai écrit quelques routines pour PreOs,
>et, sauf une (calcul du RAM_CALL ROM_VERSION, que j'ai contribuée parce que je l'avais
>déjà écrite bien avant afin de pouvoir plus facilement porter des programmes kernel vers
>le _nostub), elles sont toutes dans ce domaine.
Et je t'en remercie.

Wouaaaah t'es méchant PpHd ! imagine le boulot que va avoir Kevin pour contre-argumenter tout ça !!

Bon, début de réponse:

PpHd a écrit :
>Tu n'es pas obligé de tester quoi que ce soit! Tu dis juste que c'est supporté en théorie,
>mais que les programmes peuvent planter.
Je ne suis pas convaincu.

>>Et les variables systemes ?
>Si elles ne sont pas supportées, tu les pointe vers un endroit qui est totalement
>ignoré et tu le mets à 0 avant de lancer les programmes _nostub.
Pour top_estack, ok. Et pour FirstWIn ?

Ben, pour les ROM_CALLs qui sont des pointeurs vers des pointeurs, tu les pointes vers (par exemple) $4xxxxxx et à $4xxxxxx, il y a écrit $4yyyyyy, qui est l'adresse bidon qui ne contient que des 0s. Ce n'est pas si dur que ça.

>C'est une tentative de chantage, ça!
Non. Vu le peu de RomCalls qu'il y aura, faire des libs dynamiques sera une tres bonne chose.

Vu le peu de RomCalls qu'il y aura, ta ROM ne servira pas à grand chose. (C'est ce que je dis dès le début. Je savais bien qu'il n'allait pas y avoir grand chose comme ROM_CALLs.) Désolé.

>Bon, si ta PreRom sort vraiment et si des gens sont suffisamment bêtes pour l'utiliser,
>quelqu'un (moi?) compilera ttstart en kernel. Ça permettra d'utiliser les programmes
>_nostub. Et pour la table en $c8, tu seras bien obligé de la mettre même pour les
>programmes kernel, parce que TIGCC l'utilise.
Tiens un dump de PreRom : $c8 = $0

Bon, il va falloir qu'on fasse la table nous-mêmes alors. Sauf si elle traîne quelque part dans ta ROM. Sinon, aucun programme en C ne pourra tourner sur ta ROM.

>Et d'ailleurs, ton argument est faux: TIGCCLIB utilise des ROM_CALLs par la table
>en $c8 même en mode kernel, donc il n'y a aucun moyen de savoir si le programme
>n'utilise pas une fonction de TIGCCLIB qui appelle un ROM_CALL non supporté.
Certes. Mais ca vaut mieux que supporte les progs nostub directement.
Et puis avec votre proprogande, les progs tigcclib en kernel sont tres rare. Surtout ceux en kernel necessitant un appel indirect par l'interieur d'une lib statique.

Il n'y a pas que les librairies statiques. tipatch.lib utilise aussi $c8.
Et il n'y a pas beaucoup de programmes en C qui n'utilisent pas au moins une fonction de TIGCCLIB, et elles utilisent presque tous $c8.
Donc je répète: aucun programme en C ne pourra tourner sous PreRom.

>D'ailleurs, si tout le monde suit ton conseil (pas très intelligent d'ailleurs)
>d'abandonner la compatibilité avec tous les kernels sauf PreOs, tous les
>nouveaux programmes pour kernel (s'il y en a ) utiliseront des ROM_CALLs par
>ligne F parce que ça économise plein de place. Si tu le dis. Mais je conseilles quand meme jsr tios::machin.

Parce que tu penses à ta PreRom là. Parce que ça ne rentre pas du tout dans la logique "utilisez toutes les fonctionnalités offertes par PreOs, et on s'en fiche des autres kernels" que tu aimes tellement défendre.

>Donc ton excuse est complètement bidon: même avec un programme pour kernel,
> il n'y a aucun moyen de savoir de manière certaine quels ROM_CALLs il utilise!
Si : un PROGRAMME KERNEL BIEN PROGRAMMER NE FAIT DES APPELS QUE PAR jsr tios::machintruc. SINON c'est un programme sale.

Mais jsr tios::machin prend 6 ou dans certains cas même 10 octets de plus que dc.w $f800+machin. Et comme PreOs permet les appels F-LINE sous tous les AMS, les programmes qui de toute façon nécessitent PreOs ne vont pas tarder à l'utiliser.

Thibaut a écrit :
Wouaaaah t'es méchant PpHd ! imagine le boulot que va avoir Kevin pour contre-argumenter tout ça !!

LOL.

PpHd a écrit :
>Pas nécessairement. Le format kernel a besoin d'un stub et d'un header
>qui prennent de la place. Et il ne faut pas oublier de compter la taille
>du kernel et des librairies, qui font partie de la place requise par un
>programme pour kernel.
Mais pour plusieurs programmes partageant la meme librarie, on ECONOMISE de
la place. L'exemple le plus flagrant est les grayscale.
10 programmes l'utilisant = 10 * 1K de mem archive gaspille. Contre 5K (Et encore 3.5K pour certains) de kernel + 2.5K de graphlib.

Tu n'as pas pris en compte ExePack ici:
10 programmes utilisant les niveaux de gris de TIGCCLIB = 10 * 1 KO * 2/3 = 6,7 KO de memoire archive utilisée

Contre 5 KO de kernel + 2,5 KO de graphlib = 7,5 KO
Ou: Contre 5 KO de kernel + 2,5 KO *2/3 de graphlib + 0,6 KO de shrnklib = 7,3 KO
Ou: Contre 5 KO *2/3 de kernel + 2 KO de lanceur pour le kernel + 2,5 KO de graphlib = 7,8 KO
Ou: Contre 5 KO *2/3 de kernel + 2 KO de lanceur pour le kernel + 2,5 KO *2/3 de graphlib + 0,6 KO de shrnklib = 7,6 KO

Donc même avec 10 programmes l'utilisant, la librairie statique prend moins de place.

Et on peut meme compresser les programmes archives.

Oui, on peut compresser les librairies dynamiques avec le programme avec la dernière bêta de PreOs, mais avec ça, quel intérêt y a-t'il d'utiliser une librairie dynamique? La librairie statique prendra moins de place parce qu'elle ne comportera on-calc que les fonctions vraiment utilisées, pas la librairie entière.

>- les ROM_CALLs! Malgré le fait que TIGCCLIB a déjà éclairci le fait que presque
>toutes les fonctions dont un programmeur peut avoir besoin sont déjà dans la ROM
>en janvier 2000, même maintenant, beaucoup de personnes sous-estiment
>encore leur potentiel. Et qui sont chiantes a reprogrammer pour PreRom

Pourquoi reprogrammer une ROM s'il en existe déjà une qui marche très bien (AMS)?

Heureusement qu'il y a des programmes utilisant des libs, qui me feront pas chier.

Tu viens d'avouer que tu es parresseux avec cette phrase.

>- les librairies statiques, qui contiennent presque toutes les fonctions
>dont on pourrait avoir besoin et qui manquent dans AMS. Et contrairement à ce que
> la propagande en faveur des librairies dynamiques proclame, les librairies statiques
> ne font pas perdre de la place, mais au contraire en économisent, parce que seules
>les fonctions réellement utilisées devront être transférées sur la calculatrice.

>Les défenseurs des librairies dynamiques oublient toujours de compter la taille de
>ces librairies dynamiques (avec toutes leurs fonctions non utilisées qui traînent
>dans la mémoire et gaspillent de la place) lorsqu'ils calculent la taille des programmes.
Et toi tu oublies toujours de compter le nombre de fois ou plusieurs programmes utilisent
ces libraries.
Pour UN programme, je suis d'accord. Mais ca m'etonnerait qu'un utilisateur ne possede qu'UN SEUL programme.

Et toi, tu fais toujours des erreurs de calcul:

Tu n'as pas pris en compte ExePack ici:
10 programmes utilisant les niveaux de gris de TIGCCLIB = 10 * 1 KO * 2/3 = 6,7 KO de memoire archive utilisée

Contre 5 KO de kernel + 2,5 KO de graphlib = 7,5 KO
Ou: Contre 5 KO de kernel + 2,5 KO *2/3 de graphlib + 0,6 KO de shrnklib = 7,3 KO
Ou: Contre 5 KO *2/3 de kernel + 2 KO de lanceur pour le kernel + 2,5 KO de graphlib = 7,8 KO
Ou: Contre 5 KO *2/3 de kernel + 2 KO de lanceur pour le kernel + 2,5 KO *2/3 de graphlib + 0,6 KO de shrnklib = 7,6 KO

Donc même avec 10 programmes l'utilisant, la librairie statique prend moins de place.

Voilà.

>Par contre, pas besoin de kernel qui font plus planter les caltos qu'autre chose.
Avec Preos, c'est plutot le contraire.
Heureusement qu'il est la pour recuperer les crashs

Tu surestimes de loin la capacité de ton anti-crash. Aucun anticrash ne peut garantir que la calculatrice se trouvera en un état stable après un plantage. Le seul moyen de le garantir est un vrai reset.

>L'idéal pour une nouvelle ROM est d'offrir les 2 modes, pour des raisons de compatibilité. Je ne prends que la technologie la plus evoluee.

Non, tu prends la technologie la plus ancienne, celle de Fargo.

>En revanche, l'idéal pour un nouveau logiciel de développement serait de n'offrir que
>le _nostub. A quand pour Tigcc ?

Quand Sebastian arrêtera de mettre son véto à chaque fois que je lui propose cette décision.

>Le mode kernel est une vieille technologie dépassée, et il faudrait enfin penser
>à le retirer de la circulation.
J'hallucine grave. Retourne a la prehistoire la.

Quand auras-tu compris que kernel = émulation Fargo = émulation TI-92 I = vieux et que _nostub = TI-89/92+/V200 = moderne?

PpHd a écrit :
>non, sans rire, on dit que les progs kernels plantent,
Forcement. Les progs kernels qui plantent sont ceux qui censes tourner que sur AMS 1.00. C'est deja un EXPLOIT de les faire tourner sur AMS 2.0x !

Pose-toi la question: Pourquoi ne sont-ils "censés tourner que sur AMS 1.00"?
Réponse: parce qu'ils sont programmés de manière sale et utilisent les structures internes de AMS plutôt que les ROM_CALLs.

Il n'y a eu que 2 programmes en langage machine qui ont été programmés à l'époque de AMS 1, mais ont quand-même fonctionné sur HW2 AMS 2.0x dès sa sortie: CBlaster et CReversi. Et comme par hasard, ils sont en C _nostub. La raison:
- Ce sont des programmes _nostub qui ne dépassent pas la limite de taille, donc pas besoin de désactiver des protections de AMS.
- Ils ont été écrits avec TIGCCLIB, donc n'utilisent que les ROM_CALLs et n'accèdent pas directement aux structures internes de AMS.

>Mais un prog kernel en C/ASM bien programmé et le même prog nostub,
>ça sera la même chose au niveau des plantages !
Non. Le kernel intercepte certains crashs

1. Un bon kernel (comme le tien d'ailleurs ) intercepte les plantages aussi si le programme est en _nostub. Donc que le programme soit en mode kernel ou en mode _nostub ne changera absolument rien.
2. Il faut quand-même faire un reset après parce qu'il n'y a aucune garantie que le programme n'a pas corrompu la RAM avant de planter. Un anti-crash ne sert pas à grand chose si on veut avoir une calculatrice qui marche de manière stable.

>À condition que le kernel ne soit pas bogué, oui.
>Mais on introduit un logiciel en plus (souvent codé en assembleur d'ailleurs), Tu sous-entends que l'assembleur est plus proprice a la proliferation de bogues ?

Déjà, il l'est certainement. Par rapport au C, il y a tout simplement plus de potentiel de se tromper en assembleur. Je ne dis pas pour ça qu'il ne faut plus programmer en assembleur, juste qu'il faut avoir conscience de ce fait.

Et je disais ça ici surtout parce que iceman sous-entendait que la seule raison pour laquelle les programmes _nostub sont souvent plus stables est qu'ils sont souvent écrits en C et que les programmes kernel sont souvent écrits en assembleur (je dis bien "souvent", pas toujours). Je lui ai donc rappelé que le pur fait d'installer un kernel rajoute un programme en assembleur (pas en C) en plus.

> et il y a toujours le risque d'un bogue dans un logiciel.
>D'où un risque de bogues et donc de plantages plus grand en mode kernel. Moui, mais tu oublies le systeme anti-crash.

Cf. 2 paragraphes plus haut.

>Et souvent un programme pour kernel ne sera pas codé de la même façon qu'un programme
>_nostub. Il aura tendance d'utiliser des librairies dynamiques codées de manière sale,
>ou des RAM_CALLs permettant l'accès de manière sale (trop directe) à des structures
>internes de AMS, comme la table des handles ou la VAT. La VAT et la Heap Table sont des structures parfaitement connus et saines.

Et si elles changent dans AMS 3? Hop, plantage...
Alors que les programmes utilisant HeapDeref ou Sym* continueront à fonctionner sans problèmes.

>Le programme _nostub, lui, aura
>tendance d'utiliser des ROM_CALLs officiels comme HeapDeref, ou comme les
>fonctions de vat.h pour l'accès aux fichiers, à la place, ce qui le rendra
>bien plus stable. Des exemples ?

En as-tu vraiment besoin? Compare les sources de TI-Chess et celles de SMA...

>Et les malchanceux qui ont une V200 et qui ne peuvent pas patcher leur AMS, ils font quoi?
>Et puis tout le monde n'a pas forcément envie de patcher son AMS.
Ben ils patchent leur programme kernel avec mon AutoPreosPatcher
qui patche le header des progs kernels pour mettre l'auto-install de preos

Et si par hasard ils essayent de lancer le programme à partir de TICTEX -> plantage...

>Tu viens de donner la raison pour laquelle je n'ai pas envie d'avoir toutes
> les librairies dynamiques possibles et imaginables sur ma calculatrice justement.
>Arrête de te contredire!
Pourtant c'est presque le cas (filelib/genlib/genalib/genclib/graphlib/userlib/ziplib/pk92lib/brwselib/ugplib/fargray/gray4lib/gray7lib/util/triglib/linelib/hufflib/hexlib sont dans ta calc -si tu as stdlib standard de preos 0.59-).

Et bonjour le gaspillage de place...
Je signale à ceux qui ne sont pas bêta-testeurs de PreOs que stdlib fait 22093 octets! Oui, 22 KO! Et avec ça, PpHd se plaint que UniOS fait 12 KO... Ben, c'est normal, plus de librairies dynamiques on intègre, plus de place ça prend.

Et il faut shrnklib en plus, parce que PpHd n'a pas voulu intégrer ttunpack_decompress au kernel comme il aurait dû faire: ça compresserait mieux, et on n'aurait pas besoin d'une librairie non compressée à part.

Et en plus, avec les libs dynamiques compressees, elles ne prennent plus rien comme place.

Ah, 22 KO, ce n'est rien? Ben alors, ne te plains pas si tu as 22 programmes qui utilisent les niveaux de gris de TIGCCLIB sur ta calculatrice.

>Argument très objectif...
>Alors voila, je suis nostubien, et je resterai nostubien.... La c'est bien. Enfin quelque chose d'objectif.

LOL.
Je n'ai fait que reprendre l'"argument" de iceman pour lui montrer à quel point il est subjectif et ne démontre rien.

PpHd a écrit :
>Moi aussi, j'ai PreOs. Je le trouve sympa parce que:
>- il sait lancer TICT Explorer avec SHIFT+ON (c'est moi qui ai codé ça d'ailleurs)

>- il fournit un anti-crash pour les programmes _nostub (donc fini l'argument que le
> _nostub ne permet pas l'anticrash; la plupart des améliorations de l'anticrash _nostub
> de PreOs par rapport à sa première version sont d'ailleurs de moi) Mais il faut un kernel pour ca !

Mais l'anti-crash n'est pas du tout une fonctionnalité obligatoire! Avec la récupération de la mémoire archive, ce n'est pas grave si on est obligés de faire un reset. Donc c'est bien de laisser à l'utilisateur le choix s'il veut un anti-crash (auquel cas il peut utiliser PreOs ou KerNO) ou s'il n'en veut pas (auquel cas il n'a besoin d'aucun kernel). L'anti-crash n'est pas un argument en faveur du mode kernel (parce que l'utilisateur a la possibilité d'en utiliser un que le programme soit en format _nostub ou en format kernel).

Et aussi d'Extended

C'est vrai, merci à ExtendeD pour ça d'ailleurs. C'est toujours bien de travailler contre la discrimination des programmes _nostub par certains kernels, et le fait de n'offrir l'anti-crash qu'aux programmes au format kernel est un exemple de cette discrimination.

>Et si vraiment on a besoin de librairies dynamiques (à cause de la limite de 64 KO),
> c'est également possible (cf. FAT Engine, et cf. les versions récentes de TIGCC).
Mais bien plus complique. Et on NE PEUT PAS faire d'appel croise, pour vraiment supporte les 128 K.

Si, tu passes un pointeur vers ta fonction!

alors qu'en kernel, en plus d'etre possible, c'est simple et QUASI-TRANSPARENT au niveau du code !

Passer un pointeur vers la fonction est aussi très simple! Un pea func1(PC) suffit. Et pour l'appel, un: move.l x(a7),a0 et un jsr (a0) suffisent. (J'utilise le passage par pile exprès, parce que sinon tu vas te plaindre que je gaspille un registre. )

Et les kernels, la limite c'est la RAM maximale

Pour le _nostub aussi: si ta DLL en importe elle-même une autre, la limite passe à 3*64=192 KO, la taille totale de la RAM utilisateur.
Et sinon, tu peux aussi décharger une DLL et en charger une autre à la place, ce qui te permet d'aller même au delà des 192 KO (je sais, c'est également possible avec PreOs).

>Il y a les ROM_CALLs et les librairies statiques!!!
>Lis la documentation de TIGCC, et si tu programmes en assembleur, lis aussi ce tutorial. Mais les libs statiques prennent de la place dans le programme, place qui est gaspillee si plusieurs programmes les utilisent !

Mais on économise la place prise par la librairie dynamique et la place prise par le kernel, et on peut aussi économiser la place prise par les informations de relogement si on utilise les appels PC-relatifs (c'est possible avec un librairie statique).

Et en plus, en cas de buggues il faut :
+ remettre a jour tous les programmes. + retransferer tous les programmes.

C'est vrai, mais si une correction de bogue entraîne nécessairement une incompatibilité (ce qui est parfois le cas), ce n'est pas gênant pour les librairies statiques (les anciens programmes continueront d'utiliser l'ancienne librairie), alors que pour les librairies dynamiques, on est obligés de garder le bogue.

Un exemple: dans TIGCCLIB, on changera peut-être fopen pour refuser d'ouvrir des fichiers cachés, parce que AMS cache les fichiers qu'il utilise pour montrer qu'ils sont utilisés, et qu'il faut éviter d'ouvrir des fichiers utilisés par AMS. On ne pourrait pas faire ça avec une librairie dynamique parce que des programmes qui dépendent de l'ancien comportement ne fonctionneraient plus. (Ceci dit, comme ce changement-ci crée aussi une incompatibilité au niveau des sources, nous sommes en train de chercher une solution meilleure. Mais je ne suis pas sûr qu'il en existe une.)

>Je ne trouve pas que c'est plus facile de programmer kernel, c'est juste que beaucoup
>de tutoriaux assembleur sont écrits pour Fargo ou pour kernel, et c'est pour ça
>que les newbies en assembleur apprennent souvent le mode kernel en premier.

(1) jsr tios::ngetchx

Contre :

(2) move.l $C8,a0
move.l ngetchx*4(a0),a0
jsr (a0)
Je preferes le (1) plus elegant (Meme s'il y a une macro le faisant, ok).

1. Il y a en effet une macro.
2. Le plus élégant, c'est ce qui permet aux programmeurs de comprendre la vraie API, et donc le (2). Le (1) cache l'API de AMS aux programmeurs.
3. Si on optimise l'écriture (2) (cf. OPTIMIZE_ROM_CALLS), on obtient du code plus court que celui de l'écriture (1).
4. Si tu aimes tellement l'écriture (1), je peux mettre un switch dans A68k qui transforme automatiquement le (1) en le (2). Mais ça ne me fascine pas trop personnellement parce que ça cacherait ce qui se passe vraiment.
5. Bientôt, ces 2 écritures seront toutes les 2 dépassées et on passera à la (3):
dc.w $f800+ngetchx

>Et je ne pense pas vraiment que ce qui fait que les programmes kernel sont
>souvent mal programmés est le niveau des programmeurs kernel.
>Je pense plutôt que ce sont les interfaces sales proposées par les kernels.
>Par exemple:
>- doorsos::Heap. HeapDeref, c'est pour les chiens?
>- doorsos::FolderListHandle, doorsos::MainHandle.
>Il y a des ROM_CALLs (cf. vat.h) qui permettent l'accès aux variables
>sans aller traffiquer directement dans la VAT!
Si meme avec les romcalls, tu es obbliges de trafiquer dans la vat. Sinon comment lire un handle ?

Tu ne traffiques pas dans la VAT, tu lis une entrée de la structure documentée vers laquelle le ROM_CALL te renvoie un pointeur. Que cette structure soit dans la VAT ou n'importe où ailleurs n'a aucune importance. Et surtout: l'utilisation des ROM_CALLs permet à TI de rajouter des champs à la fin de la structure sans rendre les programmes qui accèdent aux fichiers incompatibles.

>- doorsos::font_medium. DrawStr (et DrawChar), c'est pour les chiens? C'est fait pour afficher plus vite, ca prendre de la place pour une autre fonte.

Et à faire en sorte que les programmes:
- n'utilisent pas la fonte modifiée si on utilise RomEdit
- n'utilisent pas la fonte modifiée si on utilise le programme que Mike Grass compte sortir qui permettra de remplacer les fontes de AMS 2 par des fontes personnalisés sans modifier AMS
- ne fonctionnent pas sur VTI avec une ROM en TIB ou 89U si on utilise d'autres fontes que la fonte de taille moyenne (parce que ce sont des offsets par rapport à doorsos::font_medium, qui ne sont valables que pour les fontes du boot)
- arrêteront de fonctionner de manière irremédiable si TI change l'ordre des fontes dans les nouveaux boot codes (de manière irremédiable parce qu'on ne peut pas modifier le boot code)
Donc ça a bien plus de désavantages que d'avantages.

Tous tes exemples sont des structures kernels qui marchent PARFAITEMENT ! Et qui n'entrainent aucun bogue.

Ben non, cf. ci-dessus.

PpHd a écrit :
>Non, c'est de la pure statistique. Les jeux pour kernel sont en général moins stables
>que les jeux _nostub, donc à moins d'avoir une chance énorme avec les jeux pour kernel
>et une malchance énorme avec les jeux _nostub, on remarquera la même chose que toi.
Les jeux kernels sont developpes pour AMS 1.00.
S'ils arrivent a tourner sur AMS 2.0x, c'est grace a la puissance de la technologie des kernels.
Et les jeux _nostub : 80 % a jeter direct Et le reste

Je connais exactement 2 jeux _nostub sortis avant AMS 2: CBlaster et CReversi.
De ces-ci, 100% fonctionnent sous AMS 2, et 0% étaient "à jeter direct".

>Et enfin: les mauvaises expériences avec PlusShell et DoorsOS ne m'ont certainement
>pas fait aimer les kernels, mais ce n'est pas que pour ça que je n'aime pas le mode
>kernel. C'est aussi parce que c'est totalement illogique de ne pas pouvoir lancer
>un programme assembleur ou C comme un programme BASIC (c'est-à-dire: nom du programme,
>[(], [)], [ENTER], sans avoir à installer quoi que ce soit avant).
Tu connais l'auto-installation de preos 0.60. Elle est faite pour toi
Tu peux taper :
nom du programme, [(], [)], [ENTER], sans avoir à installer quoi que ce soit avant
Et ca marche ! C'est dingue hein

Non, elle n'est pas faite pour moi, parce que je n'aime pas les programmes instables, et que ton auto-installation n'est pas stable.


Voilà, j'ai répondu à tout là.

je rappelle que cela fait belle lurette qu'une rom faite maison circule sur le web

PpHd>De toute maniere cette rom est inutile..
Si tu veux vraiment faire qqc d'utilie, implante Genlib dans l'ams.

Raaaahhh encore ce putain de débat _nostub VS kernel qui recommence

Quand est-ce que ça s'arrêtera ?

PpHd> ce serait une bonne idée d'intégrer tigcclib.a à PreRom, comme ça on pourra qd même utiliser les progs pour TI-GCC (avec #include <prerom.h>, qui redéfinirait fopen, etc...)

Kevin> les DLL nostub sont vraiment horribles. J'ose pas imaginer le temps que j'y passerais si je voulais convertir GTC en DLL _nostub

Pollux
a écrit : PpHd> ce serait une bonne idée d'intégrer tigcclib.a à PreRom, comme ça on pourra qd même utiliser les progs pour TI-GCC (avec #include <prerom.h>, qui redéfinirait fopen, etc...)

Il lui faudra aussi modifier tipatch.lib.

Kevin> les DLL nostub sont vraiment horribles. J'ose pas imaginer le temps que j'y passerais si je voulais convertir GTC en DLL _nostub

Mais non, c'est tout aussi simple que les DLLs kernel!

Ca se voit que t'as jamais fait de prog qui nécessite 3 libs dynamiques avec des tonnes de références croisées...

>Vu le peu de RomCalls qu'il y aura, ta ROM ne servira pas à grand chose. (C'est ce que je dis dès le début. Je savais bien qu'il n'allait pas y avoir grand chose comme ROM_CALLs.) Désolé.

Le but est d'offir une BASE MINIMALISTE. Ensuite pourrons venir se greffer n'importe quoi, avec comme place 2Mo - 2*64K, sans aucune protection d'execution. Mais je la fais pour moi seul. Je ne la distriburais pas. Je suis sûr que des gens peteraient leur calc avec. Alors...

>Bon, il va falloir qu'on fasse la table nous-mêmes alors. Sauf si elle traîne quelque part dans ta ROM. Sinon, aucun programme en C ne pourra tourner sur ta ROM.
Mais si. Tu surestimes le nombre de reference a $C8. Et puis je m'en fous.

> aucun programme en C ne pourra tourner sous PreRom.
Tu connais le fichier kernel.h ?


>Parce que tu penses à ta PreRom là. Parce que ça ne rentre pas du tout dans la logique "utilisez toutes les fonctionnalités offertes par PreOs, et on s'en fiche des autres kernels" que tu aimes tellement défendre.
Non. Je pense encore et toujours que le seul format pour une application d'appeller une ROM_CALL est jsr tios::machin_truc.
Preos utilise le FLINE car c un kernel, voilou.

>Mais jsr tios::machin prend 6 ou dans certains cas même 10 octets de plus que dc.w $f800+machin. Et comme PreOs permet les appels F-LINE sous tous les AMS, les programmes qui de toute façon nécessitent PreOs ne vont pas tarder à l'utiliser.
Je parle de programmation propre ! Donc utiliser une table de relogement des appels systemes. Heureusement que le FLINE est quand meme plus propre que l'acces indirect.

Tu n'as pas pris en compte ExePack ici:
10 programmes utilisant les niveaux de gris de TIGCCLIB = 10 * 1 KO * 2/3 = 6,7 KO de memoire archive utilisée
Contre 5 KO de kernel + 2,5 KO de graphlib = 7,5 KO
Ou: Contre 5 KO de kernel + 2,5 KO *2/3 de graphlib + 0,6 KO de shrnklib = 7,3 KO
Ou: Contre 5 KO *2/3 de kernel + 2 KO de lanceur pour le kernel + 2,5 KO de graphlib = 7,8 KO
Ou: Contre 5 KO *2/3 de kernel + 2 KO de lanceur pour le kernel + 2,5 KO *2/3 de graphlib + 0,6 KO de shrnklib = 7,6 KO

Donc même avec 10 programmes l'utilisant, la librairie statique prend moins de place.

10 prog utilisant les niveaux de gris de TIGCCLIB = 10 * 1 KO * 2/3 = 6,7 KO de memoire archive utilisée + Lanceur 2 Ko = 8,7 Ko
Contre 5 Ko de kernel + 2,5 KO *2/3 de graphlib + 0,6 KO de shrnklib = 7,3 Ko
Et je ne compte que les niveaux de gris la dedans. Mais on pourrait rajouter les routines graphiques en lib statiques, qui ne feraient que renforcer la dominance du systeme kernel.

Oui, on peut compresser les librairies dynamiques avec le programme avec la dernière bêta de PreOs, mais avec ça, quel intérêt y a-t'il d'utiliser une librairie dynamique? La librairie statique prendra moins de place parce qu'elle ne comportera on-calc que les fonctions vraiment utilisées, pas la librairie entière.

T'es sourd ou quoi ? TON HYPOTHESE N'EST VALABLE QUE POUR UN SEUL PROGRAMME.
Des que plusieurs programmes rentrent en jeu, ton analyse s'effondre !

>Pourquoi reprogrammer une ROM s'il en existe déjà une qui marche très bien (AMS)?
Pour disposer de plus d'espace d'archives. Pour le fun. Voila.

>Tu viens d'avouer que tu es parresseux avec cette phrase.
Qui ne l'est pas ?

>Et toi, tu fais toujours des erreurs de calcul:
C'est plutot toi.

>Tu surestimes de loin la capacité de ton anti-crash. Aucun anticrash ne peut garantir que la calculatrice se trouvera en un état stable après un plantage. Le seul moyen de le garantir est un vrai reset.
Oui je suis d'accord. Et l'argument en faveur des nostub il est ou ?

>Non, tu prends la technologie la plus ancienne, celle de Fargo.
Fargo utilise une technologie BIEN SUPERIEURE a celle offerte par AMS !
La preuve : vous etes obblige de rajouter tout un systeme de patch avant d'executer le programme, et une lib statique pour combler les lacunes du format nostub d'AMS.
Alors ne dit pas que c'est a jour.

>Quand Sebastian arrêtera de mettre son véto à chaque fois que je lui propose cette décision.
Pour bientot donc, puisqu'il compte arreter le developement de tigcc.

>Quand auras-tu compris que kernel = émulation Fargo = émulation TI-92 I = vieux et que _nostub = TI-89/92+/V200 = moderne?
Et moderne veut donc dire :

pea ret(pc)
pea fonction(pc)
jmp return
ret:

return: rts ?
(Code d'une V200)

a :
jsr fonction
(Code d'une Ti-92)

Arrete de deconner, moderne est tres loin de signifier le plus recent !



>Pose-toi la question: Pourquoi ne sont-ils "censés tourner que sur AMS 1.00"?
>Réponse: parce qu'ils sont programmés de manière sale et utilisent les structures internes de AMS plutôt que les ROM_CALLs.
Et ? Ce n'est pas LEUR faute si les ROM CALLS n'etaient pas documentes a l'epoque !

>Il n'y a eu que 2 programmes en langage machine qui ont été programmés à l'époque de AMS 1, mais ont quand-même fonctionné sur HW2 AMS 2.0x dès sa sortie: CBlaster et CReversi.

> Et comme par hasard, ils sont en C _nostub. La raison:
- Ce sont des programmes _nostub qui ne dépassent pas la limite de taille, donc pas besoin de désactiver des protections de AMS.
- Ils ont été écrits avec TIGCCLIB, donc n'utilisent que les ROM_CALLs et n'accèdent pas directement aux structures internes de AMS.

Troisieme raison : ils n'utilisent en rien la puissance de la machine...

>1. Un bon kernel (comme le tien d'ailleurs ) intercepte les plantages aussi si le programme est en _nostub. Donc que le programme soit en mode kernel ou en mode _nostub ne changera absolument rien.
Certes mais un bon kernel (comme le mien d'ailleurs) rend une calculette plus stable pour les programmes kernels car il a pu fire une image du systeme avant l'appel du programme.

>2. Il faut quand-même faire un reset après parce qu'il n'y a aucune garantie que le programme n'a pas corrompu la RAM avant de planter. Un anti-crash ne sert pas à grand chose si on veut avoir une calculatrice qui marche de manière stable.
Certes. Mais perso, je ne le fais jamais.

>Et si elles changent dans AMS 3? Hop, plantage...
>Alors que les programmes utilisant HeapDeref ou Sym* continueront à fonctionner sans problèmes.
Si elles changent on pourra QUAND meme se demerder en creant une image du systeme et en interceptant tous les appels standars de heap et de vat.
Mais je te signales qu'on accede directement, meme en nostub a la structure SYM !
Donc s'il la change (comme le passage ti-92 -> 92+) : TOUS LES programmes poubelles (sauf ceux compiles avec preos 0.60 )


>n as-tu vraiment besoin? Compare les sources de TI-Chess et celles de SMA...
SMA n'a jamais plante chez moi. Tichess si (A cause du lanceur je pense).
Donc tu veux prouver quoi ?
(Et je blague pas).


>t si par hasard ils essayent de lancer le programme à partir de TICTEX -> plantage...
Ben defaut de tictex qui ne supporte pas l'install des TSR. C pas ma faute.

>Et bonjour le gaspillage de place...
Tu peux le changer si tu le souhaites.

>Je signale à ceux qui ne sont pas bêta-testeurs de PreOs que stdlib fait 22093 octets! Oui, 22 KO! Et avec ça, PpHd se plaint que UniOS fait 12 KO... Ben, c'est normal, plus de librairies dynamiques on intègre, plus de place ça prend.
Je signale à ceux qui ne sont pas bêta-testeurs de PreOs que stdlib est un fichier archive qui n'est JAMAIS desarchive : seuls les petits bouts des libs sont desarchives si besoin est.

>Et il faut shrnklib en plus, parce que PpHd n'a pas voulu intégrer ttunpack_decompress au kernel comme il aurait dû faire: ça compresserait mieux, et on n'aurait pas besoin d'une librairie non compressée à part.
Je ne voulais pas imposer de format de compression. Tu peux utiliser ttunpack_decompress si tu le souhaites. Aucune difficulte.
Et la difference de compression est inferieure a 2% alors

>Ah, 22 KO, ce n'est rien? Ben alors, ne te plains pas si tu as 22 programmes qui utilisent les niveaux de gris de TIGCCLIB sur ta calculatrice.
Regarde la difference de fonctionnalite offerte. J'offre beaucoup de fonctions dans beaucoup de libraries. Ce n'est pas comparable. Autant comparer AMS et PreRom.


>Mais l'anti-crash n'est pas du tout une fonctionnalité obligatoire! Avec la récupération de la mémoire archive, ce n'est pas grave si on est obligés de faire un reset. Donc c'est bien de laisser à l'utilisateur le choix s'il veut un anti-crash (auquel cas il peut utiliser PreOs ou KerNO) ou s'il n'en veut pas (auquel cas il n'a besoin d'aucun kernel). L'anti-crash n'est pas un argument en faveur du mode kernel (parce que l'utilisateur a la possibilité d'en utiliser un que le programme soit en format _nostub ou en format kernel).
Certes. Mais c'est mieux avec que sans.


>C'est vrai, merci à ExtendeD pour ça d'ailleurs. C'est toujours bien de travailler contre la discrimination des programmes _nostub par certains kernels, et le fait de n'offrir l'anti-crash qu'aux programmes au format kernel est un exemple de cette discrimination.
Ce n'est pas que ca. J'ai passe de nombreuses heures de recherche avant de trouver une methode efficace (et en plus elle etait simple) pour faire l'anti crash _nostub. Et j'en ai essaye des trucs.
En kernel, c'est bien plus simple : tu fais une image avant, puis hop tu restaures l'image. En nostub, faut trouver un point d'entree en AMS.
Et d'ailleurs je trouve l'anti-crash de kerno largement incomplet.

>Si, tu passes un pointeur vers ta fonction!
Image la complexite de ton programme s'il y en a partout !
Ca devient ingerable en nostub !


>Passer un pointeur vers la fonction est aussi très simple! Un pea func1(PC) suffit. Et pour l'appel, un: move.l x(a7),a0 et un jsr (a0) suffisent. (J'utilise le passage par pile exprès, parce que sinon tu vas te plaindre que je gaspille un registre. )

Mais si c plusieurs disaines de fonctions ?

>Pour le _nostub aussi: si ta DLL en importe elle-même une autre, la limite passe à 3*64=192 KO, la taille totale de la RAM utilisateur.
Et sinon, tu peux aussi décharger une DLL et en charger une autre à la place, ce qui te permet d'aller même au delà des 192 KO (je sais, c'est également possible avec PreOs).

C'est lourd, tres lourd.

>Mais on économise la place prise par la librairie dynamique et la place prise par le kernel, et on peut aussi économiser la place prise par les informations de relogement si on utilise les appels PC-relatifs (c'est possible avec un librairie statique).

Ce n'est valable que pour des libs statiques de petite taille. Des qu'elles depassent 1 Ko, ca devient bien plus discutable (Pour ne pas dire plus !)

C'est vrai, mais si une correction de bogue entraîne nécessairement une incompatibilité (ce qui est parfois le cas), ce n'est pas gênant pour les librairies statiques (les anciens programmes continueront d'utiliser l'ancienne librairie), alors que pour les librairies dynamiques, on est obligés de garder le bogue.
Un exemple: dans TIGCCLIB, on changera peut-être fopen pour refuser d'ouvrir des fichiers cachés, parce que AMS cache les fichiers qu'il utilise pour montrer qu'ils sont utilisés, et qu'il faut éviter d'ouvrir des fichiers utilisés par AMS. On ne pourrait pas faire ça avec une librairie dynamique parce que des programmes qui dépendent de l'ancien comportement ne fonctionneraient plus. (Ceci dit, comme ce changement-ci crée aussi une incompatibilité au niveau des sources, nous sommes en train de chercher une solution meilleure. Mais je ne suis pas sûr qu'il en existe une.)

Si le protocole de la fonction de la lib est BIEN definie, et si sa description est complete, il n'y aura pas de pbs. Et pour votre histoire de fichiers caches, je ne vois pas ou est l'imcompatibilite.

>2. Le plus élégant, c'est ce qui permet aux programmeurs de comprendre la vraie API, et donc le (2). Le (1) cache l'API de AMS aux programmeurs.
Ti n'a jamais supporte cette methode d'acces. Elle est donc illegale !
Cf doc du SDK...

>3. Si on optimise l'écriture (2) (cf. OPTIMIZE_ROM_CALLS), on obtient du code plus court que celui de l'écriture (1).
MAIS ON GASPILLE UN REGISTRE !
Ce qui est tres ennuyant !

>4. Si tu aimes tellement l'écriture (1), je peux mettre un switch dans A68k qui transforme automatiquement le (1) en le (2). Mais ça ne me fascine pas trop personnellement parce que ça cacherait ce qui se passe vraiment.
Tu as vraiment du temps a perdre ! Et il y a la romcall en plus

>5. Bientôt, ces 2 écritures seront toutes les 2 dépassées et on passera à la (3):
dc.w $f800+ngetchx
qui est le truc officiel. C'est mieux que le (2), mais moins bon que le (1), en terme d'acces systemes.