移転（コンピューティング）

再配置とは、プログラムの位置に依存するコードとデータにロードアドレスを割り当て、割り当てられたアドレスを反映するようにコードとデータを調整するプロセスです。^[1]^[2]マルチプロセスシステムの登場前、そして現在でも多くの組み込みシステムでは、オブジェクトのアドレスは既知の場所（多くの場合ゼロ）から始まる絶対アドレスです。マルチプロセッシングシステムはプログラム間で動的にリンクおよび切り替えを行うため、位置に依存しないコードを使用してオブジェクトを再配置できることが必要になりました。リンカーは通常、プログラムを実行する前に、ファイルとライブラリを検索してシンボリック参照またはライブラリ名をメモリ内の実際に使用可能なアドレスに置き換えるプロセスであるシンボル解決と組み合わせて再配置を実行します。

再配置は、通常、リンク時にリンカーによって行われますが、再配置ローダーによってロード時に行われる場合や、実行時に実行中のプログラム自体によって行われる場合もあります。アーキテクチャによっては、アドレスの割り当てを実行時に延期することで、再配置を完全に回避するものもあります。たとえば、ゼロアドレス演算を行うスタックマシンや、すべてのコンパイル単位が個別のセグメントにロードされるセグメント化されたアーキテクチャなどです。

セグメンテーション

オブジェクトファイルは、さまざまなメモリセグメントまたはセクションタイプに分割されます。セグメントタイプの例には、コードセグメント (.text)、初期化されたデータセグメント (.data)、初期化されていないデータセグメント (.bss)、または共通セグメントや名前付き静的セグメントなど、プログラマーによって確立されたその他のセグメントが含まれます。

移転テーブル

再配置テーブルは、トランスレータ (コンパイラまたはアセンブラ) によって作成され、オブジェクトまたは実行可能ファイルに格納されるポインタのリストです。テーブル内の各エントリ (または「フィックスアップ」) は、オブジェクトコード内の絶対アドレスへのポインタであり、ローダがプログラムを再配置するときに正しい場所を参照するように変更する必要があります。フィックスアップは、プログラムの再配置を完全なユニットとしてサポートするように設計されています。場合によっては、テーブル内の各フィックスアップ自体が 0 のベースアドレスに相対的であるため、ローダがテーブル内を移動すると、フィックスアップ自体を変更する必要があります。^[2]

一部のアーキテクチャでは、特定の境界（セグメント境界など）を越えるフィックスアップやワード境界に揃えられていないフィックスアップは不正であり、リンカーによってエラーとしてフラグが立てられます。^[3]

DOS および 16 ビット Windows

DOS 実行可能ファイル( EXE )内のコードまたはデータを指すfarポインタ(セグメント:offsetを持つ32 ビットポインタ、 DOS プログラムで使用可能な 20 ビット 640 KB のメモリ空間をアドレス指定するために使用される) には絶対セグメントがありません。これは、コード/データの実際のアドレスはプログラムがメモリ内のどこにロードされるかによって異なり、プログラムがロードされるまでこのアドレスはわからないためです。

代わりに、セグメントは DOS EXE ファイル内の相対値です。実行可能ファイルがメモリにロードされたときに、これらのセグメントを修正する必要があります。EXEローダーは、再配置テーブルを使用して、調整する必要があるセグメントを検索します。

32 ビット Windows

32 ビット Windows オペレーティングシステムでは、EXE ファイルは仮想アドレス空間にロードされる最初のイメージであり、優先ベースアドレスにロードされるため、EXE ファイルの再配置テーブルを提供する必要はありません。

Windows Vistaで導入されたエクスプロイト緩和技術であるアドレス空間レイアウトのランダム化(ASLR)を選択したDLLと EXE の両方で、バイナリが仮想アドレス空間に最初にロードされるにもかかわらず、実行前に動的に移動される可能性があるため、再配置テーブルが再び必須になります。

