Discussion :

[Tchetch]

Bonjour,

Je vais faire simple, j'ai la structure suivante :

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
struct ffb_init0 {
    unsigned long long fileID; /* 48 bits */
    unsigned short clientID; /* 16 bits */
    unsigned long long blockNumbers; /* use only 45 bits */
    unsigned long packetNumbers; /* 32 bits */
    unsigned long long magicValue; /* 64 bits */
    unsigned long long fileHash[4]; /* at least 512 bits */
    unsigned char hashMethod; /* 8 bits */
    unsigned char protocolVersion; /* use only 4 bits */
    unsigned long long fileTime; /* use only 48 bits, hold unixtime */
    unsigned long long dataBlockPayload; /* 64 bits */
    unsigned char hasMetadata; /* 1 bit */
    unsigned char uft8Filename[69]; /* 552 bits for utf8 filename */
    /* 6 bits left to pad at 0x0 */
};

Je veux la convertir en tableau de bits, alors j'ai commencé comme suit :

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
    unsigned char barr_p[175];
 
    /* FileID */
    barr_p[0] = (p->fileID >> 40) & 0xff;
    barr_p[1] = (p->fileID >> 32) & 0xff;
    barr_p[2] = (p->fileID >> 24) & 0xff;
    barr_p[3] = (p->fileID >> 16) & 0xff;
    barr_p[4] = (p->fileID >> 8) & 0xff;
    barr_p[5] = p->fileID & 0xff;
 
    /* clientID */
    barr_p[6] = (p->clientID >> 8) & 0xff;
    barr_p[7] = p->clientID  & 0xff;
 
 
    /* blockNumbers */
    barr_p[8] = (p->blockNumbers >> 37) & 0xff;
    barr_p[9] = (p->blockNumbers >> 29) & 0xff
    barr_p[10] = (p->blockNumbers >> 21) & 0xff;
    barr_p[11] = (p->blockNumbers >> 13) & 0xff;
    barr_p[12] = (p->blockNumbers >> 5) & 0xff;
    /* Start to mix data in a byte as blockNumbers is 45 bits, so 3 bits are
     * used in the last byte and so we have to complete with the five bits of
     * the next value in the structure.
     */
    barr_p[13] = (((p->blockNumbers << 3) & 0xff) +
            ((p->packetNumbers >> 29) & 0xff)) & 0xff;
    barr_p[14] = (p->packetNumbers >> 21) & 0xff;
    barr_p[15] = (p->packetNumbers >> 13) & 0xff;
    barr_p[16] = (p->packetNumbers >> 5) & 0xff;

Le problèmes est bien le suivant, j'ai 175 cases de tableaux à remplir comme ça, avec un décalage (champs 45 bits), et je me demandais si quelqu'un a juste une idée pour automatiser un peu ça.

[jowo]

Bonjour,

On pourrait utiliser une macro pour "alléger" la lecture

(non testé)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
 
#define EXTRACTBIT(f,nb) ((f) >> (nb) & 0xff)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
    unsigned char barr_p[175];
 
    /* FileID */
    barr_p[0] = EXTRACTBIT(p->fileID, 40);
    barr_p[1] = EXTRACTBIT(p->fileID, 32);
    barr_p[2] = EXTRACTBIT(p->fileID, 24);
    barr_p[3] = EXTRACTBIT(p->fileID, 16);
    barr_p[4] = EXTRACTBIT(p->fileID, 8) ;
    barr_p[5] = EXTRACTBIT(p->fileID, 0);
 
    /* clientID */
    ....

Ce ne sont que 175 lignes....

Petite remarque: Tu utilises l'opérateur + pour combiner deux champs, pour ma part j'utiliserai plutôt le OU Logique |

[Médinoc]

Avec un truc de ce genre:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/* Sérialisation d'entier 64 bits "unchecked" */
void SerializeU64_u(unsigned char *pbuffer, size_t *pIndex, unsigned long long u64)
{
	/* Note: On peut aussi faire une boucle */
	pBuffer[(*pIndex)++] = (u64 >> 56) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 48) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 40) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 32) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 24) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 16) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >>  8) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >>  0) & 0xff;
}
 
/* Sérialisation d'entier 64 bits */
int SerializeU64(unsigned char *pbuffer, size_t *pIndex, unsigned long long u64, size_t tailleBuffer)
{
	const size_t TAILLE = sizeof u64;
	/* --- Contrôle des paramètres --- */
	/* pIndex n'est jamais nul, en C++ ce serait une référence */
	assert(pIndex != NULL);
	/* Buffer nul+taille nulle: Calcul de la taille nécessaire */
	if(pBuffer == NULL && tailleBuffer == 0)
	{
		(*pIndex) += TAILLE;
		return 0;
	}
	/* Buffer nul ou insuffisant: Erreur */
	if(pBuffer == NULL)
		return -1;
	if((*pIndex) + TAILLE > tailleBuffer)
		return -1;
 
	SerializeU64_u(pBuffer, pIndex, u64);
	return 0;
}
 
