Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigen.org sur IRC
Liste des membres Rechercher Aide
Bienvenue Kevin Kofler !   Se déconnecter             Mes sujets   
Administrer
1 membre(s) et 0 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : @Kevin Kofler
Avant de poster sur le forum ou de discuter sur le chan IRC #tigen.org, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum et lire la charte IRC.
  :: Index » Forum Ti68K » Programmation ETP Studio » Code généré affreux (38 réponse(s))
./POST DE DEPART (post n°0)
Kevin Kofler Ecrit le: Mardi 4 janvier 2005 à 22:29 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Quelques morceaux de code de mineswp.89z qui me sont sautés aux yeux:

1.
move.l   %a0,%d4              /* [0x12 (18)] 28 08             */
tst.l    %d4                  /* [0x14 (20)] 4a 84             */

tst.l en trop.

2.
move.l   0xC8,%d0             /* [0x6A76 (27254)] 20 38 00 c8       */
andi.l   #0x600000,%d0        /* [0x6A7A (27258)] 02 80 00 60 00 00 */

Et la Titanium? 0x600000 à remplacer par 0xE00000.

3.
movea.l  %a7,%a0              /* [0x2E0 (736)] 20 4f             */
addq.l   #2,%a0               /* [0x2E2 (738)] 54 88             */
movea.l  %a0,%a6              /* [0x2E4 (740)] 2c 48             */
move.b   #0x70,(%a6)+         /* [0x2E6 (742)] 1c fc 00 70       */
move.b   #0x72,(%a6)+         /* [0x2EA (746)] 1c fc 00 72       */
move.b   #0x65,(%a6)+         /* [0x2EE (750)] 1c fc 00 65       */
move.b   #0x73,(%a6)+         /* [0x2F2 (754)] 1c fc 00 73       */
move.b   #0x65,(%a6)+         /* [0x2F6 (758)] 1c fc 00 65       */
move.b   #0x6E,(%a6)+         /* [0x2FA (762)] 1c fc 00 6e       */
move.b   #0x74,(%a6)+         /* [0x2FE (766)] 1c fc 00 74       */
move.b   #0x73,(%a6)+         /* [0x302 (770)] 1c fc 00 73       */

Alors là, on peut difficilement faire pire!
  • 3 premières lignes à remplacer par lea 2(a7),a6
  • série de move.b à remplacer par une copie en boucle d'une constante stockée hors du code
  • inutile de copier octet par octet sur la pile, on sait que la destination est alignée
  • Pourquoi passes-tu une chaîne de caractères par valeur?! La recopie est inutile.


4.
addq.l   #8,%a7               /* [0x2D4 (724)] 50 8f             */
lea      (-0x32,%a7),%a7      /* [0x2D6 (726)] 4f ef ff ce       */

Une instruction suffit.

5.
move.w   #0x4,%d1             /* [0x2DA (730)] 32 3c 00 04       */
move.w   %d1,-(%a7)           /* [0x2DE (734)] 3f 01             */

Ici aussi.
-Edité le Mardi 4 janvier 2005 à 22:37 par Kevin Kofler-
-Edité le Mercredi 5 janvier 2005 à 03:24 par Kevin Kofler-
-Edité le Mercredi 5 janvier 2005 à 03:24 par Kevin Kofler-
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123        
./Post n°1
Kevin Kofler Ecrit le: Mardi 4 janvier 2005 à 22:41 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


À titre de comparaison, voilà ce que génère TIGCC pour cet extrait (3.-5.):
  move.w #4,-(%sp)
  pea .LC3
  move.w #76,-(%sp)
  move.w #60,-(%sp)
  .word _F_LINE+0x1A9

avec:
.LC3:
  .ascii "presents\0"

et ce que génère ETP:
lea      (-0x32,%a7),%a7      /* [0x2D6 (726)] 4f ef ff ce       */
move.w   #0x4,%d1             /* [0x2DA (730)] 32 3c 00 04       */
move.w   %d1,-(%a7)           /* [0x2DE (734)] 3f 01             */
movea.l  %a7,%a0              /* [0x2E0 (736)] 20 4f             */
addq.l   #2,%a0               /* [0x2E2 (738)] 54 88             */
movea.l  %a0,%a6              /* [0x2E4 (740)] 2c 48             */
move.b   #0x70,(%a6)+         /* [0x2E6 (742)] 1c fc 00 70       */
move.b   #0x72,(%a6)+         /* [0x2EA (746)] 1c fc 00 72       */
move.b   #0x65,(%a6)+         /* [0x2EE (750)] 1c fc 00 65       */
move.b   #0x73,(%a6)+         /* [0x2F2 (754)] 1c fc 00 73       */
move.b   #0x65,(%a6)+         /* [0x2F6 (758)] 1c fc 00 65       */
move.b   #0x6E,(%a6)+         /* [0x2FA (762)] 1c fc 00 6e       */
move.b   #0x74,(%a6)+         /* [0x2FE (766)] 1c fc 00 74       */
move.b   #0x73,(%a6)+         /* [0x302 (770)] 1c fc 00 73       */
move.b   #0x0,(%a6)+          /* [0x306 (774)] 1c fc 00 00       */
move.l   %a0,-(%a7)           /* [0x30A (778)] 2f 08             */
move.w   #0x4C,%d1            /* [0x30C (780)] 32 3c 00 4c       */
move.w   %d1,-(%a7)           /* [0x310 (784)] 3f 01             */
move.w   #0x3C,%d1            /* [0x312 (786)] 32 3c 00 3c       */
move.w   %d1,-(%a7)           /* [0x316 (790)] 3f 01             */
movea.l  0xC8,%a4             /* [0x318 (792)] 28 78 00 c8       */
movea.l  (0x6A4,%a4),%a4      /* [0x31C (796)] 28 6c 06 a4       */
jsr      (%a4)                /* [0x320 (800)] 4e 94             */
lea      (0xA,%a7),%a7        /* [0x322 (802)] 4f ef 00 0a       */
lea      (0x32,%a7),%a7       /* [0x326 (806)] 4f ef 00 32       */


