[F] [mOved] Mon langage est mieux que le tien - Page 73

Tu n'as qu'à recoder ton propre compilateur C, qui optimisera aux petits oignons.

./2157 : qu'est-ce qui ne va pas et que choisirais-tu à la place ?

Folco: tu devrait mettre du PNG plutot que du BMP

Sinon apres un visionage rapide, ton code n'est pas completement equivalent entre la version C et la version ASM, tu as deux fonction prepareLayouerHorizontal et une pour le Vertical, en ASM tu n'a que prepareLayout qui gere les deux.

Je n'ai pas le temps de regarder en details, mais ta version ASM tu applique des optimisation de flux que le compilateur ne va pas faire parce que tu as definis plusieurs fonctions qui ne sont pas statiques donc il faut quelle soient appelable depuis l'exterieur il ne peux pas les inliner (surtout si c'est dans des fichiers differents)

Idem je ne sais pas avec quel options tu compile la version C, mais le compilo par exemple va genrer les framepointers (quoiquoi j'ai un doute sur TI) sauvegarde de registers & co, ton ABI n'est pas forcement la meme sur les bra/jmp que ce que le compilateur va faire, ca fait gagner/perdre de la place

Exact. Cependant, rendons à César ce qui est à César, et à Zerosquare ce qui est à Zerosquare : c'est lui qui m'a crafté cette belle image il y a quelques années, et je l'ai toujours conservée telle quelle.

Oh, tu as gardé ça ?

Godzil (./2163) :
Je n'ai pas le temps de regarder en details, mais ta version ASM tu applique des optimisation de flux que le compilateur ne va pas faire parce que tu as definis plusieurs fonctions qui ne sont pas statiques donc il faut quelle soient appelable depuis l'exterieur il ne peux pas les inliner (surtout si c'est dans des fichiers differents)

Effectivement. Les fonctions que tu veux avoir inlinées doivent être static et dans le même fichier .c.

Idem je ne sais pas avec quel options tu compile la version C, mais le compilo par exemple va genrer les framepointers (quoiquoi j'ai un doute sur TI)

-fomit-frame-pointer est par défaut dans TIGCC si on est en -O (-O1) ou supérieur (et -O0 est pourri et inutilisable de toute façon).

Folco (./2158) :
ça

Mais pourquoi avec A68k, bon sang? Je ne comprends pas pourquoi certains s'obstinent à écrire du nouveau code avec un assembleur déprécié. Utilise GNU as!

Godzil (./2163) :
Sinon apres un visionage rapide, ton code n'est pas completement equivalent entre la version C et la version ASM, tu as deux fonction prepareLayouerHorizontal et une pour le Vertical, en ASM tu n'a que prepareLayout qui gere les deux.

Pas exactement, c'est découpé en C pour des questions de lisibilité (et parce qu'appeler une sous-fonction crée un overhead à cause des arguments, chose que tu peux gérer bien plus intelligemment en asm).
Mais ce sont des fonctions internes, l'API est exactement la même.

Oui mais ça change beaucoup le code généré

Appeler une fonction entre deux fichiers ne permet pas l'inline ou appel direct, ce que tu fait en ASM.

Pour avoir tracé tout l'asm généré, la différence (700 octets pour 2ko quand même) ne vient pas de là, mais du code qui est juste pourri, GCC n'a vraiment aucune immagination

Ce n'est pas vraiment ce qu'on lui demande l'imagination

Folco, j'attends ta contribution de passes d'optimisation, ou au moins de peepholes, à TIGCC.

J'ai déjà corrigé un bug cet après-midi, dans realloc.s, faut pas tester le retour de HeapRealloc avec un tst.w d0, mais un move.w d0,(sp), parce que les arguments sur la pile sont destructibles. Sait-on jamais ce que nous réserve PedroM 0.84, voire KKOS 1.0 !!!

Ce genre d'optimisations (théoriquement abusives) dans le code ASM de TIGCCLIB sont faites exprès.

Et donc tu flippais à chaque release d'AMS, en espérant qu'il n'y ait pas 10 nouvelles cassures à détecter ? Tout était à retester ?

On avait les utilisateurs pour ça.

Il y a ce genre de choses seulement là où il est "impossible" que ça casse. Et il y a des trucs plus fragiles que ça, par exemple la manière d'obtenir vcbprintf, qui a dû être mise à jour avec AMS 2 parce que TI a baissé le niveau d'optimisation de leur compilateur et que donc le code qui "ne pouvait pas changer" se trouvait pessimisé de manière absurde.

TI a baissé les optimisations d'AMS au fur et à mesure des releases. Apparemment, à chaque fois qu'ils ont recontré un problème avec leur compilateur, au lieu de modifier leur code, faire en sorte que le compilateur (tiers) qu'ils ont utilisé soit modifié ou utiliser un compilateur moins foireux (GCC), ils ont tout simplement compilé avec moins d'optimisations.

Ah, j'ignorais que c'était ça les problèmes, et la question du nombre de secteurs qui augmentaient sans cesse

C'est clairement visible, quand des abs.w se retrouvaient transformés en abs.l (même quand l'adresse tient en un word), des instructions redondantes se retrouvaient insérées etc., alors que le fonctionnement du code n'avait pas changé.

on sait ce qu'ils utilisaient TI? Keil?

Il me semble que c'était Sierra-C ou nom equivalent

Dans le SDK public, oui, mais il n'est pas sûr qu'ils utilisent le même compilateur en interne, il me semble que certaines personnes aient constaté des différences au niveau du code généré.

La version de SierraC fourni avec le SDK n'est pas la version complète. Et je vois mal TI aller acheter une licence hors de prix pour ce compilo pour un SDK au marché douteux.

C'est possible, mais ce n'est pas certain. Distribuer une version limitée, c'est aussi un moyen de se faire de la pub, d'ailleurs plusieurs développeurs de compilos distribuent des versions limitées gratuites. TI a pu choisir Sierra C parce qu'ils ont pu négocier un accord commercial intéressant avec eux, pas forcément parce que c'est ce qu'ils utilisaient en interne.

À vrai dire GCC aurait très bien pu faire leur affaire.

Oui ce n'est pas certain, mais SierraC est pas vraiment le compilateur le plus connu, il doit y avoir une bonne raison qu'il ai été choisis.

Ai quand même cest plus simplement d'éviter de mélanger des trucs comme les compilateurs, même si ça peu marcher, tout faire avec le même est plus rationnel et potentiellement moins problematique

Un petit cadeau pour Flan en ce vendredi matin : le démontage en règle d'un rant anti-Python 3 (écrit, curieusement, par l'auteur d'un bouquin d'introduction au Python...) :
https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/

Je ne mets pas de lien vers l'article d'origine, premièrement parce que le commentaire le cite largement, deuxièmement parce que même sans rien connaître au Python, la mauvaise foi qu'il contient me crève les yeux

Zerosquare (./2185) :
un rant anti-Python 3 (écrit, curieusement, par l'auteur d'un bouquin d'introduction au Python...)

Je ne vois pas la contradiction. Il dit aux gens d'en rester au Python 2 qui est toujours majoritaire. Et franchement, il a raison de se plaindre de l'incompatibilité de la nouvelle version. Et je suis aussi presque entièrement d'accord avec ce qu'il dit sur les chaînes de caractères (mais je coderais en dur l'UTF-8 comme le charset pour la conversion automatique au lieu d'utiliser ce gros hack de chardet qu'il propose d'utiliser).

Tu as lu la partie où il prétend que parce que les machines virtuelles des deux versions ne sont pas compatibles, ça veut dire que le langage n'est pas Turing-complet ?

Ou celle où il se plaint que Python 3 distingue clairement les suites d'octets des chaînes de caractères (Unicode) ? (c'est vrai que ne pas différencier les deux, ça a tellement bien marché pour [par exemple] PHP... )

Zerosquare (./2187) :
Tu as lu la partie où il prétend que parce que les machines virtuelles des deux versions ne sont pas compatibles, ça veut dire que le langage n'est pas Turing-complet ?

Regarde sa version éditée où il s'explique à ce sujet. (Il ne fallait pas le prendre à la lettre, évidemment.)

Ou celle où il se plaint que Python 3 distingue clairement les suites d'octets des chaînes de caractères (Unicode) ? (c'est vrai que ne pas différencier les deux, ça a tellement bien marché pour [par exemple] PHP... )

