JPH0731604B2 - 目標コンピュータ・システム、異なるコンピュータ・システム間でプログラムを実行する方法 - Google Patents

Description

【発明の詳細な説明】 ［産業上の利用分野］ 本発明はコンピュータ・プログラムのコード翻訳分野に
関する。

［従来の技術］ 歴史的に見て、FORTRAN、COBOL及びPL/1等の硬度なコン
ピュータ・ソース言語はプログラミングを容易にするば
かりでなく、プログラムがマシンから独立した言語で書
き込まれ、その後、コンパイラによりマシン依存性の目
的コード形態に翻訳されるようにすることによって、種
々のコンピュータ間に移動可能とするように開発され
た。従って、コンピュータの使用者や供給者はソフトウ
ェア・システムの開発に当たり、（しばしば膨大な）調
査を行い、その調査の利益を失わずに自己のコンピュー
タ・ハードウェアを比較的易い費用でグレードアップす
る手段を講じていた。

しかしながら、コンパイラ技術は完全な解決策ではな
い。例えば、あるプログラムに対するソースコードは、
それを所有する当事者がそれの再コンパイル（再編集）
を有効とすることを望まない場合や、旧式プログラムの
場合それが単に失われてしまっていて、利用できないこ
とがある。更に、種々のハードウェア構成間の非同一性
を解決することはコンパイラ技術の範囲を越えているこ
とがある。コンパイラの基本機能は、あるプロセッサと
他のプロセッサとのマセンティック（意味）及びシンタ
ックス（構文）の違いを分析することであって、コンピ
ュータ・ハードウェアやオペレーティング・システムの
特有な特色の違いを分析することではない。例えば、あ
るコンピュータの特殊なグラフィック能力を利用するプ
ログラムは、簡単にはこれらの能力を持たないマシン上
でラン（作業）するように再コンパイルすることはでき
ない。（本明細書では、用語「コンピュータ」及び「マ
シン」が相互に入れ替えて使用される。） 上記考察はパーソナル・コンピュータの開発で重要性を
増して来ている。多くの種類のハードウェア装置が市場
に導入されており、コンパイラ技術の上記制限の為に、
ワード・プロセッサやグラフィック向きパッケージのよ
うな複雑なプログラムをあるハードウェア装置から他の
ハードウェア装置へ移入することは高価である。このこ
とが、市場への新しいハードウェアの導入に比較し、プ
ログラムの開発に遅れを来している。すなわち、ソフト
ウェア開発者はそのハードウェアの充分な販売がその移
入努力に妥当な見返りの見込みが明らかになるまでその
移入を行おうとするリソース（資源）に関わるのをため
らって来た。同じ理由によって、コンピュータの供給者
は、第三者であるソフトウェア開発者が彼等のソフトウ
ェアをその新しいハードウェア基盤へ移入するのに関わ
るのを待って、彼等が自己のハードウェアを市場へ供給
（実捕捉）して利益を上げることができる。

この状況に応じて、ある供給者は、最初のコンピュータ
即ち「ソース」コンピュータ上で実行するように設計さ
れたソフトウェアの非移入バージョンが、別の「目標」
コンピュータ上で実行するように為されていることに基
づいてスキーマを開発してきた。このようなスキーマ
は、いわゆるハードウェア及びソフトウェアのエミュレ
ーションを含む。

特にハードウェア・エミュレーションは、例えば、ソー
スコンピュータの機能性をハードウェアに複製するコー
プロセッサの導入を含む。このアプローチの利点はソー
スマシンのものと類似する性能及び開発された大概のア
プリケーションを実行する能力を含む。しかしながら、
ソースマシンの必要な機能性を有効のある費用で正確に
複製することは極めて困難である。実際、ソースマシン
と目標マシンとの間の体系的な相違（例えば、バス体系
の相違）の為に、しばしば、ソースマシンに使用された
ある非標準の周辺装置（例えば、グラフィック・コント
ローラ）は、目標マシン中で支援されず、そのためその
ような周辺装置が存在することに依拠しているプログラ
ムの目標マシン上での実行が排除される場合がある。こ
のようなハードウェア・エミュレーションのアプローチ
では、それらは市場でほんの限られた成功しか得られな
かった。

他のアプローチ、即ちソフトウェア・エミュレーション
は、いわゆるエミュレーション・ソフトウェアの使用を
意味し、このエミュレーション・ソフトウェアは実時間
での入力として、ソースマシンに対してコンパイルされ
た目的コード・プログラムを取り、それが実行されるの
に必要な核インストラクション（命令）を識別し、元の
インストラクションの機能性を複製する一続きの目標マ
シン・インストラクションを実行することによって、目
標マシン上で同等な演算を実行する。これは、目標マシ
ン・インストラクションをソースマシン・インストラク
ションに翻訳する効力を持っている。ソースマシン・イ
ンストラクションがオペレーティング・システム又はソ
ースマシンの他の特有のマシン・サービスを呼び出した
ような場合には、エミユレーション・ソフトウェアは更
に、そのような呼び出しの各々が起きるのを認識し、対
応する目標マシン・サービスをアクセスするソフトウェ
アを含まなければならない。

ソフトウェア・エミュレーション・アプローチの利点の
一つは、それが実際上比較的安価であることである。更
に、エミュレーション・ソフトウェアは、二つのこと、
即ち,a）ソースマシンと目標マシンの一方又は双方に生
じた変化、ｂ）エミュレーション・ソフトウェア自身に
必要な訂正、例えば、「バグ（虫）」の補修、の二つに
適応するように容易に修正できる。一方、ソース・ハー
ドウェア上で実行するソースプログラムのものと類似な
性能で、エミュレーションが目標マシン上で実行するた
めに、目標マシン・ハードウェアは、以下に述べるよう
なソースマシン・ハードウェアのものより実質的に優れ
た性能を用意しなければならない。ソースウシマシンの
能力に従って、この規準は妥当な費用で達成することが
できる。ソフトウェア・エミュレーションが目標マシン
に優れた性能を必要とする理由には少なくとも二つ有
り、この二つはソフトウェア・エミュレーションが実時
間的性格のものであるせいである。その第一は、エミュ
レートしている目標マシン・インストラクションの実際
の実行に加えて、入力ストリームに対応している各ソー
スマシン・インストラクションを先ず変換するのに時間
がかかるという事実に関係している。第二の理由は、一
組のソース・プロセッサ・インストラクションの主効力
及び副効力の双方を複製する必要があることに関係して
いる。

あるインストラクションの主効力は、その表現が意味す
るように、そのインストラクションの基本的な目的であ
る。（例えば、ADD（加算）インストラクションの主効
力は二つの量を加算することにあり、JUMP（飛び越し）
インストラクションの主効力は制御のフローを変えるこ
とにある）。対照的に、副効力は、実行しているプログ
ラムにより更に参照するために、ハードウェアによって
保持されているインストラクションの実行から得られる
数片の情報である。（ここで使用されているような表現
「副効力」は、以下により厳密に定義される）。例え
ば、副効力は条件コード・レジスタを設定することを含
む。エミュレーション・ソフトウェアがインストラクシ
ョン毎の原理で動作する限り、そしてその結果、そのよ
うな副効力が極めて希にその実行中に後で参照されよう
なときは決定できない限り、全ての副効力は目標マシン
中で複写されなければならない。ソースマシン中でこれ
らの副効力は、インストラクション自体の肝要な部分と
してプロセッサ・ハードウェアによって実行されるの
で、それらはソースマシン中の性能にひどく影響するこ
とはない。しかしながら、ソースマシン及び目標マシン
で使用されているプロセッサでの相違は、典型的には目
標マシン上でのソフトウェア・エミュレーションの個々
のインストラクションの実行が、ソースマシン上で実行
されているソースインストラクションのものとは完全に
違っている副効力になるかもしれないことである。従っ
て、目標マシン上に同等な副効力を持たない各ソースマ
シンの各副効力が別の目標マシン・インストラクション
又はインストラクション列を介して目標マシン上ではっ
きりとエミュレートされなければならない。この結果、
プログラム・コードは大量に拡大してしまう。

上記の結果、単にソースマシン上で実行されるプログラ
ムのものと類似な性能を用意するために、ソースマシン
が一つのインストラクションを実行する時間に、目標マ
シンは大量のインストラクションを実行できる能力がな
ければならない。これは、もしソースマシンが旧く技術
が劣ったものであれば、そしてこの場合に実質的に優れ
た性能を持つ目標マシンが妥当な費用で旨く利用できる
なら、たやすく達成できるであろう。しかしながら、不
都合にも、もしソースマシン及び目標マシンの双方とも
似た技術のものであると、使用者は実質的に劣った性能
を容認するか、又は機能は優れているが疑いなく費用が
嵩む目標マシンに投資しなければならない。

他のマシン向けに開発されたソフトウェアを目標マシン
上で実行する第三のアプローチは、「翻訳」と呼ばれ
る、上記で略述したようてハードウェア及びソフトウェ
ア・エミュレーションの双方の欠点のうち少なくともそ
の幾らかを克服するアプローチである。

翻訳はソフトウェア・エミュレーションに似ていて、そ
れは、典型的には、ソースマシン向けにコンパイルされ
た目的コード・プログラムをその入力として取り、ソー
スマシン・インストラクションを、一組のソース・プロ
セッサ・インストラクションの主効力及び副効力の双方
を複製する一つ以上の目標マシンの目的コード・インス
トラクションに翻訳するソフトウェアを使用することを
意味する。しかしながら、ソフトウェア・エミュレーシ
ョンのアプローチは、実時間でソースマシン・インスト
ラクションを処理することを意味し、即ち、それらはプ
ログラム入力ストリーム中で応対されるが、翻訳はこれ
を「オフライン」で行い、その結果得られた目標マシン
・インストラクションを後での実行のために保存する。
このアプローチの利点は、ソースマシン・インストラク
ションの翻訳を実行時間に遂行する必要性によって引き
起こされる性能の損失が回避されることである。しかし
ながら、不都合にも、この翻訳は典型的に、上記したよ
うに、プログラム・コードの前記拡大のせいで大量の保
存スペースを必要とする。更に、この翻訳は以前として
副効力をエミュレートしなければならないので、これは
ソフトウェア・エミュレーションと同じく性能低下の悩
みを持つ可能性がある。

（発明の概要） 翻訳及びエミュレーションの双方の場合に於ては、実行
ソフトウェア、例えば、割り込み制御装置のレジスタへ
アクセスし得るソースマシンのハードウェア・システム
資源（resources）のみならず、ソースマシンのソフト
ウェア・システム資源（例えば、オペレーティング・シ
ステム機能）は、いわゆるシステム・シミュレーション
を介して目標マシン上に実現される。このシステム・シ
ミュレーションの目的は、相当するサービスを持つソー
スマシンのサービスを目標マシン上に機能的に複製する
ことである。同様なサービスを各マシンに設けることも
できるが、これらのサービスをアクセスする際に伴う意
味（semantics）及び構文（Syntax）が必然的に相違す
る。幾つかの場合には、ソースマシン上の一つのサービ
スをシミュレートするために、目標マシン上でのサービ
スを結合することが必要となる。従って、この様なシス
テム・シミュレーションを生み出す処理は、ソースマシ
ンによって設けられたシステム・サービスを分析し、こ
れらソースマシンのサービスを目標マシンのサービスへ
写像し、そしてこの写真を実現するソフトウェアを開発
することが必要とされる。エミュレーションの場合に
は、このシステム・シミュレーションがエミュレーショ
ン・ソフトウェア・パッケージの一部である。このエミ
ュレーション・ソフトウェアは、実行時間に意図されて
いるシステム・アクセスを認識し、このシミュレーショ
ンを介してその意図された機能を実行する。翻訳の場合
には、このシミュレーションは共通に配分可能なライブ
ラリーの一部であり、システム資源へのアクセスはこの
翻訳処理中に認識され、規準に従ってそのライブラリー
中の適当なシステム・シミュレーション・ソフトウェア
に置き換えられる。その後、この翻訳は、そのライブラ
リーへ向かわされ、その結果、このシステム・シミュレ
ーションはその翻訳の重要な部分となる。

所与のエミュレーション又は翻訳環境に対するシミュレ
ーションの展開は、ａ）ソースマシンの機能性が目標マ
シン上に複製可能であり、即ち各マシンに類似するシス
テム資源が存在し、且つ、ｂ）ソースマシンのシステム
・ソフトウェアの機能性がそれを正確に複製するのを不
可能にする程、複雑でない限り、事実上、かなり容易に
達成される。しかしながら、現今の市場には少なくとも
幾つかの大衆向きのコンピュータが存在し、これらに対
して大量の応用ソフトウェアが開発されてきており、そ
れらコンピュータのシステム・ソフトウェアの複雑性は
シミュレーション展開を極めて困難にし、その結果、実
際上の見地から、これらのアプリケーションのエミュレ
ーション又は翻訳を排除する程である。

本発明は、この問題を解決する。本発明によれば、特定
のソースマシン／目標マシンの対に書き込まれたソース
のソフトウェアが、そのソースマシンのシステム・ソフ
トウェアの少なくとも数部分を翻訳するのに使用され
る。目標マシン上で実行されるべく翻訳されたアプリケ
ーションは、その翻訳されたシステム・ソフトウェア向
けとなるか、さもなければそれに当てられる。これは、
翻訳されたアプリケーションが少なくとも幾つかの特定
システム・サービスを必要とするとき、単なるシミュレ
ーション、即ちその機能的に書き直されたバージョンで
はなく、これらのサービスを履行するソースマシンのシ
ステム・ソフトウェア・プログラムの翻訳されたバージ
ョンである。

この考察により、その実行システム・ソフトウェアはソ
ースマシンのシステム・ソフトウェアの翻訳であるか
ら、そのソフトウェアによって参照された全てのアドレ
スは、そのソースマシンのメモリの記憶位置及びメモリ
装置のアドレスとなろう。しかしながら、ソースマシン
及び目標マシンのアドレス割り当てスキーマ（schem
a）、いわゆるアドレス空間は、決まって相違する。こ
のことは、参照されるアドレスが、装置非関連な、ある
いは「普通の」RAMの記憶位置はお互いから区別できな
いので、両マシンの普通RAMの記憶位置に対応する程度
までは問題ではない。しかしながら、更に何らかのこと
が講じられないと、２つのアドレス空間の相違が、特定
のハードウェア装置に関連付けられた記憶位置に対して
試みられるアクセスが一般的には正しく遂行されなくす
るであろう。

本発明の特徴に従って、都合よく、実際上のハードウェ
ア環境が、この様な状況を取り扱うために目標マシンに
備えられる。この環境は、ソースマシンのアドレス空間
に於ける全てのアドレスが、目標マシンに於ける普通RA
Mの記憶位置に対応するように設定される。これによっ
て、ソースマシンの全アドレス空間のいわゆる「イメー
ジ」が、目標マシン上の普通RAMに与えられる。このよ
うに、翻訳実行システムあるいは応用ソフトウェアによ
って、ソースマシンの何らかの部分に試みられるどのよ
うなアクセスも、事実（そのような記憶位置の読み出し
又は書き込みが達成されて）成功するであろう。勿論、
アクセスがハードウェア装置に対して試みられた場合
は、ことごとくこのアクセスが、かわって普通RAMへの
又はそれからのアクセスにも、事実、為されるであろ
う。しかしながら、翻訳ソフトウェアの要素（ここでは
実際上のハードウェア項目モニターとして言及する）
は、ソースマシンのハードウェア装置に相当するイメー
ジ中の全記憶位置の状態を周期的にチェックし、もし最
終チェック以後の変化が観測されると、目標マシンのシ
ステム・サービスの補助を得るか、又は目標マシンのハ
ードウェアを直接アクセスすることによって、目標マシ
ンに於て意図されている機能演算を遂行する。更に、実
際上のハードウェア項目モニターもまた、目標マシンの
ハードウェアをモニターし、ソースマシンのイメージに
於ける何らかの対応記憶位置を更新する。この結果、目
標マシンのハードウェアの状態変化が、翻訳実行システ
ムあるいは応用ソフトウェアに認識されるであろう。

