Où est CC ? - Page 11

TIGCC est en Delphi, si je ne me trompe... O3, Os... En delphi ?

arf mince c'est ce que je comptait faire, et tu me dis que ca été déja fait

l'IDE est en delphi...
le compilateur, c'"est GCC...qui doit etre codé en C, je pense, comme la majorité des logiciels unix...

bah l'IDE je vais pas y toucher c'est pas l'interet principal du compilateur. ceci dit d'après ce que j'ai lu sur le portage Linux, il y aurait du delphi pour une partie du compilateur(ce que je trouve louche) mais pas indispensable.

du delphi pr le compilo ?

Pollux> Tu as implémenté plein d'extensions très intéressantes, bravo
Ily en a quand même deux très importantes que j'ai été surpris de ne pas voir : Assembler Instructions with C Expression Operands et Variables in Specified Registers.
Sinon, juste pour une question de pratique, est-ce que tu pourrais rajouter le support des nombres binaires comme dans TIGCC (en plus bcp de prog utilisent ça, donc ça serait vraiment pratique pour la compatibilité) ?

squale92 a écrit :
l'IDE est en delphi... le compilateur, c'"est GCC...qui doit etre codé en C, je pense, comme la majorité des logiciels unix...

Oui mais tu parlais de TIGCC
Si je ne me trompe pas, TIGCC et TIGCC IDE ont été fait en Delphi. Pas GCC évidement, mais ce n'est pas du tout la même chose.

306> qd tu veux compiler en ligne de commande, tu appelle "tigcc"
(que ce soit sous linux ou windows)
donc, je parlais de TIGCC
TIGCC, c le compilo.... TIGCC-IDE, c l'IDE...

tigcc ne fait "qu" appeller GCC...

Non GCC et TIGCC sont codé en C/ASM sauf apparament une partie spéciale de TIGCC, mais je vais regarder plus précisément avant d'avancer n'importe quoi. Quant a l'IDE elle est codée en Delphi.

Uther Lightbringer
a écrit : Non GCC et TIGCC sont codé en C/ASM sauf apparament une partie spéciale de TIGCC, mais je vais regarder plus précisément avant d'avancer n'importe quoi. Quant a l'IDE elle est codée en Delphi.

GCC ok, mais TIGCC t'es sur de toi ? Il me semble avoir lu qu'il avait été codé en Delphi également. Par contre pour l'IDE oui y'a pas de doute

Vertyos> ma fois, qd je veux compiler, j'appelle TIGCC. donc, j'appelle l'outils de compilation "tigcc"
qd je veux l'IDE, je lance "ide" (enfin, il me semble)

je confirme TIGCC est en C sauf l'extracteur d'information de débuggage en delphi.

Le truc qui renvoie les erreurs et warnings à l'IDE ?

ca ca fait partie de l'IDE donc c'est du delphi c'est sur.
Je parle d'un module qui importe des informations dans le fichier .s

c le premier tigcc.exe (celui de xavier) qui etait ecrit en delphi.

ah ok... autant pour moi
jackiechan > le "truc" qui renvoie les erreurs et les warnings est propre à l'IDE en effet (bien foutu d'ailleurs...)

> le "truc" qui renvoie les erreurs et les warnings est propre à l'IDE en effet (bien foutu d'ailleurs...)
tout dépends ce qu'on entend par bien foutu: ca ralentit pas mal la compilation quand même

Ah bah oui mais y'a pas trop le choix... De toute façon l'IDE est ultra lente, si tu veux compiler vite tu t'en passe, c'est la meilleure solution.

IDE ultra lente... bah, je continue de dire que ca depend de l'OS
sous XP, entre les batch et l'ide, la différence est pas bien grande...
(sous 98, par contre, c autre chose)

enfin, du temps ou j'ai testé

les controles delphis doivent être mieux gérés sous XP, ceci dit la lenteur n'est pas une fatalité : avec Emacs, Context ou UltraEdit, le temps de compilation est quasiment le même qu'a la ligne de commande.

> Assembler Instructions with C Expression Operands
Ca devrait arriver. Mais il faut que je trouve une syntaxe logique (enfin bon les ':' de TI-GCC ne sont pas très logiques non plus )

> Variables in Specified Registers
Euh j'en vois pas trop l'utilité? A part pour émuler de manière très inefficace "Assembler Instructions with C Expression Operands" puisque les registres seront monopolisés dans toute la fonction

