CC Compilateur C on-calc - Page 9

"détester" : faut pas exagérer non plus

Une fonction peut-elle retourner une structure de plus de 4 octets ?? si oui, comment ?

Kevin Kofler a écrit :
C'est normal, une structure n'est pas un pointeur!
Un long sera aussi retourné en D0.

Oui je sais bien, c'est pas ça que je voulais dire
Pour retourner une structure, CC alloue de la mémoire dans la stack frame de l'appellant, et push un parametre en plus pour indiquer à la fonction où elle doit mettre la structure qu'elle veut retourner.

Il marche sans problème chez moi ...

Tu es bien sûr que tu fais :
ansi2knr("source_ansi","source_k&r") ?

Oui, mais en fait, je viens de réuploader AS sur ma TI et ça marche. J'avais p-e une vieille version de AS...

jackiechan91 a écrit :
Ben ouais, et ça ne marche pas (enfin, je l'ai p-e mal utilisé...). Même quand j'utilise ISOCC... Pourtant j'ai compilé ton exemple (hellow).

As-tu déjà un fichier nommé csrc? Si oui, efface-le ou renomme-le.

jackiechan91
a écrit : Oui, mais en fait, je viens de réuploader AS sur ma TI et ça marche. J'avais p-e une vieille version de AS...

Bon, je vois que le problème est règlé.

bah à la limite j'ai pratiquement arrêté la prog en BASIC sur TI, donc les langues maintenant.
Juste une question (conne) : n'y aurait t'il pas un prog ASM qui pourrait mettre la langue anglaise par défaut. Car ça serait fort pratique pour les prog BASIC ! on lance ce prog ASM au début de l'execution du programme BASIC (qu'on a auparavant tokénisé en anglais avant de le distribuer), et il met en anglais la calc, comme ça plus de problème !!!
enfin, je sens qu'on va me dire : "tu peux toujours rêver !" .

Il est possible de faire une chaîne Exec pour ça (j'en ai une qui traîne sur mon disque dur), mais il est beaucoup mieux de convertir le programme proprement plutôt que de changer la langue en cours d'exécution, ce qui pourrait entraîner des problèmes bizarres. (Il doit y avoir une raison pour laquelle TI n'a pas mis la langue dans les options setMode.)

C peut-être simplement par-ce que l'on ne peut pas savoir quelles sont les langues présente sur la TI

En assembleur ou en C on doit pouvoir le savoir, en utilisant les fonctions concernant les applications Flash .

ben, de toute façon, l'anglais est toujours présent...

J'ai fait un convertisseur de fichier PIC en fichier TEXT contenant le code du sprite :


Ça peut être utile avec CC, si vous voulez utiliser des sprites (ça ne marche qu'avec des sprites de largeur inférieure à 32 pixels) : il suffit de faire #include "image" au début de votre code source pour pouvoir l'appeler plus tard dans le prog.
Pour pouvoir les afficher, j'ai recopié les fonctions de sprites d'EXTGRAPH, je vous conseille d'en faire autant.

Pour le télécharger, c'est ici : http://membres.lycos.fr/jackiechan/converter.zip

ça peut être utile si on se fait chier en cours et qu'on veut se faire un petit jeu.

ça me fait penser que g deux heures de maths là
dommage, DS demain => v passer les deux h à booser

j'ai essayé 10min de lancer lowkblib__0002(); sous CC,ensuite j'ai lu le readme de AS...
plize,dépèche toi pour les libs dynamiques nitro!!!!!!!
sinon, ton compilo est
ttrrrooopppp bien et
ttrrrooopppp pratique!!!!

j'adore!!!!!
je peux vous dire que mon editeur va avancer plus vite avec ça!
par contre, il a pas l'air très optimisé en taille, si?

libs dynamique, ça veut dire mode kernel...
et qui dit mode Kernel dans CC dit mode Kernel dans AS... ce qui n'est pas encore fait

D'ou Gtc

tu as donné la même réponse partout
Gtc, on ne l'a pas...

janjan2 a écrit :
j'ai essayé 10min de lancer lowkblib__0002(); sous CC,ensuite j'ai lu le readme de AS... plize,dépèche toi pour les libs dynamiques nitro!!!!!!!

Dépèche-toi plutôt pour les librairies statiques, c'est plus important!

plus important...
pas à mes yeux

(enfin, pas au niveau de la programmation on-calc !)

Avec CC, quand on fait #include "fichier_h" au début d'une source, 'fichier_h' est entièrement copié dans la source ?

jackiechan91
a écrit : Avec CC, quand on fait #include "fichier_h" au début d'une source, 'fichier_h' est entièrement copié dans la source ?

Pour l'instant non (j'ai integré le préprocesseur au parseur du compilateur), mais ça va changer tres bientôt.
En effet, j'ai implémenté les macros dans le préprocesseur, et je me suis alors aperçu que faire cohabiter les tables de symboles du préprocesseur avec celles du compilateur en une seule passe, on peut pas se le permettre avec la RAM qu'on a

Le préprocesseur supportera-t-il aussi les #ifdef? Ça serait bien de pouvoir faire une source compilable à la fois avec TIGCC et avec CC avec des #ifdef __TIGCC_ENV__.

Kevin Kofler a écrit :
Le préprocesseur supportera-t-il aussi les #ifdef? Ça serait bien de pouvoir faire une source compilable à la fois avec TIGCC et avec CC avec des #ifdef __TIGCC_ENV__.

Oui bien sûr, un autre avantage de le mettre en externe c'est que je ne suis plus limité par la taille du programme... je peux donc rajouter tout ce qui faut

cool

j'ai un bug:
parfois CC compile (souvent au dessus de 4boucles imbriquees) et rajoute des
move XX,d3
move XX,d7
jsr __lmul
(chuis plus tres sur j'ai pas la ti sous la main)
donc AS met des undefined symbol __lmul

et aussi, hier j'ai pris un =====Err_Throw=====
juste en ne restaurant pas les registres la pile (ac AS)!!!!

Nitro a écrit :
Pour l'instant non (j'ai integré le préprocesseur au parseur du compilateur), mais ça va changer tres bientôt.
En effet, j'ai implémenté les macros dans le préprocesseur, et je me suis alors aperçu que faire cohabiter les tables de symboles du préprocesseur avec celles du compilateur en une seule passe, on peut pas se le permettre avec la RAM qu'on a

Ben alors on peut se servir des fichiers inclus avec la directive #include "fichier" comme lib statique, si ça ne recopie que les fonctions utilisées et pas le fichier entier, non ?
Ou alors je n'ai pas bien compris le principe des lib statiques.

janjan2 a écrit :
j'ai un bug:
parfois CC compile (souvent au dessus de 4boucles imbriquees) et rajoute des
move XX,d3
move XX,d7
jsr __lmul
(chuis plus tres sur j'ai pas la ti sous la main) donc AS met des undefined symbol __lmul

Normal, les multiplications de longs ne sont pas encore implémentées dans CC.

et aussi, hier j'ai pris un =====Err_Throw===== juste en ne restaurant pas les registres la pile (ac AS)!!!!

Normal aussi. Si tu ne restaures pas la pile, ça plante! Et si tu ne restaures pas les autres registres, ça risque aussi très fort de planter.

Kevin Kofler a écrit :
Normal, les multiplications de longs ne sont pas encore implémentées dans CC.

pffff!!!!!

Normal aussi. Si tu ne restaures pas la pile, ça plante! Et si tu ne restaures pas les autres registres, ça risque aussi très fort de planter.

oué mais j'avais jamais prs de err_throw!

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