TIGCC 0.95 Beta 6 - Page 7

Vous faites vraiment ch**r.

FL00DEUR était pourtant parfaitement dans le topic

voila!!! ca c'etait un kick justifie
vu ce qu'ils avaient dit... quelle idee aussi de venerer tigcc et ce kevin

Pollux
:

Kevin Kofler
: * Temps d'assemblage économisé (pas nécessairement négligeable).

Si, très clairement. Surtout qu'il n'y a aucun parsing à faire.

Tu n'as pas l'air de connaître l'assembleur GNU, toi.

* Gestion des librairies statiques.

Il n'y a aucune différence : en l'occurrence, il faut aussi que les libs statiques se conforment au nouveau format de fichiers objets.

Et ben, un avantage de la méthode actuelle est qu'il y a compatibilité antérieure. Par exemple, si la librairie statique est vieille (compilée sans mode all-relocs), le range-cutting est automatiquement désactivé pour le code issu de cette librairie statique.

* Gestion du linking entre sources en des langages divers (C, GNU as, A68k, voire d'autres qui pourraient être introduits plus tard). La méthode du tout-en-un ne marche plus si on a du A68k et du GNU as.

Si. Ca ne demande pas plus de boulot que de se conformer au nouveau format de fichier objet, voire même plutôt moins (parce qu'il faudra encore rajouter des hacks pour la gestion des infos supplémentaires que tu compte rajouter).

* Le "boulot [...] de se conformer au nouveau format de fichier objet" a déjà été effectué.
* Il n'y a pas un nouveau format de fichiers objet, mais deux: AmigaOS + extensions TIGCC (utilisé par A68k) et COFF + extensions TIGCC (utilisé par GNU as). C'était beaucoup moins de travail que de tout changer dans un des deux assembleurs pour utiliser l'autre format.
* Tu devras m'expliquer comment tu veux compiler en un seul coup (sans fichiers objet) des sources avec 2 assembleurs radicalement différents et dont les licences sont incompatibles.

Et puis, pour "attendre le linking final pour produire du code binaire", il faut à un moment convertir ça en include, et aussi renommer tous les labels non-exportés pour éviter les conflits. C'est beaucoup plus dur que ça n'a l'air, sachant que les assembleurs n'ont aucun support pour l'assemblage de plusieurs sources en même temps. Et puis je trouve que c'est au linker de faire le linking, pas à l'assembleur.

Je ne parle pas de passer par un fichier texte intermédiaire, je parle juste d'utiliser les routines de l'assembleur. Ce n'est vraiment pas compliqué.

Si. Les assembleurs travaillent tous les deux sur des fichiers texte en entrée et des fichiers objet en sortie. On ne peut pas tout simplement "utiliser les routines de l'assembleur" pour faire ce que tu proposes de faire. Et puis même si c'était techniquement possible, l'incompatibilité de la licence de A68k avec la GPL nous interdirait de le faire.

Ce cas est déjà géré correctement. C'est à ça que sert le mode all-relocs: Il y aura un relogement vers l1 relatif à l2 (relogement de différence d'adresses). Le linker calcule l'offset final après les optimisations qui suppriment du code.

Non, c'est pire que ça. Je dis que sans une certaine forme de désassemblage ou à moins de gérer des tonnes de cas particuliers (donc c'est très casse-gueule),
move.w #0x6000,d0; dc.w l1-l2 a des chances de se retrouver transformé en move.w #(0x60<<8)|(l1-l2),d0 ...
(et je présume que le linker ne gère pas ça correctement non plus... ]

dc.w l1-l2 est un relogement relatif à un label, donc l'optimisation n'y touche pas.

			// Completely ignore builtin relocs. Also ignore relation-relative
			// relocs, since the only relative relocs we can optimize further
			// are branches, and those are never relation-relative.
			// Ignore relocs which are not in code segments.

Notre méthode consiste surtout à repérer les relogements, et nous servir des relogements pour optimiser. Seulement s'il y a un relogement, nous regardons ce qu'il y a devant pour identifier l'instruction.

Et? Ca ne suffit pas... (cf plus haut)

Je sais (mais ton exemple est mal choisi), et je compte corriger ça en passant encore plus d'informations au linker. Mais pour l'instant, ce qu'il y a marche très bien dans presque tous les cas.

Tout débogueur a besoin d'informations de débogage dans le fichier objet pour fonctionner. La nature exacte des informations dont nous aurons besoin n'est pas encore connue. Ça va se fixer au fur et à mesure de l'implémentation, quand il sera temps de réaliser le débogueur.