/* Etc. */

Et tu appelles les bonnes fonctions pour les bons membres de la structure.

[Tchetch]

Ouais la macro, c'est clair, j'y ai même pas pensé ...

Ce ne sont que 175 lignes....

J'ai plusieurs structures au final.

Petite remarque: Tu utilises l'opérateur + pour combiner deux champs, pour ma part j'utiliserai plutôt le OU Logique |

Juste, merci.

Et tu appelles les bonnes fonctions pour les bons membres de la structure.

J'y ai pensé, mais le problème est à partir du décalage. Je penses peut-être faire d'abord des morceaux de 64 bits (unsigned long long) à l'aide d'une fonction générique du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
unsigned long long (unsigned long long val1, int startVal1, int lenVal1, ...) {
}

Et ensuite je peux rassembler ces morceaux en gros bloc de 1400 bits ... Ce serait une solution ...

[Médinoc]

Ah, je vois, c'est un tableau de bits qu'il te faut et non d'octets...
Enfin, tu peux sûrement faire à peu près la même chose.
Essaie de te faire une fonction générique de ce genre:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

void CopyBits(unsigned char *dest, size_t iBitDest, unsigned char const *src, size_t iBitSrc, size_t nBits);

Et bien sûr, optimisée pour éviter de copier les bits un par un.

[souviron34]

Je veux la convertir en tableau de bits, alors j'ai commencé comme suit :
..
Le problèmes est bien le suivant, j'ai 175 cases de tableaux à remplir comme ça, avec un décalage (champs 45 bits), et je me demandais si quelqu'un a juste une idée pour automatiser un peu ça.

...
J'y ai pensé, mais le problème est à partir du décalage. Je penses peut-être faire d'abord des morceaux de 64 bits (unsigned long long) à l'aide d'une fonction générique du genre :
..
Et ensuite je peux rassembler ces morceaux en gros bloc de 1400 bits ... Ce serait une solution ...

D'après le contenu de la structure, es-tu sûr que ce soit des tableaux de bits que tu veuilles ?

et non avoir en entrée un tableau de unsigned char (lecture du buffer envoyé/reçu), et le décomposer suivant les paramètres des structures ?

Si c'est le cas, j'aurais plutôt tendance à avoir quelque chose comme :

Decode_Int ( adr, offset, longueur, &i );
Decode_Float ( adr, offset, longueur, &fl );
....

adr étant l'adresse d'un octet, offset le nombre de bits de décalage, longueur le nombre de bits où la varaible est stockée, et ensuite l'adresse où stocker...

(certains formats compressés sont faits comme ça)

[Tchetch]

Ah, je vois, c'est un tableau de bits qu'il te faut et non d'octets...

Je change le boutisme de mes valeurs. Donc c'est au niveau des octets. Je crois qu'il faut que je prenne le problème différemment :

- Changer le boutisme de toute la structure
- Empaqueter sans espacement d'alignement.

Je vais faire ça je crois, c'est plus logique en fait.

[souviron34]

il y a les fonctions

htonl htons etc etc et leurs inverses ntohl ntohs ... (Host To Netwrok et Network To Host)

[Médinoc]

Si tu fais juste un tableau d'octets, tu peux utiliser des fonctions comme celles que je t'ai conseillées (et que souviron34 a également conseillé).
La fonction échantillon que t'ai montré fait ça pour un nombre 64 bits, puis il faut en faire pour les 32, 16, 8 bits...

[Tchetch]

Voilà, je vais utiliser un truc comme ça et juste gérer les croisement, ça devrait fonctionner

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
#define ffbMASK(x) (x & 0xff)
#define ffbXR(a,n)  (ffbMASK((a >> n)))
#define ffbXL(a,n)  (ffbMASK((a << n)))
#define ffbMIX(a, b) (((a) & 0xff) | ((b) & 0xff))
 
inline void __ffb_doBoringStuff(unsigned long long x, BARR_TYPE * barr_p,
        unsigned int xLen)
{
    int i = 0;
 
    for(i = xLen; i >= 8; i-=8) {
        *barr_p = ffbXR(x, i);
        barr_p++;
    }
    return;
}

[Médinoc]

Donc finalement, c'est à l'échelle du bit ou de l'octet?
Tu m'as dit une chose et son contraire...

Franchement, pour moi, le mieux est de faire champ par champ.
Tu fais des fonctions Serialize_u64, Serialize_u48 si tu veux, Serialize_u32, Serialize_u16, Serialize_u8, et enfin une fonction Serialize_ffb_init...

[Tchetch]

Tu fais des fonctions Serialize_u64, Serialize_u48 si tu veux, Serialize_u32, Serialize_u16, Serialize_u8, et enfin une fonction Serialize_ffb_init...

Et pour les valeurs qui ne sont pas divisible par un octet (45 bits, 1 bit, ...) ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
       tab[x]       tab[x+1]
   |            |            | 
