QQN a t il un ANTI CRASH POUR Ti89 !!! SVP - Page 5

Sauf que moi, je parlais du passage à AMS 2 et que tu es donc hors-sujet.

moi je parle de hw2 depuis le debut, le passage à hw2 a cause au moins autant de soucis qu'ams

Bon, vu que tu veux parler des HW2, je te signale qu'aucun programme pour kernel n'a marché sur HW2 AMS 2 dès le départ. Seulement sur HW1 ou sur HW2 AMS 1.05. On a dû attendre longtemps le HW2Patch. CBlaster et CReversi ont fonctionné sur HW2 AMS 2 dès le départ.

mais il a suffit de changer les kernels pour que les programmes marchent. Idem pour la v200. txtrider tourne très bien dessus alors qu'il est pas franchement conçu pour

Kevin Kofler :
Bon, vu que tu veux parler des HW2, je te signale qu'aucun programme pour kernel n'a marché sur HW2 AMS 2 dès le départ. Seulement sur HW1 ou sur HW2 AMS 1.05. On a dû attendre longtemps le HW2Patch. CBlaster et CReversi ont fonctionné sur HW2 AMS 2 dès le départ.

Je suis tout a fait d'accord avec toi, aucun prgm kernel ne marchait sur hw2 au depart et c'est tout a fait normal vues les modifications apportées a la TI. Meme les ams concus pour hw1 ne sont pas tres recommandes sur hw2.

Pour les prgm nostub, ceux qui utilisent les nvg ne devaient pas marcher non plus, il a fallu attendre que tigcc fasse ce remarquable boulot pour rendre les routines tigcclib compatibles et recompiler les prgm pour que ça marche.
Pour les prgm kernel, il a fallu attendre que les auteurs des libs mettent a jour leurs routines pour les rendre compatibles et a priori les bon prgm kernel n'ont pas eu besoin d'etre recompilés (sauf s'ils utilisent des routines internes au prgm qui ont perdu leur compatibilité mais ça c'est le programmeur qui est stupide et qui aurait du utiliser des routines de libs dynamiques).

dis moi si je me trompe

>Et si je t'envoyais un patch un de ces jours?
a voir. Si le patch est bon, je pourrais le mettre en option. S'il est tres bon, il sera inclu dans le truc d'office.

>CBlaster et CReversi ont été créés avant AMS 2, et ils marchaient sous AMS 2 dès le départ.
2 jeux.

>CF utilise des hacks pour faire du linkage dans les 2 sens, chose qui n'est pas vraiment supportée par le format kernel (contrairement aux .so *nix). Ce sont des hacks parce que la librairie n'est plus utilisable par n'importe quel programme client vu que le nom du programme client est codé en dur dans la librairie. Ce n'est pas une utilisation correcte des librairies, et c'est normal que ça ne passe pas avec ttstart.
C'est supporte depuis DoorsOs (la 1ere version), mon cher. C'est une utilisation parfaitement correcte des librairies, et faudrait que je le mette dans les docs officielles.

>Donc si on critique le mode kernel, on fait maintenant des "remarques déplacées"?! C'est carrément n'importe quoi!
Si on raconte des conneries, on fait n'importe quoi. (Et ce qu'il a dit ce sont des conneries).

Flanker
: Idem pour la v200. txtrider tourne très bien dessus alors qu'il est pas franchement conçu pour

Les programmes _nostub aussi (au pire avec le V200 Executables Patcher), et ils plantent bien moins souvent que TxtRider.

liquid
: Je suis tout a fait d'accord avec toi, aucun prgm kernel ne marchait sur hw2 au depart et c'est tout a fait normal vues les modifications apportées a la TI. Meme les ams concus pour hw1 ne sont pas tres recommandes sur hw2.

Aucun rapport. AMS est le système d'exploitation. Il est évident que le système d'exploitation doit être mis à jour en cas de changement matériel.

