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"