J'espère que tu avoueras qu'il y a encore pas mal de progrès à faire...
-Edité le Mardi 4 janvier 2005 à 22:41 par Kevin Kofler-
-Edité le Mercredi 5 janvier 2005 à 03:23 par Kevin Kofler-
-Edité le Mercredi 5 janvier 2005 à 03:26 par Kevin Kofler-
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123      
./Post n°2
Nounours Ecrit le: Mercredi 5 janvier 2005 à 01:14 Déconnecté(e)    Voir le profil de Nounours Envoyer un email à Nounours Visiter le site WEB de Nounours Envoyer un message privé à Nounours  


Oui il y a des progrès à faire.

Je l'ai deja dit n fois que ma gestion de string était "provisoire"!!! en effet les strings sont des tableaux de 50 caractère, ce qui peut etre limitant, et leur gestion est également assez rudimentaire (comme sur ton exemple). Cela dit, ca permet d'utiliser ETP et lorsque la vraie version de la gestion des strings sera en place, l'utilisateur n'aura rien à changer à ses codes.

Il y a d'autres optimisations à faire que tu n'as visiblement pas vu mais dont je suis au courant. Par exemple la declaration de plein de variables locales à la suite..

Il est vrai que ETP n'est pas parfait. Les exemples que tu donnes sont pertinents. Mais il faut me laisser le temps. Tu es d'accord que faire un compilateur tout seul n'est pas une chose évidente. Et je n'ai jamais dit que c'était la version finale de ETP. Je vais bien sur l'améliorer en mettant en priorité la demande des utilisateurs.

Malgré tout ca tu t'attaque à mon travail avec un topic dont le titre est limite acceptable, dont le seul objectif semble etre faire de la mauvaise pub. Je suis ouvert aux critiques, ca m'aide à expliquer le fonctionnement de ETP mais si tu continues à être aussi insolant, je vais simplement t'ignorer.
Pour conclure, il faut savoir que ETP est plutot optimisé en vitesse et pas en taille de prog générés (il vise surtout des auteurs de jeu).
concepteur de ETP-Studio http://www.etpstudio.com
membre de OrageStudio http://oragestudio.free.fr
IP: 212.64.194.104      
./Post n°3
Kevin Kofler Ecrit le: Mercredi 5 janvier 2005 à 01:39 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Nounours :
en effet les strings sont des tableaux de 50 caractère

Argh, il y a toujours cette limitation, en plus!?! #sick#

Il y a d'autres optimisations à faire que tu n'as visiblement pas vu mais dont je suis au courant. Par exemple la declaration de plein de variables locales à la suite..

J'ai juste survolé le binaire, c'est sûr qu'il doit y avoir d'autres trucs lourds.

Tu es d'accord que faire un compilateur tout seul n'est pas une chose évidente.

Certes. Mais je ne vois pas l'intérêt de le faire.

Je t'attrappe sans arrêt en train de faire de la pub pour ton projet, en disant des trucs du style "ETP révolutionne la programmation TI", "je veux une news pour ETP", "ETP rend TIGCC obsolète" (#ptdr#), ... Ça me gonfle franchement, en vue de ce qu'il y a derrière cette pub: un compilateur bogué (cf. code incompatible Titanium), très limité, qui n'apporte strictement rien de nouveau (du point de vue de l'utilisateur, hein - il est évident que tu y as mis beaucoup de travail) par rapport à ce qui existe déjà (TIGCC, TIFS). La seule chose qui distingue ton langage du C est la syntaxe.

Et je n'ai jamais dit que c'était la version finale de ETP. Je vais bien sur l'améliorer en mettant en priorité la demande des utilisateurs.