上記で考察した実際上のハードウェア環境を履行する上
での副産物は、システム・ソフトウェアと同じようにし
てソースマシンのアドレス空間をアクセスするので、い
わゆる浮浪プログラムと呼ばれるプログラムの翻訳を支
援する能力があることである。こうして、翻訳されたシ
ステム・ソフトウェアを支援するための上記した機構
は、また浮浪プログラムを支援するであろう。

（実施例の説明） エミュレション及び翻訳の概説 ソースコンピュータ 第１図のコンピュータ100はパーソナル・コンピュータ
であり、その要部はアドレス、データ及び一般的にバス
121として示された制御バスを有するプロセッサ111であ
る。バス121には、幾つかの周辺装置が接続される。こ
の周辺装置には、その内容がビデオ・コントローラ113
でCRT114向けにビデオ信号を発生するために使用される
表示メモリ112;プロセッサ111間で直列インタフェース
として働き、他方では、符号116で総合的に示されるキ
ーボード及びマウスとして働く、汎用非同期レシーバ・
トランスミッタ（UART）115;ハードウェアの割り込みリ
ード（図示せず）が、中でもUART115からそこへ延長さ
れる割り込みコントローラ117、プロセッサ111とフロッ
ピー・ディスク・メモリ129との間のインタフェースと
して働くフロッピー・ディスク・コントローラ128;プロ
セッサ111とハード・ディスク・メモリ133との間のイン
タフェースとして働くハード・ディスク・コントローラ
131;プログラムの実行によって作成され、且つ又は使用
されるのみならず、一般に実行のために使用できるプロ
グラム（以下に述べるオペレティング・システムを含
む）のコピーを保持するランダム・アクセス・メモリ
（RAM）134;及びリード・オンリー・メモリ（ROM）135
を含む。

100は、そのいわゆるシステム・ソフトウェアの制御の
下で動作する。このシステム・ソフトウェアはアプリケ
ーションのために種々のサービスを実行し、且つコンピ
ュータの全体に亘る機能を管理するものである。こうし
て、例えば、このシステ・ソフトウェアは、ファイルお
よびメモリの管理サービス；表示装置、キーボード及び
マウスの入力／出力（I/O）機能；ポートの直列管理等
を提供する。

コンピュータ100のシステム・ソフトウェアは例示的に
は、二つの要素、即ち、基本入力／出力システム（BIO
S）及びオペレティング・システムとを有する。

コンピュータのBIOSは、不揮発性メモリ、即ち、ROM中
に存在し、この理由から、しばしば、ROM BIOSとして言
及される。特に、コンピュータ100中でROM BIOSはROM13
5中に存在し、1351で示される。ROM BIOS1351は、ハー
ド・ディスク及びフロッピー・ディスク双方への低レベ
ルでのアクセスを提供するだけでなく、上記した表示装
置、キーボード及びマウスの機能のような基本入力／出
力サービスを実行するためのソフトウェア手順を含む。
ROM BIOS1351は更に「ブート・ローダ」としての手順を
含む。この手順は、コンピュータが電源投入されたとき
に、いわゆるハードウェア・リセット機構を介して呼び
出される。その基本機能は、マシン機能の基本チェック
を実行し、それからシステム・ソフトウェア（オペレテ
ィング・システム1331）の残りを、ハード・ディスク13
3からRAM134へロードすることである。こうしてRAMにロ
ードされて、オペレティング・システムは後続の実行の
ために使用できるようになる。事実、ROM BIOSはブート
・ローダの実行が終了したときに、制御をオペレティン
グ・システムへ回す。オペレティング・システム1331
は、システム・ソフトウェアの残り、従って、上記した
ようにコンピュータの全体に亘る機能の管理、ファイル
及びメモリの管理サービスの提供、ポートの直列管理等
を行う手順を含む。

ソフトウェアの実行の見地から、BIOSとオペレティング
・システムの間、或いはRAMとROMの間のシステム・ソフ
トウェアを特に分離することは重要ではない。例えば、
幾つかのマシンでは、全システム・ソフトウェアがROM
中に在り、一方、他のマシンでは、ブート・ローダのみ
がROM中に記憶される。しかしながら、システム・ソフ
トウェアを翻訳する概念を履行することは、以下に詳述
するように、システム・ソフトウェアが特定のソースコ
ンピュータに於いてRAMとROMの間をたまたま分離する仕
方には全く依存しないことは注目されよう。

アドレス空間 プロセッサ111は、バス121を介してそのバスのアドレス
・リードにアドレスを給与し、且つ、同時にアドレスさ
れている装置に向けられたコマンド及びデータを、デー
タ・リード及びコントロール・リードに供給することに
よって、その種々の周辺装置と通じる。事実、アクセス
されている装置が（ROM又はRAM）のメモリ位置として物
理的に履行すされるか、或いはいわゆるハードウェア装
置又は周辺装置例えばディスク・コントローラ・レヂス
タとして物理的に履行されるかどうかで、類似した動作
が使用される。特定の装置に関連付けられたアドレス
は、しばしば製造時に固定され、そのようなアドレスの
全体は、コンピュータの「アドレス空間」として言及さ
れる。

第４図は、ソースコンピュータの「アドレス空間」の例
の論理図を提供する。特に、いわゆる割り込みベクトル
（RAMに記憶されている）は、記憶位置０で始まるアド
レス空間に置かれ、幾つかの割り込み制御装置レヂスタ
は（16進）記憶位置0x000400で始まるアドレス空間に置
かれ、幾つかのフロッピー・ディスク制御装置レヂスタ
は記憶位置0x000410で始まるアドレス空間に置かれ、幾
つかのハード・ディスク制御装置レヂスタは記憶位置0x
000420で始まるアドレス空間に置かれ、クロック・レヂ
スタは記憶位置0x000430で始まるアドレス空間に置か
れ、RAMアドレスは再び記憶位置0x000434を占め、ROM B
IOS及び他のファームウェアは記憶位置0x00000で始まる
アドレス空間に置かれ、そして表示メモリは記憶位置0x
ff6000で始まり0xffffffで終了するアドレス空間に置か
れる。

しばしば、ハードウェア設計で強制される約束により、
アプリケーション・プログラムは、単に、アドレス空間
のRAMに対応する部分をアクセスするものと仮定され
る。アドレス空間の他の部分全ては、システム・ソフト
ウェア、即ちオペレティング・システム及びROM BIOSに
よって排他的にアクセスするものと仮定される。このよ
うに、アドレス空間のそのような他の部分との通信を要
求するアプリケーションは、そのアプリケーションのた
めのアクセスを実行するシステム・ソフトウェア内での
特定の手順を呼び出すことでその通信を要求するものと
仮定される。システム・ソフトウェアを迂回することに
より性能を改善するため、これらの約束を無視するアプ
リケーションは、以下で更に詳論するように「浮浪者
（rogue）」と称される。

この点で、最初のソースマシンに対して第二の目標マシ
ン上にコンパイルされたプログラムを実行するための、
ハードウェア・エミュレーション、ソフトウェア・エミ
ュレーション及び翻訳に対する従来技術のアプローチを
幾らか詳しく検討することは有益であろう。

一般に、コンピュータは、タイプが異なる毎に異なるア
ドレス空間レイアウトを持っている。このことは、又、
第４図に示されている。即ち、第４図は、更に、ソース
コンピュータのためにコンパイルされたアプリケーショ
ンが（ハードウェア・エミュレーション或いはソフトウ
ェア・エミュレーションの何れかを用いて）エミュレー
ト或いは翻訳する目標マシンのアドレス空間の説明図を
示す。

ソースマシン及び目標マシンのアドレス空間レイアウト
は、典型的によく有るように、異なることに注意を要す
る。特に、目標マシンの（RAMに記憶された）割り込み
ベクトルは記憶位置０で始まるアドレス空間に置かれ、
幾つかのハード・ディスク制御装置レヂスタは記憶位置
0x10000で始まるアドレス空間に置かれ、幾つかのフロ
ッピー・ディスク制御装置レヂスタは記憶位置0x1020で
始まるアドレス空間に置かれ、幾つかの割り込みベクト
ルは記憶位置0x1040で始まるアドレス空間に置かれ、表
示メモリは記憶位置0x1060で始まるアドレス空間に置か
れ、クロック・レヂスタは記憶位置0x6000で始まるアド
レス空間に置かれ、RAMアドレスは記憶位置0x6004で始
まるアドレス空間に置かれ、ROM BIOS及び他のファーム
ウェアは記憶位置0xf00000で始まり0xffffffで終了する
アドレス空間に置かれる。

ソースマシンと目標マシンのアドレス空間の間には、更
に他のタイプの差異が有ってもよい。例えば、あるマシ
ンは、メモリをアクセスするためと入力／出力（I/O）
装置をアクセスするためとで分離されたアドレス空間を
持つことができる。これらは、実際には全てのものを含
んでいる単一の（但し、大きな）アドレス空間を持つも
のと同じである。従って、続いて為される論考では、ア
ドレス空間の語は常にI/Oのみならずメモリを包含する
ものとして考慮し、且つアドレスはメモリの記憶位置又
はI/O装置レヂスタの何れかに言及することができる。

ソースマシンと目標マシンとのアドレス空間の相違は、
ソースマシンのアドレス空間の全体を、第４図に示すよ
うに、記憶位置0xc000及び0x100bfffの間の、目標マシ
ンのアドレス空間のRAM部へ写像することによる（ハー
ドウェア又はソフトウェアの）エミュレーション及び翻
訳に於いて説明される。こうして、実際のソースマシン
のアドレス空間の記憶位置及びその目標マシンのアドレ
ス空間内のいわゆる「イメージ」間に一対一の対応が有
る。従って、種々のエミュレート又は翻訳されたプログ
ラム・インストラクションに含まれるアドレスにオフセ
ットを加えることはエミュレーション又は翻訳ソフトウ
ェアに対して簡単な事項であり、その結果、それらはソ
ースマシンのアドレス空間のイメージ内の適切な記憶位
置に関係する。こうして、例えば、ソースマシン・イン
ストラクションに現れるアドレス０は、対応するエミュ
レート又は翻訳された、対応するインストラクション中
のアドレス0xc000に変換される等するであろう。そのア
プリケーションが「浮浪者」でない限り、その正しい機
能はこのアプローチによって維持される、何故なら、ア
ドレス空間の記憶位置へ非「浮浪者」プログラムが参照
するの常にRAMへの参照である。RAMの記憶位置は他のも
のと区別できないから、ソフトウェアのエミュレーショ
ン又は翻訳を実行することによりRAM中の特定な記憶位
置にアクセスすることは、事実、旨くいくであろう。他
方、一般にソースマシンのアドレス空間の種々の非RAM
部分と目標マシン中のそれらのイメージとの間の対応性
は、上記で触れたように、個々のアドレス空間のレイア
ウトが殆ど常に相違しているために失われる。例えば、
第４図に於いて、ソースマシンの装置レヂスタのアドレ
スは目標マシン中の割り込みベクトルのアドレスであ
る。従って、もしソースマシンに対してコンパイルされ
たアプリケーションが、直接ソースマシンの装置レヂス
タの記憶位置を読み出す（即ち、そのアプリケーション
は「浮浪者」である）と、この読み出しは、メモリ動作
の見地から、旨くいくが、しかし勿論不正確が読み出さ
れてしまう。

理屈では、ソースマシンのアプリケーション・プログラ
ム・インストラクション中に現れる種々の非RAMのソー
スマシン・アドレスは認識されて目標マシンのアドレス
空間中の対応するアドレスに写像される。しかしなが
ら、コンピュータ自体に存在する相違、例えば、異なっ
た製造者が所与の総称的タイプを持つ周辺装置、例えば
ハード・ディスク制御装置を実現するように規制してい
る約束に相違が存在することは、殆ど常に、そのような
写像が不可能であることを意味している。従って、エミ
ュレーション及び翻訳への公知なアプローチは、簡単に
は効果的に「浮浪者」プログラムを取り扱うことはでき
ない。

「浮浪者」プログラムに関する上記考察は又、ソースマ
シンのシステム呼び出しを履行する手順に当てはまる。
何故なら、これらの手順は、必然的にソースマシンのア
ドレス空間の正規でないRAM領域を引用しなければなら
ない。更に、目標マシン中のシステム・ソフトウェア
は、ソースマシンのシステム・ソフトウェアよりは異な
ったサービスを提供し、或いはそれらに異なった約束を
提供することができる。エミュレーション及び翻訳への
公知なアプローチは、ソースマシンのアプリケーション
・プログラム・インストラクションに於けるシステム呼
び出しを認識し、且つ注文で書かれたソフトウェアを使
用することによって、このことを取り扱う。このソフト
ウェアは、ここでは「システム・シミュレーション」と
称され、直接又は目標マシンのシステム・ソフトウェア
への呼び出しを介して、目標マシンのアドレス空間をア
クセスすることによって同等なサービスを提供する。勿
論、後者は目標マシンのアドレス空間のレイアウトを熟
知して書き込まれる。アドレス空間のレイアウトとシス
テム・ソフトウェア双方に於ける上記した相違点はそれ
によって調製される。この点で又、ソースマシン又は目
標マシンのRAM及びRAM記憶位置に関するここでの全論考
は、必ずしもディスクリートな物理的メモリへの言及と
しては理解されるべきでないことが、又注目される。従
って、ここでの全論考は、仮想メモリ技術を使用しない
ソースコンピュータ及び目標コンピュータ・システムの
みならず、それを使用しているものにも適用される。

エミュレーション さて、第５図を参照して前述のものを構成する。第５図
は、従来の技術で知られているハードウェア・エミュレ
ーション及びソフトウェア・エミュレーションへのアプ
ローチの論理図である。特に、ソースマシン・アプリケ
ーション51が、目標マシン内で実行するハードウェア又
はソフトウェア・エミュレータ53への入力として使用さ
れる。最初に、エミュレータは、目標マシンのシステム
・ソフトウェア58から目標マシンのアドレス空間55内の
適当な量のメモリを要求することによって、ソースマシ
ンのアドレス空間のイメージ54を作成する。それから、
エミュレータ53は、ａ）アプリケーション51のプログラ
ム・インストラクションを（以下に説明するように）デ
コードし;b）もし、デコードされたインストラクション
がシステム呼び出しでなければ、そのインストラクショ
ンを目標マシンの一組のインストラクションの同等な一
続きの動作上に（同じく以下に説明するように）写像
し；そしてｃ）その結果である写像された一続きのイン
ストラクションを実行する。

デコーディングは、特にコンパイルされたソースマシン
のアプリケーションを個々の要素インストラクションに
分離する動作である。各要素インストラクションは、典
型的には遂行すべき動作を示し、一つ以上の演算数、例
えば、データが常駐して演算されるレヂスタのアドレス
に続く。そして、デコーディングは、処理中、遂行すべ
き動作及び演算が為されるデータを識別する。写像は、
各ソースマシン・インストラクションに対し、副効力を
含み、目標マシンの一組のインストラクションを使用し
ている、目標マシン中の同等な一続きの動作を決定する
動作である。写像プロセスの一部として、エミュレータ
は以前述べたオフセットを、上記したように種々のイン
ストラクションに含まれるアドレスに加算する。その結
果、ソフトウェア・エミュレーション中のインストラク
ションは目標マシンのRAM中の適当な記憶位置を引用す
る。その結果である写像された一続きのインストラクシ
ョンは、続いて前述した実行ステップ中に目標マシン中
で実行される。

