1

A quand genSlib pphd ?

parck moi j'ai juste besoin de routines d'affichage de sprite encore + rapide k dans extgraph, c'est tout !
(et k je veux rester à faire un prog 100% nostub)

D'ailleurs C pas poss de faire les routines en asm inline pour booster encore + ?

2

Il ne faut pas espérer d'avoir genlib converti en une librairie statique avant que TIGCC ne supporte la création de librairies statiques avec A68k. PpHd ne va pas s'amuser à réécrire toute sa librairie avec GNU as.

Et même quand (si?) les librairies statiques avec A68k seront supportées dans TIGCC, la décision de sortir une genlib statique dépend uniquement de PpHd, et en ce moment, d'après ses commentaires précédents, il n'a pas l'air favorable du tout.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

3

c clair je m' attendais a k ca soit pas faisable

egalement, meme si c'etait faisable je doute plus k fortement k pphd le veuille (ce ki est tout à fait comprehensible d'ailleurs)

bon tant pis je me contenterais d'extgraph... c quand meme assez rapide je trouve, le prob c'est k j'ai pas de point de comparaison avec genlib.

faudrait k pphd fasse des bench comme dans les démos incluses dans extgraph.a

4

Et il a bien raison !
Mais bon, ne partons pas en couilles sur le débat stub/nostub.
Sainte Marie mère de Dieu
Priez pour nous pauvres pêcheurs
Maintenant et à l'heure de notre mort

Amen.

5

#crayin# Le maitre a dit qu'il ferais un genlib pour le nostub, mais pas en librairie statique ...

6

