Une sollution a ce probleme: - Page 1

Voilà, j'ai un registre de n bits à l'adresse @.
je souhaite pouvoir acceder a des registres en C de maniere efficace par tranche de 4 bits sur un proc de 16bits.
exempe:
SR.A=1;
SR.B=2;
SR.C=3;
SR.D=4;
serait equivalent à:
SR=(1<<12) | (2<<8) | (3<<4) | (4);
La seule solution que j'ai trouvée etant de le faire à l'aide de macro. Je cherche neanmoins une solution à base d'enum; car la solution de macro est assez lourde (il faut definir 4*nbr(registres) qui revients a definir plus de 600 macros...). Le probleme intervenant etant aussi le pading du compilo (dont on ne m'a meme pas encore donné la ref, et qui est certainement proprietaire).

ben, il y a sans doute une solution avec les champs de bits (structures dont on spécifie la taille des champs au bit près, mais il y a qualques problèmes avec:
1- Ne pas oublier de déclarer en les champs unsigned (pas mal d'erreurs avec ça)
2- L'implémentation change d'un compilo à l'autre... Sur certains, le champ de bits sera mis dans un certain ordre, sur d'autres, dans l'ordre inverse... Bref, il faudra plonger au fin fond de la doc du compilo pour cela, et si tu ne l'as pas...

C'est quoi le pb avec les macros ?

en gros pas assez optimisé.

gni ?

Bon j'ai des nouvelles, apparement il faut utiliser une specificité du compilateur qui permet comme l'a dit link d'utiliser un champ de bit sur un entier...
unsigned int XXX: 4;
je peux pas en donner plus...

typedef union Byte_ {
unsigned char b0:1;
unsigned char b1:1;
unsigned char b2:1;
unsigned char b3:1;
unsigned char b4:1;
unsigned char b5:1;
unsigned char b6:1;
unsigned char b7:1;
} Byte;

Et la ou l'ordre des bits a le plus de chance de changer, c'est lors d'un passage du code vers du low/high endianess

ou d'un changement de compilo/d'ABI, souvent le choix de l'ordre des bits est complètement arbitraire (i.e. aucun ordre n'est plus efficace qu'un autre), et est donc déterminé par des raisons historiques...

Ce qui est en meme temps completement idiot :/

Ce genre de choses aurais du être fixé par le standard (tout au moins par le C-ANSI aka C89 vu qu'avant ct un bordel monstrueux))

ben pkoi ? le standard n'a pas à imposer à un processeur ternaire de stocker les champs des structures comme des entiers binaires
d'ailleurs on peut parfaitement imaginer un processeur qui serait très lent pour accéder aux champs individuels d'un bitfield, et qui donc les considère comme des structures normales... ou inversement un processeur avec des instructions spéciales de manipulation de bits, mais qui traitent les bits 2 par 2 ou 4 par 4 ^^

si tu veux ton format de stockage à toi pour faire des manipulations spéciales, la solution compatible avec le standard c'est de faire "machin&0x4000" et faire les décalages tout seul comme un grand (sinon rien ne garantit que ton struct{} sera assez court pour tenir dans un entier par exemple)

Oui, mais c'est justement cela qui est idiot, car la principale utilité potentielle des champs de bits aurait été justement le dialogue avec des périphériques, qui eux ont l'habitude d'utiliser des champs de bits qui sont toujours les mêmes ('suffit de voir le registre de contrôle d'un port Com).

Comme ceci est impossible du fait de l'absence de standard, les champs de bits ne sont pratiquement jamais utilisés (je suppose qu'ils le sont dans des systèmes embarqués où la mémoire est rare, et ce doit être pratiquement tout...)

Link: de tte maniere, le pbm des champs de bits sont leur lenteur....

Pollux>
"machin&0x4000"

Plutôt machin & (1<<14) non ? Tu citais l'exemple de machines à trois états logiques ^^

ben 0x4000 est pas un peu égal à 1<<14 ?

Pour une machine à trois états logiques, un & ou un << ne sont peut-être pas des opérations "naturelles", mais ça n'empêche qu'elles sont bien définies et que toutes les manipulations sur des unsigned se font bien modulo une puissance de 2...

Ben un décalage de bits si chaque bit a trois états, ça multiplie par 3.
Et si ça multiplie pas par 3, alors << n'est pas un décalage de bit dans ce cas.

Flemme de regarder dans la norme, mais a priori << est un décalage de bit *binaire* (= multiplication par une puissance de 2)... Sinon à peu près n'importe quel code qui utilise << ne serait pas portable sur ces architectures, donc autant dire que y aurait pas bcp de code rigoureusement standard dans la nature ^^

De même que & est un ET binaire, et que l'addition de deux unsigned int s'effectue modulo une puissance de 2 (définie par l'implémentation). Ca favorise les architectures binaires en termes de performance, mais ça permet au moins que y ait des programmes qui marchent sur les architectures bizarres

>Deux unsigned int s'effectue modulo une puissance de 2 (définie par l'implémentation).

T'es sûr ? Moi non. Je crois que c'est seulement modulo (UINT_MAX+1).

Oui j'en suis certain, mais flemme de chercher là tout de suite ^^

Moi aussi je suis persuade de ce que j'ai dit.

6.2.6.2 Integer types
1 For unsigned integer types other than unsigned char, the bits of the object
representation shall be divided into two groups: value bits and padding bits (there need
not be any of the latter). If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2^(N-1), so that objects of that type shall be capable of
representing values from 0 to 2^N - 1 using a pure binary representation; this shall be known as the value representation. The values of any padding bits are unspecified.

A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the largest value that can be
represented by the resulting type.

^^ (exercice : vérifier si c'est pareil pour C89)

Je crois pas. Je parlais de C89.