AZUR - Page 3

Mais c'est encore mieux que ce que je pensais ton truc ... Bon courage pour la fin ...

squale92 :
val1472 : tu pensais quoi ?
[edit]Edité par Thibaut le 08-02-2002 à 21:06:29[/edit]

J'en pensais du bien, mais maintenant j'en pense encore plus de bien ...

Thibaut> c'est bien le type d'expressions que tu aimes, non ?
(lol lol lol)

escusez mon ignorence mais AZUR = ????

Vas voir le lien de la signature à Thibaut.

thx

Je suis en train de passer file.txt en HTML, squale92

OK.
je v me mettre à en rédiger un ou deux de plus ce soir...

le plus rigolo, c la doc:
"ds la partie xxx du zip..."
lé où le zip???
on pourrait pas avoir une pitite beta?
voir comment ca tourne, quoi!

Nan.
Et squale92, je compte sur toi pour garder ta bêta sur ton disque dur et pas sur le DD d'autres, tu me suis...
[edit]Edité par Thibaut le 10-02-2002 à 14:16:08[/edit]

aucun pb.
la bêta est sur MON disque dur
(et éventuellement sur mon compte sur le serveur de l'IUT)
nulle part ailleurs

Comme je disais je ne sais plus où, on a chacun notre code d'honneur : on ne distribue pas les bêtas, sauf si le concepteur nous a explicitement dit qu'il était OK... ce n'est pas le cas ici => pas de distribution venant de moi.
(mais il fo reconnaitre qu'on aimerai que les autres que soit ne se tiennent pas à leur code d'honneur )

Échange TIGCC avec passage par registres contre bêta de l'Azur.

je ne mange pas de ce pain là
demande directement à Thibaut

Kevin : Y'a une bêta de TIGCC qui passe les params par registre ?
Mais c'est quoi l'intérêt de passer des params par registres, puisqu'il faut les sauver sur la pile quand on doit les utiliser pour appeler une fonction... ?

>Y'a une bêta de TIGCC qui passe les params par registre ?

J'ai adapté le patch pour le passage par registres pour GCC 2.95 à GCC 3.0.2, et Sebastian va probablement le mettre dans les versions futures de TIGCC.

>Mais c'est quoi l'intérêt de passer des params par registres, puisqu'il faut les sauver sur la pile quand on doit les utiliser pour appeler une fonction... ?

Pas si ce sont d0-d2/a0-a1 (qui seront détruits de toute façon).

Et le passage par registres ne sera pas automatique (du moins pas dans la première version). Il faudra spécifier les registres explicitement, ou utiliser __attribute__ ((regparm)) dans les déclarations de fonctions, ou encore utiliser le switch -mregparm (mais il faudra que les headers soient adaptés pour que ça marche avec les ROM_CALLs - on devra préciser __attribute__ ((stkparm)) dans chaque déclaration de ROM_CALL).
[edit]Edité par Kevin Kofler le 10-02-2002 à 22:46:40[/edit]

arf...
Le passage par registres devrait permettre de gagner en rapidité...

Ils seront difficilement rendus automatiques, puisqu'il faudra réécrire toute la bibliothèque de TIGCC.

D'accord, c'est d0-d2/a0/a1 qui sont détruits, mais ce que je veux dire c'est, pour illustrer :
- Ma fonction Fonction1 qui a pour paramètres Param1 et Param2, appelle à un moment une fonction quelconque qui demande aussi des paramètres. Param1 et Param2 vont être réutilisés après cet appel.
- Les paramètres Param1 et Param2 doivent donc être sauvés sur la pile.
- Résultat : perte de temps par rapport à la convention de passage normale où les paramètres, passés sur la pile, n'auraient pas à être sauvés.
[edit]Edité par Thibaut le 10-02-2002 à 22:56:09[/edit]

la majorité des fonctions de TIGCC sont des ROM_CALLS => ça ne s'appliquera pas là, je penses...

Mais ça sera sans nul doute utile pour des librairies graphiques, et autres

Bah, avec ExtGraph et GraphX, ce sera du passé

>Ils seront difficilement rendus automatiques, puisqu'il faudra réécrire toute la bibliothèque de TIGCC.

Il suffit de mettre __attribute__ ((stkparm)) pour les fonctions existantes.


Et le passage par registres ne sera activé par défaut que s'il réduit vraiment la taille des exécutables. (Désolé, j'ai l'habitude de mesurer l'optimisation par la taille plutôt que par la vitesse, et je pense que c'est la même chose pour Sebastian. La taille est visible sans avoir à lancer le fichier, donc beaucoup plus facile à mesurer.)
Et s'il est activé par défaut et qu'il ne te plaît pas, il sera désactivable (si on le met dans l'IDE, il suffit de le supprimer, et si on l'active directement dans GCC, il y a le switch -mno-regparm pour le désactiver).

Sinon, avec spécification explicite des registres, le passage par registres aura 2 usages:
- des fonctions en assembleur où on s'épargne clairement de prendre un paramètre de la pile (j'en ai déjà postée une comme ça sur le forum)
- les fonctions de certaines librairies dynamiques existantes
[edit]Edité par Kevin Kofler le 10-02-2002 à 23:08:56[/edit]

Pour diminuer la taile des exécutables, plutôt que de ralentir en proposant un passage foireux, commencez par optimiser la librairie, par exemple en faisant des copier-collers de la bibliothèque Azur 1 mois et demi après sa sortie...

À priori, si ça ralentit vraiment, ça fera aussi perdre en place (parce qu'il y aura des instructions en plus) et vice-versa.

Et puis:
- Le patch est déjà prêt.
- Ce ne sera (très probablement) pas activé par défaut.
- J'ai fait ça pour que PpHd arrête de râler toutes le 2 semaines qu'il manque le passage par registres.
- Ça sera en tout cas désactivable.
- On pourra combiner passage par pile et passage par registres! Soit avec spécification explicite des registres, soit avec des __attribute__.

Ok, merci des infos

Au fait, pour Azur, je prévoyais le support de l'appel des fonctions pour cette semaine. Eh bien en fait je vais prendre du retard !

En effet, grâce à Kevin, je vais pouvoir abandonner le projet Azur.

PS : squale92 : pourquoi tu n'utilise pas CC ?

KK: je veux bien la version de tigcc qui permet le passage par registre....
cela me premetrai d'offrire un version enfin propre de _X_lib , qui est sans aucun doute, l'outil s indispensable pour develloper des jeux avec tigcc ....

>Thibaut:
>Au fait, pour Azur, je prévoyais le support de l'appel des fonctions pour cette semaine. Eh bien en fait je vais prendre du retard !
>En effet, grâce à Kevin, je vais pouvoir abandonner le projet Azur.


[edit]Edité par Kevin Kofler le 10-02-2002 à 23:26:14[/edit]