TI-GCC Format des fichiers .a - Page 4

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