JPH0254337A - 実行可能イメージの生成を容易とするデータ処理システム - Google Patents
実行可能イメージの生成を容易とするデータ処理システムInfo
- Publication number
- JPH0254337A JPH0254337A JP1165143A JP16514389A JPH0254337A JP H0254337 A JPH0254337 A JP H0254337A JP 1165143 A JP1165143 A JP 1165143A JP 16514389 A JP16514389 A JP 16514389A JP H0254337 A JPH0254337 A JP H0254337A
- Authority
- JP
- Japan
- Prior art keywords
- code
- memory
- stored
- lisp
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/54—Link editing before load time
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
（産業上の利用分野）
この発明は、ＬＩＳＰなど高度なコンピュータ言語での
実行可能イメージの生成に関する。
実行可能イメージの生成に関する。
（従来の技術と課題）
適切に生成された実行可能イメージはオペレーティング
システムの品質向上に直面してもより堅固であるため、
実行可能イメージの方がサスペンド状態の非実行イメー
ジ（サスペンドイメージ）よりも好ましい。サスペンド
状態のイメージフォーマットは、一つのオペレーティン
グシステムで生成され、別のオペレーティングシステム
で使われると破損し易い。複数ユーザの環境では、実行
可能イメージの読取専用部分及びシステム共有可能部分
がメモリ内へ一旦マッピングされる。実行可能イメージ
のその後の呼び出しにおいては、実行可能イメージのス
タティック部分でだけマツピングを行えばよい。実行可
能イメージは、読取専用部分及びシステム共有可能部分
を読み込んで共有可能とするのに、オペレーティングシ
ステムのマツピング機構を使用する。サスペンドイメー
ジは非常に小さい“核”からスタートし、全てのデータ
を各ユーザによってマツピングされることを必要とする
。サスペンドイメージはどの部分も、複数のユーザ間で
共有できない。実行可能イメージの方がロードするのに
遠く、配分するのも容易である。
システムの品質向上に直面してもより堅固であるため、
実行可能イメージの方がサスペンド状態の非実行イメー
ジ（サスペンドイメージ）よりも好ましい。サスペンド
状態のイメージフォーマットは、一つのオペレーティン
グシステムで生成され、別のオペレーティングシステム
で使われると破損し易い。複数ユーザの環境では、実行
可能イメージの読取専用部分及びシステム共有可能部分
がメモリ内へ一旦マッピングされる。実行可能イメージ
のその後の呼び出しにおいては、実行可能イメージのス
タティック部分でだけマツピングを行えばよい。実行可
能イメージは、読取専用部分及びシステム共有可能部分
を読み込んで共有可能とするのに、オペレーティングシ
ステムのマツピング機構を使用する。サスペンドイメー
ジは非常に小さい“核”からスタートし、全てのデータ
を各ユーザによってマツピングされることを必要とする
。サスペンドイメージはどの部分も、複数のユーザ間で
共有できない。実行可能イメージの方がロードするのに
遠く、配分するのも容易である。
フォートラン（ＦＯＲＴＲＡＮ）など伝統的なコンピュ
ータ言語では通常、前記した理由から実行可能イメージ
を生成している。プログラムがユーザによって作成され
、コンパイルされた目的コードを生成する。次いで、目
的コードがリンカ−（Ｉ １ｎｋｅｒ）によってリンク
され、最終的な実行可能イメージを生成する。一方、サ
スペンドイメージは本質的に、システムのサスペンド時
点にメモリがどのようになっているかのスナップショト
（ダンプ）である。これは、リンカ−での使用に適さな
いフォーマットでのコード及びデータからなる。
ータ言語では通常、前記した理由から実行可能イメージ
を生成している。プログラムがユーザによって作成され
、コンパイルされた目的コードを生成する。次いで、目
的コードがリンカ−（Ｉ １ｎｋｅｒ）によってリンク
され、最終的な実行可能イメージを生成する。一方、サ
スペンドイメージは本質的に、システムのサスペンド時
点にメモリがどのようになっているかのスナップショト
（ダンプ）である。これは、リンカ−での使用に適さな
いフォーマットでのコード及びデータからなる。
言語は通常、一部のプロセッサで利用できない演算（例
えば三角関数）をサポートしているので、コンパイラデ
ベロッパがコンパイラ実行プロジェクトの一部として“
ランクイムサポート”機能を実行する。これらの機能は
通例、１つ以上のランタイムサポートライブラリ （Ｒ
ＴＬ）に含まれている。従って、実行可能プログラムを
生成するためには、リンカ−が前記ライブラリから選択
された機能を与えるコードを目的コードと組合せて、実
行可能イメージを形成しなければならない。リンカ−に
よって実施される前記及びその他の機能の結果、目的コ
ードは、元の目的ファイル内にあったその通りにはメモ
リ内に編成されない。
えば三角関数）をサポートしているので、コンパイラデ
ベロッパがコンパイラ実行プロジェクトの一部として“
ランクイムサポート”機能を実行する。これらの機能は
通例、１つ以上のランタイムサポートライブラリ （Ｒ
ＴＬ）に含まれている。従って、実行可能プログラムを
生成するためには、リンカ−が前記ライブラリから選択
された機能を与えるコードを目的コードと組合せて、実
行可能イメージを形成しなければならない。リンカ−に
よって実施される前記及びその他の機能の結果、目的コ
ードは、元の目的ファイル内にあったその通りにはメモ
リ内に編成されない。
目的コードが記憶されるメモリロケーションのこのよう
な変化は、はとんどのプログラムがコード内での相互依
存性を含んでいるので、問題を生じることがある。つま
り、目的コードがリンクされるときに起きるメモリの避
けられない再編成が、このような相互依存性に影響を及
ぼす。例えば、一つの命令がプログラム内の別の地点へ
の制御の転送を必要とすることがある（例えば“ｇｏ
ｔｏ”命令）。第１Ａ図は、Ｎ行の目的コードを含む目
的ファイルを示す。ロケーション１の地点Ａとロケーシ
ョン３の地点Ｂとの間に、相互依存性が存在することが
ある。これら両地点間のメモリ内における正確な変位が
、コードを正しく実行するために知られなければならな
い。目的ファイルの特殊命令部分がファイル内の全ての
相互依存性を記述し、リンカ−がこれらを用いて前記依
存性の問題を解決する。
な変化は、はとんどのプログラムがコード内での相互依
存性を含んでいるので、問題を生じることがある。つま
り、目的コードがリンクされるときに起きるメモリの避
けられない再編成が、このような相互依存性に影響を及
ぼす。例えば、一つの命令がプログラム内の別の地点へ
の制御の転送を必要とすることがある（例えば“ｇｏ
ｔｏ”命令）。第１Ａ図は、Ｎ行の目的コードを含む目
的ファイルを示す。ロケーション１の地点Ａとロケーシ
ョン３の地点Ｂとの間に、相互依存性が存在することが
ある。これら両地点間のメモリ内における正確な変位が
、コードを正しく実行するために知られなければならな
い。目的ファイルの特殊命令部分がファイル内の全ての
相互依存性を記述し、リンカ−がこれらを用いて前記依
存性の問題を解決する。
第１Ｂ図は、伝統的な実行可能ファイルを示している。
このファイルでは、図中１０で示す前述したようなラン
タイム機能などの機能をファイル内に含めることによっ
て、コードの各行が分離されている。両地点ＡとＢはよ
り大きく離れることになるので、コードはこの変化及び
その他の変化を含めるように修正されねばならない。こ
れらの修正は、目的ファイルの命令部分内に含まれた命
令に基づき、リンカ−によって行われる。
タイム機能などの機能をファイル内に含めることによっ
て、コードの各行が分離されている。両地点ＡとＢはよ
り大きく離れることになるので、コードはこの変化及び
その他の変化を含めるように修正されねばならない。こ
れらの修正は、目的ファイルの命令部分内に含まれた命
令に基づき、リンカ−によって行われる。
ＬＩＳＰなどの言語では、コンパイルされたコードが伝
統的な言語で生成された目的コードよりもはるかに複雑
である。ＬＩＳＰにおいて、コンパイルされたコードは
翻訳（ｉｎｔｅｒｐｒｅｔｅｄ）コード及びデータと自
由にミックス可能である。フォートランなどで形成され
たプログラムと異なり、ＬＩＳＰプログラムはインタプ
リタ、エデイフタ、デバグツール、ウィンドウ形成シス
テムなどのディベロソプメントツールを含んでいる。こ
の結果、コードが実行可能な形でランするのを保証する
ためには、実行可能なＬＩＳＰイメージを正しく生成し
得るリンカ−が、目的コードのフォーマント及び特殊命
令の処理に対して極めて複雑な変化を可能とするもので
なければならない。例えば、ＬＩＳＰで形成されたプロ
グラムにおいては、ソース（翻訳された）及び／又はコ
ンパイルされたファイルが、先にロードされたファイル
のフオーム／オブジェクトを再定義可能である。すなわ
ち、システムがある機能Ｆを定義するファイルを処理し
た後、機能Ｆを再定義する別のファイルを処理する場合
、このシステムはＦの古いヴアージョンを除去するよう
に働く。リンカ−はリンク時点で、この事実を認識でき
なければならない。また、伝統的な言語では記号がメモ
リ内のロケーションを表すに過ぎないが、ＬＩＳＰでの
記号はリンカ−によって評価されねばならない何等かの
機能性を含んでいる。ＬＩＳＰのオブジェクト（目的）
は自由にリロケート（再配置）可能で、ＬＩＳＰコード
の編成はリンクされたとき変化することがある。これら
のオブジェクトは全て、目的ファイル内で現れていたの
と同じように、実行可能イメージ内でも順次現れねばな
らない。かかる及びその他の複雑なＬＩＳＰ演算を正し
く処理するのに必要な高度のレベルを持つ、実用可能な
リンカ−は存在しない。
統的な言語で生成された目的コードよりもはるかに複雑
である。ＬＩＳＰにおいて、コンパイルされたコードは
翻訳（ｉｎｔｅｒｐｒｅｔｅｄ）コード及びデータと自
由にミックス可能である。フォートランなどで形成され
たプログラムと異なり、ＬＩＳＰプログラムはインタプ
リタ、エデイフタ、デバグツール、ウィンドウ形成シス
テムなどのディベロソプメントツールを含んでいる。こ
の結果、コードが実行可能な形でランするのを保証する
ためには、実行可能なＬＩＳＰイメージを正しく生成し
得るリンカ−が、目的コードのフォーマント及び特殊命
令の処理に対して極めて複雑な変化を可能とするもので
なければならない。例えば、ＬＩＳＰで形成されたプロ
グラムにおいては、ソース（翻訳された）及び／又はコ
ンパイルされたファイルが、先にロードされたファイル
のフオーム／オブジェクトを再定義可能である。すなわ
ち、システムがある機能Ｆを定義するファイルを処理し
た後、機能Ｆを再定義する別のファイルを処理する場合
、このシステムはＦの古いヴアージョンを除去するよう
に働く。リンカ−はリンク時点で、この事実を認識でき
なければならない。また、伝統的な言語では記号がメモ
リ内のロケーションを表すに過ぎないが、ＬＩＳＰでの
記号はリンカ−によって評価されねばならない何等かの
機能性を含んでいる。ＬＩＳＰのオブジェクト（目的）
は自由にリロケート（再配置）可能で、ＬＩＳＰコード
の編成はリンクされたとき変化することがある。これら
のオブジェクトは全て、目的ファイル内で現れていたの
と同じように、実行可能イメージ内でも順次現れねばな
らない。かかる及びその他の複雑なＬＩＳＰ演算を正し
く処理するのに必要な高度のレベルを持つ、実用可能な
リンカ−は存在しない。
そのため、ＬＩＳＰでのプログラミング環境は、サスペ
ンドイメージへのアクセスを与える小さい実行可能な“
核”と組み合わされた、全てのＬＩＳＰファイル（また
はモジュール）を含むサスペンドイメージとして市販さ
れている。核は、ＭａｃｒｏまたはＢＬＩＳＳなどの低
水準言語で書かれている。ユーザがＬＩＳＰシステムを
使いたいときは、その小さい核が実行されて、ＬＩＳＰ
環境の全てをメモリ （すなわちエデイツタ、インタプ
リタなど）内にロードする。典型的なＬＩＳＰシステム
のメモリレイアウトが第２図に示してあり、低水準言語
環境の部分をＬＩＳＰからアクセスし且つその逆を行う
のに使われるリンク式転送ベクトル；前述した実行可能
な核；ランタイムライブラリファイル；読取専用メモリ
：スタティックメモリ；２つのダイナミックメモリスペ
ース；及びビボップ（Ｂｉｂｏｐ）テーブルを含んでい
る。ビポップテーブルは、各ページのメモリに記憶され
たデータの種類に関する情報を含む。２つのダイナミッ
クメモリは、１つのメモリスペースから別のメモリスペ
ースへ（例えばダイナミック１からダイナミック０へ）
全ての有価値データを書き込むプロセスである“ガーベ
ージコレクション”を容易とするために使われる。
ンドイメージへのアクセスを与える小さい実行可能な“
核”と組み合わされた、全てのＬＩＳＰファイル（また
はモジュール）を含むサスペンドイメージとして市販さ
れている。核は、ＭａｃｒｏまたはＢＬＩＳＳなどの低
水準言語で書かれている。ユーザがＬＩＳＰシステムを
使いたいときは、その小さい核が実行されて、ＬＩＳＰ
環境の全てをメモリ （すなわちエデイツタ、インタプ
リタなど）内にロードする。典型的なＬＩＳＰシステム
のメモリレイアウトが第２図に示してあり、低水準言語
環境の部分をＬＩＳＰからアクセスし且つその逆を行う
のに使われるリンク式転送ベクトル；前述した実行可能
な核；ランタイムライブラリファイル；読取専用メモリ
：スタティックメモリ；２つのダイナミックメモリスペ
ース；及びビボップ（Ｂｉｂｏｐ）テーブルを含んでい
る。ビポップテーブルは、各ページのメモリに記憶され
たデータの種類に関する情報を含む。２つのダイナミッ
クメモリは、１つのメモリスペースから別のメモリスペ
ースへ（例えばダイナミック１からダイナミック０へ）
全ての有価値データを書き込むプロセスである“ガーベ
ージコレクション”を容易とするために使われる。
（課題を解決するための手段）
本発明は一般に、コードがリンクされて実行可能イメー
ジを形成する前に、１つ以上の選択ファイル内に含まれ
たコードを処理するシステムからなり、本システムは、
リンカ−がコードを記憶するメモリロケーションを判定
する手段；及び該判定されたメモリロケーションに従っ
てコードを修正する手段を備える。
ジを形成する前に、１つ以上の選択ファイル内に含まれ
たコードを処理するシステムからなり、本システムは、
リンカ−がコードを記憶するメモリロケーションを判定
する手段；及び該判定されたメモリロケーションに従っ
てコードを修正する手段を備える。
また本発明は一般に、コードがリンクされて実行可能イ
メージを形成する前に、コードを処理するシステムから
なり、本システムは、プログラミング環境からなるコー
ドを記憶する手段；ユーザによって供給されたコードを
記憶する手段；及びプログラミング環境からなるコード
の選択部分を削除する手段を備える。
メージを形成する前に、コードを処理するシステムから
なり、本システムは、プログラミング環境からなるコー
ドを記憶する手段；ユーザによって供給されたコードを
記憶する手段；及びプログラミング環境からなるコード
の選択部分を削除する手段を備える。
また本発明は一般に、コードがリンクされて実行可能イ
メージを形成する前に、１つ以上の選択ファイル内に含
まれたコードを処理するシステムからなり、本システム
は、コードを記憶する少なくとも第１及び第２の記憶手
段；及びコードを判定して、コードの各部分が記憶手段
のどこに記憶されるべきかを判定する手段；を備え、前
記評価手段の制御下で、第１または第２いずれかの記憶
手段にコードが記憶される。
メージを形成する前に、１つ以上の選択ファイル内に含
まれたコードを処理するシステムからなり、本システム
は、コードを記憶する少なくとも第１及び第２の記憶手
段；及びコードを判定して、コードの各部分が記憶手段
のどこに記憶されるべきかを判定する手段；を備え、前
記評価手段の制御下で、第１または第２いずれかの記憶
手段にコードが記憶される。
好ましい実施例では、プログラミング環境がＬＩＳＰで
あり、ＬＩＳＰ環境のどの部分（存在する場合）が最終
的な実行可能イメージ内に含まれないかをユーザが選択
する。コードがメモリ内のどこに記憶されるかを判定す
るために、使われるリンカ−に応じて、リンカ−がコー
ドを置く場所を制御する必要がある。好ましい実施例で
は読取専用、スタティック及びダイナミックメモリを用
い、ユーザコードの各部分はそれがロードされるとき適
切なメモリを選択するように評価される。
あり、ＬＩＳＰ環境のどの部分（存在する場合）が最終
的な実行可能イメージ内に含まれないかをユーザが選択
する。コードがメモリ内のどこに記憶されるかを判定す
るために、使われるリンカ−に応じて、リンカ−がコー
ドを置く場所を制御する必要がある。好ましい実施例で
は読取専用、スタティック及びダイナミックメモリを用
い、ユーザコードの各部分はそれがロードされるとき適
切なメモリを選択するように評価される。
本発明は、標準のリンカ−を用いて実行可能なＬＩＳＰ
イメージを生成できるため、従来技術と比べ著しく改善
されている。リンカ−が実行可能イメージのコードを記
憶する場所を予測し、コードがリンクされる前にそれに
基づきファイルを修正することによって、ＬＩＳＰファ
イルを連続的にリンクし、実行可能イメージを形成し得
る。
イメージを生成できるため、従来技術と比べ著しく改善
されている。リンカ−が実行可能イメージのコードを記
憶する場所を予測し、コードがリンクされる前にそれに
基づきファイルを修正することによって、ＬＩＳＰファ
イルを連続的にリンクし、実行可能イメージを形成し得
る。
ＬＩＳＰ環境コードの選択部分を削除する能力は、不必
要なコードを記憶するメモリが無駄にならないため有利
である。またＬＩＳＰコードの削除は、データが少なく
なるので“ガーベージコレクション”を行うのに費やさ
れる時間に関して有利であると共に、削除されるコード
は正当に保護されたコードで、その削除によって最終的
な実行可能イメージが自由に販売可能となるので、ライ
センスの条件についても有利である。更なる利点は、コ
ードを評価して、そのコードを正しい種類のメモリに割
り当てることによって達成される。従来のシステムでは
、ユーザによって入力された全てのコードが、スタティ
ック及びダイナミックメモリスペースに記憶されていた
。本発明ではユーザコードを評価し、それを（ユーザコ
ードの性質に応じて）可能な場合には読取専用またはス
タティックスペース内に記憶する。これは、読取専用ス
ペースを共有する能力（ダイナミック及びスタティック
スペースは共有可能でない）を含め、多くの理由から有
利である。
要なコードを記憶するメモリが無駄にならないため有利
である。またＬＩＳＰコードの削除は、データが少なく
なるので“ガーベージコレクション”を行うのに費やさ
れる時間に関して有利であると共に、削除されるコード
は正当に保護されたコードで、その削除によって最終的
な実行可能イメージが自由に販売可能となるので、ライ
センスの条件についても有利である。更なる利点は、コ
ードを評価して、そのコードを正しい種類のメモリに割
り当てることによって達成される。従来のシステムでは
、ユーザによって入力された全てのコードが、スタティ
ック及びダイナミックメモリスペースに記憶されていた
。本発明ではユーザコードを評価し、それを（ユーザコ
ードの性質に応じて）可能な場合には読取専用またはス
タティックスペース内に記憶する。これは、読取専用ス
ペースを共有する能力（ダイナミック及びスタティック
スペースは共有可能でない）を含め、多くの理由から有
利である。
（実施例）
動−作
実行可能なＬＩＳＰイメージを生成したいユーザは、Ｌ
ＩＳＰ環境を形成する標準の市販パッケージに付は加え
たいものがあれば、そのソースコードをまず書き込む。
ＩＳＰ環境を形成する標準の市販パッケージに付は加え
たいものがあれば、そのソースコードをまず書き込む。
ユーザは、自分のコードを発生するのにＬＴＳＰ環境、
あるいはその他何等かの環境どちらでも使える。ユーザ
コード及びデータは通常、Ｌｒ５Ｐシステムの動作前に
、テストされ、翻訳され、コンパイルされる。
あるいはその他何等かの環境どちらでも使える。ユーザ
コード及びデータは通常、Ｌｒ５Ｐシステムの動作前に
、テストされ、翻訳され、コンパイルされる。
その後、本発明のシステムが第４図のフローチャートに
示しであるように使われる。ユーザは、“フレッシュラ
ン” （すなわち新規スタートの）ＬＩＳＰシステムを
開始する（第１図のステップ１）。フレッシュランシス
テムは、他のイメージに関するファイルが現イメージの
発生で誤って使われる可能性を最小限とするのが好まし
い。次にユーザは、システムで使われるファイルを識別
することによって、生成すべき実行可能イメージを定義
する。これらのファイルは、ユーザのソースコードに応
じて発生されたコードのコンパイルコード（“ユーザコ
ード”）を含む（第４図のステップ２）他、ユーザが実
行可能イメージに入れたいＬＩＳＰ環境に関連したファ
イル（”ＬＩＳＰファイル”）を含む（第４図のステッ
プ３）。他のほとんどの言語と異戸り、ＬＩＳＰは最終
的な実行可能イメージ内にユーザソースコードを含むこ
ともできる。ＬＩＳＰファイルは、ユーザによって特に
除外されたものを除き、全てが含まれる。
示しであるように使われる。ユーザは、“フレッシュラ
ン” （すなわち新規スタートの）ＬＩＳＰシステムを
開始する（第１図のステップ１）。フレッシュランシス
テムは、他のイメージに関するファイルが現イメージの
発生で誤って使われる可能性を最小限とするのが好まし
い。次にユーザは、システムで使われるファイルを識別
することによって、生成すべき実行可能イメージを定義
する。これらのファイルは、ユーザのソースコードに応
じて発生されたコードのコンパイルコード（“ユーザコ
ード”）を含む（第４図のステップ２）他、ユーザが実
行可能イメージに入れたいＬＩＳＰ環境に関連したファ
イル（”ＬＩＳＰファイル”）を含む（第４図のステッ
プ３）。他のほとんどの言語と異戸り、ＬＩＳＰは最終
的な実行可能イメージ内にユーザソースコードを含むこ
ともできる。ＬＩＳＰファイルは、ユーザによって特に
除外されたものを除き、全てが含まれる。
例えば、生成すべきイメージがＬＩＳＰエデイツタを必
要としなければ、ユーザがそのように指定し、エデイフ
タは含まれない。この不必要なファイルの除去は、前述
したように幾つかの利点を有する。
要としなければ、ユーザがそのように指定し、エデイフ
タは含まれない。この不必要なファイルの除去は、前述
したように幾つかの利点を有する。
次にシステムは、前記の選択されたＬＩＳＰファイルと
、必要なランタイムライブラリファイルをロードする（
第４図のステップ４）。ステップ３で最終イメージから
除外されるべきものとユーザが指示したＬＩＳＰファイ
ルはロードステップ中にロードされず、従ってこれらの
ファイルによって与えられる機能は生成される実行可能
イメージ内に含まれない。ＬＩＳＰ環境のどの部分を削
除するかの選択は、最終的な実行可能イメージの意図す
る用途に依存する。例えば、コードまたはデータを追加
、変更または削除する必要があるユーザによって最終イ
メージが使われる場合には、エデイツタまたはデバガー
などのＬＩＳＰ環境が含まれる。一方、最終イメージの
ユーザがデータを入力してその結果を得るだけなら、エ
デイツタやデバガーなどのＬＩＳ、Ｐ環境は不必要とな
り、除去可能である。
、必要なランタイムライブラリファイルをロードする（
第４図のステップ４）。ステップ３で最終イメージから
除外されるべきものとユーザが指示したＬＩＳＰファイ
ルはロードステップ中にロードされず、従ってこれらの
ファイルによって与えられる機能は生成される実行可能
イメージ内に含まれない。ＬＩＳＰ環境のどの部分を削
除するかの選択は、最終的な実行可能イメージの意図す
る用途に依存する。例えば、コードまたはデータを追加
、変更または削除する必要があるユーザによって最終イ
メージが使われる場合には、エデイツタまたはデバガー
などのＬＩＳＰ環境が含まれる。一方、最終イメージの
ユーザがデータを入力してその結果を得るだけなら、エ
デイツタやデバガーなどのＬＩＳ、Ｐ環境は不必要とな
り、除去可能である。
次にシステムは、全てのユーザコードをメモリ内にロー
ドする（第４図のステップ５−１２）。
ドする（第４図のステップ５−１２）。
システムがユーザコードを評価し、第２図のメモリ構成
で、メモリ内のどこにそれが記憶されるべきかを判定す
る。命令（すなわち好ましい実施例ではＬＩＳＰ命令）
からなるユーザコードは、読取専用メモリ内にロードさ
れる（ステップ７）。
で、メモリ内のどこにそれが記憶されるべきかを判定す
る。命令（すなわち好ましい実施例ではＬＩＳＰ命令）
からなるユーザコードは、読取専用メモリ内にロードさ
れる（ステップ７）。
これが可能なのは、命令が変更可能でない（または変更
されるべきでない）からである。機能オブジェクトは、
共有可能でないスタティックメモリ内にロードされる（
スイッチ９）。ここでスタティックメモリを用いるのは
、最終イメージの異なるユーザは異なる機能を持つこと
があるため、このデータは共有可能とすべきでないから
である。
されるべきでない）からである。機能オブジェクトは、
共有可能でないスタティックメモリ内にロードされる（
スイッチ９）。ここでスタティックメモリを用いるのは
、最終イメージの異なるユーザは異なる機能を持つこと
があるため、このデータは共有可能とすべきでないから
である。
最終に、他の全てのユーザコードがダイナミックメモリ
内に記憶される（スイッチ１０）。これらのルールは、
アプリケーションに応じて変更できる。例えば、定数は
変化せず、誰にとっても同じであるべきなので、全ての
定数を読取専用メモリ内に記憶することも可能である。
内に記憶される（スイッチ１０）。これらのルールは、
アプリケーションに応じて変更できる。例えば、定数は
変化せず、誰にとっても同じであるべきなので、全ての
定数を読取専用メモリ内に記憶することも可能である。
前述したように、ＬＩＳＰの複雑な性質のため、ロード
されたファイルはこの時点がリンクできない。そのため
次のステップは、目的（及び場合によってソース）ファ
イルを、リンカ−が正しくリンク可能なファイルへと変
換することからなる。
されたファイルはこの時点がリンクできない。そのため
次のステップは、目的（及び場合によってソース）ファ
イルを、リンカ−が正しくリンク可能なファイルへと変
換することからなる。
システムは、リンク後にコードが記憶されるメモリ内の
ロケ−シランに従ってファイルを修正する（第４図のス
テップ１３−１６）。ファイルの修正時には、新たなメ
モリロケーションに応じていずれの相互依存性も修正さ
れねばならないため、システムは最終的な実行可能イメ
ージ内の各行のコードをリンカ−が記憶する場所を正確
に予測する（ステップ１３）。次にシステムは、各オブ
ジェクトの現メモリロケーションとその将来のロケーシ
ョンとの間のずれからなるテーブルを構成する（ステッ
プ１４）。そして、全てのポインタがそのテーブルを用
いて更新される（ステップ１５−１６）。
ロケ−シランに従ってファイルを修正する（第４図のス
テップ１３−１６）。ファイルの修正時には、新たなメ
モリロケーションに応じていずれの相互依存性も修正さ
れねばならないため、システムは最終的な実行可能イメ
ージ内の各行のコードをリンカ−が記憶する場所を正確
に予測する（ステップ１３）。次にシステムは、各オブ
ジェクトの現メモリロケーションとその将来のロケーシ
ョンとの間のずれからなるテーブルを構成する（ステッ
プ１４）。そして、全てのポインタがそのテーブルを用
いて更新される（ステップ１５−１６）。
ステップ１３の予測を行う際の困難は、その後に使われ
るリンカ−に依存する。一部のリンカ−はメモリを予測
可能な方法でアレンジする一方、別のリンカ−はもっと
ランダムにメモリを割り当てるからである。リンカ−が
データ及びコードを予測可能な方法で記憶しない場合に
は、処理後のファイルのリンク時に、リンカ−が予測可
能な方法で最終イメージをメモリ内へ入れるように“強
制”する必要がある。コード及びデータのロケーション
の予測不能は通例、サイズを予測できない何等かのもの
の後に、リンカ−がコード及びデータを記憶することか
ら生じる。“何等かのもの″のサイズが予測不能なため
、それがメモリ内のどこで終るのか予測できず、従って
コード及びデータファイルが始まる場所を予測すること
ができない、この点は、リンカ−によってメモリ内の高
い位置（すなわち予測不能なデータの前）にファイルを
記憶させることで解消できる。これで、正確なロケーシ
ョンが求められる。
るリンカ−に依存する。一部のリンカ−はメモリを予測
可能な方法でアレンジする一方、別のリンカ−はもっと
ランダムにメモリを割り当てるからである。リンカ−が
データ及びコードを予測可能な方法で記憶しない場合に
は、処理後のファイルのリンク時に、リンカ−が予測可
能な方法で最終イメージをメモリ内へ入れるように“強
制”する必要がある。コード及びデータのロケーション
の予測不能は通例、サイズを予測できない何等かのもの
の後に、リンカ−がコード及びデータを記憶することか
ら生じる。“何等かのもの″のサイズが予測不能なため
、それがメモリ内のどこで終るのか予測できず、従って
コード及びデータファイルが始まる場所を予測すること
ができない、この点は、リンカ−によってメモリ内の高
い位置（すなわち予測不能なデータの前）にファイルを
記憶させることで解消できる。これで、正確なロケーシ
ョンが求められる。
こうして、標準的なリンカ−でリンクされ、最終的な実
行可能イメージを生成するファイルの準備が整えられる
。最終的な実行可能イメージの一例が第３図に示しであ
る。尚、このイメージは小さいダイナミックスペースだ
けを含み、追加のダイナミックスペースがイメージのユ
ーザによって必要に応じ割り当てられるようになってい
る。
行可能イメージを生成するファイルの準備が整えられる
。最終的な実行可能イメージの一例が第３図に示しであ
る。尚、このイメージは小さいダイナミックスペースだ
けを含み、追加のダイナミックスペースがイメージのユ
ーザによって必要に応じ割り当てられるようになってい
る。
発明のその他の実施例は、特許請求の範囲内に含まれる
。
。
第１図は伝統的言語によってメモリ内に記憶されたコー
ドの構成を示す図、第２図はＬＩＳＰプログラミング環
境におけるメモリレイアウトの図、第３図は実行可能な
ＬＩＳＰイメージのメモリレイアウトの図、第４図は本
発明のシステムにょって実行されるステップを示すフロ
ーチャートである。 〜 Ｎ＋１ 寸 Ｌ／）ｔ。 弦
ドの構成を示す図、第２図はＬＩＳＰプログラミング環
境におけるメモリレイアウトの図、第３図は実行可能な
ＬＩＳＰイメージのメモリレイアウトの図、第４図は本
発明のシステムにょって実行されるステップを示すフロ
ーチャートである。 〜 Ｎ＋１ 寸 Ｌ／）ｔ。 弦
Claims (1)
- 【特許請求の範囲】 １、コードがリンクされて実行可能イメージを形成する
前に、１つ以上の選択ファイル内に含まれたコードを処
理する装置において： 前記コードのリンク後、前記コードがメモリ内で記憶さ
れるメモリロケーションを判定する手段：及び 前記判定手段によって判定された前記メモリロケーショ
ンに従って前記コードを修正する手段：を備えた装置。 ２、前記ファイルがユーザによって入力されたコードを
含む請求項１記載の装置。 ３、前記ファイルがプログラミング環境からなるコード
を含む請求項１記載の装置。 ４、前記プログラミング環境がＬＩＳＰである請求項３
記載の装置。 ５、リンカーが前記コードを記憶する場所を制御する手
段をさらに備えた請求項１記載の装置。 ６、前記プログラミング環境からなるコードの選択部分
を削除する手段をさらに備えた請求項３記載の装置。 ７、前記コードを記憶する第１及び第２の記憶手段をさ
らに備えた請求項１記載の装置。８、前記コードを評価
し、コードの各部分が前記記憶手段のどちらに記憶され
るべきかを判定する手段をさらに備え、前記コードが該
判定手段の制御下で記憶される請求項７記載の装置。 ９、コードがリンクされて実行可能イメージーを形成す
る前にコードを処理する装置において：プログラミング
環境からなるコードを記憶する手段： ユーザによって供給されたコードを記憶する手段：及び 前記プログラミング環境からなるコードの選択部分を削
除する手段： を備えた装置。 １０、前記削除手段が、前記選択部分を除く前記コード
の全てをロードする手段を備えた請求項９記載の装置。 １１、前記ユーザが前記選択部分を決める請求項９記載
の装置。 １２、コードがリンクされて実行可能イメージを形成す
る前に、１つ以上の選択ファイル内に含まれたコードを
処理する装置において： 前記コードを記憶する少なくとも第１及び第２の記憶手
段： 前記コードを評価して、コードの各部分が前記記憶手段
のどこに記憶されるべきかを判定する手段：及び 前記評価手段の制御下で、前記コードを前記第１または
第２いずれかの記憶手段に記憶する手段：を備えた装置
。 １３、前記第１の記憶手段が読取専用メモリからなる請
求項１２記載の装置。 １４、前記第２の記憶手段がスタティックメモリからな
る請求項１２記載の装置。 １５、第３の記憶手段をさらに備えた請求項１２記載の
装置。 １６、前記第３の記憶手段がダイナミックメモリからな
る請求項１５記載の装置。 １７、命令からなるコードが前記読取専用メモリ内に記
憶される請求項１３記載の装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US217322 | 1988-07-11 | ||
| US07/217,322 US5051893A (en) | 1988-07-11 | 1988-07-11 | System for processing data to facilitate the creation of executable images |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH0254337A true JPH0254337A (ja) | 1990-02-23 |
Family
ID=22810576
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP1165143A Pending JPH0254337A (ja) | 1988-07-11 | 1989-06-27 | 実行可能イメージの生成を容易とするデータ処理システム |
Country Status (3)
| Country | Link |
|---|---|
| US (2) | US5051893A (ja) |
| JP (1) | JPH0254337A (ja) |
| CA (1) | CA1319439C (ja) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ATE141423T1 (de) * | 1988-09-20 | 1996-08-15 | Digital Equipment Corp | Anordnung zur teilung eines generischen kodes für ein digitales datenverarbeitungssystem |
| EP0423989A3 (en) * | 1989-10-16 | 1992-09-23 | Hewlett-Packard Company | Software compiler and linker with improved line number table |
| AU651453B2 (en) * | 1991-03-07 | 1994-07-21 | Digital Equipment Corporation | Improved software debugging system and method especially adapted for code debugging within a multi-architecture environment |
| US5652869A (en) * | 1991-03-07 | 1997-07-29 | Digital Equipment Corporation | System for executing and debugging multiple codes in a multi-architecture environment using jacketing means for jacketing the cross-domain calls |
| US5418954A (en) * | 1991-06-19 | 1995-05-23 | Cadence Design Systems, Inc. | Method for preparing and dynamically loading context files |
| CA2061298C (en) * | 1992-02-17 | 1996-12-03 | Douglas J. Mortson | Method for detecting critical failures during the building of complex computer programs from source code parts |
| US5469572A (en) * | 1992-12-01 | 1995-11-21 | Taylor; James M. | Post compile optimizer for linkable object code |
| US5590331A (en) * | 1994-12-23 | 1996-12-31 | Sun Microsystems, Inc. | Method and apparatus for generating platform-standard object files containing machine-independent code |
| US5812854A (en) * | 1996-03-18 | 1998-09-22 | International Business Machines Corporation | Mechanism for integrating user-defined instructions with compiler-generated instructions and for optimizing the integrated instruction stream |
| US5815718A (en) * | 1996-05-30 | 1998-09-29 | Sun Microsystems, Inc. | Method and system for loading classes in read-only memory |
| US5991763A (en) * | 1996-10-29 | 1999-11-23 | Sun Microsystems, Inc. | Method and apparatus for embedding concatenated data files into object files during runtime in a virtual file system |
| GB2343021A (en) * | 1998-10-19 | 2000-04-26 | Ibm | Class loading model for object oriented programming |
| GB9920905D0 (en) * | 1999-09-03 | 1999-11-10 | Sgs Thomson Microelectronics | A relocation format for linking |
| US6745324B1 (en) * | 2000-11-16 | 2004-06-01 | International Business Machines Corporation | Dynamic firmware image creation from an object file stored in a reserved area of a data storage device of a redundant array of independent disks (RAID) system |
| EP1280056B1 (en) * | 2001-07-26 | 2011-10-05 | STMicroelectronics Limited | Generation of debugging information |
| US7237085B2 (en) * | 2004-05-28 | 2007-06-26 | Oracle International Corporation | Architecture for a scalable heap analysis tool |
| US7225297B2 (en) * | 2004-05-28 | 2007-05-29 | International Business Machines Corporation | Compressed cache lines incorporating embedded prefetch history data |
| US8151243B1 (en) * | 2006-06-06 | 2012-04-03 | Oracle America, Inc. | System and method for determining whether an array is a read-only array |
| US8413125B2 (en) * | 2007-01-26 | 2013-04-02 | Oracle International Corporation | Asynchronous dynamic compilation based on multi-session profiling to produce shared native code |
| US8341609B2 (en) * | 2007-01-26 | 2012-12-25 | Oracle International Corporation | Code generation in the presence of paged memory |
| US20110246966A1 (en) * | 2010-04-06 | 2011-10-06 | Sony Computer Entertainment America Inc. | Embedding source files into program symbol files |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4672532A (en) * | 1982-06-14 | 1987-06-09 | Tektronix, Inc. | Software/hardware integration control system |
| US4667290A (en) * | 1984-09-10 | 1987-05-19 | 501 Philon, Inc. | Compilers using a universal intermediate language |
| US4734854A (en) * | 1985-10-08 | 1988-03-29 | American Telephone And Telegraph Company | System for generating software source code components |
| JPS62159274A (ja) * | 1986-01-08 | 1987-07-15 | Hitachi Ltd | 条件分岐の分割・複写によるベクトル化方式 |
| US4949255A (en) * | 1988-09-07 | 1990-08-14 | International Business Machines Corp. | Message interface and method for recursive calling between interpretive and compiled computer processes |
-
1988
- 1988-07-11 US US07/217,322 patent/US5051893A/en not_active Expired - Lifetime
-
1989
- 1989-06-19 CA CA000603213A patent/CA1319439C/en not_active Expired - Fee Related
- 1989-06-27 JP JP1165143A patent/JPH0254337A/ja active Pending
-
1993
- 1993-03-25 US US08/037,714 patent/US5303380A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA1319439C (en) | 1993-06-22 |
| US5303380A (en) | 1994-04-12 |
| US5051893A (en) | 1991-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5051893A (en) | System for processing data to facilitate the creation of executable images | |
| US5729748A (en) | Call template builder and method | |
| US5339406A (en) | Reconstructing symbol definitions of a dynamically configurable operating system defined at the time of a system crash | |
| JP3550151B2 (ja) | ロード・リンキング装置および方法 | |
| US5636366A (en) | System and method for preserving instruction state-atomicity for translated program | |
| US5303392A (en) | Accessing current symbol definitions in a dynamically configurable operating system | |
| JP5039031B2 (ja) | ネイティブコード及び目的コードをプログラムコード変換中に組み合わせて実行する方法及び装置 | |
| EP0665496B1 (en) | Method and apparatus for run-time error checking using dynamic patching | |
| US6298479B1 (en) | Method and system for compiling and linking source files | |
| US20050278318A1 (en) | Iterative development with prioritized build | |
| US5418954A (en) | Method for preparing and dynamically loading context files | |
| JPH08512154A (ja) | 増分リンカ・システム | |
| JP2000347874A (ja) | レジスタ割当器を用いた呼出規則プロローグ・エピローグコード構築方法及び装置 | |
| JP2002525707A (ja) | バーチャルコールのインライン化のための精確な方法 | |
| US5062039A (en) | Sharing of workspaces in interactive processing using workspace name tables for linking of workspaces | |
| US5617564A (en) | Program source file preprocessing method and apparatus to detect modifications and generate a class of files | |
| US6526407B1 (en) | Method for supporting multiple file-systems in file input/output operations | |
| US5150474A (en) | Method for transferring arguments between object programs by switching address modes according to mode identifying flag | |
| GB2342200A (en) | Initializing global registers | |
| JP2001022560A (ja) | ライブラリ関数バージョンアップ方法 | |
| US20090265697A1 (en) | Methods, Devices and Software Applications for Facilitating a Development of a Computer Program | |
| US7076780B2 (en) | Application program interface for a computer program | |
| JP2006048431A (ja) | 動的リンクライブラリ処理装置 | |
| KR20000003162A (ko) | 효율적인 플래시 메모리 운용 방법 | |
| JPH01207824A (ja) | モジュール結合制御方式 |