64 ビット Windows

Windows Vista 以降でネイティブ 64 ビットバイナリを実行する場合、ASLR は必須^{[引用が必要]}であり、コンパイラによって再配置セクションを省略することはできません。

Unix系システム

ほとんどのUnix系システムで使用されている実行可能およびリンク可能フォーマット（ELF）実行形式と共有ライブラリフォーマットでは、いくつかのタイプの再配置を定義することができます。 ^[4]

移転手続き

リンカーは、オブジェクトファイル内のセグメント情報と再配置テーブルを読み取り、次の方法で再配置を実行します。

共通タイプのすべてのセグメントをそのタイプの単一のセグメントに結合する
各セクションと各シンボルに一意のランタイムアドレスを割り当て、すべてのコード (関数) とデータ (グローバル変数) に一意のランタイムアドレスを与える^{[説明が必要]}
再配置テーブルを参照して^{[なぜ? ]}シンボル参照を変更し、正しい^{[説明が必要]}実行時アドレスを指すようにします。

例

次の例では、Donald KnuthのMIXアーキテクチャと MIXAL アセンブリ言語を使用しています。詳細は異なりますが、原則はどのアーキテクチャでも同じです。

(A) プログラムSUBR は、マシンコードとアセンブラの両方で表示されるオブジェクトファイル (B) を生成するためにコンパイルされます。コンパイラは、コンパイルされたコードを任意の場所 (多くの場合、図に示すように場所 1) から開始します。場所 13 には、場所 5 のステートメントSTへのジャンプ命令のマシンコードが含まれています。
(C) SUBRが後で他のコードとリンクされる場合、1 以外の場所に格納される可能性があります。この例では、リンカーはそれを 120 の場所に配置します。現在 133 の場所にあるジャンプ命令のアドレスは、ステートメントSTのコードの新しい場所 (現在は 125) を指すように再配置する必要があります。[命令に示されている 1 61 は、125 の MIX マシンコード表現です]。
(D) プログラムが実行のためにメモリにロードされるとき、リンカーによって割り当てられた場所以外の場所にロードされることがあります。この例では、SUBR が現在 300 の位置にあることを示しています。現在 313 にあるジャンプ命令のアドレスは、 STの更新された場所である 305 を指すように再度再配置する必要があります。[4 49 は 305 の MIX マシン表現です]。

参照

参考文献

