Питання

У контексті низькорівневого вбудованого металу , я хотів би створити порожній простір в пам'яті, в структурі C ++ і без будь-якого імені, щоб заборонити користувачеві доступ до такого розташування пам'яті.

Зараз я домігся цього, поставивши потворне uint32_t :96;бітове поле, яке зручно займе місце трьох слів, але воно викличе попередження від GCC (бітфілд занадто великий, щоб вмістити його в uint32_t), що цілком правомірно.

Хоча він працює нормально, він не дуже чистий, коли ви хочете поширити бібліотеку з кількома сотнями цих попереджень ...

Як це зробити правильно?

Чому виникає проблема в першу чергу?

Проект, над яким я працюю, полягає у визначенні структури пам'яті різних периферійних пристроїв цілої лінії мікроконтролерів (STMicroelectronics STM32). Для цього результатом є клас, який містить об’єднання декількох структур, які визначають усі регістри, залежно від цільового мікроконтролера.

Одним простим прикладом досить простого периферійного пристрою є наступний: вхід / вихід загального призначення (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;
    };
};

Де все GPIO_MAPx_YYY- це макрос, який визначається як uint32_t :32або як тип реєстру (виділена структура).

Тут ви бачите, uint32_t :192;що працює добре, але викликає попередження.

Що я розглядав до цього часу:

Я міг би замінити його декількома uint32_t :32;(тут 6), але у мене є деякі крайні випадки, коли я маю uint32_t :1344;(42) (серед інших). Тому я волів би не додавати близько ста рядків поверх 8k інших, навіть незважаючи на те, що генерація структури виконана за сценарієм.

Точне попереджувальне повідомлення виглядає приблизно так: width of 'sool::ll::GPIO::<anonymous union>::<anonymous struct>::<anonymous>' exceeds its type(Мені просто подобається, як це тіньово).

Я волів би не вирішити це шляхом простого видалення попередження, а використання

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

може бути рішенням ... якщо знайду TheRightFlag. Однак, як зазначено в цій темі , gcc/cp/class.cз цією сумною частиною коду:

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

Що говорить нам, що не існує -Wxxxпрапора для видалення цього попередження ...

Використовуйте кілька сусідніх анонімних бітових полів. Отже, замість:

    uint32_t :160;

наприклад, у вас буде:

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

По одному для кожного реєстру, для якого ви хочете бути анонімним.

Якщо у вас є великі простори для заповнення, це може бути зрозуміліше і менше помилок, схильних до використання макросів для повторення одного 32-бітного простору. Наприклад, враховуючи:

#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)

Тоді простір 1344 (42 * 32 біт) можна додати таким чином:

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

Як щодо 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;
}

Ви отримуєте автозаповнення через GPIOпростір імен, і немає потреби в фіктивних відступів. Навіть, зрозуміліше, що відбувається, оскільки ви можете бачити адресу кожного реєстру, вам зовсім не доведеться покладатися на поведінку компілятора в заполнении.

На арені вбудованих систем ви можете моделювати апаратне забезпечення, використовуючи структуру, або визначаючи вказівники на адреси реєстру.

Моделювання за структурою не рекомендується, оскільки компілятору дозволено додавати відступи між членами для цілей вирівнювання (хоча багато компілятори для вбудованих систем мають прагму для упаковки структури).

Приклад:

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);

Ви також можете використовувати позначення масиву:

uint16_t status = UART1[UART_STATUS_OFFSET];  

Якщо вам потрібно використовувати структуру, IMHO, найкращим методом пропуску адрес буде визначення члена, а не доступ до нього:

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

В одному з наших проектів ми маємо як константи, так і структури від різних постачальників (постачальник 1 використовує константи, тоді як постачальник 2 використовує структури).

geza має рацію, що ви дійсно не хочете використовувати для цього класи.

Але якщо ви хотіли наполягати, найкращий спосіб додати невикористаний член шириною n байт - це просто зробити це:

