Mon second programme en C - Page 4

Folco (./47) :
Du coup, j'écris ça :
Plane0Ptr = (void *)0x4c00;Là, il ne râle pas, ça doit bien être comme ça qu'on fait. C'est normal ?

Oui.

Ou alors est-ce du bidouillage et je ne fais pas ça proprement ?

Une adresse codée en dur est forcément du bidouillage.

Comme tu t'es rendu compte dans le ./48, tu peux écrire:
Plane0Ptr = LCD_MEM;
comme ça tu laisses TIGCCLIB faire son bidouillage (et c'est normal qu'il y ait du bidouillage dans la libc ).

Lionel Debroux (./49) :
Est-ce que tu fais un programme kernel-based ?
(je demande parce que j'ai upgradé kernel.h, voir http://trac.godzil.net/gcc4ti/ticket/9 ).

kernel.h est un bidouillage, il suffit d'activer le mode kernel dans les headers officiels de TIGCC (cf. options du projet ou -DUSE_KERNEL en ligne de commande).

Folco (./60) :
Pourquoi ça marche pas ça ?
PlanesPtr = PlanesPtr & ~7;Il me dit que les opérateurs sont invalides... On a pas le droit de jouer à ça avec un pointeur ?

Effectivement, les opérations booléennes par bits sont interdites sur les pointeurs, la plupart des processeurs ne les permettant pas. (D'ailleurs, le 68k en fait partie, il n'y a pas de anda.)

edit -> Ca, c'est la solution propre ?
PlanesPtr = (void *)((long)PlanesPtr & ~7);

C'est le mieux que tu puisses faire, malheureusement.

Mais il est plus propre d'utiliser intptr_t de stdint.h plutôt que long. Tu peux récupérer le fichier stdint.h qui sera dans la prochaine bêta de TIGCC ici, rajoute-le dans ton dossier $TIGCC/include/c.

Folco (./61) :
Mais pourquoi ne râle-t-il pas, je lui ai jamais dit que ~7 était un long, comment le sait-il ?

Il ne le sait pas. Il calcule comme ça:
7 est un int.
~7 vaut -8, toujours de type int.
Tu fais un & entre un int et un long. L'opération est effectuée en le type le plus grand, en l'occurrence long. Du coup, il y a extension de signe, tes entiers étant signés, donc le & est effectué entre (long)PlanesPtr et (long)-8. Et donc le résultat est le bon.

Mais il vaut mieux écrire ~7L si tu veux être sûr que tu travailles sur un long.

Folco (./64) :

	PlanesPtr = ((void *)((long)(PlanesHdPtr + 7) & ~7));
	GribOn(PlanesPtr,PlanesPtr+LCD_SIZE);

La routine de gris est censée faire ça toute seule, Grib ne le fait-elle pas? Utilise plutôt la fonction GrayOn de TIGCC, qui s'occupe de toutes ces allocations toute seule. (La manière de travailler en C, c'est de faire faire ce genre de choses aux libs, pas de réinventer la roue comme tu aimes le faire.)

Brunni (./65) :
Typiquement pour aligner de la mémoire tu as memalign en principe.

Ça n'existe pas dans TIGCC.

Sally (./69) :
Un truc qui ne te sert pas en l'occurrence mais peut t'intéresser, c'est que si tu as un pointeur vers un type le compilateur s'arrange tout seul pour l'aligner sur une adresse permettant de lire ce type. Si je ne me trompe pas, si tu castes un pointeur void* vers int* il doit ajouter une instruction pour obtenir la parité, en particulier.

Euh non, pas du tout. Si tu castes un pointeur impair vers int *, tu vas te taper un Address Error dès la première fois que tu essaies de l'utiliser.

Par contre il me semble que sur TI il n'est jamais *nécessaire* d'avoir un alignement meilleur

Sauf pour les plans de gris sur HW1, comme tu viens de le voir.

Zerosquare (./76) :
C'est pas terrible en effet, mais t'as pas vraiment le choix : les pointeurs sont typés en C, tu ne peux quasiment rien faire avec un pointeur void, à part le caster vers un pointeur typé. En pratique, void ça sert essentiellement comme étape intermédiaire quand un type peut varier à l'exécution (Exemple : une fonction qui accepte plusieurs types de pointeurs en entrée, suivant la valeur d'un flag).
Il me semble que certains compilos interprètent les pointeurs void comme des pointeurs vers un char, mais je doute que ce soit standard.

TIGCC permet de faire de l'arithmétique sur un void * comme si c'était un char *. Mais tu ne peux pas le déréférencer, ça ne veut rien dire, de lire ou écrire un void.

Lionel Debroux (./78) :
et je ne pense pas qu'il soit prévu que ça fasse partie de C++0x...

On s'en fout de C++0x dans TIGCC, c'est du C, pas du C++.

squalyl (./86) :
Folco> trilove parce que rah, quand même, ce genre d'expression pour 3 opcodes 68k, ça rox (et je sais qu'on a pas le choix, les faut bien les cast ^^)