Pour les prgm nostub, ceux qui utilisent les nvg ne devaient pas marcher non plus, il a fallu attendre que tigcc fasse ce remarquable boulot pour rendre les routines tigcclib compatibles et recompiler les prgm pour que ça marche.

Bon, déjà une correction: C'est Scott Noveck qui a fait ce boulot, avec l'aide de Niklas Brunlid pour l'optimisation en vitesse de l'interruption. Tout le monde a utilisé des dérivés des routines de Scott Noveck et Niklas Brunlid, que ce soient les librairies kernel ou TIGCCLIB.
Ensuite, une recompilation a suffi pour règler tout problème de compatibilité, alors que...

Pour les prgm kernel, il a fallu attendre que les auteurs des libs mettent a jour leurs routines pour les rendre compatibles et a priori les bon prgm kernel n'ont pas eu besoin d'etre recompilés (sauf s'ils utilisent des routines internes au prgm qui ont perdu leur compatibilité mais ça c'est le programmeur qui est stupide et qui aurait du utiliser des routines de libs dynamiques).

... contrairement à ce que tu dis là, beaucoup de programmes pour kernel ont dû être modifiés (dans les sources, pas seulement recompilés). Pourquoi? Ben, c'est simple, les auteurs des kernels et des librairies pour kernel, pour une raison ou pour une autre, ont documenté que leur plan foncé était toujours sur LCD_MEM, alors que c'est un détail interne qui ne regarde pas du tout les programmes clients de la librairie. Résultat: beaucoup de programmeurs (y compris ceux de jeux très utilisés comme Tetris89) ont décidé d'"optimiser" leurs programmes en remplaçant toute référence au plan foncé (une variable importée d'une librairie) par LCD_MEM (une constante). Le résultat sur HW2 était catastrophique. Soit ajouté en passant que si les librairies de gris de l'époque avaient été statiques, utiliser une importation plutôt qu'une constante n'aurait porté aucun coût en termes d'optimisation. movea.l D_plane(%PC),%a0 prend 4 octets tout comme lea.l 0x4c00:w,%a0.

dis moi si je me trompe

Cf. ci-dessus.

PpHd :
>Et si je t'envoyais un patch un de ces jours? a voir. Si le patch est bon, je pourrais le mettre en option. S'il est tres bon, il sera inclu dans le truc d'office.

Je vais me plonger là-dessus.

>CBlaster et CReversi ont été créés avant AMS 2, et ils marchaient sous AMS 2 dès le départ. 2 jeux.

Ben, c'est à peu près tout ce qu'il y avait en _nostub à l'époque.

>CF utilise des hacks pour faire du linkage dans les 2 sens, chose qui n'est pas vraiment supportée par le format kernel (contrairement aux .so *nix). Ce sont des hacks parce que la librairie n'est plus utilisable par n'importe quel programme client vu que le nom du programme client est codé en dur dans la librairie. Ce n'est pas une utilisation correcte des librairies, et c'est normal que ça ne passe pas avec ttstart. C'est supporte depuis DoorsOs (la 1ere version), mon cher.

Ce n'est pas vraiment "supporté", c'est un hack affreux.

C'est une utilisation parfaitement correcte des librairies,

Je ne suis pas d'accord. Le fait d'avoir le nom du programme client dans une librairie va contre le concept de librairie. Normalement, un système programme-librairie est un système client-serveur. Le client accède au serveur par son nom. Le serveur est censé répondre à n'importe quel client. Si le nom du programme client est codé en dur, la librairie ne remplit pas son rôle.

et faudrait que je le mette dans les docs officielles.

Bon, fais ce que tu veux, mais je ne trouve pas ça propre du tout.

>Donc si on critique le mode kernel, on fait maintenant des "remarques déplacées"?! C'est carrément n'importe quoi! Si on raconte des conneries, on fait n'importe quoi. (Et ce qu'il a dit ce sont des conneries).