^ 「オブジェクトコードの種類」。iRMX 86 アプリケーションローダーリファレンスマニュアル(PDF)。Intel。pp . 1-2–1-3。2020年 1 月 11 日にオリジナルからアーカイブ(PDF) 。2020年 1 月 11 日に取得。[…]絶対コード、および絶対オブジェクトモジュールは、LOC86 によって処理され、メモリ内の特定の場所でのみ実行されるコードです。ローダーは、絶対オブジェクトモジュールを、モジュールが占有する必要がある特定の場所にのみロードします。位置独立コード(一般に PIC と呼ばれる) は、PIC を任意のメモリ場所にロードできるという点で絶対コードとは異なります。絶対コードに対する PIC の利点は、PIC では特定のメモリブロックを予約する必要がないことです。ローダーが PIC をロードすると、呼び出しタスクのジョブのプールからiRMX 86メモリセグメントが取得され、PIC がセグメントにロードされます。 PIC に関する制限は、セグメント化のPL/M-86 COMPACT モデルと同様に、コードセグメントとデータセグメントを 1 つずつしか持てず、これらのセグメントのベースアドレス、つまりセグメント自体が動的に変化しないことです。つまり、PIC プログラムの長さは必然的に 64K バイト未満になります。PIC コードは、LINK86 の BIND 制御によって生成できます。ロード時に位置指定可能なコード(一般に LTL コードと呼ばれる) は、オブジェクトコードの 3 番目の形式です。LTL コードは、メモリ内の任意の場所にロードできるという点で PIC に似ています。ただし、LTL コードをロードするときに、ローダーはポインタのベース部分を変更して、ポインタがマイクロプロセッサのレジスタの初期内容に依存しないようにします。この修正 (ベースアドレスの調整) により、LTL コードは、複数のコードセグメントまたは複数のデータセグメントを持つタスクで使用できます。つまり、LTL プログラムの長さは 64K バイトを超える場合があります。FORTRAN 86とPascal 86 は、短いプログラムでも LTL コードを自動的に生成します。LTL コードは、LINK86 の BIND 制御によって生成できます。[…]
^ ab Levine, John R. (2000) [1999 年 10 月]。「第 1 章: リンクとロード、第 3 章: オブジェクトファイル」。リンカーとローダー。Morgan Kaufmann シリーズソフトウェアエンジニアリングおよびプログラミング (第 1 版)。サンフランシスコ、カリフォルニア州、米国: Morgan Kaufmann。p . 5。ISBN 1-55860-496-0. OCLC 42413382. 2012年12月5日にオリジナルからアーカイブ。2020年1月12日閲覧。コード: [1][2] エラッタ: [3]
^ Borland (1999-09-01) [1998-07-02]. 「Borland 記事 #15961: 「Fixup Overflow」メッセージへの対処」. community.borland.com . 技術情報データベース - 製品: Borland C++ 3.1. TI961C.txt #15961. 2008-07-07 にオリジナルからアーカイブ。2007-01-15に取得。
^ 「実行可能およびリンク可能フォーマット (ELF)」(PDF)。skyfree.org 。ツールインターフェース標準 (TIS) ポータブルフォーマット仕様、バージョン 1.1。2019年 12 月 24 日のオリジナルからアーカイブ(PDF) 。2018 年 10 月 1 日に取得。

さらに読む