J'ai déjà réfléchi au pb, mais il n'y a pas du tout besoin d'infos aussi fines que celles nécessaires à redimensionner un code & faire vos hacks.

Si tu veux déboguer du code assembleur, tu as 2 solutions:
* faire que l'assembleur émet la source (comme un compilateur C),
* utiliser le mode all-relocs et s'en servir pour afficher un désassemblage de haute qualité (avec noms des labels etc.).
Du moins pour A68k, la deuxième solution est probablement la plus simple.

Et au passage:

Ah, et vu qu'on est en plein débat de toute façon, je peux aussi reprendre le ./150:

Pollux
:

Désolé, je ne comprends pas du tout d'où tu sors ces chiffres. Si tu pouvais expliciter... Parce que les chiffres qui "tombent du ciel", je ne vois vraiment pas quoi y répondre.

Je détaille : ton 99% vient de toi et est censé être la proportion de progs ASM correctement compilés. Le 99.994% est la probabilité qu'il y n'ait pas la moindre collision dans la génération de 500 seeds différents avec un seed de 31 bits... Et l'ordre de grandeur est le même.

Et ton "gain d'une 20aine d'octets", il sort d'où?

Ce paragraphe-là n'explique rien, mais par contre le paragraphe suivant de ce post donne un semblant de raison...

...

pour le code C, on est d'accord, tu fais ce que tu veux (et tu as parfaitement le droit de le faire dans le linker si ça te fait plaisir, ce n'est pas ça que je critique). Je dis que pour le code ASM, le rapport gain de place / taux d'erreur est plus faible que pour le remplacement de ta fonction randomize() "mathématiquement idéale" () par ma fonction.

Grave erreur. Je peux écrire un code ASM qui sera optimisable exactement autant que CC! C'est même trivial de le faire: tigcc -S *.c.

Ce n'est pas une raison pour transformer les bsr/rts en bra, parce que ça change carrément la sémantique... Normalement, la sémantique de "tigcc *.s" devrait être la même que "cat *.s > $$.s && tigcc $$.s && rm -f $$.s" (modulo le nom du fichier de sortie, et modulo les éventuels conflits de macro). Et c'est largement faisable : sauf qu'il ne faut pas utiliser un format objet hacké dans tous les sens, il faut utiliser un code intermédiaire gardant toutes les infos sémantiques du fichier assembleur de départ...

J'ai déjà répondu à ça en répondant à ton résumé.

Mon "million" était un chiffre au hasard (d'où l'écriture en lettres, pas en chiffres), et ici, j'ai même opté pour "suffisamment de fois" qui est encore plus clair. 2 milliards de fois, c'est un nombre fini d'essais, donc qualifie très bien comme "suffisamment de fois".

Qui parle de million?

Moi. (Dans une autre phrase.)
Mais avec ton "Qui parle de million?", tu as évadé le cœur de mon paragraphe, qui porte sur le "suffisamment de fois".

[ttdasm] est la meilleure manière de voir si la sortie correspond à l'entrée. Mais bon, j'avoue que je ne l'ai fait que pour des très petits programmes, et c'était souvent pour déboguer le linker.

Bah oui, en dehors de testcases simples, c'est complètement impraticable.

Ça, c'est un peu exagéré à mon avis. Pour des petits programmes, c'est dans le domaine du faisable. Mais bon, les petits programmes sont aussi ceux où l'optimisation apporte le moins.

et pour cause : si j'assemble un truc, je suppose que l'assembleur va faire son boulot et pas le modifier en faisant des suppositions trop fortes sur la signification de "bsr", par exemple. En plus, c'est pas du tout viable : le formattage est très différent (sans même parler des macros!), et ttdasm n'est pas parfait.

Le formattage différent n'a aucune importance, vu qu'il s'agit de comparer à la main, pas automatiquement.

Donc en plus il faut le faire à chaque modification du fichier?

Théoriquement oui...

Dans ces cas, tout dépend de la qualité des tests effectués. Avec un bon whiteboxing, on teste tous les chemins d'exécution. Mais comme déjà dit, l'idéal est de comparer avec ce que sort ttdasm.

Bah dans les deux cas c'est gore, et tout sauf sûr.

C'est vrai.

Il est vrai que des fois les tests sont vraiment durs à faire. D'où mon conseil d'utiliser ttdasm.

Toujours aussi impraticable, ça n'a pas changé depuis les 3 paragraphes précédents

Cf. ci-dessus.

Et d'ailleurs, pour le cas des problèmes avec l'optimisation tailcall des bsr, il suffit de regarder la source pour voir s'il y a un problème, on n'a même pas besoin de désassembler ou tester le résultat! C'est simple: S'il y a un bsr ou jsr label suivi d'un rts sans aucun label entre les 2, ça sera optimisé.

