A propos de CC - Page 1

Salut tout le monde!
En fait je me demandais si quelqu'un avait fait une librairie pour CC, car là, j'ai même pas les fonctions fopen et cie (je n'arrive pas à le mettre). J'ai vu un topic qui en parlait mais le lien (datant d'une année bientôt) était mort.
A part ça, je voulais aussi savoir pourquoi si je déclare:
void *malloc();
char *ecran;
main() {
ecran=malloc((unsigned long)3840);
}
Ca me fait un warning à la ligne ecran=malloc... Comme quoi que le pointeur est de type incompatible. J'ai le même problème dans mes routines de sprite, cependant celles de extgraph ne font pas le moindre warning. Sinon le programme final fonctionne.

il faut caster le malloc je pense

ecran=(char*)malloc blablabla

Si seulement c'était si simple... Malheureusement ça marche pas. Merci quand-même
Si je déclare
char *malloc();
là par contre j'ai plus de warning. Mais je pense que j'en aurai certainement un (voir un plantage à l'exécution) si j'alloue pour un tableau de short...

Warning bidon pour un void *, d'ailleurs, mais CC n'est pas excellent en termes de diagnostiques.

pourquoi tu déclares char* malloc aussi ?

Si on ne le déclare pas, il croira que la valeur retournée est int, donc quelque chose de 2 octets et pas 4 comme il faut.

Je n'arrive pas à recompiler les sources de CC (il me fait une erreur sur chaque fichier car un switch est inconnu)
-fno-if-conversion
J'ai la version 0.94 de TIGCC...

pourquoi tu déclares char* malloc aussi ?

Pour ne pas avoir de warning... Et c'est soit l'un soit l'autre.

Si on ne le déclare pas, il croira que la valeur retournée est int, donc quelque chose de 2 octets et pas 4 comme il faut.

Oui. J'ai bien cherché pour faire fonctionner OSRegisterTimer (faut caster la valeur à unsigned long).

g jamais déclarer la fonction malloc en C.
suffit d'inclure le bon header.
et g jamais eu de warning

Hum...
Ici on parle de CC pas de TIGCC... CC est un petit compilateur On-calc qui plante pour un rien. Mais bon c'est mieux que rien quand on s'embête pendant les cours

Brunni :
Je n'arrive pas à recompiler les sources de CC (il me fait une erreur sur chaque fichier car un switch est inconnu)
-fno-if-conversion J'ai la version 0.94 de TIGCC...

http://tigcc.ticalc.org/gcc33/
Tu ne peux pas compiler avec l'ancien GCC, il donne du code trop gros qui dépasse la limite de taille (du moins en combinaison avec l'ancien linker, le nouveau permettra de gagner énormément de place ).

Merci.
Sinon personne n'aurait une lib pour CC alors?

Si, il y a déjà pas mal de choses faites à ce sujet. Essaie de chercher dans ce forum

Kevin Kofler :
Tu ne peux pas compiler avec l'ancien GCC, il donne du code trop gros qui dépasse la limite de taille (du moins en combinaison avec l'ancien linker, le nouveau permettra de gagner énormément de place ).

T'as pas l'impression d'avoir oublié un détail ?
"il donne du code trop gros" en _nostub uniquement !
Brunni, si tu compiles en mode kernel, ça marche.

Mettre à jour GCC est plus simple que changer le code ou le fichier projet pour compiler en kernel. Et ça lui servira aussi pour plein d'autres choses (ses projets à lui par exemple).

Je précise aussi que le problème en _nostub est le non-support des BSS. Ce problème est résolu avec le nouveau linker.

sera résolu

Est résolu parce que le nouveau linker existe déjà.
Ou carrément a été résolu, parce que ça fait longtemps qu'on a ajouté le support des BSS.

sera, pour l'instant le nouveau linker ne lui est pas d'une grande utilité

Plus que quelques jours... On est en train de finir la mise à jour de la documentation en ce moment. Tous les exécutables sont prêts pour la bêta 1.

sera ! Pour le moment c'est un vaporware

le problème en _nostub est le non-support des BSS

Il faut que tu m'expliques un truc, mon cher :
- Tu critiquais la section BSS (fonctionnalité du mode kernel) quand on faisait un débat nostub/kernel... Tu disais que c'était sale, que HeapAlloc était préférable !
- Tu soutiens que la meilleure des optimisations est l'optimisation en taille... GTC optimise mieux en taille que TIGCC... et tu traîtes GTC de merde catégoriquement !
- Tu as critiqué une personne qui cache les points positifs de GCC et qui traite d'obsolète une technique pleine d'avantages... tu critiques ton propre comportement !
- Tu soutiens que X/GX/Gen sont inutiles parcequ'elles sont plus grosses et que la vitesse d'ExtGraph (12 FPS) suffit... Une version plus rapide et plus grosse d'ExtGraph va sortir... tu as encouragé le développement de cette version !

Je ne te comprends pas Kevin...

Thibaut :
sera ! Pour le moment c'est un vaporware

Le nouveau linker existe bel et bien, que tu le veuilles ou pas! Tu crois que je l'ai linké avec quoi, UnInEvHk 3.00? Et Backgammon pour Fargo?

le problème en _nostub est le non-support des BSS

Il faut que tu m'expliques un truc, mon cher :
- Tu critiquais la section BSS (fonctionnalité du mode kernel) quand on faisait un débat nostub/kernel... Tu disais que c'était sale, que HeapAlloc était préférable !

L'explication, c'est que ta citation est hors-contexte.
Avec contexte: "le problème de la compilation de CC en _nostub est le non-support des BSS". Le problème pourrait aussi être règlé dans CC. Mais ce n'est plus la peine maintenant, le nouveau linker résout le problème tout seul.

- Tu soutiens que la meilleure des optimisations est l'optimisation en taille... GTC optimise mieux en taille que TIGCC... et tu traîtes GTC de merde catégoriquement !

Je ne crois pas ce que tu racontes avant d'avoir vu les preuves. Tout ce que j'ai vu jusqu'à présent, c'est que ton propre bench de taille, c'est GCC 3.3 qui a fini par le gagner (et encore, c'était avant mes patches pour améliorer l'optimisation en taille).

- Tu soutiens que X/GX/Gen sont inutiles parcequ'elles sont plus grosses et que la vitesse d'ExtGraph (12 FPS) suffit... Une version plus rapide et plus grosse d'ExtGraph va sortir... tu as encouragé le développement de cette version !

J'ai encouragé la réécriture en assembleur parce qu'elle allait donner des routines plus petites et plus rapides. Maintenant, les développeurs veulent les grossir, donc je leur ai déjà annoncé que je vais forker s'ils mènent ça à terme.

Kevin Kofler :
Le nouveau linker existe bel et bien, que tu le veuilles ou pas! Tu crois que je l'ai linké avec quoi, UnInEvHk 3.00? Et Backgammon pour Fargo?

Pourquoi dis-tu que GTC est un vaporware alors qu'il est dans la même situation que ton linker : quelques personnes seulement l'ont essayé, on en parle depuis longtemps, le programmeur affirme qu'il existe mais presque personne n'a de preuves...

L'explication, c'est que ta citation est hors-contexte.
(...) Mais ce n'est plus la peine maintenant, le nouveau linker résout le problème tout seul.

Mettons-nous d'accord : TIGCC va-t-il permettre les sections BSS ?
Si oui, alors la question tient toujours : pourquoi critiquais-tu le support BSS apporté par le mode kernel...

Je ne crois pas ce que tu racontes avant d'avoir vu les preuves.

Nous aussi, pour ton linker.
De plus, comme tu es dans le doûte (est-ce vrai ? est-ce faux ?) tu n'as pas le droit de porter un jugement aussi catégorique sur GTC !
Et quand tu ne seras plus dans le doûte, je ne pense pas non-plus qu'il sera raisonnable de penser "c'est de la merde catégoriquement" parceque quelques fonctionnalités maquent. "il n'est pas entièrement satisfaisant", ok.

Tout ce que j'ai vu jusqu'à présent, c'est que ton propre bench de taille, c'est GCC 3.3 qui a fini par le gagner (et encore, c'était avant mes patches pour améliorer l'optimisation en taille).

Tu as la mémoire courte !!!! De la même manières que tu ne cites que les inconvénients du kernel/GX/X/GTC et les avantages du nostub/EG/TIGCC aux newbies, tu ne te souviens que de ce que tu veux !
Pollux a posté les benchs de taille de TILTmaze, d'Einstein, de TIChess.

Thibaut
:

Kevin Kofler :
Le nouveau linker existe bel et bien, que tu le veuilles ou pas! Tu crois que je l'ai linké avec quoi, UnInEvHk 3.00? Et Backgammon pour Fargo?

Pourquoi dis-tu que GTC est un vaporware alors qu'il est dans la même situation que ton linker : quelques personnes seulement l'ont essayé, on en parle depuis longtemps, le programmeur affirme qu'il existe mais presque personne n'a de preuves...

Ça fait des années que Pollux le nous promet (avec des dates de sortie totalement fantaisistes). Et on n'en n'a toujours pas vu trace. Moi, je n'ai pas donné de date de sortie du linker qui n'a pas été maintenue.

Mettons-nous d'accord : TIGCC va-t-il permettre les sections BSS ? Si oui, alors la question tient toujours : pourquoi critiquais-tu le support BSS apporté par le mode kernel...

C'est Sebastian qui a implémenté les BSS, pas moi. L'équipe de TIGCC ne consiste pas d'une seule personne. Et ayant vu les bons résultats que l'implémentation de Sebastian donne, je me suis dit que ce n'était pas une si mauvaise chose après tout.

Je ne crois pas ce que tu racontes avant d'avoir vu les preuves.

Nous aussi, pour ton linker.

Patiente quelques jours. Sebastian est en train de compléter la documentation, et il a déjà pratiquement fini.

Pollux a posté les benchs de taille de TILTmaze, d'Einstein, de TIChess.

Tout le monde peut poster des nombres au hasard. Je n'ai même pas vu les fichiers compilés (pour ton bench non plus, d'ailleurs). Et je sais déjà que Pollux est un menteur (cf. dates de sortie même pas approximativement réalistes), donc je n'ai aucune raison de lui croire ces chiffres-là.

ouhhhh mais c encore un joli débat comme on les aime

J'ai quand meme eu le nouveau linkeur entre les mains. Donc il existe Et oui, il est complexe. (Trop, je suis sur qu'on pourrait faire plus simple).

J'ai aussi vu tourner GTC (on PC et une vieille version), donc il existe... mais ça ne fait pas avancer le débat...

Magnifique ce débat KK et Pollux
Mais est-ce possible d'avoir déjà une version en développement de GTC on-calc? J'en aurais bien besoin, même si elle est boguée...
A part ça, j'ai bien trouvé une lib CC mais le lien est (comme par hasard) mort. C'est vraiment dommage que CC ne gère pas les #define parce que c'est un peu pauvre sans ça...

Si tu avais lu le topic tu aurais vu que la réponse à ta question est non. Tu peux peut-être demander une version PC de GTC, mais surement pas la version oncalc.

Hum, j'ai lu le topic (forcément puisque c'est moi qui l'ai créé)...