Tu peux choisir de ne pas m'écouter vu que je ne suis pas un de tes utilisateurs, mais en tant que "collègue", je te conseille de:
  • travailler l'optimisation! La sortie actuelle est catastrophique.
  • permettre d'utiliser tous les ROM_CALLs, pas seulement quelques ROM_CALLs assortis et renommés avec des noms fantaisistes (DrawStr->Locate, DrawLine->Line, FontSetSys->Font)
  • gérer les constantes. Pour un langage qui se veut "plus simple" que le C, voir 4 à la place de A_NORMAL fait mal aux yeux!
  • améliorer la gestion des chaînes de caractères. Là est le pratiquement le seul domaine où ton langage pourrait se distinguer du C, et la gestion actuelle est inacceptable. Copier une chaîne constante sur la pile avec une instruction par octet (et cela après 3 instructions de calcul d'adresses et 1 instruction pour préparer la pile, et suivi d'une instruction un peu plus loin pour défaire la pile) n'est vraiment pas tolérable de la part d'un compilateur "production".


Malgré tout ca tu t'attaque à mon travail avec un topic dont le titre est limite acceptable

Que veux-tu que je te dise, le code généré par ETP me fait mal aux yeux, AMS est une merveille d'optimisation en comparaison!

dont le seul objectif semble etre faire de la mauvaise pub.

Non, je te signale tout ce que tu peux faire mieux en termes de génération de code (dont un changement trivial est de corriger ta routine de gris pour détecter la Titanium correctement).

Pour conclure, il faut savoir que ETP est plutot optimisé en vitesse et pas en taille de prog générés (il vise surtout des auteurs de jeu).

Ah bon, depuis quand une copie octet par octet avec un immediate par octet est "optimisée en vitesse"?! Et tous les autres morceaux de code que j'ai montrés sont eux aussi mauvais autant en vitesse qu'en taille.

Tu veux que je fasse un bench de vitesse ETP vs. TIGCC pour qu'on rigole?
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123      
./Post n°4
verytourist Ecrit le: Mercredi 5 janvier 2005 à 01:44 Déconnecté(e)    Voir le profil de verytourist Envoyer un email à verytourist Visiter le site WEB de verytourist Envoyer un message privé à verytourist  



dont le seul objectif semble etre faire de la mauvaise pub.

Non, je te signale tout ce que tu peux faire mieux en termes de génération de code (dont un changement trivial est de corriger ta routine de gris pour détecter la Titanium correctement).


Lorsqu'on lit le titre du topic, c'est ce qu'il ressort... (que tu fasse de la mauvaise pub [edit] et je suis gentil[/edit])

Edit: Fr+completion
-Edité le Mercredi 5 janvier 2005 à 01:57 par verytourist-
Verytourist,
Programme pour 68k (et z80)en Ti-basic et C.

Webmaster de
www.Ti-Gruge.fr.st
IP: 83.192.231.231      
./Post n°5
Sn00zE Ecrit le: Mercredi 5 janvier 2005 à 01:44 Déconnecté(e)    Voir le profil de Sn00zE Envoyer un email à Sn00zE Visiter le site WEB de Sn00zE Envoyer un message privé à Sn00zE  


Sur ce coup c'est vrai Kevin, que ton attitude n'est pas extra.
Comme l'a fait remarquer Nournours tes remarques sont pertinantes et constructives, ce qui je pense va l'aider a avancer (et oui car tu semble l'oublier qu'il s'agit encore d'un projet et qu'aucune version finale n'est sortie).
Ensuite tu fait des comparaisons entre TIGCC et ETP qui n'on aucune raison d'etre (et d'ailleurs Nounours n'en fait aucune) deja parceque le langage utilisé n'est pas le meme, de plus il est normal que TIGCC soit plus avance que ETP car vous etes dessus depuis beaucoup plus longtemps. Ils ne s'adressent pas aux memes personnes, aux memes utilisations. Et enfin tu semble croire que Nounours clame que ETP va "detroner" TIGCC.
Et meme dans le cas ou il serai possible de comparer ces deux logiciels et qu'effectivement TIGCC se revele "superieur" (je ne voi pas trop en quoi ni comment) de quel droit te permet tu de critiquer ETP comme tu le fait en allant jusqu'a dire que (osont le mot) c'est une merde. C'est exactement le comportement qui etait denoncé sur yaronet et c'est contre cela que TI-Gen s'est créé. C'est a dire qu'il devai y voir un partage des connaissances et une entraide apparente. Ce que tu fait revien au meme que si Geogeo (qui a quand meme des jeux tels que Nebulus et Arkanoid) ou alors JFG(avec bomberdude) venai descendre l'utilisateur lambda qui decide de programmer un prog' pour son cours de maths et qui vien demander conseil aux programmeurs agueris.
Ton comportement est tout simplement lamentable, et d'autant plus que tu es "moderateur general".
Ne sous-estimez pas le pouvoir de la banane...... #banane#
IP: 83.154.64.253      
./Post n°6
Kevin Kofler Ecrit le: Mercredi 5 janvier 2005 à 01:50 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Sn00zE :
deja parceque le langage utilisé n'est pas le meme

