Salut, comment peut on définir une structure afin qu'elle fasse pile poil
la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Salut, comment peut on définir une structure afin qu'elle fasse pile poil
la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Salut, comment peut on définir une structure afin qu'elle fasse pile poil
la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Salut, comment peut on définir une structure afin qu'elle fasse pile
poil la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octets alors que je
pensais qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Salut, comment peut on définir une structure afin qu'elle fasse pile
poil la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octets alors que je
pensais qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Salut, comment peut on définir une structure afin qu'elle fasse pile
poil la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octets alors que je
pensais qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Etienne writes:Salut, comment peut on définir une structure afin qu'elle fasse pile poil
la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
La regle systematique la plus simple pour qu'une structure prenne le
moins de place possible, est de mettre les membres dans l'ordre
decroissant de contraintes d'alignement (en pratique, celles-ci sont des
puissances de 2). Mais meme alors, la structure aura une taille
multiple de la plus grande contrainte d'alignement.
Dans ton cas, un pointeur a vraisemblablement une contrainte de 8, donc
ca ne changera rien. Mais tu pouvais faire pire avec
typedef struct
{
unsigned short start;
struct asmScanSprite *next_bloc;
unsigned short end;
struct asmScanSprite *next_line;
} asmScanSprite;
qui aurait eu une taille de 32.
Certains compilateurs ont des moyens (attributs, pragma, ...) pour
indiquer qu'il ne faut pas respecter les contraintes d'alignment, quite
a payer le cout en performance.
Etienne <etienne@tlk.fr> writes:
Salut, comment peut on définir une structure afin qu'elle fasse pile poil
la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
La regle systematique la plus simple pour qu'une structure prenne le
moins de place possible, est de mettre les membres dans l'ordre
decroissant de contraintes d'alignement (en pratique, celles-ci sont des
puissances de 2). Mais meme alors, la structure aura une taille
multiple de la plus grande contrainte d'alignement.
Dans ton cas, un pointeur a vraisemblablement une contrainte de 8, donc
ca ne changera rien. Mais tu pouvais faire pire avec
typedef struct
{
unsigned short start;
struct asmScanSprite *next_bloc;
unsigned short end;
struct asmScanSprite *next_line;
} asmScanSprite;
qui aurait eu une taille de 32.
Certains compilateurs ont des moyens (attributs, pragma, ...) pour
indiquer qu'il ne faut pas respecter les contraintes d'alignment, quite
a payer le cout en performance.
Etienne writes:Salut, comment peut on définir une structure afin qu'elle fasse pile poil
la taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
La regle systematique la plus simple pour qu'une structure prenne le
moins de place possible, est de mettre les membres dans l'ordre
decroissant de contraintes d'alignement (en pratique, celles-ci sont des
puissances de 2). Mais meme alors, la structure aura une taille
multiple de la plus grande contrainte d'alignement.
Dans ton cas, un pointeur a vraisemblablement une contrainte de 8, donc
ca ne changera rien. Mais tu pouvais faire pire avec
typedef struct
{
unsigned short start;
struct asmScanSprite *next_bloc;
unsigned short end;
struct asmScanSprite *next_line;
} asmScanSprite;
qui aurait eu une taille de 32.
Certains compilateurs ont des moyens (attributs, pragma, ...) pour
indiquer qu'il ne faut pas respecter les contraintes d'alignment, quite
a payer le cout en performance.
Salut, comment peut on définir une structure afin qu'elle fasse pile poil la
taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Salut, comment peut on définir une structure afin qu'elle fasse pile poil la
taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Salut, comment peut on définir une structure afin qu'elle fasse pile poil la
taille attendue.
Par exemple
typedef struct
{
unsigned short start;
unsigned short end;
struct asmScanSprite *next_bloc;
struct asmScanSprite *next_line;
} asmScanSprite;
Sur mon linux 64 bit cette structure prend 24 octects alors que je pensais
qu'elle n'en ferai que 20 (2 + 2 + 8 + 8)
Une approche crade, économe en taille mais qui peut être catastrophique
en performances, serait de contraindre un alignement plus petit, 1 ou
2. En Visual C ce serait encadrer le typedef par #pragma pack(push, 2)
et #pragma pack(pop), et obtenir le même résultat sous gcc, avec des
__attributes__ (__packed__) ou un truc comme ça.
Une approche crade, économe en taille mais qui peut être catastrophique
en performances, serait de contraindre un alignement plus petit, 1 ou
2. En Visual C ce serait encadrer le typedef par #pragma pack(push, 2)
et #pragma pack(pop), et obtenir le même résultat sous gcc, avec des
__attributes__ (__packed__) ou un truc comme ça.
Une approche crade, économe en taille mais qui peut être catastrophique
en performances, serait de contraindre un alignement plus petit, 1 ou
2. En Visual C ce serait encadrer le typedef par #pragma pack(push, 2)
et #pragma pack(pop), et obtenir le même résultat sous gcc, avec des
__attributes__ (__packed__) ou un truc comme ça.
In article ,
Pierre Maurette wrote:Une approche crade, économe en taille mais qui peut être catastrophique
en performances, serait de contraindre un alignement plus petit, 1 ou
2. En Visual C ce serait encadrer le typedef par #pragma pack(push, 2)
et #pragma pack(pop), et obtenir le même résultat sous gcc, avec des
__attributes__ (__packed__) ou un truc comme ça.
Deuxieme fois que je vois passer ca.
NON, c'est pas juste catastrophique en performances, c'est surtout non
portable, au point de crasher sur la plupart des architectures.
Il y a surtout Intel qui permet les acces non alignes au prix d'une
performance moindre, mais sur la plupart des processeurs autres, un acces non
aligne conduit tout droit a une fault (et un SIGBUS sur un Unix).
In article <mn.cc717dc6fb802491.79899@free.fr>,
Pierre Maurette <maurette.pierre@free.fr> wrote:
Une approche crade, économe en taille mais qui peut être catastrophique
en performances, serait de contraindre un alignement plus petit, 1 ou
2. En Visual C ce serait encadrer le typedef par #pragma pack(push, 2)
et #pragma pack(pop), et obtenir le même résultat sous gcc, avec des
__attributes__ (__packed__) ou un truc comme ça.
Deuxieme fois que je vois passer ca.
NON, c'est pas juste catastrophique en performances, c'est surtout non
portable, au point de crasher sur la plupart des architectures.
Il y a surtout Intel qui permet les acces non alignes au prix d'une
performance moindre, mais sur la plupart des processeurs autres, un acces non
aligne conduit tout droit a une fault (et un SIGBUS sur un Unix).
In article ,
Pierre Maurette wrote:Une approche crade, économe en taille mais qui peut être catastrophique
en performances, serait de contraindre un alignement plus petit, 1 ou
2. En Visual C ce serait encadrer le typedef par #pragma pack(push, 2)
et #pragma pack(pop), et obtenir le même résultat sous gcc, avec des
__attributes__ (__packed__) ou un truc comme ça.
Deuxieme fois que je vois passer ca.
NON, c'est pas juste catastrophique en performances, c'est surtout non
portable, au point de crasher sur la plupart des architectures.
Il y a surtout Intel qui permet les acces non alignes au prix d'une
performance moindre, mais sur la plupart des processeurs autres, un acces non
aligne conduit tout droit a une fault (et un SIGBUS sur un Unix).
Deuxieme fois que je vois passer ca.
NON, c'est pas juste catastrophique en performances, c'est surtout non
portable, au point de crasher sur la plupart des architectures.
Deuxieme fois que je vois passer ca.
NON, c'est pas juste catastrophique en performances, c'est surtout non
portable, au point de crasher sur la plupart des architectures.
Deuxieme fois que je vois passer ca.
NON, c'est pas juste catastrophique en performances, c'est surtout non
portable, au point de crasher sur la plupart des architectures.
> Deuxieme fois que je vois passer ca.
> NON, c'est pas juste catastrophique en performances, c'est surtout
> non portable, au point de crasher sur la plupart des architectures.
Tu es sûr ? Je croyais que quand on accédait à un champ d'une
structure "compactée" sur une telle architecture, gcc générait
explicitement le code pour lire (de façon alignée) le début et la fin
du champ et le reconstruire.
> Deuxieme fois que je vois passer ca.
> NON, c'est pas juste catastrophique en performances, c'est surtout
> non portable, au point de crasher sur la plupart des architectures.
Tu es sûr ? Je croyais que quand on accédait à un champ d'une
structure "compactée" sur une telle architecture, gcc générait
explicitement le code pour lire (de façon alignée) le début et la fin
du champ et le reconstruire.
> Deuxieme fois que je vois passer ca.
> NON, c'est pas juste catastrophique en performances, c'est surtout
> non portable, au point de crasher sur la plupart des architectures.
Tu es sûr ? Je croyais que quand on accédait à un champ d'une
structure "compactée" sur une telle architecture, gcc générait
explicitement le code pour lire (de façon alignée) le début et la fin
du champ et le reconstruire.
Plus de détails ici :
http://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe
Et une discussion plus technique sur certains aspects du problème là :
http://gcc.gnu.org/bugzilla/show_bug.cgi?idQ628
Plus de détails ici :
http://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe
Et une discussion plus technique sur certains aspects du problème là :
http://gcc.gnu.org/bugzilla/show_bug.cgi?idQ628
Plus de détails ici :
http://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe
Et une discussion plus technique sur certains aspects du problème là :
http://gcc.gnu.org/bugzilla/show_bug.cgi?idQ628
Etienne writes:
Dans ton cas, un pointeur a vraisemblablement une contrainte de 8, donc
ca ne changera rien. Mais tu pouvais faire pire avec
typedef struct
{
unsigned short start;
struct asmScanSprite *next_bloc;
unsigned short end;
struct asmScanSprite *next_line;
} asmScanSprite;
qui aurait eu une taille de 32.
Certains compilateurs ont des moyens (attributs, pragma, ...) pour
indiquer qu'il ne faut pas respecter les contraintes d'alignment, quite
a payer le cout en performance.
Etienne <etienne@tlk.fr> writes:
Dans ton cas, un pointeur a vraisemblablement une contrainte de 8, donc
ca ne changera rien. Mais tu pouvais faire pire avec
typedef struct
{
unsigned short start;
struct asmScanSprite *next_bloc;
unsigned short end;
struct asmScanSprite *next_line;
} asmScanSprite;
qui aurait eu une taille de 32.
Certains compilateurs ont des moyens (attributs, pragma, ...) pour
indiquer qu'il ne faut pas respecter les contraintes d'alignment, quite
a payer le cout en performance.
Etienne writes:
Dans ton cas, un pointeur a vraisemblablement une contrainte de 8, donc
ca ne changera rien. Mais tu pouvais faire pire avec
typedef struct
{
unsigned short start;
struct asmScanSprite *next_bloc;
unsigned short end;
struct asmScanSprite *next_line;
} asmScanSprite;
qui aurait eu une taille de 32.
Certains compilateurs ont des moyens (attributs, pragma, ...) pour
indiquer qu'il ne faut pas respecter les contraintes d'alignment, quite
a payer le cout en performance.