問題

ローレベルベアメタル埋め込みコンテキスト、私はそのようなアクセスメモリ位置にユーザを禁止するために、C ++構造内の任意の名前なしで、メモリ内の余白を作成したいです。

現在、私はuint32_t :96;3ワードの代わりになる醜いビットフィールドを配置することでそれを達成しましたが、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;
    };
};

all GPIO_MAPx_YYYがマクロである場合、uint32_t :32またはレジスタタイプ（専用構造）として定義されます。

ここでは、uint32_t :192;どれがうまく機能するかがわかりますが、警告が表示されます。

これまでに検討したこと：

私はそれをいくつかuint32_t :32;（ここでは6つ）に置き換えた可能性がありますが、uint32_t :1344;（42）（特に）ある極端なケースがあります。そのため、構造の生成がスクリプト化されている場合でも、8kの上に約100行追加するのはやめたいと思います。

正確な警告メッセージは次のようなものです 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;

匿名にするレジスタごとに1つ。

埋めるのに大きなスペースがある場合は、マクロを使用して単一の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つには、さまざまなベンダーの定数と構造体の両方があります（ベンダー1は定数を使用し、ベンダー2は構造を使用しています）。

このためにクラスを使用したくないというのは、gezaの権利です。

ただし、主張したい場合は、nバイト幅の未使用のメンバーを追加する最善の方法は、単にそうすることです。

char unused[n];

実装固有のプラグマを追加して、クラスのメンバーに任意のパディングが追加されないようにすると、これは機能します。

GNU C / C ++（gcc、clang、および同じ拡張機能をサポートするその他）の場合、属性を配置する有効な場所の1つは次のとおりです。

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

（= 7バイトを示すGodboltコンパイラエクスプローラの例offsetof(GPIO, b)）

@Cliffordの回答と@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;です。はい、それは既存の8k行に数百行を追加しますが、各ヘッダーは個別に小さいので、それほど悪くはないかもしれません。

ただし、よりエキゾチックなソリューションを検討する場合は...

$のご紹介。

これはあまり知られていない事実で$あり、C ++識別子にとって実行可能な文字です。（数字とは異なり）実行可能な開始文字ですらあります。

$そうな眉毛を引き上げるソースコードに出現する、と$$$$確かにコードレビュー時の注目を集めるために起こっています。これはあなたが簡単に利用できるものです：

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

単純な "lint"をpre-commitフックとして、またはコミットさ$$$$れたC ++コードを探してそのようなコミットを拒否するCIにまとめることもできます。

構造体をMCU I / Oポートアクセスに使用しないでください。ただし、元の質問には次のように答えることができます。

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];
};