TIGCC suggestions - Page 10

Kevin >

Dans l'IDE, c'est une case à décocher. En ligne de commande, ce n'est pas par défaut.

Faudrait que la case soit décochée par défaut. Il ne faut pas que des switch
du linker servent à empêcher une optimisation, c'est le contraire...

Flanker: Utilise Makeprgm, il est moins bugge,

et produit un code moins gros sans chercher a optimiser.

Y'a un pb qqpart alors.

Godzil >

Perso ce que j'ai adoré c'est les sources asm ecrites avec la 0.94 et info qui n'assemblent plus sous la 0.95

Laisse-moi deviner, c'est du kernel ?
TIGCC a un comportement étrange vis-à-vis du kernel parfois.

Et moi j'en ai marre de voir des gens qui affirment qu'un assembleur doit optimiser autres choses du meme genre, si j'ecrit un code assembleur,il doit apparaitre TEL QUEL dan sle code objet/machine généré et ne doit pas etre modifié par un quelconque assembleur/linker

. En fait, je suis à la limite d'accord pour que le linker optimise, mais si RIEN n'est fait par défaut. (Et que le défaut concerne tout, les cases dans l'IDE
aussi...)

Kevin Kofler :
Franchement, j'en ai marre. Toutes les plaintes au sujet de ld-tigcc sont de la part de programmeurs assembleur [...] qui n'ont visiblement pas lu la documentation

Je cite la documentation (http://tigcc.ticalc.org/doc/gnuasm.html):

However, please make sure that you put a .data directive at
the beginning of each assembly source file.

et toi, tu dis :

1. section ".data" -> obsolète, à virer. Correctif: virer.

Il est d'actualité de dire que la doc est pas à jour.

#270: tout faux c'est du sans kernel

#271:

Godzil
: #270: tout faux c'est du sans kernel

Alors c'est un bug, et pas une feature.

Entièrement d'accord: un assembleur n'est pas sensé optimisér; s'il obtimise pourquoi pas a condition que ce ne soit pas par défaut.
Quant au linker ce n'est absolument pas son rôle de faire des optimisations.

Que ce soit pour l'assembleur ou le linker, il faudrait
ne pas avoir d'optimisation par défaut, on est d'accord...

Mais le linker peut faire des optimisations que l'assembleur
ne peut pas faire... Dans le cas d'une compilation séparée,
optimiser des sauts vers d'autres sections, dont l'assembleur
n'est pas "conscient" puisqu'elles sont assemblées à part...

Ximoon
: Un linker ne devrait pas modifier le code, à la limite mettre des infos 'bra better than jmp in toto.asm at line 42'...

Ton idée ne sert strictement à rien si le code assembleur en question est:
* automatiquement généré (par un compilateur comme GCC par exemple) OU
* dans une librairie statique: on ne sait pas à l'avance quelle sera la longueur adaptée du saut OU
* faisant référence à une librairie statique (même problème)
etc. etc.

Dans un contexte avec plusieurs fichiers objets (ou plusieurs sections dans le même fichier objet), le programmeur ne peut pas savoir la distance, et l'assembleur non plus, seul le linker peut le savoir.

Et puis cette histoire de sections est parfaitement inutile sur TI,

Ce n'est pas parce que toi, tu ne comprends pas l'utilité des sections qu'elle n'existe pas. Les sections sont indispensables:
* dans le cas où il y a plusieurs fichiers objet (chaque fichier objet est une section ou un ensemble de sections, mais une section ne peut pas s'étendre à plusieurs fichiers objet), cf. compilation séparée, librairies statiques etc.
* dans le cas où tu veux pouvoir éliminer les fonctions inutilisées ou réordonner les fonctions pour minimiser la taille des références (cf. -ffunction-sections)
* même chose pour les données (cf. -fdata-sections)
* pour le constant/string merging
...

J'ai vraiment marre de vos critiques totalement naïves!

Godzil
: Et moi j'en ai marre de voir des gens qui affirment qu'un assembleur doit optimiser autres choses du meme genre, si j'ecrit un code assembleur,il doit apparaitre TEL QUEL dan sle code objet/machine généré et ne doit pas etre modifié par un quelconque assembleur/linker

Alors tu désactives les optimisations (elles sont toutes optionnelles!) et tu la fermes.

pour ce qui est des sources en voici une des partie qui coince sous 0.95 alors q'uelle a toujours tres bien marché jusque la :

Tu as quoi comme erreur et à quelle ligne?

Godzil
:

Kevin Kofler
:

et produit un code moins gros sans chercher a optimiser.

Il y a contradiction ici...

Alors je crois que bcp de personne n'est absolument pas d'accord avec toi

L'optimisation réduit la taille du code au minimum possible (ou au quasi-minimum dans le cas d'optimisations heuristiques comme --reorder-sections). Donc il faut vraiment faire exprès pour ne pas voir la contradiction dans la phrase citée.

Billy Charvet :
Kevin >

Dans l'IDE, c'est une case à décocher. En ligne de commande, ce n'est pas par défaut.

Faudrait que la case soit décochée par défaut. Il ne faut pas que des switch du linker servent à empêcher une optimisation, c'est le contraire...

C'est la philosophie de la ligne de commande, mais l'IDE fonctionne autrement: les options par défaut dans l'IDE activent des optimisations, ça a toujours été comme ça (par exemple, -Os est mis par défaut depuis des lustres, et avant, c'était -O2) et ça ne changera pas. Les options par défaut de l'IDE donnent du bon code sans devoir se soucier des détails d'implémentation. (Le problème en question sera corrigé, --remove-unused ne devrait pas démolir les librairies kernel en effet.)