特定のインストラクションをデコードする差異に、もし
エミュレータ53が、それがシステム呼び出しであること
を決定すると、それは上記したような写像を遂行しな
い。むしろ、それは制御をソースマシンのシステム・ソ
フトウェアの前述したシミュレーション、即ちシステム
・シミュレーション57へ回す。システム・シミュレーシ
ョン57は、目標マシンのアドレス空間を直接又は目標マ
シンのシステム・ソフトウェア58を介してアクセスする
ことにより、要求されたサービスを遂行する。

最終的には、上記し且つ第５図に破線で示すように、
「浮浪者」プログラムにより、イメージのRAM部外にあ
るソースマシンのアドレス空間中の記憶位置をアクセス
する試みは、一般に、希望の機能が遂行される結果に成
らないからであろう。

（一方でのエミュレータ53、システム・シミュレーショ
ン57及び目標マシンのシステム・ソフトウェア58と、他
方での目標マシンのアドレス空間55との間の干渉を叙述
する目的で、前者は後者の外部に有る如く論理図で示さ
れる。実際に、目標マシン上で実行する全ソフトウェア
は、目標マシンのアドレス空間内に、実行されるために
存在しなければならない。このアプローチは同様に第７
図及び第８図にも引き継がれる。） この点で、ハードウェア・エミュレーション及びソフト
ウェア・エミュレーションは同様に動作するものと想定
される。実際、それらは第５図に表された機能レベルで
そうなっている。基本的な相違は、ソフトウェア・エミ
ュレーションに於いては、目標コンピュータのプロセッ
サが上記動作の全てを実行するのに依存しており、ハー
ドウェア・エミュレーションに於いては、目標マシン
が、タイプがソースマシンのそれと同等な第二のプロセ
ッサを含み、ソースマシンのアプリケーション・プログ
ラム・コードが直接この第二プロセッサ上で実行される
ことである。このアプローチは、前述したデコーディン
グ・ステップが全く必要とされず、写像ステップが前述
したオフセットの加算を実行する限りでのみ必要とな
る、確かな効力を奏する。こうして、ハードウェア・エ
ミュレーションの性能は、一般にソフトウェア・エミュ
レーションのそれより（典型的には、100倍）良くな
る。他方、ソースマシンのシステム環境と目標マシンの
それとは違っているので、ハードウェア・エミュレーシ
ョンは、依然として上記したようにシステム・シミュレ
ーションを介してシステム・サービスを遂行するため
に、目標マシンのプロセッサに依存しなければならな
い。ハードウェア・エミュレーションの基本的な欠点
は、特定のソースマシンをエミュレートするために必要
とされるハードウェアが、目標マシンの費用を酷く高価
にすることである。実際、各ソースマシンをエミュレー
トするために、異なったハードウェア・エミュレータが
目標マシンに必要とされる。こうして、例えば、三台の
ソースマシンからソフトウェアを動かすには、四個のプ
ロセッサ、即ち目標マシンのものに加えて各ソースマシ
ン毎に一つ、が必要とされる。

翻訳 都合良く、翻訳はソフトウェア・エミュレーションとハ
ードウェア・エミュレーション双方の幾つかの欠点を克
服する。

翻訳は、それが、ここで「トランスレータ」と称するソ
フトウェアの使用を伴う点で、ソフトウェア・エミュレ
ーションと似ている。このトランスレータは、その入力
として、ソースマシンに対してコンパイルされたプログ
ラムを取り、且つ各ソースマシン・インストラクション
の機能を複製する一つ又はそれ以上の目標マシン・イン
ストラクションに各ソースマーン・インストラクション
をデコードし、写像する。しかしながら、ソフトウェア
・エミュレーションと対比すると、このデコーディング
及び写像は「オフライン」で実行されてその結果のソフ
トウェア翻訳が保全される。その結果、アプリケーショ
ンが目標マシン上で実行されようとする度毎に作り直す
よりむしろ、それは繰り返し実行することができる。

第６図は、上記したように、「翻訳」コンピュータに於
いて遂行される翻訳プロセスのオフライン段階を示す。
特に、ソースマシン・アプリケーション61は、翻訳され
たアプリケーション、即ち、より単純には、後での使用
のために記憶される「翻訳」63を出力するトランスレー
タ62への入力として働く。トランスレータ62の最も単純
なタイプの実施例では、翻訳63を有する一続きの目標マ
シン・インストラクションは、実際の目的に対しては、
ソフトウェア・エミュレータによって使用されるであろ
うものと同じである。

翻訳63の実行時実行が、第７図に示される。この図で、
それは71として参照される。ここで再び、少なくとも最
も単純な場合に於いては、一続きのインストラクション
は、実質的に、ソフトウェア・エミュレーションの場合
に於けるものと同じであるから、実行インストラクショ
ンと目標マシンの間の相互作用も又、実質的に同じであ
る。こうして、特に、翻訳されたアプリケーション71は
目標マシンのアドレス空間75内で、ソースマシンのアド
レス空間のイメージ74をアクセスする。システム呼び出
しは、システム・シミュレーション77へ渡される。シス
テム・シミュレーション77は、順次、目標マシンのアド
レス空間75を直接又は目標マシンのシステム・ソフトウ
ェア78を介してアクセスする。そして、先程と同じく、
「浮浪者」プログラムにより、イメージの通常RAM部の
外にあるソースマシンのアドレス空間中の記憶位置をア
クセスする試みは、一般に、希望の機能が遂行される結
果に成らないであろう。

この点で、この説明に於いて、翻訳コンピュータ及び目
標コンピュータを更に詳しく述べることが好適であろ
う。

特に、第２図は、「翻訳」コンピュータ200の説明図を
示し、この「翻訳」コンピュータ200上で、第６図に示
す翻訳プロセスのオフライン段階が例示的に遂行され
る。翻訳コンピュータ200は例示的にはミニコンピュー
タであり、その全体的アーキテクチャはソースマシン、
実際、最新式コンピュータのそれと同様である。しかし
ながら、コンピュータ100と200の間には幾つかの相違が
ある。

例えば、翻訳コンピュータ200は表示メモリや、はたま
た分離されたキーボード及びマウスを持っていない。む
しろ、全ての使用者インターフェースは例示のように、
従来のコンピュータ端末213に接続された直列ポート・
コントローラ212を介して遂行される。更に、このシス
テムはフロッピー・ディスク・メモリを持っていない。
むしろ、ミニコンピュータ環境で典型的であるように、
テープ・コントローラ228によって制御される磁気テー
プ・ドライブ229の手段により、ソフトウェアとデータ
の双方又は一方が、そこへ入力されたそこから出力され
たりするコンピュータである。翻訳コンピュータ200の
他の全ての要素は、ソースコンピュータ100に対応する
要素を持っており、参照符号の後部二桁に同一数字を持
つ。

翻訳コンピュータ200のオペレティング・システム2331
に加えて、第２図は、更に翻訳プロセスに於いて特に好
適な、翻訳コンピュータ200のハード・ディスク・ユニ
ット233中のこれらのファイルを示す。特に、ハード・
ディスク・ユニット233は、第６図のトランスレータ62
に相当し、このコンピュータ上で第６図に示す翻訳プロ
セスのオフライン段階を実行するアプリケーションとし
て実行されるトランスレータ2332;第６図のソースアプ
リケーショ61に相当し、トランスレータ2332への入力と
して働く、二つのソースマシン・アプリケーション2333
及び2334;そして最後に、第６図の翻訳されたアプリケ
ーション63に相当し、ソースマシン・アプリケーション
2333及び2334をそれぞれ処理した結果として、トランス
レータ2332の出力積を表す、二つの翻訳されたアプリケ
ーション2335及び2336を記憶する。例示的に、トランス
レータ2332は、コンピュータ200上ではなく、むしろ、
第三の目標コンピュータ、例えば、第３図に示すコンピ
ュータ300で実行するように意図された翻訳を作成する
ように設計されており、以下に説明される。こうして、
ソースマシン・アプリケーション2333及び2334と翻訳さ
れたアプリケーション2335及び2336の何れも翻訳コンピ
ュータ200上で実行できない。むしろ、コンピュータ200
に関する限り、それらは、それぞれ、単に入力及び出力
を構成する。

第３図は、目標コンピュータ300を例示的に示し、その
上で第７図で示すような（後で、更に第８図でも示すよ
うな）翻訳されたアプリケーションが実行される。目標
コンピュータ300は、例示的には、グラフィックス・ワ
ークステーションである。目標コンピュータ300が、ソ
ースマシン100上で実行されるものを写し取る機能を遂
行するものである限りでは、この二つのコンピュータ
は、当然、多くの同様な要素を含み、それらは参照符号
の後部二桁に同一数字を持つ。しかしながら、それらに
は、先と同様に、幾つかの相違がある。

特に、目的コンピュータ300は、翻訳コンピュータ200と
同様、フロッピー・ディスク・ユニットを持たない。外
界との接続は、LANコントローラ328によるローカル・エ
リア・ネットワーク（LAN）の手段によって為される。
他の基本的な相違は、ROM335が完全なBIOSは含まず、む
しろ上記したように、ブロト・ローダ3351のみを含むこ
とである。オペレティング・システム3331に加えて、第
３図は、更に、第７図で示すような翻訳プロセスの実行
時部分に特に好適な、目標コンピュータのハード・ディ
スク333中のファイルを示す。特に、ハード・ディスク3
33は、第２図の翻訳されたアプリケーション2335及び23
36に対応する、翻訳コンピュータ200によって出力され
た二つの翻訳されたアプリケーション3332及び3333、及
び第７図の翻訳されたアプリケーション71を記憶する。
更に、例示的にハード・ディスク333上には、目標コン
ピュータ300上での実行のためにコンパイルされた二つ
のアプリケーション3334及び3335が記憶されている。

ハード・ディスク333中に示される他のファイルについ
ては後でもっと折よい時機に考察する。

システム・ソフトウェアの翻訳 第８図は，翻訳構成の代案を示す。以前のように、ソー
スマシンからの翻訳されたアプリケーション・プログラ
ム81はソースマシンのアドレス空間のイメージ84をアク
セスすく。しかしながら、ここでは、シミュレーション
である代わりに、翻訳されたアプリケーションとして働
くシステム・ソフトウェアは、少なくとも部分的に、ソ
ースマシンのシステム・ソフトウェアの少なくとも数部
分の翻訳87である。実際、ソースマシンのシステム・ソ
フトウェアのこの翻訳は、このソースマシンのシステム
・ソフトウェアを全く同じアプリケーション処理、即ち
第６図に示すような処理に当てることによって作成され
る。

ソースマシン・システム・ソフトウェアの全体を翻訳す
る必要が無いことは、強調されるべきことである。例え
ば、もし、特定のシステム・サービスが、実質的にソー
スマシンと目標マシンの双方に同様に設けられていれ
ば、翻訳されたアプリケーションを目標マシン・バージ
ョンにつなぐために、そのサービスのソースマシン・バ
ージョンを履行するコードの翻訳を更に進めることがで
きる。翻訳されたシステム・ソフトウェア87は又、目標
マシンのシステム・ソフトウェア88を、現にシステム・
シミュレーションが行っているのと大部分同じ仕方で呼
び出すことができる。他の場合では、ソースマシンのシ
ステム・ソフトウェアの一部を翻訳するより、むしろシ
ミュレートし、且つ再びそれらに翻訳されたアプリケー
ションをつなぐことが有益であると考えられる。更に、
アプリケーションによりアクセスされることが期待され
ていないソースマシン・システム・ソフトウェアの要素
は翻訳される必要が無い。

翻訳されたシステム・ソフトウェア87は目標マシン300
（第３図）にライブラリとして記憶され、そこでは参照
数字3336を持つ。第23図を参照して後に更に詳述するよ
うに、翻訳されたアプリケーションは、それらが実行の
ため目標マシン300のRAM334にロードされる前に、翻訳
されたシステム・ソフトウェアに結合される。こうし
て、翻訳されたアプリケーション81が少なくとも、特定
のシステム・サービスを要求するとき、単なるシミュレ
ーションよりむしろ、目標マシン上で実行されるこれら
のサービスを履行するソースマシン・システム・ソフト
ウェア・プログラムの翻訳されたバージョン、即ちそれ
の機能的に書かれたバージョンである。

翻訳されたシステム・ソフトウェア87は、それがソース
マシン中で行っていたように、ソースマシンのアドレス
空間のイメージ上で正確に動作する。ソースマシン・シ
ステム・ソフトウェアのセマンティックス（意味）は、
こうして同一に保全される。このことは、シュミレーシ
ョンの伝統技術のアプローチ、即ちソースマシン・シス
テム・ソフトウェアの書き直しを越えた顕著な利益を持
っている。

特に、システム・ソフトウェアの開発者により提供され
た、実際に特定のシステム・サービスをソフトウェア中
で遂行する方法の既述は、しばしば、ａ）一つ以上（大
概は少ない）の事柄で不正確であるか、ｂ）不完全であ
るか、又はその双方である。その結果、そのような既述
を元にして書かれたマシン・システム・ソフトウェア・
シミュレーションは、これらは通常利用できる唯一のソ
ースであるが、オリジナルに存在している特定の機能を
具体化することは出来ない。シュミレートされたシステ
ム・サービスを呼び出すエミュレートされたアプリケー
ション又は翻訳されたアプリケーションは、こうして適
切に実行出来ない。対照的に、ソースマシンのシステム
・ソフトウェアは、実際、浮浪者プログラムの作成者が
時折その利益を得るプログラム・バグ（プログラムの
虫）を含めて、それらのニューアンスの全てが保全され
るのを確実にする。

翻訳されたシステム・ソフトウェア87によって参照され
るすべてのアドレスはイメージ84内にある。即ち、それ
らはソースマシン内のメモリ記憶位置及び装置のアドレ
スである。浮浪者プログラムに関する上記考察は、こう
して翻訳されたシステム・ソフトウェア87に適用され
る。特に、ソースマシン及び目標マシンのアドレス空間
が、必ず相違しているという事実は、参照されるアドレ
スが両方のマシン内に於ける記憶位置、装置非関連の、
即ち通常RAMに対応している限りでは、通常RAMの記憶位
置は互いに見分けがつかないものであるから、問題では
無い。しかしながら、二つのアドレス空間の相違が調和
されない限り、たとえば、特定のハードウェア装置に関
連付けられた記憶位置へ試みられたアクセスは、一般に
適切には遂行されない。

都合よく、仮想ハードウェア環境が、前記のものを扱う
ために目標マシンに備えられる。特に、翻訳ソフトウェ
アの要素、例えば、仮想ハードウェア事象モニタ90は、
周期的に、例えば0.01秒毎にタイマー割り込みに応じて
呼び出される。後で詳述するように、モニタ90はソース
マシンのハードウェア装置に対応するイメージ84内の記
憶位置の全ての状態をチェックし、もし最終チェックの
前に変化が生じた場合、直接又は目標マシンのシステム
・ソフトウェア88を介して目標マシンのアドレス空間に
意図されたアクセスを遂行する。更に又、モニタ89は、
目標マシンのハードウェアに対応する目標マシンのアド
レス空間のそれらの記憶位置をモニタし、イメージ84内
の対応する記憶位置を更新する。その結果、目標マシン
のハードウェアの状態の変化は、翻訳されたアプリケー
ション81及び翻訳されたシステム・ソフトウェア87に知
得される。

