Sasume (./97) :
Si si, elle peut le faire (avec la fonction GribOnAllocPlanes), mais elle permet aussi à l’utilisateur de fournir lui-même les planes, s’il a envie.Et il y a aussi une macro (GribMakePlanes) qui permet d’obtenir, à partir d’un bloc de mémoire (pas forcément aligné sur une adresse multiple de 8), les adresses des deux plans (alignées comme il faut).

Cette manière de fonctionner ne permet pas d'utiliser LCD_MEM pour l'un des plans sur HW1.

Folco (./98) :
Et ya aussi GribOnAllocPlanes2, qui alloue deux plans contigus, alignés komilfô évidemment, sur tous les HW, et en utilisant le handler de f-line (-50 bytes)

Ce n'est pas réutilisable dans tous les programmes. Il y a des situations dans lesquelles on ne peut pas utiliser de handler F-Line. Par exemple, si le programme doit être compatible tous AMS (donc impossible d'utiliser celui de AMS) et si on veut pouvoir exécuter un autre programme sur une Titanium sans HW3Patch (donc impossible d'utiliser un handler perso, parce que ce programme, qui n'est pas forcément compatible tous AMS, pourrait essayer d'utiliser le handler de AMS et donc se taper ton handler perso et du coup exécuter du code dans une zone non déprotégée).

Lionel Debroux (./101) :
Voilà ce qui se passe quand Kevin n'est pas présent sur le forum depuis plusieurs jours, et découvre un gros topic

Euh, le topic n'avait que 2 jours quand je l'ai découvert! Vous avez réussi à poster des tonnes de messages en quelques heures, donc certains étaient carrément incorrects d'ailleurs.

Non, il ne suffit pas d'utiliser les headers officiels de TIGCC pour bénéficier de toutes les capacités de PreOS, devenu standard de fait depuis qu'il est le seul "kernel" maintenu (ça fait CINQ ans, quand même...). Et ce n'est pas de ma faute, puisque j'ai justement modifié kernel.h pour le rendre plus intégrable dans le système de doc spécifique de TIGCC/GCC4TI

kernel.h ne sera jamais intégré à TIGCC, c'est une mauvaise solution à un "problème" qui n'en est pas un.

Depuis quand est-il interdit d'évoquer un sujet un peu plus large, sous peine de se faire rabrouer par le maître ?

Parce que ce topic parle de C et de TIGCC, pas de C++. Tu es hors sujet.

De plus, il serait dommage qu'il n'y ait pas, à moyen terme, d'upgrade du standard C à partir d'un petit sous-ensemble de ce qui est ajouté par C++0x (voir http://gcc.gnu.org/projects/cxx0x.html ), citons:
* changement d'auto (?);
* expressions constantes généralisées;
* static asserts;
* extension des enums pour améliorer leur typage, par exemple §3.2 de n2347;* pointeur null et alignements (un sous-ensemble de n2341);

Ça m'étonnerait, les standards C et C++ divergent de plus en plus, le C++0x n'intègre toujours pas toutes les nouveautés du C99 et certaines ont même été explicitement refusées.

Lionel Debroux (./103) :
Relever ce qu'il a écrit et sur lequel on peut avoir une opinion différente de la sienne est la cause racine du fait qu'il m'ait retiré les pouvoirs d'admin sur le forum de TIGCC/TICT.

Non, parce que tu as abusé de tes pouvoirs pour nommer des admins sans demander l'avis de Thomas, Sebastian et/ou moi. Te laisser tes droits aurait été un risque de sécurité, donc j'ai été obligé d'agir rapidement. (Et j'ai discuté avec Thomas et Sebastian quoi faire. J'avais proposé de faire un forum TIGCC séparé et de te rendre les droits sur le forum TICT, et je pense toujours que ça aurait été la meilleure solution. Peut-être que je vais même finir par le faire maintenant que la TICT est devenue notre concurrent (cf. la news qui est sur votre page d'accueil depuis quelques semaines).)

Folco (./107) :
Bon, au sommet de ma nioubitude, j'arrive pas à définir un BITMAP... Ben ouais ça arrive.

J'essaye ça :
const struct BITMAP mapic = {10,10, {les data}};

Et apparemment... c'est pas ça

c'est défini comme ça :

typedef struct { 
 unsigned short NumRows, NumCols; 
 unsigned char Data[]; 
} BITMAP; 

Pourtant c'est bien la bonne syntaxe normalement. Tu essaies de définir ça où? Si c'est à l'intérieur d'une fonction, essaie avec static const struct ....

Folco (./108) :

Kevin Kofler (./89) :
Pourquoi -O2 et pas -Os?

Ben pourquoi c'est par défaut alors ?

C'est -Os par défaut pour tous les nouveaux projets dans les EDIs depuis des lustres. En ligne de commande, c'est -O0 par défaut (totalement inutilisable) pour des raisons de compatibilité antérieure (et c'est bien à cause de ça que la ligne de commande est dépréciée, elle n'a aucun moyen de savoir si tu as un nouveau projet ou un vieux projet).