Ben moi aussi ça m'interreserait des routines d'affichage de sprites + rapides que celles d'extgraph, ms en C je crois pas que ce soit possible...
Bon c vrai g un peu modifié celles d'extgraph pour qu'elles soient + rapides en niveaux de gris, mais faudrait en avoir en asm (moi et l'asm...grin), si qqn voudrait bien nous en faire unewink

7

Moi smile
Assymetric Suçon Megabitte RULEEEZZZZZ
Sainte Marie mère de Dieu
Priez pour nous pauvres pêcheurs
Maintenant et à l'heure de notre mort

Amen.

8

Skulk> bah tu peut utiliser genlib (ou genclib), c'est fait pour ca smile

Et de toute facon, nostub sucks wink

9

OUéé j'suis d'accord cool
_nostub SUXXXX bang
Sainte Marie mère de Dieu
Priez pour nous pauvres pêcheurs
Maintenant et à l'heure de notre mort

Amen.

10

Dark> ben oui ms le pb c que g commencé mon jeu sans genlib, et il faudrait tout réécrire avec genlib pour pouvoir l'utiliser...
Sinon je suis d'accord: vive les kernels!grin

11

Kevin: Il ne faut pas espérer d'avoir genlib converti en une librairie statique avant que TIGCC ne supporte la création de librairies statiques avec A68k.
Ce n'est pas un gros probleme.
J'ai deja fait un prog qui passe de l'asm GNU a a68k. Le contraire aussi devrait etre facile.

>les librairies statiques avec A68k seront supportées dans TIGCC, [...] il n'a pas l'air favorable du tout.
Tout a fait.
Une librarie se doit d'etre dynamique pour etre independante du programme.
C un minimun de programmation objet.

Autre probleme: L'imbrication des fonctions entre elles. C'est pas pour dire, mais appeller une fonction sous-entend appeller pas mal d'autres fonctions a cause de ce truc...

Sinon, j'ai deja fait le bench (Avec le vieux sprite extension).
Genlib est juste '2x' plus rapide.
Je sais c peu. Mais c pas si facile.

12

C deja pas mal je trouve !
je ne pensais pas k tu allais 2 fois + vite k'extgraph !!

13

Sans probleme !
Et encore, les fonctions affichant des plans, permettent de monter entre 3 et 4x plus vite.

14

Non, c moi qui l'ai fait en premier :P

15

Marrant, on est nombreux à avoir fait le même programme apparament smile

16

bandes de voleurs !
c mon programme !

scrogneugneu !

17

Et puis moi je vais le distribuer :P

18

Et je le distriburais avant vous.
Suffit que je le retrouve...

19

Trop tard je viens de l'envoyer à ti-fr smilesmilesmile

20

Arg !
Le mechant.
....
Bah avec le temps qu'il comprenne a quoi il sert, je le sortirais sur mon site grin

21

devinez quoi !
moi j'avait fait un prog qui convertit asm68k -> asmGNU.

je pense que convertir genlib en static serait debile.
si tu le fait pphd je te raye de ma liste de gens respectables.
desolé aghnar il y a de bien meilleurs solutions.

22

>segaman :desolé aghnar il y a de bien meilleurs solutions.

Ah ouais ben c'est lesquelles ?
Sachant k je prog en C / nostub, et k j'utilise extgraph, je vois vraiment pas ou trouver des routines d'affichage + rapide !!!

tu veux peut etre me faire comprendre :
"passe en mode kernel avec genlib" ?
Désolé mais c'est non dans ce cas.

23

la meilleurs solution c'est d'apprendre l'ASMwink

24

Aghnar>
Je crois que tu (et d'autres), n'a (ont) pas compris que si genlib etait en static librairie, ca ferais perdre plein de place sur le calc !
Non, mais c'est vrai, koi, imagine, j'ai sur ma calc, Total Destruction (forcement), SMA (parceque c'est le meilleur jeux actuel), Chrono (parceque c'est le meilleur jeux futur), et ton jeux (puisque c'est le but du debat).
Ca me fait d'apres une estimation grossiere 40%+80%+90%+30%= 240% de genlib !!!
Soit une perte de 140%de genlib = ~30Ko

Je vois vraiment pas pourquoi PpHd, toi, et moi feroins une betise pareille ...

PS: bah oui, ce deja ce qui se passe avec ExtGraph ou avec TiGCC roll

25

Oui, mais imagine un utilisateur ayant un seul jeu utilisant genlib, les autres jeux qu'il possède utilisant d'autres routines que leurs programmeurs considèrent mieux adaptées à la situation (et il y en a: AMS, TIGCCLIB, ExtGraph, graphlib, ...). Si c'est un jeu n'exploitant pas toutes les possibilités de genlib, mais seulement 30%, cela fera 70% de genlib inutiles, soit 12 KO de gaspillés. Considère maintenant que ce jeu soit le seul nécessitant un kernel. Cela fera encore 12 KO de plus, donc 24 KO.

Ton scénario est extrème. Peu de gens rempliront toute la mémoire de la calculatrice avec les énormes jeux qui utilisent tout le potentiel de genlib, notamment SMA et Chrono. De plus, en supprimant Chrono qui n'existe pas encore, on n'en serait (en admettant que tes approximations soient correctes) qu'à 150% de genlib présents sur la calculatrice si genlib était une librairie statique, donc un gaspillage de seulement 9 KO, beaucoup moins que dans mon scénario.

De plus, une librairie statique peut être compressée avec ExePack avec le reste du programme, une librairie dynamique ne peut pas être compressée (même pas avec RunC, à moins d'utiliser un archive composé à décompresser manuellement avant de lancer le programme, un gaspillage de temps et de mémoire). Donc, en admettant un facteur de compression de 33% (le taux mesuré pour la compression d'exécutables dans mes tests de compression, qui ont aussi montré que ExePack compresse légèrement mieux que RunC, mais la différence se mesurant en octets), la perte due aux librairies dynamiques dans mon scénario est de 100-30*2/3=80% de genlib + le kernel, c'est-à-dire de 14+12=26 KO, alors que le gain dans le scénario opposé (en retirant encore Chrono, qui n'existe pas encore et que peu de gens auront sur leur calculatrice en même temps que SMA pour des raisons de place) se réduit à 150*2/3-100=0% de genlib, c'est-à-dire rien du tout. Et je n'ai pas compté le kernel que l'on pourrait supprimer dans ce cas, ce qui épargnerait 12 KO.

Même dans ton scénario original comprenant à la fois SMA et Chrono, où les librairies dynamiques épargneraient 240*2/3-100=60% de genlib, c'est-à-dire 11 KO, si on prend en compte le fait que les librairies statiques permettent de se débarasser du kernel, l'utilisation de librairies statiques épargnerait en fin de compte 1 KO!

Donc, d'après mes calculs, les librairies statiques consomment, sauf cas vraiment extrêmes, moins de place (26 KO de moins dans le scénario où un seul jeu utilise genlib, et seulement 30% des fonctions).

attention LES DIFFÉRENCES ENTRE LES CALCULS DE DARK ANGEL ET LES MIENS MONTRENT COMMENT IL EST FACILE DE MANIPULER LES STATISTIQUES DANS UN SENS COMME DANS L'AUTRE. SACHEZ QUE CHACUN DE NOUS VEUT MONTRER QUELQUE CHOSE, ET QUE DONC, MÊME EN RECHERCHANT UN MAXIMUM D'OBJECTIVITÉ, LES CHIFFRES DIFFÈRENT DE MANIÈRE IMPRESSIONNANTE.
[edit]Edité par Kevin Kofler le 15-06-2001 à 00:06:04[/edit]
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

26

Les sources de mes chiffres:
taille de genlib: la version incluse avec Total Destruction beta 0.7
pourcentages d'utilisation de genlib: les approximations de Dark Angel
taille du kernel: taille de Universal OS 1.30 (install+kernel)

Tous les chiffres ont été arrondis au KO près.

Vous pouvez vérifier mes calculs, je ne crois et n'espère pas avoir fait d'erreurs de calcul. Dans le cas contraire, n'hésitez pas à me corriger.
[edit]Edité par Kevin Kofler le 15-06-2001 à 00:06:45[/edit]
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

27

Kevin >

Evidemment que mes calculs sont extremes wink

De toute facon, les differences ne sont pas tres importantes (quelques % de l'achive totale) ...

28

>Kevin: C'est comme je t'ai deja dit. Les static optimisent la place pour un progamme. Or l'optimisation maximale de chaque programme n'est pas recommande pour que leur somme soit minimale. Cf comparaison RISC et CISC.

Ensuite une librairie dynamique ne peut pas (encore) etre decompresse au debut du lancement du programme. Faut attendre Runc v1.50 avec son paquet LIBRARIES contenant une archive des librairies compresses :P (Pas complique mais j'ai la flemme).

>ExePack compresse légèrement mieux que RunC, mais la différence se mesurant en octets
Tout a fait. La difference est en faveurs de Exepack mais pas enorme.

Personnelement je possede pas mal de prog utilisant genlib. Pas mal de beta aussi grin

>Kevin: Pourquoi tu dis toujours qu'un kernel prend 12 Ko ? Moi c 3 Ko !!!

Et puis de tout facon, genlib est adapte au programme de ma calc, et j'en demande pas plus.
Faut vraiment que je fasse un programme (nostub to kernel program' qui vire toutes les libs statiques et les remplacent par des dynamiques, corrige tous les appels en rom.

29

de vttes façons dans uniOS c'est pas le kernel qui prends 12ko, c'est les librairies intégrées (dynamiquesgrin), qui prennent de la place...

30

>PpHd: >Kevin: Pourquoi tu dis toujours qu'un kernel prend 12 Ko ? Moi c 3 Ko !!!

Bon, ça dépend du kernel. (J'ai utilisé Universal OS dans mes calculs parce que c'est le plus récent.) Effectivement, si les seuls programmes nécessitant un kernel que l'on utilise sont ceux qui utilisent genlib, un kernel plus petit pourrait être une meilleure idée (en tout cas si on veut consommer le moins de place en mémoire possible) que Universal OS qui intègre d'autres librairies.

>PpHd: Faut vraiment que je fasse un programme (nostub to kernel program' qui vire toutes les libs statiques et les remplacent par des dynamiques, corrige tous les appels en rom.

Tiens, moi j'ai une idée de projet dont je n'arrive pas à me débarasser (même si je me dis à chaque fois que c'est inutile, et que je ne l'ai par conséquent même pas commencé): faire un linker qui fasse exactement le contraire de ce que tu veux faire... (linker statiquement toutes les librairies dynamiques, remplacer les RAM calls par des routines en _nostub, corriger tous les appels en ROM dans l'autre sens et sortir un programme en _nostub comme résultat)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité