Où est CC ? - Page 5

Kevin> Les IDE que tu as cité sont bien moins efficaces que MSVC

De toute facon, Jarode et Kevin ont déja énormément travailler pour adapter de nombreuses fonctions sur AS() et CC(), et j'ai bien l'intention d'en intégrer quelques unes (sans vous oublier bien sur) dans mes programmes

Kevin> sauf que qd tu n'as pas le droit d'installer de logiciels...

kevin> Alors la je pige plus la derniere fois que g trainer sur msdn online, il refusait de me sortir le guide des api :/ je pige plus rien a leur site :/

Perso je trouve que MSDN est très mal fichu j'ai jamais réussi a trouver quoi que se soit dans ce bordel

MSDN est surement tres complet (le site)...
mais c un foutoir immonde
et vu que c pas mal complet, la fonction de recherche te renvoie toujours trop de resultats...

et MSDN en version off-line... bah, la version que j'ai, elle est pas a la derniere norme ANSI pr le C++, deja...
(elle utilise toujours les vieux headers en .h)

squale92 a écrit :
Kevin> sauf que qd tu n'as pas le droit d'installer de logiciels...

Ben, en milieu scolaire/universitaire ou d'entreprise, ils sont censés installer au moins un IDE et l'éditeur de ressources, eux (et cela que vous ayez le droit de les installer vous-même ou non; ça ne devrait pas être à vous de le faire). C'est tout gratuit, donc il n'y a aucune raison pour eux de ne pas le faire. De la même manière qu'ils peuvent faire un choix pour M$VC, ils peuvent en faire un pour MinGW + Dev-C++ + éditeur de ressources de LCC-Win32. La raison que tu donnes n'est pas une raison valable en justification de leur choix pour M$VC.

bah, le choix qu'ils ont fait est MSVC.
j'ai pas eu mon mot a dire

et sinon, on a GCC sur le serveur UNIX... mais en interface texte... alors, pour dessigner des fenetres, c pas le pieds

ma foi, ils ont choisi la solution payante plutot que la solution gratuite...
libre a eux...
je suppose que leur choix a ete guide par le fait que c'est ce qui est utilise en milieu professionnel, ou quelque chose dans ce genre... enfin, qu'est-ce que j'en sais

squale92 a écrit :
bah, le choix qu'ils ont fait est MSVC.
j'ai pas eu mon mot a dire

Tu n'as toujours pas compris que ce n'est pas toi que je critique, mais eux! Ce sont ceux qui ont fait le choix qui, à mon avis, ont fait le mauvais choix. Tu n'as pas fait le choix, toi, donc tu n'y es pour rien.

bah je sais bien que j'y suis pr rien

XDanger & Kevin : toujours aussi minables. Vous démontrez bien une fois de plus que vous encouragez les programmeurs qui collent à vos idées et que vous êtes prêts à tout pour couler les projets les plus formidables dès qu'ils ne correspondent pas à 100 % à vos idées.

M'enfin, vous n'avez très heureusement aucun pouvoir dans cette communauté et beaucoup de monde sera hyper-heureux de la venue de GTC qui permet de programmer très confortablement sur sa calculatrice quand on en a besoin. Même s'il n'est pas aussi bien que GTC il est très fonctionnel et ce n'est absolument pas une raison pour le démonter comme vous faites. Oui, vraiment, je vois pas pourquoi. C'est le premier compilateur on-calc, projet formidable, et tout ce que 2 personnes antipathiques trouvent à faire, c'est cracher dessus alors qu'il est le rêve de beaucoup.

