1. 導入: なぜBIT(n)の設計が重要なのか
メインフレーム開発において、メモリ効率を追求する際に欠かせないのがBIT(n)属性です。しかし、安易な使用はCPU命令の実行サイクルを増大させ、逆に広範囲にわたる変換はメモリ不足を招くという「速度と容量のトレードオフ」が存在します。本稿では、BIT(n)のメモリ占有の仕組みを理解し、現場でパフォーマンスを損なわないための設計指針を解説します。
2. 基礎知識: UNALIGNEDとアライメントの仕組み
BIT(n)は、言語仕様上デフォルトでUNALIGNED（境界調整なし）として扱われます。これは、8ビット（1バイト）の境界を跨いでデータが詰め込まれることを意味します。
例えば、BIT(4)を2つ定義した場合、通常は合計8ビットとして1バイトに収まります。一方で、ALIGNEDを指定すると、データ型に応じた境界（ワードやダブルワード）に配置されるため、メモリは余分に消費しますが、CPUが1回のロード命令でデータを取得できるため、処理速度は向上します。
3. 実装/解決策: メモリ消費の設計計算
ビット列を定義する際は、構造体全体のサイズとアクセス頻度を考慮します。
・ビット演算が頻発するフラグ: ALIGNEDを指定し、メモリを犠牲にして速度を優先する。
・数百万件規模の巨大な配列データ: UNALIGNED（デフォルト）を維持し、メモリ節約を優先する。
4. サンプルプログラム: PL/I形式での定義例
以下のコードは、メモリ効率を意識した構造体定義の例です。
/ BIT(n)属性を使用した構造体定義例 /
DCL 1 SAMPLE_DATA_STRUCT,
/ フラグ類はアクセス頻度が高いためALIGNEDで定義 /
5 FLAG_DATA BIT(8) ALIGNED,
/ 大量データはUNALIGNED（デフォルト）で詰め込み効率を優先 /
5 WORK_ARRAY(1000),
10 STATUS_BIT BIT(1) UNALIGNED,
10 TYPE_CODE BIT(3) UNALIGNED;
/
コメント:
1. FLAG_DATAは境界調整されるため、L命令等で即座にロード可能です。
2. WORK_ARRAYは各ビットが連続して配置されるため、
メモリ消費を最小限に抑えられます。
/
5. 応用・注意点: 現場で陥りやすい罠
現場で最も多いトラブルは「現代言語の感覚で全てのフラグをINTEGER型に置き換える」ことです。
数百万件のデータを持つ配列で、BIT(1)を4バイトのINTEGER型に変更すると、単純計算でメモリ消費量は32倍に膨れ上がります。これはメインフレームの主記憶を圧迫し、ページングを多発させてシステム全体のパフォーマンスを著しく低下させる要因となります。
回避策のポイント:
・アクセス頻度の可視化: 頻繁に更新するフラグはALIGNED、参照のみのフラグや大量データはUNALIGNEDと明確に分けること。
・サイズ計算の習慣化: 構造体の定義を変更する際は、必ず最終的なメモリ占有量（Offset）を確認し、バウンダリ（境界）がどこで発生しているかを設計段階で把握してください。
コメント