Bah, il faut bien faire l'équivalent en assembleur: il faut mettre le pointeur dans un registre de données (<=> le caster en un entier), faire le addq (+7) et le andi (&~7) et puis le remettre dans un registre d'adresses (<=> le recaster en un pointeur) pour pouvoir l'utiliser comme une adresse.

squalyl (./88) :

Kevin Kofler (./88) :
2. Un char [] n'est pas un char *, il y a des endroits où c'est différent et ceci en est un!

je l'ai en effet appris à mes dépends, mais EN QUOI c'est différent?

extern char *x attend de trouver ça:
x: .long x_data
avec:
x_data: .asciz "toto"

extern char x[] attend de trouver ça:
x: .asciz "toto"

Kevin Kofler (./91) :
Euh non, pas du tout. Si tu castes un pointeur impair vers int *, tu vas te taper un Address Error dès la première fois que tu essaies de l'utiliser.

Ah bon , je ne sais pas d'où j'avais tiré cette idée alors (je croyais que le compilateur était intelligent moi )

Il s'agit d'un compilateur C hein : c'est pas le genre de langage qui te tire d'un mauvais pas, plutôt celui qui te donne un coup dans le dos quand t'es au bord du gouffre ^^

Sally (./92) :

Kevin Kofler (./91) :
Euh non, pas du tout. Si tu castes un pointeur impair vers int *, tu vas te taper un Address Error dès la première fois que tu essaies de l'utiliser.

Ah bon , je ne sais pas d'où j'avais tiré cette idée alors (je croyais que le compilateur était intelligent moi )

Certains compilateurs rajoutent du padding dans les structures pour aligner les octets sur des adresses paires, mais de là à corriger tes pointeurs automatiquement, il y a un monde

Ximoon > ah oui j'ai dû extrapoler après avoir vu un truc de ce genre alors ^^. Si tu définis une structure avec un char et un int, il va rajouter un octet vide pour que l'int soit à une adresse paire, c'est ça ?

Oui

Kevin Kofler (./91) :

Folco (./64) :

	PlanesPtr = ((void *)((long)(PlanesHdPtr + 7) & ~7));
	GribOn(PlanesPtr,PlanesPtr+LCD_SIZE);

La routine de gris est censée faire ça toute seule, Grib ne le fait-elle pas?

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

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)

Au fait je remarque en ./61 que le code généré est moins efficace que celui des macros intégrées à Grib #sifflote#

Oui, c'est pas optimal, et on parle pas du relogement

Voilà ce qui se passe quand Kevin n'est pas présent sur le forum depuis plusieurs jours, et découvre un gros topic
Bon, il ne peut évidemment pas s'empêcher de raconter des conneries (au milieu de choses correctes), comme d'habitude:

Est-ce que tu fais un programme kernel-based ?
(je demande parce que j'ai upgradé kernel.h, voir http://trac.godzil.net/gcc4ti/ticket/9 ).

kernel.h est un bidouillage, il suffit d'activer le mode kernel dans les headers officiels de TIGCC (cf. options du projet ou -DUSE_KERNEL en ligne de commande).

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

et je ne pense pas qu'il soit prévu que ça fasse partie de C++0x...

On s'en fout de C++0x dans TIGCC, c'est du C, pas du C++.

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, je ne comprends pas pourquoi tu mords encore à l’hameçon ?

Peut-être parce que j'espère toujours (même si j'ai, comme beaucoup, été tant de fois déçu...) que Kevin changera, un jour... C'est souhaitable pour tout le monde.

Je mords à certains hameçons, mais avec le temps, j'ai appris à ne pas relever tout ce qu'il a écrit et sur lequel on peut avoir une opinion différente de la sienne, ou simplement compléter ce qu'il a écrit (parce qu'il n'écrit pas que des conneries - il n'aurait pas tenu 9 ans dans la communauté si c'était le cas)
Les faits montrent que ça ne sert à rien, puisque non seulement ça n'a pas fait pas changer Kevin d'avis jusqu'à présent (au contraire: en général, il se braque encore plus), mais aussi, c'est un bon moyen de dégrader l'ambiance du forum et de se faire mal voir.

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. En effet, je m'étais mis à relever ses omissions et sa mauvaise foi sur ce forum-là, après avoir compris à l'été 2004 (conséquence inattendue de l'épisode "Kevina", pour ceux qui s'en souviennent) quel personnage désagréable il était en réalité.
Evidemment, comme il répondait (il faut être au moins deux pour se disputer...), ça a dégradé l'ambiance. Je sais très bien qu'au moins une personne a arrêté de fréquenter la communauté TI-68k suite à ça, elle me l'a écrit. J'avais donc fini par ajouter geogeo et serioussam comme modérateurs, pour justement nous modérer si on continuait dans cette voie...
Ca a duré moins d'une heure, le temps que Kevin le voit et vire tout le monde. Il est vrai que c'est plus facile de se venger que d'accepter la critique et de se remettre en cause...