111 10000    111 10000   1111 0000
+++++++++    ++++++++++  ++++++++++
+s->val1     +s->val2    +s->val3

[Médinoc]

Donc, c'est bien un tableau de bits qu'il te faut et pas un tableau d'octets!
C'est à l'échelle du bit que tu dois gérer tout ça, donc mes propositions de sérialisation ne marchent pas, sauf celle pour une fonction CopyBits().

Pas facile de bosser avec quelqu'un qui se contredit sur les specs...

[Tchetch]

Dans un premier temps, on travail au niveau de l'octet pour avoir du gros-boutiste, mais on a pas d'espacement. Donc quand on a 45 bits, on va chercher 3 bit dans le nombre suivant pour compléter le dernier octet et on change le boutisme sur 48 bits.

Donc oui on travail au niveau de l'octet, mais il n'y a pas toutes les valeurs qui sont des multiples de 8, donc dans ces cas là, on va compléter la valeur et la traiter ensuite.

[souviron34]

je crois qu'il y a un problème de fond dans l'expression du besoin....


Je ne sais pas quel est le problème de fond.

Je mentionnais tout à l'heure une technique , utilisée par exemple pour les gros fichiers binaires de la météo (les modèles numériques compressés)(GRIB pour ceux qui veulent se rensiegner).

On lit par exemple le fichier d'un coup, comme un buffer de unsigned char.

Là dedans, le protocole dit que c'est fait de plusieurs structures, comme tu les déclares là-haut. Sauf qu'il donne une table de correspondance disant : "ça c'est un int codé sur 1 octet. ça c'est un réel codé sur 14 bits, suivi d'un int codé sur 6 bits, suivi d'un int codé sur 9 bits, etc etc.."

Pour fabriquer (et décoder) ces fichiers, c'est en fait une suite ininterrompue de bits. MAIS ce n'est pas en l'interprétant sous forme de tableaux de bits qu'on s'en sortira.

Il faut prendre la spec, le buffer de unsigned char, et démarrer :

adresse 0 : 8 bits.=> transformer 8 bits en un int
adresse 0 + 8 : => transformer 14 bits en un float
adresse 0 + 8 + 14 => transformer 6 bits en un int
adresse 0 + 8 + 14 + 6 => transformer 9 bits en un int

Ce dont je parlais tout à l'heure, c'était un truc comme ça...

(adr était le début de l'octet en cours, offset était le nombre de bits où commence le nombre , longueur était le nombre de bits représentant le nombre (les nombres sont souvent à cheval sur plusieurs octets)).

Je n'ai jamais vu un truc aussi compact.

Mais cela implique , comme le disait Médinoc, des routines de "base", c'est à dire disposer de 4 (ou 2) octets en mémoire, et faire des shifts et copies de bits pour transformer suivant le protocole.

Je ne sais pas si c'est cela que tu veux dire, ou si c'est bêtement faire aller d'un certain ordre à un autre, auquel cas les fonctions htonl ... font le travail toutes seules...

[Tchetch]

Il existe plein de protocole d'encodage binaire (comme XDR, CDF, ...) mais là ce n'est pas le problème. Le problème de fond était de convertir une structure donnée dans une série de bits sans le "padding" et en "big-endian".
Ici le format est défini. C'est pas du XDR, pas du CDF, pas du GRIB, pas du HDF ...

[souviron34]

Le problème de fond était de convertir une structure donnée dans une série de bits sans le "padding" et en "big-endian".
Ici le format est défini.

Et ???

C'est pas ce que je mentionne ????

SANS "padding".... de bits...

Car si tu veux écrire juste la suite des éléments de la structure, la manière portable de le faire (que ce soit little ou big endian) est de se servir des fonctions faites pour (htons et ntohs par exemple).

[Médinoc]

Le problème, c'est que les htonX seuls ne suffisent pas, car il faut en plus les décalages de bits.

(D'ailleurs, les htonX sont moins portables que le faire soi-même (par décalages), car à ma connaissance, ils ne sont pas standard C mais POSIX. Bien sûr, sur un PC on s'en moque...)

[souviron34]

Le problème, c'est que les htonX seuls ne suffisent pas, car il faut en plus les décalages de bits.

C'est là que je ne comprends pas...

SI il doit y avoir un flux continu de bits SANS paddings de bits, alors oui, mais il faut un protocole décrivant (comme je l'ai mentionné plus haut), la structure, car il est à priori impossible de savoir si un int sera codé sur 4, 7, 9, ou 13 bits, et où commencera l'élément suivant de la structure.

SI le "non-padding" s'applique au fait que les éléments se suivent sans tenir compte d'un éventuel padding de la structure, il n'y a aucun besoin de faire de shift de bits, les frontières tombant sur des octets..

[Médinoc]

Si j'ai bien compris, il doit bel et bien sérialiser la structure sous forme d'un flux continu de bits sans padding entre. Le protocole est décrit dans les commentaires sur la structure: Il y est indiqué qu'un des entiers ne fait que quatre bits, notamment.