> tu as pas vu l'état de ta pile avec TIGCC?
"Argument" douteux. La pile a en général ~LCD_SIZE octets pour SAVE_SCREEN, mais ce n'est pas un problème pour la plupart des programmes. Et quand c'est un problème, il y a toujours HSR, qui fait une centaine d'octets: pas de quoi fouetter un chat.
La pile est un espace à part, il n'est pas comptabilisé dans la quantité de RAM disponible (allouable).
Et le linker fonctionne...
Cross de 4 posts pour moi (#25 -> #29)...
Ca ressemble à un test et un troll monstre, ça. La dernière phrase n'a aucun sens: pourquoi rajouter la taille de trucs qu'on n'utilise pas ?
Link Le 01/08/2005 à 12:49 C'est pour les rajouter dans l'autre: Si tu dis que genlib prend de la place, tu dois compter la place qu'il faudrait au programme pour faire la même chose sans (cad le tilemap engine) avant de comparer les tailles des deug programmes.
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
je trouve que le kernel permet une programmation plus propre en rejettant le plus de hacks possibles dans un seul programme. l'argument mémoire reste assez bidon je trouve, vu que la plupart des gens ont toujours assez de ram libre. alors, avoir 150ko de libres au lieu de 160, ça ne change pas beaucoup ^^
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
#33, #34: si, j'ai compris, mais vu que le tilemap engine d'ExtGraph est utilisé par très peu de programmes, ça s'appelle pénaliser artificiellement une façon de faire... Parmi les programmes utilisant ExtGraph, une proportion non négligeable n'en utilise qu'une partie négligeable.
> mais avec deux trois programmes sur la calc, on s'y retrouve vite...
Il en faut un peu plus que ça... Le stub des programmes AMS native prend au plus quelques centaines d'octets (souvent ~130 de trop à cause de __need_in_use_bit; inutiles, en plus d'options souvent inadaptées mais malheureusement défaut comme l'utilisation de BSS), le kernel + stdlib prennent 30 KB.
Le bout de programme le plus redondant entre les programmes est la routine de grays, mais TI a fait ce qu'il faut pour qu'il coûte souvent plus cher de la mettre en externe et de la lancer que de la mettre en interne (taille du code de recherche et lancement + désoptimisation due aux adressages xxx.l relogés vs. d(pc) non relogés).
chez moi, ça ne prend que la place de Preos + les 4 libs dont j'ai besoin ^^ pas besoin de stdlib !
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
Cross, j'avais lu jusqu'à #42.
#43: pour y gagner, il faut quand même le faire... Poids du kernel lui-même (> LCD_SIZE) + poids des parties inutilisées des libs + poids ajouté dans le code comparé à du linké statiquement (xxx.l relogé au lieu de d(pc))...
Nouveau cross.
#46: ce qui fait quand même au moins 6 KB, c'est à dire une dizaine des plus gros stubs...
sauf que les appels aux libs ne sont pas toujours très nombreux, donc les xxx.l relogés ne prennent pas forcément énornément de place ^^
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
A ce moment-là, les fonctions linkées statiquement non plus...
PpHd Le 01/08/2005 à 14:36 J'ai un enorme doute : ce topic est-il un enorme troll ou y'a-t-il quelqu'un dans le besoin ?
Et c'est #2 (myself) qui commence, suivi par les autres...
!
