tigcc c trop fort! - Page 1

ben ue... je met ca avec la derniere beta (0.94 qquechose):

struct vertex_3i
{
  int x;
  int y;
  int z;
};

struct vertex_3s
{
  short x;
  short y;
  short z;
};

struct vertex_2c
{
  char u;
  char v;
};

struct BSP_vertex_t
{
  vertex_3i coord;
  vertex_2c texture_coord;
  vertex_3s normal;
};

et j'ai un beau parse error a la premiere utilisation d'une struct dans une autre struct, cad ici:

struct BSP_vertex_t
{
[b][4]>>>[/4][/b]  vertex_3i coord;
  vertex_2c texture_coord;
  vertex_3s normal;
};

c super hein? du coup je peux rien faire... merci tigcc

Not a bug.

Le C n'est pas du C++.

Syntaxe correcte A:

struct vertex_3i
{
  int x;
  int y;
  int z;
};

struct vertex_3s
{
  short x;
  short y;
  short z;
};

struct vertex_2c
{
  char u;
  char v;
};

struct BSP_vertex_t
{
  [b]struct[/b] vertex_3i coord;
  [b]struct[/b] vertex_2c texture_coord;
  [b]struct[/b] vertex_3s normal;
};

Sytaxe correcte B:

[b]typedef[/b] struct
{
  int x;
  int y;
  int z;
} vertex_3i;

[b]typedef[/b] struct
{
  short x;
  short y;
  short z;
} vertex_3s;

[b]typedef[/b] struct
{
  char u;
  char v;
} vertex_2c;

struct BSP_vertex_t
{
  vertex_3i coord;
  vertex_2c texture_coord;
  vertex_3s normal;
};

Fais ton choix.

non, j'ai deja essaye les typedef struct, et niet... y me met un truc du genre c inutile...

Ce n'est clairement pas inutile. Peut-être que tu n'as pas mis le typedef correctement. Fais un copier-coller de mon exemple B et tu verras que ça passe.

et pis g jamais dit que ct un bug...
court extrait des encore plus nombreux msg d'erreur avec typedef:

"useless keyword or type name in empty declaration"
et encore les memes parse error

erf... on peut pas mettre le nom de la struct apres typedef struct????

y fo le mettre avant le ; ????

meuuuuhhhh.....

C'est que tu dois mettre le nom de la structure après la structure si tu utilises typedef!
Fais un copier-coller de mon exemple, bon sang! Je suis sûr à 100% qu'il marche parce que je viens d'essayer.

sBibi a écrit :
erf... on peut pas mettre le nom de la struct apres typedef struct????
y fo le mettre avant le ; ????

Exact.

g pas copie colle, mais effectivement en le mettant apres, ca marche... rhalala... voila ce ke c les compilos genre Borland ou vc++, on croit coder en C, et en fait c du c++.......

bon, bah merci...
topic clos

koike ca me stresse d'avoir le nom des struct a la fin de la struct...
v plutot prendre la premiere solution...

Il y a aussi cette méthode-là:

struct vertex_3i
{
  int x;
  int y;
  int z;
};

struct vertex_3s
{
  short x;
  short y;
  short z;
};

struct vertex_2c
{
  char u;
  char v;
};

typedef struct vertex_3i vertex_3i;
typedef struct vertex_3c vertex_3c;
typedef struct vertex_2c vertex_2c;

struct BSP_vertex_t
{
  vertex_3i coord;
  vertex_2c texture_coord;
  vertex_3s normal;
};

et puis la méthode barbare:

struct vertex_3i
{
  int x;
  int y;
  int z;
};

struct vertex_3s
{
  short x;
  short y;
  short z;
};

struct vertex_2c
{
  char u;
  char v;
};

#define vertex_3i struct vertex_3i
#define vertex_3c struct vertex_3c
#define vertex_2c struct vertex_2c

struct BSP_vertex_t
{
  vertex_3i coord;
  vertex_2c texture_coord;
  vertex_3s normal;
};

ue, bah le #define, c pa la peine et l'autre non plus, ca surcharge le code pr rien.. la premiere est tres bien

