オーバーレイ（プログラミング）

一般的なコンピューティングの意味で、オーバーレイとは「プログラムコードやその他のデータのブロックをメインメモリに転送し、すでに格納されているものを置き換えるプロセス」を意味します。^[1]オーバーレイは、プログラムをコンピュータのメインメモリよりも大きくすることができるプログラミング方法です。^[2]組み込みシステムでは、システムオンチップの内部メモリである物理メモリの制限と仮想メモリ機能の欠如のため、通常オーバーレイが使用されます。

オーバーレイ プログラムを構築するには、プログラムをオーバーレイまたはリンクと呼ばれる自己完結型のオブジェクト コードブロックに手動で分割し、通常はツリー構造で配置します。^{[b]同じ深さレベルにある}兄弟セグメントは、オーバーレイ領域^[c]または宛先領域と呼ばれる同じメモリを共有します。オーバーレイ マネージャーは、オペレーティング システムの一部またはオーバーレイ プログラムの一部であり、必要なときに外部メモリから必要なオーバーレイを宛先領域に読み込みます。これは自動または明示的なコードによって行われます。多くの場合、リンカーはオーバーレイをサポートします。^[3]

次の例は、構造を示すためにインデントされた単一の領域を含むオーバーレイ プログラムをリンクするように OS/360 リンケージ エディターに指示する制御ステートメントを示しています(セグメント名は任意です)。

SYSLIB(MOD1) をインクルードする
 SYSLIB(MOD2) をインクルードする
 オーバーレイA
   SYSLIB(MOD3) をインクルードする
     オーバーレイAA
       SYSLIB(MOD4) をインクルードする
       SYSLIB(MOD5) をインクルードする
     オーバーレイAB
        SYSLIB(MOD6) をインクルードする
 オーバーレイB
    SYSLIB(MOD7) をインクルードする

                       +--------------+
                       | ルートセグメント |
                       | MOD1、MOD2 |
                       +--------------+
                               |
                    +----------+-----------+
                    | |
             +---------------+ +---------------+
             | オーバーレイ A | | オーバーレイ B |
             | MOD3 | | MOD7 |
             +---------------+ +---------------+
                    |
           +--------+--------+
           | |
    +---------------+ +---------------+
    | オーバーレイ AA | | オーバーレイ AB |
    | MOD4、MOD5 | | MOD6 |
    +---------------+ +---------------+

これらのステートメントは、ルートと呼ばれる永続的に常駐するセグメントと、MOD2 の終了後にロードされる 2 つのオーバーレイ A と B で構成されるツリーを定義します。オーバーレイ A 自体は、AA と AB という 2 つのオーバーレイ セグメントで構成されます。実行時には、オーバーレイ A と B は両方とも同じメモリ位置を使用します。AA と AB は両方とも、MOD3 の終了後に同じ位置を使用します。

ルートと特定のオーバーレイ セグメント間のすべてのセグメントは、パスと呼ばれます。

2015 年現在、ほとんどのビジネス アプリケーションは、仮想メモリ^{[アップデート]}を備えたプラットフォームで実行することを想定しています。このようなプラットフォームの開発者は、プログラムのワーキング セットが使用可能な物理メモリを超えない限り、メモリ制約が存在しないかのようにプログラムを設計できます。最も重要なことは、オーバーレイ サイズによって制約されたステップに処理を強制するという設計上の困難さを回避して、アーキテクトが解決すべき問題に集中できることです。したがって、設計者は、プログラマがサイズをあまり制御できない高水準プログラミング言語 (例: Java、C++、Smalltalk ) を使用できます。

それでも、オーバーレイは組み込みシステムでは有用である。^[4]組み込みシステムで使用される一部の低コストプロセッサは、メモリ管理ユニット（MMU）を提供しない。さらに、多くの組み込みシステムはリアルタイムシステムであり、オーバーレイはページングよりも確実な応答時間を提供する。たとえば、スペースシャトル プライマリアビオニクスシステムソフトウェア（PASS）はプログラムされたオーバーレイを使用している。^[5]

仮想メモリを備えたプラットフォームでも、コーデックなどのソフトウェア コンポーネントは、必要に応じてロードおよびロードできる程度まで分離される場合があります。

IBMはFORTRAN II でチェーンジョブ^[6]の概念を導入しました。プログラムは新しいリンクをロードするためにCHAINサブルーチンを明示的に呼び出す必要があり、新しいリンクはFortran COMMON領域を除く古いリンクのストレージをすべて置き換えました。

IBMはIBSYS / IBJOBに、ツリー構造やCALL処理の一部としてのリンクの自動ロードなど、 より一般的なオーバーレイ処理^{[7]を導入しました。}

OS/360 では、IBM は IBLDR のオーバーレイ機能を拡張し、オーバーレイ プログラムがそれぞれ独自のオーバーレイ ツリーを持つ独立したオーバーレイ領域を持つことができるようにしました。また、OS/360 には、1024 バイトの SVC 一時領域を使用する、 一時SVCルーチン用のよりシンプルなオーバーレイ システムもありました。