アプリケーションがソースマシン内で働くのと同様な仕
方で翻訳されたアプリケーション81を満足する、翻訳さ
れたシステム・ソフトウェア87の能力は、目標マシンの
システム・ソフトウェア88に関連して、ソースマシンの
ハードウェアの動作を正確にシミュレーションするため
の項目モニター89の設計者の能力に依存する。有益なこ
とに、典型的にソースマシンのシステム・ソフトウェア
に使用できるドキュメンテーションの不適切性に関して
上記で概説した問題は、そのハードウェアをシミュレー
トする状況に於いては生じない。その理由は、種々のハ
ードウェア素子に対するインタフェースが旨く規定され
ており、実際、項目モニター89の設計者に使用出来るド
キュメンテーションがソースマシンのハードウェア設計
者によって使用し得、且つ依存されるものと同じであ
り、このドキュメンテーションが種々のハードウェア要
素の種々の製造者によって供給されるものであるからで
ある。こうして、目標マシンのシステム・ソフトウェア
88に関連して、項目モニター89の設計者がソースマシン
のハードウェア装置の特徴や性質を充分に履行する限
り、翻訳されたアプリケーション81及び翻訳されたシス
テム・ソフトウェア87により呼び出されるように企画さ
れたハードウェア機能は、事実、同様に実行することが
出来る。

第９図は、仮想ハードウェア項目モニター89の動作のフ
ローチャートである。特に、モニタ89は、ステップ902
で、モニタの最後の呼び出し後に、翻訳された（アプリ
ケーション又はシステム）ソフトウェアを実行すること
がスクリーン変化を為したかどうかを決定することによ
って、即ち、イメージ84内のスクリーン・メモリに書き
込むことによって、開始する。この検査は、目標マシン
の能力に応じて、幾つかの方法で遂行される。もし、変
化が合った場合、モニター89は、目標マシンの実際のス
クリーン・メモリ内で、変化した画素の値を更新するた
めに、目標マシンのシステム・ソフトウェア88を呼び出
す。

モニター89は、それからステップ914へ進む。ここで、
それは目標マシンのクロック・レヂスタに記憶された現
在の値を仮想クロック・レヂスタ、即ち目標マシンのク
ロック・レヂスタに対応するイメージ84内の記憶位置に
コピーする。同様に、ステップ916で、マウス座標がイ
メージ84内の類似した記憶位置に記憶された、目標マシ
ン内の記憶位置に記憶された現在の値をコピーする。

最後に、キーボードがステップ917に於いて検討され
る。特に、モニター89は、キーボードの項目が置かれて
いる目標マシンのシステム・ソフトウェアによって維持
された待ち行列をチェックする。もし、この待ち行列が
最後にチェックされた後で変化が有ったことが判ると、
処理はステップ923へ進み、ここでこの情報は翻訳され
たアプリケーションを実行することによって知得され
る。例示するように、これは単にキーボードの項目情報
を直接、イメージ84内に維持されている類似した待ち行
列中に置くことによって達成される。また別に、翻訳さ
れたソースマシンのシステム・ソフトウェア内の割り込
み手順は、その情報をその待ち行列中に置くように、モ
ニター89によって呼び出すことも出来よう。

この点で、モニター89は後で再呼び出しされるべく、出
力する。

第10図は、翻訳ソフトウェアの開発から翻訳されたソフ
トウェアの実行まで、翻訳を遂行するための項目の順を
示すフローチャートである。

1001及び1003で示されるように、最初のステップは、ト
ランスレータ及び仮想ハードウェア項目モニターを作成
することである。勿論、これは基本的にコンピュータの
プログラミング・タスクである。

一旦、トランスレータ及び仮想ハードウェア項目モニタ
ーが作成されてしまうと、ａ）ソースマシンのシステム
・ソフトウェアの全部又は一部を翻訳し、それを目標マ
シン中に、1006、1008及び1011で示すように記憶し;b）
所望のシステム・シミュレーション・ソフトウェアを履
行し、それを目標マシン中に、1012及び1013で示すよう
に記憶し；及び、ｃ）一つ又はそれ以上のアプリケーシ
ョンを翻訳し、それらを翻訳されたシステム・ソフトウ
ェア及び他のシステム・ソフトウェアに纏めて、目標マ
シン中に、1014、1016、1019、1020及び1022で示すよう
に記憶するステップを遂行することが可能になる。ステ
ップ1024で判定されるように、もし目標マシン上で翻訳
されたアプリケーションの特定の一つを実行することが
求められると、そのアプリケーションは、1028で示すよ
うに直接実行される。

特に、ステッ1028は、目標マシンのシステム・ソフトウ
ェア88内のアプリケーション始動手順によって例示的に
遂行される。この手順はイメージ84に対しメモリ空間を
割り付ける目標マシンのシステム・サービスを呼び出
し；基本的にそれが前述したタイマ割り込みを設定する
ように指示することによって、翻訳されたアプリケーシ
ョン81をそのイメージ内の適当な場所にロードしてモニ
ター89を始動し；且つそれから制御をアプリケーション
81へ渡す機能を勤める。アプリケーション81の実行が完
了したとき、アプリケーション始動手順は、それにその
タイマ割り込みを停止するよう指示することによってモ
ニター89を停止し；イメージ84に割りつけられたメモリ
空間を解放し；且つ、プログラム制御を目標マシンのシ
ステム・ソフトウェア88へ戻すよう、機能する。

トランスレータ ここで、第２図中のトランステレータ2332及び第６図中
のトランスレータ62として示される、実際の翻訳を行う
翻訳ソフトウェアのこの部分を例示的に実現することに
ついての詳しい論考に移る。

ソフトウェア・エミュレーションを通しての翻訳の基本
的な利益は、さもないとデコーディング及び写像で費や
される時間が排除され、顕著な、典型的には約３対１の
性能改善となる事実である。しかしながら、不利益に
も、翻訳されたソフトウェアは、一組のソースマシン・
インストラクションの主効力及び副効力を明確に複製す
る必要性から起きる上記したプログラム・コードの拡大
のせいで、典型的には膨大な量の記憶空間、例えば典型
的に元のプログラム・コードの15倍乃至25倍の増加を必
要とする。副効力が明確に複製されるときにソースマシ
ン／コードが拡大する仕方の例は、第11図の最初の二カ
ラムに示されている。プログラム・コードのこの拡大、
及びそれに付随して必要な多量の記憶場所と実行速度の
低下は、この点で、目的コードの翻訳を本来使用されな
い別の手段に変えていた。

しかしながら、本発明によれば、劇的に性能が改善され
且つ規模を縮小された目的コードの翻訳が、拡大したプ
ログラム・コードを解析し、実際には、適当なプログラ
ム実行に対して必要ではないインストラクションを排除
することによって、達成することができる。実際、以下
に述べるように、もし本発明の種々の特徴及び見地に従
ってこのことが遂行されれば、その結果得られる一組の
インストラクションは、ソースマシンのアプリケーショ
ン・コードより顕著に多い記憶場所を必要とはしなくな
る。第11図の第３カラムはこれら最適化技術が生じるこ
とのできる縮減度合を示す。

第12図は、本発明による翻訳を遂行するためのトランス
レータによって行われる処理の概観を表す。この翻訳プ
ロセスは、三つの基本要素、即ち、分析、翻訳及びコー
ド発生を有するように、多くの点で伝統的コンパイラ・
プロセスと類似している。特に、分析要素は入力アプリ
ケーション・ソフトウェア又はシステム・ソフトウェア
の目的コードを読取り、それを更にマシン非依存性の処
理の適する中間言語表現に変換する。ついで、翻訳要素
は冗長度及び不必要コードを排除することにより、中間
言語コードの規模を縮小する。最後に、コード発生要素
はその中間言語表現を目標マシンの目的言語に変換す
る。

これら三要素をこれから順に説明する。

分析 分析要素は三つの段階（フェーズ）、即ち分解、解析及
び写像を持っている。

分解は、目的コードの個々のインストラクションの正直
なデーコーディング及びそれらのアセンブリ言語形態へ
の変換から成り、これらデーコーディング及び変換の双
方は周知の伝統的技術に従って遂行される。引き続い
て、解析フェーズ分解処理の管理に責任を負っている。

分解／解析の初期タスクは、いわゆる基本ブロックに分
けられた入力プログラムのアセンブリ言語表現を作成す
ることである。基本ブロックは、インストラクションの
一順序（シーケンス）であり、これは実行中のそのとき
に正確に制御がそのシーケンスに入ることができる一イ
ンストラクション及び実行中のそのときに正確に制御が
そのシーケンスから出ることができる一インストラクシ
ョンを有している。解析中、各基本ブロックは、ａ）そ
の基本ブロックに対し任意に選択された名称、ｂ）その
基本ブロックの開始点、ｃ）その基本ブロックの終了
点、及びｄ）その基本ブロックのいわゆる「後続」を識
別するコメント・ラインで注釈される。これらは、制御
のフローがそこへ直接渡され得る基本ブロックである。
例示的には、一本のコメント・ラインａ）とｂ）の双方
を果たすのに仕様される。上記のように注釈され、且つ
後で詳述するようないわゆる「手順」に分類される数個
の基幹的基本ブロックが、第15図に示される。

基本ブロックを識別するプロセスはいわゆる「セグメン
ト・リスト」を作成することによって遂行され、そのリ
ストは、コード又はデータの何れかであるとして識別さ
れるプログラムのセグメントの開始位置及び終了位置を
含む。初期に、第14図に1405で示されているプログラム
の全体は、試験的にデータ・セグメントとして識別され
る。こうして、14図に1403で示されているように、その
セグメント・リストは、初期には単一の記述項を含み、
この記述項はそれぞれ「Ａ」及び「Ｚ」で示されている
完全プログラムの開始位置及び終了位置を含む。コード
の各セクションは解析益として見出だされるので、それ
らは、以前にそれらを含んでおり且つセグメント・リス
ト内で「コード」として更に分類されている、先にデー
タとして試験的に識別されたセグメントから「引き離
し」をされる。一旦、これらの処理が完了すると、各コ
ード・セグメントは基本ブロックとして認証される。

第13図はトランスレータの分析要素全体のフローチャー
トであり、そのフローチャートの大部分はコード・セグ
メントとデータ・セグメントの識別に、従って究極的に
は基本ブロックの識別に当てられている。実際、第13図
が充分に記述された後で評価されるが、ステップ1311は
分解を遂行し、ステップ1335は写像を遂行し、且つ残り
のステップは分析を遂行する。

処理はステップ1301から開始し、ここで知得されている
基本ブロックの開始点のリストであるいわゆる探求リス
トから記述項を取り出す。初期には、この探求リスト
は、目的コード・プログラム、即ちプログラムの実行が
開始するときに制御を受けることができる目的プログラ
ム内の記憶位置に対する入口点のリストである。普通、
アプリケーションは一個の入口点のみを持っている。し
かしながら、更に翻訳することができるシステム・ソフ
トウェアは典型的には多数の入口点、即ちアプリケーシ
ョンがそこでそれを呼び出すかも知れない種々の記憶位
置の全部を有する。初期の探求リストは、第14図に1401
で示されており、この場合は単一の記述項、即ち「Ｅ」
で示されているこのプログラムの入口点の記憶位置を有
する。種々の他の基本ブロックの開始点は後で述べる方
法で識別されるので、それらは探求リストに加えられ
る。

ステップ1303で判定されるように、もし探求リストが空
であれば、コード・セグメント・ブロックとデータ・セ
グメント・ブロックを識別する処理は完了する。そうで
ない場合は、ステップ1307で検討中のアドレスに於ける
インストラクションが実際、既に遭遇済みであるか否か
を判定するために、更に検査が為される。このことが起
きる可能性については、後のもっと折よい時期に述べ
る。

実際、もし検討中のインストラクションが以前に遭遇さ
れていなかった場合、それは定義により、新規に識別さ
れた基本ブロックであり、そのアドレスは後で使用する
ために保存される。従って、初期には、それは記憶位置
「Ｅ」で保存される。

ついで、処理はステップ1311へ続く。この点で、そのイ
ンストラクションは分解され、その結果、次のステップ
1313はそのインストラクションが制御のフローを変える
稼動か、即ちブランチが呼び出しか戻しであるかを判定
することができる。もしそれが制御のフローを変えない
と、そのセグメントの端部が未だ見付けられていない。
そのアドレスはステップ1315で増分され、且つステップ
1311及び1313が次のインストラクションに対して繰り返
される。

究極的には、制御のフローを変えるインストラクション
が遭遇される。第14図に1415で示されるように、この例
ではそのインストラクションは記憶位置「Ｆ」のブラン
チ・インストラクションである。ステップ1317は、現在
のインストラクションが制御を移すことのできるインス
トラクションのアドレスを、そのようなアドレスの各々
が定義により各基本ブロックの最初のインストラクショ
ンであるので、それらを探求リストへ加える。この例で
は、記憶位置「Ｇ」及び「Ｋ」が、制御のフローが記憶
位置「Ｆ」でのブランチ・インストラクションからそこ
へ渡ることができるインストラクションである。つい
で、ステップ1319は、セグメント・リストに新しいコー
ド・セグメントの記述項を作成するために、ステップ13
09で保存されたアドレス及び現在のアドレスを使用す
る。こうして1413で示されるように、そのセグメント・
リストは現在、三個の記述項、即ち、記憶位置「Ａ−
Ｅ」及び「Ｆ−Ｚ」の仮りデータ・セグメント及び記憶
位置「Ｅ−Ｆ」のコード・セグメントを含む。ここで
は、記憶位置「Ｅ−Ｆ」に新しく作成されたコード・セ
グメントが基本ブロックであることを述べるのは、その
セグメント内のインストラクションが目的の、即ち未だ
遭遇していないブランチ・インストラクションであり、
且つそれでそれがそれ自体の基本ブロックの最初のイン
ストラクションであることは後で判明することなので早
すぎる。事実、後で分かるように、記憶位置「Ｋ」はち
ょうどそのような目的のインストラクションの記憶位置
である。

この点で、処理はステップ1301へ戻り、探求リストから
別の記述項、ここでは記述項「Ｇ」を処理する。この場
合、同様な処理ステップが続き、その結果、記憶位置
「Ｇ−Ｈ」での別のコード・セグメントの識別及び、そ
の記憶位置でのインストラクションが記憶位置「Ｈ」で
のインストラクションの目標である記憶位置「Ｍ」の探
求リストへの付加が為される。

処理は再びステップ1301へ戻る。しかしながら、記憶位
置「Ｋ」が記憶位置「Ｅ−Ｆ」でのコード・セグメント
内にあることに注意を要する。こうして、ステップ1307
での検査の結果は、記憶位置「Ｋ」が記憶位置「Ｅ−
Ｆ」でのコード・セグメントを識別した処理中に遭遇さ
れているので、現在「YES」である。

ついで、ステップ1308は、現在のインストラクションが
既に識別されたセグメントの最初のインストラクション
であるか否かを判定する。このことは、もし記憶位置
「Ｋ」が既に探求リスト上に置かれていた場合、その結
果が記憶位置「Ｈ」でのインストラクションより以前に
遭遇されたインストラクションの目標であるので、起こ
り得る。その場合、それ以上のことは為される必要はな
く、処理は再びステップ1301へ戻る。しかしながら、こ
の場合、記憶位置「Ｋ」は未だ既に識別されたセグメン
トの最初のインストラクションとしては識別されていな
い。従って、記憶位置「Ｋ−Ｆ」での新しいセグメトは
ステップ1310で引き離され、処理は再びステップ1301へ
戻る。

究極的に，ステップ1303で、探究リストが空であること
が見出だされよう。この点で処理中にコードとして識別
されなかったセグメント、即ち非インストラクションは
何れも、制御のフロー中のパスで、それによって、こと
によりそのようなインストラクションが実行のために到
達できるようなものは見出だされていないので、データ
である。なおこお点で、使用した方法論によって、すべ
てのコード・セグメントは基本ブロックとして保証され
る。