struct machin
{
};

struct truc
{
struct machin bidule;
};

marchi ca marche bien maintenant

tien, bah pdt qu'on y est....

struct BSP_face_t
{
  byte							texture_ID;   // texture_index
  byte							type; // type (FACE_POLYGON == polygon, FACE_PATCH == bezier patch)
  byte							color;        // face color
  short							vertex_index[3]; // verts indices
  struct vertex_3i	normal;       // face normal vector
};

struct BSP_face_t	BSP_face[] = {
{0,0,0,0,1,2,{0,0,0}},  // {texture_ID,type,color,vert_1,vert_2,vert_3,{nx,ny,nz}}
{0,0,0,2,3,0,{0,0,0}},
{0,0,0,0,1,5,{0,0,0}},
{0,0,0,5,4,0,{0,0,0}},
{0,0,0,1,2,6,{0,0,0}},
{0,0,0,6,5,1,{0,0,0}},
{0,0,0,0,3,7,{0,0,0}},
{0,0,0,7,4,0,{0,0,0}},
{0,0,0,7,6,5,{0,0,0}},
{0,0,0,5,4,7,{0,0,0}},
{0,0,0,3,2,6,{0,0,0}},
{0,0,0,6,7,3,{0,0,0}}
};

ca ca me donne un warning:
"Missing braces around initializer (near initialization for 'BSP_face[0].vertex_index')"

pourquoi?
ca a l'air bon ca pourtant...

heu, g mis un #define byte unsigned char

et y me met le curseur ici:

struct BSP_face_t BSP_face[] = {
{0,0,0,0ici,1,2,{0,0,0}}, // {texture_ID,type,color,vert_1,vert_2,vert_3,{nx,ny,nz}}
{0,0,0,2,3,0,{0,0,0}},
{0,0,0,0,1,5,{0,0,0}},
{0,0,0,5,4,0,{0,0,0}},
{0,0,0,1,2,6,{0,0,0}},
{0,0,0,6,5,1,{0,0,0}},
{0,0,0,0,3,7,{0,0,0}},
{0,0,0,7,4,0,{0,0,0}},
{0,0,0,7,6,5,{0,0,0}},
{0,0,0,5,4,7,{0,0,0}},
{0,0,0,3,2,6,{0,0,0}},
{0,0,0,6,7,3,{0,0,0}}
};

Missing braces around initializer, ça veut dire ce que ça veut dire.

struct BSP_face_t	BSP_face[] = {
{0,0,0,[b]{[/b]0,1,2[b]}[/b],{0,0,0}},  // {texture_ID,type,color,[b]{[/b]vertex_index[0],vertex_index[1],vertex_index[2][b]}[/b],{nx,ny,nz}}
{0,0,0,[b]{[/b]2,3,0[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]0,1,5[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]5,4,0[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]1,2,6[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]6,5,1[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]0,3,7[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]7,4,0[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]7,6,5[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]5,4,7[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]3,2,6[b]}[/b],{0,0,0}},
{0,0,0,[b]{[/b]6,7,3[b]}[/b],{0,0,0}}
};

ben j'avais bien compris ce que ca veut dire... mais pkoi il les faut la???
c pas juste autour des sous-structures?

C'est aussi autour des tableaux.

merde alors... bah pourtant c comme si on faisait

struct BSP_face_t
{
byte texture_ID;
byte type;
byte color;
short vertex_index0;
short vertex_index1;
short vertex_index2;
struct vertex_3i normal;
};

a moins ke ca soit l'asm ki me perturbe...

heu, pis tant qu'a faire, g un autre truc zarb... y me met right shift count >= width of type... et j'ai un truc du genre:

(((cos_roll * cos_yaw) << 6) - (srsp * sin_yaw)) >> 16;

c'est tout des shorts, et je le mets dans un short...

en asm, le >> 16, j'aurai fait un swap et recopie uniquement la partie basse du long dans le word... c pas possible de faire ca en C?

