bah, a la limite, l'idéal est l'utilisation de fichiers séparés...
un en Os pr les menus, un en O3 pr le moteur, par exmepple..;
C'est stupide vouloir mettre O2 ou O3 par défaut, Os est vraiment un point fort de gcc ...
> Mais c'est koi tes instructions bizares? Une subroutine pour la multiplication?
Non, c'est un HeapDeref "manuel" à partir d'un registre, en l'occurence a4 où j'ai mis "HeapTable". C'est pour ça que je citais HeapDeref.
GCC générait des opérations sur des longs (inutiles, mais il ne peut pas le savoir). Comment pourrait-on lui faire comprendre que le tableau ne fait que 8000 octets et qu'il n'est pas censé avoir des élements d'index négatifs ?
Quoi qu'il en soit, j'ai gagné au moins 100 octets en recodant avec de l'ASM inline avec opérandes C ces HeapDeref "manuels".
Je pense que tthdex serait au moins 2 KO plus gros que ce qu'il n'est actuellement (moins de 12 KO) si je n'avais rien optimisé. Et je réfléchis à faire une global register variable (ça n'est pas pour tout de suite). La table de relocations est assez petite, mais on pourrait presque tout supprimer avec une global register variable. Comme je n'utilise plus OPTIMIZE_ROM_CALLS car j'utilise les ROM_CALLs en F-Line, je peux récupérer a5. Il faut aussi voir si je conserve "HeapTable" dans a4 dans tout le programme, vu que maintenant, avec les ROM_CALLs en F-Line, il est plus avantageux en taille d'utiliser un HeapDeref en ROM_CALL que d'utiliser un HeapDeref "manuel".
Je vais continuer dans la mesure du possible à faire comme Thomas: utiliser la release de TIGCC pour les releases. Pour moi, ça sera 0.94, patchée si nécessaire (si un gros bug est trouvé). Avant c'était 0.93 patchée pour la détection des V200, d'AMS 2.08, etc.
Après, il faudra voir au cas par cas, en fonction du type de programme et de ce dont il a besoin. Par exemple, TICT-Explorer tirera profit d'un GCC 3.3 et du nouveau linker, mais il a de toute façon besoin de nombreuses optimisations à la main auparavant... Je vais lui appliquer quelques trucs que j'ai déjà appliqués avec succès dans tthdex, notamment l'optimisation des tableaux de strings. Ca a gagné des centaines d'octets dans tthdex, et TICT-Explorer a plus de tableaux de strings que tthdex.
Si j'arrivais à réduire à moins de 20 KO le fichier tictexpl (ce qui est loin d'être fait et qui n'est peut-être même pas possible), ça serait bien.
Je n'utilise -Os que rarement, mais il est en effet stupide de mettre -O2 ou pire, -O3 par défaut... Ca va générer un code plus gros, voire énorme si on a -O3. Et avec -O3, il faut faire attention notamment aux problèmes d'inlining (déclarer les routines courtes en assembleur __attribute__((__noinline__)), etc.)
Personnellement, même les programmes pour PC, je les compile en -Os. Par exemple, les programmes C de TIGCC (y compris GCC) sont tous compilés en -Os.
> Oui, mais c'est normal de leur part de faire ça, il ne veulent toucher que les programmeurs PC, et dans ce cas là, ils s'en foutent de la taille malheuresement...
Malheureusement...
Il faut dire que si les PC était mieux faits (l'assembleur x86 est horrible comparé à l'assembleur 68k, mieux conçu, plus puissant à l'origine et plus clair...), il y aurait moins besoin de vitesse !
C'est en effet à cause du nouveau linker que je préfère attendre avant d'utiliser TIGCC 0.95 Beta pour les releases. Ca m'étonnerait qu'il y ait d'énormes problèmes, mais bon...
Kevin, ça changerait beaucoup la taille si tu compilais en -O2 ? On n'en est pas à 200 ou 300 KO près, i.e. une minute de téléchargement, sur 4 MO de toute façon...
En revanche, pour les sources, je pense qu'il faudrait fournir une version des sources sans le système d'aide, qui représente à lui seul, même compressé, plus de la moitié de la taille des sources.
1>Je suis désolé, mais moi il me fait les quatre opérations. Peut-être que si c'est un non-signé qu'on multiplie par 30, il fait les 4 opérations, sinon un muls (à verifier).
Seb C bien
C bien, C beau, C ni Bosch ni Bush: C ++
1. Peut-être qu'il faudrait attendre que Kevin Kofler distribue la version corrigée pour que tu puisse vraiment essayer...
Jackie> Il a dit "avait", c'était référence aux versions précédentes, il contestait l'existence du "bogue" avec 30.
Seb C bien
C bien, C beau, C ni Bosch ni Bush: C ++
Pour l'histoire du btst, il y a des personnes qui sont en train de travailler sur un patch pour GCC 3.3 qui améliorera entre autre le support pour btst, donc je vais attendre ce qu'ils vont nous sortir et essayer d'adapter le patch (le porter du Coldfire, un dérivé du 68k à jeu d'instructions réduit, vers le 68000).
je vais peut essayer de réecrire les fonctions de sprite
1) en tenant compte de vos remarques
2) en me basant sur la source de tigcc
(l'idée première est de me satisfaire de mes moyens préhistoriques on-calc, mais je doute que mes fonctions vous soient très utiles)
Par exemple, il n'y a pas vraiment d'optimisations spécialement conçues pour optimiser en taille, -Os ne fait que désactiver les optimisations qui pessimisent la taille et changer quelques paramètres dans les autres.
Par exemple, il n'y a pas vraiment d'optimisations spécialement conçues pour optimiser en taille, -Os ne fait que désactiver les optimisations qui pessimisent la taille et changer quelques paramètres dans les autres.
)
), elles ne vous toucheront pas du tout.