処理はここでステップ1303からステップ1331へ進み、こ
こでは基本ブロックの前述した後続要素が識別される。
これは各基本ブロックの最終インストラクションを単に
検査し、且つ制御のフローがそこへパスすることができ
る基本ブロックを判定することにより達成することがで
きる。ついで、元プログラムのいわゆる手順はステップ
1333で識別される。これは、最初にそれら基本ブロック
の個々の一つがいわゆる「手順先頭ブロック」であると
して識別することにより得られる。なお、手順先頭ブロ
ックはその最初のインストラクションが、ａ）前述した
入口点又はｂ）呼び出しインストラクションの目標の何
れかである基本ブロックである。ある手順は、ａ）それ
自体は手順先頭ブロックではなく、且つｂ）制御のフロ
ーがどのような中間手順先頭ブロックを介してもそこへ
はパスしない、いわゆる手順先頭ブロックから、（後続
要素のシーケンスを介して）到達し得る全てのブロック
で構成される。

第15図は、1501から1505までの多数の基本ブロックを示
し、ここに、それら基本ブロックの手順へのグループ化
が例示的に示されている。ここで、各基本ブロックが、
基本ブロックの開始点とその名称を意味する「＃BLOCKb
lock150x」の形態のコメント・ライン；基本ブロックの
終了点と又その名称を意味する「＃ENDBLOCKblock150
x」の形態のコメント・ライン；基本ブロックの後続要
素と勿論そのプログラム・コードを意味する「＃SUCCES
SORS 150a、150b、等」の形態のコメント・ラインを有
することが注意される。制御のフローを変更するインス
トラクションのみが、その図に明確に（プログラム擬似
コードで）示されている。

基本ブロック、即ち「Ａ＝10」の最初のインストラクシ
ョンは入口点である。従ってその基本ブロックは手順先
頭ブロックである。残りの基本ブロックの全部はブロッ
ク1501から到達する。特に、基本ブロック1502及び1503
は条件ブランチを介してLABEL1へ到達する。もしそのブ
ランチが取られると、制御のフローがLABEL1へパスし、
このLABEL1は基本ブロック1503の最初のインストラクシ
ョンをマークする。そうでない場合は、基本ブロック15
02の最初のインストラクションに対しそのブランチを
「失敗」に制御する。ブロック1504は呼び出しにより、
基本ブロック1503からLABEL2へ到達する。最後に、基本
ブロック1505はブロック1504の「失敗」及びそれ自体の
双方により、条件ブランチを介してLABEL3へ到達する。

後続要素1502及び1503は基本ブロック1501に続く手順で
ある。しかしながら、基本ブロック1504及び1505は、な
おそれらは又基本ブロック1501のついての後続要素であ
るが、他の手順に属する。先ず、基本ブロック1504は、
それが呼び出しの目標であるので、自己の権利で手順先
頭ブロックとして適任である。更に、基本ブロック1505
から基本ブロック1501への制御のフローは、中間手順先
頭ブロック、即ち基本ブロック1504を介してパスする。
それ故、基本ブロック1505は基本ブロック1501を先頭と
する手順中には無い。むしろ、それは、基本ブロック15
04を先頭とする手順中のみに存在する。

第13図のステップ1333は分析要素の解析フェーズを完成
する。最終の分析ステップ、即ち写像は、ついでステッ
プ1335で遂行される。これは、各分解インストラクショ
ンに対し、マシン非依存性の中間言語で表された副効力
を含めて動作の等価シーケンスを代行するプロセスであ
る。こうして、ステップ1335で遂行された写像プロセス
は、前述したように、伝統的ソフトウェア・エミュレー
ション中に遂行される写像と全く同じである。

この点で、用語「副効力」の意味と、写像プロセスが、
実際、ソースマシン・インストラクションのセットの副
効力のセマンティックスのすべてを中間言語表現中に複
製するために、管理されねばならない理由をより充分に
述べることが適切である。

限定すれば、インストラクションのセットはコンピュー
タのプログラマーが使用可能な全インストラクションの
全体効力である。各インストラクションは、そのインス
トラクションの形態を決めるシンタックス（構文）及び
セマンティックス（意味）を有する。セマンティックス
が、又主効力及び副効力の双方を含む。

主効力は、「主情報」として考えられるデータ値を発生
することができる。こうして、例えば、ADDインストラ
クションの主効力は二つの量の加算である。他に、その
主効力は非データ動作、例えば、JUMPのような制御のフ
ロー中の変化であることも可能である。

副効力は、ａ）その主効力以外のもので、且つｂ）潜在
的に、プログラム実行中、後で使用可能なインストラク
ションの何らかの効力である。副効力は、例えば、種々
の二次情報を発生することができる。こうして、例え
ば、算術的インストラクションの副効力は、しばしば，
その値が（０又は非０かのような）算術結果あるいは
（結果がオーバフローしたかどうかのような）動作自体
の属性を示す条件コード・ビットの設定を含む。他に、
その副効力は、二次情報の発生には与からず、むしろ、
インストラクションのセマンティックスの特性に与かる
ことができる。ある例は、語長レヂスタの高次の半語
が、そのレヂスタ上で半語の動作が遂行されていると
き、保全されるか否かである。

特定の副効力が、そのプロセッサ設計チームにより意図
されていたか、いなかったかは注意を要する。例えば、
プロセッサ・ファームウェア中のエラーのせいで、特定
のインストラクションの実行の際に常にリセットされる
と想定されている特定の条件コード・ビットが、そのイ
ンストラクションが特定のオペランド値で実行されてい
るとき、非リセット状態に残されることが起きるかも知
れない。

副効力が、プログラム中で使用される仕方は色々であ
る。例えば、条件コード・ビットの値は、制御のフロー
を各ために、その直後のプログラム・コード・インスト
ラクション中に検査を受けることができる。あるいは、
オーバフロー条件コード・ビットの値が検査を受けるこ
とができ、もしセットされていることが見出だされる
と、オーバフローの場合に対する例外ハンドラーが呼び
出される。これらは、プロセッサ設計チームが彼等の一
般的ユーティリティの理由から装備する、副効力のルー
チン的使用の例である。しかしながら、プログラマー
は、しばしば元々意図されていたもの以外に対する特定
の副効力を利用し、実際、この目的に巧妙な副効力を利
用することができる。

元々意図されていたもの以外のために、巧妙さは無い特
定の副効力がしようされる例は、システム呼び出しが失
敗したことを呼び出しプログラムに返報する手段とし
て、システム呼び出しを出力する際の、桁上げ条件コー
ドの設定である。有益にしようとすることができる巧妙
な副効力の例は、半語動作が語長レヂスタ上で遂行され
ているときに、そのレヂスタの高次の半語が保全されて
いるという事実であ。このことが有るので、あるプログ
ラムは、そのプログラムの部分を代行して実行するため
にデータをパスするこの効力に依存することができる。
実際上，そのレヂスタの高次の半語は特設半語レヂスタ
として機能する。写像プロセスは、翻訳されつつあるそ
のプログラムの作成体がそれらに、実際、予見出来ない
方法で依存していたかも知れないので、そのような副効
力の全部を誠実に複製しなければならない。

副効力を写像する旨い方法は次のとおりである。すなわ
ち、トランスレータ写像フェーズの作成中、ソースマシ
ン・インストラクション・セットの各インストラクショ
ンは、その主効力及びその副効力の全部の双方を評価す
るために解析される。初期に、そのプロセッサ参照マニ
ュアルまたは他のドキュメンテーションがその副効力に
ついての情報を集めるために使用される。ついで、基幹
の中間言語表現のシーケンスが各ソースマシン・インス
トラクションのために開発され得る。このシーケンスは
そのインストラクションの主効力及びその既に知得され
ている副効力を遂行する中間言語インストラクションを
含む。例えば、ADDインストラクションに対する基幹
は、種々の条件コード・ビットを計算し且つセットする
個々の中間言語ステートメント（文）を含むであろう。
ソースマシン及び目標マシンの双方が僅かに類似した副
効力を持つことはできるが、それらの詳細なセマンティ
ックスは違っていても良い。例えば、一つのマシン上の
MOVEインストラクションは、他のマシン上の同等インス
トラクションが全く条件コード・ビットに影響すること
ができないので、零及び負の条件コード・ビットをセッ
トすることができる。こうして、好ましい実施例では、
基幹のシーケンスが、目標マシンの相当する副効力に依
存するよりむしろ、明確にソースマシンの副効力を複製
するであろう。） 副効力の特質も又考慮されなければならない。例えば、
もし、特定の条件コード・ビットが、設計により又はエ
ラーで、特定のオペランド値に対してセットされない、
例えば、これらのオペランド値を検査し、且つ適切な場
合に於いてその条件コード・ビットを無視するコードを
設けることによって、その基幹中に再生されなければな
らない。更に、写像されつつあるインストラクションの
主効力上に強い影響を与える副効力も又は考慮されなけ
ればならない。こうして、例えば、半語加算は、上記で
考察した例に於いてのように、語長レヂスタの高次の半
語の適切な取扱いを含まなければならない。

更に、その中間言語コードを、それが各副効力を、それ
が（下記に考察する如く、最適化のコード・エリミネー
ション・フェーズ中）不必要なコードを除くために最大
数の潜在的機会をもたらすので、できる限り他の各副効
力を遂行するものから独立して遂行するように保つ注意
が払われねばならないことに注意を要する。

ソースマシン・インストラクション・セット中の各イン
ストラクションに対する、基幹中間言語コード・シーケ
ンスが、翻訳時に於ける写像フェーズに使用可能であ
る。こうして、写像は、既に作成されている中間言語コ
ード・リストへの、ａ）各インストラクションのオペラ
ンドを取り出すためのコード、ｂ）適当な基幹、及び
ｃ）もし必要であれば、そのインストラクションの結果
を記憶するためのコードの加算から成る。

トランスレータの開発中に、特定の副効力がそれらが文
章化されてもおらず明白でもなかったために考慮されな
かったことは旨く、判明し得る。従って、そのような副
効力に依存するアプリケーションは、翻訳されたとき
に、期待されるようには遂行しないであろう。このこと
は、その中で翻訳されたプログラムの失敗点が見出ださ
れ、副効力に対しての不明が識別され、且つ写像プロセ
スがそれらを考慮するために変形される開発を繰り返し
必要とする。

最後に、分解フェーズ及び写像フェーズはソースマシン
に依存性があることを指摘することができる。従って、
異なる分解要素及び写像要素が、異なるソースマシンの
各々に対して作成されなければならない。このことは、
製造者のインストラクション・セット・マニュアルを参
照することにより、容易に運ぶことができる。しかしな
がら、解析は、その機能が基本的に分解を管理すること
の一つであるので、マシン非依存性である。

変換 再び、第12図を参照して、トランスレータの次の要素、
即ち変換が二つのフェーズ、即ち最適化及び合成を持っ
ていることが見られる。

本発明によれば、上記したように、最適化フェーズの基
本的機能は拡張されたプログラム・コードを解析し、且
つ実際、適当なプログラム性能に不必要であるインスト
ラクションを消去することである。好ましい実施例に於
いては、らり特定的に、その解析及びインストラクショ
ン消去は全般的に遂行される。即ち、特定のインストラ
クションを保持するか又は消去するかの必要性又は不必
要性は翻訳されつつあるプログラムの全体についての検
査に基づいて決められる（例えば、その反対には基本の
フロー・ブロック又は手順がある）。このアプローチ
は、実際に不必要として識別され得るプログラム・コー
ドの量を最大にする。（事実、このことは、拡張された
コードの量が膨大であり、その量を減らす各機会を旨く
利用するので重要である）。公知の最適化技術、即ち初
期にコンパイラ用に開発された最適化技術がこの動作を
遂行するために例示的に使用される。有益なことに、そ
のような最適化技術は実際上、例えばソースマシン・コ
ンパイラによって所定のアプリケーション内に作成され
ていた遺物を消去することにより、例え、そのコンパイ
ラが実際にそのような最適化技術を具体化しなかったと
しても、プログラムの質を改良することができる。これ
らの遺物は、例えば、メモリからの到達し得ないコード
及び不必要なロードを含み、且つメモリへ記憶する。

この最適化フェーズへの入力は、明確化された全副効力
を持ち、第15図に於ける如く、注釈されたソースアプリ
ケーションの中間言語表現である。実際のそのようなプ
ログラム・コードの小部分が第11図の中間カラムに示さ
れる。

本発明の特徴によれば、更に，これまでに開発され且つ
コンパイラ技術に使用様されているいわゆるデータ・フ
ロー解析技術が、不必要なインストラクションの解析及
び消去を遂行するための翻訳問題に有益に適用できる。
そのうえ、本発明の別の特徴によれば、以下に述べるよ
うに、データ・フロー解析は二つの部分で遂行される。
定義−使用のチェイニングのコンパイラ用に開発され得
た技術は、有益なことにデータ・フロー解析を達成する
ために例示的に用いられる。特に、データ・フロー解析
の目的は、「定義」又は「使用」の何れかであるとし
て、中間言語表現中の変数の全叙述が「定義」若しくは
「使用」であるとして分類することである。「変数」は
（条件コード・ビットを含む）レヂスタ、メモリの記憶
位置又はスタックの記憶位置の名称である。「定義」は
新しい値を得るインストラクション内に於ける変数の出
現である。「使用」はその変数の他の出現、即ちその定
義された値が使用される場所である。こうして、各使用
はある定義（又は一組の定義）によって作成された値の
叙述であり、且つ手順中を通しての可能な制御のフロー
のパスを検査することにより、特定の使用中にその値を
発生することができるであろう一組の定義が推論され
る。こうして、先に簡単に第21図を見ると、インストラ
クション「Ｚ＝10」は変数Ｚの定義であり、一方、次ぎ
のインストラクション「Ｘ＝Ｚ」は変数Ｚの使用であ
る。定義を使用に結合するプロセスは実際、上記の定義
−使用チェイニングであり、こうして発生された情報
は、ここでは「データ・フロー結果」として言及され
る。

本発明の特徴によれば、データ・フロー結果は、そこ
で、例示的に「共通サブ・イクスプレッション（副表
現）消去」、「不変量コード・モーション（行動）」、
「定数伝搬」、「スカラ伝搬」及び「休止コード消去」
を含む、数個のコンパイラ用に開発された変換を遂行す
る。

休止コード消去は、遂行されるべき最終の変換であり、
使用を持たない定義を含んでいるインストラクションの
除去に関係する。それは、拡大した中間言語バージョン
は使用されることが無い副効力の計算に当てられたイン
ストラクションで一杯になっているため、（翻訳最適化
中に消去され得る数個のインストラクションに関して）
最も有効な変換である。このことは、第11図に示され、
この図は３カラムで、ソースマシン・プログラム・コー
ドの５本のラインが中間言語コードの39本のラインに拡
大され、且つ、休止コード消去後、被翻訳コードの10本
のラインに縮小される仕方を示す。

その最適化が実際に遂行されるときは、他の変換が休止
コード消去に変更する。見られるように、それらの各々
はプログラムの性能を改良する。そのうえ、定数伝搬及
びスカラ伝搬は、ある程度を余剰にし、従って休止コー
ド消去により除去可能にする有益な高価を持っている。
そのような変換は、基のソースマシン・コードを作り出
したコンパイラ中で使用された最適化の質に反比例した
効果を持っている。実際、極く最近まで市販用コンパイ
ラに最適化技術を含めることは一般的ではなかった。そ
れ故、これらの変換は、上記した高い有効性を持った休
止コード消去プロセスとの組み合わせにより、現在、市
販で利用できる大多数のプログラムの翻訳には極めて有
効である。そのうえ、これらの変換はいずれにしても休
止コードを発生される必要があるデータ・フロー結果を
使用するので、最適化プロセスにそれらを導入するの
は、比較的に僅かな計算時間を伴うだけである。