Sur le fond, si. Ce n'est que la syntaxe qui change. Cf. http://www.tigen.org/pws/forum/index.php?action=sujet&forum=10&cat=101&topic=1544&page=1#10.
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123      
./Post n°7
Nounours Ecrit le: Mercredi 5 janvier 2005 à 03:00 Déconnecté(e)    Voir le profil de Nounours Envoyer un email à Nounours Visiter le site WEB de Nounours Envoyer un message privé à Nounours  


BOn allez je me lance..
Kevin Kofler :
Sn00zE :
deja parceque le langage utilisé n'est pas le meme

Sur le fond, si. Ce n'est que la syntaxe qui change. Cf. http://www.tigen.org/pws/forum/index.php?action=sujet&forum=10&cat=101&topic=1544&page=1#10.

Un prog écrit en Ada aussi tu peux le transcrire en C 1:1. Un prog écrit en Vb, tu peux le transcrire en C++ 1:1 exactement comme tu as fais. Imagine on publie les fichiers general.c et general.etp , tu prend le rapport cardinal(gens_qui_captent_general.c) / cardinal(gens_qui_captent_general.etp) je pense que ca tend vers 0. Tu vois ce que je veux dire?

Kevin Kofler :
Nounours :
en effet les strings sont des tableaux de 50 caractère

Argh, il y a toujours cette limitation, en plus!?! #sick#

#Mode "Repeat After Me"=ON#
La gestion des strings est PROVISOIRE!!!
#Mode "Repeat After Me"=OFF#

Certes. Mais je ne vois pas l'intérêt de le faire.

C'est vrai, il existe deja plein de compilateurs pour le PC, je ne vois pas non plus pourquoi ils en font des nouveaux?? Y avait deja Visual C++ avec ces MFC, je vois pas l'interet de VB moi??
C'est pas parce que tu ne t'en servira pas que ce n'est pas utile.

Kevin Kofler :
Et je n'ai jamais dit que c'était la version finale de ETP. Je vais bien sur l'améliorer en mettant en priorité la demande des utilisateurs.

Tu peux choisir de ne pas m'écouter vu que je ne suis pas un de tes utilisateurs...

Je veux dire "utilisateur" au sens large, pas forcément un membre du fan club. Un gars qui a testé un truc et qui me fait part des imperfections, pour moi c'est un utilisateur.

Je t'attrappe sans arrêt en train de faire de la pub pour ton projet...