Ce compilateur ne dérangera personne puisque ceux qu'il n'intéresse pas ne l'utiliseront pas ! Tout comme ceux que Visual C++ n'intéresse pas utilisent DevC++ (n'est-ce pas Kevichou ?).

Je termine en vous demandant pourquoi vous ne gueulez pas sur CC et ne faites pas de la propagande pour l'envoyer aux oubliettes, étant donné qu'il est infiniment moins compatible avec TIGCC et qu'il optimise moins que GTC... Ce sont bien les arguments que vous exprimez contre GTC...

Voilà, j'ai voulu vous expliquer que vous passez pour deux gros jaloux plutôt bornés, non pas sur GTC (sinon vous auriez aussi coulé CC), mais sur Pollux. Vous ressentez visiblement le besoin d'emmerder du monde. Quand ce n'est pas PpHd, c'est Pollux

Pollux
a écrit : patience, ça va arriver...

lol, Pollux cultive sa réputation !

on a jamais été aussi proche de 2048

oué chaque jour nous en rapproche...

Euh sinon pour ceux qui croient que GTC est moins performant que TI-GCC, avec TIGCC 0.94 b18, TI-Chess recompilé en -Os avec TI-GCC prend 52181 octets alors que TI-Chess compilé avec GTC (en optimisation taille et un peu vitesse) prend 49745 octets (avec les nouvelles optimisations ) Kevin, tu sais pas où je peux trouver GCC 3.3? [UPDATE: j'ai trouvé, j'ai essaye tout de suite]

On pourrait programmer pour PedRom avec GTC ?

Pour l'instant rien de prévu pour PedRom, mais sait-on jamais... Je préfère me concentrer sur la version on-calc.

Et enfin je viens de tester avec GCC 3.3 : 50945 octets

et coté vitesse ,on perd combien?

Pas encore testé. C possible que GTC soit légèrement plus rapide ou plus lent, je ne sais pas.

Thibaut
a écrit : M'enfin, vous n'avez très heureusement aucun pouvoir dans cette communauté et beaucoup de monde sera hyper-heureux de la venue de GTC qui permet de programmer très confortablement sur sa calculatrice quand on en a besoin. Même s'il n'est pas aussi bien que GTC

Raaah, encore une fois!!! (Tu voulais dire "GCC" ici, n'est-ce pas?)
Ces noms se ressemblent trop!!!

C'est le premier compilateur on-calc,

C'est faux. CC est sorti avant.

Tout comme ceux que Visual C++ n'intéresse pas utilisent DevC++ (n'est-ce pas Kevichou ?).

Arrête de m'appeler comme ça immédiatement!!! Je commence vraiment à perdre ma patience avec tes provocations permanentes.
Et ton exemple est justement un exemple parfait pour montrer que tu as tord, vu que les programmes Open Source qui ne compilent (du moins en leur version Win32) qu'avec M$VC++ et pas avec MinGW sont un problème réel et d'ordre majeur (et que donc la présence de M$VC++ dérange beaucoup).

Je termine en vous demandant pourquoi vous ne gueulez pas sur CC

Je ne conseille pas du tout CC pour tout usage sérieux (au contraire, je le déconseille fortement pour tout programme plus complexe de manière significative qu'un "Hello, World!"), et je fais exactement la même chose pour GTC.

Je précise que je ne réponds pas au reste de ce message troll parce que c'est tellement n'importe quoi qu'on ne peut pas y répondre par une argumentation sérieuse.

Pollux a écrit :
Et enfin je viens de tester avec GCC 3.3 : 50945 octets

Argh...
Mais bon, on n'est pas loin. Mais je sens que je vais devoir travailler un peu sur les peepholes m68k de GCC. (Pas sur les optimisations génériques, on peut difficilement faire mieux que ce qui est déjà fait dans GCC. )

C'est le premier compilateur on-calc, projet formidable, et tout ce que 2 personnes antipathiques trouvent à faire, c'est cracher dessus alors qu'il est le rêve de beaucoup.

Tu sais lire ? J'ai répété quoi à propos de GTC on-calc (pas on-PC) à de nombreuses reprises ? En plus, comme l'a fait remarquer Kevin, tu mens.

Je précise que je ne réponds pas au reste de ce message troll parce que c'est tellement n'importe quoi qu'on ne peut pas y répondre par une argumentation sérieuse.

En effet.


La différence entre GTC et GCC 3.3 est de 1250 octets de différence sur une cinquantaine de Ko, ce qui n'est somme toute pas énorme, environ 2,5 %. OK, il est plus petit, les faits sont là, mais ça n'est pas très significatif...
Et pour TI-Chess, c'est difficile de comparer la vitesse du code compilé... TI-Chess n'est pas un bon choix pour cela.

Si GTC supportait l'ASM inline avec opérandes C, on pourrait compiler tthdex dessus...

Donne exactement les options de compilation que tu utilises pour chacun des deux compilateurs, aussi.

Il faudrait voir les points faibles de GCC pour les améliorer. J'en vois peut-être certains, mais ça vient peut-être aussi du fait que je ne sais pas lui faire optimiser comme il faut...

Est-ce que dans GTC, des optimisations simples mais intéressantes en taille du style de celles que fait GCC avec -Wa,-l, sont faites par défaut ?

Ah tiens, c'est une bonne question, ça. Ça me fait penser à ce qu'il faudra que j'essaye de compiler TI-Chess avec les optimisations du linker activées sous ld-tigcc (le futur linker de TIGCC 0.95).

Pollux, tu as testé quelle version de TI-Chess?

Ah, c'est vrai qu'il n'a pas précisé quelle version de TI-Chess il utilisait... J'espère quand même qu'il utilise TI-Chess 4.00. Ca ne changerait probablement pas grand chose de toute façon...

Il faudrait voir si le fix que tu m'as envoyé fait changer la différence de taille...

> Est-ce que dans GTC, des optimisations simples mais intéressantes en taille du style de celles que fait GCC avec -Wa,-l, sont faites par défaut ?
Pour TI-Chess, j'ai inclus tous les fichiers les uns après les autres (donc un seul fichier .o, pas d'histoire de -Wa,-l), et j'ai utilisé les switch du makefile de TI-Chess (en remplaçant -Os/-O2/-O3 par -Os).

> La différence entre GTC et GCC 3.3 est de 1250 octets de différence sur une cinquantaine de Ko, ce qui n'est somme toute pas énorme, environ 2,5 %. OK, il est plus petit, les faits sont là, mais ça n'est pas très significatif...
Entièrement d'accord. Mais comprends moi bien, c'est juste pour faire taire Kevin qui parle de compilateur (je cite) "techniquement inférieur" alors que la différence n'était que de 1% dans l'autre sens.


> Et pour TI-Chess, c'est difficile de comparer la vitesse du code compilé... TI-Chess n'est pas un bon choix pour cela.
OK, donne moi un (ou plusieurs) programme(s) dans lequel la vitesse est significative, je me ferai une joie de faire un comparatif.


> Si GTC supportait l'ASM inline avec opérandes C, on pourrait compiler tthdex dessus...
Rien n'empêche de mettre des #ifdef et de mettre des routines supplémentaires pour GTC... avec le passage par registre, c'est assez efficace.

J'ai testé TI-Chess 4.00 finale. De toutes façons ça ne change rien puisque GTC et TIGCC ont compilé la même source.

>> Ca ne changerait probablement pas grand chose de toute façon...
> J'ai testé TI-Chess 4.00 finale. De toutes façons ça ne change rien puisque GTC et TIGCC ont compilé la même source.
On dit la même chose.

> OK, donne moi un (ou plusieurs) programme(s) dans lequel la vitesse est significative, je me ferai une joie de faire un comparatif.
Ben, je ne sais pas, justement...
Ce qui est sûr, c'est qu'il faudrait se mettre d'accord sur un truc. Il faudrait compter sur HW2 real calc en ticks d'AUTO_INT_1 (c'est même bien plus de précision qu'il ne nous en faut).

Est-ce que dans GTC, des optimisations simples mais intéressantes en taille du style de celles que fait GCC avec -Wa,-l, sont faites par défaut ?

> Est-ce que dans GTC, des optimisations simples mais intéressantes en taille du style de celles que fait GCC avec -Wa,-l, sont faites par défaut ?

Je ne pas encore fait l'exportation de fichiers objet, mais ce sera certainement géré par le projet, et si le projet fait moins de 32ko, ce sera tout le temps activé, sinon partiellement. Sinon pour les autres trucs du style, -fomit-frame-pointer est activé par défaut (je ne vois d'ailleurs pas à quoi ça sert en théorie, sauf si le compilo ne gère pas __attribute__((alloca)))

