Padding dans un record

[Frédéric Praca]

Bonjour les gens,
dans le cadre de certains développement bas-niveau, j'ai été confronté à
la création records représentant les registres d'un processeur.
Mon problème est le suivant.
Dans certains cas, il y a des "trous" :)
En clair, certains registres contiennent des zones réservées dans
lesquelles on n'intervient pas. Exemple :
type GPIO_Register is record
MODER : MODER_IOs := (others => GPIO.Mode_AN);
OTYPER : OTYPER_IOs := (others => GPIO.Type_PP);
RESERVED : Bits_16 := 16#0000#; -- Always 0
OSPEEDR : OSPEEDR_IOs := (others => GPIO.Speed_4MHz);
PUPDR : PUPDR_IOs := (others => GPIO.No_Pull);

IDR : Inputs := (others => False);
RESERVED_IDR : Bits_16 := 12#0000#;

ODR : Outputs := (others => False);
RESERVED_ODR : Bits_16 := 16#0000#;

BSRR : Word := 16#0000#;

LCKR : LCKn := (others => False);
LCKK : Boolean := False;

AFRL : Bits_8x4 := (others => GPIO.AF_USART1);
AFRH : Bits_8x4 := (others => GPIO.AF_USART1);
end record;

N'y a-t-il pas un meilleur moyen de faire sachant que l'utilisation de
clauses de représentation spécifiant des zones plus grandes que
nécessaires retourne un warning de type "unused bits" ?

Merci de vos éclaircissements

Fred

[J-P. Rosen]

Post by Frédéric Praca
Bonjour les gens,
dans le cadre de certains développement bas-niveau, j'ai été confronté à
la création records représentant les registres d'un processeur.
Mon problème est le suivant.
Dans certains cas, il y a des "trous" :)
En clair, certains registres contiennent des zones réservées dans
type GPIO_Register is record
MODER : MODER_IOs := (others => GPIO.Mode_AN);
OTYPER : OTYPER_IOs := (others => GPIO.Type_PP);
RESERVED : Bits_16 := 16#0000#; -- Always 0
OSPEEDR : OSPEEDR_IOs := (others => GPIO.Speed_4MHz);
PUPDR : PUPDR_IOs := (others => GPIO.No_Pull);
IDR : Inputs := (others => False);
RESERVED_IDR : Bits_16 := 12#0000#;
ODR : Outputs := (others => False);
RESERVED_ODR : Bits_16 := 16#0000#;
BSRR : Word := 16#0000#;
LCKR : LCKn := (others => False);
LCKK : Boolean := False;
AFRL : Bits_8x4 := (others => GPIO.AF_USART1);
AFRH : Bits_8x4 := (others => GPIO.AF_USART1);
end record;
N'y a-t-il pas un meilleur moyen de faire sachant que l'utilisation de
clauses de représentation spécifiant des zones plus grandes que
nécessaires retourne un warning de type "unused bits" ?

Hmmm... je ne vois pas bien le problème.
1) On peut laisser des trous dans une clause de représentation (i.e. les
composants n'ont pas besoin d'être consécutifs)

2) Il peut être préférable (pour coller à la description hard) de faire
des composants "reserved", et effectivement cela parait logique d'en
faire des tableaux de bits. La question est de savoir si on peut écrire
dedans ou pas en cas d'affectation globale.

3) Un warning n'est pas gênant: le compilateur signale qu'il y a des
bits inutilisés, si c'est vrai, pourquoi pas?

[Frédéric Praca]

Bonsoir Jean-Pierre,

Post by J-P. Rosen

Post by Frédéric Praca
Bonjour les gens,
dans le cadre de certains développement bas-niveau, j'ai été confronté
à la création records représentant les registres d'un processeur.
Mon problème est le suivant.
Dans certains cas, il y a des "trous" :)
En clair, certains registres contiennent des zones réservées dans
type GPIO_Register is record
OTYPER_IOs := (others => GPIO.Type_PP); RESERVED : Bits_16 :=
16#0000#; -- Always 0 OSPEEDR : OSPEEDR_IOs := (others =>
GPIO.Speed_4MHz);
PUPDR : PUPDR_IOs := (others => GPIO.No_Pull);
IDR : Inputs := (others => False);
RESERVED_IDR : Bits_16 := 12#0000#;
ODR : Outputs := (others => False);
RESERVED_ODR : Bits_16 := 16#0000#;
BSRR : Word := 16#0000#;
LCKR : LCKn := (others => False);
LCKK : Boolean := False;
Bits_8x4 := (others => GPIO.AF_USART1);
end record;
N'y a-t-il pas un meilleur moyen de faire sachant que l'utilisation de
clauses de représentation spécifiant des zones plus grandes que
nécessaires retourne un warning de type "unused bits" ?

