TIGCC suggestions - Page 7

1. Rajouter une section n'est pas backwards-compatible non plus. Le format AmigaOS ne définit pas du tout comment on saute un hunk (= une section) de type inconnu.
2. Je n'ai pas envie de tout changer juste parce que 2 personnes n'aiment pas un détail d'implémentation qui n'a aucune importance en pratique.

Pas d'importance en pratique ? Au niveau compatibilité, c'est exactement comme si vous aviez totalement changé le format de fichier objet : c compatible ni dans un sens, ni dans l'autre

Et si on met ça dans une section à la fin ? Il n'y a pas besoin de la sauter si elle n'est pas gérée, et si elle est gérée on peut la traiter correctement.

Ben, si on rajoute une section, même à la fin, tous les linkers existants renverront "erreur: section inconnue" et c'est fini.
Et bon, puisque tu n'as toujours pas compris: le format est déjà fixé, c'est trop tard pour le changer.

Et maintenant, je peux vous dévoiler la raison de mon attitude hostile à tout changement: la première prerelease de la bêta 19 était déjà faite à 16h16. Et maintenant, la bêta 19 finale est sortie, le format est fixé, il ne va pas changer.

Kevin> Tu reprochais justement à Flanker d'implanter des trucs sans en parler avant. Tu devrais adopter la même attitude, tu n'as pas toujours la meilleure idée, à priori consulter les autres ne peut t'apporter que des bonnes choses.

Sa suggestion n'est pas meilleure, elle causerait les mêmes problèmes de compatibilité que ma solution.

Et puis je n'ai pas trop apprécié l'attitude de Pollux. D'abord, il dit "Sauf qu'il manque encore le support A68k." sans rien dire d'autre. Ensuite, j'implémente, et après il me dit que l'implémentation ne lui va pas. Ben, tant pis. Il aurait pu me dire tout de suite comment il voulait que je l'implémente.

Je suis même allé jusqu'à écrire un patch pour le principal linker "concurrent" pour qu'il puisse aussi lire ces fichiers objet. Donc il ne faut vraiment pas m'accuser d'ignorer l'interopérabilité.

Et en plus, si vous aviez lu la liste des changements, vous saurez que j'ai même implémenté le feature le plus demandé pour A68k (la gestion des fichiers de plus de 32766 lignes). Alors je suis assez mécontent de vous voir râler encore.

>Je suis même allé jusqu'à écrire un patch pour le principal linker "concurrent" pour qu'il puisse aussi lire ces fichiers objet.
Ca bien du te prendre 5 minutes

>(la gestion des fichiers de plus de 32766 lignes).
D'autres choses a part les modifs de Pollux ?

PpHd :
>Je suis même allé jusqu'à écrire un patch pour le principal linker "concurrent" pour qu'il puisse aussi lire ces fichiers objet.
Ca bien du te prendre 5 minutes

Un peu plus quand-même (10-15 minutes).

>(la gestion des fichiers de plus de 32766 lignes). D'autres choses a part les modifs de Pollux ?

J'ai pris une définition de INT_MAX qui n'a pas besoin de limits.h:
#define NODEF ((int)(((unsigned)-1)>>1)) /* Kevin Kofler, v.2.71.F3s */
Et puis Pollux a laissé traîner des DebugEnd=32767 que j'ai corrigés aussi.

Kevin > Je te trouve bien trop gentil avec a68k. Si j'étais toi, j'aurais envoyé
chier ce machin, pas de possibilité de linking avec TIGCC et ses .a. En ajoutant
à ça des tutos pour as, et le fait que peu de choses dans les kernels marchent
vraiment, et en laissant a68k à ses vieilles libs en espérant qu'elles soient les
plus incompatibles possibles avec les nouveaux HW et versions, d'AMS, tu
aurais déjà pu imposer as depuis longtemps.

Et pas d'emmerdement avec le format AmigaOS.

Et puis je n'ai pas trop apprécié l'attitude de Pollux. D'abord, il dit "Sauf qu'il manque encore le support A68k." sans rien dire d'autre. Ensuite, j'implémente, et après il me dit que l'implémentation ne lui va pas. Ben, tant pis. Il aurait pu me dire tout de suite comment il voulait que je l'implémente.

Ou t'aurais pû refuser tout de suite.