コモン・サブ・イクスプレッション（共通副表現）の消
去は、同じ値を持つ冗長な計算の排除に関係する。共通
副表現は、各計算中の変換が他の計算中の対応する変数
として同じく関連付けられた定義をもつものとして、同
じ変数上に同じ演算を遂行することにより、定義の所定
の対が計算されることを判定することによって識別され
る。こうして、第16図に示される初期プログラム・コー
ドを検討する。なお、この図において、レヂスタＸは、
加算レヂスタＡ及びＢの結果を割り当てられ、後のレヂ
スタＹも又、加算レヂスタＡ及びＢの結果を割り当てら
れている。レヂスタＡ及びＢの割り当てへの干渉は無い
ものと仮定する。この加算を二階遂行するのは最適では
ない。したがって、変数＠１が変数Ａ及びＢの加算結果
を保持するために作成される。ついで、変数＠１を参照
して、この加算は、変数Ａ及びＢへの割り当てに置き換
えられる。

不変数コード動作は、ある値の計算がその制御のフロー
中のループ内で遂行される場合に関係する。もし、その
計算に関係する使用が、そのループ外にある関連付けら
れた定義を持つだけであれば、その計算はそのループ内
の不変数であろう。すなわち、そのループの繰り返し毎
に同じ値が計算されるであろう。従って、その計算はそ
のループの前に移すことができ、その結果、それが一回
遂行されるだけで、実行時間（これはコードの規模では
ないが）が改善される。従って、第17図に示される初期
プログラム・コードを検討する。レヂスタＸは、LABEL
により定義されたループ内で加算レヂスタＡ及びＢの結
果を割り当てられている。しかしながら、そのループ内
のレヂスタＡ及びＢには割り当てが無いものと仮定す
る。即ち、その計算中、レヂスタＡ及びＢの使用はその
ループ内に関連付けられた定義を持たないものと仮定す
る。こうして、そのループの各パスに対しては計算を遂
行する必要が無くなる。従って、変数Ａ及びＢの加算結
果を保持するために、変数＠２への割り当てがループ外
で作成され、ここではそれが一回遂行されるだけであ
る。ついで、変数＠２に関連して、この加算は、そのル
ープ内の割り当てに置き変えられる。

定数伝播は、もし、ある使用が唯一の関連付けられた定
義を持ち、且つその定義が引き続いてある変数へのある
定数の割り当てであれば、その使用をその定数で置き換
えることに関係する。従って、第18図に示される初期プ
ログラム・コードを検討する。ここで、値「１」がレヂ
スタＡに割り当てられ、次ぎのインストラクション「Ｘ
＝Ａ＋Ｂ」がレヂスタＡの内容を使用する。この場合、
この第２インストラクションでのレヂスタＡへの参照は
その値「１」自体に置き換えられる。そこで、そのデー
タ・フローの結果はその使用と考察中の定義との間の関
連付けを解除するために更新される。次ぎの休止コード
消去変換は、その定義に対する使用が見出だされないの
で、それを余分として削除するであろう。

スカラ伝搬は定数伝搬に似ていて、ここでは、その使用
が再び唯一の関連付けられた定義を持つ。しかしなが
ら、ここで、その定義は（定数の代わりに）第一の変数
の値の第二の変数への割り当てを構成する。更に、第一
の変数の媒介再定義が無い限り、第二の変数の使用は第
一の変数に関連して置き変えられる。そこで、そのデー
タ・フローの結果は適切に更新される。従って、第19図
に示される初期プログラム・コードを検討する。ここ
で、レヂスタＢの内容はレヂスタＡに割り当てられ、次
ぎのインストラクション「Ｘ＝Ａ＋１」がレヂスタＡの
内容を使用する。この場合、（レヂスタＢへの媒介割り
当てが無い限り）この第二インストラクションでのレヂ
スタＡへの参照はレヂスタＢの内容への参照に置き換え
られる。上記の如く、このときは、レヂスタＡの使用と
考察中の定義との間の関連付けを除去するために（且
つ、データ・フローの結果を正確に保ち、レヂスタＢの
新しい使用とその使用に関連付けられた定義との間に関
連付けを加えるために）、そのデータ・フローの結果が
更新される。元の定義は、定義が、実際、媒介割り当て
が有る少なくとも一個の他の使用を持っているかどうか
によって、余分に成ったり成らなかったりする。もし何
も無ければ、その定義は、（次ぎの）休止コード消去に
よって削除されるであろう。

以下に詳細に考案し、且つ第12図に示されるように、最
適化フェーズの変換要素は、本発明の特徴に従って、手
順毎のベースでのソースアプリケーションを有する。こ
れに対する理由は、最適化されつつあるプログラム・ユ
ニットの規模が増大するので、最適化のために使用され
たデータ・フロー解析技術が、実行時間及びスペースの
爆発的な増加を持つためである。最適化を手順の規模の
ユニットに限定することにより、その増加の問題を管理
可能なレベルに保つことができる。しかしながら、この
アプローチは、ある手順内に他の手順に対する呼び出し
が存在することに特別な考慮を払なければならないこと
を意味する。この理由では、最初の手順内で為された定
義は、それによって呼び出された第二手順内の使用を持
つかも知れず、又その反対もあり得る。それで、定義−
使用チェイニング・プロセスはこのことを考慮しなけれ
ばならず、さもないと翻訳プロセス全般が不正確なコー
ドを生じることになろう。

これに関して、正確性を確保する一つの方法は、各変数
が各手順呼び出し内で使用され、且つ定義されることを
盲目的に想定することである。こうして、例えば、もし
呼び出し手順内の定義が、（呼び出し手順ではなくて）
呼び出された手順内で実際に使用されると、各定義が呼
び出された手順内で使用されているという盲目的想定
は、考察中の定義が休止コード消去中に除去されないこ
とを画定することになろう。他の例として、呼び出し手
順内の定義が、あるレヂスタにある一定値を割り当てる
ことであり、それでそのレヂスタの内容が呼び出し後に
その呼び出し手順内で使用されると想定する。更に、そ
の呼び出された手順がそのレヂスタの内容を定義し直す
と想定する。全てがその呼び出された手順により定義さ
れるこの盲目的想定によって、呼び出し手順内でのこの
使用はその呼び出しの先に、その中に現れる定義に関連
付けられないであろうことが確実になり、こうして、定
数伝搬の間違ったアプリケーションが防止される。

他方、上記したように、このアプローチは正確性を保証
する。即ち、コード消去がローカルな環境では不必要で
あると思われ、あるもっと全般的な環境では実際に必要
とされるが、そのコード消去は無いであろう。他方、そ
のような想定は、普通余りにも悲観的であり、最適化の
効果を大きく縮小する。

更に本発明の特徴によれば、より有効なアプローチは、
最適化プロセスを動かすためにいわゆる呼び出しツリー
を使用することである。特に、呼び出しツリーは、その
プログラムの手順呼び出し動作の静的な反映である。そ
のプログラムの入口点での手順はそのツリーの「根」で
ある。（普通、アプリケーションは一つの入口点のみを
持ち、従って、直角的に気体されるように一つの根のみ
が有る。）その根によって呼び出された各手順はそのツ
リーの「枝」であり、枝によって呼び出される各手順は
その枝の「支枝」である。等々。他の手順の呼び出しを
しない手順は「葉」と呼ばれる。所定の手順から一つ以
上の呼び出しによって到達し得る一組みの手順は、その
「子孫」であり、それは逆に「先祖」である。

第20図は、例示的な呼び出しツリーを示し、それはその
根として、「MAIN」として知られている手順、及びその
子孫として、PROC_A、PROC_B、...PROC_Kとして知られ
ている手順を持っている。こうして、例えば、MAINはPR
OC_Aを呼び出し、それは順にPROC_B、PROC_Cを呼び出
す。他の例としては、PROC_DがPROC_Fを呼び出し、それ
は順にPROC_Eを呼び出す。後者は、再帰的にPROC_Dを呼
び出す。

データ・フロー解析ステップは、全ての手順を二度、一
度目は呼び出しツリーを順方向に、即ち、根から葉へ、
そして二度目は呼び出しツリーを逆方向に、即ち、葉か
ら根へ、処理する。こうして、一度目のパスに於ける処
理の例示的順序は、MAIN、PROC_A、PROC_B、PROC_C、PR
OC_D、PROC_F、PROC_E、PROC_H、PROC_G、PROC_I、PROC
_KそしてPROC_Jである。二度目のパスにおける処理の例
示的順序は、PROC_B、PROC_C、PROC_A、PROC_G、PROC_
I、PROC_H、PROC_E、PROC_F、PROC_J、PROC_K、PROC_D
そしてMAINである。PROC_EからPROC_Dへの再帰アークは
これらの順序を確立する際に無視されていることは注目
される。実際、そのような再帰サイクルに関わる呼び出
しツリーの部分にデータ・フロー解析遂行するとき、呼
び出しに関して、定義−使用チェイニングは極端に複雑
になるかも知れない。この理由は、上記した、各変数が
各呼び出された手順内で使用され且つ定義される悲観的
な想定は、典型的にその呼び出しツリーのそのような部
分のために使用される。こうして、PROC_D、PROC_F及び
PROC_E、及びそれらのお互いの呼び出しを含む、第20図
の呼び出しツリーのその部分はこの様式で取り扱われ
る。しかしながら、PROC_FからPROC_H及びPROC_Iへの呼
び出しは、なお以下に述べたように（即ち、再帰サイク
ルに繋がれていない手順と同じ方法で）処理することが
できる。

二つのデータ・フロー解析の使用は、定義−使用チェイ
ニングが、所定の手順を呼び出す手順及びそれが呼び出
す手順の双方を、ａ）定義−使用チェイニングを容認で
きない程の実行時間及びスペースの犠牲で全般的に遂行
したり、又はｂ）最適化を大きく弱める最悪の想定を、
これらの関係について為す必要無しに、考慮することが
できるようにする有益な目的に役立つ。こうして、その
呼び出しツリーに亘って複数のパスを使用することは翻
訳プロセスを扱い易くしている。それは又、プログラム
によって要求されるメモリ空間に肯定的に影響を及ぼし
且つ実行性能を改善する。最初のデータ・フロー解析パ
スは、ａ）それによって呼び出された手順によって少な
くとも潜在的に定義され、且つ、ｂ）その呼び出しの
後、その呼び出し手順中に使用される手順中で使用され
るこれらの変数のリストの規準に宛てられる。このリス
トは、呼び出された手順中の変数の定義がそれらを使用
する呼び出し手順のために保全されねばならない、変数
リストの第一の近似である。この近似は、呼び出された
手順中で実際に起きるこれらの定義のみを含むように、
後で第二のパス中で純化される。（呼び出しツリーの葉
に対しては、この純化は第一パス中でなされ得るが、こ
の実施例ではそうではない。） 順方向パス中の各手順の処理は第21図に、例示され、こ
の図は、第20図の呼び出しツリーに示される二つの手
順、ROC_K及びPROC_Jの基幹を示す。その後者は前者の
途中で二度呼び出される。見られるように、PROC_Jに対
するリストに対してPROC_Kの第一パス・データ・フロー
解析は、変数Ａ、Ｂ、Ｒ、Ｘ及びＹが全て上記規準に合
致することを見出だすことになるであろう。なお、種々
の手順中で現れるこれらの変数については以下に述べ
る。即ち、それらは潜在的にPROC_Jによって定義され、
それらへの呼び出しの後で使用される。PROC_Jの次ぎの
第二パス・データ・フロー解析は、実際にPROC_Jで定義
されたリスト上の最適の変数である単一の変数Ｘに対す
るこのリストを純化するであろう。

同様にして、PROC_Kを呼び出す手順の以前の処理は、変
数Ｗ、Ｒ及びＹからるPROC_Kのための使用リストの規準
に帰着している。PROC_Kの次の第二パス・データ・フロ
ー解析は、実際にPROC_Kで定義されたリスト上の最適の
変数である二つの変数Ｗ及びＹに対するこのリストを純
化するであろう。

上記のように、データ・フロヒ解析の第二ステップは変
数の明確な各叙述を見出だし、且つ各々を、定義の記憶
位置か又はしうの記憶位置であるとして、分類すること
である。このことは、第21図に、定義のリストと使用が
各プログラム・インストラクションで現れている二カラ
ムで反映されている。

又「使用」カラムに含まれて、いわゆる非明示の使用の
括弧内に記述項が有る。これは、PROC_Kを呼び出す手順
についての第一パスを処理中に、この処理が進行するに
連れ、それによって潜在的に定義されて明らかになるで
あろう方法で、識別された変数のリストである。こうし
て、第21図に示されるように、PROC_Kを呼び出す手順に
ついての、PROC_D及びMAIN（第20図）のような、第一パ
スのを処理は、PROC_Kによって潜在的に定義されると
き、変数Ｒ、Ｗ及びＹの識別を完了している。

第二パス・データ・フロー解析は、先ず各呼び出しを、
その手順中に使用を持つすべての変数の定義の記憶位置
であるとして、分類する。これらは、非明示の定義と名
付けられ、PROC_Jへの呼び出しの各々からPROC_Jへ亘る
「定義」カラム内の括弧内に示される。Ａ、Ｂ、Ｒ、
Ｗ、Ｘ、Ｙ及びＺは全て、PROC_K内に使用を持ち、各CA
LLPROC_Kインストラクションは、先ずこれらの変数の各
々の非明示の定義の記憶位置として見做される。この最
初の分類は、呼び出しうちの定義について、上記の悲観
的想定を具体化する。即ち、この点で、各呼び出しは呼
び出し手順内で叙述された各変数を定義することが想定
あれなければならない。

次ぎのステップは、各使用を一つ以上の定義と関連付け
るために、定義−使用チェイニングを遂行することであ
る。（この例では示されていないが、が、一つ使用に対
し多数の定義が存在することは、各々がそれに当てはま
るの変数の定義を含んでいるが、一繋がりになった幾つ
かの基本ブロックのチェーン内に有る、ある基本ブロッ
ク内に含まれる使用の結果として生じる。）特定の使用
と特定の定義との関連付けは、第21図に、各使用をその
明らかな定義と繋ぐ線で示される。例えば、インストラ
クション「Ｘ＝Ｚ」での「Ｚ」の使用は、早期にインス
トラクション「Ｘ＝10」内で定義される。更に、インス
トラクション「Ａ＝Ｙ」での「Ｙ」の使用は、早期に最
初のインストラクションCALLPROC_J内で定義（少なくと
も、この点で想定）される。そのうえ、PROC_K内のRETU
RNインストラクションに於ける「Ｙ」の非明示な使用
が、早期にインストラクション「Ｙ＝Ａ＋Ｂ」内で定義
される。

最後に、各呼び出しが検査され、それに関連付けられた
しらうを持つ定義が呼び出されつつある手順の戻りイン
ストラクションに関連付け非明示な使用のリストに加え
られる。こうして、PROC_Kの第一パス処理の終端で、変
数Ａ、Ｂ、Ｒ、Ｘ及びＹはPROC_JのRETURNインストラク
ションに記録される。これは、PROC_Kの見地から、PROC
_Jによって定義することができる最良の推量を表す。Ｗ
及びＺは、PROC_Jに対する呼び出し後は明示の使用を少
なくとも媒介定義なしでは持たず、それらは、PROC_Jの
終了点でRETURNと関連付けられた使用を非明示の使用の
リストに含まれない。更に、PROC_K内に非明示の定義及
び使用のみを持つ変数Ｒが、未だそのリストに含まれて
いることが注目される。実際、上記で考察したように、
変数ＲがPROC_Kを呼び出す何らかの手順によって使用さ
れ、この点で、変数がPROC_J内で定義され得ることが想
定されるに違いないのでそのことは適切である。（何故
なら、PROC_Jは未だ検査されておらず、確定した答えは
未だしられていない。） この点で、PROC_Kの第一パス処理は完了し、この処理
は、ａ）この点で、PROC_Jによって定義されるものと想
定されなければならず、且つ、ｂ）PROC_Jに対する呼び
出し後に使用される、PROC_K内で使用されたこれらの変
数を識別するその仕事を完了する。PROC_Jは呼び出しツ
リーの葉であるので、それは呼び出しを含まず、且つ、
実際、第一パスは呼び出しに関する情報を集めることに
当てられているので、PROC_J又は第一パス内のその他の
葉を処理する必要は無い。