Pen^2 (./111) :
Sinon ça, ça fonctionne aussi (sans allocation dynamique, contrairement à ce que j'avais raconté...) :

typedef struct {  
 unsigned short NumRows, NumCols;  
 unsigned char* Data;  
} BITMAP; 
unsigned char data[]= {1, 2, 3} ;
BITMAP myBitmap= { 10, 10,  data} ;

Ça ne fonctionne pas, ta structure BITMAP est incompatible avec celle de AMS.

Folco (./112) :
On fait comment pour faire une boucle infinie propre dans un programme ?

while (1) ou for (;;).

Folco (./113) :
Tiens, quand je fais ce switch :

	short key;
MainLoop:
	key = ngetchx();

	switch (key) {
		case 'KEY_APPS':
			DrawMenu(&RootMenu,&DrawingData);
			break;
		case 'KEY_CATALOG':
			DrawMenu(&DrawingMenu,&DrawingData);
			break;
		case 'KEY_MODE':
			DrawMenu(&ModeMenu,&DrawingData);
			break;
	}
	goto MainLoop;

Il me warn : Character constant too long for its type, en m'indiquand les KEY_*.

Parce que les apostrophes sont en trop, ce n'est pas un caractère, c'est une constante.

De plus, tu ne peux en général pas faire un switch sur les KEY_* parce que certains dépendent de la calculatrice et ne sont donc pas des constantes (mais des pseudo-constantes).

Folco (./115) :
Bon sinon j'en ai marre de buter sur des conneries du genre :

	case '1':
		DrawingData.FLAGS_DEFAULT = 10;
		break;

Expected identifier before numeric constant, me dit-il avec le curseur entre le nom de la structure et le nom du champ. Qu'est-ce qu'il merdouille encore, c'est pourtant pas compliqué ?

FLAGS_DEFAULT est une macro qui correspond à un nombre (je ne sais pas lequel parce que ce n'est pas une constante de TIGCCLIB), donc tu es en train de lui dire quelque chose comme DrawingData.0 = 10, évidemment que le compilateur ne comprend pas. Tu dois vouloir dire flags ou Flags, pas FLAGS_DEFAULT.

Lionel Debroux (./116) :
e souvent asm volatile("0: bra.s 0b");Pour le breakpoint, j'utilis

Le débogueur sert à ça!

Brunni (./118) :

Lionel Debroux (./116) :
e souvent asm volatile("0: bra.s 0b");Pour le breakpoint, j'utilis

Bizarre pourquoi tu ne fais pas simplement while (1); ?

Parce que GCC vire tout le code dominé par (= démontrablement exécuté toujours après) une boucle infinie parce qu'il ne peut pas être atteint. Du coup tu ne peux pas sauter ton "breakpoint" dans le débogueur. (Mais de toute façon, cette manière de créer un breakpoint est totalement foireuse, il faut passer par le débogueur pour mettre ses breakpoints, pas perdre son temps à recompiler son programme, en plus en y mettant une instruction qui plante la calculatrice, tu risques de publier un programme qui plante par erreur, c'est déjà arrivé au moins 2 fois à Lionel.)

Folco (./132) :
Ok, c'est ma version perso de Grib qui déconne. Au niveau des variables je suppose.

Si tu as modifié la recopie des plans sur HW2, ça doit être TiEmu qui ne reconnaît pas ta routine de recopie. TiEmu reconnaît les routines de gris courantes (y compris la version standard de Grib) pour ses "gris parfaits", si tu as bidouillé cette recopie, ça ne va plus marcher.

Cela dit, si c'est ça, je ne comprends pas pourquoi ça foire si tu émules une HW1. Es-tu sûr que tu ne nous fais pas des recopies sur HW1 au lieu de changer le port du matériel comme il faut?

Sasume (./137) :
Oui, c’est parce que les macros KEY_machin ne sont pas toujours de bêtes constantes numériques : http://tigcc.ticalc.org/doc/compat.html#KEY_DOWN (par exemple) et si tu fouilles un peu tu t’aperçois que ça utilise ça : http://tigcc.ticalc.org/doc/compat.html#PSEUDO_CONST_CALC or, la variable CALCULATOR peut ne pas être résolue en temps de compilation (c’est-à-dire que c’est une variable dont la valeur dépendra du contexte d’exécution). Or, switch ne permet d’utiliser que des constantes numériques (ce n’est pas le cas dans d’autres langages de programmation de plus haut niveau).

Effectivement. Il faut utiliser une chaîne if-else.

Un de mes TODOs pour GCC est de permettre les switches sur les pseudo-constantes d'une manière ou d'une autre (le plus simple, ça doit être de transformer les switches contenant des variables en une chaîne de if-else au niveau de la conversion de l'arbre syntaxique C en l'arbre syntaxique Gimple), mais je n'ai jamais eu le temps d'implémenter ça, un volontaire?

Folco (./140) :
Voici ce qu'est la pseudo-constante CALCULATOR :

This pseudo-constant is 0 on the TI-89, 1 on the TI-92 Plus, and 3 on the V200.

Quid des 89ti ? c'est 0, comme les 89 ?

Oui. Pour TIGCC, une Titanium est une TI-89 HW3/HW4. Il y a même "TI-89" dans le nom, et toutes les différences sont dues à la version du matériel. Les caractéristiques définies par le modèle (écran, clavier) sont les mêmes. De plus, ça fait que les programmes existants utilisant if (CALCULATOR) marchent toujours.

Malheureusement, PpHd dans sa sagesse infinie a ignoré tous mes arguments, ainsi que la compatibilité avec TitaniK et Iceberg, quand il a porté PreOs vers la Titanium, donc du coup on se tape ça en kernel:

/* PreOs 0.70 says CALCULATOR is -1 on the Titanium. We don't. */
#define CALCULATOR ((signed char)_CALCULATOR[0]>0?_CALCULATOR[0]:0)

Sally (./146) :
il fait une suite de if/elseif s'il y a des trop gros trous dans la table

Il fait un arbre binaire de if/elseif, sauf dans TIGCC en -Os où il fait une chaîne (parce que c'est plus petit).

mais je ne sais pas exactement quels sont les seuils (ça doit dépendre des switches d'optimisation).

range > 3 * count en -Os, range > 10 * count sinon.