PL/Iの「SELECT文」の裏側：コンパイラが描く高速分岐の秘密
こんにちは。メインフレームの世界へようこそ。
JavaやCOBOLを触ってきた方にとって、PL/I（ピーエル・アイ）という言語は、少し古風で、それでいて驚くほど懐の深い「職人気質」な道具に見えるかもしれません。
今日は、PL/Iの制御構文の中でも、特に「SELECT文」がコンパイルの過程でどのように機械語へと昇華されるのか、その裏側のロジックを紐解いていきましょう。
—
1. 予約語を持たないPL/Iの「寛容さ」
まず、PL/Iに初めて触れる方が驚くのが「予約語がない」という仕様です。
Javaで`if`や`class`を識別子（変数名）にできないのと違い、PL/Iでは`IF`という名前の変数を定義しても、コンパイラは怒りません。
「えっ、そんなことしたらコンパイラが混乱するのでは？」と思いますよね。
実は、PL/Iのコンパイラは文脈（Context）を読み取る天才なんです。
`IF = 10;` と書けば「これは変数への代入だな」と理解し、`IF A > B THEN…` と書けば「これは制御文だな」と判断します。この自由度の高さは、かつてのプログラマーたちの柔軟な思考を支えてきたPL/Iの美学の一つです。
—
2. SELECT-WHEN構造の正体：ジャンプテーブルという魔法
さて、本題の`SELECT-WHEN`構造です。これは他の言語で言う`switch-case`文に近いですが、内部実装は非常に効率的です。
PL/Iコンパイラは、`SELECT`文の中に記述された`WHEN`条件が「定数」かつ「連続的または一定の範囲内」であると判断すると、単なる`IF-THEN-ELSE`の連鎖ではなく、「ジャンプテーブル（分岐テーブル）」をメモリ上に生成します。
内部で起きていることのイメージ
想像してみてください。何百もの部屋がある巨大なホテルで、ゲスト（条件値）がやってきたとき、フロント係（CPU）がいちいち「あなたはAさんですか？」「あなたはBさんですか？」と全員に尋ねるのは非効率ですよね。
ジャンプテーブルとは、「Aさんなら301号室、Bさんなら302号室へ」という直通の案内板をあらかじめ作っておくようなものです。
/i
/ 処理の分岐例：エラーコードに応じたメッセージ出力 /
SELECT (ERROR_CODE);
WHEN (100) PUT SKIP LIST(‘入力データが不正です’);
WHEN (200) PUT SKIP LIST(‘計算オーバーフローが発生しました’);
WHEN (300) PUT SKIP LIST(‘システムリソースが枯渇しています’);
OTHERWISE PUT SKIP LIST(‘未知のエラーコードです’);
END;
WHEN条件が増えるとどうなるか？
1. 条件が少ない場合： コンパイラは単純な比較命令（Compare）を生成します。
2. 条件が多い場合： 条件値の範囲を計算し、インデックスによるメモリアクセスで、対象の処理へ一瞬でジャンプする機械語を出力します。
つまり、`WHEN`句が10個あろうが100個あろうが、ジャンプテーブルが生成される限り、パフォーマンスへの影響は最小限に抑えられます。これは、バッチ処理で大量のトランザクションを捌くメインフレームにおいては、非常に重要な「高速化の秘訣」なのです。
—
3. 実務で知っておくべき「データストレージ」のヒント
PL/Iを扱う上で、変数の宣言（DECLARE）は非常に重要です。
特に、以下のコード例のように、変数のサイズや型を厳密に定義することが、コンパイラに「ジャンプテーブルを最適化する余地」を与えることにも繋がります。
/i
/ 固定長変数による効率的な分岐制御 /
DCL ERROR_CODE FIXED BIN(15) INIT(0); / 2バイトの整数型 /
/
FIXED BIN(15)は、ハードウェアのレジスタに乗りやすく、
分岐判断の際の計算コストが極めて低くなります。
/
—
最後に：怖がらなくて大丈夫です
「古い言語だから、仕様が複雑で怖い」と思っている方もいらっしゃるかもしれません。しかし、PL/Iは非常に論理的に設計されています。
特に`SELECT-WHEN-OTHERWISE`のような構文は、読みやすさとマシン性能の両立を追求した当時のエンジニアたちの「魂」が込められています。
もし皆さんの現場で古いPL/Iコードを読み解く機会があれば、「これはコンパイラがどう翻訳して、CPUを楽にさせてあげようとしているのかな？」という視点で眺めてみてください。きっと、無機質なコードの中に、当時のエンジニアたちの温かい工夫が見えてくるはずです。
それでは、次回の記事では、PL/I特有の「構造体（STRUCTURE）」とメモリ配置の不思議についてお話ししましょう。またお会いしましょう！
