Register - Page 2

>> Sinon qd on met trop de registre il me semble bien que TIGCC les déclare comme une var normale
C'est ce que je t'ai expliqué au post #24

>> c'est normale qu'en redéclarant les varaibles dans toutes les fonctions que je gagne de la place?
oui !

>> Et c'est possible de faire ça ?
Ben essaie

>> c'est normale qu'en redéclarant les varaibles dans toutes les fonctions que je gagne de la place?
oui !

sauf si tu les initialise dans toutes

De la doc de TIGCC:
>>the request for storing data in registers may be denied, if the compiler concludes that >>there is not enough free registers for use at this place.
Alors, s'il n'y a pas assez de registre libres, la variable ne sera pas stocké dans un registre. Aussi, au lieu de écrire "void Disp_Menu(register unsigned short x1, register unsigned short x2, register unsigned short l, register unsigned short v)" utilise -mregparm, ça fera la même chose, mais il faut avoir TIGCC .94 (je ne sais pas quelle bêta, il était bouggé dans .94B14).

n'utilisez pas de nested functions, c la seule incompatibilité majeure entre TI-GCC et GTC, et puis de toutes façons l'intérêt est limité (surplus de taille et de temps d'exécution à cause du link/unlk et du stockage des variables communes aux sous-fonctions et à la fonction principale dans la pile)

GTC

hé hé

vous inquiétez pas, a priori il sort à la Toussaint (la version actuelle est quasiment distribuable, mais g encore pas mal de boulot genre doc et site)

la toussain c bien bo mais de kelle année

GTC sux....
Xlib tournera meme pas dessus alors a quoi bon avoir le meilleur compilo si on a pas la meilleur lib

GTC forever....
GraphX tournera dessus alors à quoi bon "suxer" GTC si on a une bonne lib qui tourne dessus

> la toussain c bien bo mais de kelle année

A priori 40 ans en avance sur le calendrier (NDLR: 2042, pour les incultes)

> Xlib tournera meme pas dessus

ah bon, c nouveau? Si c compatible TI-GCC, y a pas mal de chances pour que ça soit compatible GTC (avec éventuellement un minimum de portage)


PS : Je viens de regarder XLib 1.00, et ça va rouler au niveau du portage juste à lancer les outils de conversion et hop, ready to send

GTC supporte la gestion des DLL ?
Si oui chapeau!!

NB: si tu pouvais optimiser au passage la gestion des dll , ya pas mal de chose a faire...

je signale qd même que je n'ai rien réimplémenté, simplement converti (ceci dit c qd même assez coton vu la quantité de RAM et de ROM de faire tenir les 260 ko de la TI-GCC Lib en 40 ko )

Sinon je peux facilement faire une sorte de OPTIMIZE_DLL_CALLS type OPTIMIZE_ROM_CALLS, mais qui ne bouffe pas de registre dans les fonctions qui n'utilisent pas ou peu les appels de DLL/ROM_CALL, donc c assez sympa (et c activé d'office puisque ça ne présente jamais d'inconvénient au niveau du code généré ) - d'ailleurs GTC ne supporte pas le OPTIMIZE_ROM_CALLS traditionnel qui désactive a5...

un optimisation des appels serait tres interessant.

bon je viens de regarder un peu plus en détail, et il faudrait changer un seul truc : mettre l'adresse du sprite dans a0 et pas dans a1 (je pourrais m'arranger pour que ça marche avec a1, mais c bcp de boulot pour pas gd-chose...)