Non. GCC est censé optimiser ça tout seul.
Mais le problème du "shift count" trop gros, c'est que les calculs sont tous faits en short. Ce qu'il te faut:
((((long)cos_roll * (long)cos_yaw) << 6) - ((long)srsp * (long)sin_yaw)) >> 16;

sBibi a écrit :
merde alors... bah pourtant c comme si on faisait

struct BSP_face_t
{
byte texture_ID;
byte type;
byte color;
short vertex_index0;
short vertex_index1;
short vertex_index2;
struct vertex_3i normal; };

Le résultat est le même, mais pas la syntaxe.

Le résultat est le même, mais pas la syntaxe. > ok

>Non. GCC est censé optimiser ça tout seul.
>Mais le problème du "shift count" trop gros, c'est que les calculs sont tous faits en short. Ce qu'il te faut:
>((((long)cos_roll * (long)cos_yaw) << 6) - ((long)srsp * (long)sin_yaw)) >> 16;

de tte facon, j'ai change en:

register int srsp;
register int crsp;
register int temp;

temp = (((cos_roll * cos_yaw) << 6) - (srsp * sin_yaw)) << 2;
matrix[m11] = temp >> 16;

bon, et la ca le remet.... meme si je fais

matrix[m11] = (int)(temp >> 16);

ca fait pareil...

hmmmm..... les int sur ti correspondraient pas aux short par hazard?

et merde... sur pc c l'equivalent des longs Ti, je pensais ke ct pareil la...

g tout change en

register long srsp;
register long crsp;
register long temp;

et la ca marche lol...

C'est correct, mais la solution des transtypages est meilleure parce que GCC peut optimiser ça. Par exemple:

volatile short var1,var2,var3;
var3=((long)var1*(long)var2+(long)var1*(long)var2)/32;

donne:

move.w -2(%a6),%d2
move.w -4(%a6),%d0
muls.w %d0,%d2
move.w -2(%a6),%d0
move.w -4(%a6),%d1
muls.w %d1,%d0
add.l %d0,%d2
jbpl .L2
moveq.l #31,%d0
add.l %d0,%d2
.L2:
asr.l #5,%d2
move.w %d2,-6(%a6)

alors que:

volatile long var1,var2,var3;
var3=(var1*var2+var1*var2)/32;

donne:

move.l -4(%a6),%d1
move.l -8(%a6),%d0
lea __mulsi3,%a2
move.l %d0,-(%sp)
move.l %d1,-(%sp)
jbsr (%a2)
addq.l #8,%sp
move.l %d0,%d3
move.l -4(%a6),%d1
move.l -8(%a6),%d0
move.l %d0,-(%sp)
move.l %d1,-(%sp)
jbsr (%a2)
addq.l #8,%sp
add.l %d0,%d3
jbpl .L2
moveq.l #31,%d0
add.l %d0,%d3
.L2:
asr.l #5,%d3
move.l %d3,-12(%a6)

ce qui est beaucoup plus lent.
(Remarque l'utilisation de l'instruction muls dans le premier cas, et l'appel à la fonction __mulsi3 dans le deuxième cas.)

(Les volatile ne sont là que pour éviter que GCC supprime tout le code en optimisant.)

PS: jackiechan reconnaîtra les exemples que je lui ai envoyés par mini-message aujourd'hui.

ok

volatile evite que gcc supprime tout le code en optimisant????
cad supprime tout le code?

Dans mon exemple, les variables ne sont utilisées nulle part par la suite. Normalement, l'optimiseur de GCC reconnaît ça, voit que le code ne fait rien du tout, et supprime tout. C'est pour ça que j'ai mis volatile.

ah ok d'accord...

heu, dis alors si il fait ca...
g mis ca dans mon code pr le ralentir:

long i;
float a;
for (i = 0; i < 50000; i++)
{
a = i / 100.3;
a *= 1.5;
}

et pourtant la variable a est utilisee nulle part par la suite, mais ca ralentit quand meme, pkoi ca le supprime pas alors ca, vu que c'est utilise nulle part?

Les optimisateurs parfaits n'existent pas.