Il problema

In un contesto embedded bare-metal di basso livello , vorrei creare uno spazio vuoto nella memoria, all'interno di una struttura C ++ e senza alcun nome, per impedire all'utente di accedere a tale posizione di memoria.

In questo momento, l'ho ottenuto inserendo un brutto uint32_t :96;bitfield che prenderà opportunamente il posto di tre parole, ma solleverà un avviso da GCC (Bitfield troppo grande per adattarsi a uint32_t), che è abbastanza legittimo.

Anche se funziona bene, non è molto pulito quando si desidera distribuire una libreria con diverse centinaia di questi avvisi ...

Come posso farlo correttamente?

Perché c'è un problema in primo luogo?

Il progetto a cui sto lavorando consiste nel definire la struttura della memoria di diverse periferiche di un'intera linea di microcontrollori (STMicroelectronics STM32). Per fare ciò, il risultato è una classe che contiene un'unione di diverse strutture che definiscono tutti i registri, a seconda del microcontrollore di destinazione.

Un semplice esempio per una periferica piuttosto semplice è il seguente: un General Purpose Input / Output (GPIO)

union
{

    struct
    {
        GPIO_MAP0_MODER;
        GPIO_MAP0_OTYPER;
        GPIO_MAP0_OSPEEDR;
        GPIO_MAP0_PUPDR;
        GPIO_MAP0_IDR;
        GPIO_MAP0_ODR;
        GPIO_MAP0_BSRR;
        GPIO_MAP0_LCKR;
        GPIO_MAP0_AFR;
        GPIO_MAP0_BRR;
        GPIO_MAP0_ASCR;
    };
    struct
    {
        GPIO_MAP1_CRL;
        GPIO_MAP1_CRH;
        GPIO_MAP1_IDR;
        GPIO_MAP1_ODR;
        GPIO_MAP1_BSRR;
        GPIO_MAP1_BRR;
        GPIO_MAP1_LCKR;
        uint32_t :32;
        GPIO_MAP1_AFRL;
        GPIO_MAP1_AFRH;
        uint32_t :64;
    };
    struct
    {
        uint32_t :192;
        GPIO_MAP2_BSRRL;
        GPIO_MAP2_BSRRH;
        uint32_t :160;
    };
};

Dove all GPIO_MAPx_YYYè una macro, definita come uint32_t :32o il tipo di registro (una struttura dedicata).

Qui vedi il uint32_t :192;che funziona bene, ma fa scattare un avviso.

Quello che ho considerato finora:

Potrei averlo sostituito con diversi uint32_t :32;(6 qui), ma ho alcuni casi estremi in cui houint32_t :1344; (42) (tra gli altri). Quindi preferirei non aggiungere un centinaio di righe in cima ad altre 8k, anche se la generazione della struttura è scriptata.

L'esatto messaggio di avvertimento è qualcosa del tipo: width of 'sool::ll::GPIO::<anonymous union>::<anonymous struct>::<anonymous>' exceeds its type(Adoro quanto sia ombroso).

Preferirei non risolverlo semplicemente rimuovendo l'avviso, ma l'uso di

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-WTheRightFlag"
/* My code */
#pragma GCC diagnostic pop

potrebbe essere una soluzione ... se trovo TheRightFlag. Tuttavia, come sottolineato in questo thread , gcc/cp/class.ccon questa triste parte di codice:

warning_at (DECL_SOURCE_LOCATION (field), 0,
        "width of %qD exceeds its type", field);

Il che ci dice che non esiste un -Wxxxflag per rimuovere questo avviso ...

Usa più bitfield anonimi adiacenti. Quindi invece di:

    uint32_t :160;

ad esempio, avresti:

    uint32_t :32;
    uint32_t :32;
    uint32_t :32;
    uint32_t :32;
    uint32_t :32;

Uno per ogni registro che vuoi rendere anonimo.

Se si dispone di ampi spazi da riempire, potrebbe essere più chiaro e meno soggetto a errori utilizzare le macro per ripetere il singolo spazio a 32 bit. Ad esempio, dato:

#define REPEAT_2(a) a a
#define REPEAT_4(a) REPEAT_2(a) REPEAT_2(a)
#define REPEAT_8(a) REPEAT_4(a) REPEAT_4(a)
#define REPEAT_16(a) REPEAT_8(a) REPEAT_8(a)
#define REPEAT_32(a) REPEAT_16(a) REPEAT_16(a)

Quindi uno spazio 1344 (42 * 32 bit) può essere aggiunto così:

struct
{
    ...
    REPEAT_32(uint32_t :32;) 
    REPEAT_8(uint32_t :32;) 
    REPEAT_2(uint32_t :32;)
    ...
};

Che ne dici di un modo in C ++?

namespace GPIO {

static volatile uint32_t &MAP0_MODER = *reinterpret_cast<uint32_t*>(0x4000);
static volatile uint32_t &MAP0_OTYPER = *reinterpret_cast<uint32_t*>(0x4004);

}