hein?? je fais pas plus de pub plus qu'il n'en faut.. j'ai fait un nouveau soft, j'aimerais que maximum de gens puisse en profiter (si possible sans qu'ils croient qu'en l'installant ca va détruire leur ordinateur, ou bien que c'est radioactif tant qu'à faire!!)

"ETP révolutionne la programmation TI"
pour les jeux.. oui.
"je veux une news pour ETP"
Je n'ai jamais dis ca. Serioussam a demandé à maintes reprises si j'en voulais un, je lui ai dis d'attendre pendant des mois!! Et une fois seulement j'ai demandé à en avoir. Alors quand je vois cette citation, ca me met hors de moi!! Quand les autres sites ont des news avant ti-gen concernant ETP tu rales, quand je veux une news sur ti-gen tu rales aussi! mais enfin tu veux quoi?

"ETP rend TIGCC obsolète" (#ptdr#)
#ptdr# également c'était une blague, j'étais moi meme #ptdr# quand je l'ai écrit et toi aussi, alors ne fais pas de la désinformation.

qui n'apporte strictement rien de nouveau (du point de vue de l'utilisateur, hein
Justement ca apporte beaucoup du coté de l'utilisateur. La simplicité. Si ca ne saute pas aux yeux (encore que comme je l'ai dis on peut regarder le nombre de gens qui comprennent le prog en etp sans comprendre celui de C) avec MineSweeper, va jeter un coup d'oeil du coté du Map Editor (technologie non utilisé dans MineSweeper).. Je vais refaire mon jeu de foot avec etp également. De plus, tu es un boss en C, donc faire un tel prog ne te pose aucun probleme mais imagine un gars qui ne maitrise pas de tels lignes de code:

#define ImportBitmap(bmp) 
extern BITMAP bmp##d; 
extern BITMAP bmp##l; 
asm(".section " #bmp 
    "d,"dm""); 
import_binary(#bmp "d.bin",bmp##d 
             ); 
asm(".section " #bmp 
    "l,"dm""); 
import_binary(#bmp "l.bin",bmp##l 
             );

...

INT_HANDLER int1=GetIntVec(AUTO_INT_1);
INT_HANDLER int5=GetIntVec(AUTO_INT_5);
SetIntVec(AUTO_INT_1,DUMMY_HANDLER);
SetIntVec(AUTO_INT_5,AI5Counter);

si si ca existe.

La seule chose qui distingue ton langage du C est la syntaxe.

Comme je l'ai dit, y a bien plus (tu te bases sur un seul prog). Mais rien que ca, c'est deja pas mal. (cf le paragraphe apres la premiere citation)

Tu peux choisir de ne pas m'écouter vu que je ne suis pas un de tes utilisateurs, mais en tant que "collègue"

Je t'écoute car je répond à tes critiques, je te remercie pour tes critiques. Mais en tant que "collègue" tu te permet d'envoyer des gros mots (des adjectifs qualifiant etp) alors que tu es modérateur.. c'est surtout ce comportement que je critique et non pas le fait que tu critiques. Je devrais peut etre demander à etre modérateurs dans cette section mais c'est pas plus mal comme ca, car je prefere que ca soit les admins qui voient ton manque de respect et prennent les mesures nécessaires, plutot que je lock et qu'on m'accuse de locker des critiques constructives. Les soit-disant conseils que tu donnes font deja partie de mon fichier TO DO, je l'ai dit quelques posts plus haut et dans divers topics et sur le chan.

ETP me fait mal aux yeux
...
je te signale tout ce que tu peux faire mieux en termes de génération de code
C'est fou comme tu changes d'expression :D C'est sur que ca change de "affreux",... "a la con" Malheuresement j'aurais preferé un tel parlé dès le départ.

Kevin Kofler :
Pour conclure, il faut savoir que ETP est plutot optimisé en vitesse et pas en taille de prog générés (il vise surtout des auteurs de jeu).

Ah bon, depuis quand une copie octet par octet avec un immediate par octet est "optimisée en vitesse"?! Et tous les autres morceaux de code que j'ai montrés sont eux aussi mauvais autant en vitesse qu'en taille.


#Mode "Repeat After Me"=ON#
La gestion des strings est PROVISOIRE!!!
#Mode "Repeat After Me"=OFF#
Je ne parle évidemment pas de la gestion des strings!! (encore une fois, je devrais faire un "copier" puis "coller" à chaque fois, c'est lourd de le réecrire quoi alors fais un effort aussi) Je veux dire d'une manière globale. Bien que mon but n'est pas de comparer etp avec tigcc, les routines d'affichage de ETP sont beaucoup plus optimisés que les routines de la librairie de TIGCC mais là aussi il faut avoir utilisé le Map Editor.

Tu veux que je fasse un bench de vitesse ETP vs. TIGCC pour qu'on rigole?
Ouais si tu veux, j'ai deja fait des tests et les ai publiés. C'était concernant fibo en récursif, le truc qui teste beaucoup de choses sur un compilateur (pas tout ok mais ca donne une idée). Je suis personnelement assez satisfait des résultats (surtout avec si peu d'optimisation). Avec les optimisations prévues, je devrais atteindre des meilleurs résultats :D
concepteur de ETP-Studio http://www.etpstudio.com
membre de OrageStudio http://oragestudio.free.fr
IP: 212.64.194.104      
./Post n°8
Kevin Kofler Ecrit le: Mercredi 5 janvier 2005 à 03:23 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Nounours :
Un prog écrit en Ada aussi tu peux le transcrire en C 1:1. Un prog écrit en Vb, tu peux le transcrire en C++ 1:1 exactement comme tu as fais.

Euh, pas vraiment. Le VB a des features comme:
  • les chaînes de caractères (non-provisoires :D)
  • les objets (!)
  • les types Variant
  • les tests de débordement ("bound checks" et "overflow checks")
  • ...
qui ne se traduisent pas sans pertes en C (ni en C++ d'ailleurs). (Je veux dire par là qu'on peut générer du code C, mais ce ne sera pas une correspondance 1:1 comme ici. (Par exemple, il n'y aura pas écrit a+b, mais AddVariant(a,b) qui est nettement moins lisible. En C++, tu as l'overloading d'opérateurs pour cet exemple-là, mais tu ne peux quand-même pas transposer le code 1:1 sans changer le comportement.) Tu diras peut-être que j'ai triché en mettant des trucs comme ReverseScreenLight inline, mais j'aurais très bien pu le déclarer comme fonction, inline ou pas, ou en tant que macro, et on aurait vu la correspondance 1:1.)

Imagine on publie les fichiers general.c et general.etp , tu prend le rapport cardinal(gens_qui_captent_general.c) / cardinal(gens_qui_captent_general.etp) je pense que ca tend vers 0. Tu vois ce que je veux dire?

Moi, je pense plutôt que ça tend vers 1. :D Le code est pratiquement le même!

j'ai fait un nouveau soft, j'aimerais que maximum de gens puisse en profiter

C'est noble comme but, mais ce qui me dérange, c'est de voir de la publicité "mensongère", plus précisément de la publicité qui cache des détails important tout en restant vraie. (Je sais que toute la publicité des entreprises commerciales fonctionne comme ça, mais ce n'est pas une raison de faire pareil.) Que de maximum de gens puissent en profiter, c'est bien. Que des gens soient poussés à l'utiliser sans connaître les désavantages, ce n'est pas bien.

"ETP révolutionne la programmation TI"
pour les jeux.. oui.

Ah, parce que c'est une révolution d'écrire:
Procedure DrawAll()

  Local i as Integer
  Local j as Integer
  If CameraY = 4 Then
    For i=96 To 100
      LightPlane
      Line 0,i,160,i,4
      DarkPlane
      Line 0,i,160,i,0
    Next i
  EndIf
  
  For i=0 To 15
    For j=0 To 15
      ShowBloc i,j
    Next
  Next

à la place de:
void DrawAll(void) {
  int i, j;
  if (CameraY == 4) {
    for(i=96;i<=100;i++) {
      GraySetAMSPlane(LIGHT_PLANE);
      DrawLine(0,i,160,i,4);
      GraySetAMSPlane(DARK_PLANE);
      DrawLine(0,i,160,i,0);
    }
  }
  
  for(i=0;i<=15;i++)
    for(j=0;j<=15;j++)
      ShowBloc(i,j);
}

?!

Si ca ne saute pas aux yeux (encore que comme je l'ai dis on peut regarder le nombre de gens qui comprennent le prog en etp sans comprendre celui de C) avec MineSweeper, va jeter un coup d'oeil du coté du Map Editor (technologie non utilisé dans MineSweeper)..

Je suis désolé, mais toutes ces technologies sont parfaitement transposables au C.

Je vais refaire mon jeu de foot avec etp également. De plus, tu es un boss en C, donc faire un tel prog ne te pose aucun probleme mais imagine un gars qui ne maitrise pas de tels lignes de code:

#define ImportBitmap(bmp) 
extern BITMAP bmp##d; 
extern BITMAP bmp##l; 
asm(".section " #bmp 
    "d,"dm""); 
import_binary(#bmp "d.bin",bmp##d 
             ); 
asm(".section " #bmp 
    "l,"dm""); 
import_binary(#bmp "l.bin",bmp##l 
             );

Ça, on peut le mettre dans un header, et il suffira de faire: #include "bitmaps.h" et on n'a pas besoin de se soucier de comment marche ce code. Et non, le débutant en C n'aura pas besoin d'écrire lui-même le header, juste de prendre mon header et de l'inclure.

INT_HANDLER int1=GetIntVec(AUTO_INT_1);
INT_HANDLER int5=GetIntVec(AUTO_INT_5);
SetIntVec(AUTO_INT_1,DUMMY_HANDLER);
SetIntVec(AUTO_INT_5,AI5Counter);

Ça aussi, ça peut se mettre dans un header. Soit en tant que macro, soit carrément dans une section de démarrage (ne sous-estime pas la puissance de ld-tigcc).

Je ne parle évidemment pas de la gestion des strings!! (encore une fois, je devrais faire un "copier" puis "coller" à chaque fois, c'est lourd de le réecrire quoi alors fais un effort aussi) Je veux dire d'une manière globale.

Le tst.l d4 après un move.l a0,d4 n'a rien à voir avec la gestion des chaînes. La gestion sous-optimale de la pile (ajustements redondants, parfois un directement après l'autre) non plus.

Bien que mon but n'est pas de comparer etp avec tigcc, les routines d'affichage de ETP sont beaucoup plus optimisés que les routines de la librairie de TIGCC mais là aussi il faut avoir utilisé le Map Editor.

Je te signale qu'il y a ExtGraph 2 aussi, en C...
-Edité le Mercredi 5 janvier 2005 à 03:32 par Kevin Kofler-
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123      
./Post n°9
geogeo Ecrit le: Mercredi 5 janvier 2005 à 11:44 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Kevin Kofler> Tu pousses un peu trop loin le bouchon!
Cette photo n'est pas un trucage, Dédé existe vraiment, ne le sous estimez pas!
Alors grattez-le!
IP: 82.253.203.180      
./Post n°10
serioussam Ecrit le: Mercredi 5 janvier 2005 à 13:56 Déconnecté(e)    Voir le profil de serioussam Envoyer un email à serioussam Visiter le site WEB de serioussam Envoyer un message privé à serioussam  


Allez, hop, le vase a débordé #rage#

EDIT : tiens, je viens juste de remarquer que tu prends des libertés vis-à-vis de moi maintenant. Je m'en souviendrais.
-Edité le Samedi 15 janvier 2005 à 12:31 par serioussam-
Hafnarfjördur !
La Serious Letter, ma chronique hebdo.

Toute reproduction partielle ou totale de ce post est strictement interdite. ©
IP: 82.64.129.115      
./Post n°11
Kevin Kofler Ecrit le: Mercredi 5 janvier 2005 à 23:22 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Lock de topic injustifié.
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123      
./Post n°12
geogeo Ecrit le: Mercredi 5 janvier 2005 à 23:24 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Ne jouez pas trop longtemps à ce jeu!
Retour au topic et par pitié comme il faut!
-Edité le Mercredi 5 janvier 2005 à 23:24 par geogeo-
Cette photo n'est pas un trucage, Dédé existe vraiment, ne le sous estimez pas!
Alors grattez-le!
IP: 82.253.203.180      
./Post n°13
Nounours Ecrit le: Jeudi 6 janvier 2005 à 00:20 Déconnecté(e)    Voir le profil de Nounours Envoyer un email à Nounours Visiter le site WEB de Nounours Envoyer un message privé à Nounours  


Kevin, tu ne réponds pas à toutes mes remarques, je suppose que tu as compris ce que je critique dans ta façon de poster.

Si tu arrives sans trop de difficulté à faire le meme jeu en C, tant mieux pour toi, ce n'est pas le cas pour tout le monde. Les utilisateur décideront si ca vaut le coup d'apprendre le C.

Et pour le reste, les optimisations viendront avec le temps.
Voici une petite histoire:

Il était une fois un petit étudiant qui voulait programmer un utilitaire pour visualiser ses notes sur sa calculatrice en pensant que le tableur integré n'était pas adapté pour calculer sa moyenne de facon précise. Il a découvert un compilateur C pour sa calculatrice et a programmé le logiciel en question sous le nom de STUDLOOK. Une fois compilé le prog faisait 20 Ko! Mais ca ne lui posait aucun probleme. Deux ans plus tard, d'autres voulaient améliorer son code pour adapter le prog à la v200. Il leur a alors donné le code qu'il n'avait pas touché depuis. Mais là, surprise!! Le programme compilé ne faisait plus que 10 Ko et ne fonctionnait pas correctement. Pourtant il n'avait pas modifié une seule ligne! Et la, il s'est rendu compte que ca venait de la nouvelle version du compilateur en question, qui mettait ses nouvelles optimisations en route par défaut. Le meme programme faisait la moitié, deux ans plus tard. Pourtant personne n'avait crié au scandale à l'époque où le meme prog faisait 20 Ko, ni insulté le travail de l'équipe qui avait accompli un travail utile à des milliers de programmeurs grace à un travail acharné (qui vraisemblement n'était pas terminé). Fin
concepteur de ETP-Studio http://www.etpstudio.com
membre de OrageStudio http://oragestudio.free.fr
IP: 212.64.194.49      
./Post n°14
Kevin Kofler Ecrit le: Jeudi 6 janvier 2005 à 00:34 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


et ne fonctionnait pas correctement. Pourtant il n'avait pas modifié une seule ligne! Et la, il s'est rendu compte que ca venait de la nouvelle version du compilateur en question, qui mettait ses nouvelles optimisations en route par défaut.

  • Et tu as fait un bug report? Faut pas te plaindre sinon.
  • C'est peut-être déjà corrigé, il y avait des bogues dans l'optimisation du linker dans certaines bêtas en effet.
  • Rien ne dit que c'est un bogue du compilateur et pas une erreur de ton code. J'ai même vu un cas où du code dépendait d'un bogue de la gestion des floats de TIGCC 0.94. (x/15. était remplacé par x*inv15 où inv15 était un arrondi tronqué de 1/15, donc pour x=15, on avait 0.999qqch. et le programme dépendait du fait que (int)(x/15.) donnait 0 pour x=15.) Il a corrigé son code depuis. Je lui ai donné une correction possible qui était de coder explicitement ce que faisait TIGCC 0.94, mais il a réécrit le calcul plus proprement.

EDIT: C'est bien une erreur dans le programme, il stocke des données dans des variables globales non-initialisées. Le minimum à faire est de mettre une initialisation pour que les variables ne soient pas en BSS. Une solution propre est de stocker ces données importantes dans un fichier externe archivé, pas dans des variables globales dans le programme.

Le meme programme faisait la moitié, deux ans plus tard.

TIGCC 0.95 peut faire des miracles, en effet. :p

Mais le code de TIGCC 0.94 n'était pas du code mal optimisé comme celui que j'ai relevé dans ce topic, c'était probablement que tu avais de gros tableaux globaux que TIGCC 0.95 a mis dans des sections BSS pour toi. Le fait que TIGCC 0.94 ne gérait pas les BSS en _nostub était documenté et ça aurait été à toi d'allouer tes tableaux avec malloc. ETP génère du mauvais code quoiqu'en fasse. Si TIGCC génère du mauvais code, c'est souvent la faute du programmeur.
-Edité le Jeudi 6 janvier 2005 à 00:35 par Kevin Kofler-
-Edité le Jeudi 6 janvier 2005 à 00:55 par Kevin Kofler-
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123      
./Post n°15
Nounours Ecrit le: Jeudi 6 janvier 2005 à 01:16 Déconnecté(e)    Voir le profil de Nounours Envoyer un email à Nounours Visiter le site WEB de Nounours Envoyer un message privé à Nounours  


C'était pas un bogue, il fallait qu'il n'y ait pas d'optimisation pour que le programme fonctionne car il a été fait à l'époque ou il n'y en avait pas. Et suite à notre discussion sur le chan, je voudrais tu dire que je ne discute pas si STUDLOOK est bien fait ou mal fait. Tu n'as visiblement pas compris la morale de cette histoire #kc# alors je vais te l'écrire noir sur blanc.

LA MORALE DE L'HISTOIRE PRECEDENTE ETAIT:
TIGCC n'était pas super optimisé dès le début et laisse moi le temps d'améliorer mon soft au lieu de crier au scandale!!!!!!!!
#mur#

Je vais supposer que tu es assez intelligent pour avoir compris tous les points, et par contraposition toutes tes remarques/critiques non faits dans les normes et dans le respect seront tout simplement ignorés.
concepteur de ETP-Studio http://www.etpstudio.com
membre de OrageStudio http://oragestudio.free.fr
IP: 212.64.194.49      
./Post n°16
Kevin Kofler Ecrit le: Jeudi 6 janvier 2005 à 01:39 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Nounours :
TIGCC n'était pas super optimisé dès le début et laisse moi le temps d'améliorer mon soft au lieu de crier au scandale!!!!!!!!
#mur#

Non, TIGCC générait du mauvais code parce que tu lui as demandé de générer du mauvais code en créant un gros tableau global alors qu'il était dit dans la documentation d'utiliser malloc. Si TIGCC génère du mauvais code, c'est souvent parce que le programmeur qui l'utilise est incompétent.

Et puis ce n'était pas du mauvais code vu que c'était le code que tu t'es attendu et duquel tu dépendais. :p Mais une fois de plus, tu n'as pas lu la documentation qui disait clairement que le comportement allait changer et que pour avoir dans tous les cas un tableau directement dans le programme, il fallait l'initialiser explicitement, style int tableau[100][100]={}; plutôt que int tableau[100][100];. Et il y a aussi le switch de compatibilité -mno-bss.

Et pour finir, ce n'est pas une histoire de code comme les morceaux que j'ai postés, c'est une histoire d'endroit d'allocation des données.
-Edité le Jeudi 6 janvier 2005 à 01:40 par Kevin Kofler-
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123      
./Post n°17
Nounours Ecrit le: Jeudi 6 janvier 2005 à 01:43 Déconnecté(e)    Voir le profil de Nounours Envoyer un email à Nounours Visiter le site WEB de Nounours Envoyer un message privé à Nounours  


Tu évites le vrai sujet, encore une fois

Nounours :
LA MORALE DE L'HISTOIRE PRECEDENTE ETAIT:
TIGCC n'était pas super optimisé dès le début et laisse moi le temps d'améliorer mon soft au lieu de crier au scandale!!!!!!!!
#mur#


c'est à desespérer #tsss#
concepteur de ETP-Studio http://www.etpstudio.com
membre de OrageStudio http://oragestudio.free.fr
IP: 212.64.194.49      
./Post n°18
Kevin Kofler Ecrit le: Jeudi 6 janvier 2005 à 01:57 Connecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Je n'évite pas, je te dis que c'est faux!
TIGCC n'a jamais donné du code comme celui que j'ai relevé chez ETP. Même en -O0 et sans aucune optimisation du linker, TIGCC donne du code meilleur que ETP. Le fait que tu ne veuilles pas comprendre ça est à désespérer.

L'exemple que tu cites est un exemple où tout utilisateur qui a eu du mauvais code l'a eu parce qu'il n'a pas lu la documentation qui disait clairement comment obtenir du code meilleur. Avec ETP, il n'y a aucun moyen de ne pas avoir le mauvais code que j'ai relevé.
Kevin Kofler - Modérateur général et newseur. Vous voulez une news? http://www.tigen.org/pws/message.php?id=39 :)

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
IP: 213.47.68.123      
./Post n°19
verytourist Ecrit le: Jeudi 6 janvier 2005 à 19:30 Déconnecté(e)    Voir le profil de verytourist Envoyer un email à verytourist Visiter le site WEB de verytourist Envoyer un message privé à verytourist  

N'empéche que soit tu n'a pas saisi ce qu'il voulait dire, soit t'es vraiment un cas désespéré. Au choix :D

Edit: Fr
-Edité le Vendredi 7 janvier 2005 à 22:21 par verytourist-
Verytourist,
Programme pour 68k (et z80)en Ti-basic et C.

Webmaster de
www.Ti-Gruge.fr.st
IP: 62.161.76.170      
  :: Index » Forum Ti68K » Programmation ETP Studio » Code généré affreux (38 réponse(s))
Pages : 1/2     « [1] 2 » »|

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Page générée en 931ms avec 25 requetes