Ayant déjà passé une journée (enfin, plutôt soirée-nuit ) sur IRC avec un développeur Python à porter du code Python 2 vers Python 3 (il faisait les modifications, je les testais au fur et à mesure), le manque d'une telle conversion automatique m'a totalement agacé! (Regarde le nombre de commits qu'il lui a fallu pour rajouter ces conversions partout, où Python 2 restait en octets (UTF-8, mais il s'en foutait, tant qu'on n'essayait pas de convertir implicitement en u"machin") sans la moindre conversion.) Il faudrait convertir implicitement en UTF-8 (plutôt qu'en ASCII 7 bits comme Python 2, ce qui était effectivement pourri) et lancer une exception si ce n'est pas de l'UTF-8 valide.

Une autre modification totalement débile est qu'ils ont changé le comportement de l'opérateur /!!! Sans blague! (Il marche maintenant comme en BASIC plutôt que comme en C, C++, Java, JavaScript etc.)

Bin oui, le changement des chaînes de caractères avec Python 3 est pénible…
Mais le fonctionnement de Python 2 est franchement sa plus grosse erreur de conception et est probablement aussi la plus grosse source de bugs.
Alors, oui, le changement est chiant… pour les trucs mal codés (si ça avait été codé avec rigueur, il n'y aurait pas trop de souci, surtout avec 2to3 qui fait ça tout seul, mais c'est vrai que Py2 pousse au crime à ce niveau). Après, ça fait plus de 10 ans que Py3 est sorti et il y a pas mal de façons de coder à la fois pour Py2 et Py3. Ça laisse quand même un peu de temps pour faire la transition.

(et sinon, j'imagine que ton pote n'a pas trouvé une façon encore plus inefficace de développer ?)

Zerosquare (./2187) :
c'est vrai que ne pas différencier les deux, ça a tellement bien marché pour [par exemple] PHP...

D'o� tu te moques ? c'est tr�s bien ainsi, il n'y a pas de probl�me avec PHP, tout a �t� g�r� de main de ma�tre.