int main() {
    GPIO::MAP0_MODER = 42;
}

Ottieni il completamento automatico a causa dello GPIOspazio dei nomi e non è necessario un riempimento fittizio. Inoltre, è più chiaro cosa sta succedendo, poiché puoi vedere l'indirizzo di ogni registro, non devi fare affidamento sul comportamento di riempimento del compilatore.

Nell'arena dei sistemi embedded, è possibile modellare l'hardware utilizzando una struttura o definendo i puntatori agli indirizzi di registro.

La modellazione in base alla struttura non è consigliata perché al compilatore è consentito aggiungere riempimento tra i membri per scopi di allineamento (sebbene molti compilatori per sistemi incorporati abbiano un pragma per comprimere la struttura).

Esempio:

uint16_t * const UART1 = (uint16_t *)(0x40000);
const unsigned int UART_STATUS_OFFSET = 1U;
const unsigned int UART_TRANSMIT_REGISTER = 2U;
uint16_t * const UART1_STATUS_REGISTER = (UART1 + UART_STATUS_OFFSET);
uint16_t * const UART1_TRANSMIT_REGISTER = (UART1 + UART_TRANSMIT_REGISTER);

Puoi anche usare la notazione dell'array:

uint16_t status = UART1[UART_STATUS_OFFSET];  

Se è necessario utilizzare la struttura, IMHO, il metodo migliore per saltare gli indirizzi sarebbe definire un membro e non accedervi:

struct UART1
{
  uint16_t status;
  uint16_t reserved1; // Transmit register
  uint16_t receive_register;
};

In uno dei nostri progetti abbiamo sia costanti che strutture di diversi fornitori (il fornitore 1 utilizza le costanti mentre il fornitore 2 utilizza le strutture).

geza ha ragione sul fatto che tu non voglia davvero usare le classi per questo.

Ma, se dovessi insistere, il modo migliore per aggiungere un membro inutilizzato di larghezza n byte, è semplicemente farlo:

char unused[n];

Se aggiungi un pragma specifico dell'implementazione per impedire l'aggiunta di spaziatura interna arbitraria ai membri della classe, questo può funzionare.

Per GNU C / C ++ (gcc, clang e altri che supportano le stesse estensioni), uno dei posti validi in cui inserire l'attributo è:

#include <stddef.h>
#include <stdint.h>
#include <assert.h>  // for C11 static_assert, so this is valid C as well as C++

struct __attribute__((packed)) GPIO {
    volatile uint32_t a;
    char unused[3];
    volatile uint32_t b;
};

static_assert(offsetof(struct GPIO, b) == 7, "wrong GPIO struct layout");

