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

ソフトウェア開発において、再配置とは、プログラムの位置に依存するコードとデータにロードアドレスを割り当て、割り当てられたアドレスを反映するようにコードとデータを調整するプロセスです。 ^[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 オペレーティングシステムでは、EXE ファイルは仮想アドレス空間にロードされる最初のイメージであり、優先ベースアドレスにロードされるため、EXE ファイルの再配置テーブルを提供することは必須ではありません。

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

Windows実行ファイルはASLR互換としてマークできます。Windows 8以降では、互換としてマークされていないアプリケーションでもASLRを有効にする機能があります。^[4]この環境で正常に動作させるには、コンパイラによって再配置セクションを省略することはできません。

Unix系システム

ほとんどのUnix系システムで使用されている実行可能およびリンク可能フォーマット（ELF）実行ファイルと共有ライブラリフォーマットでは、いくつかの種類の再配置を定義することができます。^[5]^{: 1–22}

移転手続き

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

共通タイプのすべてのセグメントをそのタイプの単一のセグメントに結合する
各セグメントと各シンボルに重複しない実行時アドレスを割り当て、すべてのコード（関数）とデータ（グローバル変数）に一意の実行時アドレスを割り当てます。
再配置テーブルを参照して、データおよびオブジェクトコード内のシンボル参照を変更し、割り当てられた実行時アドレスを指すようにします。

例

以下の例では、ドナルド・クヌースの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章オブジェクトファイル」. リンカーとローダー. モルガン・カウフマン著『ソフトウェア工学とプログラミング』(第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 article #15961: Coping with 'Fixup Overflow' messages」. community.borland.com . 技術情報データベース - 製品: Borland C++ 3.1. TI961C.txt #15961. 2008-07-07にオリジナルからアーカイブ。2007-01-15に閲覧。
^ 「Windowsにおけるアドレス空間レイアウトのランダム化に関する6つの事実」2020年3月17日. 2020年7月24日閲覧。
^ 「実行可能およびリンク可能フォーマット（ELF）」（PDF） . skyfree.org . ツールインターフェース標準（TIS）ポータブルフォーマット仕様、バージョン1.1. オリジナル（PDF）から2019年12月24日にアーカイブ。 2018年10月1日閲覧。

さらに読む

Johnson, Glenn (1975-12-21) [1975-11-13]. 11/34 メモリ管理基本ロジックテスト. Digital Equipment Corporation (DEC). MAINDEC-11-DFKTA-AD . 2017年8月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 Reference number: X7170.2014. Archived (PDF) from the original on 2014-12-27 . Retrieved 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月9日). 「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年2月1日にアーカイブ。 2020年2月1日閲覧。[…] MOVCPM [pl]がどのように動作するのか疑問に思ったことはありませんか？BDOSとCCP はユーザーアプリケーションよりも上位のハイメモリにあるため、システムメモリサイズが変更されるたびにアドレスを変更する必要があります。相対アドレス指定はハードウェアに含まれていないため、 8080コードではアドレスの再配置が必要になります。本格的な再配置アセンブラとローダーを実装せずに、どうすればこれを実行できるでしょうか？これは実に巧妙で、MP/M はページ再配置可能なファイルの構築にもこの方式を採用しています。ソースプログラムを2回アセンブルし、2番目のアセンブリオリジンを1番目のアセンブリオリジンより100H（256バイト）高い位置に配置します。次に、2つのバイナリイメージをバイト単位で比較し、バイトペアの値がちょうど100Hだけ異なるマップを作成します。その結果、メモリ内のプログラムの位置を移動する際に再配置値を調整する必要がある場所のリストが生成されます。MP/Mではこの種のファイルをPRL（ページ再配置可能）と呼びますが、CP/M 2.2でこの名前が作られたかどうかは分かりません。[…]
Guzis, Charles "Chuck" P. (2015-07-29). 「Re: MOVCPM.COM はどのように機能しますか？」. Vintage Computer Forum . ジャンル: CP/M および MP/M. オリジナルから2020年2月1日にアーカイブ。 2020年2月1日閲覧。[…] 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年2月1日アーカイブ. 2020年2月1日閲覧. […] PRLファイルについて、それがMOVCPM [pl]から始まり、 MP/MおよびCP/M 3.0の不可欠な部分となった経緯について言及しました。しかし、PRLファイルはビットマップを使用しており、各ビットはメモリ位置に対応しています。1ビットは、対応するメモリ位置にページ再配置オフセットを追加する必要があることを示します。絶対メモリ参照（相対参照ではなく）が非常に少ない場合は、ビットマップではなくポインタリスト（参照ごとに2バイト）を使用することをお勧めします。相対ジャンプを持たない8080コードではこのような問題は起こりにくいですが、 Z80コードでは考慮すべき問題となる可能性があります。これを素早く見つけるコツは、プログラムを2回アセンブルすることです。2回目は100Hオフセットでアセンブルし、2つのバイナリを比較します。実行時再配置の利点は、再配置の問題を回避しようとするコードにペナルティを課す必要がないことです。つまり、「トリック」は不要で、ただコードを書けばよいのです。[…]
ロス、リチャード・L.（1978年2月）[1977]「移転は単にプログラムを移動させるだけではない」『ドクター・ドブのコンピュータ体操＆矯正歯科ジャーナル』3 (2)。米国カリフォルニア州リッジフィールド：ピープルズ・コンピュータ・カンパニー：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 Relocating Loader」.ノースカロライナ大学チャペルヒル校にて執筆。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年1月26日にアーカイブ。 2020年1月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年1月26日時点のオリジナルからのアーカイブ。 2020年1月26日閲覧。 […] REL フォーマットは、 Microsoftの M80 とDigital Researchの RMACによって生成されます。[…]
feilipu (2018-09-05) [2018-09-02]. 「MP/M用ページ再配置可能実行ファイル、PRLのサポート」。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]
ハーディン・ブラザーズ（1985年4月）「再配置可能なプログラム：マイクロコンピューティングのホーボーズ」『マイクロコンピューティングの次のステップ』（80ページ）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]
ミッチェル、ブリッジャー（1988年7～8月）。カールソン、アート（編）「Z3PLUSと再配置 - ZCPR3PLUSに関する情報、および自己再配置型Z80コードの書き方」。コンピュータジャーナル（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、およびType-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, New Jersey, USA: 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 and Type-4 Programs」. The Computer Journal (TCJ) - プログラミング、ユーザーサポート、アプリケーション. Z-System Corner - Some New Applications of Type-4 Programs (55). S. Plainfield, New Jersey, USA: Socrates Press: 13–19. ISSN 0748-9331. ark:/13960/t4dn54d22 . 2021年11月29日閲覧.[26][27]
Ganssle, Jack (1992年2月). 「再配置可能なコードの書き方 - 組み込みコードは複数のアドレスで実行する必要がある」. Embedded Systems Programming . The Ganssle Group - Perfecting the Art of Building Embedded Systems / TGG. 2019年7月18日時点のオリジナルよりアーカイブ。 2020年2月20日閲覧。