Bon, allez, fini le off-topic. Mon précédent message ne l'était pas complètement, celui-ci l'est...
Comme souvent, c'est à la suite d'omissions, de mauvaise foi ou de remarques carrément off-topic de Kevin... Comme souvent, le topic se tenait bien jusqu'à ce qu'il y amène ses gros sabots (en plus de ses compétences techniques utiles à tous)...

Lionel Debroux (./104) :
Peut-être parce que j'espère toujours (même si j'ai, comme beaucoup, été tant de fois déçu...) que Kevin changera, un jour... C'est souhaitable pour tout le monde.

Non, c'est ce que tu veux toi. Est ce vraiment important pour "tout le monde"? enfin perso je me suis convaincu que old kevin is old, je l'accepte comme ça et relève ce qui est intéressant, le reste ne vaut pas la peine que je le remarque.

bref grâce à kevin ajd j'ai appris la différence entre char[] et char*.

Est ce vraiment important pour "tout le monde"?

Ben, pour Kevin et pour les gens avec qui il est en relation. J'ai déjà expliqué ça à topics/2-117325-moved-tigcc-nom-pour-le-fork/3#86 .
Avec un Kevin plus agréable et plus ouvert, GCC4TI n'existerait probablement pas, et TIGCC serait plus avancé que ce qu'il n'est. Ce qui serait bien, là aussi pour "tout le monde" (la communauté TI-68k, ici).

je l'accepte comme ça et relève ce qui est intéressant, le reste ne vaut pas la peine que je le remarque.

J'y viens aussi, ne t'en fais pas
Si ça n'était pas le cas, par exemple, GCC4TI aurait déjà fait une réponse officielle au FUD que Kevin a posté sur GCC4TI (ce que plusieurs personnes ont suggéré de faire). Mais il n'était à mon avis pas opportun de creuser plus profond dans le bac à sable, en utilisant les propres techniques de Kevin.

Des fois ça ne sert à rien de vouloir changer les gens, chacun a sa vision et philosophie de vie, et souvent certaines qu'on n'arrive absolument pas à comprendre fonctionnent en fait plutôt bien, voire mieux que la nôtre en fin de compte ^^

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; 

Kevin Kofler (./89) :
Sinon, tu peux aussi utiliser directement &(const SCR_RECT){{0,0,239,127}} partout où tu en as besoin et ça sera unifié par le constant merging.

Ah, je me demandais si ça serati regroupé, tant mieux si ça l'est, je vais pouvoir faire ça, c'est en effet plus simple.

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

Ben pourquoi c'est par défaut alors ?

Je crois qu'il faut définir la taille de ton tableau Data.

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

Sinon utilise un pointeur de unsigned char à la place, ça devrait passer. (mais forcément, ça implique une allocation dynamique, etc)

Ok merci, je vais tenter d'essayer, merci.

ça fait combien t'avais dit ?

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

M'enfin pour être franc, je n'ai pas fait de C depuis des lustres... !

Cher, très cher ! En plus je me suis connecté au boulot en VPN/RDP pour vérifier que ça compile... (pas de gcc sous la main pour vérifier ) Bon, je "retourne" chez moi

On fait comment pour faire une boucle infinie propre dans un programme ? Autant le bra en assembleur me va très bien, autant le goto en C me paraitrait immonde (même si ça ferait la même chose ) Ya pas moyen de faire ça "élégamment" ?

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_*. J'ai essayé divers casts, sans succès. Comment faire svp ?

Folco (./112) :
On fait comment pour faire une boucle infinie propre dans un programme ? Autant le bra en assembleur me va très bien, autant le goto en C me paraitrait immonde (même si ça ferait la même chose ) Ya pas moyen de faire ça "élégamment" ?

J'ai vu que ça provoque de gros trolls sur des forums cette question. "Faut faire for(; !!!" "Mais non abruti, while(true)." "Mais non, un label pour ce genre de chose, ça peut aller faut pas abuser" etc...

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

./112: en plus du goto, les manières les plus traditionnelles d'avoir une boucle infinie sont
for ( ; ; ) { ... } }, while(1) { ...(1); et do { ... } while
e souvent asm volatile("0: bra.s 0b");Pour le breakpoint, j'utilis
tthdex-internal-not-working contient au moins une boucle infinie imbriquée dans une boucle infinie, et on sort des deux par un goto

./113: il faut enlever les '' autour de KEY_*. '' est une valeur pour un unique char. '1' est le caractère 1 (0x31), pas 0x1.

Lionel Debroux (./116) :
./113: il faut enlever les '' autour de KEY_*. '' est une valeur pour un unique char. '1' est le caractère 1 (0x31), pas 0x1.

Ah oué tiens, maintenant que tu le dis t1 je sais pas où j'ai la tête des fois

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

Par habitude, et pour être sûr que le breakpoint est écrit sous la forme d'un bra.s

./115: comment sont définies le type de la struct DrawingData, et FLAGS_DEFAULT ?

Ben chépa, mais toujours est-il que maintenant, ça marche.
En asm, t'as des bugs chelou au run-time. Ici, je les ai en temps de compilation. Ok.

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