(esempio sull'esploratore del compilatore Godbolt che mostra offsetof(GPIO, b)= 7 byte.)

Per espandere le risposte di @ Clifford e @Adam Kotwasinski:

#define REP10(a)        a a a a a a a a a a
#define REP1034(a)      REP10(REP10(REP10(a))) REP10(a a a) a a a a

struct foo {
        int before;
        REP1034(unsigned int :32;)
        int after;
};
int main(void){
        struct foo bar;
        return 0;
}

Per espandere la risposta di Clifford, puoi sempre macro i bitfield anonimi.

Quindi invece di

uint32_t :160;

uso

#define EMPTY_32_1 \
 uint32_t :32
#define EMPTY_32_2 \
 uint32_t :32;     \ // I guess this also can be replaced with uint64_t :64
 uint32_t :32
#define EMPTY_32_3 \
 uint32_t :32;     \
 uint32_t :32;     \
 uint32_t :32
#define EMPTY_UINT32(N) EMPTY_32_ ## N

E poi usalo come

struct A {
  EMPTY_UINT32(3);
  /* which resolves to EMPTY_32_3, which then resolves to real declarations */
}

Sfortunatamente, avrai bisogno di tante EMPTY_32_Xvarianti quanti byte hai :( Tuttavia, ti permette di avere singole dichiarazioni nella tua struttura.

Per definire un grande spaziatore come gruppi di 32 bit.

#define M_32(x)   M_2(M_16(x))
#define M_16(x)   M_2(M_8(x))
#define M_8(x)    M_2(M_4(x))
#define M_4(x)    M_2(M_2(x))
#define M_2(x)    x x

#define SPACER int : 32;

struct {
    M_32(SPACER) M_8(SPACER) M_4(SPACER)
};

Penso che sarebbe utile introdurre un po 'più di struttura; che può, a sua volta, risolvere il problema dei distanziatori.

Assegna un nome alle varianti

Mentre gli spazi dei nomi piatti sono belli, il problema è che si finisce con una raccolta eterogenea di campi e non un modo semplice per passare insieme tutti i campi correlati. Inoltre, utilizzando strutture anonime in un'unione anonima non è possibile passare riferimenti alle strutture stesse o utilizzarle come parametri del modello.

Come primo passo, quindi, prenderei in considerazione l' idea di suddividerestruct :

// GpioMap0.h
#pragma once

// #includes

namespace Gpio {
struct Map0 {
    GPIO_MAP0_MODER;
    GPIO_MAP0_OTYPER;
    GPIO_MAP0_OSPEEDR;
    GPIO_MAP0_PUPDR;
    GPIO_MAP0_IDR;
    GPIO_MAP0_ODR;
    GPIO_MAP0_BSRR;
    GPIO_MAP0_LCKR;
    GPIO_MAP0_AFR;
    GPIO_MAP0_BRR;
    GPIO_MAP0_ASCR;
};
} // namespace Gpio

// GpioMap1.h
#pragma once

// #includes

namespace Gpio {
struct Map1 {
    // fields
};
} // namespace Gpio

// ... others headers ...

E infine, l'intestazione globale:

// Gpio.h
#pragma once

#include "GpioMap0.h"
#include "GpioMap1.h"
// ... other headers ...

namespace Gpio {
union Gpio {
    Map0 map0;
    Map1 map1;
    // ... others ...
};
} // namespace Gpio

Ora posso scrivere un void special_map0(Gpio:: Map0 volatile& map);, oltre a ottenere una rapida panoramica di tutte le architetture disponibili a colpo d'occhio.

Distanziatori semplici

Con la definizione suddivisa in più intestazioni, le intestazioni sono individualmente molto più gestibili.

Pertanto, il mio approccio iniziale per soddisfare esattamente le tue esigenze sarebbe quello di continuare a ripetere std::uint32_t:32;. Sì, aggiunge alcune righe da 100 alle righe esistenti da 8.000, ma poiché ogni intestazione è individualmente più piccola, potrebbe non essere così male.

Se sei disposto a considerare soluzioni più esotiche, però ...

Presentazione di $.

È un fatto poco noto che $è un carattere valido per gli identificatori C ++; è anche un valido carattere iniziale (a differenza delle cifre).

Una $comparsa nel codice sorgente probabilmente solleverebbe le sopracciglia e $$$$attirerà sicuramente l'attenzione durante le revisioni del codice. Questo è qualcosa che puoi facilmente sfruttare:

#define GPIO_RESERVED(Index_, N_) std::uint32_t $$$$##Index_[N_];

struct Map3 {
    GPIO_RESERVED(0, 6);
    GPIO_MAP2_BSRRL;
    GPIO_MAP2_BSRRH;
    GPIO_RESERVED(1, 5);
};

Puoi anche mettere insieme un semplice "lint" come hook pre-commit o nel tuo CI che cerca $$$$nel codice C ++ sottoposto a commit e rifiutare tali commit.

Sebbene sia d'accordo che le strutture non debbano essere utilizzate per l'accesso alla porta I / O MCU, la domanda originale può essere risolta in questo modo:

struct __attribute__((packed)) test {
       char member1;
       char member2;
       volatile struct __attribute__((packed))
       {
       private:
              volatile char spacer_bytes[7];
       }  spacer;
       char member3;
       char member4;
};

Potrebbe essere necessario sostituire __attribute__((packed))con #pragma packo simile a seconda della sintassi del compilatore.

Mescolare membri privati ​​e pubblici in una struttura normalmente risulta in quel layout di memoria non è più garantito dallo standard C ++. Tuttavia, se tutti i membri non statici di uno struct sono privati, è ancora considerato POD / layout standard, così come gli struct che li incorporano.

Per qualche motivo gcc produce un avviso se un membro di una struttura anonima è privato, quindi ho dovuto dargli un nome. In alternativa, inserendolo in un'altra struttura anonima si elimina anche l'avviso (questo potrebbe essere un bug).

Tieni presente che il spacermembro non è privato di per sé, quindi è ancora possibile accedere ai dati in questo modo:

(char*)(void*)&testobj.spacer;

Tuttavia, un'espressione del genere sembra un ovvio trucco e, si spera, non sarebbe stata utilizzata senza una buona ragione, figuriamoci come un errore.

Anti-soluzione.

NON FARE QUESTO: Mescola campi privati ​​e pubblici.

Forse sarà utile una macro con un contatore per generare nomi di variabili uniqie?

#define CONCAT_IMPL( x, y ) x##y
#define MACRO_CONCAT( x, y ) CONCAT_IMPL( x, y )
#define RESERVED MACRO_CONCAT(Reserved_var, __COUNTER__) 


struct {
    GPIO_MAP1_CRL;
    GPIO_MAP1_CRH;
    GPIO_MAP1_IDR;
    GPIO_MAP1_ODR;
    GPIO_MAP1_BSRR;
    GPIO_MAP1_BRR;
    GPIO_MAP1_LCKR;
private:
    char RESERVED[4];
public:
    GPIO_MAP1_AFRL;
    GPIO_MAP1_AFRH;
private:
    char RESERVED[8];
};