nitro
:

Kevin Kofler :
Franchement, j'en ai marre. Toutes les plaintes au sujet de ld-tigcc sont de la part de programmeurs assembleur [...] qui n'ont visiblement pas lu la documentation

Je cite la documentation (http://tigcc.ticalc.org/doc/gnuasm.html):

However, please make sure that you put a .data directive at
the beginning of each assembly source file.

et toi, tu dis :

1. section ".data" -> obsolète, à virer. Correctif: virer.

Oups... On a oublié de virer ça alors. C'est une erreur, je vais corriger ça.

Uther
: Entièrement d'accord: un assembleur n'est pas sensé optimisér; s'il obtimise pourquoi pas a condition que ce ne soit pas par défaut.

A68k a toujours optimisé par défaut (désactivable avec -n).

Quant au linker ce n'est absolument pas son rôle de faire des optimisations.

Raaaahhhh!!! Arrrrghhhhh!!! J'ai marre de lire et relire ce commentaire naïf et mal informé! Et j'ai marre aussi du fait que toi, Uther, tu mets toujours trop long à comprendre...
Je répète pour la 36000^ème fois: Ce que le linker optimise, ce sont des optimisations qui sont I_M_P_O_S_S_I_B_L_E_S à faire dans l'assembleur! IMPOSSIBLES. IMPOSSIBLES. IMPOSSIBLES. Comment veux-tu que l'assembleur sache si un label est à moins de 32 KO ou à moins de 128 octets s'il est dans un AUTRE fichier objet qui est assemblé de manière totalement séparé??? Et de plus, le linker peut réordonner les sections pour permettre d'optimiser des références. L'assembleur ne peut pas connaître l'ordre des sections quand il ne compile qu'une partie du programme.
Il faut vraiment vous sortir de la tête l'idée obsolète qu'un fichier .asm (avec éventuellement des include "toto.asm" ) correspond à un programme! En réalité, un fichier .asm n'est en général qu'une partie du programme, et donc l'assembleur ne connaît pas le programme entier. Donc il ne peut pas optimiser des trucs qui nécessitent la connaissance du programme entier.

C'est la philosophie de la ligne de commande, mais l'IDE fonctionne autrement: les options par défaut dans l'IDE activent des optimisations, ça a toujours été comme ça (par exemple, -Os est mis par défaut depuis des lustres, et avant, c'était -O2) et ça ne changera pas. Les options par défaut de l'IDE donnent du bon code sans devoir se soucier des détails d'implémentation. (Le problème en question sera corrigé, --remove-unused ne devrait pas démolir les librairies kernel en effet.)

Perso j'ai rien contre -Os, mais toute optimisation qui pourrait faire bugger même dans un cas particulier
ne devrait pas y être mis par défaut. Mais bon en fait je m'en fiche, la seule chose importante c'est que:
- Par défaut ça marche. Donc réparer --remove-unused ou ne pas la mettre par défaut, au choix.
- Ensuite, si on veut, on regarde les optimisations...

