Afficher un pixel - Page 2

Mais chez toi, même s'ils voudraient t'aider, ils ne pourraient pas, parce qu'ils n'ont pas les sources...
(post croisé )

Je n'ai pas dit que je voulais de l'aide, moi

Tu préfères garder toutes les déficiences d'optimisation que tu ne peux pas résoudre? (Ne me dis pas qu'il n'y en a pas, il y en a certainement...)

PS: Ximoon, Vertyos: pas taper SVP.

Pff... Vertyos aurait bien raison de nous kicker, étant donné que tu n'arrêtes pas de relancer...

Bon, je réponds qd même, mais c'est la dernière fois dans ce topic : pour les déficiences d'optimisation, à mon avis le compromis est assez raisonnable on-calc au vu des capacités limitées de la calc, et on n'a de toute façon pas besoin d'une efficacité extraordinaire on-calc (juste assez pour que ça ne rame pas, on s'en tape de gagner 3% en taille). On-PC, il y a effectivement une grosse marge pour l'optimisation, donc je refais tout de fond en comble et ce serait vraiment débile de rajouter des optimisations pour la version actuelle qui de toute façon est limitée par son architecture qui sépare trop les instructions différentes à mon goût.

Et de toute façon, là n'est pas le problème : je ne me plains de rien, moi...

Merci pour mon topic...

Kevin Kofler :
Personne ne veut m'aider avec GCC pour TIGCC...

De toute façon, la norme du C impose que les calculs soient fait sur des int, donc ce ne serait pas conforme ?
Enfin, vu qu'au niveau du résultat ça reviendrait au meme on pourrait se le permettre quand meme ?
Mais franchement, je ne sais pas du tout comment fonctionne cette partie du compilateur.

De toute façon, la norme du C impose que les calculs soient fait sur des int, donc ce ne serait pas conforme ? Enfin, vu qu'au niveau du résultat ça reviendrait au meme on pourrait se le permettre quand meme ?

Le C ne t'impose évidemment pas de faire des calculs sur un certain type de données en interne, il t'impose juste que ça te donne le même résultat, donc oui c'est légal d'utiliser moveq puis lsr.b. Mais crois-moi, tu perdrais vraiment ton temps à implémenter des détails comme ça dans GCC (ou dans GTC d'ailleurs). Ce ne sont pas ces optimisations-là qui font qu'un compilateur est meilleur qu'un autre.

Sasume
:

Kevin Kofler :
Personne ne veut m'aider avec GCC pour TIGCC...

De toute façon, la norme du C impose que les calculs soient fait sur des int, donc ce ne serait pas conforme ? Enfin, vu qu'au niveau du résultat ça reviendrait au meme on pourrait se le permettre quand meme ?

Évidemment. Règle "as if": Si le résultat est exactement le même, on peut utiliser une autre méthode de calcul. On ne pourrait rien optimiser sans cette règle!

Mais franchement, je ne sais pas du tout comment fonctionne cette partie du compilateur.

C'est dans m68k.md qu'il faudra changer des trucs. Il faut voir la doc des MDs, ou alors carrément faire du copier/coller/éditer de ce qui fonctionne (ce que je fais la plupart des cas ).

Pollux
:

De toute façon, la norme du C impose que les calculs soient fait sur des int, donc ce ne serait pas conforme ? Enfin, vu qu'au niveau du résultat ça reviendrait au meme on pourrait se le permettre quand meme ?

Le C ne t'impose évidemment pas de faire des calculs sur un certain type de données en interne, il t'impose juste que ça te donne le même résultat, donc oui c'est légal d'utiliser moveq puis lsr.b. Mais crois-moi, tu perdrais vraiment ton temps à implémenter des détails comme ça dans GCC (ou dans GTC d'ailleurs). Ce ne sont pas ces optimisations-là qui font qu'un compilateur est meilleur qu'un autre.

Il y a des trucs plus importants, certes, mais ce n'est pas une raison de négliger les détails. Surtout qu'ici un petit peephole devrait suffire.

un petit peephole devrait suffire

Non, pas à 100%, loin de là.

Bah si, un truc du style (en notation simplifiée) move.w #128,%dn;lsr.w #[0-7],%dn;f(subreg(.b,%dn)) -> moveq #-128,%dn;lsr.b #[0-7],%dn;;f(subreg(.b,%dn)).

T'es drôle... Implémenter ça comme ça, ça améliorera peut-être ce programme-là, mais ça ne marchera pas dans des cas qui sont pourtant très similaires. Ce qu'il faut faire, ce n'est pas un peephole aussi basique que celui-là, c'est plus quelque chose dans le goût de _mulsi3 versus muls (le genre de truc qui est implémenté dans le compilo actuel de GTC dans le générateur de code lui-même).

Kevin> Je ne trouve rien comme info sur les MDs ni sur m68k.md, et je ne trouve pas ce fichier dans tigccscr.zip (il faut télécharger les sources de GCC, je suppose...)

Pollux
: (le genre de truc qui est implémenté dans le compilo actuel de GTC dans le générateur de code lui-même).

C'est sûr que ça m'avance beaucoup, n'ayant pas accès à cette implémentation...

Sasume
: Kevin> Je ne trouve rien comme info sur les MDs ni sur m68k.md,

http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gccint/Machine-Desc.html

et je ne trouve pas ce fichier dans tigccscr.zip (il faut télécharger les sources de GCC, je suppose...)

Oui.

C'est sûr que ça m'avance beaucoup, n'ayant pas accès à cette implémentation...

Ce que ça veut dire, c'est qu'un peephole est bien trop bas niveau pour te permettre d'implémenter ça sans de grosses limitations. D'ailleurs tu pourrais regarder CC, ça fonctionne à peu près pareil de ce point de vue-là.

Enfin tu fais comme tu veux

Rahhhh quelle bande de lourds !!!
Créez un topic, ou utilisez-en un déjà existant mais qui parle du bon sujet.

On est en train de discuter sérieusement comment faire dans nos compilateurs pour optimiser au mieux le code dont parle ce sujet. Je ne vois pas en quoi c'est hors sujet.

Fais pas semblant de ne pas comprendre... Il en a rien à foutre de vos technique d'optmisation à priori, va voir le premier post. Et tu m'oblige à flooder autant que toi là... Stop.

Pour une fois, le débat est presque sérieux, je trouve.