> est-ce que tu pourrais rajouter le support des nombres binaires comme dans TIGCC
C'est fait

Pollux a écrit :
> Assembler Instructions with C Expression Operands
Ca devrait arriver. Mais il faut que je trouve une syntaxe logique (enfin bon les ':' de TI-GCC ne sont pas très logiques non plus )

Oui, elle est compliquée je trouve

> Variables in Specified Registers
Euh j'en vois pas trop l'utilité? A part pour émuler de manière très inefficace "Assembler Instructions with C Expression Operands" puisque les registres seront monopolisés dans toute la fonction

Ben les deux premiers points (glabal variables et local variables in specified registers) ça n'est pas très important, mais pour les fonctions, c'est indispensable de savoir où on met nos paramètres, si on utilise des fonction ASM en plus.

Ah tu veux dire en paramètres, pas en variables locales...
Euh ben pour déclarer une fonction comme ça en C c facile, le plus chiant serait de gérer l'appel à une fonction de ce style... A part la manière bourrin "stkparm puis push des registres détruits puis lecture des params pour les mettre dans les registres puis appel de la fonction puis restauration puis pop", mais on peut pas dire que ça soit très efficace au niveau code généré

Donc c pour ça que c préférable d'utiliser __attribute__((regparm)) pour l'interfaçage avec l'ASM... (code généré de manière optimale)

Bah il fonctionne comment l'attribut regparm ?
On met nos paramètres, et automatiquement, GTC choisit un registre pour le mettre ?
Mais si on fait des fonctions en ASM, c'est important de préciser quels paramètres vont dans quels registres.

il me semble que les prototypes du style:
fonction(short x asm("d0"), short y asm("d1")) sont suportés non? Car ca c'est vraiment indispensable

Pollux a écrit :
> Le problème est que tu ne peux pas le prouver, et que Pollux nous empêche de prouver le contraire en refusant de sortir les sources. Il est donc inutile de continuer à discuter sur ce point.
Si, qqun peux toujours le faire sur CC s'il en est capable

Sauf que tellement de choses manquent à CC que ça n'en vaut pas le coup.

> Mais ceux qui les utilisent causent des problèmes pour ceux qui veulent recompiler leurs sources. Mais évidemment, cette considération-là ne rend pas du tout dans la tête de Pollux avec son esprit closed-source.
[...] 2) Je ne vois absolument pas le rapport avec le closed-source

Le rapport, c'est que si on est dans l'esprit closed-source, on ne pense pas du tout à ce que des personnes puissent avoir envie de recompiler du code écrit par d'autres (et pas forcément avec le même compilateur).

> Quelqu'un d'autre que Pollux (je n'ai jamais dit que ce serait moi!!!) pourrait trouver une manière d'implémenter la même chose en 10 lignes plutôt que 100!
Oui. Mais pour l'instant personne n'a trouvé le moyen de faire passer GTC de 100 à 10 ko, donc je ne te permets pas de me critiquer sur le fait que je pourrais faire mieux. Je fais ce que je peux, c'est tout.
Et si tu me dis que c parce que GTC n'est pas open-source, j'attends encore celui qui fera passer CC à 6 ko

Ce n'est pas parce qu'on peut coder une fonctionnalité en 10 fois moins de code qu'on peut coder tout en 10 fois moins de code!

> Le chargement/déchargement de code au besoin, ça existe. ... et après c le bordel ... (incompatibilités entre les différentes versions de GTC)

Vérification du numéro de la version au chargement. Le système de DLLs de TIGCC permet des "major version numbers", où la DLL ne se charge pas si la version majeure ne correspond pas, peu importe dans quel sens elle diffère.

> Pour TIGCC 0.94 SP4, je viens de compter, et ce sont 11.656.119 octets (somme de tigccsrc.zip + sources de GCC 3.2.1 et Binutils 2.13.1), donc moins de 12 MO. Plus je présume un compilo genre mingw... Si tu mets tes 12 Mo sur un ordinateur avec Windows tout juste installé, tu ne pourras pas recompiler TIGCC

Ben évidemment...
Mais pour recompiler n'importe quel logiciel, il te faudra forcément un compilateur (ou du moins un assembleur)!

> Tu as l'air d'aimer beaucoup les macros récursives. Moi, je n'aime pas du tout! Tu as l'air de ne pas beaucoup aimer faire des routines optimisées en assembleur. Je m'en sers tout le temps dans Formula 0, dans mon début de routine de triangle...

Pour moi, ce n'est pas "optimiser" que de recopier un code 100 fois avec une macro. Ça prendra 100 fois plus de place!

> Là, c'est une déclaration, pas des instructions, et c'est pour montrer qu'il n'y a pas de nom de variable dans la déclaration. Ça n'a aucun rapport avec asm.
> Et d'ailleurs, la syntaxe asm(""); résout cette ambiguïté. Oui, mais asm("") est bien adapté parce que l'argument est une chaîne. Dans GTC, l'argument est du code

Il n'y a aucune bonne raison pour que ce soit le cas. Tu fais exprès de traîter ça différemment que GCC sans aucune raison valable!

(c'est d'ailleurs la même chose que dans Visual C++) (et oui je sais tu préfères GCC)

Oui, en plus, tu t'alignes sur M$!

> Au contraire, j'aime bien cette extension! (D'ailleurs, si GTC ne la comprend pas, il est totalement inutilisable pour moi.)
Je sais que tu l'aimes bien (moi aussi d'ailleurs). Je dis juste qu'au moment où les développeurs de GCC l'ont introduite, tu n'aurais pas aimé la syntaxe des parenthèses autour des {...}