Johnson, Glenn (1975-12-21) [1975-11-13]. 11/34 メモリ管理基本ロジックテスト。Digital Equipment Corporation (DEC)。MAINDEC-11-DFKTA-AD。2017-08-19に取得。
Formaniak, Peter G.; Leitch, David (1977 年 7 月)。「マイクロプロセッサソフトウェア標準の提案」。BYTE - the small systems journal。技術フォーラム。第 2 巻、第 7 号。米国ニューハンプシャー州ピーターボロ: Byte Publications, Inc. pp. 34、62–63。ark:/13960/t32245485。2021年 12 月 6 日に取得。(3 ページ) (注: Mostekによる再配置可能な 16 進形式について説明します。)
Ogdin, Carol Anne; Colvin, Neil; Pittman, Tom; Tubb, Philip (1977 年 11 月)。「再配置可能なオブジェクトコード形式」。BYTE - the small systems journal。技術フォーラム。第 2 巻、第 11 号。米国ニューハンプシャー州ピーターボロ: Byte Publications, Inc. pp. 198–205。ark:/13960/t59c88b4h、ark:/13960/t3kw76j24。2021年 12 月 6 日に取得。(8 ページ) (注: TDLによる再配置可能な 16 進形式について説明します。)
キルドール、ゲイリー・アーレン（1978年2月）[1976]。「絶対マシンコードの静的再配置のための簡単なテクニック」。ドブ博士のコンピュータ体操と矯正のジャーナル。3 （2）。ピープルズ・コンピュータ・カンパニー：10–13（66–69）。ISBN 0-8104-5490-4. #22 ark:/13960/t8hf1g21p . 2017年8月19日閲覧。[4][5][6]。元々はKildall, Gary Arlen (1977) [1976年11月22～24日]に発表された。「絶対マシンコードの静的再配置のための単純な手法」。米国カリフォルニア州モントレーの海軍大学院で執筆。Titus, Harold A. (編)。会議記録: 第10回アシロマ回路・システム・コンピューター会議: 1976年11月22～24日に発表された論文。アシロマ信号・システム・コンピューター会議。アシロマホテルおよび会議場、カリフォルニア州パシフィックグローブ、米国: Western Periodicals Company。pp. 420～424。ISSN 1058-6393 。2021年12月6日閲覧。（609ページ）。 (この「サイズ変更」方法は、ページ境界再配置と呼ばれ、プログラム実行のTPA を最大化するためにMOVCPM [pl] を使用してCP/M-80ディスクイメージに静的に適用できます。また、CP/M デバッガのDynamic Debugging Tool (DDT)によって、自分自身をより上位のメモリに再配置するために動的に利用されました。同じアプローチは、再配置可能なPL/Mコードを生成するために、 IMS AssociatesのBruce H. Van Nattaによって独立して開発されました。段落境界再配置として、この方法の別のバリエーションは、 DR DOS 6.0以降でKEYB、SHARE、およびNLSFUNCなどの動的HMA自己再配置TSRによって後に利用されました。多少似たアプローチに基づく、はるかに洗練されたバイトレベルの粒度の方法は、Matthias R. Paul と Axel C. Frinke によって独立して考案および実装され、動的デッドコード除去によって常駐ドライバと TSR (FreeKEYB など) の実行時フットプリントを動的に最小化しました。)
Mossip, Richard H. (1980 年 9 月 - 10 月)。米国ニュージャージー州ブルーミングデールで執筆。「Relocatable Code」(PDF)。S -100 Microsystems。第 1 巻、第 5 号。米国ニュージャージー州マウンテンサイド & スプリングフィールド: Libes, Inc. pp. 54 - 55。ISSN 0199-7955。ark :/13960/s2cfgkmxcwg。ark:/13960/s2qdm1t01nr。2023年 11 月 27 日にオリジナルからアーカイブ(PDF) 。2023年 11 月 27 日に取得。[7][8] (2ページ) (注: ページ境界の再配置と再配置アセンブラについて説明します。)
Huitt, Robert; Eubanks, Gordon ; Rolander, Thomas "Tom" Alan ; Laws, David; Michel, Howard E.; Halla, Brian; Wharton, John Harrison ; Berg, Brian; Su, Weilian; Kildall, Scott ; Kampe, Bill (2014-04-25). Laws, David (ed.). 「Legacy of Gary Kildall: The CP/M IEEE Milestone Dedication」(PDF) (ビデオトランスクリプション). Pacific Grove, California, USA: Computer History Museum . CHM 参照番号: X7170.2014. 2014-12-27 にオリジナルからアーカイブ(PDF)されました。2020-01-19に取得。[…] Laws: […] OS の「動的再配置」とは何ですか。なぜ重要だったのですか。 […]ユーバンクス: […]ゲイリーがやったことは […] 驚くべきものでした。 […] 学校で彼が研究室に飛び込んできて、「再配置の方法が分かった」と言った日のことを覚えています。彼は、唯一のバイトは常に上位バイトになるという事実を利用しました。そこで彼はビットマップを作成しました。 […] コンピュータのメモリ容量は関係なく、オペレーティングシステムは常に上位メモリに移動できます。したがって、これを商品化することができます […] メモリ容量の異なるマシンで。 […] 64K CP/Mと 47K CP/M を販売することはできません。アドレスにハードコンパイルがあるのは馬鹿げています。そこでゲイリーは、ある夜、おそらく真夜中にコーディングのことを考えながらこれを思いつき、これによって CP/M の商品化が可能になりました。この再配置がなければ、非常に困難な問題になっていたと思います。人々にそれを買わせるには、複雑に思われるでしょうし、メモリを追加すると、別のオペレーティングシステムを入手しなければなりません。[…] Intel […]は、メモリアドレスのバイトを逆にしていました。しかし、それらは常に同じ場所にあったので、正確には256 バイト境界で再配置できました。したがって、それらの場所のビットマップだけで、常に再配置できました。[…] Laws: 動的再配置について私が今まで聞いた中で最も雄弁な説明は、間違いなくこれです。[…][9][10] （33ページ）
リーバー、エックハルト。フォン・マッセンバッハ、トーマス (1987)。「CP/M 2 は、「新しい」CP/M をモジュール化したシステムです。」c't - コンピュータ技術に関する雑誌(パート 1) (ドイツ語)。1987年(1)。ハイセ・フェルラーク: 124–135; リーバー、エックハルト。フォン・マッセンバッハ、トーマス (1987)。「CP/M 2 は、「新しい」CP/M をモジュール化したシステムです。」c't - コンピュータ技術に関する雑誌(パート 2) (ドイツ語)。1987年（2）。ハイゼ・フェルラーク: 78–85; Huck, Alex (2016-10-09). 「RSM für CP/M 2.2」。Homecomputer DDR (ドイツ語)。2016-11-25 にオリジナルからアーカイブ。2016-11-25に取得。
Guzis, Charles "Chuck" P. (2015-03-16). "Re: CP/M アセンブリ言語プログラミング". Vintage Computer Forum . ジャンル: CP/M および MP/M。2020-02-01 にオリジナルからアーカイブ。2020-02-01に取得。[…] MOVCPM [pl]がどのように機能するか疑問に思ったことはありませんか? BDOSとCCP はユーザーアプリケーションの上位の高メモリにあるため、システムメモリサイズが変更されるたびにアドレスを変更する必要があります。相対アドレス指定はハードウェアの一部ではないため、 8080コードでアドレスを再配置する必要があります。本格的な再配置アセンブラとローダーを実装せずに、これをどのように行うのでしょうか? これは実際には非常に巧妙で、MP/M はページ再配置可能ファイルを作成するためにもこのスキームを使用しています。ソースプログラムを2 回アセンブルし、2 番目のアセンブリオリジンを最初のアセンブリオリジンより 100H (256 バイト) 高くするだけです。次に、2 つのバイナリイメージをバイトごとに比較し、バイトのペアの値がちょうど 100H 異なるマップを作成します。結果は、メモリ内のプログラムの位置を移動する場合、再配置値を調整する必要がある位置のリストです。MP/M では、この種のファイルを PRL (ページ再配置可能) と呼びますが、CP/M 2.2 でこの名前が付けられたかどうかはわかりません。[…]
Guzis, Charles "Chuck" P. (2015-07-29). 「Re: MOVCPM.COM はどのように機能しますか?」。ヴィンテージコンピュータフォーラム。ジャンル: CP/M および MP/M。2020-02-01 にオリジナルからアーカイブ。2020-02-01に取得。[…] MOVCPM [pl]は、初期のタイプの PRL 形式を使用します。基本的に、CP/Mは 2 回アセンブルされ、2 回目は 100H バイトオフセットです。2 つのバイナリが比較され、ビットマップが構築されます。セットされたビットは、アドレスの上位バイトが調整されることを意味します。下位アドレスバイトは影響を受けません。したがって、「ページ再配置可能ファイル」です。ビットマップの各バイトは、バイナリデータの 8 バイトに対応します。[…] したがって、MOVCPM で移動されるものはすべて、イメージとその再配置ビットマップの一部です。[…]
Guzis, Charles "Chuck" P. (2016-11-08). 「Re: CP/M アセンブリプログラムで RST 28h を使用するのは安全ですか?」。Vintage Computer Forum。ジャンル: CP/M および MP/M。 2020-02-01 にオリジナルからアーカイブ。 2020-02-01に取得。 […] 私は PRL ファイルについて、それがもともとMOVCPM [pl]で始まったが、 MP/MおよびCP/M 3.0の不可欠な部分になった経緯について言及しました。ただし、PRL ファイルはビットマップを使用しており、そのすべてのビットがメモリ位置に対応しています。1 ビットは、ページ再配置オフセットを対応するメモリ位置に追加する必要があることを示します。絶対メモリ参照 (相対参照ではなく) が非常に少ない場合は、ビットマップではなくポインターリスト (参照ごとに 2 バイト) を使用することをお勧めします。相対ジャンプのない8080コードでは、このようなことは起こりそうにありませんが、 Z80コードでは考慮する必要があります。これをすばやく見つけるには、プログラムを 2 回アセンブルします。2 回目は 100H オフセットし、2 つのバイナリを比較します。実行時再配置の利点は、再配置の問題を回避しようとするコードに対してペナルティを課す必要がないことです。つまり、「トリック」は不要で、単純なコードを書くだけです。[…]
Roth, Richard L. (1978 年 2 月) [1977]. 「移転は単にプログラムを移動するだけではない」. Dr. Dobb's Journal of Computer Calisthenics & Orthodontia . 3 (2). リッジフィールド、カリフォルニア州、米国: People's Computer Company : 14–20 (70–76). ISBN 0-8104-5490-4. #22. 2019年4月20日時点のオリジナルよりアーカイブ。2019年4月19日閲覧。
Calingaert, Peter (1979) [1978-11-05]。「8.2.2 ローダーの再配置」。ノースカロライナ大学チャペルヒル校で執筆。Horowitz , Ellis (編)の『アセンブラ、コンパイラ、プログラム変換』。コンピュータソフトウェアエンジニアリングシリーズ (第 1 刷、第 1 版)。米国メリーランド州ポトマック: Computer Science Press, Inc.、pp . 237–241。ISBN 0-914894-23-4. ISSN 0888-2088. LCCN 78-21905 . 2020年3月20日閲覧。（2+xiv+270+6ページ）
Microsoft OBJ ファイル形式。Microsoft 、製品サポートサービス。アプリケーションノート SS0288。2017 年 9 月 9 日にオリジナルからアーカイブされました。2017年 8 月 21 日に取得。
Tanenbaum, Andrew Stuart ; Bos, Herbert (2015). Modern Operating Systems (第 4 版). Pearson Education Inc. ISBN 978-0-13359162-0。
Elliott, John C. (2012-06-05) [2000-01-02]. 「PRL ファイル形式」. seasip.info . 2020-01-26 にオリジナルからアーカイブ。2020-01-26に取得。[…] PRL ファイルは、MP/MおよびCP/M Plusが.COM ファイル以外のさまざまなモジュールに使用する再配置可能なバイナリファイルです。このファイル形式は、 Amstrad PCWの FID ファイルにも使用されます。PRL のバージョンを使用するファイル形式には、SPR (System PRL)、RSP (Resident System Process) などがあります。LINK-80 は、 PRL ヘッダーを持つが再配置可能ではないOVL (オーバーレイ) ファイルも生成できます。GSXドライバーはPRL 形式であり、 Resident System Extensions (.RSX)も同様です。 […][11]
Elliott, John C. (2012-06-05) [2000-01-02]. 「Microsoft REL 形式」. seasip.info . 2020-01-26 にオリジナルからアーカイブ。 2020-01-26に取得。[…] REL 形式は、Microsoftの M80 とDigital Researchの RMAC によって生成されます。 […]
feilipu (2018-09-05) [2018-09-02]. 「PRL のサポート、MP/M のページ再配置可能実行可能ファイル」z88dk . 2020-02-01 にオリジナルからアーカイブ。2020-01-26に取得。 […] リンカーは、アセンブルされたMicrosoft .REL ファイルから、MP/M用の .PRL 形式の実行可能ファイルを生成する必要があります。 .PRL 形式は、基本的に、プログラムとそのデータを任意のページに再配置できるようにするための追加情報を含む.COM ファイルです。 .PRL ファイルはどのようになっているのでしょうか。最初のバイトはプログラムのサイズで、その後に 0x0100 のプログラム原点が続きます。プログラムの後には、プログラムを再配置するときにプログラム内のどのバイトを変更する必要があるかを MP/M システムが認識できるように、ビット単位のバイトマスクが追加されます。リンカーは、アプリケーション全体を逆アセンブルせずに、どのようにこれを実行するのでしょうか。プログラムは、.REL オブジェクトから 2 つの異なるオリジン 0x0100 と 0x0200 に事前にリンクされます。リンカーのトリックは、実行可能ファイルの 2 つのバージョンのどのバイトが異なるかを認識するだけです。これらのバイトは、実行可能ファイルの後に格納されるビットマスクに記録され、最終的な .PRL プログラムは 0x0100 プラスページオフセットから実行されるように設計されています。同じトリックが .RSP および .SPR 実行可能ファイルに対して実行されますが、これらの形式は両方ともオフセットを省略し、0x0000 プラスページオフセットから実行されます。[…]
Brothers, Hardin (1983 年 4 月)。「再配置可能コードを理解する」。80 Micro . The Next Step (39) 。1001001, Inc. : 38, 40, 42, 45。ISSN 0744-7868 。2020年 2 月 6 日閲覧。[12][13]
Brothers, Hardin (1985年4月). 「再配置可能なプログラム: マイクロコンピューティングのホーボーズ」. 80 Micro . 次のステップ (63). CW Communications/Peterborough, Inc. : 98, 100, 102–103. ISSN 0744-7868 . 2020年2月6日閲覧。[14][15]
Sage, Jay (1988年5月～6月)。Carlson, Art (編)。「ZCPR 3.4 - タイプ4プログラム」。The Computer Journal (TCJ) - プログラミング、ユーザーサポート、アプリケーション。ZCPR3コーナー (32)。コロンビアフォールズ、モンタナ州、米国: 10～17 [15～16]。ISSN 0748-9331。ark :/13960/t1wd4v943。2021年11月29日閲覧。[16][17]
Mitchell, Bridger (1988 年 7 月 - 8 月)。Carlson, Art (編)。「Z3PLUS と再配置 - ZCPR3PLUS に関する情報、および自己再配置 Z80 コードの記述方法」。The Computer Journal (TCJ) - プログラミング、ユーザーサポート、アプリケーション。Advanced CP/M (33)。コロンビアフォールズ、モンタナ州、米国: 9 - 15。ISSN 0748-9331。ark :/13960/t36121780。2020年 2 月 9 日閲覧。[18][19]
Sage, Jay (1988 年 9 月～10 月)。Carlson, Art (編)。「再配置可能コード、PRL ファイル、ZCPR34、およびタイプ 4 プログラムの詳細」。The Computer Journal (TCJ) - プログラミング、ユーザーサポート、アプリケーション。ZCPR3 コーナー (34)。コロンビアフォールズ、モンタナ州、米国: 20～25。ISSN 0748-9331。ark :/13960/t0ks7pc39。2020年 2 月 9 日閲覧。[20][21][22]
Sage, Jay (1992 年 1 月～2 月)。Carlson, Art、McEwen, Chris (編著)。「ZCPR の 10 年間」。The Computer Journal (TCJ) - プログラミング、ユーザーサポート、アプリケーション。Z-System Corner (54)。S. Plainfield、ニュージャージー州、米国: Socrates Press: 3～7。ISSN 0748-9331。ark :/13960/t89g6n689。2021年 11 月 29 日閲覧。[23][24][25]
Sage, Jay (1992 年 5 月～6 月) [1992 年 3 月～6 月]。Carlson, Art、McEwen, Chris (編)。「Type-3 および Type-4 プログラム」。The Computer Journal (TCJ) - プログラミング、ユーザーサポート、アプリケーション。Z-System コーナー - タイプ 4 プログラムのいくつかの新しいアプリケーション (55)。S. Plainfield、ニュージャージー州、米国: Socrates Press: 13～19。ISSN 0748-9331。ark :/13960/t4dn54d22。2021年 11 月 29 日閲覧。[26][27]
Ganssle, Jack (1992 年 2 月)。「再配置可能なコードの記述 - 一部の組み込みコードは複数のアドレスで実行する必要があります」。組み込みシステムプログラミング。The Ganssle Group - Perfecting the Art of Building Embedded Systems / TGG。2019 年 7 月 18 日にオリジナルからアーカイブ。2020 年 2 月 20 日に取得。