En tout cas qu'on ait pas de problème avec ça d'habitude.

Bon je suis aussi d'accord avec le ./279, mais je préfère m'abstenir de citer.

Je vais essayer de réparer --remove-unused aussitôt que possible (ce soir si je ne m'endors pas tout de suite).

Kevin Kofler
:

Quant au linker ce n'est absolument pas son rôle de faire des optimisations.

Raaaahhhh!!! Arrrrghhhhh!!! J'ai marre de lire et relire ce commentaire naïf et mal informé! Et j'ai marre aussi du fait que toi, Uther, tu mets toujours trop long à comprendre...
Je répète pour la 36000^ème fois: Ce que le linker optimise, ce sont des optimisations qui sont I_M_P_O_S_S_I_B_L_E_S à faire dans l'assembleur! IMPOSSIBLES. IMPOSSIBLES. IMPOSSIBLES. Comment veux-tu que l'assembleur sache si un label est à moins de 32 KO ou à moins de 128 octets s'il est dans un AUTRE fichier objet qui est assemblé de manière totalement séparé??? Et de plus, le linker peut réordonner les sections pour permettre d'optimiser des références. L'assembleur ne peut pas connaître l'ordre des sections quand il ne compile qu'une partie du programme.

Je pense que ce qu'Uther voulait dire, c que le linker ne doit pas faire des optimisations que n'aurait pas fait l'assembleur, i.e. que si le linker fait des optimisations, il doit se comporter en tout point comme si les .o étaient simplement des .asm et comme si le linker était un assembleur...

Ben, c'est bien beau comme principe, mais si le linker peut faire plus que ça, autant en profiter.

Plus que ça ? à part le droit d'échanger l'ordre de ses arguments, il ne devrait avoir *aucun* droit en plus...

Ho si. Tous les linkers naissent libres et égaux en droits.

Dans un contexte avec plusieurs fichiers objets (ou plusieurs sections dans le même fichier objet), le programmeur ne peut pas savoir la distance, et l'assembleur non plus, seul le linker peut le savoir.

Et tu ne peux pas faire une compilation en deux passes ? Le compilateur appelle ensuite le linker qui fait rappelle ensuite le compilateur (ssi il est l'appelant) pour effectuer les optimisations. Ainsi le linker ne fait rien d'imprévu, et quelqu'un qui bosse directement en assembler n'a pas de problème (ça revient en fait à ce que propose Ximoon : le linker renvoie des warnings, mais il ne les renvoie pas à l'utilisateur, il les renvoie au compilateur qui refait des modifs avant de repasser la version définitive et compilée au linker.
Ou alors tu crées un outil intermédiaire juste avant le linker qui sert exclusivement à ces optimisations, mais d'après ce que j'ai compris (je n'ai pas regardé de pres TIGCC depuis pas mal de temps, donc ne t'énerve pas si je dis une boulette, je fais juste une proposition) ça n'est pas possible vu que tu optimises pendant le processus de link et pas juste avant.

Nil, envoie-moi les patches qui implémentent ça dans GCC et on en reparlera. Mon avis: ce n'est pas faisable.

Et le linker ne fait déjà rien d'imprévu, l'assembleur lui communique déjà quels relogements peuvent être optimisés et lesquels non. Cf. relogements inoptimisables.

Pollux :
Plus que ça ? à part le droit d'échanger l'ordre de ses arguments, il ne devrait avoir *aucun* droit en plus...

Bah si:
* optimiser les relogements (à faire obligatoirement dans le linker, cf. ci-dessus),
* supprimer les sections non référencées (selon les cas, ça peut aussi être faisable en temps de linking seulement, et ça ne peut normalement créer aucun problème (l'histoire des librairies sera corrigée)),
* réordonner les sections, de manière à pouvoir mieux optimiser les relogements (à faire obligatoirement dans le linker),
* mettre en commun les constantes (constant merging) entre plusieurs fichiers objet (à faire obligatoirement dans le linker).

Kevin Kofler
:

nitro
:

Kevin Kofler :
Franchement, j'en ai marre. Toutes les plaintes au sujet de ld-tigcc sont de la part de programmeurs assembleur [...] qui n'ont visiblement pas lu la documentation

Je cite la documentation (http://tigcc.ticalc.org/doc/gnuasm.html):

However, please make sure that you put a .data directive at
the beginning of each assembly source file.

et toi, tu dis :

1. section ".data" -> obsolète, à virer. Correctif: virer.

Oups... On a oublié de virer ça alors. C'est une erreur, je vais corriger ça.

Patch envoyé à Sebastian.

Je vais m'occuper de l'histoire de --remove-unused maintenant.

(Ah ouais, merde, j'avais oublié que tu étais tributaire de GCC )

Kevin Kofler
:

Pollux :
Plus que ça ? à part le droit d'échanger l'ordre de ses arguments, il ne devrait avoir *aucun* droit en plus...

Bah si:
* optimiser les relogements (à faire obligatoirement dans le linker, cf. ci-dessus),
* supprimer les sections non référencées (selon les cas, ça peut aussi être faisable en temps de linking seulement, et ça ne peut normalement créer aucun problème (l'histoire des librairies sera corrigée)),
* réordonner les sections, de manière à pouvoir mieux optimiser les relogements (à faire obligatoirement dans le linker),
* mettre en commun les constantes (constant merging) entre plusieurs fichiers objet (à faire obligatoirement dans le linker).

* optimiser les relogements : lis mon post, je ne propose d'assembler qu'à la fin (au moment du link)
* réordonner / supprimer / partager les sections : oui, c'est bien les droits en plus dont je parle...

Bah, tu n'aimes pas ces optimisations, tant pis, tu les désactives. Mais je ne vois pas pourquoi TIGCC devrait donner du code plus gros/lent que nécessaire seulement parce que monsieur Pollux ne veut pas que le linker fasse une certaine optimisation.

Flanker :
j'ai un pb avec tigcc, je pense que c'est une erreur bête de ma part, mais j'arrive pas à la trouver

j'ai le .asm suivant, dans A68k assembly files
[...]
et dans reglib0000.h
[...] et quoique je fasse, le .9xz produit fait toujours 89o, quelque soit le code asm. Je veux bien savoir optimiser, mais là j'y crois pas trop. Où est l'erreur ?

Comme dit plus haut, c'est un problème dans le linker. Correctif envoyé à Sebastian.

Godzil :
pour ce qui est des sources en voici une des partie qui coince sous 0.95 alors q'uelle a toujours tres bien marché jusque la :

XCpyBWPlanToLPlan: 
	move.l	CBWplan,%a0 
	move.l	CGplan,%a1 
	bsr.s		XCpyPlan 
	rts 
[...]

Not a bug.
"Value of 142 too large for field of 1 bytes at 0xd" veut dire ce que ça veut dire, c'est trop loin pour un bsr.s. Si ça a "marché" avant, c'était un bogue, et le code généré était probablement incorrect.

Tiens, ca me rappelle qqch cette source

Je répète pour la 36000ème fois: Ce que le linker optimise, ce sont des optimisations qui sont I_M_P_O_S_S_I_B_L_E_S à faire dans l'assembleur! IMPOSSIBLES. IMPOSSIBLES. IMPOSSIBLES. Comment veux-tu que l'assembleur sache si un label est à moins de 32 KO ou à moins de 128 octets s'il est dans un AUTRE fichier objet qui est assemblé de manière totalement séparé??? Et de plus, le linker peut réordonner les sections pour permettre d'optimiser des références. L'assembleur ne peut pas connaître l'ordre des sections quand il ne compile qu'une partie du programme.

Je sais très bien ce qu'est le compilation séparée, n'empèche que ce n'est normalement pas au linker de faire des optimisations c'est pourquoi ca devrait être désactivé par défaut.

Nan mais t'as pas compris, c'est désactivé par défaut, c'est juste activé par défaut dans l'ide parce que c'est le role de l'ide (l'histoire ne dit pas quel est le role précis de l'IDE )

Oups autant pour moi.
Si c'est activé par défaut uniquement dans l'IDE c'est vraiment pas un problème vu qu'il ne faut pas utiliser l'IDE(kevin peu flammer ici )

J'avais cru comprendre que c'était systématique.

nEUrOO
: Tiens, ca me rappelle qqch cette source

Ça provient de XLib, il l'a dit.

La bêta 20 corrigeant le problème reporté par Flanker et l'erreur de documentation reportée par nitro est maintenant disponible sur http://tigcc.ticalc.org.