Ben, il faut bien trouver une syntaxe, et je trouve ça plutôt logique de mettre des parenthèses autour pour en faire une expression.

> Ce n'est pas drôle. Je cite: ... Ce n'est pas parce que tu cites que tu as raison.

Ce que j'avais dit, c'est: "... si tu acceptes de l'utiliser, malgré le fait qu'elle n'est pas libre. Ce n'est pas le cas de tout le monde (cf. Richard Stallman et la philosophie GNU).". Donc un seul contre-exemple (Richard Stallman en l'occurrence) suffit. Et je n'avais dit que je faisais partie de ceux qui refusent d'utiliser n'importe quel logiciel non-libre. Le fait que genlib nécessite un kernel me dérange bien plus que le fait qu'il ne soit pas libre.

jackiechan a écrit :
Sinon, moi je suis un peu perdu avec tous les standarts.
Kevin> C'est quoi le standart par défaut utilisé par TIGCC ? Parce que j'ai du mal comprendre, mais j'ai l'impression que c'est des bouts de standarts pris d'un peu partout ? D'après la doc, j'ai cru comprendre que le standart par défaut est du C89, avec des extensions GNU (donc non standart) et quelques extensions prises du C99.

Le standard par défaut est de l'ISO C90 (ANSI C89) avec des extensions GNU. Mais il se trouve que les extensions GNU se recoupent en partie avec l'ISO C99. Tu peux avoir de l'ISO C99 avec extensions GNU en utilisant le switch -std=gnu99. Pour les modes sans extensions GNU, n'essaye même pas, ils ne fonctionnent pas sous TIGCC (parce qu'il y a des extensions GNU dans tous les sens dans nos headers).

Thibaut a écrit :
> Il faut faire des choix entre les possibilités qu'on permet et ce qu'on retire parceque c'est moins indispensable.
>> Peut-être, peut-être pas, mais tu ne peux pas l'affirmer si tu ne peux pas le démontrer.
Kevin, j'espère que tu as conscience de répondre un truc vraiment idiot !!! Sinon il faut rapidement que tu fasses une thérapie.

Je pense qu'il faut rapidement que tu prennes un cours de Mathématiques.
Tu ne fais qu'affirmer, affirmer et réaffirmer sans aucun essai d'argumentation et encore moins de démonstration.

> Tu penses bien que ces extensions ne peuvent pas tenir sur quelques octets !
>> Le problème est que tu ne peux pas le prouver

C'est évident pour tout programmeur un tant soit peu intelligent. Arrête de préférer passer pour un con à admettre de te tromper

Arrête d'affirmer sans aucune argumentation et de croire que tout le monde qui ne croit pas à tes affirmations infondées se "trompe".

> Il est évident que GTC ne peut pas prendre en compte TOUTES les fonctionnalités de TIGCC
>> Ce n'est pas du tout "évident". Rien n'est "évident". Soit tu peux le prouver (et je t'y défie), soit tu te tais!

[insultes supprimées] Tu as vu la taille de TIGCC ? Tu crois qu'il est possible de la réduire à 100 ko en gardant toutes les fonctionnalités ???????

Je ne dis pas que c'est forcément possible, mais qu'il n'est pas du tout évident que ce soit impossible. Tout le monde ici disait qu'il était "évident" qu'un émulateur de Game Boy pour TI-89/92+/V200 était impossible, et pourtant... Mais ça n'a pas fait réfléchir certains apparemment

> Mais ceux qui les utilisent causent des problèmes pour ceux qui veulent recompiler leurs sources.
Pollux est malin puisqu'il a trouvé une solution qui annulera ton argument : dire dans la documentation de l'extension qu'elle ne fonctionnera pas sur tout autre compilateur. A moins de prendre les autres pour des incapables (ce que tu sembles faire), on est sûr qu'il n'y aura pas de problème.

Ce n'est pas du tout une solution. Il faut mettre au minimum un switch pour détecter et rejeter les utilisations de ces extensions, et il serait une bonne idée de le mettre par défaut. Sinon, des programmeurs utiliseront ces extensions sans faire exprès.

Et puis même avec ça, des programmeurs égo­ïstes qui s'en fichent de la compatibilité de leurs programmes avec TIGCC pourraient quand-même utiliser ces extensions, donc la seule solution vraiment efficace est de ne pas les accepter du tout.

> Et rien ne l'oblige de "gagner autant de place que possible"!
Si ! tu sais parfaitement quoi. Mais tu préfères faire semblant de ne pas comprendre parceque tu aurais trop de mal à avouer que tu t'es trompé.

Ben, que le compilateur fasse 100 KO ou 200 KO, peu importe. Il y a au minimum 576 KO de mémoire archive sous toutes les versions raisonnablement récentes de AMS.

Et puis tu sais bien que tu es réputé pour être quelqu'un de très mauvaise foi. Tout le monde le dis.

Non, il n'y a que toi à le répéter à longueur de journée. Demande à XDanger s'il trouve que je suis de mauvaise foi. Je pense qu'il indiquera quelqu'un d'autre (devine qui ) si on lui demande d'indiquer qui est de mauvaise foi ici.

> Quelqu'un d'autre que Pollux (je n'ai jamais dit que ce serait moi!!!) pourrait trouver une manière d'implémenter la même chose en 10 lignes plutôt que 100! Arrête de prendre Pollux pour un dieu!

Quel débutant ce Kevin

Tu préfères donc me traîter de débutant plutôt que d'avouer d'avoir tord. Quelle mauvaise foi! Peut-être que son pseudonyme mythologique t'en donne l'impression (et même, Pollux n'était-il pas le mortel parmi les 2 jumeaux? Mais c'est hors-sujet de toute façon), mais Paul Froissart n'est pas un dieu.

> Le chargement/déchargement de code au besoin, ça existe.
Et bonjour la lenteur...

Ben, tant pis. Tu ne t'attends quand-même pas à pouvoir compiler un gros projet en 1 seconde sur un processeur à 10 ou 12 MHz. Si c'est le cas, ben évidemment que le compilateur sera pourri, il n'a pas le temps de travailler. Un temps de compilation d'une minute est beaucoup plus réaliste!

Thibaut
a écrit : PS : ta citation a finit par me faire mourrir de rire. Une fois de plus, t'es prêt à faire les pires conneries pour paraître crédible.

Tu peux trouver que Richard Stallman est "con", mais moi, je n'ai fait que le citer, donc je n'y suis pour rien.

XDanger a écrit :
> g cru entendre parler d'une modification au niveau des tables de relogement Une possibilité d'optimisation, pas une modification. TIGCC respectera toujours le standard natif d'AMS, le seul que comprenne EX_Patch !

Par défaut, oui. Avec le nouveau switch de ld-tigcc, non. Mais on ne verra pas la différence, à moins de regarder à l'éditeur hexadécimal.

Uther Lightbringer
a écrit : Le C le plus standard actuellement est le C89 ou C ANSI.

Non. Il a été invalidé par ISO en 1999. Le C99 le remplace en tant que standard ISO.

je pense qu'il doit implémenter une table de relogement style kernel

Et voilà, tu as deviné.

De plus il n'a pas nié le fait que ca serait incompatible avec le format nostub standard.

Je le nie maintenant. C'est le code de démarrage qui s'occupera du relogement si (et seulement si) le switch en question est utilisé, donc on ne verra pas la différence en tant qu'utilisateur.

Et Pollux qui refuse de reconnaitre que TIGCC est libre parcequ'il y a trop de logiciels a télécharger.

Pollux
a écrit : Double-Word Integers ** non

Pas de long long??? C'est totalement inutilisable ce truc alors!
Et je te signale que long long est prévu par le standard ISO C99!

Complex Numbers non

Ça aussi, c'est prévu par le standard ISO C99!

Arrays of Variable Length * non

Ça aussi!

Et les autres extensions qui manquent, elles sont aussi très utiles. Par exemple:

Variables in Specified Registers non

Quant à ce que tu appelles "compatibilité antérieure", tu y as jeté un peu tout et n'importe quoi:

Naming an Expression's Type deprecated?

Oui, ça ne fonctionne plus depuis GCC 3.0 déjà (plantage du compilateur) et donne maintenant une erreur. Pas la peine d'implémenter ça (au contraire!).

Hex Floats non

C'est prévu par le standard ISO C99, ça! Ce n'est pas du tout de la compatibilité antérieure, c'est une nouveauté!!!

Function Names as Strings non

Euh, GTC comprend-il au moins __func__ comme prévu par le standard ISO C99?

Specifying Attributes of Variables N/A Specifying Attributes of Types N/A

Comment ça, "N/A"?

> Et Pollux qui refuse de reconnaitre que TIGCC est libre parcequ'il y a trop de logiciels a télécharger.
lol mais c clair que c impossible à recompiler. Je suis sûr que personne sur le forum (sauf Kevin ) n'a essayé de le recompiler...

Faux, il y a Littleboy qui a recompilé quelques prereleases de GCC 3.3 en -O3 et avec optimisation pour familles de processeurs spécifiques.

squale92
a écrit : un gars l'avait recompilé, TIGCC, et filait une version compilée en O3 plutot que Os, il me semble

En effet, c'était Littleboy. http://sourceforge.net/project/showfiles.php?group_id=18261. Mais comme vous voyez, il n'y a pas la version la plus récente.

Uther Lightbringer
a écrit : je confirme TIGCC est en C sauf l'extracteur d'information de débuggage en delphi.

C'est vrai pour la version Linux/Unix seulement, ça. Pour la version Windows, tigcc.exe est entièrement en Delphi, et l'extracteur d'informations de déboguage y est intégré, comme l'est la version Delphi du système de patches de fichiers assembleur (là aussi, il y a une version C pour la version Linux/Unix).

godzil
a écrit : c le premier tigcc.exe (celui de xavier) qui etait ecrit en delphi.

Alors là pas du tout. Il était écrit en C++ si je me rappelle bien, ou alors en C, mais pas en Delphi.

Je pense qu'il faut rapidement que tu prennes un cours de Mathématiques. Tu ne fais qu'affirmer, affirmer et réaffirmer sans aucun essai d'argumentation et encore moins de démonstration.

l'argument facile: mathématiquement Mathématiquement la probabilité d'y arriver et très proche de 0 ca te va?

Je ne dis pas que c'est forcément possible, mais qu'il n'est pas du tout évident que ce soit impossible. Tout le monde ici disait qu'il était "évident" qu'un émulateur de Game Boy pour TI-89/92+/V200 était impossible, et pourtant... Mais ça n'a pas fait réfléchir certains apparemment

on avait eu une discution sur la faisabilité de la chose il y a longtemps était a peu près d'accord sur le fait qu'une recompilation était envisageable et c'est ce que fait boogerman car l'emulateur EST trop lent

Ce n'est pas du tout une solution. Il faut mettre au minimum un switch pour détecter et rejeter les utilisations de ces extensions, et il serait une bonne idée de le mettre par défaut. Sinon, des programmeurs utiliseront ces extensions sans faire exprès. Et puis même avec ça, des programmeurs égo­ïstes qui s'en fichent de la compatibilité de leurs programmes avec TIGCC pourraient quand-même utiliser ces extensions, donc la seule solution vraiment efficace est de ne pas les accepter du tout.

Bof, de toute facon ca prendra 5 minute a un programmeur d'adapter ca.

Ben, que le compilateur fasse 100 KO ou 200 KO, peu importe. Il y a au minimum 576 KO de mémoire archive sous toutes les versions raisonnablement récentes de AMS.

arète ta mauvaise foi la. Tu sais très bien que compiler nécéssite de la RAM, un code source et de la place pour l'exectutable, si on a en plus on a d'autre prog sur ca calc, ca commence a faire limité.

Non. Il a été invalidé par ISO en 1999. Le C99 le remplace en tant que standard ISO.

Certe mais aucun compilateur ne le gère actuellement a 100% donc pour moi le seul C standard commun a la pluspart de compilo actuels, c'est le ANSI C89