cc - Page 1

J'ai la version 0.1 de Small Integrated Devellopment Environment.
Ce que je ne comprend pas,c'est pourquoi
(...)
main(){
char screen[3840L];
(...)
}

est accepté alors que

(...)
long LCD_SIZE=3840;
(...)
main{
char screen[LCD_SIZE];
(...)
}

retourne une erreur à cette ligne "char screen[LCD_SIZE]"?

parce que ton long LCD_SIZE est une VARIABLE
et que les tailles de tableau alloués sur la pile doitvent être constantes, du moins sous les anciens standard (et CC est au standard K&R, qui est le tout premier)
(je penses que ça vient de là)

ok!

Tu réserves presque 4Ko sur la pile
Franchement, ce n'est pas conseillé, tu devrais plutot utiliser malloc() pour une taille pareille...

Ben pourquoi ?
On a jusqu'à 16ko...

moué... mais toutes les variables que tu réserve comme ça prennent de la place...
si tu as 1000 variables de 2 octets, plus 500 de 4 octets, ça te fait déjà 4 ko !!!

Ce qui ne représente que le quart de la totalité de la place disponible. (et puis 1500 variables, faut le faire, quand même...)

à cela, tu peux rajouter les params pour les appels de fonctions, plus les variables pr les fonctions...
(multiplié par un bon petit nombre de fois dans le cas de fonctions récursives !)

Les params pour les appels de fonctions sont en général passés dans les registres et puis ça ne prends pas énormément de place non plus.

Par contre, si tu utilises des fonctions récursives, il vaut mieux éviter en effet d'utiliser bcp de variables...
D'ailleurs, y a-t-il des fonctions qui permettent de connaître l'état de la pîle ?

Les params pour les appels de fonctions sont en général passés dans les registres

tu en es sûr ?
c'est implémenté seulement depuis peu dans TIGCC... et uniquement qd on le précise explicitement...
sous TIGCC, par défaut, le passage se fait par la pile, me semble-t-il.

sous CC, je penses que c toujours par la pile, non ?


pour connaitre l'état de la pile, il suffit de regarder la valeur du registre pointeur de pile...
plus la valeur est petite, moins il y a de place dispo sur la pile...
(et si tu dépasse une certain valeur, tu as une Interruption (stack overflow) qui se déclenche)

En effet, pour le passage des param, je viens de vérifier (mais c'est possible que je me trompe, vu que je n'y connais pratiquement rien à l'ASM), et j'ai l'impression que les arguments sont passés sur la pile (enfin, seulement pour les fonctions faites pas l'utilisateur, cela ne concerne pas les appels vers des fonctions de tigcclib.h ou des ROM_CALLS)
Enfin, ça ne représente que très peu d'octets, en général, les params...

squale92 a écrit :
parce que ton long LCD_SIZE est une VARIABLE
et que les tailles de tableau alloués sur la pile doitvent être constantes, du moins sous les anciens standard (et CC est au standard K&R, qui est le tout premier) (je penses que ça vient de là)

Oui, c'est ça. Les tableaux de taille variable n'ont été introduits que dans ISO C99 (mais GCC les a déjà supportés avant).

Link a écrit :

Tu réserves presque 4Ko sur la pile

La macro SAVE_SCREEN de TIGCC fait la même chose.

Franchement, ce n'est pas conseillé, tu devrais plutot utiliser malloc() pour une taille pareille...

Tant qu'on n'essaye pas d'allouer plus de 2 écrans de cette manière, il n'y a pas de problème. Mais à partir de 3, c'est assez mal parti, parce que la pile ne fait que 16 KO, dont une partie utilisée par AMS:

La fonction de compression d'Einstein (un bête Huffman adaptatif pour cette première version) a besoin de ... 0 octet de RAM pour compresser ! J'alloue tout sur la pile, soit 8 ko, et ça ne pose pas de problème.
Si quelqu'un arrive à la planter avec une Stack Overflow, qu'il m'en informe

Certes mais c'est pour pas qu'il prenne de mauvaises habitude parceque quand il aura besoin de faire sa pour des grosse quantité de memoire, il comprendra pas pourquoi ca plante(je le sais ca m'est arrivé).

et puis Einstein je suis pas prêt de l'utiliser tant qu'il aura pas des icone de petites taille(le top serait de pouvoir choisir)

Tu veux des icônes 8x8 ? il y a Doors et PTC qui peuvent faire ton bonheur !

Mais bien sur: je n'utilise que Doors dommage que l'interface ne soit pas très pratique. Dès que j'ai fini mon projet je m'attaque a mon shell