コンピュータプログラミング において、自己再配置プログラムとは、実行時に自身のアドレス依存命令とデータを再配置するプログラムであり、そのため任意のアドレスにメモリにロードすることができます。 [ 1 ] [ 2 ]多くの場合、自己再配置コードは自己修正コードの一種でもあります。
自己再配置は、プログラムが外部記憶装置からメインメモリにコピーされる際にリンカ・ローダが行う再配置プロセスと似ています。違いは、再配置を実行するのがオペレーティングシステムやシェル内のローダではなく、ロードされたプログラム自体であるという点です。
自己再配置の一形態として、プログラムが命令コードを単一のコンピュータのメインメモリ内の1つの場所から別の場所へコピーし、その後、メモリのソース場所にある命令からメモリの宛先場所にある命令へプロセッサの制御を移す場合が挙げられます。このように、プログラムのアルゴリズムによって操作されるデータは、プログラムを定義するバイト列です。
静的自己再配置は通常、ロード時(オペレーティングシステムがソフトウェアをロードして制御をソフトウェアに渡した後、初期化が完了する前)に発生し、実行時後半にプログラムの構成を変更する場合にも発生することがあります。[ 3 ] [ 4 ]
例えば、IBM PC互換機のようなアーキテクチャ上でオペレーティングシステムを起動する際の初期段階では、自己再配置がよく用いられます。この場合、下位レベルのチェーンブートローダー(マスターブートレコード(MBR)、ボリュームブートレコード(VBR)、 DOSなどのオペレーティングシステムの初期ブートステージなど)が、次のステージをメモリにロードするために、自らを移動させます。
CP/Mでは、デバッガのダイナミックデバッグツール(DDT) は、プログラムが実行される一時プログラム領域(TPA)を最大化するために、ページ境界再配置によって利用可能なメモリの最上位に動的に移動します。[ 5 ] [ 6 ]
1988年、 Zシステム用の代替コマンドラインプロセッサZCPR 3.4では、組み込みスタブを介して自己再配置可能なタイプ4プログラムが導入されました。 [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]
DOSでは、より高度なドライバや常駐システム拡張機能(RSX) または終了して常駐するプログラム(TSR)が、アプリケーションに使用できるメモリを最大化するために、外部から提供される「高」ローダー ( DOS 5 以降、 LOADHIGH / HILOAD、INSTALLHIGH / HIINSTALL、DEVICEHIGH / HIDEVICEなど[ 12 ] ) よりも効率的に上位メモリに自身を「高」ロードするために使用されることもあります。これは、オペレーティングシステムがロードされるドライバの内部動作を知らないため、初期化後に解放されるとしても、初期化コードを含むドライバ全体をブロックとして保持するのに十分な大きさの空きメモリ領域にロードする必要があるためです。TSR の場合、オペレーティングシステムはプログラムセグメントプレフィックス(PSP) と環境セグメントも割り当てる必要があります。[ 13 ]これにより、ドライバが最適な空きメモリ領域にロードされないか、上位メモリにロードされない可能性があります。これとは対照的に、自己再配置ドライバはどこにでも(従来のメモリを含む)ロードでき、その後、その(通常ははるかに小さい)常駐部分のみを上位メモリの適切な空きメモリ領域に再配置できます。さらに、高度な自己再配置TSR(オペレーティングシステムによって既に上位メモリにロードされている場合でも)は、自身のPSPセグメントとコマンドラインバッファの大部分を再配置し、環境セグメントを解放して、結果として生じるメモリフットプリントをさらに削減し、断片化を回避できます。[ 14 ]一部の自己再配置TSRは、TSRとして最初にロードされた場合でも、動的に「性質」を変更してデバイスドライバに変形することができ、それによって通常はメモリも解放されます。[ 4 ]最後に、外部ローダーがドライバを拡張メモリ(EMS)、高メモリ領域(HMA)、または拡張メモリ( DPMSまたはCLOAKING経由) に移動することは技術的に不可能です。これらの方法では、再配置ターゲット領域へのアクセスを調整するために、ドライバ固有の小さなスタブが従来メモリまたは上位メモリに残る必要があるためです。[ 15 ] [ nb 1 ] [ nb 2 ]また、デバイスドライバの場合、ドライバのヘッダーは常に最初のメガバイト内に留まる必要があるため、この条件が満たされます。[ 15 ] [ 13 ]これを実現するために、ドライバはこれらの領域への自己再配置をサポートするように特別に設計されている必要があります。[ 15 ]
高度な DOS ドライバの中には、デバイス ドライバ (オペレーティングシステムによってオフセット +0000h にロードされる) と TSR (オフセット +0100h にロードされる) の両方を含み、内部でファット バイナリとして共通のコード部分を共有するものもあります。[ 13 ]共有コードが位置独立になるように設計されていない場合、再配置ローダによって既に実行されていたものと同様の何らかの内部アドレス修正が必要になります。これは自己再配置の修正段階に似ていますが、コードは (ドライバ自体ではなく) オペレーティングシステムのローダによって既にターゲット ロケーションにロードされています。
IBM DOS/360 には、ロード中にプログラムを再配置する機能はありませんでした。プログラムの複数のバージョンが維持される場合があり、それぞれが異なるロード アドレス (パーティション) 用に構築されていました。自己再配置プログラムと呼ばれる特別なクラスのプログラムは、ロード後に自身を再配置するようにコーディングされていました。[ 16 ] IBM OS/360 は、実行可能プログラムをメモリにロードするときに再配置しました。プログラムのコピーは 1 つだけ必要でしたが、ロードされるとプログラムは移動できませんでした (いわゆるワンタイム位置独立コード)。
(複数回の)自己再配置の極端な例として、動的自己再配置とも呼ばれるコンピュータ プログラムが、実行中であってもメモリ内の固定アドレスにとどまらないように構築することが可能です。これは、例えばワームのメモリ テストで使用されます。[ 17 ] [ 18 ] [ 19 ] [ 20 ] Apple Wormも動的自己再配置です。[ 21 ]
[…] Laws: […] OS の「
動的再配置
」について。それが何で、なぜ重要だったのか教えていただけますか? […]
ユーバンクス
: […]
ゲイリーが
やったことは […] 驚くべきことでした。 […] 学校で
彼が研究室に飛び込んできて、「
再配置する
方法がわかった」と言った日のことを覚えています。彼は、唯一のバイトが常に
最上位バイト
になるという事実を利用しました
。そして、
ビットマップ
を作成しました。 […] コンピュータのメモリ容量がどれだけ大きくても、オペレーティングシステムは常に最上位メモリに移動できました。そのため、この技術を […] メモリ容量の異なるマシンで商用化することができました。 […] 64K
CP/M
と 47K CP/M を販売することはできません。アドレスでハードコンパイルを行うのはばかげています。ゲイリーはある夜、おそらく真夜中にコーディングのことを考えているときにこのことを思いつき、これが CP/M の商用化を可能にしたのです。この再配置がなければ、非常に難しい問題だったと思います。人々がそれを購入するには、複雑に思えるでしょうし、メモリを追加する場合は別のオペレーティングシステムを入手しなければなりません。 […]
Intel
[…]は、メモリ アドレスの
バイトを逆にして
いました。しかし、それらは常に同じ場所にあったので、正確には
256 バイト境界
で再配置できました。したがって、それらの場所のビットマップだけで常に再配置できました […] 法則: 動的再配置について私がこれまで聞いた中で最も雄弁な説明です […]
(33ページ)
[…] ドライバに SYS デバイス ドライバ ヘッダーを追加して、CTMOUSE が
通常の
TSR
とデバイス ドライバの
両方を 1 つに持つことができるようにします。これは、当社の FreeKEYB 高度なキーボード ドライバと同様です。 […] これは、
DR
DOS 3.41以降で
INSTALL
= がサポートされ、DR DOS が
[
D
]
CONFIG.SYS
ディレクティブの順序を保持する
ため、 DR DOS では実際には必要ありません […] しかし、これは […]
MS-DOS
/
PC DOS
システムでの […] 柔軟性を向上させます。これらのシステムでは […] ファイル内の順序に関係なく、常に
DEVICE
= ディレクティブが INSTALL= ステートメントの前に
実行されます。
[…] ソフトウェアによっては、マウス ドライバがデバイス ドライバとして存在する必要がある場合があります。昔からマウス ドライバは常にデバイス ドライバでした。これらのマウス ドライバは、使用するプロトコルに応じて特定のデバイス ドライバ名を持っていました (たとえば、
マウス システム モードの場合は「
PC$MOUSE
」
)。一部のソフトウェアは、使用する正しいタイプのマウスを見つけるために、これらのドライバを検索する場合があります。 […] もう 1 つの利点は、デバイス ドライバは通常、メモリ消費量が少ないことです (
環境も
PSP
もありません
)。 […] 基本的には、複雑なファイル ヘッダー、コマンドラインを解析するための異なるコード、異なるエントリ ポイントと終了行、および ORG 0 / ORG 100h の違いを克服するためのセグメント マジックです。デバイス ドライバの自己ロード ハイイングは、ドライバ ヘッダーをそのままにして、ドライバの残りの部分だけを再配置する必要があるため、少し複雑です […]
[…] 少なくとも
MS-DOS 6.0
+
GRAFTABL は、常駐サイズを最小限に抑えるため、
PSP
セグメントの一部
(オフセット +60h 以降) に自身を再配置します。 […]
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク) (注: DR-DOS 7.03以降のGRAFTABL 2.00+は動的自己再配置もサポートしています。){{cite newsgroup}}: CS1 maint: 非推奨のアーカイブサービス (リンク) (注: DOS におけるロードハイ方式の概要、LOADHIGHコマンドなどの使用方法、 XMSUMB APIを利用したUMBへの自己再配置方式について説明します。また、セグメント内オフセット再配置を利用してTSR をHMAに再配置するために必要な、より高度な方式についても説明します。)DOSの
問題のあるプログラムを自己再配置する
方法を提供します。DOSRELOは、
リンケージエディタが
コアイメージライブラリ
にカタログ化する前に、プログラムの
オブジェクトコード
にエントリポイントロジックを追加することにより、言語に関係なく、すべてのプログラムに対して自己再配置機能を実現します
。 […]
Z80
は命令のフェッチに加えて、
サイクルの半分をダイナミック RAM の更新に使用します
。
[
… ] Z80 は各
命令フェッチ
サイクルの半分を他のタスクの実行に費やす必要があるため、
命令バイト
をフェッチする時間はデータ バイトをフェッチする時間ほどありません。アクセスしているメモリ位置の
RAM チップ
のいずれか
が少し遅い場合、Z80 は命令をフェッチするときに間違ったビット パターンを取得する可能性がありますが、データを読み取るときには正しいビット パターンを取得します。 […] 内蔵のメモリ テストでは、この種の問題は検出されません […] これは厳密にはデータの読み書きテストです。テスト中、すべての命令フェッチはRAMからではなく
ROM
から行われるため、
H89
はメモリテストに合格するものの、一部のプログラムでは依然として不安定な動作を示す。 […] これは、RAM内を移動することでメモリをテストするプログラムである。その際、CPUはプログラムの現在のアドレスを
CRT
に表示し、そのアドレスの命令をフェッチする。そのアドレスのRAM ICが正常であれば、CPUはテストプログラムを次のメモリ位置に移動し、新しいアドレスを表示して、この手順を繰り返す。しかし、RAM ICのいずれかが十分に遅く、誤ったビットパターンを返すと、CPUは命令を誤って解釈し、予測不能な動作をする。ただし、ディスプレイは故障したICのアドレスを表示してロックアップする可能性が高い。これにより問題は8つのICに絞り込まれ、最大32個をチェックする必要があった場合と比べて改善されました。[…] このプログラムは、
メモリの下位アドレスから最後の動作アドレスまでRST 7(RESTART 7)命令をプッシュすることで
ワームテストを実行します。プログラムの残りの部分は静止したままで、RST 7命令の現在の位置とその
再配置
の表示を処理します。ちなみに、このプログラムがワームテストと呼ばれるのは、RST 7命令がメモリを移動する際に、
NOP
(NO OPERATION)の
痕跡を
残すためです。[…]