Et en plus, si vous aviez lu la liste des changements, vous saurez que j'ai même implémenté le feature le plus demandé pour A68k (la gestion des fichiers de plus de 32766 lignes). Alors je suis assez mécontent de vous voir râler encore.

C'est du temps perdu. T'aurais mieux fait de le passer à adapter le patch
TIGCC pour GCC 3.4.

>J'ai pris une définition de INT_MAX qui n'a pas besoin de limits.h:
>#define NODEF ((int)(((unsigned)-1)>>1)) /* Kevin Kofler, v.2.71.F3s */
Pas portable

>Si j'étais toi, j'aurais envoyé chier ce machin, pas de possibilité de linking
>avec TIGCC et ses .a. En ajoutant à ça des tutos pour as,
>et le fait que peu de choses dans les kernels marchent vraiment,
>et en laissant a68k à ses vieilles libs en espérant qu'elles soient les
>plus incompatibles possibles avec les nouveaux HW et versions, d'AMS, tu
>aurais déjà pu imposer as depuis longtemps.
Je crois que c'est ton cerveau qui marche pas.
Mais ne t'inquietes pas. C'est pas grave.
On peut parfaitement vivre sans.

Je n'en attendais pas moi. Kevin et toi êtes si prévisibles.

Je ne loupe jamais une occasion de troll.

"J'utilise a68k."

Vas-y, trolles.

(Tu connaît plus de défauts d'a68k que moi, alors ça sera facile. lol )

GNU AS et globalement plus efficace mais le défaut est simple: Syntaxe de merde.

y a pas de les labels locaux

Uther > Ben on finit par s'y habituer... je programme qu'avec as...

Flanker > Kevin a déjà répondu à cette remarque.

--register-prefix-optional.

Et pour les labels locaux, faut juste les commencer par 'L'.

...

Billy Charvet :
Et pour les labels locaux, faut juste les commencer par 'L'.

les labels qui commencent par L sont des labels locaux ?

Billy Charvet
: C'est du temps perdu. T'aurais mieux fait de le passer à adapter le patch TIGCC pour GCC 3.4.

Pas de GCC 3.4 pour TIGCC 0.95. Je n'ai pas envie que le release soit repoussé encore des mois en arrière. Il y aura forcément des bogues dans la première adaptation de GCC 3.4, il y en a eu à chaque fois qu'on est passés à une mise à jour majeure de GCC.

Une fois TIGCC 0.95 releasé, je m'occuperai d'adapter GCC 3.4.x ou 4.0.

PpHd :
>J'ai pris une définition de INT_MAX qui n'a pas besoin de limits.h:
>#define NODEF ((int)(((unsigned)-1)>>1)) /* Kevin Kofler, v.2.71.F3s */
Pas portable

Mais marche sur les systèmes K&R qui ne connaissent pas limits.h. Je n'ai pas envie d'inclure des headers ISO dans un programme K&R.

Et puis les systèmes sur lesquels cette définition est fausse, tu me les montreras.

Uther
: GNU AS et globalement plus efficace mais le défaut est simple: Syntaxe de merde.

--register-prefix-optional, tu connais?

Flanker
:

Billy Charvet :
Et pour les labels locaux, faut juste les commencer par 'L'.

les labels qui commencent par L sont des labels locaux ?

"L." plutôt. Mais ces labels ne sont pas comme les labels locaux en A68k, ils sont locaux au fichier .s les contenant, pas à la rangée définie par 2 labels globaux.

Sinon, tu as les labels locaux numériques aussi (permettent de spécifier la direction de la recherche).

"L." plutôt. Mais ces labels ne sont pas comme les labels locaux en A68k, ils sont locaux au fichier .s les contenant, pas à la rangée définie par 2 labels globaux.

ça perd pas mal de son intérêt :/

>Et puis les systèmes sur lesquels cette définition est fausse, tu me les montreras.
Les cray ?

Ca t'arrive souvent de faire tourner tigcc sur un cray?

Bah qui te dis qu'il n'a pas recompilé tigcc pour l'utilisé dans son labo de recherche ?

>Ca t'arrive souvent de faire tourner tigcc sur un cray?
On parle d'a68k ici.

les cray utilisent des 68000 ?

Non, pourquoi ?

Les PC n'utilisent pas de 68k, et pourtant on a a68k sur pc, godzil