Si tu pouvais le faire avant que XLib soit officielle... (pas de pb d'incompatibilité avec les progs existants)

Raphaël a écrit :
Je comprends pas bien pourquoi qd j'utilise register pour déclarer une variable qui servira à une fonction, il y a le message : "Register variable 'ma_var' used in nested function".
On peut pas déclarer une variable qui sera utiliser par une fonction avec register ? Pourtant ça à l'air de bien marcher...

C'est le mot "nested" qui dit tout. Tu ne peux pas l'utiliser dans une sous-fonction d'une autre fonction. Et si ça marche, c'est parce que GCC ignore "register" vu que ce n'est pas possible dans ta situation.

janjan2 a écrit :
hem nested functions = recursion

Non, ce sont des fonctions embriqués (extension GCC).

Raphaël
a écrit : Et c'est possible de faire ça ? : "void Disp_Menu(register unsigned short x1, register unsigned short x2, register unsigned short l, register unsigned short v)"

Oui, mais il faut soit préciser des registres explicitement:
void Disp_Menu(register unsigned short x1 asm("d0"), register unsigned short x2 asm("d1"), register unsigned short l asm("d2"), register unsigned short v asm("d3"))
(d'ailleurs, le mot register est optionnel ici - je ne l'ai mis que pour la clarté), soit utiliser __attribute__((__regparm__)):
__attribute__((__regparm__(4))) void Disp_Menu(unsigned short x1, unsigned short x2, unsigned short l, unsigned short v)
Le "4", ça veut dire que 4 registres par classes de registres peuvent être utilisés pour les paramètres. Donc d0-d3/a0-a3. Et GCC utilisera des registres d'adresses pour les pointeurs et des registres de données pour le reste.

n'utilisez pas de fonctions avec des paramètres 'register' autres que d0-d2/a0-a1 si vous voulez que votre prog soit compatible GTC

Tant pis pour GTC.

Kevin tu oublies que GTC est super important, ce sera le meilleur compilo on-calc.

Il vaut mieux s'y préparer sinon on pourrait le regretter.

Enfin pour moi, toujours, c'est très important : j'ai toujours rêvé de pouvoir programmer on-calc. J'ai pas fait Azur par pure folie

Kevin, franchement tu me déçois bcp...

Je pensais que tu défendais le _nostub parce que tu croyais que les kernels étaient une mauvaise solution, mais en fait tu ne cherches qu'à promouvoir envers et contre tout ce dans quoi tu t'es investi : tu as fait pas mal de choses en faveur du _nostub, donc maintenant tu te mets à défendre le _nostub quoi qu'il arrive, indépendamment des arguments en faveur des kernels; et maintenant comme tu fais partie de la team TI-GCC tu vas critiquer GTC sous prétexte que c'est un "concurrent" de TI-GCC ? (au passage, à propos de "concurrence", Nibbles Pro est plus petit compilé avec GTC qu'avec TI-GCC )

Si GTC ne gère pas cette méthode de passage, c pas par flemme ou par manque de temps, c parce que à cause de l'organisation des registres, le programme serait bcp plus gros et plus lent (alors que regparm est fait pour optimiser )
Alors, vous me direz, pkoi ne pas changer l'organisation des registres? Tout simplement pour maintenir la RAM requise, la vitesse de compilation et la taille du compilo dans des limites raisonnables (ce qui n'est pas du tout une contrainte sur PC)

tiens c bien la 1è fois que Kevin ne répond pas dans un topic où il est accusé... Kevin?

Désolé, si TIGCC compile très bien des programmes, je ne vois aucune raison de permettre leur compilation avec d'autres compilateurs. Si les programmeurs veulent le faire, tant mieux, mais s'ils n'ont pas que ça à faire, c'est tout à fait normal.

Et je ne vois aucune raison de sacrifier des performances (en n'utilisant pas d3 ici par exemple) juste pour supporter un compilateur inférieur au notre.

> Désolé, si TIGCC compile très bien des programmes, je ne vois aucune raison de permettre leur compilation avec d'autres compilateurs
Ben moi j'en vois une : le fait de pouvoir compiler et modifier son prog on-calc...

> Si les programmeurs veulent le faire, tant mieux, mais s'ils n'ont pas que ça à faire, c'est tout à fait normal.
Je ne dis pas qu'il faut obliger les programmeurs, je dis bien qu'il faut le permettre.

Je précise que mon premier post était à titre purement informatif :

n'utilisez pas de fonctions avec des paramètres 'register' autres que d0-d2/a0-a1 si vous voulez que votre prog soit compatible GTC

Tant pis pour GTC.

> Et je ne vois aucune raison de sacrifier des performances (en n'utilisant pas d3 ici par exemple) juste pour supporter un compilateur inférieur au notre.
Il est légèrement inférieur en qualité de code généré, mais très supérieur en vitesse de compilation et en accessibilité (c plus facile de trimballer une 89 qu'un PC ), donc je ne vois pas l'intérêt de refuser la compatibilité avec GTC... (la compilation conditionnelle ça existe)

Pollux a écrit :
> Et je ne vois aucune raison de sacrifier des performances (en n'utilisant pas d3 ici par exemple) juste pour supporter un compilateur inférieur au notre.
Il est légèrement inférieur en qualité de code généré, mais très supérieur en vitesse de compilation et en accessibilité (c plus facile de trimballer une 89 qu'un PC ), donc je ne vois pas l'intérêt de refuser la compatibilité avec GTC... (la compilation conditionnelle ça existe)

Il est aussi (légèrement d'après ce que tu dis, mais quand-même) inférieur en termes d'extensions acceptées.

Kevin Kofler
a écrit : Il est aussi (légèrement d'après ce que tu dis, mais quand-même) inférieur en termes d'extensions acceptées.

Si tu parle par la des extention GNU, elle sont loin de faire l'uninimité du consorcium sur le C, le C99 a ajouter pas mal de truc au C mais aucune des extention GNu !!

C'est dommage ! y'a des trucs vraiment excellents parmi les extensions GNU
Du genre les tableaux de dimensions indéfinies :

typedef struct
{
  short allocated;
  short used;
  SYM_ENTRY entries[];
} FATVAT;

Sans les extensions GNU ce serait impossible !

ptet masi c super crade au nivo code !
et puis

SYM_ENTRY entries[];

reviens a ecrire

SYM_ENTRY *entries;

et apres c toi qui gere avec malloc/realoc etc..

Sa me fait penser au genre de chose qu'on ammené le C++ qui sont vraiment plus que sale dans le code généré....

godzil
a écrit : Si tu parle par la des extention GNU, elle sont loin de faire l'uninimité du consorcium sur le C, le C99 a ajouter pas mal de truc au C mais aucune des extention GNu !!

Faux!
long long, constructeurs par transtypage, nombres complexes, tableaux de taille déterminée en temps d'exécution seulement, ... Tout ça, c'étaient des extensions GNU jusqu'en 1999, et ça fait partie du standard C99 maintenant.

Thibaut a écrit :
C'est dommage ! y'a des trucs vraiment excellents parmi les extensions GNU
Du genre les tableaux de dimensions indéfinies :

typedef struct
{
  short allocated;
  short used;
  SYM_ENTRY entries[];
} FATVAT;

Sans les extensions GNU ce serait impossible !

Ça, c'est une extension GNU par rapport au C90, mais c'est du C99 standard!
D'ailleurs, avec GCC 2.x, il fallait écrire SYM_ENTRY entries[0];. GCC 3.x suit la syntaxe ISO C99.

godzil a écrit :
ptet masi c super crade au nivo code !
et puis

SYM_ENTRY entries[];

reviens a ecrire

SYM_ENTRY *entries;
et apres c toi qui gere avec malloc/realoc etc..

Pas du tout. Avec la première déclaration, les données de la structure sont contigües!