Il s'est parfois trompé, mais pas mal des choses qu'il a dites sont vraies.

Postulat: quand Kevin pense que quelque chose est vrai, ça l'est. Et réciproquement. Et inversement aussi.

Kevin Kofler
:

liquid
: Je suis tout a fait d'accord avec toi, aucun prgm kernel ne marchait sur hw2 au depart et c'est tout a fait normal vues les modifications apportées a la TI. Meme les ams concus pour hw1 ne sont pas tres recommandes sur hw2.

Aucun rapport. AMS est le système d'exploitation. Il est évident que le système d'exploitation doit être mis à jour en cas de changement matériel.

Ben si, le rapport c'est que qd tu changes de hard, c'est normal que plus rien ne soit compatible.

Pour les prgm nostub, ceux qui utilisent les nvg ne devaient pas marcher non plus, il a fallu attendre que tigcc fasse ce remarquable boulot pour rendre les routines tigcclib compatibles et recompiler les prgm pour que ça marche.

Bon, déjà une correction: C'est Scott Noveck qui a fait ce boulot, avec l'aide de Niklas Brunlid pour l'optimisation en vitesse de l'interruption. Tout le monde a utilisé des dérivés des routines de Scott Noveck et Niklas Brunlid, que ce soient les librairies kernel ou TIGCCLIB.
Ensuite, une recompilation a suffi pour règler tout problème de compatibilité, alors que...

ok je savais pas que c'etait scott noveck, mais sur ça on est d'accord.

Pour les prgm kernel, il a fallu attendre que les auteurs des libs mettent a jour leurs routines pour les rendre compatibles et a priori les bon prgm kernel n'ont pas eu besoin d'etre recompilés (sauf s'ils utilisent des routines internes au prgm qui ont perdu leur compatibilité mais ça c'est le programmeur qui est stupide et qui aurait du utiliser des routines de libs dynamiques).

... contrairement à ce que tu dis là, beaucoup de programmes pour kernel ont dû être modifiés (dans les sources, pas seulement recompilés). Pourquoi? Ben, c'est simple, les auteurs des kernels et des librairies pour kernel, pour une raison ou pour une autre, ont documenté que leur plan foncé était toujours sur LCD_MEM, alors que c'est un détail interne qui ne regarde pas du tout les programmes clients de la librairie. Résultat: beaucoup de programmeurs (y compris ceux de jeux très utilisés comme Tetris89) ont décidé d'"optimiser" leurs programmes en remplaçant toute référence au plan foncé (une variable importée d'une librairie) par LCD_MEM (une constante). Le résultat sur HW2 était catastrophique. Soit ajouté en passant que si les librairies de gris de l'époque avaient été statiques, utiliser une importation plutôt qu'une constante n'aurait porté aucun coût en termes d'optimisation. movea.l D_plane(%PC),%a0 prend 4 octets tout comme lea.l 0x4c00:w,%a0.

Ben c'est a peu pres ce que je dis, les programmeurs ont fait du bidouillage ds leur prgm ou des conneries qui ont fait que le simple fait de modifier les libs n'a pas suffit, mais d'apres ce que je me souviens, certains prgm n'ont mm pas eu besoin d'etre recompilés.

>Donc si on critique le mode kernel, on fait maintenant des "remarques déplacées"?! C'est carrément n'importe quoi! Si on raconte des conneries, on fait n'importe quoi. (Et ce qu'il a dit ce sont des conneries).

Il s'est parfois trompé, mais pas mal des choses qu'il a dites sont vraies.

comme vive tigcc ?

C'est parfaitement propre si on utilise pas de methodes inofficielles pour lancer les programmes, c'est tout!
Ca marche parfaitement, et cf n'est pas le seul programme a l'utiliser. Tu es encore jaloux et tu veux pas le dire