第二の、データ解析ステップによる呼び出しツリーを通
る逆方パスは、各手順のデータ・フロー解析を再び全体
に亘って遂行するが、ここでは、ちょうど述べた如く、
第一パス内で集められた情報は使用しない。特に、その
定義−使用チェイニングは、スクラッチから再び、遂行
されるが、しかしここでは各手順に対して開発された非
明示な定義及び使用の純化されたリストを合同させる。

そのパスは逆順であるので、PROC_J及びその処理結果
は、第22図で示される。この図で示されるように、PROC
_Jの第二の、データ・フロー解析の第１ステップは、再
び、変数の各明示された叙述を見出だし、それを定義の
記憶位置又は変数の記憶位置の何れであるとして分類す
ることである。「使用」カラムに含まれているのは、第
一パス中に開発された非明示な使用のリストであり、こ
のリストは変数Ａ、Ｂ、Ｒ、Ｘ及びＹを持っている。
（もしPROC_Jを呼び出す他の手順が有った場合は、なお
他の変数が、これらの変数最初のパス中に処理されたと
き、なお他の変数がそのリストに加えられていよう）。
更に、このパスは、その手順の入口点に関連付けられた
非明示な定義のリストを作成するステップを含み、この
リストは、手順内で使用されるが、その中では定義され
ないそれら変数を含んでいる。特に、PROC_Jでは、この
リストは変数Ｑ及びＳから成っている。

第一パスでのように、次ぎのデータ・フロー解析ステッ
プは、解析されつつある手順によって呼び出れる全ての
手順に非明示な定義を関連付けることに関わる。しかし
ながら、PROC_Jは、他の手順は何れも呼び出しせず、従
って、このステップでは何のアクションも取られない。

次ぎのステップでは、再び定義−使用チェイニングが遂
行される。第22図に示すように、変数Ｘの非明示な使用
はインストラクション「Ｘ＝Ｑ＋Ｓ」内でその変数の定
義と関連付けられる。一方、変数Ｑ及びＳの明示された
使用は、PROC_Kの入口点と関連付けられた非明示な定義
と関連付けられる。しかしながら、変数Ａ、Ｂ、Ｒ及び
Ｙは、それらが、PROC_Kの有利点から、PROC_Jで潜在的
に定義されていた変数のリスト内に含まれていた事実に
もかかわらず、PROC_J内には定義を持たない。ここで、
第一パスのリストは、（第22図に、それらを通して置か
れたスラッシュで示すように）これらの変数を捨て、そ
れにより変数Ｘを唯一の記述項として残すことによっ
て、純化することができる。実際、変数Ｘは、PROC_Jに
対する呼び出しに続くPROC_K内で使用されるPROC_J内で
定義される唯一の記述項である。

ここで、PROC_Jを通じての第二データ・フロー解析が完
了する。即ち、PROC_J及び他の手順間の呼び出し関係を
考慮しつつ、最終的に且つ正しく到達している定義の計
算が遂行されている。ついで、共通副表現消去、不変量
コード・モーション、定数伝搬、スカラ伝搬及び休止コ
ード消去の次の変数がPROC_J上で遂行され、その手順の
裁量化が完了する。

結局、第二パスの処理がPROC_Kに遭遇し、PROC_Jの第二
パスの処理に関して上記に略述したと同様なステップが
遂行される。勿論、PROC_Jとは違い、PROC_Kは呼び出し
を含む。従って、又PROC_Jとは違い、定義がこれらの呼
び出しに関連付けられる。しかしながらここで、それ
は、第一パスでの場合であったような、PROC_K内で使用
された全変数のリストよりむしろ、使用されているPROC
_Jに対して先に開発された変数の純化されたリストであ
る。ここで、このリストは、それが実際、PROC_J、この
場合単一の変数Ｘによって、定義されているこれらの変
数のみを含むので、「完全」である。

更に、非明示な使用のリストは、各手順の呼び出しに関
連付けられる。なおこのリストは、以前、呼び出された
手順に対する第二パス中に開発された非明示な定義であ
る。

こうして、PROC_Kに於いて、PROC_Jの入口点での非明示
定義として開発された変数のリストが、PROC_Kに於ける
PROC_Jの呼び出しに対する非明示な使用として使用され
る。このステップは、PROC_K、又はそれを呼び出す手順
内の変数Ｑ及びＳの定義がPROC_Jに必要なので、必要で
ある。従って、そのような定義は、それらと関連付けら
れた使用を持つことによって、休止コード消去から保護
されなければならない。この例では、変数Ｑ及びＳは、
事実、PROC_Kで定義されず、且つその結果、それらがPR
OC_Jに対して為されたのと全く同様な仕方で、その手順
の入口点に関連付けられた非明示定義のリストに用意さ
れる。

定義−使用チェイニングが遂行され、PROC_Kに対するそ
の結果が再び接続線によって示される。ここで、PROC_J
についての純化された情報の使用が、第一パスでのその
計算に比して、定義に到達する計算に幾つかの顕著な違
いを起こしていたことが注意される。

例えば、インストラクション「Ｙ＝Ａ＋Ｂ」での変数Ａ
及びＢの使用は、PROC_Jに対する第二の呼び出しでの非
明示の定義と最早、関連付けられていず、むしろインス
トラクション「Ｂ＝Ｙ」及び「Ａ＝Ｙ」でのこれらの変
数の区域的定義に関連付けられている。次ぎの共通副表
現変換は、第16図に厳密に示すように、こうしてインス
トラクション「Ｘ＝Ａ＋Ｂ」及び「Ｙ＝Ａ＋Ｂ」が共通
副表現であり、且つ最適化に対する候補であると認知す
ることができるであろう。更に、変数Ｒは最早、PROC_J
の呼び出しによって定義されるとは想定されていので、
PROC_Kの出力点でのそれらの非明示使用も最早、何らの
関連付けられた定義を持たず、非明示使用のリストは、
第22図に、「Ｒ」を貫いて置かれたスラッシュで示すよ
うに）その変数を除外するように純化することができ
る。ちょうど考察したばかりの変数Ａ及びＢの場合との
直接的な類比で、PROC_Kの出力点に於ける非明示使用リ
ストからの変数この消去は、変数Ｒが最早、PROC_Kで定
義されるべきこれらの呼び出し手順によって想定される
変数のリスト上ち現れないであろうから、PROC_Kを呼び
出す手順の最適化を引き続き与かるであろう。

又、PROC_K内の変数Ｘの四つの定義のうち三つ、即ち、
定義「Ｘ＝Ｚ」、「Ｘ＝Ａ＋Ｂ」及び第二のCALLPROC_J
インストラクションに関連付けられている使用は無いこ
とが注意される。こうして、これら三つのインストラク
ションの全ては休止コード消去によって削除されよう。
（インストラクション「Ｘ＝Ａ＋Ｂ」は、共通副表現消
去ステップによって、第16図に示すような形態「Ｘ＝＠
１」に変換されているであろうが、それにも拘らず、関
連付けられた使用が欠乏しているため、休止コード消去
によって除去されるであろう。） PROC_Kを通してのデータ・フロー解析の第二パスも又、
ここで完了する。こうして、共通副表現消去、不変量コ
ード・モーション、定数伝搬、スカラ伝搬及び休止コー
ド消去はPROC_K上で遂行され、その手順の最適化が完了
する。

ここで、第12図に戻って、その最適化の変換要素の最終
フェーズが「合成」であることを見てみよう。変換のこ
の合成フェーズの全般的ゴールは、現に動作しているア
センブリ言語表現よりは元のコンパイラ・ソース言語に
近いプログラム表現を発生することである。このように
することは、目標マシンの資源及び能力を効果的に使用
するためにより大きな機会を持ったコード発生要素を提
供するであろう。このことは、翻訳されたプログラムの
規模と実行速度（性能）の双方とも改良する。

この目的のため、変換の合成フェーズは、それらが現に
中間言語に変換されているソースマシン目的コードであ
るそれらより効率的に表現し得る「高レベル」機能とし
て認め得る中間言語構造のシーケンスを探す。例えば、
ソースマシン・プロセッサは直接、32ビット乗法演算を
遂行することはできず、むしろそれを遂行するための一
連のインストラクションを必要とするものと想定する。
しかしながら、目標マシンは直接、32ビット乗法演算を
遂行することはできる。その合成フェーズは、インスト
ラクションのパターンが実際、32ビット乗算を構成して
いることを認知し、、且つ中間言語バージョンに於ける
適切な単一インストラクションを代行するように設計す
ることができる。他の例は、Ｃ言語「交換」文、パスカ
ル「格」文、折り返し論理構成、等である。

合成フェーズに使用できる認知可能シーケンスのレパー
トリは、翻訳ソフトウェアの開発中、ソースマシン及び
目標マシンの設備及び元の目的コードの特徴を検査する
ことによって、経験的に開発されている（勿論、それら
は最初の位置でソースマシンのアプリケーション目的コ
ードを発生したコンパイラの特徴に依存する）。

要するに、共通副表現消去、不変量コード・モーショ
ン、定数伝搬、スカラ伝搬及び合成は、本質的に、同等
で小さいインストラクションのグループをで置き換え得
る、拡大したインストラクションのグループを識別する
パターン認識技術である。不変量コード・モーションは
パターン認識技術の別のタイプである。これは、拡大し
たインストラクションの数を減らしはしない。しかしな
がら、これは、インストラクションのシーケンスが。前
記第二バージョン内のインストラクションの順序換えさ
れた同等なシーケンスを識別することによって、そのイ
ンストラクション、により効率的な順序換えをおこな
う。

コード発生 翻訳プロセスのコード発生フェーズは、実質的に伝統的
なコンパイラのコード発生フェーズと同じである。即
ち、上記したように最適化された、アプリケーションの
中間言語バージョンは、格中間言語インストラクション
に一つ以上の適切な目標マシンのアセンブリ言語インス
トラクションを置き換えることによって、目標マシンの
アセンブリ言語へ変換される。そこで、その結果のコー
ドは、目標マシンの目的コードにアセンブルされ、翻訳
されたシステム・ソフトウェアと結び付けられる。−P/
39、L/2− 第23図は、翻訳されたアプリケーションが翻訳されたシ
ステム・ソフトウェア及び目標マシンシステム・ソフト
ウェアと結び付けられる方法を例示的に示す。このよう
な情況においては、用語「結び付け」は、ソフトウェア
内の記号アドレスを究極的に、プロセッサが動作するこ
とができる実際のアドレスに変換するプロッセスに関係
する。

より明確には、この分野で極めて伝統的であるように、
この結び付けは、例示的には二つのステージ内に在る。
第一ステージでは、「連結」として知られているよう
に、「翻訳されたシステム・ソフトウェアのような」第
二目的コード・モジュールの入口点への（被変換アプリ
ケーションのような）第一目的コード・モジュール内の
記号基準が、結合された目的プログラムの第一アドレス
にに関して、そのような入口点の全てにラベル付けする
数値オフセットに変換される。第二ステージは、いわゆ
る「ローディング」プロセス内に包含されており、この
ステージでは、その後、それらのオフセットが、プロセ
ッサが動作することができるアドレスに変換される。

ついで、第12図では、その第一カラムが三つの目的モジ
ュール、即ち、被変換アプリケーション、翻訳されたシ
ステム・ソフトウェア及び目標マシンのシテム・ソフト
ウェアをコンパイルされた形態で示す。この点でモジュ
ールの各々は、それ自体のセットで0x0で始まり、それ
ぞれ0x1000、0x200及び0x600で終了するアドレス記憶位
置を持つものとして考えることができる。

その被変換アプリケーションは、例示的にそのアプリケ
ーションにたいして内部的である手順PROC_Jに対する呼
び出しを有する。こうして、そのトランスレータの、こ
の事項に関してはコンパイラ機能を奏するコード発生要
素は、0x200に於けるPROC_Jに対する規準を識別できて
いて、中間言語コード中の「PROC_J」の叙述でもあった
ものを、そのモジュールの出発点、即ち例示的には0x80
0である入口点に関して、PROC_Jの入口点の記憶位置を
表示するオフセットに置換し終わっている。

更に、その被変換アプリケーションは、それぞれ翻訳さ
れたシステム・ソフトウェア及び目標マシンのシステム
・ソフトウェアのプログラムである、システム・サービ
スSERVICE1及びSERVICE2に対する二つき呼び出しを含
む。これらは被変換アプリケーションの外部に有る基準
プログラムを呼び出すので、SERVICE1及びSERVICE2の叙
述はコード発生部によって「解明」、即ちオフセットに
置換され得ない。同様に、目標マシンのシステム・ソフ
トウェア内のシステム・サービスSERVICE3に対する翻訳
されたシステム・ソフトウェア内の規準はこの点で解明
されずに残る。

第23図の第二カラムは、リンキング（結び付け）後の三
モジュールを示す。とりわけ、リンカー（結び付け部）
はこれら三モジュールを、0x0から0x800までの単一のア
ドレス・スペクトラムに組み合わせており、且つ各イン
ストラクションはそのスペクトラム内にアドレスを持っ
ている。こうして、ここでは、翻訳されたシステム・ソ
フトウェアの第一アドレスは0x1000であり、一方、目標
マシンのシステム・ソフトウェアの第一アドレスは0x10
00である。SERVICE1、SERVICE2及びSERVICE3に対する種
々の記号規準は、リンクされたモジュールの開始点に関
してそれぞれ計算されたオフセット、即ち0x1000、0x13
00及び0x1600で置換され得る。

あるコンピュータ・システムでは、言わば、呼び出しイ
ンストラクションが、実際のアドレス実行中、そのオフ
セットを呼び出しインストラクション自体のアドレスに
加えることによって決定される際に、結び付け部によっ
て与えられたオフセットが、プログラム実行のための適
切な基礎、即ち、オフセットによって識別されたプログ
ラム・コードのメモリ内の実際のアドレスを提供する。
こうして、例えば、第二の翻訳されたアプリケーション
の呼び出しに於けるオフセット0x800は、制御のフロー
が記憶位置0x1000へ移行すべきことを判定するために、
その呼び出し自体の記憶位置0x200に加えられる。しか
しながら、本発明の例示的実施例では、プロセッサは、
実行可能コードが、オフセットよりむしろアドレスを含
むことを必要とする。これは、そのコードが実行のため
にRAMにロードされるとき、そのコードをロードする実
際の開始RAMアドレスを各オフセットへ単に加えること
によって、適応される。こうして、第23図の第三カラム
に示すように、そのリンクされたモジュールは記憶位置
0x500へ始まるRAMにロードされていて、ここで、全ての
呼び出しが、その呼び出しの目標として、0x5000の適切
なオフセットとの和によって与えられた計算済みのアド
レスを識別する。

他の実施例 前記は、単に本発明の原理を示す。