char unused[n];

Якщо ви додасте конкретну реалізацію прагми, щоб запобігти додаванню довільних відступів для членів класу, це може спрацювати.

Для GNU C / C ++ (gcc, clang та інші, що підтримують однакові розширення), одним із допустимих місць для розміщення атрибуту є:

#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");

(приклад у провіднику компілятора Godbolt показує offsetof(GPIO, b)= 7 байт.)

Щоб розширити відповіді @ Clifford's та @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;
}

Щоб розширити відповідь Кліффорда, ви завжди можете зробити макрос анонімними бітовими полями.

Так замість

uint32_t :160;

використання

#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

А потім використовуйте це як

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

На жаль, вам знадобиться стільки EMPTY_32_Xваріантів, скільки байт у вас є :( Тим не менше, це дозволяє вам мати окремі оголошення у вашій структурі.

Визначити великий пробіл як групи по 32 біти.

#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)
};

Я думаю, було б вигідно ввести ще якусь структуру; що, в свою чергу, може вирішити проблему розпірок.

Назвіть варіанти

Незважаючи на те, що плоскі простори імен приємні, проблема полягає в тому, що у вас виходить строката колекція полів і не простий спосіб передачі всіх пов’язаних полів разом. Крім того, використовуючи анонімні структури в анонімному об'єднанні, ви не можете передавати посилання на самі структури або використовувати їх як параметри шаблону.

Отже, на першому кроці я міг би розглянути наступнеstruct :

// 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 ...

І нарешті, загальний заголовок:

// Gpio.h
#pragma once

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

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

Тепер я можу написати void special_map0(Gpio:: Map0 volatile& map);, а також швидко переглянути короткий огляд усіх доступних архітектур.

Прості розпірки

З визначенням, розділеним на кілька заголовків, заголовки стають набагато більш керованими.

Тому моїм початковим підходом точно відповідати вашим вимогам було б дотримуватися повторення std::uint32_t:32;. Так, він додає кілька рядків 100-х до існуючих 8-лінійних рядків, але оскільки кожен заголовок індивідуально менший, це може бути не так погано.

Якщо ви готові розглянути більш екзотичні рішення, проте ...

Представляємо $.

Маловідомий факт $є життєздатним символом ідентифікаторів С ++; це навіть життєздатний початковий символ (на відміну від цифр).

Поява $у вихідному коді, швидше за все, підніме брови, і $$$$, безумовно, приверне увагу під час огляду коду. Цим можна легко скористатися:

#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);
};

Ви навіть можете скласти простий "вовк" як гачок перед фіксацією або у вашому інтерфейсі, який шукає $$$$в коді C ++, що фіксується, і відхилити такі коміти.

Хоча я згоден, що структури не повинні використовуватися для доступу до порту вводу-виводу MCU, на оригінальне запитання можна відповісти таким чином:

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

Можливо, вам доведеться замінити __attribute__((packed))на #pragma packабо подібне залежно від синтаксису компілятора.

Змішування приватних та загальнодоступних членів у структурі зазвичай призводить до того, що розміщення пам'яті більше не гарантується стандартом C ++. Однак якщо всі нестатичні члени структури є приватними, це все одно вважається POD / стандартним макетом, а також структури, які їх вбудовують.

З якоїсь причини gcc видає попередження, якщо член анонімної структури є приватним, тому мені довелося дати йому ім'я. Крім того, загортання його в чергову анонімну структуру також позбавляє попередження (це може бути помилка).

Зверніть увагу, що spacerчлен сам не є приватним, тому доступ до даних все одно можна отримати таким чином:

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

Однак такий вираз виглядає як очевидний хак, і, сподіваємось, не буде використаний без дійсно вагомих причин, не кажучи вже про помилку.

Анти-розчин.

НЕ РОБІТЬ ЦЕ: Поєднуйте приватне та публічне поля.

Можливо, макрос з лічильником для створення імен змінних 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];
};