Hmmm... je ne vois pas bien le problème.
1) On peut laisser des trous dans une clause de représentation (i.e. les
composants n'ont pas besoin d'être consécutifs)

Bon, ben, oui forcément, vu comme ça... Je ne sais pas trop pourquoi je
voulais absolument remplir toute la zone mémoire :)

Post by J-P. Rosen
2) Il peut être préférable (pour coller à la description hard) de faire
des composants "reserved", et effectivement cela parait logique d'en
faire des tableaux de bits. La question est de savoir si on peut écrire
dedans ou pas en cas d'affectation globale.

Alors, d'après la doc, par exemple, après le champ OTYPER, il y a 16 bits
réservés qui doivent être à la valeur de reset ("Bits 31:16 Reserved,
must be kept at reset value"). Du coup, j'aurais tendance à dire qu'on
n'y touche jamais.
Maintenant, d'un point de vue lisibilité du code et maintenabilité, peut-
être est-il effectivement plus intéressant de laisser les champs
réservés ?

Post by J-P. Rosen
3) Un warning n'est pas gênant: le compilateur signale qu'il y a des
bits inutilisés, si c'est vrai, pourquoi pas?

En fait, si, c'est gênant vu que les options de compilation traitent les
warnings en erreurs. En plus, je n'aime pas les warnings ;)

Donc une fois de plus, merci pour la réponse et la rapidité pour la faire.

Fred

[J-P. Rosen]

Post by Frédéric Praca

Post by J-P. Rosen
2) Il peut être préférable (pour coller à la description hard) de faire

Post by J-P. Rosen
des composants "reserved", et effectivement cela parait logique d'en
faire des tableaux de bits. La question est de savoir si on peut écrire
dedans ou pas en cas d'affectation globale.

Alors, d'après la doc, par exemple, après le champ OTYPER, il y a 16 bits
réservés qui doivent être à la valeur de reset ("Bits 31:16 Reserved,
must be kept at reset value"). Du coup, j'aurais tendance à dire qu'on
n'y touche jamais.

Alors il faut faire attention, car si les champs réservés ne sont pas
sur des frontières "naturelles" (de mot, d'octet), l'écriture d'un
composant voisin peut les affecter.

Je me rappelle un tonneau de discussions à ce sujet, mais je ne sais
plus ce qui fait partie de 2012, de l'amendement à venir, ou des
discussions en cours... En tout cas, je te recommande de méditer C.6, en
particulier l'aspect Independent.

[Frédéric Praca]

Post by J-P. Rosen

Post by Frédéric Praca

Post by J-P. Rosen
2) Il peut être préférable (pour coller à la description hard) de faire

Post by J-P. Rosen
des composants "reserved", et effectivement cela parait logique d'en
faire des tableaux de bits. La question est de savoir si on peut
écrire dedans ou pas en cas d'affectation globale.

Alors, d'après la doc, par exemple, après le champ OTYPER, il y a 16
bits réservés qui doivent être à la valeur de reset ("Bits 31:16
Reserved, must be kept at reset value"). Du coup, j'aurais tendance à
dire qu'on n'y touche jamais.

Alors il faut faire attention, car si les champs réservés ne sont pas
sur des frontières "naturelles" (de mot, d'octet), l'écriture d'un
composant voisin peut les affecter.

Ok. Globalement, les réservés sont sur des frontières naturelles mais
j'ai effectivement un cas où il y a un risque.

Post by J-P. Rosen
Je me rappelle un tonneau de discussions à ce sujet, mais je ne sais
plus ce qui fait partie de 2012, de l'amendement à venir, ou des
discussions en cours... En tout cas, je te recommande de méditer C.6, en
particulier l'aspect Independent.

Je m'en vais lire ça dès que possible.

Merci encore

[Frédéric Praca]

Post by Frédéric Praca

Post by J-P. Rosen
Alors il faut faire attention, car si les champs réservés ne sont pas
sur des frontières "naturelles" (de mot, d'octet), l'écriture d'un
composant voisin peut les affecter.

Ok. Globalement, les réservés sont sur des frontières naturelles mais
j'ai effectivement un cas où il y a un risque.

Après test, même aux endroits où il n'y a pas de risque, l'utilisation
d'une représentation et le retrait des "reserved" font que cela ne
fonctionne pas. J'avoue que je ne comprends pas trop pourquoi sachant
qu'un dump de la zone mémoire concernée ne montre aucune différence entre
les deux implémentations.