[Intel_iRMX-1] 「オブジェクトコードの種類」。iRMX 86 アプリケーションローダーリファレンスマニュアル(PDF)。Intel。pp . 1-2–1-3。2020年 1 月 11 日にオリジナルからアーカイブ(PDF) 。2020年 1 月 11 日に取得。[…]絶対コード、および絶対オブジェクトモジュールは、LOC86 によって処理され、メモリ内の特定の場所でのみ実行されるコードです。ローダーは、絶対オブジェクトモジュールを、モジュールが占有する必要がある特定の場所にのみロードします。位置独立コード(一般に PIC と呼ばれる) は、PIC を任意のメモリ場所にロードできるという点で絶対コードとは異なります。絶対コードに対する PIC の利点は、PIC では特定のメモリブロックを予約する必要がないことです。ローダーが PIC をロードすると、呼び出しタスクのジョブのプールからiRMX 86メモリセグメントが取得され、PIC がセグメントにロードされます。 PIC に関する制限は、セグメント化のPL/M-86 COMPACT モデルと同様に、コードセグメントとデータセグメントを 1 つずつしか持てず、これらのセグメントのベースアドレス、つまりセグメント自体が動的に変化しないことです。つまり、PIC プログラムの長さは必然的に 64K バイト未満になります。PIC コードは、LINK86 の BIND 制御によって生成できます。ロード時に位置指定可能なコード(一般に LTL コードと呼ばれる) は、オブジェクトコードの 3 番目の形式です。LTL コードは、メモリ内の任意の場所にロードできるという点で PIC に似ています。ただし、LTL コードをロードするときに、ローダーはポインタのベース部分を変更して、ポインタがマイクロプロセッサのレジスタの初期内容に依存しないようにします。この修正 (ベースアドレスの調整) により、LTL コードは、複数のコードセグメントまたは複数のデータセグメントを持つタスクで使用できます。つまり、LTL プログラムの長さは 64K バイトを超える場合があります。FORTRAN 86とPascal 86 は、短いプログラムでも LTL コードを自動的に生成します。LTL コードは、LINK86 の BIND 制御によって生成できます。[…]

[Levine_1999_CH1_CH3-2] Levine, John R. (2000) [1999 年 10 月]。「第 1 章: リンクとロード、第 3 章: オブジェクトファイル」。リンカーとローダー。Morgan Kaufmann シリーズソフトウェアエンジニアリングおよびプログラミング (第 1 版)。サンフランシスコ、カリフォルニア州、米国: Morgan Kaufmann。p . 5。ISBN 1-55860-496-0. OCLC 42413382. 2012年12月5日にオリジナルからアーカイブ。2020年1月12日閲覧。コード: [1][2] エラッタ: [3]

[Borland_2007-3] Borland (1999-09-01) [1998-07-02]. 「Borland 記事 #15961: 「Fixup Overflow」メッセージへの対処」. community.borland.com . 技術情報データベース - 製品: Borland C++ 3.1. TI961C.txt #15961. 2008-07-07 にオリジナルからアーカイブ。2007-01-15に取得。

[ELF-4] 「実行可能およびリンク可能フォーマット (ELF)」(PDF)。skyfree.org 。ツールインターフェース標準 (TIS) ポータブルフォーマット仕様、バージョン 1.1。2019年 12 月 24 日のオリジナルからアーカイブ(PDF) 。2018 年 10 月 1 日に取得。