Mon second programme en C - Page 2

Ok, merci. J'ai prêté mon K&R à mon frangin (et attends, remarque que c'est déjà pas mal d'avoir un bouquin comme ça quand on fait que de l'assembleur )

Folco > faire du C est assez déconcertant quand on a fait de l'ASM, mais finalement tu verras que c'est très utile de bien connaître le 68k quand tu passes au C : tu comprends nettement mieux ce qui se passe (notamment quand tu commences à avoir des pointeurs de pointeurs de pointeurs, pourquoi tu ne peux pas modifier une variable que tu passes en argument, etc.) Tu verras quand tu seras habitué, tous ces détails te paraîtront super clairs, et tu comprendras vraiment l'intérêt de chaque truc du C

Merci des encouragements !

Mouarf, c’est marrant de voir des questions du genre « on fait comment pour dire au compilateur de faire une table de saut pc-relative »

Sinon, j’arrive un peu après la bataille, mais la manière classe de résoudre le problème évoqué en ./15 c’est de déclarer tes chaînes comme ceci : « char string1[] = "ABCDE"; »

[edit] Oui, forcément, au début ça peut paraître emmerdant d’avoir à apprendre la grammaire du C quand on sait faire en quelques lignes la même chose en ASM, mais quand tu géreras des programmes un peu plus gros, tu seras ravi de pouvoir les écrire beaucoup plus rapidement (et avec moins de bugs) en C qu’en ASM.

Bon, encore une question de déclaration. Je voudrais déclarer quelque part un SCR_RECT, dont la définition et dans la doc de TIGCC :

typedef union { 
 struct { 
 unsigned char x0, y0, x1, y1; 
 } xy; 
 unsigned long l; 
} SCR_RECT; 

Je voudrais savoir comment définir quelque part les 4 constantes caracères à la suite : {0,0,239,127}.
J'ai bien des moyens à base de chaine de caractère ou de calcul à la main, mais c'est crade. Comment employer ça proprement ? (en fait, je veux un dc.b 0,0,239,127 qqpart).

unsigned char tab[]= {0, 0, 239, 127} ?
Faut voir comment c'est compilé, mais je pense que ça doit ressembler à un dc.b.

sinon un truc du genre
unsigned long data= 0 << 24 | 0 << 16 | 239 << 8 | 127 << 0 ;
mais je suppose que ça donnera plutôt un dc.l

Folco (./36) :
Folco : Bon, encore une question de déclaration. Je voudrais déclarer quelque part un SCR_RECT, dont la définition et dans la doc de TIGCC :
typedef union { struct { unsigned char x0, y0, x1, y1; } xy; unsigned long l; } SCR_RECT; Je voudrais savoir comment définir quelque part les 4 constantes caracères à la suite : {0,0,239,127}.

SCR_RECT s= {xy: {x0:0,y0:0,x1:239,y1:127} }; (je sais c'est moche)
oubien
SCR_RECT r={l: 0x0000EF7F};

Folco (./28) :
C'est quand même pas la classe de devoir tracer de l'assembleur pour comprendre ce qu'on dit en C.

au contraire, ça t'aide a controler exactement ce que pond le compilo, tu verras mieux ce qui est généré pour chaque instruction C.

Ouais, et si TIGCC est du même genre que les autres versions de GCC, tu vas halluciner devant ce que le compilo te sort comme code, des fois

oui, j'ai oublié de dire, pour mater le code généré, ne pas oublier le flag -O0 (qui devrait s'appeler -fhuman-readable )

Ouais mais là Martial va prendre un couteau quand il va voir le résultat

(ce que je voulais dire c'est que même en mode -O2, des fois, c'est pas génial ; en mode -O0, c'est digne d'un débutant en assembleur )

Pen^2 (./36) :
sinon un truc du genre unsigned long data= 0 [...]

Ouais, je voulais éviter ça même si marche. Je voulais essayer la solution la plus "académique". Et là, il s'agit d'unsigned char.

