TIGCC 0.94 Beta 15 - Page 1

La bêta 15 de TIGCC 0.94 est sortie ce matin. Au programme:
- GCC 3.1 (le dernier prerelease, et il n'y a pas eu de changements entre ce prerelease et la version officielle - à part un patch dans le backend pour une plateforme qu'on n'utilise pas)
- Un AS.EXE qui ne plante pas.
- Documentation de plusieurs nouveaux ROM_CALLs.
- Fonctions de shifting, division et modulo de long longs.
- Une fonction assert qui marche.
- Possibilité de renvoyer des erreurs vers AMS sans avoir des ennuis avec les programmes pas délockés correctement ou des trucs comme ça. Mais ne râlez pas: le code supplémentaire pour ça est désactivé par défaut. Il faut mettre un #define.
- Pour ceux qui ont essayé la bêta 14 hier: Plus de bogue avec les programmes pour kernel et TIGCCLIB.

Ce qui est nouveau dans GCC 3.1:
- de nouvelles optimisations
- __attribute__((__deprecated__)) pour générer un warning à chaque fois qu'un identifiant est utilisé - c'est une alternative à #pragma poison qui donne carrément des erreurs
- possibilité de prendre l'adresse des constructeurs par transtypage même si l'initialisateur n'est pas constant
- correction d'un bogue dans le patch TIGCC qui empêchait de prendre l'opposé d'un nombre complexe

C'est quand meme relou la disparaition du .comm _nostub,2
Vais essayer avec cette version.

Ca ne change strictement rien a mon programme. (Tigcc beta 15).

Nouvelle bêta (bêta 16):
- -mregparm fonctionne maintenant correctement.
- GCC ne donne plus de warning pour printf("%lx",ptr) parce que c'est la syntaxe attendue par la fonction de AMS appelée par l'implémentation de printf dans TIGCCLIB.
- Les DLLs en mode _nostub (à n'utiliser que si votre programme dépasserait les 64 KO si vous ne les utilisiez pas) sont maintenant officiellement documentées.

erf
encore une version à dl
raménerait ça pr le Week-end prochain
(si y'a pas une nouvelle bêta d'ici là)

le mregparm, c pr les passages de param pr registre automatique, non ?
(des 3 trucs, c le seul qui m'interesserait éventuellement)

squale92 a écrit :
le mregparm, c pr les passages de param pr registre automatique, non ? (des 3 trucs, c le seul qui m'interesserait éventuellement)

Oui.


Au fait, la bêta 17 vient de sortir, mais il n'y a pas eu de changements dans les binaires par rapport à la bêta 16. Juste:
- mise à jour du patch (dans les sources) pour Binutils. Sebastian avait oublié de mettre à jour le patch après mon dernier changement de 4 lignes pour permettre exg.l comme synonyme à exg.
- petite correction dans l'exemple pour les DLLs _nostub: Le programme demandait un numéro de version plus grand que celui dans la DLL, donc ça ne marchait pas.

BOUHHHHHH ! mon progamme fait 400 octets de plus avec la beta 17 .
Avec ce que je me fait chier optimiser...

400 o de plus par rapport à quelle verson ?

par rapport à la beta 12, ça doit être GCC 3.1...

moi, j'ai gagné 40 octets sur un programme de 45ko en passant à GCC3.1
(en fait,20o en psssant à GCC3.1, puis 20o en passant à TIGCC.15)

Le seul pogramme ou j'ai gagné quelque chose, c'est une petite lib, j'ai un gain de 40 octets environ. Pi aussi ttstart, qui maigrit de 60 octets.
Mais mon prog de 17 kO, lui, il grossit

mon prog de 45k diminue en taille
(en -O3 -W -Wall -fomit-frame-pointer -fno-function-cse je crois)

put1, si je le mais en -O3, il prend 1 kO !, -Os powwaaaaaa

arf...
ce que tu peux faire, c couper ton source en plusieurs fichiers...
dans l'un, tu met le moteur, qui abeosin de ra^pidité, et tu compile en -O3
et dans l'autre, tu met le reste, en -Os

c'est ce que j'ai fait pr K, et ce que je ferai pr la finalle de KII

(c chiant, faut le faire via un .bat, et non pas depuis l'IDE)

Bof, c'est de la comptabilité, donc pas besoin de -O3, d'ailleur, la différence de vitesse est vraiment pas évidente avec -Os

moué...
sinon, pr gagner en rapidité si tu utilises très peu de ROM_CALL, tu peux ne pas mettre le OPTIMIZE_RO_CALLS... de la sorte, tu devrai libérer le dregistre a5
et si tu veux gagner en mémoire, en perdant (un tout petit peu) en rapidité, tu peux utiliser le 1111 emulator

bof, enlever OPTIMISE_ROM_CALLS fait grossir le prog de 800 octets, et le FLINE_EMULATOR ne change rien (pareil en kernel et _nostub)

C'est:
#define USE_FLINE_ROM_CALLS
#define USE_INTERNAL_FLINE_EMULATOR
Si tu fais une faute de frappe là-dedans, les #defines ne seront pas reconnus.

ah, ben j'avais mis #define USE_FLINE_EMULATOR..., j'avais mal lu la doc

Par contre, avec ça, il compile plus :
1 undefined reference to '_ROM_CALL_5E'
1 undefined reference to '_ROM_CALL_197'
2 undefined reference to '_ROM_CALL_1A9'
.....

Y en a 16 comme ça

Si, Si, il compile, mais seulement en mode kernel ,
C'est bête pour les antis-kerneleux de TIGCC-Team (dont toi)

Apparement, c'est ça : #define USE_FLINE_ROM_CALLS qui fait déconner

LIS LA DOCUMENTATION!

Il faut rajouter dans les options du compilateur: -fno-function-cse.

ah, ben vi, excuse moi , mais ça serait bien de mettre ça en automatique dès qu'il y a le define

Ce n'est pas pratiquement implémentable.

ben ça marche bien en mode kernel sans cette option...

C'est parce que le kernel sait reloger un lea _ROM_CALL_5E,a0.
Pour que ça marche en _nostub, il faut interdir au compilateur de faire ça. Avec -fno-function-cse, il ne génèrera que des jsr _ROM_CALL_5E qui peuvent être transformés en des appels par ligne 1111 (F).
D'ailleurs, même en mode kernel, cette option peut créer des programmes plus petits parce que tous les ROM_CALLs pourront être tranformés en des appels par ligne 1111, pas seulement quelques uns.

Kevin Kofler
a écrit : Ce n'est pas pratiquement implémentable.

Mauvais linkeur la

Le linker n'y est pour rien! Ce qu'il a demandé devrait être implémenté dans GCC, ou dans l'IDE et dans TIGCC.EXE!

AU fait KK, qu'en penses-tu que sortira la version officielle ?
Sinon, j'ai recupéré la dernière Beta.