TIGCC 0.95 Beta 2 pour Windows - Page 1

1. Pour LInux, c'est pour quand ?
2. Tu as corrige tous les bugs reportes ?
3. Je ferais mieux d'aller sur le forum de la tict au lieu de poser des questions.
4. MEa culpa.

PpHd
: 1. Pour LInux, c'est pour quand ?

Quand j'aurai le temps.
Probablement ce weekend seulement.

2. Tu as corrige tous les bugs reportes ?

J'espère...
En tout cas, ton problème avec set_ld.i est corrigé (réécriture des routines de floats). Et les librairies kernel en C marchent aussi. (Les DLLs _nostub ont aussi été corrigées, d'ailleurs.)

Avez-vous modifié les routines de dialogs dans la 0.95 par rapport à la 0.94? (pour le support des dialogs statiques par exemple) ? Parceque je me demande si j'ai pas mis le doigt sur un bug ... Je fouille ça ...

Non, les mises à jour n'ont pas encore été mises. Je ne pense pas que le problème soit dans dialogs.h.

ok c'était moi.
Sinon toujours pas de -freg-relative ?

Si, -freg-relative a été réimplémenté (adapté au nouveau linker). Backgammon compile sans problèmes en -freg-relative. Seul problème: pas toutes les références sont reg-relative, il y a des move.l #label,... et même des move.l ...,label non convertis qui traînent. Il faudra que j'aille voir pourquoi GCC fait ça. Mais ce n'est certainement pas un bogue nouveau (une régression) par rapport à GCC 3.3 utilisé avec TIGCC 0.94, et probablement pas non plus par rapport à GCC 3.2.1.

et ça s'appelle comme avant ? freg-relative-an ? vais tester ça tiens

Ximoon
: et ça s'appelle comme avant ? freg-relative-an ?

Oui, tout est comme avant.

ok au poil
faut "merger" le BSS bien sûr

Ou compiler carrément avec -mno-bss.

Comment qu'on fait pour avoir du freg-relative qu'avec la section BSS ?

On ne peut pas. -freg-relative ne gère pas du tout les BSS, même. Le point auquel c'est relatif est __ld_entry_point+0x8000.
Il te faudra un patch supplémentaire à GCC pour avoir ce que tu veux. Et il faut aussi que le compilateur ait un moyen de savoir lesquelles de tes variables sont en BSS.

Ou alors tout reference a la section data passe par freg-relative ?

Il y a toujours le bug du "Pas de disque dans le lecteur x:"

PpHd
: Ou alors tout reference a la section data passe par freg-relative ?

Là encore, il faut que le compilateur sache que le target est dans la section de données. C'est probablement faisable de manière plus précise du côté du linker. Mais ça doit aussi être possible du côté du compilateur. Mais je veux voir un patch, pas juste des requêtes de fonctionnalité. Ce ne sera très probablement pas moi qui implémenterai le support des applications PedroM.

Oui, mais je veux savoir si c'est faisable avant. Pour pas que je perde mon temps a faire un patch horrible, gros et immonde.

Bon Kevin arrête moi si je me trompe mais:
-Dans la doc il y a marqué que -fomit-frame-pointer est activé par -Os or ça n'est pas vraiment le cas selon les quelques tests que j'ai pu faire
-La source suivante génère le code encore suivant (bon ça n'a pas forcément de rapport avec la 0.95b2 mais je suis sûr que ça te fais plaisir de voir que tigcc peut sortir une instruction intelligente de temps à autre).

#include <tigcclib.h>
//  -Wall -W -Wwrite-strings -Os -fomit-frame-pointer
void _main(void)
{
char * plane0 = LCD_MEM;
short y=400;
		do{
				 *(plane0+2*y)=0;
		} while(y--);
}

__main:
	move.w #400,%d0
.L2:
	move.w %d0,%a0
	add.w %d0,%a0
	[b]move.w %a0,%a0[/b]
	clr.b 19456(%a0)
	dbra %d0,.L2
	rts

ou alors c'est une optimisation qui m'échappe ...

edit: ça le fait aussi en -O2, mais en -O3 ça sort un autre code pessimisé

Ximoon :
Bon Kevin arrête moi si je me trompe mais: -Dans la doc il y a marqué que -fomit-frame-pointer est activé par -Os or ça n'est pas vraiment le cas selon les quelques tests que j'ai pu faire

Ce n'est pas le cas, il faut le mettre explicitement.
Je ne sais pas où tu as lu ça, mais c'est faux, et ce n'est probablement pas de notre faute (ça doit être dans la documentation de GCC, qui est "importée" de gcc.gnu.org, tout comme le reste de GCC).

-La source suivante génère le code encore suivant (bon ça n'a pas forcément de rapport avec la 0.95b2 mais je suis sûr que ça te fais plaisir de voir que tigcc peut sortir une instruction intelligente de temps à autre).

#include <tigcclib.h>
//  -Wall -W -Wwrite-strings -Os -fomit-frame-pointer
void _main(void)
{
char * plane0 = LCD_MEM;
short y=400;
		do{
				 *(plane0+2*y)=0;
		} while(y--);
}

__main:
	move.w #400,%d0
.L2:
	move.w %d0,%a0
	add.w %d0,%a0
	[b]move.w %a0,%a0[/b]
	clr.b 19456(%a0)
	dbra %d0,.L2
	rts

ou alors c'est une optimisation qui m'échappe ...
edit: ça le fait aussi en -O2, mais en -O3 ça sort un autre code pessimisé

C'est une extension de signe. On jette le word de poids fort et on le remplace par l'extension de signe de celui de poids faible. Cette instruction n'est pas redondante.

pour moi le move.w d0,a0 provoque déjà une extension de signe, pourquoi en rajouter une ?

et pour le -fomit-frame-pointer:

Options That Control Optimization

-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines (the Motorola 68000 used in TI calculators is such a case).

Note, however, that you must not use this option if you use floating point operators: The TIOS routines for floating point arithmetic assume that the frame pointer is always present!

Enabled at levels '-O', '-O2', '-O3', '-Os'.

C'est une erreur de la doc alors.

Sinon, non c'est pas tout a fait redondant dans le cas general. Mais dans ce cas particulier, je crois que oui.

pour moi le move.w d0,a0 provoque déjà une extension de signe, pourquoi en rajouter une ?

Pas s'il y a overflow.

Oui mais y'a le add.w d0,a0 qui corrigera cet overflow

Je sais que ma question est un petit peu hors-sujet, mais j'aimerai savoir si on peut compiler des DLLs nostub avec l'IDE et si oui, où se trouve l'option.
Si ça se trouve c'est une question très conne, mais j'ai eu beau chercher, je n'ai pas trouvé. Et puis comme le linker est une dll, c'est assez difficile d'y accéder manuellement

C'est une erreur de la doc alors.

Que j'ai déjà signalée d'ailleurs, m'enfin bon

Ximoon
: pour moi le move.w d0,a0 provoque déjà une extension de signe, pourquoi en rajouter une ?

Parce qu'il y a un add.w %d0,%a0 entre les 2.

PpHd :
Oui mais y'a le add.w d0,a0 qui corrigera cet overflow

Justement non, c'est ce qui le provoque!

GoldenCrystal
: Je sais que ma question est un petit peu hors-sujet, mais j'aimerai savoir si on peut compiler des DLLs nostub avec l'IDE et si oui, où se trouve l'option.

Tu sais, savoir lire, ça aide...

Oula a Kevin a presqu été méchant dans une kernion ou y'avait nostub dedans

Sinon j'ai un warning du genre: Startup code added into library c'est du a quoi ca?

Génère-t-elle enfin l'instruction mulx pour multiplier des nombres sur 16 bits ?