J'ai demandé la version pour pouvoir faire mes propres tests. Et je n'arrive pas à reproduire ton résultat. Avec ça:

short FastStringWidth(const unsigned char* s);
#define FastStringWidth foobar
#include "tichess.c"
#undef FastStringWidth
#include "logo.c"
#include "generic.c"
#include "bg_ti89.c"
#include "input.c"
#include "interrupt.c"
#include "board.c"
#include "loadsave.c"
#include "infoboards.c"
#include "menu.c"
#include "gui.c"
#include "engine.c"
#include "clocks.c"

en compilant avec "GCC.EXE (GCC) 3.3 20030421 (TIGCC prerelease)" et en linkant avec le système de linking de TIGCC 0.94 (avec la ligne de commande tigcc -Os -fomit-frame-pointer -DUSE_TI89 -DLANG_ENGLISH hack.c), mon fichier n'a pas la taille que tu indiques.

Je ne pas encore fait l'exportation de fichiers objet, mais ce sera certainement géré par le projet, et si le projet fait moins de 32ko, ce sera tout le temps activé, sinon partiellement. Sinon pour les autres trucs du style, -fomit-frame-pointer est activé par défaut (je ne vois d'ailleurs pas à quoi ça sert en théorie, sauf si le compilo ne gère pas __attribute__((alloca)))

Alors à ce moment-là, pour faire un bench correct, on doit mettre -Wa,-l et -fomit-frame-pointer à GCC...

Kevin Kofler
a écrit : ---

... oui, tout à fait

> Alors à ce moment-là, pour faire un bench correct, on doit mettre -Wa,-l et -fomit-frame-pointer à GCC...
* -Wa,-l ne change rien puisqu'il n'y a qu'un seul fichier objet (pas de relocations externes). Et de toutes façons -Wa,-l ne marche certainement pas avec TI-Chess.
* -fomit-frame-pointer est activé (c'est dans le makefile de TI-Chess)