CC Compilateur C on-calc - Page 10

Thibaut a écrit :
Nitro : si tu envisages de traiter les sources en deux passes, on ne pourra pas compiler des sources dont la taille de l'ensemble des fichiers est supérieure à 64 ko

Remarque je m'en fout ça fera un avantage supplémentaire pour Azur

Je pense que tu n'as pas compris le problème... il n'y a tout simplement pas assez de RAM pour faire cohabiter CC + fichier generé + table de symbole avec les macros du préprocesseur. Alors certes ça réduit la taille maximum des fichiers sources, mais au moins ça compile. Et ce que je dis est basé sur des tests en condition réélle.

Donc j'avais parfaitement compris.

Tout dépend de la façon dont tu traites les macros. Moi je le fais d'une manière très spéciale (et qui a été chiante à mettre au point, certains diraient qu'elle est "sale") qui me permet de placer tous les identificateurs dans la même table, tous demandant la même quantité de RAM que ce soit une variable ou une macro, et quelle que soit la marco
Je ne sais pas comment tu as fais toi

En considerant que chaque rom call est une macro, ça fait trop.
Et entre un compilateur qui ne fait que du preprocessing et un compilateur qui compile moi choix est vite fait

Non ça ne fait pas trop ! absolument pas, si le programmeur prend soin de n'inclure que les headers dont il a besoin.
En tout cas mon compilo ne bronche pas même si j'inclus toute la bibliothèque, alors


Azur ne fait pas que de la précompilation. La bêta pourtant très ancienne que tu as peut déjà compiler un peu.

Bon aujourd'hui je commence à travailler en entreprise, et vu les horaires que j'ai, je ne vais plus pouvoir venir sur yaronet, et encore moins continuer CC et AS (durant le peu de temps libre qu'il me reste, je vais devoir finir les contrats que j'ai actuellement).
Je verrai à la rentrée prochaine (dans 2 mois) ce qu'il adviendra de ces programmes.

C'etait mon dernier messages avant un bout de temps.

Je viens de corriger un bogue dans ANSI2KNR. Cf. http://forumti.timouss.firstream.net/viewtopic.php?t=29.

... quand on pense que GTC va bientôt sortir ...

Pollux
a écrit : ... quand on pense que GTC va bientôt sortir ...

J'espère que c'est vrai et qu'il sera mieux que CC...
Est-ce qu'il gère le type float (et double) ?

1 : Oui
2 : Oui

Thibaut> comment sais-tu qu'il gère le type float?

jackiechan91> il gère le format Fast Floating Point (4 octets, 24 bits de mantisse, 7 bits d'exposant, 1 bit de signe), avec tout plein de routines optimisées à mort de quoi enterrer (pour les jeux en tout cas) le TI_FLOAT

Pollux a écrit :
jackiechan91> il gère le format Fast Floating Point (4 octets, 24 bits de mantisse, 7 bits d'exposant, 1 bit de signe), avec tout plein de routines optimisées à mort de quoi enterrer (pour les jeux en tout cas) le TI_FLOAT

Argh... Y en a marre des gens qui passent leur temps à réécrire des fonctions qui sont déjà dans la ROM!!!

huhu, si on devait utiliser que les ROM_CALL et qq fonctions de sprites de TIGCC_lib, bonjour les jeux qu'on aurait ! des petits jeu ok, mais finit les SMA, SMQ , Krypton et companie ...

Si vous utilisez les nombres à virgule flottante dans des jeux censés être rapides, il y a déjà un problème quelque part.

C'est vrai, je suis d'accord avec Kevin.

Pollux : si tu as gardé notre conversation de l'autre jour, relis ce que tu m'as dit

Kevin> je penses pas que Pim parlait des fonctions de calcul, mais des fonctions de dessin, par exemple...
tu imagine un jeu que avec des BitMapPut ?

Pourquoi pas?
On peut même faire un Super Mario en BASIC. (J'en ai écrit un, mais il n'y a qu'un niveau de 4 écrans, et tout le niveau est "hard-coded", donc il est pratiquement impossible d'en rajouter d'autres. Il faudrait les coder entièrement.)

moué... j'avais commencé un jeu de ce style en BASIC...
mais ct pas vraiment le peids par rapport à ce que je suis capable de faire maintena t en C

Ca peut servir, entre autres, à faire des solveurs numériques très très rapides (eh oui y a pas que les jeux), et puis la virgule fixe c pas toujours très pratique, même dans les jeux (j'en ai déjà fait l'expérience dans Formula 0 ), donc c assez utile pour les routines pas trop critiques en temps (mais quand même un peu donc pas de TI-Float )

Et puis sinon, pour ce qui est de la compatibilité ANSI, GTC compile parfaitement Nibbles Pro (taille compilé avec TI-GCC : 7700 octets, 8300 avec GTC), avec les headers originaux de TI-GCC (en changeant seulement les asm(...) et en supprimant le prototype d'alloca)

Kevin Kofler a écrit :
Pourquoi pas? On peut même faire un Super Mario en BASIC. (J'en ai écrit un, mais il n'y a qu'un niveau de 4 écrans, et tout le niveau est "hard-coded", donc il est pratiquement impossible d'en rajouter d'autres. Il faudrait les coder entièrement.)

un petit screenshot stp !!!

Non ça ne fait pas trop ! absolument pas, si le programmeur prend soin de n'inclure que les headers dont il a besoin

erf "std" vive #header

Tu répond à un vieux post de moi, si j'ai bonne mémoire. Elle fonctionne comment ta directive #header ?

erf tu verras bien... c un genre de #include, mais bien plus puissant tout en étant bcp plus adapté aux TI (si TI-GCC supportait #header, ils ne se seraient même pas donné la peine de porter AR )

quand est-ce qu'ils sortent vos compilateurs on-calc ?
bientôt ou jamais ?

Ah
Je dirais 2006

pour GTC, bientôt

Le moment tant attendu serait-il proche ?