家庭用コンピュータの時代には、オペレーティングシステムとそれが動作するコンピュータシステムの多くに仮想メモリがなく、現在の標準からするとRAMが非常に少なかったため、オーバーレイが人気でした。オリジナルのIBM PCは、構成に応じて16Kから64Kでした。オーバーレイは、コモドールBASICでグラフィック画面をロードするための一般的な手法でした。^[2]

「1980 年代のいくつかのDOSリンカーは、25 年前のメインフレーム コンピュータで使用されていたものとほぼ同じ形式で [オーバーレイ] をサポートしていました。」^{[4] [8]メモリ オーバーレイを含む} バイナリ ファイルの拡張子は、事実上の標準である.OVL ^[8]または.OVR ^[9]でした (ただし、後続のファイルには.000、.001などの数値のファイル拡張子も使用されました^[10] )。このファイル タイプは、WordStar ^[11] (メインの実行可能ファイルWS.COMとオーバーレイ モジュールWSMSGS.OVR、WSOVLY1.OVR、で構成さMAILMERGE.OVRれ、SPELSTAR.OVR" fat " オーバーレイ ファイルはCP/M-86および MS-DOSへの移植でもバイナリが同一でした^[12] )、dBase、^[13]、Enable SoftwareのEnable DOS オフィス オートメーション ソフトウェア パッケージなどで使用されていました。BorlandのTurbo Pascal ^{[14] [15]}およびGFA BASICコンパイラは、.OVL ファイルを生成できました。

• 拡張メモリ(EMS)
• 仮想メモリ
• チェーンローディング
• ページング
• 銀行の切り替え
• 再帰

• IBM OS リンケージ エディターおよびローダー - プログラム番号 360S-ED-510、360S-ED-521、360S-LD-547 (PDF)。リリース 21 (第 10 版)。米国ニューヨーク州ホワイト プレーンズ: IBM Corporation。1972年 3 月 [1972 年 1 月]。注文番号 GC28-6538-9、ファイル番号 S360-31。2022年 7 月 10 日にオリジナルからアーカイブ(PDF)されました。 {{cite book}}:|work=無視されました (ヘルプ) (2+244+4 ページ)
• Groeber, Marcus; Di Geronimo, Jr., Edward "Ed"; Paul, Matthias R. (2002-03-02) [2002-02-24]. 「RBIL62 の GEOS/NDO 情報?」.ニュースグループ: comp.os.geos.programmer. 2019-04-20 にオリジナルからアーカイブ。2019-04-20に取得。 […] Geos が16 の割り込みを必要とする理由は、コードのサイズを変更せずに、セグメント間 ("far") 関数呼び出しを割り込みに変換するスキームが使用されるためです。これを行う理由は、"何か" (カーネル) が Geos アプリケーションによって行われたすべてのセグメント間呼び出しにフックし、適切なコード セグメントが仮想メモリからロードされ、ロックダウンされるようにするためです。DOS用語で言えば、これはオーバーレイ ローダーに相当しますが、コンパイラやアプリケーションからの明示的なサポートを必要とせずに追加できます。次のようなことが起こります: […] 1. リアル モード コンパイラは次のような命令を生成します: CALL <segment>:<offset> -> 9A <oflow><offhigh><seglow><seghigh> ここで、<seglow><seghigh> は通常、コードが配置されているアドレスに応じてロード時に修正する必要があるアドレスとして定義されます。 […] 2. Geos リンカーはこれを別のものに変換します: INT 8xh -> CD 8x […] DB <seghigh>,<oflow>,<offhigh> […] これも 5 バイトなので、「インプレース」で修正できることに注意してください。ここで問題となるのは、割り込みには 2 バイトが必要ですが、CALL FAR 命令には 1 バイトしか必要ないことです。その結果、32 ビット ベクター (<seg><ofs>) を24 ビットに圧縮する必要があります。 […] これは 2 つの方法で実現されます。まず、<seg> アドレスはセグメントへの「ハンドル」としてエンコードされ、その最下位ニブルは常に 0 です。これにより 4 ビットが節約されます。さらに […] 残りの 4 ビットは割り込みベクターの下位ニブルに入り、INT 80h から 8Fh までのいずれかが作成されます。 […] これらすべてのベクターの割り込みハンドラーは同じです。3.5 バイト表記からアドレスを「アンパック」し、セグメントの絶対アドレスを検索し、仮想メモリのロード処理を行った後に呼び出しを転送します。呼び出しからの戻りも、対応するロック解除コードを通過します。 […] 割り込みベクターの下位ニブル (80h～8Fh) には、セグメント ハンドルのビット 4 から 7 が保持されます。セグメント ハンドルのビット 0 から 3 は (Geos ハンドルの定義により) 常に 0 です。[…] すべての Geos API は「オーバーレイ」スキームを通じて実行されます […]: Geos アプリケーションがメモリにロードされると、ローダーはシステム ライブラリ内の関数の呼び出しを対応する INT ベースの呼び出しに自動的に置き換えます。いずれにしても、これらは一定ではなく、ライブラリのコード セグメントに割り当てられたハンドルに依存します。[…] Geosは当初、非常に早い段階で保護モードに変換することを意図していました[…]、リアルモードで「レガシー オプション」のみであるため […] アセンブリ コードのほぼすべての行がこれに対応しています […]

• http://computer-programming-forum.com/29-pascal/45df7513ab22cf7e.htm