Non, je ne suis pas "jaloux", cette méthode est un hack. C'est toi qui utilise des méthodes inofficielles pour linker dans les 2 sens. Voilà comment se passe le linkage dans les 2 sens avec un système qui le supporte vraiment (*nix par exemple):

programme principal (prog):
* table d'importation de librairies:
  lib.so
* table d'importation de fonctions:
  foo
* table d'exportation
  bar

librairie (lib.so):
* table d'importation de fonctions:
  bar
* table d'exportation
  foo

Comme on voit, ici, n'importe quel programme exportant bar peut linker avec lib.so. On a donc une vraie librairie dynamique linkable dans le 2 sens. En revanche, voici ce qui se passe dans ton cas:

programme principal (prog):
* table d'importation:
  lib
    0000 //lib::foo
* table d'exportation
  0000 //prog::bar

librairie (lib):
* table d'importation:
  [b][4]prog //erreur fatale![/4][/b]
    0000 //prog::bar
* table d'exportation
  0000 //lib::foo

Regarde la ligne marquée "//erreur fatale!". Ici, tu codes dans la librairie le nom du programme! Si un deuxième programme toto veut linker avec lib (et lui faire utiliser sa fonction bar), il ne pourra pas. Ta librairie dépend de prog. Ce n'est pas du linkage dans les 2 sens, c'est une dépendance circulaire. Pas très propre comme idiome... Et ta librairie n'est plus une librairie parce qu'elle n'est plus utilisable par n'importe quel programme client.

La solution correcte pour passer un callback à une librairie sur un système ne gérant pas le linkage dans les 2 sens (du moins pas sans coder en dur le nom du programme client dans la librairie) est de le passer en pointeur. Dans mon exemple, il suffit de passer &bar en argument à foo. Ça règlerait ton problème avec CF et ExePack.

Je ne vois pas OU est le probleme. C'est le standard de DoorsOs/ PlusShell depuis les premieres versions, et ca marche nicquel, sauf si on fait des Hacks.

Le problème est là:

Kevin Kofler :
Si un deuxième programme toto veut linker avec lib (et lui faire utiliser sa [propre] fonction bar), il ne pourra pas.

C'est pour ça que je dis que c'est un hack.

Mais c'est pas concu pour. Tu veux que la map de cf puisse se linker avec un autre moteur que celui de cf ? C'est pas concu pour!

Et puis ce systeme de linkage dynamique EST l'explication de la mauvaise reputation des libraries dynamiques. En un rien de temps, tu crees des incompatibilites. A les 9 versions de glibs, toutes incompatibles entre elles. Au moins sur Ti, grace a ce systeme, la compatibilite est plus simple a maintenir.

Désolé, mais les incompatibilités de glibc n'ont rien à voir avec le système de linking *nix. La compatibilité binaire est tout aussi simple (ou tout aussi difficile) à maintenir sous *nix que sous PreOs. La raison pour laquelle le problème ne se pose pas sur TI-89/92+/V200 est que les librairies n'évoluent pas ou peu. À l'exception de TIGCCLIB qui, elle, n'a jamais gardé la compatibilité binaire, mais vu qu'elle est linkée statiquement, ça ne pose pas de problèmes.

Nan pas du tout d'accord. Avec la methode sous Nix, on est vraiment plus capable de sortir des incomaptibilites binaires.
Et les libraries evoluent mon cher. Mais elles gardent toujours une compatibilite ascendante.

Ben je dirais pas ça je les aime bien quand même, mais voilà.

Bon, à tout le monde, si on arrêtait de troller ?

Là on s'éclate la gueule pour le dilemme majeure sur TI : NoStub ou Kernel ?

C'est comme la gauche et la droite, ou l'OM et le PSG...





Nan, mais à part ca on s'aime bien quand même...

"la parole du sage"

Pas faux.

Pas touche a mon loisir numero 1: discuter kernel/nostub avec Kevin

Clair, j'adore lire les arguments 200 % pure mauvaise foi (c) Kernel Killer