Un tout nouveau shell pour TI: sh`L - Page 10

Pour toutes les autres libs, je ne vois comment ils réussient a faire un truc plus rapide que TIGCCLIB car c du tres condensé!!!

C'est relativement simple. C'est parce que les routines de sprite de TIGCCLIB (et d'ExtGraph) sont en C, et que les autres sont en ASM. GCC a beau être un assez bon compilateur optimisateur, il ne connaît pas tous les trucs qui sont possibles en ASM. On gagne un peu en vitesse (moins de 20 en réécrivant les routines en ASM, sans changer l'algorithme. En changeant l'algorithme, on peut probablement faire nettement mieux sur certaines fonctions (là, je parle d'ExtGraph, j'ai une idée, qui s'avèrera d'ailleurs peut-être inexploitable, pour deux fonctions), sans modifier beaucoup la taille.

Bon c'est quoi MiaM ??

XDanger> T'a pas vu les sources ASM alors....

>C'est la faute des égoïstes comme PpHd, TiMad, Thibaut et Vertyos qu'il n'y a pas de routines meilleures dans TIGCCLIB.
Je te signale que j'ai ecrit genlib bien avant tigcclib, et que genlib n'a d'interet qu'en librarie dynamique (Les routines se modifient les unes les autres). Donc s'il te plait retire cette accusation. J'ai passe beaucoup de temps (et nitro aussi) a faire une implantation de qualite pour tigcc sous kernel et sous nostub (et toi aussi d'une certaine facon).

J'ai presque triplé la vitesse d'une routine d'ExtGraph en changeant l'algorithme et en réécrivant le tout en ASM. De plus, la routine est plus petite.


PpHd: donc, tu as commencé à écrire GenLib avant 1999 ?
L'implémentation de GenLib en _nostub n'est qu'un vulgaire loader de librairie kernel, non (il y a 68kL dans la librairie...) ? Donc ça N'EST PAS du _nostub. C'est une émulation kernel en _nostub.

Je n'avais pas vu que Kevin avait dit:

C'est la faute des égoïstes comme PpHd, TiMad, Thibaut et Vertyos qu'il n'y a pas de routines meilleures dans TIGCCLIB.

Mais je suis assez d'accord... Il est tout à fait permis de documenter AMS et d'améliorer TIGCCLIB (ce que je dis ne s'adresse pas trop à PpHd qui a amélioré la documentation de certaines fonctions d'AMS dans TIGCC, et il a peut-être fait d'autres choses pour TIGCC).

Ok sympa...

XDanger
a écrit : J'ai presque triplé la vitesse d'une routine d'ExtGraph en changeant l'algorithme et en réécrivant le tout en ASM. De plus, la routine est plus petite.

et les nouvelles routines gèrent le clipping ?

PpHd
a écrit : Je te signale que j'ai ecrit genlib bien avant tigcclib, et que genlib n'a d'interet qu'en librarie dynamique (Les routines se modifient les unes les autres). Donc s'il te plait retire cette accusation. J'ai passe beaucoup de temps (et nitro aussi) a faire une implantation de qualite pour tigcc sous kernel et sous nostub (et toi aussi d'une certaine facon).

Voilà, j'ai édité le message afin de ne plus viser personne directement là. Ce n'était rien de personnel contre toi.

Mais je réitère que cette attitude "On ne fait nos routines que pour nos libs closed-source et on refuse de les contribuer à TIGCCLIB." qui règne généralement m'énerve.

XDanger
a écrit : L'implémentation de GenLib en _nostub n'est qu'un vulgaire loader de librairie kernel, non (il y a 68kL dans la librairie...) ? Donc ça N'EST PAS du _nostub. C'est une émulation kernel en _nostub.

En effet.

Et quel est la différence?

La différence, c'est que ce n'est pas du _nostub, même si PpHd essaye de le faire passer comme tel.

Oui mais niveau utilisation, atout, désavantage etc, ca change quoi par rapport au vrai _nostub ?

C'est en effet complètement transparent pour l'utilisateur, je ne vois pas du tout où est le mal...

En tout cas par rapport a un DLL Nostub ou a la FAT engine il n'y a presque pas de différences.

Si: Le code de chargement de genlib est environ 3 fois plus gros que celui de FAT Engine.

bof c'est pas flagrant la différence et puis de toute façon genlib en nostub c'est pour les idiot qui s'obstinent a refuser un kernel. Depuis PreOS c'est vraiment inutile de refuser un kernel sur sa calculatrice.

>PpHd: donc, tu as commencé à écrire GenLib avant 1999 ?
Fin 1998.

>L'implémentation de GenLib en _nostub n'est qu'un vulgaire loader de librairie kernel,
>non (il y a 68kL dans la librairie...) ? Donc ça N'EST PAS du _nostub. C'est une
>émulation kernel en _nostub.
Je crois que tu confonds "nostub" et librarie dynamique. C'est une lib dynamique au format kernel (en effet, ca embrouillerait tout le monde d'avoir plusieurs versions de lib dynamiques une pour le nostub et une autre pour le kernel).
Un nostub c'est quelque chose sans 'noyau' au debut du programme (ce que ne fait plus les dernieres versions de tigcc puisqu'elles rajoutent par defaut un gros loader - un stub quoi). Ton programme utilisant genlib en nostub sera a 100% nostub ! Mais il aura besoin d'une lib dynamique. Capiche ?

>Mais je suis assez d'accord... Il est tout à fait permis de documenter AMS et
>d'améliorer TIGCCLIB (ce que je dis ne s'adresse pas trop à PpHd qui a amélioré la
>documentation de certaines fonctions d'AMS dans TIGCC, et il a peut-être fait d'autres
>choses pour TIGCC).
Heureusement qu'il y a la parenthese.


>Mais je réitère que cette attitude "On ne fait nos routines que pour nos libs closed
>-source et on refuse de les contribuer à TIGCCLIB." qui règne généralement m'énerve.
1. Je refuse de faire de genlib une lib 100% statique. Rien qu'avec 2 jeux on gagne de la place, et en plus elle est compressee maintenant.
2. Je refuse de distribuer les sources avant la version 1.00.
3. Tigcclib est contre l'emploi des libs dynamiques et des kernels et tu voudrais que je vous aide ? (Je suis vicieux, puisque je le fais quand meme). Au fait je dois te passer quelques 'add-ons' a la doc (de nouveaux).

>Le code de chargement de genlib est environ 3 fois plus gros que celui de FAT Engine.
Moins de 2x.

PpHd a écrit :
>PpHd: donc, tu as commencé à écrire GenLib avant 1999 ? Fin 1998.

Et d'ailleurs TIGCCLIB n'est sortie qu'en 2000, pas en 1999.

>L'implémentation de GenLib en _nostub n'est qu'un vulgaire loader de librairie kernel,
>non (il y a 68kL dans la librairie...) ? Donc ça N'EST PAS du _nostub. C'est une
>émulation kernel en _nostub.
Je crois que tu confonds "nostub" et librarie dynamique. C'est une lib dynamique au format kernel (en effet, ca embrouillerait tout le monde d'avoir plusieurs versions de lib dynamiques une pour le nostub et une autre pour le kernel). Un nostub c'est quelque chose sans 'noyau' au debut du programme (ce que ne fait plus les dernieres versions de tigcc puisqu'elles rajoutent par defaut un gros loader - un stub quoi). Ton programme utilisant genlib en nostub sera a 100% nostub ! Mais il aura besoin d'une lib dynamique. Capiche ?

C'est une librairie en mode kernel, donc il y a un stub, donc ce n'est pas du _nostub. L'exécutable principal a beau être en _nostub, le programme (c'est-à-dire l'ensemble exécutable principal + librairies dynamiques utilisées) ne l'est pas.

>Mais je réitère que cette attitude "On ne fait nos routines que pour nos libs closed
>-source et on refuse de les contribuer à TIGCCLIB." qui règne généralement m'énerve. 1. Je refuse de faire de genlib une lib 100% statique. Rien qu'avec 2 jeux on gagne de la place, et en plus elle est compressee maintenant.

Sauf que les jeux qui utilisent genlib sont en général tellement gros (en comptant les données) que pour en mettre 2 sur une même calculatrice, ce n'est pas gagné.

3. Tigcclib est contre l'emploi des libs dynamiques et des kernels et tu voudrais que je vous aide ?

1. Si on était vraiment contre les kernels, ça ferait longtemps que USE_KERNEL n'existerait plus.
2. Si on était vraiment contre les kernels, Sebastian ne se ferait pas ch*** à coder le support du mode kernel dans son nouveau linker qui remplacera notre système de linking actuel (GNU ld + GNU objcopy + obj2ti) pour TIGCC 0.95. On a déjà un linker 100% fonctionnel pour le _nostub. Le mode kernel fait pas mal de travail en plus. Mais on le fait.

(Je suis vicieux, puisque je le fais quand meme).

Au fait je dois te passer quelques 'add-ons' a la doc (de nouveaux).

OK. Mais je te préviens que ça ne sera probablement pas dans la 0.94 finale, on est vraiment en "deep freeze" là.

>Le code de chargement de genlib est environ 3 fois plus gros que celui de FAT Engine. Moins de 2x.

Non. Le loader de genlib fait environ 3 KO (il suffit de comparer tes programmes exemple en mode kernel et en mode pseudo-_nostub - cf. plus haut pour le "pseudo"). Celui de FAT Engine fait environ 1 KO.

On s'en fout du mistub, du moment que l'utilisateur ne voit pas la différence...

Personnellement je ne fais pas la "course" sur ma TI pour gagner quelques ko, et je pense que ca concerne beaucoup de personne

jackiechan a écrit :
et les nouvelles routines gèrent le clipping ?

Non. En fait, je parlais de SpriteX8_MIRROR_H, pas d'une routine d'affichage de sprite... Désolé !
SpriteX8_MIRROR_V ne devrait pas gagner beaucoup en vitesse avec une réécriture en ASM.
Actuellement, ExtGraph est en __attribute__((__stkparm__)). Il faudrait peut-être que Tom et moi en rediscutions. Mais il faudra deux versions des routines ASM, une __stkparm__ et l'autre __regparm__; deux noms différents pour les deux routines...


>>Mais je suis assez d'accord... Il est tout à fait permis de documenter AMS et
>>d'améliorer TIGCCLIB (ce que je dis ne s'adresse pas trop à PpHd qui a amélioré la
>>documentation de certaines fonctions d'AMS dans TIGCC, et il a peut-être fait d'autres
>>choses pour TIGCC).
>Heureusement qu'il y a la parenthese.
Je ne suis pas bête à ce point. Tu m'as encouragé au moment où je débutais la programmation en ASM pur. Tu ne m'as jamais rien fait, et je t'ai déjà rudoyé pour rien, une fois où ce que Thibaut avait écrit m'avait énervé...

Je crois que tu confonds "nostub" et librarie dynamique. C'est une lib dynamique au format kernel (en effet, ca embrouillerait tout le monde d'avoir plusieurs versions de lib dynamiques une pour le nostub et une autre pour le kernel).

Non, je ne confonds pas _nostub et librairie dynamique. Ce que je reproche à GenLib, c'est d'utiliser une librairie au format kernel, dans des programmes éventuellement en nostub... C'est une émulation kernel, pour le _nostub.
Et il est en effet très sage de ne pas proposer deux version de la lib dynamique, pour ne pas mettre de la confusion...

ce que ne fait plus les dernieres versions de tigcc puisqu'elles rajoutent par defaut un gros loader - un stub quoi

Tu entends quoi par "loader" ?

D'un autre coté, multiplier par 3 la vitesse de la routine d'affichage, ça faisait un peu beaucoup

En effet... Si on multiplie par trois la vitesse d'une routine d'affichage, c'est vraiment que c'était extrêmement mal fait auparavant, ce qui n'est pas le cas d'ExtGraph (les routines sont écrites en C "ASM-like", avec parfois de l'ASM au milieu)...

A quand l'asm pur

Il n'empeche... Vous pourriez faire des routines clippées

oxman a écrit :
Personnellement je ne fais pas la "course" sur ma TI pour gagner quelques ko, et je pense que ca concerne beaucoup de personne

Le problème, c'est que Pphd prétend que genlib (étant une librairie dynamique) économise de la place, alors qu'il en gaspille un peu partout (par exemple le loader à lui seul prend déjà presque 3 KO).

D'ailleurs, les appels de fonctions de librairies dynamiques en mode _nostub (par exemple FAT Engine) ou pseudo-_nostub (par exemple genlib) sont lents. Les appels de librairies statiques sont plus rapides. Donc une librairie dynamique n'est à utiliser que si vraiment il n'y a pas d'autre moyen d'éviter de dépasser les 64 KO, par exemple pour FAT Engine, qui fait déjà plus de 32 KO à elle seule.

Ca fait longtemps que je n'étais pas dans le monde TI, et je n'ai jamais été grand programmer.

Ainsi serais t'il possible que toi (Kevin) ou un autre me détail (de facont objective) ce qu'est réellement une lib statique/dynamique ainsi que sont fonctionnement
Un peu tout cette ensemble quoi

* librairie statique: C'est une archive de fonctions précompilées qui, lors de l'édition de liens, la dernière phase de la compilation au sens large d'un programme, sera "linkée" statiquement au programme, c'est-à-dire que les fonctions de la librairie utilisées directement ou indirectement par le programme (et seulement ces fonctions) seront copiées dans l'exécutable final.
* librairie dynamique: C'est un fichier exécutable autonome qui exporte des fonctions. Ce n'est que lors de l'exécution que le programme sera "linké" dynamiquement à cette librairie, c'est-à-dire que les références vers des fonctions de la librairies seront relogées de manière à pointer à l'endroit où se trouve la librairie en le moment donné. Les désavantages de cette solution sont:
- Même les fonctions inutilisées devront être présentes sur la calculatrice, parce que les librairies dynamiques ne peuvent en général pas être découpées contrairement aux librairies statiques.
- Si plusieurs versions de la librairie dynamique existent, il faut faire attention à la compatibilité entre ces versions, d'une manière ou d'une autre (soit il faut maintenir la compatibilité antérieure, soit il faut renommer la librairie, sinon c'est le chaos).

Nanani nanana. J'ai pas envie de discuter. Et la compatibilite doit exister aussi pour les libs statiques sinon c'est le merdier pour les programmeurs. Evidemement on s'en fout.

PpHd
a écrit : Et la compatibilite doit exister aussi pour les libs statiques sinon c'est le merdier pour les programmeurs.

1. La compatibilité source suffit pour les librairies statiques. Pour des librairies comme TIGCCLIB, entre compatibilité source et compatibilité binaire, il y a une différence énorme de flexibilité!
2. Si la compatibilité source n'est pas maintenue pour une librairie statique, personne n'empêche les programmeurs de garder la version d'avant (sauf évidemment s'il y a des bogues qui ne sont corrigés que dans les versions incompatibles, mais là, c'est chez l'auteur de la librairie statique qu'il faut se plaindre, il devrait au moins sortir des mises à jour de maintenance pour les anciennes versions, ça ne devrait pas être trop dur). L'utilisateur ne remarquera même pas qu'une ancienne version est utilisée!