squalyl (./37) :
SCR_RECT s= {xy: {x0:0,y0:0,x1:239,y1:127} }; (je sais c'est moche)
oubien
SCR_RECT r={l: 0x0000EF7F};

Ok, cool, j'essaye quand j'ai fini ma journée.

Zerosquare (./40) :
Ouais mais là Martial va prendre un couteau quand il va voir le résultat

(ce que je voulais dire c'est que même en mode -O2, des fois, c'est pas génial ; en mode -O0, c'est digne d'un débutant en assembleur )

J'ai déjà halluciné devant du code en effet, non-utilisation des registres, itérations avec lectures des variables en RAM à chaque fois etc... que du bonheur. Pour le moment, je reste en -o2 classique, l'assembleur se lit très bien et me parait bien foutu. (va juste falloir que je trouve comment dire à TIGCC d'utiliser le handler de f-line pour les ROM-calls, et non $c8).

Putain les gars si vous lui sortez ce genre de code il va fuir le C !

Solution simple et intuitive : « SCR_RECT s = {{1, 2, 3, 4}}; ».
En fait, le type SCR_RECT est une union qui contient une struct, d’où la double paire d’accolades.

squalyl (./39) :

oui, j'ai oublié de dire, pour mater le code généré, ne pas oublier le flag -O0 (qui devrait s'appeler -fhuman-readable )

Personnellement -O0 est illisible. Je comprends bien mieux -O2 ou -O3 (quelque soit le CPU - x86,amd64, 68k, ARM, Power Pc ou Spark).
(J'ai du mal à comprendre un truc écrit avec les pieds).

Je trouve moi aussi que -O0 est peu lisible... surtout pour quelqu'un qui est habitué à faire et à lire du code assembleur optimisé

Folco (./41) :
Ouais, je voulais éviter ça même si marche. Je voulais essayer la solution la plus "académique". Et là, il s'agit d'unsigned char.

Ouais mais non, si tu concatènes quatre chars ( ) il te faut un long.

Sasume (./42) :
Putain les gars si vous lui sortez ce genre de code il va fuir le C !

Je suis assez d'accord mais bon

Effectivement c'est la solution à Sasume la meilleure ^^

Bon, j'arrive un peu mieux à faire ce que je veux (et à avancer). Du coup, une question.

J'ai une déclaration de pointeur :
void *Plane0Ptr;
Il s'agit bien évidemment du pointeur sur un plan de gris.
Je veux l'initialiser :
Plane0Ptr = 0x4c00;
Il me dit que je veux balancer un int dans un pointeur, je comprends évidemment son message (sisi, je crois qu'un ou deux trucs cons commencent à devenir évidents )
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 ? Ou alors est-ce du bidouillage et je ne fais pas ça proprement ?

Question subsidiaire, une fonction dont le proto est dans un header, elle sera extern par défaut ? Et une variable, non ?

Ah en fait, ça doit être bon ?

#define LCD_MEM ((void *) 0x4C00)

^^

Question subsidiaire, une fonction dont le proto est dans un header, elle sera extern par défaut ?

Oui. C'est pour ça que j'ai fini par supprimer "extern" d'extgraph.h - ce qui, vu le nombre de fonctions dans ce header, a gagné 2 ou 3 KB sur la taille du header

Et une variable, non ?

Une variable qui est dans un header n'est pas extern par défaut, en effet.

./48: voilà

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

(cross)
Oui, c’est exactement comme ça qu’il faut faire, cf ce que tu as trouvé toi-même en ./48
En fait, le compilateur considère automatiquement qu’une constante littérale est un nombre (plus précisément un int ou un float si c’est un nombre décimal), tu dois lui préciser s’il s’agit d’autre chose (une adresse, un short, un double, etc.).

(cross²)
C'est normal oui, en général on ne fait pas pointer un truc sur une adresse entière comme ça... ça présage une erreur. Le cas des accès aux IO comme ici est une exception, et c'est pour ça que si tu veux éviter le warning il faut faire le cast.

Sasume (./50) :
En fait, le compilateur considère automatiquement quâ&#x20AC;™une constante littérale est un nombre (plus précisément un int ou un float si câ&#x20AC;™est un nombre décimal), tu dois lui préciser sâ&#x20AC;™il sâ&#x20AC;™agit dâ&#x20AC;™autre chose (une adresse, un short, un double, etc.).

Ok, merci à tous !

Non Lionel, pour le moment je me contente de faire un programme kimarche-based, ça sera déjà bien dans un premier temps Mais bien sûr, ça évolura si j'arrive à faire quelque chose de présentable. Je jouis déjà à l'avance de faire un programme à ma façon, loader + archive en ROM, ça doit être coton niveau compilation pour pas qu'il te foute des relogemenst ou des "optimisations" là où tu veux pas. C'est pour ça que l'assembleur, c'est si facile !

Ah ouais, par contre pour ce genre de bidouillage l’ASM est bien plus pratique…
C’est quoi là ton prog ?

Sasume (./53) :
C'est quoi là ton prog ?

La question à 100 balles

Un éditeur de dessin, en niveaux de gris. Export de PIC, de fichiers de tiles, de sources C/asm dans différents formats. Je vais d'ailleurs demander ailleurs les features qui pourraient être bien.

Au fait, j'utilise Grib, la version que j'ai modifiée. Je suis retombé dessus pas hasard hier, je croyais l'avoir perdue. Tu releases un jour, je le fais, je te repasse la version, bref, on en fait quio ?

Lionel Debroux (./2) :
Pour copier une string, c'est strcpy.

Mais pour copier une string de façon sûre, c'est strncpy

Mais lente, vu qu'il padde la destination...

Et faut s'assurer d'avoir le '\0' final...

Bref, pour copier une string, faut faire une boucle
Brunni > ah oui, j'avais oublié ce détail. Mais est-ce que sprintf est plus rapide du coup ? (sachant qu'il doit d'abord parser son argument...)

en fait perso je n'utilise que sprintf (avec "%.<n>s" où <n> est le nombre max de caractères) ou memcpy, strcpy et strncpy ont toutes deux un fonctionnement idiot

Thepro > oui mais avec strcpy tu dois appeler strlen avant, c'est pas tellement mieux. (Et les conséquences si tu oublies sont a priori pires)

Nan mais là ça va, c'est pas au niveau des possibilités des fonctions que j'ai des soucis (ouhouh les gars, ça fait un paquet d'années que je fais de l'asm ), mais de la syntaxe de ce langage over-compliqué ^^

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 ?

edit -> Ca, c'est la solution propre ?
PlanesPtr = (void *)((long)PlanesPtr & ~7);
C'est pas un peu lourd ? En fait, on passe son temps à tromper le compilateur, alors que ça devrait très bien marcher ...

edit² -> ah oui, et puis on dit que l'asm c'est pas lisible après :
PlanesPtr = ((void *)((long)(PlanesHdPtr + 7) & ~7));
C'est peut-être qu'une question d'habitude, mais perso ce que ça veut dire, ç me saute pas aux yeux.