Bah oui mais on n'a pas forcément toutes les optimisations en tête, et rien ne dit que tu ne vas pas en rajouter de nouvelles...

* Aucun nouveau peephole est prévu du côté du linker actuellement.
* Si jamais on en met un, je l'annoncerai, donc tu seras au courant.

Non, il "suffit" de mettre à jour TIGCC et
d'activer de nouvelles optimisations. Et il ne faut vraiment pas faire semblant de ne pas être au courant, vu que toutes mes annonces des bêtas parlent à chaque fois des nouvelles optimisations (dans les "rappels").

Sauf qu'en pratique on les active qd même, ces optimisations parce que sans, TIGCC génère du code très largement moins bon que GTC...

Et voilà pourquoi ces optimisations existent.

Ben, moi, je ne comprends pas vraiment. Ce qui règne ici, c'est une grosse paranoia appuyée sur des exemples construits (pas tirés du monde réel) pour des cas totalement improbables, ainsi que sur des exemples réels (ceux de Flanker) qui ne boguent pas à cause d'une erreur fondamentale des optimisations du linker, mais à cause d'un problème de switches qui peut être résolu par l'utilisateur en RTFM et par les versions futures de TIGCC en mettant le bon switch automatiquement. Je répète: les exemples réels cités par Flanker ne sont pas
des victimes inévitables des optimisations du linker! Toutes les victimes inévitables citées étaient des exemples construits spécialement pour ça (dont je connaissais déjà l'existance théorique), qui n'existent pas en pratique.

Ca, ça m'étonnerait énormément...

C'est fortement improbable, et puis ce que je sais est que nous n'avons eu aucun report de bogues où c'était le cas.

Personnellement, je trouve que le mode all-relocs est le seul mode d'assemblage raisonnable. L'assembleur n'a pas à essayer de faire le travail du linker en supprimant les labels locaux et en prérésolvant les références PC-relatives locales. La résolution des relogements et la gestion des labels font partie du boulot du linker. Je trouve que ce n'est vraiment pas malin de mettre la résolution des relogements dans l'assembleur, ça ne fait que dupliquer le travail du linker. Si jamais j'écris un nouvel assembleur pour TIGCC, il n'utilisera que
le mode all-relocs.

Le code objet n'est pas fait pour voir sa taille modifiée, il ne contient pas assez d'infos pour ça (même avec les labels locaux).

Mais avec tous les relogements PC-relatifs et toutes les différences d'adresses en explicit, si, il y a assez d'infos pour ça. (Mais pour les optimisations des relogements elles-mêmes, comme déjà dit, il faudrait aussi une information du style les endroits où commence chaque instruction, ou alors une distinction entre relogements optimisables et non-optimisables que l'assembleur peut faire, pour que ce soit sûr à 100% (en excluant évidemment le code automodifiant qui touche aux instructions optimisables - avec ça, on ne peut jamais optimiser de manière sure à 100. Je réfléchis encore sur la manière optimale de représenter ça.)

La solution propre, c'est de prendre un code intermédiaire plus puissant que le code objet.

Et le code objet en mode all-relocs est ce "code intermédiaire plus puissant".

je viens de me tapper deux pages complètes, excusez le retour en arrière (mais IN sujet)

tu parles du portage de l'IDE, je suppose qu'il s'accompagnera de quelques optimisations, lesquelles, pour quelle(s) version(s) (laprochaine ?)?

Je parle du portage Linux (ou plutôt de la réécriture Linux fidèle à l'original) de l'IDE. Cf. http://tigcc.ticalc.org/linux/. L'IDE Win32 ne changera pas du tout, sauf pour corriger les bogues que je remarque en faisant le portage (j'ai déjà reporté des problèmes de style conflits d'accélérateurs ou erreurs dans les textes d'aide dans la barre d'états à Sebastian et il les a corrigés dans la bêta 6).

^^ Hmm, au fait (#paskicker#) quitte à réécrire une IDE entièrement, tu ne pourrais pas en faire une meilleure que l'actuelle ? (C pas que je critique - enfin qd même un peu - mais perso, je trouve qu'un notepad avec coloration syntaxique serait limite plus ergonomique) Comme ça on pourrait peut-être un jour faire un portage Win32 d'une meilleure IDE

Non, je choisis volontairement de reproduire fidèlement l'interface de Sebastian parce qu'elle me va très bien et parce qu'elle me permet de réutiliser non seulement son design d'interface, mais aussi sa documentation.
Et de plus, avoir des IDEs qui se ressemblent un maximum permet aux utilisateurs de migrer facilement d'une plateforme à l'autre.

Et pour ceux qui veulent un "Notepad avec coloration syntaxique", ça existe déjà: http://kate.kde.org/. (D'ailleurs, je vais vraisemblablement utiliser leur composant KPart (KatePart) pour la coloration syntaxique dans mon IDE.)

je pense que tu t'avances un peu en disant que Vince et Nitro

ne sont que des grandes gueules qui n'y connaissent pas grand chose

plus "qu'un peu", à mon avis :]

Encore un de plus qu'a rien compris...
oué, je suis vnr ce soir, ça pose un problème à quelqu'un ?

Martial> Oui, y a eu toute une vague de personnes différentes visant à détruire le topic Cela dit, je pense que ces personnes-là s'attendaient à être kickées... Et personne n'a critiqué Kevin pour ça. (cela dit, si Kevin n'avait pas le droit de kick, je pensais que ces personnes ne seraient pas "intervenues"...)

Martial Demolins
: où est-ce que ça marchera aussi pour l'asm?

ça existe deja : VTI

Il parle peut-être de débugger au niveau source les progs ASM avec le débuggeur C ?
Et puis VTI n'a pas les noms de labels et les commentaires/le whitespace...

Martial Demolins
: KK-> Il n'y avait pas un débuggueur de prévu un jour.

Oui, c'est prévu, et il est prévu que ce soit ça qui marque le passage de TIGCC 0.9x à TIGCC 1.00. Mais j'ai bien peur que ça nous obligera à faire du 0.991, 0.992, ..., 0.999. Le débogueur n'est pas encore commencé. Mais bon, le linker a été écrit en un seul cycle de développement (0.95), donc peut-être qu'on arrivera à faire de même avec le débogueur.

Et s'il arrive, ce sera que pour les progs en C, où est-ce que ça marchera aussi pour l'asm?

Je compte gérer aussi l'assembleur. Mais on n'a pas encore une seule ligne de code, donc c'est un peu tôt pour faire des promesses.

Martial Demolins
: Edit: T1 au passage c'est dingue je me rends compte que de plus en plus, il faudrait mettre un max de protection dans ses posts anti-mauvaise-interprétation contre ceux qui s'amusent à faire dire au autres ce qu'ils ne disent pas.

Et ceux que j'ai kickés sont aussi spécialistes de ça (le connard de première en question se reconnaîtra, mais ce crétin de Vertyos m'empêche de le nommer ici )...

n'est-ce pas Thibaut?

C'est particulièrement un truc de pute que de glisser des allusions dans le dos de qqun que tu as kické -- je déteste ça (surtout que tu l'as kické pour des raisons relativement douteuses aussi, même si c pas aussi criant de mauvaise foi que le kick de nitro/vince...)

Et qui plus est ton insinuation n'a aucun rapport avec la raison pour laquelle tu l'as kické, donc c'est d'autant plus condamnable

oué, c'est particulièrement bas... Kevin y'aurait moyen de rectifier ça ou de réinviter Thibaut ? (sachant que "non" n'est pas une réponse acceptée)

Vertyos
: oué, c'est particulièrement bas... Kevin y'aurait moyen de rectifier ça ou de réinviter Thibaut ? (sachant que "non" n'est pas une réponse acceptée)

Non.

Mauvaise réponse.

!kick Albert Instinct
--- Kick : Albert Instinct kické(e) par Kevin Kofler
J'ai kické Thibaut entre autres pour la raison-même que je critique!
Et j'ai édité mon message comme tu me l'as demandé, maintenant ferme ta gueule, monsieur le dictateur.

D'ailleurs faut que je t'envoie un exemple ou tigcc me sort un magnifique:

        moveq.l #4,%d1
        add.l %sp,%d1
        subq.l #4,%d1

PpHd :

        moveq.l #4,%d1
        add.l %sp,%d1
        subq.l #4,%d1

Oula !

quel bel exemple d'optimisation ^^

C'est du C a la base ?

Kevin? tu trouve pas que t'abuse legerement?

et puis c'est quoi ce langage? tu viole les regles du forum la tres chere

"Vous êtes d'accord, par l'utilisation de ce service, que vous n'utiliserez pas ce forum pour poster de propos qui sont reconnus comme faux et/ou diffamatoires, abusifs, vulgaires, obscènes, menaçants, atteignant la vie privée d'un membre, ou contraire à la loi."

si tes principes de moderations etaient suivis, tu serais deja banni du site...
tu te crois unique et indispensable a un point tel que ca s'applique aux autres mais pas a toi?
et s'il te plait, essaye d'etre legerement plus constructif qu'un !kick

PpHd>