Mon second programme en C - Page 5

Non mais j'avoue honnêtement que même avec ma lenteur de débutant, le C permet d'avancer très vite.

En asm, t'as des bugs chelou au run-time. Ici, je les ai en temps de compilation. Ok.

	void *PlanesHdPtr,*PlanesPtr;			//ptr to the handle and to the planes
	if(!(PlanesHdPtr = HeapAllocPtr(LCD_SIZE*4+8)))	//try to alloc planes to save work
	{
		ST_helpMsg("Not enough RAM to run GrayTool");	//else display a message,
		ngetchx();				//wait for a key,
		return;				//and quit
	}
	PlanesPtr = ((void *)((long)(PlanesHdPtr + 7) & ~7L));		//8x alignment for HW1
	memset(PlanesPtr,0,LCD_SIZE*4);			//clear planes
	GribOn(PlanesPtr,PlanesPtr+LCD_SIZE);			//and set up grays

Ada

Folco (./108) :

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

Ben pourquoi c'est par défaut alors ?

	move.l %d4,%d3			;PlanesPtr
	addq.l #7,%d3			;alignement
	moveq #-8,%d0
	and.l %d0,%d3
	pea 15360.w			;taille du memset pour effacement des plans
	clr.w -(%sp)			;on remplit évidemment de 0
	move.l %d3,-(%sp)		;adresse des 4 plans
	move.l 2544(%a0),%a0
	jbsr (%a0)			;memset
	move.l %d3,%d7			;toujours l'adresse des plans
	add.l #3840,%d7			;plan suivant
	move.l %d3,%d1			;arg1
	move.l %d7,%d0			;arg2
	jbsr GribOn			;puis GribOn ...
	lea (10,%sp),%sp

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é ?

	.xdef	_ti92plus
	.xdef	_nostub
	.include	"kernel.h"

__main:
	pea.l	3840*2+8
	RC	HeapAllocPtr
	movea.l	%a0,%a2
	move.l	%a0,%d0
	addq.l	#7,%d0
	andi.b	#~7,%d0
	move.l	%d0,%d1
	addi.l	#3840,%d1
	bsr	GribOn
	RC	ngetchx
	move.l	%a2,(%sp)
	RC	HeapFreePtr
	addq.l	#4,%sp
	rts

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

	short KDOWN = (CALCULATOR?344:340);
	short KUP = (CALCULATOR?338:337);
	short KLEFT = (CALCULATOR?337:338);
	short KRIGHT = (CALCULATOR?340:344);

	case KLEFT:
		if (DrawingData.CursX0 != 0)
			DrawingData.CursX0 -= 1;
		break;
	case KRIGHT:
		if (DrawingData.CursX0 != LCD_WIDTH)
			DrawingData.CursX0 += 1;
		break;

short vertical = CALCULATOR;
switch (machin) {
  case 337: vertical = !vertical;
  case 338: if (vertical) /* up */ else /* left */ break;
  case 340: vertical = !vertical;
  case 344: if (vertical) /* down */ else /* right */ break;
}

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).

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)

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

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

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

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);

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.

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; 

Folco (./108) :

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

Ben pourquoi c'est par défaut alors ?

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} ;

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

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_*.

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é ?

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

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); ?

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

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).

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 ?

/* 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

diff -Naur gcc-4.1.2.orig/gcc/stmt.c gcc-4.1.2-src/gcc/stmt.c
--- gcc-4.1.2.orig/gcc/stmt.c	2006-05-29 08:50:07.000000000 +0200
+++ gcc-4.1.2-src/gcc/stmt.c	2007-02-19 02:32:34.000000000 +0100
@@ -2515,6 +2515,9 @@
 	  use_cost_table
 	    = (TREE_CODE (orig_type) != ENUMERAL_TYPE
 	       && estimate_case_costs (case_list));
+/* (TIGCC 20030907) Don't balance the tree when optimizing for size. A linear
+                    decision tree gives far smaller code. -- Kevin Kofler  */
+	  if (!optimize_size)
 	  balance_case_nodes (&case_list, NULL);
 	  emit_case_nodes (index, case_list, default_label, index_type);
 	  emit_jump (default_label);
@@ -3083,10 +3086,17 @@
 	     does not have any children and is single valued; it would
 	     cost too much space to save so little time.  */
 
+	  /* (TIGCC 20030907) Also omit the conditional branch to default if we are
+	                      optimizing for size. -- Kevin Kofler
+         (TIGCC 20040719) But don't omit branches which are needed for
+                          correctness in case ranges. -- Kevin Kofler  */
+
 	  if (node->right->right || node->right->left
 	      || !tree_int_cst_equal (node->right->low, node->right->high))
 	    {
-	      if (!node_has_low_bound (node, index_type))
+	      if (!node_has_low_bound (node, index_type)
+	          && (!optimize_size
+	              || !tree_int_cst_equal (node->right->low, node->right->high)))
 		{
 		  emit_cmp_and_jump_insns (index,
 					   convert_modes

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

Folco (./148) :
le kernel résoud silencieusement les problèmes de pseudo-constantes avec des ram calls

les problèmes de f-line

Kevin Kofler (./147) :
TiEmu reconnaît les routines de gris courantes (y compris la version standard de Grib) pour ses "gris parfaits",

Kevin Kofler (./147) :
PpHd dans sa sagesse infinie a ignoré tous mes arguments,