例えば、図示し且つ上記した例示的実施例では、ソース
マシン及び目標マシンは本質的に異なるインストラクシ
ョン・セットをもつ本質的に異なるインストラクション
を持っている。しかしながら、これは、二つのプロセッ
サが共通のプロセッサ・ファミリに属している場合であ
ってもよい。従って、同じインストラクション・セット
を持つが、しかし、そのプロセッサの一つは、例えば24
ビットのアドレス空間を有し、且つ他のプロセッサの一
つは、32ビットのアドレス空間を有することができる。
こうして、この翻訳はインストラクションの小部分の変
換のみに関わることもできる。

他の例としては、図示し且つ上記した例示的実施例に於
いて、本発明に従って、目標マシン上で実行し且つ翻訳
されたシステム・ソフトウェアを呼び出すアプリケーシ
ョンは、それ自体が翻訳されたプログラムである必要は
無い。例えば、ソースマシン及び目標マシンは、同等な
プロセッサのタイプを使用することができ、従って、そ
のソースマシン用にコンパイルされているアプリケーシ
ョンは、翻訳される必要無く目標マシン上で実行可能で
あろう。しかしながら、その二つのマシンのシステム・
ソフトウェアとアドレス空間の双方又は一方は相違して
いてもよい。こうして、翻訳不必要なアプリケーション
を目標マシン上での実行のために翻訳されたシステム・
ソフトウェアにリンクすることは有益であろう。

更に、ここで説明した本発明は、翻訳されつつあるプロ
グラムの目的コード・バージョンに対して動作するが、
入力プログラムは、別に例えば、ａ）そのアセンブリ言
語バージョンであってもよく、又はｂ）ソースマシン上
で通訳するように意図された形態になっている、いわゆ
る通訳コードに含まれていてもよい。後者の例には、UC
SDパスカルＰ−コード・コンパイラによって出力される
プログラムが有る。幾つかの場合、相違する中間アセン
ブリ言語は必要でないかも知れない。それで、元のアセ
ンブリ言語又は他のインストラクション・セットに関し
ては、むしろ拡大が遂行され得る。更に、翻訳されたプ
ログラムを目標マシンの目的形態にコンパイルするよ
り、むしろ（通訳要素を用いて）アセンブリ形態に実行
することが望ましいかも知れない。

従って、この分野での技術者が、ここには明示的に示さ
れ或いは述べられていないが、本発明の原理を含み、従
ってその精神及び範囲に有る、多くの構成を案出し得る
ことが理解されよう。

【図面の簡単な説明】

第１図は、例示的なソースコンピュータのブロック・ダ
イアグラムを示す図； 第２図は、例示的な翻訳コンピュータのブロック・ダイ
アグラムを示す図； 第３図は、例示的な目標コンピュータのブロック・ダイ
アグラムを示す図； 第４図は、典型的なソースコンピュータ及び目標コンピ
ュータのアドレス空間を示す論理図； 第５図は、目的コードのハードウェア・エミュレーショ
ン及びソフトウェア・エミュレーションを示す論理図； 第６図は、目的コード翻訳のオフライン・フェーズを示
す論理図； 第７図は、目的コード翻訳の実行時フェーズの一形態を
示す論理図； 第８図は、目的コード翻訳の実行時フェーズの第二形態
を示す論理図； 第９図は、第８図に示す仮想ハードウェア項目モニタの
動作を示すフロー・チャート； 第10図は、被翻訳ソフトウェアを作成し且つ実行する全
般的プロセスを例示的に示すフロー・チャート； 第11図は、ソースマシンのアセンブリ言語コードの部分
が、トランスレータの分析フェーズ中に拡大され、その
後その最適化フェーズ中に圧縮される方法を示す図； 第12図は、本発明を履行するために使用される例示的な
トランスレータの要素を示すフロー・チャート； 第13図は、このトランスレータの分析要素を示すフロー
・チャート； 第14図は、このトランスレータの分析要素が、翻訳され
ているアプリケーションを、いわゆる基本ブロックに分
割する方法を示す図； 第15図は、いわゆる手順に組み合わされた幾つかの基本
ブロックを示すグラフ； 第16図乃至第19図は、トランスレータの最適化要素中に
遂行され、異なる変換を例示するアセンブリ言語コード
の種々の部分を示す図； 第20図は、本発明の特徴に従い、トランスレータの最適
化要素によって使用される、いわゆる呼び出しツリーの
例を示す図； 第21図及び第22図は、本発明の特徴に従い、トランスレ
ータの最適化要素中に遂行される二つのデータ・フロー
解析パス中に、プログラム・コードが処理される方法を
示す図；そして 第23図は、被翻訳アプリケーションを被翻訳システム・
ソフトウェア及び目標マシンのシステム・ソフトウェア
に結び付ける仕方を示す図 である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アーバン ジェイ クランツラー アメリカ合衆国，07724 ニュージャージ ィ イートンタウン，アラミダ コート 17 (72)発明者 クリストファー ジェイムス メイシー アメリカ合衆国，07701 ニュージャージ ィ レッド バンク，エルム プレイス 54 (72)発明者 マーク ローガン トーメノクサ アメリカ合衆国，07702 ニュージャージ ィ シュルーズバリー，フランシス スト リート 20 (56)参考文献 特開 昭60−142428（ＪＰ，Ａ) 特開 昭60−17539（ＪＰ，Ａ)

Claims (18)

【特許請求の範囲】
1. 【請求項１】ソースコンピュータ・システム上で実行可
   能な非ソースコード形態から目標コンピュータ・システ
   ム上で実行可能な非ソースコード形態へオフラインで全
   体として変換された応用プログラムを実行する目標コン
   ピュータ・システムにおいて、 前記目標コンピュータ・システム上で実行可能な非ソー
   スコード形態は、前記ソースコンピュータ・システム上
   で実行可能な非ソースコード形態のほぼ全機能を含み、 前記ソースコンピュータ・システムは、前記応用プログ
   ラムが前記ソースコンピュータ・システム上で実行され
   るとき、前記応用プログラムにシステム・サービスを提
   供するべく前記ソースコンピュータ・システム上で実行
   可能なソースコンピュータ・システム・ソフトウェアを
   含み、 前記目標コンピュータ・システムが、 前記変換された応用プログラムが前記目標コンピュータ
   ・システム上で実行されるとき、その変換された応用プ
   ログラムにシステム・サービスを供給する目標コンピュ
   ータ・システム・ソフトウェアと、 前記変換された応用プログラムおよび前記目標コンピュ
   ータ・システム・ソフトウェアを実行する手段とからな
   り、 前記目標コンピュータ・システム・ソフトウェアが、前
   記目標コンピュータ・システム上で実行可能な形態へ翻
   訳された前記ソースコンピュータ・システム・ソフトウ
   ェアの少なくとも一部を含むことを特徴とする目標コン
   ピュータ・システム。
2. 【請求項２】前記目標コンピュータ・システム・ソフト
   ウェアが、前記目標コンピュータ・システムのメモリ空
   間内で前記ソースコンピュータ・システムのアドレス空
   間のイメージを生成する機能を有し、 前記イメージ内の所定の記憶位置をモニタし、その記憶
   位置の内容の変化に応答して、前記イメージ外の前記目
   標コンピュータ・システムのアドレス空間の対応する記
   憶位置に変化を生じさせる事象モニタ手段をさらに有す
   ることを特徴とする請求項１のシステム。
3. 【請求項３】前記事象モニタ手段の動作は、前記目標コ
   ンピュータ・システム内で周期的に呼び出されることを
   特徴とする請求項２のシステム。
4. 【請求項４】前記事象モニタ手段の動作は、タイマ割り
   込みに応答して、前記目標コンピュータ・システム内で
   周期的に呼び出されることを特徴とする請求項２のシス
   テム。
5. 【請求項５】前記目標コンピュータ・システム・ソフト
   ウェアが、前記目標コンピュータ・システムのメモリ空
   間内で前記ソースコンピュータ・システムのアドレス空
   間のイメージを生成する機能を有し、 前記イメージ外で前記目標コンピュータ・システムのア
   ドレス空間内の所定の記憶位置をモニタし、その記憶位
   置の内容の変化に応答して前記イメージ内の対応する記
   憶位置に変化を生じさせる手段をさらに有することを特
   徴とする請求項１のシステム。
6. 【請求項６】前記目標コンピュータ・システム・ソフト
   ウェアが、前記目標コンピュータ・システムのメモリ空
   間内で前記ソースコンピュータ・システムのアドレス空
   間のイメージを生成する機能を有し、 前記ソースコンピュータ・システムのハードウェア装置
   に対応する前記イメージ内の記憶位置をモニタし、その
   記憶位置の内容の変化に応答して前記目標コンピュータ
   ・システムのハードウェア装置に対応する前記目標コン
   ピュータ・システムのアドレス空間の記憶位置に変化を
   生じさせる手段をさらに有することを特徴とする請求項
   １のシステム。
7. 【請求項７】前記目標コンピュータ・システム・ソフト
   ウェアが、前記目標コンピュータ・システムのメモリ空
   間内で前記ソースコンピュータ・システムのアドレス空
   間のイメージを生成する機能を有し、 前記目標コンピュータ・システムの特定のハードウェア
   装置に関係付けられた前記目標コンピュータ・システム
   のアドレス空間の記憶位置をモニタし、その記憶位置の
   内容の変化に応答して前記ソースコンピュータ・システ
   ムの各ハードウェア装置に関係付けられた前記イメージ
   内の記憶位置をアクセスする手段をさらに有することを
   特徴とする請求項１のシステム。
8. 【請求項８】前記事象モニタ手段の動作は、前記目標コ
   ンピュータ・システム内で周期的に呼び出されることを
   特徴とする請求項７のシステム。
9. 【請求項９】前記事象モニタ手段の動作は、タイマ割り
   込みに応答して、前記目標コンピュータ・システム内で
   周期的に呼び出されることを特徴とする請求項７のシス
   テム。
10. 【請求項１０】前記ソースコンピュータ・システムが、
    第１インストラクション・セットを有するプロセッサを
    含み、前記目標コンピュータ・システムが、前記第１イ
    ンストラクション・セットとは異なる第２インストラク
    ション・セットを有するプロセッサを含むことを特徴と
    する請求項１のシステム。
11. 【請求項１１】前記目標コンピュータ・システム・ソフ
    トウェアが、前記目標コンピュータ・システムのメモリ
    空間内で前記ソースコンピュータ・システムのアドレス
    空間のイメージを生成する機能を有し、 前記イメージ内の所定の記憶位置をモニタし、その記憶
    位置の内容の変化に応答して、前記イメージ外の前記目
    標コンピュータ・システムのアドレス空間の対応する記
    憶位置に変化を生じさせる事象モニタ手段をさらに有す
    ることを特徴とする請求項10のシステム。
12. 【請求項１２】前記目標コンピュータ・システム・ソフ
    トウェアが、前記目標コンピュータ・システムのメモリ
    空間内で前記ソースコンピュータ・システムのアドレス
    空間のイメージを生成する機能を有し、 前記イメージ外で前記目標コンピュータ・システムのア
    ドレス空間内の所定の記憶位置をモニタし、その記憶位
    置の内容の変化に応答して前記イメージ内の対応する記
    憶位置に変化を生じさせる手段をさらに有することを特
    徴とする請求項10のシステム。
13. 【請求項１３】ソースコンピュータ・システム上で実行
    可能であるが目標コンピュータ・システム上で実行可能
    でない非ソースコード形態から目標コンピュータ・シス
    テム上で実行可能な非ソースコード形態へオフラインで
    全体として変換された非ソースコード・バージョンの応
    用プログラムを前記目標コンピュータ・システム内で実
    行する方法において、 前記目標コンピュータ・システム上で実行可能な非ソー
    スコード形態は、前記ソースコンピュータ・システム上
    で実行可能な非ソースコード形態のほぼ全機能を含み、 前記ソースコンピュータ・システムは、前記応用プログ
    ラムが前記ソースコンピュータ・システム上で実行され
    るとき、前記応用プログラムにシステム・サービスを提
    供するべく前記ソースコンピュータ・システム上で実行
    可能なシステム・ソフトウェアを含み、 前記目標コンピュータ・システム上で実行可能な形態へ
    翻訳された前記ソースコンピュータのシステム・ソフト
    ウェアの少なくとも一部を含み前記変換された応用プロ
    グラムが前記目標コンピュータ・システム上で実行され
    るときに前記変換された応用プログラムによって参照さ
    れて前記変換された応用プログラムにシステム・サービ
    スを供給するシステム・ソフトウェアに、前記変換され
    た応用プログラムを結合するステップと、 その結合した結果の応用プログラムおよびシステム・ソ
    フトウェアを実行するステップとからなることを特徴と
    する、異なる目標コンピュータ・システムでプログラム
    を実行する方法。
14. 【請求項１４】前記目標コンピュータ・システムのメモ
    リ空間に前記ソースコンピュータ・システムのアドレス
    空間のイメージを生成するステップと、 前記イメージ内の所定の記憶位置をモニタするステップ
    と、 前記記憶位置の内容の変化に応答して、前記イメージ外
    の前記目標コンピュータ・システムのアドレス空間の対
    応する記憶位置に変化を生じさせるステップとをさらに
    有することを特徴とする請求項13の方法。
15. 【請求項１５】前記目標コンピュータ・システムのメモ
    リ空間に前記ソースコンピュータ・システムのアドレス
    空間のイメージを生成するステップと、 前記イメージ外の前記目標コンピュータ・システムのア
    ドレス空間内の所定の記憶位置をモニタするステップ
    と、 前記記憶位置の内容の変化に応答して、前記イメージ内
    の対応する記憶位置に変化を生じさせるステップとをさ
    らに有することを特徴とする請求項13の方法。
16. 【請求項１６】ソースコンピュータ・システム上で実行
    可能な非ソースコード応用プログラムを目標コンピュー
    タ・システム上で実行する方法において、 前記ソースコンピュータ・システムは前記応用プログラ
    ムが前記ソースコンピュータ・システム上で実行される
    とき前記応用プログラムにシステム・サービスを供給す
    るべく前記ソースコンピュータ・システム上で実行可能
    なシステム・ソフトウェアを含み、 前記ソースコンピュータ・システム上で実行可能な非ソ
    ースコード形態のほぼ全機能を含む、前記目標コンピュ
    ータ・システム上で実行可能な非ソースコード形態に、
    前記応用プログラムをオフラインで全体として翻訳する
    ステップと、 前記ソースコンピュータ・システム・ソフトウェアの少
    なくとも一部を前記目標コンピュータ上で実行可能な形
    態に翻訳するステップと、 翻訳した応用プログラムを翻訳したシステム・ソフトウ
    ェアに結合するステップと、 その結合した結果の前記翻訳した応用プログラムおよび
    前記翻訳したシステム・ソフトウェアを実行するステッ
    プとからなることを特徴とする異なる目標コンピュータ
    ・システムでプログラムを実行する方法。
17. 【請求項１７】前記目標コンピュータ・システムのメモ
    リ空間に前記ソースコンピュータ・システムのアドレス
    空間のイメージを生成するステップと、 前記イメージ内の所定の記憶位置をモニタするステップ
    と、 前記記憶位置の内容の変化に応答して、前記イメージ外
    の前記目標コンピュータ・システムのアドレス空間の対
    応する記憶位置に変化を生じさせるステップとをさらに
    有することを特徴とする請求項16の方法。
18. 【請求項１８】前記目標コンピュータ・システムのメモ
    リ空間に前記ソースコンピュータ・システムのアドレス
    空間のイメージを生成するステップと、 前記イメージ外の前記目標コンピュータ・システムのア
    ドレス空間内の所定の記憶位置をモニタするステップ
    と、 前記記憶位置の内容の変化に応答して、前記イメージ内
    の対応する記憶位置に変化を生じさせるステップとをさ
    らに有することを特徴とする請求項16の方法。