JPH03118635A - ソースコード発展システム用増分コンパイラ - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 本発明はコンピュータプログラミング、殊にコンピュー
タ支援によるソフトウェア開発に関する。

本発明の目的はソフトウェア開発のスピードと生産性を
向上させるぺ（設計されたプログラミング環境、殊にソ
フトウェア開発プロセスのエディツト−コンパイル−リ
ンク−ランサイクルにおいてコンパイルのしなおしとリ
ンクしなおしに対して必要とされる時間を相当減少させ
る方法を提供することである。コードが書かれる際、ユ
ーザがアプリケーションソースコードに対して僅かな変
更を行った後のエディツト−コンパイル−リンク−ラン
サイクル中に経過した時間はターンアランドタイムと呼
ばれている。本発明の第１の目的はこのターンアラウン
ドタイムを最小限にすることである。

本文中で使用する際のプログラミング「環境」とは通常
端末に着席してコード作成作業に従事している開発者に
とってエディツト−コンパイル−リンク−ランサイクル
を実行するために使用されるプログラムもしくはモジュ
ール（即ち、コード）の集合を意味する。本発明の主題
である環境は「環境」と呼ばれるが同環境の下で開発さ
れるプログラムは何れも「アプリケーション」と称され
るであろう。環境は、環境自体を含めて、任意のアプリ
ケーションの開発を支援することができる。

環境のユーザは「開発者」と呼び、アプリケーションの
ユーザは「エンドユーザ」と称する。

ソフトウェア開発の特徴は、プログラムをエディツトし
、コンパイル、リンクし、同プログラムをランするステ
ップを含むプロセスである。コンパイラは、パスカルや
フォートランの如き高水準言語で書かれた原始プログラ
ムを目的プログラムとして知られている機械実行可能な
書式に変換する。

ソフトウェア開発プロセスは更に幾つかの段階に分けら
れる。初期の段階はアプリケーションソースファイルの
全てもしくは大部分の活動（例えばエディツト作業）が
高速で大規模であることに特徴を有し、後半の段階は、
ソースファイルの全体より少ない部分の変化が頻繁であ
りり小さい点に特徴がある。初期の段階ではその目的は
原始コード中のシンタックスの誤りと、アプリケーショ
ン中の論理上の誤りを取除（ことである。最終段階の目
的はアプリケーションの効率を向上させエンドユーザに
配布される時の形のアプリケーションの挙動をテストす
ることである。

効率の点から測定したコンパイラにより生成される目的
コードの品質は出来るだけ良好なものであることが望ま
しい。′すこぶる効率的な目的コードを生成するコンパ
イラは最適化コンパイラとして知られている。最適化さ
れただ目的コードの特徴は効率性が最大限にされて実行
時間が最小限であることである。然しなから、効率性の
高い目的コードを生成するために最適化コンパイラによ
り使用される複合的な方法と技法は必然的にそのコンパ
イル時間を比較的長いものにすることになる。

論理上の誤りを除去することは、アプリケーションの実
行の効率とは相対的に独立している。それ故、ソフトウ
ェア開発の初期段階では、環境は最適化に対するターン
アラウンドタイムに強調点をおくことが望ましい。更に
、初期段階では境界オーバランの如き一定種類の検出可
能な故障に対してアプリケーション−ラン−タイムチェ
ックを挿入することが有益である。最終段階中における
効率とテストに対する関心は最適化を必要とし、変更の
頻度が少ないことは伝統的なソフトウニアトウールの使
用を効率的にする。

特定のソフトウェア部分を開発する際にはエディツト−
コンパイル−リンク−ラン−サイクルが何度も反復され
るのが普通である。この活動のどんな段階でも、開発者
は検出された誤りを訂正する必要があるかもしれない。

（本文中では変更を行うための動機は先の見落しを修理
するか新たな機能性を追加するかの何れかであるから、
「誤り」とは「変更の必要」と意味する）「誤り」はコ
ンパイラ、リンカ、あるいは後になってはテスト実行中
のプログラマにより検出される。従来環境におけるこの
反復形式のため、コンテキストの変更は頻繁になり開発
者に対する遅れが生ずる。開発者がエディタ、コンパイ
ラ、リンカ、およびアプリケーションそれ自体を別個に
かつ順次呼出す間にコンテキストの変更が生ずる。これ
ら別個のトゥールがそのタスクを完了することを開発者
が待つ間に遅れが生ずる。

かくして、−アプリケーションの開発の最終段階、即ち
生産品質目的コードを生成する際には長いコンパイルタ
イムが許容できる一方、これらの遅れは、長いコンパイ
ルとリンクタイムがずっと注目を惹くようなソフトウェ
アの開発、テスト、ならびにデバッグプロセスの初期段
階では許されない。何故ならば、それらはずっと頻繁に
呼出されるからである。更に、開発中に行われるアプリ
ケーションコードの変更は通常局部的なもので、プログ
ラムの残部に対してその大きさは小さいのが普通である
。公知のソフトウェア開発環境では、アプリケーション
モジュールをコンパイルするためのターンアラウンドタ
イムは、モジュールの大きさに対して比例しており、一
つのアプリケーションをリンクするためのターンアラウ
ンドタイムはモジュールの大きさと数に比例している。

本発明の環境では、コンパイルとリンクのターンアラウ
ンドは、最後のコンパイル／リンク処理後に開発者によ
って行われる原始プログラムに対する変更の大きさに比
例している。多くのアプリケーションプログラムは１０
０．０００〜１．０００．０００もしくはそれ以上のコ
ード行を有している。即ち、かかるプログラムを開発す
る際のターンアラウンドタイム（エディツト−コンパイ
ル−リンク−ランのループを完了するための時間）は−
晩中要する活動となる虞れがあり、従って大きな負担を
提示している。

かくて、エディツト−コンパイル−リンク−ランのサイ
クルの高速な夕、−ンアラウンドを可能にするソフトウ
ェア開発環境を提供することが望ましい。

市販されている開発コンパイラ例としては、マイクロソ
フト社による「クイックＣＴ′４」、サイマンチック社
による「ライトスピードＣ」、ボーランド社による「タ
ーボＣ」、およびセイバー社によるセイバーＣがある。

これら従来のシステムは伝統的なバッチコンパイラより
も高速で、一定程度のくバッチ処理と区別される）増分
処理を提供することができる。例えば、最後のエディツ
ト−コンパイル−リンク−ランサイクル以来そのモジュ
ールしか変更されていなければ、そのモジュールは別個
に処理することができる。この増分処理のレベルは粗粒
（ｃｏａｒｓｅ−ｇｒａｉｎｅｄ　）増分処理として知
られている。

本発明の一実施例によれば、最後のエディツト−コンパ
イル−リンク−ランサイクル以来変更されなかった一行
コード程度の大きさの増分がコンパイルし直される代り
に再使用される点で、全体として微粒増分方式で動作す
るソフトウェア開発システムもしくは環境が提供される
。−例では一増分は一行のコード（もしくは−もしくは
それ以上の行のコード）であるか、セマンテイック増分
の如き別の適当な太きである。サイクル中の種々の位置
では増分の大きさはそのレベルに適当なものに対応する
。−例として、高速コンピュータ支援ソフトウェア工学
・開発システム（以下、それに代えてｒＲｃＡｓＥＪと
いう頭字語を使用する）と称されるシステムを開示する
。このシステムは、特に現存の伝統的なソフトウェア開
発プロセスに共通なエディツト−コンパイル−リンク−
ランのサイクルにおけるコンパイルとリンクのし直しに
要する時間を相当減少することによって、ソフトウェア
開発エンジニアのスピードと生産性を向上させるべく設
計されたプログラミング環境と一連のファシリティ−も
しくはサービスを提供する。

本文中に開示の幾つかの異なる特徴はこれらの目標を達
成するために向けられている。ＲＣＡＳＥプログラミン
グ環境は、増分スキャナ、増分リンカ、増分モジュール
依存解析ファシリティ、および仮想メモリマネージャを
含む微粒増分く例えば、−回一行）コンパイラを使用し
てスラッシュを減らしたり防止したりする。コンテキス
トのセーブとスイッチングの機構と、チェックポイント
／再スタートの機構は重要な特徴である。更に、ＲＣＡ
ＳＥシステムは、種々のインターフェース条件と合致す
る何れかの呼出し可能なエディタ、コンパイラ、もしく
はデバッガと共に動作するように設計されている。呼出
し可能なオブジェクトファイルトランスフォーマを含め
ることによって環境外部に準備されたアプリケーション
に対するアクセスを可能にすることができる。ランタイ
ムライブラリーに対するアクセスも準備されている。

本発明によるプログラミング環境では、目的コードの品
質は、プログラムの編集と実行の間の時間を少な（する
目標が至上命題であるために強調されていない。システ
ムの速度を太き（するために、ＲＣＡＳＥ環境において
生成される目的コードは最適化されず、仮想メモリ内に
残り、アプリケーションをテストするためにだけしか使
用されない。実行可能な目的コードファイルは決してデ
ィスクにセーブされることはない。それ故、開発フェー
ズの完了直後に品質目的コードを生成するために最適化
コンパイラを使用する必要がある。

上記したような今日使用可能な開発コンパイラの大部分
は、その目標の一つとして、セーブされた最適化されな
い目的コードの作成を有しているが、開発者が開発コン
パイラにより生成される目的コードを改良するためにコ
ンパイラを書く人々に対する負担を課すことになるため
に開発システムは緩慢になる。従って、本発明と公知の
ソフトウェア開発システム（セイバーＣは除く）との間
の重要な区別は、ＲＣＡＳＥ環境が、使用可能な目的コ
ードの生成とは反対に゛、迅速かつ効率的に品質コード
を作成する上でプログラマを補助することに向けられて
いる点である。

第１図について述べると、エディツト−コンパイル−リ
ンク−ランのサイクルチャートが示されている。ソフト
ウェア開発において、このサイクルは何回も反復される
ことが普通である。開発者が原始コードを作成もしくは
変更している限り、エディツト機能１０が実行される。

伝統的なシステムでは、原始テキストはファイル構造内
にあるが、本発明では、原始テキストはメモリ内のバッ
ファ内に維持されている。開発者が彼が書いたコードを
テストしたいと望む地点に達すると、コンパイラ１１が
呼出される。コンパイラ１１に対する入力は、エディタ
１０により作成される原始コードテキストである。普通
の場合、一連の原始コードテキストバッファ１２が存在
し、その一つは開発中の各アプリケーションモジュール
に対するものである。本発明の特徴によれば、変更され
ていないもしくは変更コードに依存していないモジュー
ル１２はコンパイルし直されない。もし誤りがコンパイ
ラ１１により発見されると、処理は誤りのロケーション
と性質を通知を伴いなから経路１３によってエディタ１
０へ戻される。即ち、本発明の特徴は、第１の誤りを認
識した直後にコンパイラがその誤りを報告し、クイツト
し、エディタへ戻り、発見された誤りの全てのリストを
完成して戻すことをしない点である。コンパイルフェー
ズ中に何らの誤りも発生しなければ、コンパイラ１１の
出力として作成された目的コードのテーブル１４（およ
び、以下に述べるように全体をコード・データ・シンボ
ルバッファとまとめて称されるその他の情報）がリンカ
１５に対する入力となる。更に、各モジュールに関して
説明される他のデータ構造と共に各ソースコードテキス
トモジュール１２と関連するコードテーブル１４が存在
する。リンカ１５は入力としてメモリ内の実行可能な目
的コードイメージ１６をつくりだす。但し、連結が試み
られるときに誤りに出会う場合は処理は経路１７を介し
てエディタ１０へ戻される。再びクイツト−オン−ファ
ースト−エラー原理が使用される。実行可能なコードイ
メージ１６は実際には、コードテーブル１４と、ランタ
イムライブラリからの情報と共にリンカ１５により作成
されたリンクテーブルより構成され、何れの場合にもコ
ードイメージ（メモリ内）はラン機能１８により表示さ
れるように実行される。もしランフニーズにおいて論理
上の誤りやランタイムの誤りが発見されれば、プログラ
マはエディツトフェーズに戻る。コードイメージ１６は
何らの誤りも報告されずに実行された後、デバッグ済み
の目的コードとして伝統的なシステム内にセーブされる
ことになろう、然しなから、本発明によれば、所望の目
的はデバッグ済みの原始コード、即ち、原始テキストモ
ジュール１２である。即ち、その目的は目的コードでは
なく原始コードの生成に際し開発者を補助するためのト
ウールを提供することである。

それ故、後に最適化コンパイラを使用してデバッグ済み
の原始テキストモジュール１２から品質目的コードを生
成することになろう。

第１図が経路１３．１７．１９により示すように、コン
パイル、リンク、もしくはランタイムの何れかにおいて
誤りが発見される。一つの誤りを発見するには、開発者
が原始コードをエディツトする必要がある。その後、サ
イクルのコンパイル−リンク−ラン部分が再度実行され
る。大部分のシステムでは、このサイクルを完了するた
めのターンアラウンドタイムは、アプリケーション自体
の問題よりも緩慢で恐らく扱いにくいトウールを取扱う
ために、開発者が時間を浪費して集中力をなくす結果を
もたらす。

第２図は本発明の一例による高速コンピュータ支援のソ
フトウェア工学もしくはＲＣＡＳＥ環境２１を表現する
筒路線図を示す。ＲＣＡＳＥは、エディタ、コンパイラ
等のソフトウェア開発環境にとって典型的な他の大型プ
ログラムに対する共用可能なリンクを介してその大量の
サービスを実行するプログラムである。例えば、ＲＣＡ
ＳＥは本発明のエディタ１０と増分コンパイラ１１との
間で交信し共働する手段を提供する。エディタ１０はプ
ログラムエディツトセツション中にモジュール１２内の
どの原始コードが修正されたかを知っており、コンパイ
ラ１１は、コードテーブル１４とその他のデータ構造を
介して、先のコンパイルからの計算するには高くつ＜　
（ｅｘｐｅｎｓｉｖｅ−ｔ。

ｃｏｍｐｕｔｅ　）値を想起する。エディタｌＯとコン
パイラ１１が旧値が依然妥当であるということで一致す
ると、その旧値は再使用され、従って計算しなおす必要
はない。ＲＣＡＳＥ環境２１は、後に述べるエディタ１
０と増分コンパイラ１１の他に、十分に確認された実施
例では、市場で入手可能なタイプのスタンドアロンデバ
ッガ２２の如きその他の各種サービス、恐らく各言語に
ついて各種々のバッチコンパイラ２３、ランタイムライ
ブラリ２４や、目的ファイルトランスフォーマ２５を要
求することができる。拡張実施例では、ＲＣＡＳＥ環境
は多重ブロック１１により示すようなＣ１フォートラン
、パスカル等の如き各種言語の原始コードを処理するこ
とができる。但し、本発明の特徴はＣ言語の如き一つの
言語専用のコンパイラで使用されるものと解すべきであ
る。

添付した付録には本発明の一例に対するＣ言語による原
始コードのリストが提示されている。この付録の原始コ
ードリストは次のモジュールを含んでいる。

ＲＣＡＳＥ原始コードモジュール（増分リンカを含む） 名称　　　　目的 ＲＣＡＳＥ　　ｓｙｍｂｏｌｓ　　　　ＲＣＡＳＢ、そ
のエディタ、コ（，５ｄｉ）　　　　ンパイラにより共
用される定数ならびに定義 ＲＣＡＳＥ用！、そのエディタ、コ ンパイラにより共用される ＲＣＡＳＥ用　　ｓｙｍｂｏｌｓ （，５ｄｉ） ＲＣＡＳＨ，ｈ ＲＣＡＳＥ用　　　１ｉｎｋ ｔａｂｌｅ、ｈ ＲＣＡＳＨＶｌ！Ｒ３ｌ０Ｎ、Ｈ ＲＣＡＳＥ　　ａｌｌｏｃａｔｅ、ｈ ＲＣＡＳＥ、　　Ｃ ＲＣＡＳＥ　　ａｃｔｉｖａｔｅ、ｃ ＣＡＳＥ ＲＣＡＳＢ ＲＣＡＳＢ ＲＣＡＳＢ ａｌｌｏｃａｔｅ、ｃ ｂｕｉｌｄ、ｃ ｃｈｅｃｋｐｏｉｎｔ ｒｅｓｔａｒｔ、ｃ Ｃａｌｌｂａｃｋｓ、Ｃ ＲＣＡＳＥ　　ｃｏｍｐｉｌｅ、ｃ 定数ならびに定義 ＲＣＡＳＥ用のファイルを含む。

ＲＬＩＮＫテーブルマネージャ 用ファイルを含む。

ＲＣＡＳＨ用データを変形する ＲＣＡＳＢ ＲＣＡＳＩＩ！アロケータ用ファイ ルを含む。

ＲＣＡＳＥ用メインＣ エディタ、コンパイラ、目 的プロセッサ駆動用インタ ーフェース ＲＣＡＳＥスロットアロケータ ＲＣＡＳＥビルダ チェックポイント＆再始動 用のＲＣＡＳＥ論理 ＲＣＡＳＥ用のエディタ／コン バイラ等の呼戻し コンパイルフェーズを実行 するＲＣＡＳＥ論理 ＲＣＡＳＥ　　ｃｏｍｐｉｌｅｒ ｓｅｒｖｉｃｅ、ｃ ＲＣＡＳＥ　　ｄｅｍｏｎｓ、ｃ ＲＣＡＳＥ　　　１ｉｎｋ、ｃ ＲＣＡＳＥ　　　１ｉｎｋ ｔ＋＊ａｇｅｓ、ｃ ＲＣＡＳＦ、　　　ｌｉｎｋ ｓｙｍｂｏｌｓ、ｃ ＲＣＡＳＥ　　　１ｉｎｋ ｔａｂｌｅｓ、ｃ ＲＣＡＳＥ　　ｓｅｓｓｉｏｎ ｍａｎａｇｅｒ、ｃ ＲＣＡＳＥ　　ｕｔＨ，ｃ ＲＣＡＳＥ　ｃｐｆ ＥＤＩＴＯ 名称 ＸＥＤ　ＶＥＲＳＩＯＮ、Ｈ 呼出し可能コンパイラの ＲＣＡＳＥサービス ＲＣＡＳＥスロットアロケータ 機密性チエッカ ＲＣＡＳＥリンカ ＲＬ／ＩＮＫ共用可能イ共用可能 イメージ水−ジャ ＲＬＩＮＫシンボル（ストリン グテーブル）マネージャ ＲＬＩＮＫテーブルマネージャ セツション管理用ＲＣＡＳＥ論理 Ｒ（１：ＡＳＥ用ユーティリティー ｍ＋ｎ５ｓｅｘｅ用オプションファイ ル、即ち、ＲＣＡＳＥ、ｅｘｅ。

ＤＣＡＳＥ、ｅｘｅ。

Ｒ原始コードモジュール 目　　的 スタブエディタ用ＲＣＡＳＥ ｅｄ ＸＥＤ。

ＸＥＤ ＡＣＴＩＶＡＴＥ、Ｃ ＸＥＤ ＡＬＬＯＣ，Ｃ ＸＥＤ ＣＭＥ、Ｃ ＸＥＤ　　５ＥＲＶＩＣＥＳ、Ｃ ＭＭＳ＄：ＸＥＤＳＨＲ，ＯＰＴ ＭＭＳ＄ｊＸＢＤ、ＯＰＴ 変形データ ＸＨＤエディタ内のインター 一フェース スタブエディタ用スタンド ドアロン駆動モジュール スタブエディタ用ＲＣＡＳＥ 駆動論理 スタブエディタ用メモリア ロケータ ＸＥＤコマンドインタープリ タ ＲＣＡＳＥ用ｘＥＤサービス 呼応可能ＸＥＤエディタ用リ ンすオプションファイル （ＲＣＡＳＥにより使用される） スタンドアロンＸＥＤエディ タを構築するためのリンカ オブシッンファイル ＸＣ ｘｃ、　　ｈ コードモジュール（コンパイラＸＣ） Ｘ　Ｃａｒｉｔｈｏｐｓ、ｈ Ｘ　Ｃｃｆｇ、ｈ Ｘ　Ｃｃｈｔｙｐｅ、ｈ Ｘ　Ｃｅｍｉｔ、ｈ ＸＣ １ｎｃｔａｂｌｅｓ、ｈ Ｘ　Ｃｐａｒｓｅ、ｈ ＸＣ ｔｏｋｅｎｓ、ｈ Ｘ　Ｃｖａｘｏｐｓ、ｈ ＸＣ ｖｅｒｓｉｏｎ、ｈ 主要モジュール間のィック 一フェース ｐｆｎ式のコード Ｘのｃｆｇテキスト用ルール 名 キャラクタの定義等級 エミッタモジュール間の内 部インターフェース ＸＣＣ増分テーブルマネー 中用ファイルを含む。

パーサモジュール間の内部 インターフェース トークンコードの共有リス ト 幾つかのｖａｘＨオプション コードに対する二−モニッ ク名を付与する。

プロトコンパイラ用のＲＣＡＳＥ ＸＣ６ ＸＣｅａ＋ｉｔ　　ｄｕｍｐ、ｃ Ｘ　Ｃａｃｔｉｖａｔｅ、ｃ ＸＣ ｃｏｎｔｅｘｔ、ｃ ＸＣ ５ｃａｎ、ｃ Ｘ　Ｃ５ｃａｎｌｉｎｅ、ｃ Ｘ　Ｃｐｒｏｇｒａａ＋、ｃ Ｘ　Ｃｓｔｎ＋ｔ、ｃ Ｘ　Ｃｄｅｃｌ、ｃ Ｘ　Ｃｅｘｐｒ、ｃ 変形データ ＸＣは呼出し可能ＸＣコン バイラに対するスタンドア ロンインターフェースであ る。呼出し可能コンパイラ ＸＣ５Ｉ（Ｒ，ＯＢＪ等を使用する。

エミッタをデバッグする。

ＸＣコンパイラ用ＲＣＡＳＥ駆 動ファイル ＸＣのコンテキスト切替論 理 ＲＣＡＳＩＩ！に対するスキャナイ ンターフェース 行スキャン ＸＣプログラムの回帰パー サ／ジェネレータ Ｘ文月パーサ Ｘ用語法のパーサ Ｘ式に対する回帰バーク／ ジェネレータ ＸＣ５ｙ慣ｂｏ１．ｃ ＸＣ，ｇｅｎ、ｃ Ｘ　Ｃ、ｅｍｉｔｖａｘ、ｃ Ｘ　Ｃｅｘｐｒｖａｘ、ｃ ＸＣ １１ｎｋｖａｘ、ｃ ＸＣ １ｎｃｒｖａｘ、ｃ ＸＣ １ｎｃｔａｌｄｅｓ、ｃ Ｘ　Ｃｊｏｕｒｎａｌ、ｃ ＸＣ ｒｔｌ、ｃ ＸＣコンパイラのスケルト ン記号テーブル Ｘの生成実行 ｖａｘ　（整数、プール、分岐） 用に対するスケルトンエミ ツタ ｖａｘ　（最小限最適化バージョ ン）用式コードジェネレー タ リンクテーブルビルダ ＸＣエミッタ用増分コンパ イルロジック トークン、セマンティック ならびにレキシカル増分に 対するＸＣ増分テーブルマ ネージャ エミッタとシンボルテープ 走行動に対するＣＸジャー ナルマネージャ ＸＣのランタイムライブラ ＸＣ，ｏｐｔ　　　　　　スタンドアロンＸＣの記述Ｘ
　Ｃ５ｈｒ、ｏｐｔ　　　　　共用可能ＸＣコンパイラ
構成を記述する。

Ｘ　Ｃｒｔｌ、ｏｐｔ　　　　　Ｘ　Ｃランタイムライ
ブラリ用コマンドをリンクする。

本発明の重要な特徴の一つは、第１図のエディツト−コ
ンパイル−リンク−ランサイクルの所与のフェーズもし
くはサブフェーズについて（このフェーズを実行するた
めのコードと共に）現在処理に対して必要なテキストの
データが（仮想メモリシステムによりディスクにページ
ングされるとは対照的に）実在メモリ内に残存し即座に
アクセス可能とするために設計されたメモリ管理スキー
ムである。ページフォルトとハードディスクに対するア
クセスが減る結果、エディツト−コンパイル−リンク−
ランサイクルのターンアラウンドはずっと高速になる。

このことは一部は、それ自身の隣接メモリ空間内に各原
始モジュールを維持することによって行われる。プログ
ラマが−プログダラムをエディツトしている間、多重原
始ファイル１２が開いているが、何れの瞬間にもただ一
つだけが現実にエディツトされているということになり
そうである。これらの原始テキストファイル１２はバッ
ファもしくはモジュールと称されるメモリ内構造内に位
置する。

第３図について述べると、本発明の開発システムを実行
するために使用されるコンピュータシステムが描かれて
いる。同システムは、システムバス３３によってメイン
メモリ３１とディスク記憶ファシリティ３２に接続され
るＣＰＵ３０を備える。−例では、システムはＶＡＸ■
コンピュータアーキテクチャ−とＶＡＸ＠／ＶＭＳオペ
レーティングシステムを使用する。その双方ともデジタ
ルイクウップメント社から市販されている。然しなから
、ページング機能と仮想メモリ管理を有するＵＮＩＸの
如きその他のオペレーティングシステムを使用する他の
コンピュータシステムも同様に有効であり、以下に述べ
るように、もしオペレーティングシステムがページング
機能を備えていなければ、同じ効果を環境に追加するこ
とができる。メインメモリ３１は選択されるシステムの
大きさに応じて恐らく数メガバイトのＲＡＭより構成さ
れることが普通であり、ダイナミックＲＡＭが使用され
るのが通常であるから揮発性である。

他方、ディスクメモリ３２は恐らく数百メガバイトの大
きさを有し、不揮発性である。メインメモリ３１のアク
セスタイムは１００ナノ秒オーダであるが、ディスクメ
モリは数１０ミリ秒で測られるアクセスタイムを有する
。１メガバイトメモリについてのコストはメインメモリ
３１の場合よりもディスクメモリ３２の方がずっと小さ
いことは言うまでもない、ＣＰＵ３０は、メモリ３１か
ら命令を取出し解読する命令装置３４を含み、命令によ
り命ぜられる処理を実行しオペランドのアドレスを生成
するための実行装置を備えている。更に、メモリ制御装
置３６が含まれ、この装置は、ページテーブルを参照し
くまた変換バッファを含んでいるのが普通である）、命
令装置３４又は実行装置３５内に生成した仮想メモリア
ドレスを実在メモリ３１内のアドレスに変換する。第３
ａ図に示すように、典型的なＶＡＸ／ＶＭＳもしくはＵ
ＮＩＸオペレーティングシステムの場合に実行される仮
想メモリシステムのメモリマツプは、３２ビツトアドレ
スを有するＣＰＵアーキテクチャについて２４ギガバイ
トのアドレス指定可能なロケーションを有する仮想メモ
リ空間３７を備えているが、（実際、仮想メモリ空間は
普通の場合、ディスクメモリ３２の大きさを超える）実
在のメモリ２１は例えば２メガバイトとすることができ
る。仮想メモリ空間はページ３８に分割され、各ページ
は例えば５１２バイトの大きさとする。かくして、この
例では、仮想メモリ３７中に８百万個のページロケーシ
ョンが存在するが、実在メモリ３１は何れの時期にもほ
ぼ４０００ページしか含むことができず、この相当部分
はオペレーティングシステムによって占められることに
なろう。

典型的な仮想メモリ管理装置３６では、ページテーブル
と変換バッファは、各ページについて一つのエントリを
含み、各エントリは実在メモリ３１内に現在常駐する高
次アドレスビ・ノドのページを含んでいる。実行装置３
５又は命令装置３４内に生成するアドレスによってメモ
リの参照が行われ、メモリ管理装置３６が変換バッファ
内にそれに相当するものを発見できないか、そのページ
が実在メモリ内に存在しないことをページテーブルが表
示する場合には、ページフォルトが表示される。

ページフォルトの実行はマイクロコードもしくはページ
スワップを実行するオペレーティングシステム内のルー
チンに対する飛越しより構成される。

即ち、実在メモリ３１内のページの一つをディスク３２
に書込み、問題のアドレスを含むディスク３２から実在
メモリ３１内へページを読取り、その後、流れはページ
フォルトを発生した命令へと復帰する。ページスワップ
処理は必要とされるディスクアクセスによる相当な遅れ
を導入するから、特にメモリに対して大きな要求を許す
本発明の環境の如きシステムが使用される場合には最小
限にする必要がある。

この目的のために、第３ｂ図について述べると、各原始
モジュール１２について、仮想メモリ３７の１ブロツク
３９が割当てられて、そのモジュールを仮想メモリの隣
接ページ３８内に保持するようになっており、その他の
任意のモジュール（例えば、他のモジュール１２、又は
テーブル１４の如きその他のデータ）からのテキスト又
は情報は、何れもこのモジュール１２に対して割当てら
れたメモリ空間内のページ３８に侵入することは許され
ない。以下に述べるその他のモジュール１２、コードテ
ーブル１４、およびその他のテーブル、バッファ等の何
れに対してもこの同じ制約が課せられる。このスキーム
は−モジュールを処理する間に多数ページフォルトとデ
ィスクアクセスを防止する。このメモリ管理スキームは
原始テキストモジュール１２に対してでなく、コンパイ
ルとリンク活動フェーズ中；即ち、コンパイラ１１もし
くはリンカ１５が実行中に生成する種々のテーブルとデ
ータ構造に対しても使用される０本発明ではメモリの割
当ては標準的なＣプログラミング言語からＲＥＡＬＬＯ
Ｃ機能を使用することによって行われる。即ち、原始テ
キストモジュール１２のエディツト中に、その大きさは
先にそれに対して割当てられた空間を土建ることがある
ため、分離ページがスタートすることになろう。然しな
から、このことが起こる前に、ＲＥＡＬＬＯＣ機能が実
行され、隣接するメモリブロックを割当て第３ｂ図のデ
ータ構造を再確立する。

かくして、特定データ構造又はモジュールに対するメモ
リの要求が最初に割当てられたメモリブロック３９の限
界を超えて大きくなるにつれ新たな隣接メモリのブロッ
クが割当てられなければならない、もし可能であれば、
最初のブロック３９が単に拡張されることになろうが、
この結果、継起するブロックとオーパラ、プすることに
よって新たなブロックを異なるロケーション内に割当て
ることが必要になるのが普通である。もし新たなロケー
ションが使用される場合には、データはＲＥＡＬＬＯＣ
機能により自動的に実行されるアクションである新たな
ロケーションへ移動させなければならない。これは、さ
もなければ“ゾーン化メモリ”の如きオペレーティング
システムとは独立の機構によって具体化される効果を達
成する移植性手段である。ＲＣＡＳＥの何れの特定な実
施においても移植性の少ないがより効率的なシステム固
有のゾーン化メモリ管理ファシリティを移植性バージョ
ンと取替えることができる。また、この方法がポインタ
に対して有する含意に注意されたい。もしポインタを含
むテーブルが配当しなおされると、そのポインタは誤っ
ているであろう。

それ故、本システムの高速度の結果を得るためには、ポ
インタは再配分プロセス中に移動するような何れのテー
ブル内にも使用することはできない。

自動ページングを有しないオペレーティングシステムと
共に本文中で述べる環境を使用するために、本発明の利
点は、ファイル読取りと書込みを適当な箇所に追加する
ことによって各フェーズ中に適当なデータ構造が実在メ
モリ内にあるようにすることで得ることができる。

ソフトウェア開発プロセス中には、多くの原始モジュー
ル１２と幾つかの可能なアクティビティ（例えば、エデ
ィタ１０１コンパイラ１１、リンカ１５）が存在する。

そのため、メモリ要求全体は第４図に示すような２次元
マトリックス４゜（即ち、メモリマツプ）によって表わ
される。同マツプでは行４１．４２．４３．４４．４５
はフェーズを示し、各列４６は（例えば以下に述べるよ
うなりリーンラインテーブル、トークンテーブル等の如
き）他の環境部分のうちの一つによって生成されるテー
ブルもしくはリストの如き原始テキストモジュール１２
やデータ構造に相当する仮想メモリブロック３９を表わ
す。各タイプのデータ構造に対しては処理中のアプリケ
ーション内の原始テキストのモジュール１２の数に相当
する数の列が存在することに注意されたい。エディツト
フェーズ４１　（エディタ１０が実行中の場合）では、
実メモリは、−モジュール１２の原始テキストについて
しか必要でない。即ち、他のデータは全てページアウト
できる。実メモリ内に存在するブロック３９は対角線状
の陰影によって表現される。コンパイルフェーズ４３　
（コンパイラ１１の実行時）では実メモリは原始テキス
トモジュール１２の変更部分と、任意の所与の瞬間にコ
ンパイル中の一モジュール１２と関連したコンパイラ内
部のセーブ情報についてしか必要とされない。即ち、そ
の他のデータは全てページアウトできる。

リンクフェーズ４４　（リンカ１５の実行時）では、メ
モリはリンクテーブルとコンパイルコードについてしか
必要でない。ランフェーズ４５では、コード増分テーブ
ルとリンクテーブルしか使用されない。従って、各フェ
ーズでは、各モジュール１２と関連する情報の小さな部
分のみが使用されるため、実メモリ内になければならな
い。モジュールの所与の一つについての残りの情報はペ
ージアウトすることができる。それ故、全体のメモリ要
求にかかわりなく、第４図の所与のフェーズ／モジュー
ルの関係によって規定される瞬間的なメモリ条件は、実
メモリ内に絶対必要なものだけを備えることによって満
たされる。このため、仮想メモリに対するアクセス（デ
ィスクに対するページスワツピング）の回数は減るため
、現在フェーズの実行速度は大きくなる。新たなフェー
ズがスタートすると、仮想メモリのアクティビティは、
それが要求される時の新たなフェーズに対する情報に最
早必要とされない情報をページアウトすることが必要で
ある。このことは正規のやり方で行われるため、比較的
効率的である。

経験によれば、必要とされる仮想メモリのバイト数で表
わされる本発明環境の使用上のメモリの条件は、原始モ
ジュール１２内のテキストのバイト数のほぼ５倍である
。コードの各行は、平均してほぼ４０バイトを含んでい
るから、ｉｏｏ、ｏｏ。

行の原始コード（４０Ｘ１００．０００又は４メガバイ
ト）を含むアプリケーションは、全メモリ条件として５
×４メガバイト、即ち２０メガバイトを要することにな
ろう。コンピュータシステムによってはこの程度の実メ
モリを使用できるものもあるが、にもかかわらず高価で
あり、低レベルシステムでの使用を除外することになる
。更に、例えば１．０００．　ＯＯ０行の原始コードを
含むアプリケーションを開発する際のメモリ要求は、２
００メガバイトという莫大なものとなる。所与のフェー
ズ中におけるページスワツピングを最小限にした仮想メ
モリシステムを使用する利点が明らかとなる。

それぞれの開いた原始ファイルに関してエディタ１０に
よりメモリ内に維持される情報は、第５図に示すような
原始テキストイメージモジュール１２ａと原始テキスト
ディスクリプタテーブル１２ｂを含む。ディスクリプタ
テーブル１２ｂはレコード識別子４７、レコード長さ、
および特定行の原始テキストが修正されたかどうかを示
すために使用される変更ビットと呼ばれる各行もしくは
レコードと関連する特殊ビット４８を含めて、原始テキ
ストモジュール１２ａ内のテキストの行に関する情報を
含んでいる。このビットは、その関連する行がエディツ
トされる場合には、エディタ１０によって論理１にセッ
トされる。ＲＣＡＳｆ！は検査後に変更ビットをＯにセ
ットしなおすことができる。ソーステキストモジュール
１２ａとソーステキストディスクリプタテーブル１２ｂ
は別個の分離メモリ空間（仮想メモリ３７内の異なるブ
ロック３９）内に存在する。このため、レコードディス
クリブタ情報は原始テキストモジュールＬＺａ自体を実
メモリ内に持込まずに検査（実メモリ３１内ヘページン
グ）することができる。このことはディスクリプタテー
ブル１２ｂが原始モジュール１２ａ自体よりもずっと小
さいことが普通であるから有益である。

コンパイルモードでは、コンパイラ１１は１モジユール
１２のコンパイル中に集められた情報をセーフスル、ソ
ノ際、この情報もまたその他のモジュール１２もしくは
その他の任意の付属コンパイラについてこのコンパイラ
によってセーブされた他の情報から、またエディタ１ｏ
によりセーブされた何れの情報からも隔離される（第３
ｂ図中のブロック３９内）ように配分される。

上記特徴は、バッチコンパイラと対照的に呼出し可能な
コンパイラを使用することによるものであることに注意
されたい。即ち、通常の場合、バッチコンパイラは単に
原始コードをコンパイルするのみであり、そのコンパイ
ル結果を２次メモリ３２（例えばハードディスク）内に
残す。呼出し可能なコンパイラの場合には、コンパイラ
はダイナミックにＲＣＡＳＥ内にリンクされ、コンパイ
ラ１１は、そのモジュールの続くコンパイル作業をスピ
ードアップする各アプリケーションモジュール１２につ
いてセーブされたコンテキストを含めて、コンパイル作
業間に情報を仮想メモリ３７内に維持することになる。

増分コンパイル用のメモリ管理システムはそのことによ
って第３ｂ図に見るような隣接空間をコンパイルに必要
とされる各々の別個のデータ構造について割当てること
によって、恐らく最初と最後のページを除いてページは
それぞれ上記規則により選択されるデータ以外のものは
含まないことになる。

従って、要するに、本発明のメモリ管理システムの機能
はエディツト、コンパイル又はリンク処理について必要
とされるコードとデータの全てが仮想メモリ内に常駐し
、データ構造がエディツト−コンパイル−リンク−ラン
サイクルの各フェーズにとって適当なデータ構造全体の
小さな部分を選択することを可能にするため、実メモリ
に対する瞬間的要求が最小限になるようにしなければな
らないという点にある。これはＣ言語標準関数ＲＥＡＬ
ＬＯＣを使用して必要に応じて別々のデータ構造をそれ
ぞれ拡張することによってそれぞれの別個のデータ構造
が仮想メモリ内の隣接するアドレス空間内にあり、従っ
て（各端は除き）他の何れのデータ構造からの情報も除
外されるようにすることによって移植構造で実行するこ
とができる。

バッチコンパイラでは、コンパイラはコンパイル毎に新
たに１モジユールの原始テキストの各行を読取り、その
結果をファイルシステム中に記録し、退去する。本発明
によれば、新たな機能性とデータ構造が設けられて、原
始テキストが変更されていない場合にコンパイラが再コ
ンパイル時に先に集められた情報（例えば、コンパイル
コード、リンクリスト等）を再使用できるようになって
ぃるため、原始テキストのエディツト後の再コンパイル
に要する時間を相当少なくできるようになっている。セ
ーブされた情報はコンパイラのモジュール間の内部イン
ターフェース全体のアクティビティのジャーナルとして
編成される。発明のこの面の基礎は、もし入力が変化し
ておらず他の一定の妥当性検査がパスされた場合、ジャ
ーナルの内容は、計算が反復される場合にインターフェ
ースを通過するであろうものと同一であり、従ってジャ
ーナルを使いきってその代わりにセーブデータを再び妥
当なものとしそもそもジャーナルの作成に至る高価な計
算を省略することができるとう点である。

１コンパイラ内の何れのインターフェースもジャーナリ
ング可能である。現在の実行はインターフェースをスキ
ャナ、エミッタおよび記号テーブルヘジャーナリングす
る。異なるコンピュータ言語と異なるコンパイラ編成法
はそれぞれ、エンジニアに対して、ターンアラウンドタ
イムを最も効果的に節約する上で何れのインターフェー
スをジャーナリングすべきかを判断するために必要な情
報を提供する。いったんそのインターフェースが選ばれ
、設計されると、幾つかの別個のジャーナルエントリを
より効率的な大型の結合エントリ内へ結合することによ
ってジャーナル自体を最適化できることが多い。かかる
結合の例は、１バイトのエミッタコールの系列を単一の
ｎバイトコール内へ集めること（この場合にはエミッタ
７２がそれを残したテーブル７３内に既に存在する先に
発せられたコードを再び妥当なものとすることによって
実行される。）と、記号テーブル内の一記号の多くの属
性に対する別々の多数のチェックを金属性の一回のチェ
ックに一度に結合することである。

ジャーナルのロケーションは、それらを作成した環境部
分のスタティックな状態にあるとするか、ＲＣＡＳＥ自
体により提供される全体的なジャーナリング機構内にあ
るとするかでき、多様である。

その選択は工学上のトレードオフ関係にあり、増分コン
パイラが使用できる他の用途（例えばバッチ用途）や、
何れの実行チームが種々のアルゴリズムを実行する専門
知識を有しているか、また環境の構成部分の性能全体や
構造的機密性を考慮して行う。ＲＣＡＳＥでは両方の実
行形成が使用される。

ジャーナルが効果的にリプレイされる毎に、対応するア
プリケーション原始コードをスキップしてコンパイラを
位置決めしなおして次のジャーナルを再使用するか再構
築するようにする必要がある。一つのジャーナルを構築
するさいに消費される原始コードの量は常にアプリケー
ション原始行の整数であるから、ジャーナルと共に記録
されスキップする最も原始行の整数である。行数は増分
寸法と呼ばれる。

第６図について述べると、ＲＣＡＳＥがクリーンライン
テーブル５０と呼ばれる内部データ構造と共にこのアク
ティビティを管理する。それぞれのアプリケーション原
始モジュール１２について一つのクリーンラインテーブ
ル５０が存在する。

ＲＣＡＳＥはコンテキストが変更される場合にテーブル
５０間を切替える。一つのクリーンラインテーブル５０
は関連するアプリケーションモジュールエ２内の原始行
毎に一つのエントリー５１を有する。クリーンラインテ
ーブルの各エントリー−５１は以下の情報を有する。即
ち、（１１アプリケ一シヨン原始行ディスクリブタとテ
キストを配置するフィールド５２、（２）現在点からア
プリケーション原始バッファ工２の端へ向かうどれ程の
原始行がそれらの情報（クリーン）を最後に使用してか
ら変更されないかについてのフィールド５３、および（
３）事実上はこの行と関連する全てのセーブ情報を配置
するコンパイラの手段であるが、コンパイラ１１により
提供される情報についてのフィールド５４、である、ク
リーンラインテーブル５０は種々の形で構築することが
できる。本例は、原始バッファ１２（もしくはそのディ
スクリプタテーブル１２ｂ）内の情報レコードをパスし
て、クリーンビット４Ｂを検査しクリーンラインエント
リー５１を構築すると同時に妥当でないエントリーを削
除し新たに必要となるエントリーを挿入する。

アプリケーション原始コードの一行が変更されているか
どうかをＲＣＡＳＥに通知してクリーンラインテーブル
５０をエディタ１０からの呼戻しを介して更新状態に維
持することも可能である。

この第２の方法はターンアラウンドが高速になるがエデ
ィタ１０に対する要求が大きくなり実行するのに複雑で
ある。

第６図について述べると、ＲＣＡＳＥ環境では、コンパ
イラ１１は走査機能を保持し最初のコンパイルでコンパ
イラ１１は従来の方法で原始テキスト１２を読取る。但
し、原始テキスト１２は、ファイルからでなくエディタ
メモリイメージ１２からＲＣＡＳＥ２１を経て到来する
。然しなから、更に、コンパイラ１１は、原始テキスト
中の情報の字句単位毎に対応する収集され計算された情
報を含むトークンテーブルも構成する。その際、かかる
情報の字句単位はそれぞれ対応するトークンにより識別
され索引づけされる。（第８図参照）走査ジャーナルは
できるだけ少数の行について構成される。普通の場合、
それは−行である。但し、一つの字句増分内に１行以上
を記録しなければならないプログラミング言語の特徴が
ある。（例えば第９図を参照されたい）コンパイラ１１
は、原始テキストの各行についてＲＣＡＳＥ２１へ移行
し、トークンとＲＣＡＳＥの対応する系列はトークンの
形で各行をセーブする。（第９ａ図参照）この処理を若
干異なった形で説明すると、（１）　　原始テキスト（
バッファ１２からの）はポインタとしてパスされてエデ
ィタ１０からＲＣＡＳＥ２１を経てコンパイラ１１へ１
時に１行ずつ到来する。

（２）コンパイラ１１は原始テキストを走査し、トーク
ンを表形式にし、トークンのロケーションをＲＣＡＳＥ
２１へ戻す。

＋３）　　ＲＣＡ　Ｓ　Ｅは一つのトークンが必要なと
きトークンロケーションをコンパイラ１１へ手ｉｔ。

これは、ＲＣＡＳＥ２１自体をジャーナリングエージェ
ントとして使用する場合の例である。その代わり、ジャ
ーナルをスキャナ内に維持し、トークンジャーナルが再
使用できるようにアプリケーション原始テキストが変更
されているかどうかを見るためにスキャナにチェックさ
せる方法がある。

ＲＣＡＳＥにより管理されるジャーナルの第２の集合は
発せられたコードを記録する。より現代的なコンピュー
タ言語の場合、言語の構造的ネスティングをセーブされ
たコード断片のネスティングされた集合の内部に反映さ
せることができる。

飛越し文はこの構造を侵犯するから特殊な情報レコード
で処理しなければならない。フォートランの如き旧言語
の場合、飛越しが余りに多いため入れ子断片は不可能で
あり、従って飛越しは特別のレコードを要しない。入れ
子断片の利点は大きな数の非入れ子断片を再使用するよ
りも含まれる断片とその内部断片を全て一つのジャーナ
ルアイテムとして再使用する方が効率的である点である
。

Ｃプログラミング言語における断片のタイプは、六叉（
非入れ予成）条件文（ｉｆと５ｗ１ｔｃｈ　）、ループ
（ｆｏｒ、　ｗｈｉｋおよびｕｎｔｉｌ　）ブロック、
機能定義である。

コンパイラ１１がセーブ可能な構造の始めを発見する毎
に、ＲＣＡＳＥクリーンラインテーブル５０内に妥当な
セーブフィールドが存在することを含めて種々のチェッ
クによって再使用可能な断片が存在するかどうかを見る
。（第６図）もしそれが再使用可能であれば、ジャーナ
ルは使い尽され、ＲＣＡＳＥは適当な数のアプリケーシ
ョン原始行を越えてスキップするように命ぜられる。さ
もなければ、新たなジャーナルが構築され、そのロケー
ションはクリーンラインテーブル５０内に記録される。

１断片（セマンティック増分と称する）を再構築中、コ
ンパイラ１１はジャーナリングされたスキャナ情報を使
用することになろう。

実際のテキストが修正され終ると、スキャナ情報もそれ
が使い尽くされる前に再構築される必要があろう。

これらの処理を要約すると、 （１）　　セマンティック増分を構成することが可能な
プログラミング構造の開始に出会う。これは構造の先頭
トークンを検査するか先にそれらを検査し結果を記録し
たことによって発見される。

（２）　　ジャーナルをリプレイする可能性がチェック
される。即ち、原始テキストは変更されていてはならな
い。ＲＣＡＳＥ内のこの構造について妥当なセーブフィ
ールドがなければならず、断片は更にコンパイラテーブ
ル内の情報と一致していなければならない。

（３）　　もし全てのチェックがパスすれば、ジャーナ
ルは使い尽くされ、アプリケーション原始テキストはス
キップされる。もし失敗するチェックが存在すれば、ジ
ャーナルは廃棄され、トークンが再コンパイルされ新た
なジャーナルが構築され、その新たなジャーナルは使い
尽くされる。

新たなジャーナルのロケーションは将来の参照のために
ＲＣＡＳＥへ戻される。

（４）幾つかの状況ではく通常、劣悪なアプリケーショ
ン原始テキストフォーマットの作成）、アプリケーショ
ンテキストレコード境界と整合するジャーナルは構築で
きない。この場合、ジャーナルは後に再使用される可能
性を失うことを犠牲にして記録されない。

上記のステップ１．２．３．４は少なくとも２つの形を
もっている。即ち、ラン効果と記号効果とである。前者
は、多分、幾つかの係属中のフィックスアンプを有する
ハードコンパイルコードにより表現され、後者は一連の
記号テーブルアクションによって表わされる。大抵の文
は画形式の要素を若干備えている。最小セーブ単位は行
である。

但し、多数の隣接する行を一つの論理行に束ねて状態を
セーブすることができる。

ＲＣＡＳＥレコードにより管理されるジャーナルの第３
の集合は記号名と属性を記録する。インターフェースは
（第７図と第７ａ図に見える）記号テーブル５６に対す
るものである。ジャーナリングされたアクションは、有
効範囲エントリーとエグジット、記号探索と、入力、お
よび任意の属性対する獲得と設定である。普通の場合、
記号入力と属性の設定は、アプリケーション言語中の宣
言構造に応じて行われる。普通の場合、記号探索と属性
の獲得は、アプリケーション言語の実行可能構造に応じ
て行われる。変則的には、アプリケーション言語構造の
何れとも関連するアクションを惹起こすことの可能な状
況が存在する。

完全に増分的であるための会話インタープリタ１１の記
号テーブル５６は、バッチコンパイラに必要な構造を超
える２つのユニークな属性を有することになろう。即ち
、１）有効範囲エグジットにおける記号テーブルから情
報が削除できないこと。２）全ての情報部分も妥当性ビ
ットを伴なわなければならないこと。代わりに、妥当性
ビットを有する全ての情報部分の代わりに、単一の妥当
性ビットをテーブルエントリー全体に使用することがで
きる。アプリケーション原始モジュール１２の新たなコ
ンパイルが開始されると、先のコンパイルからの完全に
作成された記号テーブル５６が存在する。その際、全て
の妥当性ビットはフエールスにセットされる。テーブル
５６内の情報を入力するアクションはそれぞれ、３つの
カテゴリーの一つにはいる。即ち、１）情報が発見され
、妥当しないとマーキングされる０反応はそれを妥当な
ものにすることである。２）情報が発見され、妥当であ
るとマーキングされる。反応はエラー診断を発しコンパ
イルを終了することである。

３）情報が発見されない。反応はそれが現在妥当である
とマーキングされた全情報と一致する限り、それを入力
することである。

記号テーブル５６から情報を取るアクションはそれぞれ
、期待される回答が発見された回答であることを見るた
めのチェックとしてジャーナリングされる。これらジャ
ーナルの目的は、その下に実行可能なジャーナルが構築
された仮定（本説明の先のセクション）が依然妥当であ
ることをチェックすることである。

次の三つの状況がある。１）情報が発見され、妥当であ
るとマーキングされる。反応は実行可能ジャーナルの再
使用を可能にすることである。２）情報が発見され妥当
しないとマーキングされる。

反応は実行可能なジャーナルを非妥当なものにし、それ
を再構築することである。３）情報は発見されない。反
応は同様に実行可能なジャーナルを妥当しなくすること
である。

実行可能なジャーナルを再構築するプロセスで、同じ３
つの状況が生じ得る。即ち、１）再構築が継続する。ケ
ース２）と３）では、再構築が停止し、エラー診断が出
され、状況を訂正すべく制御は開発者へ戻される。

有効範囲を閉じた後、ジャーナルから使尽くされるか、
ブロックの再構築中に、閉じたブロックに固有の記号テ
ーブル５６内の局部情報の全てはテーブル内に残される
が、妥当しないとマーキングされて、ルックアップ経路
から除去される。その結果、アプリケーション原始モジ
ュール１２のコンパイルの終了までにその記号テーブル
５６全体はルックアップ経路から除去され全情報は妥当
せずマーキングされる。それは正確な開始状況であり後
に再使用される。

若干の言語に対しては他のジャーナルが必要である。マ
クロ拡張に対する増分前処理はその一例である。

大抵はジャーナル中にセーブされた情報は単一のアプリ
ケーション原始モジエール１２と関連するコンテキスト
に付属される。それぞれのモジュール１２はそれ自身の
ジャーナル集合を有する。

コンピュータ１１は、その情報のどの使用にも先立って
適当な情報に対するそのコンテキストをセットするよう
に命ぜられる。コンパイル中、情報はチェックされ、通
常、一定程度変更される。リンク中、情報がアク需スさ
れ、アプリケーションモジュール境界をクロスするアド
レスを発見しセットする。コンパイラに対するＲＣＡＳ
ＥコマンドはＳｅｔ　Ｃｏｎｔｅｘｔである。それはＲ
ＣＡ　Ｓ　Ｅ、の制御中には何時でも発することができ
る。

セーブされた情報は、開発者からのコマンドにより書込
まれるチェックポイントファイルの実体である。ＲＣＡ
ＳＨの再スタートエントリは全状態がＲＣＡＳＥとその
付属構成部分に復帰するように環境を入力するための特
殊な方法であり、状況を復帰させることによって開発者
は先のチェックポイント処理に先行して作業が中断され
たところで継続することができる。チェックポイント２
は有効な情報が全てセーブされる必要はなく作り直すこ
との不可能な、あるいは環境再スタート後に作り直すに
は高価すぎる情報のみをセーブする必要がある。このこ
とはアプリケーション言語の詳細、増分コンパイラの構
造、およびホストシステムとそのバックメモリの種々の
性能係数に依存するトレードオフを伴う。

個々の原始テキストファイルを実行可能なコードにコン
パイルする他に、コンパイラは実行可能コードファイル
もリンクする必要がある。ＲＣＡＳＥでは、このリンキ
ングは原始テキストの最初のモジュラ構造で発生する実
行可能コードファイルどうしの間のモジュール境界を保
持するように行われるという点でユニークである。

このリンキングはＲＣＡＳＥでは、ファイル関連アドレ
スではなくリンクされるべきコードの「絶対」アドレス
、即ち、実際メモリのアドレスを指示するポインタを使
用することによってメモリ内で行われる。ＲＣＡＳＦ、
は、各リンクの「終り」を識別するために、即ち、アド
レスがコンパイルされたデータ内に挿入されコンパイル
コード内で各アドレスが指示される地点を識別するため
に内部テーブルを使用する。

システムプログラミングでは、数モジュールのリンクタ
イムは１モジユールのコンパイルタイムとほぼ同一であ
るというのが共通の経験である。

バッチコンパイラの結果は、たといコンパイルもしくは
リンキングのみが瞬間的であっても他方はターンアラウ
ンドの利得を５０％のスピードアップに限定することに
なるであろうということである。ＲＣＡＳＨの帰路は、
リンキングは実現すべき何れの利得に対してもコンパイ
ル程大きくスピードアップしなければならない点である
。現存の増分リンカは入手可能な改良を限定する２つの
制約の下で動作する。即ち、１）リンキングの結果は、
後に活動させるためにファイル内に配置され、情報のフ
ォーマットを作成するための時間とファイル書込み時間
の両方がかがる。それ故、ファイルは増分的に変更可能
なように設計する必要がある。２）アプリケーション原
始モジュールが変更される時、コンパイラによって全く
新たな目的モジュールが作成されるため、その供給情報
の全ては、変更モジュールに戻されるアプリケーション
の残りからの情報と共にコンパイルアプリケーション全
体に分配されなければならない。

ＲＣＡＳＥ増分コンパイラは、供給アドレスもしくは外
部値を要する位置のアドレスの何れかを変更することを
回避する。このアクションは、事実上は、大部分、再コ
ンパイルをスピードアンプするために使用される微粒増
分ルーチンの副産物である。それ故、再コンパイルが行
われる時、訂正を要する場所の数は皆無もしくは恐らく
僅く少数とすることができる。従来の増分コンパイラの
最良のケース（モジュール全体の変更）はＲＣＡＳＨに
とっては最悪のケースである。増分コンパイラ１１は、
追加情報を増分リンカ１５に対して供給し、このセーブ
を活動させなければならない。

（第６ａ図参照）一つのアプリケーションモジュール１
２のローカルリンクテーブル５８内の各エントリ５７は
、伝統的なＮ　Ｅ　Ｅ　Ｄ／Ｄ　Ｅ　Ｆフィールドの他
に、新”旧”、又は“削除済”という情報の増分状態を
与えるフィールド５９を備える。増分リンカ１５は“新
”情報の両端を更新し、それ自身のテーブルから１削除
された゛エントリ５７を除去する。

クリーンラインテーブル５０を維持する場合と同じく、
増分リンカ１５のテーブル５８を正確に維持する代わり
の方法がある。増分リンカ１５は、それを介してコンパ
イラ１１による変更が通知されるエントリを供給するこ
とによってそれらがコンパイル中に一時に一つずつ処理
されるようにすることができる。

上記の如く、原始テキストの編集は、少なくともテキス
トの変更部分を再コンパイルすることを必要とするであ
ろう、然しなから、原始テキストの１モジユール１２の
変更は、それ自体、エディタにより変更されなかった原
始テキストの他のモジュール１２内に反映されると共に
、原始テキストのこれら従属モジュールは再コンパイル
、再リンクされる必要がある。従来技術では、このこと
は、全てのテキストが再コンパイルされなければならな
いと仮定するか、開発者により作成された従属ファイル
（しばしばメイクファイルと呼ばれる）を検査した後、
各ファイルにつきファイルシステムの最終書込みデータ
に打合せて各従属モジュールがそれが依存する何らかの
モジュールよりも後の最後の書込み時間を有するように
するかの何れかによって処理されるのが普通であった。

このテストに失敗するモジュールは、その後、まづ最も
従属性の少ないファイルの順で再コンパイルされる。従
来技術はＲＣＡＳＥの特徴によりり補正される３つの欠
点を有する。即ち、１）開発者により作成されるメイク
ファイルは、従属解析が信頼性のあるものであるために
は正確なものでなければならない。開発中に変更がなさ
れるため、メイクファイルが不正確になり、開発者がそ
れを補正できないのは普通である。２）開発者はメイク
ファイルを作成する際、最悪ケースを計画しなければな
らず、不要な再コンパイルが必要になることが多い、３
）開発者が依存性を表現できる最小単位は完全なアプリ
ケーションモジュールであり、その場合、事実上、変化
は、殆んど常にかかるモジュールの小さな部分に対して
行われる。

それと対照的に、増分依存性解析の特徴によれば、ＲＣ
ＡＳＥは第６ｂ図に見るような微粒依存グラフ６０を生
成しストアし、フィールド６１内でアプリケーションモ
ジュール１２内の記号どうしの間の依存関係と、フィー
ルド６２内で各所与のアプリケーション原始モジュール
１２に対する最後の変更時間を識別する。それ故、ＲＣ
ＡＳＥは、何時でも、グラフ６０から、変更した原始テ
キストの一定部分から、変化した原始テキスト全体と、
従属する原始テキストの部分を識別することができる。

アプリケーション原始モジュール１２からの依存情報の
自動生成によって開発者は、メイクファイル中の依存情
報を表現し維持する必要から解放され、更に、開発者に
より導入されるエラーの源を除去することによって信頼
性は向上する。この特徴は、今度は、依存性を完全に再
コンパイルしたり計算したすせずに変更したコード部分
からの直接の変更もしくは依存性のために再コンパイル
されなければならないテキスト部分のみの識別を可能に
することによって再コンパイルに要する時間を相当減少
させることができる。もし原始テキストのモジュール１
２の編成を相当修正するような大きさをその変更が有し
ない場合（それは比較的稀れな場合である）、依存グラ
フ６０を計算しなおすことは滅多に必要でない。

関連する情報の大きさと複雑さのために、例えば作業者
の終りやシステム故障の場合にプロジェクトに対する作
業の停止と再始動は通常すこぶる時間のかかるものであ
るということがソフトウェア開発における共通の問題点
である。更に、もし停止発生時に一定のプロセスが完了
しなければ、一定の情報と一定量の作業が失われるかも
しれない。

この不利益が通常のソフトウェア開発環境において生ず
るのは、例えばエディットセッシッンが終了する時にド
キュメントがセーブされるとほぼ同一の形で関連情報が
標準ファイル内にセーブされ復帰されるためである。も
しファイルが最近セーブされておらず、あるいは環境の
実行中に一時的に回復不能な状態にファイルを維持する
ことが環境の性質であるならば情報は失われる。

ＲＣＡＳＥでは、先に述べたように、原始テキストやコ
ンパイルコード、使用中のエディタ、コンパイラ等の如
き加工中の全てのデータを含むプロセス全体とプロセス
情報は、常に仮想メモリ内に常駐している。このことを
活用して、ＲＣＡＳＩＩ！は、メモリ内の各モジュール
から１フアイルへ関連する状態をセーブした後、１セツ
シヨンの終了直後ファイル名称をＲＣＡＳＥに報告する
「中断」コマンドを含む、ＲＣＡＳＥは一つのファイル
内にファイル名のリストをセーブする。の後、全体の状
態が単一ファイルから復帰された形で相当する「復帰」
コマンドによって処理が再開される。

この方法によれば停止と再始動に要する時間は相当節約
されることが判った。何故ならば、正規のファイル製品
の外にＲＣＡＳＥの中間状態がセーブできるからである
。復帰するのに高くつくのはこの中間状態である。更に
、ユーザは再始動直後に中断時とぴったり同一の状態を
見ることになる。

そのため再始動後の再適応に通常要する時間とエネルギ
ーは節約される。

第７図について述べると、増分コンパイラ１１ツタイア
グラムが描かれている。コンパイラのフロントエンド構
造は、（ＲＣＡＳＥを介してエディタから）原始テキス
トとクリーンライン増分を受取り、以下に述べるように
トークンテーブル６６とレキシカル増分テーブル６７を
生成するスキャナ６５を含む。パーサ７０はスキャナか
らトークンを受取り、フィルタリングされたトークンと
ルールをコードジェネレータへ通し、実行可能文の場合
はエミッタ７２を介してコード増分テーブル７３内に維
持される目的コードの増分を生成する一方、宣言文につ
いては記号テーブル５６が生成され記号テーブルマネー
ジャ７４を介して維持される。

以下は、−例によるＲＣＡＳＥによりサポートされる増
分コンパイラ１１の構造のアーキテクチャ−的説明であ
る。ＲＣＡＳＥをサポートする増分コンパイラは以下の
特性を有することになろう。

バッチコンパイラと増分コンパイラ間の共用モジュール
について、 （ａ）　　バッチと増分によるコンパイラバージョンの
両方により共用可能な再使用可能なフロントエンドモジ
ュール（スキャナ６５、パーサ７０、および恐らくジェ
ネレータ７１）を設ける。このためバッチ環境と増分環
境間に原始言語の成る程度の一貫性が必要になる。

（ｂ）　　その再使用可能なモジュールがスタンドアロ
ンであることが可能で、また現在そうであり、それのみ
でテストできるように構成される。

（Ｃ１コンパイラの増分バージョンに対する呼出可能な
インターフェースをサポートする。

フロントエンド内部は、 （ａ）　　字句増分を生成し再使用する能力をサポート
し、 （′ｂ）標準地点で走査を停止する能力であるスキンブ
走査をサポートし、あたかも介在する原始行を走査し終
えたかの如（それを再始動する。

（Ｃ）　　そのスキャナ６５とパーサ７０の間にトーク
ンインターフェースを使用する。

（ｄ）　　その言語に対する標準的な文脈自由文法を指
定する。

（１り　　標準地点（例えば、文開始）でパージングを
停止する能力であるスキップパージングをサポートシ、
あたかもそれが介在するトークンをパージングしたかの
如くそれを再始動する。

（ｉｉｉ）　　そのパーサ７０とジェネレータ７１間の
“トークンテルール”のインターフェースを使用する。

（ｇ）セマンティック増分を生成し再使用する能力をサ
ポートする。

（ｈ）　　増分記号テーブル５６をサポートする。

ジャーナリング： （ａ）　　ジャーナリング技法を使用して妥当性をチェ
ックし、多分（トークンテーブル６６、生成テーブル７
３のコード、記号テーブル５６等の如き）先に生成され
た情報を再使用する。

コンテキストの切替えとチェックポイントは以下のもの
をサポートするために設ける。

（ａ）　　ジャーナリングされた情報の状態セーブとコ
ンテキストの切替え。

（ｂ）　　ジャーナリングされた情報、をファイルへチ
ェックポイント化して再始動後に再使用する。

以下の目的のためにメモリ管理を行う。

ｆａ）　　原始バッファ１２あたりでジャーナリングさ
れた情報用のメモリを割当てることによってスラッシン
グを避ける。

本発明による増分コンパイラ１１が位置するコンテキス
トを描いた全体線図を第６図に示す。この線図では、エ
ディタ１０は多数の原始バッファ１２を管理し、原始テ
キストをＲＣＡＳＥ２１へ提供する。ＲＣＡＳＥはエデ
ィタ１０と会話してそれらがコンパイラ１１により処理
された最後の時以降に変更された所与バンファ内の原始
行を識別する。ＲＣＡＳＥはクリーンライン増分と称さ
れる原始バッファ１２の抽象化をコンパイラ１１へ提供
する。クリーンライン増分によってコンパイラ１１は、
それが同一原始バッファ１２の先のコンパイルセラシラ
ン中に生成したセーブ情報を再使用できるかどうかを判
断することができる。

もし否であれば、コンパイラ１１は、ＲＣＡＳＥ２１を
経て適当な原始行のテキストを得て、その後火のコンパ
イルセツション内で再使用可能な必要な情報を生成する
ことができる。

コンパイラ１１の出力は増分リンカ１５により必要とさ
れる全ての必要な情報を含むコード−データー記号バッ
ファ１４である。増分的にコンパイルされる各原始バッ
ファにつき、そのための対応するコード−データー記号
バッファ１４が存在する。コード−データー記号バッフ
ァ１４は、事実上、独立に割当てられ管理される仮想メ
モリ３７内のエリアの集合体として編成され、開発者が
チェックポイントを要求するような時間まで仮想メモリ
内にのみ保持される。

ＲＣＡＳＥは、任意の所与の瞬間に環境内に１つ以上の
コンパイラ１１が活動できるように多重言語をサポート
する。ＲＣＡＳＥが原始バッファ１２をコンパイルする
リクエストを受取る毎に、適当なコンパイラが活動した
かどうかを判断しなげればならない。このためには増分
コンパイラ１１がＲＣＡＳＥ呼出し可能インターフェー
スをサポートすることによって必要な時にＲＣＡＳＥが
それらを利用可能にする必要がある。

第７図はＲＣＡＳＥ増分コンパイラ１１のフロントエン
ドの一般的構造を含む。原始行とクリーンライン増分は
ＲＣＡＳＥから到来する。スキャナとブリプロセッサ６
５は共に、詳細な情報を求めてアクセス機能を介してト
ークンテーブル６６へ照会しなおす一系列のトークンを
生成する。パーサ７０は基準パースを構成するために文
法規則アプリケーションの系列を発見する。ジェネレー
タ７１は中間言語（ＩＬ）を生成し、それをバックエン
ド構造へ送る。字句増分テーブル６７は、スキャナ６５
内のセーブ状態についてジャーナリングされた情報を含
む。字句増分が再使用される場合、スキップ走査が生ず
る。

バッチと増分コンパイラ１１は、スキャナ／プリプロセ
ッサ６５とパーサ７０、そして恐らくジェネレータ７１
用のコードを共用することが望ましい。他の何れのモジ
ュールも最微粒増分コンパイラに対して共有できるとい
うことはありそうにない。

第７図は、同様に増分バンクエンドの構造を含む。増分
バックエンドは、フロントエンドから中間言語（ＩＬ）
を受取る。ＩＬは信号テーブルマネージャ７４かチェツ
キングエミッタ７２の何れかに運ばれる。記号テーブル
マネージャ７４は増分記号テーブル５６を構成し更新す
る。チェツキングエミッタ７２は、必要に際して記号テ
ーブル５６をアクセスし、コード増分テーブル７３とセ
マンティック増分テーブル７６内に管理される最適でな
いチェツキングコードを生成する。

チェツキングエミッタ７２は、目標コード品質と高速タ
ーンアラウンドをトレードオフする。発せられたコード
は、クロス文最適化の防止を犠牲にして増文更新を可能
にする利益を得て包囲増分用コードとは独立の増分形で
生成する。また、チェツキングエミッタ７２は、メモリ
アクセスを限定し、別名化と非初期化変数を発見するた
めにチェツキングコードを加算する。

第６図において、コンパイラの最終生成物はコード−デ
ーター記号バッファ１４として記述される。論理的にい
って、単一のコード−データー記号のバッファ１４が対
応する記号テーブル５６とコード増分テーブル７３の構
成である。　ＲＣＡＳＥ増分リンカ１５により使用され
るこの論理的な視野を実行する手続上のインターフェー
スが存在する。

第７図に示すように、スキャナ６５の主な仕事は、その
クリーンライン増分と原始テキストをパーサ７０用のト
ークンの系列に変換することである。スキャナ６５は、
この任務を実行することによって行が丁度作成もしくは
停止された場合に行を実際に走査するだけでよいように
することができる。この能力はレキシカル増分と呼ばれ
るデータ構造を用いて実行される。また、スキャナ６５
は、スキップ走査と呼ばれる入力された原始行の流れで
前方ヘスキップする能力をサポートする。

更に、スキャナ６５はトークンの表示の物理的なレイア
ウトをトークンインターフェース内と連結することによ
ってコンパイラ１１の残部から隠す。

これらのコンセプトの全てを以下に解説する。

クリーンライン増分はＲＣＡＳＥによりスキャナ６５に
提示される抽象である。それは、「現在行の後にどれ程
の非変更原始行が続（か？」という質問に答えることが
できる。これは、ＲＣＡＳＨの増分コンパイルがテキス
トの多数の隣接行のジャーナリング効果（レキシカルな
らびにセマンティフク増分）にもとづいているために有
益な情報である。答が「必要なテキストは修正済み」で
ある場合には、ＲＣＡＳＥはエディタ１０内の生のテキ
ストにアクセスする。

通常の場合、原始テキストの一行はそれ自体で走査する
ことができる。１行のコンパイラ有意内容はトークンの
系列である。フォートラン″Ｃ０ＮＴＩＮＵＥ”もしく
はＣ行末オーバライド１＼”の如き異例のケースでは幾
つかの行を一単位として走査する必要がある。一つもし
くはそれ以上の行の字句単位はレキシカル増分と呼ばれ
る。レキシカル増分の使用は逐次トークンを記録した後
それらをパーサ７０へ手渡すことである。レキシカル増
分は以下の能力を有する。

チェック　（）：　　このレキシカル増分と関連する連
続する原始行の現在の組が変更されたかどうかの如き種
々の妥当性チェックを実行する。（スキャナ機構外部で
チェックしなければならないトークン構造のコンテキス
ト依存性と関係をもつ他の一定の状況において）それは
クリーンライン増分情報を使用してそのチェックの幾ら
かを実行する。妥当性チェックが成功するとＴＲＵＥに
復帰する。

５ｃａｎ　Ｉｎｃｒｅ＋＋ｅｎｔ　（）　：　　新たに
レキシカル増分をつくりだす、それが与えられる最初の
行から始まってできる限り少数の完全行を消費して妥当
なレキシカル増分を構築する。その値は（検査される数
ではなく）実際に消費される行数である。

５ｃａｎ　Ｉｎｃｒｅｍｅｎｔ　（）　：をチエ７りす
ることによって、もしこのレキシカル増分の構築が（そ
の領域を侵犯するかギャップを残すことによって）次の
ものを妥当でな（したかどうかを発見することができる
。

Ｆｉｒｓｔ　Ｔｏｋｅｎ　（）：　　レキシカル増分の
現在コンテキストをそのトークンリスト内の最初のトー
クンのロケーションヘセットする。

Ｎｅｘｔ　Ｔｏｋｅｎ　（）　：　　レキシカル増分の
現在コンテキストをそのトークンリスト中の次のトーク
ンのロケーションに更新するアイタレーダである。

Ｔｏｋｅｎ　（）　　：　　その値として現在トークン
の「ハンドル」を復帰する。（トークンインターフェー
スが記述される時ハンドルは定義される）空ハンドル値
はリストの終りに達すると復帰する。

第７図に示す如く、テーブル６７内にはレキシカル増分
が編成される。コンパイルされる原始バッファ１２は全
てそれと関連するレキシカル増分テーブル６７を有する
。また、レキシカル増分テーブル６７はそのエンティテ
ィを加算、削除、反復、ならびに更新するために定義さ
れる種々の能力を備えている。第９図は原始行とレキシ
カル増分間の関係を示す。

レキシカル増分の設計の背後にある動機は、対応するテ
キストが変更された時に５ｃａｎ　Ｉｎｃｒｅｍｅｎｔ
（）のみを加えればよいということである。レキシカル
増分のセーブされた走査トークンは、ＣＰＵタイムの節
約と、テキストをアクセスしない際にページフォルトが
潜在的にセーブされる両方の理由から、その対応するコ
ンパイルのスピードアップを伴う増分走査の基礎である
。

スキップ走査は走査を標準地点で停止させそれをあたか
も中間原始行を走査し終ったかの如く原始テキスト内で
再始動させる能力である。このアクションは、テーブル
６７からのレキシカル増分が再使用される時に適用され
ることによって走査コンテキストを再使用されたレキシ
カル増分の最終トークンに続く原始テキスト内の適当な
位置に更新できるようにする必要がある。また、このア
クションはテーブル７６からのセマンティック増分が再
使用される時に適用される。何故ならば、その関連する
レキシカル増分は間接的に再使用されるからである。走
査コンテキストが維持される限り、スキャナ６５は、新
たなレキシカル増分が生成されなければならない時に何
処で走査を開始すべきかを知ることになろう。

トークンインターフェースはスキャナ６５により、トー
クン格納の物理的レイアウトをコンパイラ１１の残部か
ら隠すために使用される。この戦略によってスキャナ６
５は如何にしてそれがトークンの状態セーブとチェック
ボイトン化をサポートするかについての詳細を隠すこと
ができる。同様にして、それはスキャナとコンパイラ１
１の残部との間のインターフェースか簡単になるために
再使用可能なスキャナモジュール（バッチ対増分）の構
成を奨励する。

トークンインターフェース内に適用される主な技法は、
トークンを識別するために「ハンドル」を使用すること
である。ハンドルは、最も簡単な場合には、情報の所有
者にとって専有の構造アレイに対する索引であり、各ア
レイ要素は一単位の情報を記述する。情報に対するアク
セスは所有者により提供される手続上のインターフェー
スにより行われる。工学上の理由から、主としてアクセ
ス機能を効率的に実行するためにより複雑なハンドル解
説が時々選択される。

それ故、第７図には、スキャナ６５とコンパイラ１１の
残部とにより交換されるトークンの発生は全て実際には
トークン用のハンドルである。１トークンに関する情報
が必要な場合、コンパイラ１１の他の部分はハンドルと
トークンインターフェースのアクセス機能を活用する。

スキャナ６５は生のテキストのトークンの変換を処理す
る。第一のステップは語素を発見することである。その
場合、語素は言語からの対応する構造と関連していなけ
ればならない。幾つかの言語についてはこれは些細なマ
ツピングである。マクロもしくはキーワードの特徴を有
する他の言語については、それは計算と他のテーブルを
必要とするかもしれない。

第８図はトークンテーブル６６の構造を示す。

語素は原始テキスト内の情報の単位である。一つの語素
の唯一の識別的特徴はそれを構成するテキストである。

一義的な語素の数は原始テキスト中の語素の総数よりも
少ない。この属性は一義的な語素を作成し、テキストキ
ャラクタについてではなくテーブル索引（すなわちハン
ドル）についての比較を可能にすることによってＲＣＡ
ＳＥ環境内で機能するように設計されたコンパイラ内で
利用される。作表対象はレキシカルテーブル７７である
。ストリングは、ストリングテーブル７８と称される収
集不能なヒープもバッキングされる。

（さしあたり空終了ＡＳＣＩＩフォーマントを想定され
たい。）語素はヒープもしくはストリングテーブル７８
に対する索引である。レキシカルテーブル７７はスラッ
シングで避けるために一つを原始テキストバッファ１２
に割当てられる。

パーサ７０の仕事は、第７図に示すように、文法規則ア
プリケーションの系列、所謂基準パースを報告すること
である。スキャナ６５は一系列のトークンをパーサ７０
へ同時に報告する。パーサ７０を駆動するのはトークン
の完全な系列である。

これら２系列はコンパイラ１１の残部により知られてい
なければならない全てを含んでいる。

増分パーサ７０はこの仕事を実行し、先のコンパイルセ
ツション以後修正されたトークンの流れの部分のみを再
パージングするという追加的な能力を提供する。この能
力はスキップパージングとして知られている。

一つのプログラミング言語について文脈自由な文法を構
成することができる。そのことが行われた時、かかる文
脈自由な文法は全ての適法的プログラムと幾つかの非適
法プログラムを記述する。

これらの非適法プログラムはコンパイラ中の他の機構に
より発見されなければならない。更に、文法はＬＡＬＲ
（１）であり、バッチと増分コンパイラによって定義さ
れる言語の意味を反映する必要がある。ＬＡＬＲ−をベ
ースにしたコンパイラに対する入力として首尾良く使用
される文法は何れもこの条件を充たす。

ＲＣＡＳＥ環境内で使用するためには各プログラミング
言語について文脈自由な文法を構成する必要がある。こ
の制約はフロントエンドがＬＡＬＲ文法プロセッサを使
用することを必要とせず、基準パースは回帰的降下技法
と共に生成させることもできる。

以下のセクションはスキップパージングと、パーサと、
ジェネレータ間のトークンルールインターフェースの使
用法を解説したものである。

スキップパージングは基準地点（例えば、文の開始）で
パーサ７０を停止させ、それをあたかも中間のトークン
を構文解析したかの如く再始動する能力である。これは
使用されるパーサのタイプ（回帰降下もしくはＬＡＬＲ
）に応じて困難な形で実行される。回帰的パーサは対応
するパージング機能を呼出さないことによって指名され
た増分をスキップする。（指令増分についての詳細は以
下のセマンティック増分についての所論を参照されたい
。）テーブル駆動パーサは、パーサの内部状態を更新し
それを指名増分のために前後から桁上げするサービスを
提供することによって間接的にスキップする。スキップ
パージングは両方の場合ともジェネレータ７１から呼出
される。

スキップパージングが生ずると、テーブル７６からのセ
マンティック増分がスキップされたトークンとルールの
セマンティックアクションを計算する代わりに再使用さ
れる。セマンティック増分の再使用（スキップパージン
グにより可能になる）はコンパイルタイムのターンアラ
ウンドのスピードアップに相当に寄与する。スキップパ
ージングはスキップ走査を意味することに注意されたい
。

トークンルールインターフェースは、パーサ７０とジェ
ネレータ７１間のゆるやがな結合を実行する。これら２
つの構成部分間の依存関係を最小限にすると、スキップ
パージングの実行と再使用可能なパーサとジェネレーク
モジュールの構成が容易になる。更に、トークンルール
インターフェースは使用中のパーサ７ｏのタイプについ
ての詳細をジェネレータ７１から隠す。

トークンとルール系列の大きな割合は、何ら意味論的な
内容をもたないため、意味論的解析に先立って効率上の
理由から濾過することができる。

殊に、定数、意味識別子、定数、ストリングを有するト
ークンは、それらを含むルールをパスさせるかあるいは
その直前にパーサ７０によりジェネレータ７エヘパスさ
れることによってセマンティソクルーチンはそれらが必
要とする内容を得るようになっている。同様にして内容
を有するルールだけがパーサ７０から通される。ジェネ
レータ７１内では普通、（すこぶる大きな）スイッチと
、各内容ルールについて一つのエントリーがある。

ジェネレータ７１は、バックエンドに至るセマンティッ
クアクシッンの系列を通過させる。

回帰的降下の観点からは、それはりュグナイザがそのＬ
ＡＬＲの対応部分と似通っており、内容トークンとルー
ルを発する以外は何も行わないということを意味する。

ジェネレータの観点からすると、それは回帰的又はＬＡ
ＬＲパーサが使用されるでいるかどうか、両方ともか、
あるいは混合体であるかは重要ではないことを意味する
。

ジェネレータ７１の仕事は、第７図に示す通り、何んづ
くセマンティックアクションの系列（エミッタおよび記
号テーブルアクション）を含むＩＬ上からバックエンド
へ通すことである。ジェネレータ７１は、大きなスイッ
チとして製作される。

各場合ともバンクエンドに対して適当な呼出しが行われ
る。一定の条件が発生すると、ジェネレータ７１は、ス
キップパージングを呼出して、セマンティック増分を再
使用し、バンクエンド生成コードの時間を節約すること
になろう。

増分コンパイラ１１のバックエンドの必要条件に関して
、バックエンドモジュールは、コンパイラのバッチと増
分バージョンどうしの間で共用されるべきではない。バ
ッチコンパイラの書込みは増分バックエンドの細目と関
わりをもつべきではない。バックエンドの仕事は、増分
リンカ１５に対する入力をつくりだすことである。それ
はテーブル７６のセマンティック増分を生成、再使用し
、増分記号テーブル５６を操作することによってこの仕
事の大部分を実行する。

原始モジュール１２の一部の意味論的な内容は、セマン
ティック増分（テーブル７６内）に記録される。セマン
ティック増分の境界は原始言語中の意味単位に対応する
。（例えば、セマンティック増分は代入文とすることが
できる）現代プログラミング言語の意味単位が入れ予成
であるために、セマンティソク増分もまた入れ予成であ
る。セマンティック増分は以下の能力を提供する。

Ｃｈｅｃｋ　（）　＋　　セマンティック増分の予め計
算された状態がその環境の状態と一致するようにする。

Ｃｈｅｃｋ　（）は決してその副次的影響を有しない。

Ｃｏｍｐｉｌｅ　（）　＊　　記号テーブルアクセスと
実行可能コードの生成の両面からこの増分の影響を計算
する。これはＣｈｅｃｋ　（）が故障状態に戻るときに
呼出される。コンパイルの任務はもし可能とあればセマ
ンティック増分テーブル内の影響を記録し、さもなけれ
ば増分能力なしにそれを実行されるがままに残しておく
ことである。この最後の場合、Ｃｏｍｐｉｌｅ　（）は
増分の構築の失敗を報告することによって以下の機能Ａ
ｐｐｌｙ　（）はアプリケーションを試みずに固有のコ
ンパイラへ直ちに復帰できるようにする。

Ａｐｐｌｙ　（）　、　　増分をコンパイルする影響が
加えられるようにする＊　Ａｐｐｆｙに）はＣｈｅｃｋ
　（）が失敗ＬＪ、：時、Ｃｏｍｐｉｌｅ　（）後に呼
出される。

ＲＣＡＳＥ環境はコード実行パージングとセマンティッ
クアクシッンの分離を必要とする。手段はパーサ７０の
基準パースとそれに関連するレキシカル情報の生成に対
する制限である。この条件のために再コンパイルが不要
なときにスキップパージングが可能になる。任意の特定
のプログラミング言語についてＲＣＡＳＥによりサポー
トされる一組の「指名増分」が存在することになろう。

例えば、同級は代入文、宣言、条件文および機能定義を
含むことができよう。ＲＣＡＳＥは、増分コンパイラ１
１が分離指名増分について分離実行可能コードを生成す
ることを必要とする。この分離属性によって増分セマン
ティクスが可能になる。

ネスティングされた増分は分離する必要がないのはいう
までもないが、増分にとって一義的なアプリケーション
原始行よりスタートする必要はない。

即ち、ネスティングされた増分でさえ同一行からスター
トすることは不可能である。

種々のレベルの抽象間の関係は（恐らく当てにならない
カリ簡単である。生のテキストはエディタｌＯにより維
持され、コンパイラのスキャナ６５により走査可能な目
的（テーブル６７のレキシカル増分）に分割される。レ
キシカル増分の隣接する系列は何れもセマンティック増
分の範囲内にある。セマンティック増分は常に適当にネ
スティングし、更に、最初のレキシカル増分を共用する
ことは決してない。この後者は、一部はプログラミング
言語設計の人工的所産（新たなものが識別シンタクスと
共に常に開始される）であり、−部は実行上の便利さに
対する譲歩である。何故ならば、セーブされた状態を一
義的なアプリケーション原始テキスト行と関連させるこ
とが必要であり、従って一行と関連して２行の情報をセ
ーブすることは不便であるためである。（第９図参照）
第９図の例は、Ｃプログラムを含む原始バッファ１２の
部分を示す。たとい最初の代入文であるＸ：＝　（ｘ＋
ｙ）＋　（ｘ−ｙ） が多数の行にまたがっていても、各行は別々に走査する
ことによってその行の各々についてレキシカル増分がつ
くりだされるようにする。（Ｌ２＆Ｌ３）即ち、セマン
ティック増分Ｓｌはこの文により形成される。然しなか
ら、“ＥＬＳＥ”節はＣのオーバライドキャラクタ“＼
”を使用して多数の行の間隔を埋めるため、その行の各
々は別個に走査することはできなくなる。この場合、こ
の特殊構造（Ｌ４）を走査するために要する行全体を含
むために一個のレキシカル増分がっくりだされる。第９
ａ図はレキシカル増分Ｌ３とＬ４に対するトークンハン
ドルリスト内容を示す。（トークンはトークンテーブル
６６内に、レキシカル増分はテーブル６７へ入力される
。） 第９図のセマンティック増分によりサポートされる指名
増分は代入（３１と３２）とｉｆ　−ｅｌｓ構造（Ｓ３
）である。第９ｂ図はセマンティック増分の内容を示す
。

セマンティック増分は発せられたコードもしくは記号テ
ーブル５６の何れかに対する影響である。

記号テーブル５６は以下に述べる。セマンティック増分
（例えばＳｌ、ｓ２、Ｓ３）の実行可能な影響は、その
ために生成されるコードである。第９ｂ図について述べ
ると、セマンティック増分テーブル７６内のエントリー
８５は、セマンティック増分の識別８６、実行する必要
のある妥当性チェック８７、および、そのチェックがパ
スした場合に再使用可能なコード増分を識別するための
フィールド８８を含む。ｓ２の場合、妥当性チェックは
、原始コードを含む行が修正されなかったということ、
また変数Ｘの属性が不変であることである。この場合、
その効果はハンドル１ｏにより指定されたセーブコード
を再使用することである。

セマンティック増分は任意の深さにネスティングできる
ことを強調しておくのは重要である。その結果、セーブ
状態の長い増分は小さな増分がそれぞれ必要とする同一
の一定オーバーヘッドについて再使用できる。これは本
発明のシステムのスピードの主要な決定要因でありユニ
ークなものである。即ち、セマンティック増分テーブル
７６内のセマンティック増分の内容は、それとハンドル
をコード増分テーブル７３内に妥当化するためのチェッ
クである。コード増分テーブル７３は実行可能コードの
断片を含む。それぞれは多分、若干の固定アドレスを求
めて隣接しているが、さもなければＣＰＵに対して準備
態勢にある。

セマンティック増分が再使用される時、そのためのコー
ド生成フェーズはテーブル７３からコード断片を再使用
することによってスキップされる。

ＲＣＡＳＥ中の実行イメージの多く　（もしくは全部）
は、コード増分テーブル７３内で実行される。

第９ｃ図は、コード増分テーブル７３の編成を示す。コ
ード増分テーブル７３は、実際には２つのサブテーブル
より構成される。コード索引テーブル７９は、コード断
片テーブル８ｏを管理する情報を含んでいる。セマンテ
ィック増分ｓ１．８２等は、コード索引テーブル７９内
のエントリー８２をアクセスするためのハンドル８１を
含んでいる。コード索引エントリー８２から、コード断
片エントリー８３が導き出される。コード断片エントリ
ー８３は実行可能コードシーケンスを含む。

増分コンパイラ１１により発せられる全コードはプレイ
とポインタ境界材は用に自己チェックを行う。

記号はプログラム内でのその用法を解決するために必要
とされる全情報と共に原始プログラム用で使用される名
称である。特定記号と名称の発生を関係づける伝統的な
機構は記号テーブル又は装飾抽象シンタクストリーであ
る。（Ｃ言語における有効範囲ルール又はフォートラン
における定義の位置の如き）文脈上の解釈のために各記
号はコンテキスト内で解釈しなければならない。それ故
、各記号に関する情報は記号名、そのデータ型、使用方
法（例えば手続、変数又はラベル）そのアドレス等を備
えることができる。

従来の記号テーブルは情報を入力、チェック、検索する
方法を介してアクセスされる。増分記号テーブル５６は
従来通り振舞うと同時に有効範囲クロージャを横切って
再使用たりコンパイル終了のためにも情報をセーブしな
ければならない。

ＲＣＡＳＥと一貫するインプリメンテーションは、情報
の個々のアイテム（又は属性）上にウオーム／コールド
（妥当性）ビットを設け、全体としての記号、全体とし
ての局部有効範囲、および全体としての記号テーブルを
設けることである。

ＲＣＡＳＥで使用するためには記号テーブル５６は、通
常バッチコンパイラ内で見出されるよりもより詳細な情
報を含まなければならない。殊に絶対メモリアドレスは
グローバル変数に割当てられる。

第７ａ図について述べると、増分記号テーブル５６内の
エントリのフィールドが本発明の実施例に従って描かれ
ている。最初のフィールドは記号名がストアされたトー
クンテーブルの索引を含んでいる。コンテキストフレー
ムを定義するためにブロック署名フィールドが使用され
る。コンテキストフレームは名称の有効範囲を限定する
目的に奉仕することによって名称に対する照会があいま
いにならずに同一の名称が異なるコンテキスト中で異な
る目的で使用できるようになっている。従って異なる手
続は同一名を異なる形で定義し使用することができる。

妥当性ビット、属性、およびアドレスフィールドは先に
論じた。

アプリケーション原始モジュールの新たなコンパイルが
開始されると、先のコンパイルからの十分に開発された
記号テーブル５６が存在する。

（妥当情報は記号テーブル５６から決して廃棄されない
）その際、全ての妥当性ビットはフォールスにセットさ
れる。その後、コールドアイテムはウオームアツプされ
（即ち妥当性ビットがセットされ）再コンパイル中に再
使用される。例えば、コンパイルが進行するにつれて、
記号名とそれに関連する情報が生成する。しかし、この
情報が記号テーブル５６内に入力される前に、テーブル
が（ジャーナルアクシランを介して）チェックされ、そ
の情報が先のコンパイルからのテーブル内に既に存在す
るかどうかが判断される。もし特定の名前が記号テーブ
ル内に既に存在すれば、その妥当性ビットはウオームに
セットされ、その属性が先のコンパイル後のものと同一
であるかどうかを判断するための調査がなされる。もし
一つの属性が不変であれば、その妥当性ビットはウオー
ムにセットされる。このプロセスは変更された属性が発
見されるか新たなエントリが発見されるまで続く。

このことが起こると、変更された情報又は新たな情報に
依存するものは全て再コンパイルしなければならない。

然しなから、この点まで、コンパイラは不必要にコード
をコンパイルしなおさずにクリーンなもしくは不変の増
分の上をスキップすることができる。パースにより発生
する情報は先のコンパイル中にセーブされ今や再使用す
ることができるためにクリーンな増分はパージングする
必要はない。スピードと効率を更に向上させるために、
先に述べた如く、記号テーブル５６に対するメモリは、
スラッシングを回避するために単一の原始モジュール１
２に対して隣接して割当てられる。

ジャーナリングは重要な特徴である。本文中に論する増
分コンパイルの基礎にある技法は、第７図のコンパイラ
１１のモジュールどうしの間のインターフェースを横切
る対話を選択的にジャーナリングすることである。コン
パイラ１１が入力のかたまりに対するその応答を一系列
のアクションとして記録することができる場合にはいつ
でもそれらを再計算するよりもアクションを使い尽くす
潜在力がある。これが特に魅力的なのは前者が後者より
も実行速度が何倍も高速である時である。

最も簡単な例はテキストと一行の走査結果である。

ジャーナルは、対応する原始テキストと関連するトーク
ンの系列である。トークンリストはスキャナ６５内にテ
ーブル６７のレキシカル増分形でセーブされる（また第
９ａ図も参照されたい）トークンは要求に応じて１度に
１回、パーサ７０に戻される。ジャーナリングは２つの
レベルで実行される。レキシカル増分のトークンリスト
内にはトークンハンドルがセーフ゛される。トークン細
目はトークンテーブル６６内にセーブされる。所与のト
ークンに関する情報はトークンハンドルを使用してトー
クンテーブル６６からアクセスできる。

もう一つのジャーナル例はセマンティック増分テーブル
７６である。各セマンティック増分はその影響を（如何
にそれ自身を妥当化すべきかについての情報を含めて）
記号テーブル５６又は発されたテーブル７６のコードに
ふりむける。関連コードはコード増分テーブル７３内に
ジャーナリングされ、そのロケーションはセマンティソ
ク増分内にハンドルとして表示される。ジャーナルに対
しては他の多くの候補が潜在的に存在する。実行ジャー
ナルの選択は各ジャーナルの費用／便益の分析に基づい
て個々のコンパイラが行う。

この技法の限界は増分がテキストの行ブロックとだけ関
連できジャーナリングが影響を再計算するよりもプレイ
バンクをより効率的にするに十分簡単でなければならな
いということである。全てのスピードアンプが事実上費
用効果的であるということは期待できない。

アクションが簡潔で十分規定されたインターフェースを
横切ってアクティビティを記録するときジャーナリング
はより効果的である。

各ジャーナルは、そのチェックがジャーナルの一部とな
るような一組の言語特有な条件の下で妥当である。一つ
の普遍的な条件はモジュール１２の対応する原始テキス
トが変化しておらずＲＣＡＳＥ２１がクリーンラインを
経てコンパイラ１１のスキャナ６５に提供する情報がテ
ーブル５０から増分する点である。

所与の原始テキスト増分についてジャーナルを最適化す
ることができる。例えば、伝統的なコンパイラが記号テ
ーブル５６内の変数の発生を繰返し探索する場合、増分
コンパイラ１１はそれを１回で探索して先の属性が変更
していないことを確かめ、その後更にチェックすること
なしに増分全体について変数に関する全アクションを承
認することができる。′ｉｆ”文の場合、いったん変数
の妥当性チェックが行われると、最終的な目標コードが
一連の小さなエミッタ固定アクションでなく単一のアク
ションとしてプレイバックできる。

ジャーナリング法を使用すると次の責任が生ずる。

（ａ）　　ジャーナルの生産者はジャーナルエントリを
操作するために必要な全てのアクセス機能（創造、削除
、妥当化、反復等）を提供しなければならない。

（ｂ）　　各ジャーナルは又ラッシングを避けるために
原始バッファ１２あたりで割当てなければならない。

（Ｃ）　　一つのジャーナルはチェックポイン化可能な
ハンドルをそのエントリーに提供しなければならない。

（ｄ）　　一つのジャーナルはジャーナル生産者により
提供されるアクセス機能を介して解釈しなければならな
い。

コンテキストスイッチングとチェックポインティングは
もう一つの重要な特徴である。−セツションでは、開発
者は多くの相異なる原始バッファ１２をコンパイルする
ことになろう。ＲＣＡＳＥは増分コンパイラ１１が呼出
し可能であることを必要とするから、多数モジュールの
処理を管理できなければならないであろう。増分コンパ
イラ１１は情報をセーブし、その情報を隠し、一方コン
テキストを新たなモジュール１２に切替えた後、コンテ
キストがスイッチバックされた時にそのセーブされた情
報を明らかにすることができなければならない。このこ
とは今度は、増分コンパイラの内部モジュール（例えば
、スキャナ６５、ジェネレータ７１、エミッタ７２）の
全てがそれぞれのセーブ状態（例えばレキシカル増分テ
ーブル６７、セマンティック増分テーブル７６等）のコ
ンテキスト切替えをサポートできなければならないこと
を意味する。

コンテキスト切替えてサポートするために、増分コンパ
イラ１１はＲＣＡＳＨにアクセスできる次の能力をサポ
ートあることができなければならない。

Ｓｅｔ　Ｃｏｎｔｅｘｔ　（ｈ）：　　ｈが“コンテキ
ストハンドル”である場合、１回に一つ以上のコンパイ
ル単位につき状態を呼出し可能なコンパイラ１１がセー
ブし要求に応じてコンテキストどうしの間を切替えるこ
とができる。現在のコンテキストはＣｈｅｃｋｐｏｉｎ
ｔ（）の如きコンパイラ供給のサービスの意味を定義す
ると共にメモリ割当スキームに影響を及ぼす。

例えば、トークン値を記述するテーブル６６を考察する
。環境により処理される一つ以上のモジュール１２が存
在できる。スキャナ６５は、トークン値をセーブする外
に、コンテキストｈについてＳｅｔ　Ｃｏｎｔｅｘｔ（
ｈ）に対する要求を受取ると特定のトークンテーブル６
５を明らかにし隠すことができなければならない。

更に、ＲＣＡＳＥは開発者が現在の環境をセーブしそれ
を後になって再開できるセツションサポート（チェック
ポイント／リスタート）を提供する。このためには、各
コンパイラモジュールがそのセーブ状態をファイルに書
込み同じセーブ状態を読取り再開できることが必要であ
る。この条件は内部に、又はセーブされた情１［！　（
例えばハンドル）を記述するために機械アドレスを使用
しないインプリメンテーシジンを示唆するものである。

チェックポイント／リスタートを支持するために、増分
コンパイラ１１は、ＲＣＡＳＥ２１にアクセス可能な次
の能力をサポートしなければならない。

Ｃｈｅｃｋｐｏｉｎｔ（）　：　　このエントリは、現
在の原始モジュール１２について全ての関連する状態情
報をファイル上に記録するコンパイラのチェックポイン
トファシリティを活動させる。リターン値はチェックポ
イントファイルのパス名である。

（注：　　Ｓｅｔ　Ｃｏｎｔｅｘｔ（）は多重モジュー
ル１２内を反復するために使用される。） Ｒｅｓｔａｒｔ（ｎ）　：　　ｎがチェックポイントフ
ァイルのバス名である場合、チェックファイルの内容か
ら増分コンパイルに必要とされるデータ構造全体を復帰
させるコンパイラのりスタートファシリティを活動させ
る。普通の場合、リスタートはここに指示するようにＲ
ＣＡＳＥ内からでな（ＲＣＡＳＥヲ活動させるオペレー
ティングシステムのコマンドラインから呼出される。

更に、ＲＣＡＳＥはユニークなチェックポイントファイ
ル名を生成するために次の能力をコンパイラ１１に供給
することになろう。

Ｍｏｄｕｌｅ　Ｎａｎ＋ｅ（）　：　　現在原始モジュ
ール１２の名前をリターンする。

Ｐｒｏｊｅｃｔ　Ｎａ隋ｅ（）：　　現在プロジェクト
の名前をリターンする。

増分リンカ１５はその入力としてコード−データー記号
バッファ１４を受取る。上記バッファ１４は先に説明し
たように、記号テーブル５６、コード増分テーブル７３
、リンクテーブル５８を備える。リンカ１５は先のリン
キング処理以来変更されず変更された要素に依存しない
コード−データー記号バッファ１４からの増分が再使用
される意味で増分的である。増分リンカをずっと高速に
処理させることのできる特徴の一つは、コード−データ
ー記号テーブル１４がファイル内ではなく仮想メモリ内
にある点である。すなわち、セーブと復帰の時間だけで
なくファイルシステムとファイルフォーマット作成の複
合性が全て存在するとは限らない。もう一つの特徴は環
境が非最適化コードを創造し、したがってコード（コー
ドデータ記号テーブルや実行可能コードテーブルプラス
リンクリスト中に具体化される）はすこぶる簡単でリン
クする任務をより複雑でないものにするという点である
。

コンパイラは各モジュールについてリンクテーブル５８
の必要データと供給データをつくりだす。

これらのデータは各エントリ５７について、“新”“旧
”削除”タグ５９を備え、リンカ１５は、これらを変更
モジュール内の変更データのみを更新するために使用す
る。即ち、もし１つのモジュールが変化していなければ
、更新の必要はなく、もし変化したモジュール内では更
新さるべきであるのは変化した必要もしくは供給データ
のみである。ランタイムライブラリ２４内の外部アドレ
スは、通常１サイクルから次のサイクルまで一定のまま
にとどまることになろう。それ故、コン、＜イラ１１は
各モジュール１２に対するテープＪし５８を生成し、増
分リンカ１５は、リンク機能が呼出されたとき、テーブ
ル５８の全ての組合せであるグローバルリンクテーブル
を生成又は更新する。

このバローバルリンクテーブルはモジュールの何れにお
いてもそれぞれの必用又は定義（供給）についてのエン
トリを含み、このテーブルは−サイクルから次のサイク
ルまでメモリ内に保持されることによって、ファイルと
して形成されメモリに書込まれた後呼出される必要はな
いようになっている。メモリ内キャラクタと、エントリ
のかたまりが再生される必要がないという事実はターン
アラウンドのリンク部分を著しくスピードアンプする。

これらの特徴はＲＣＡＳＥがメモリに対して行う異例の
要求と、従って上記メモリ管理方法が処理に対して有す
る重要性を明らかにする。ＲＣＡＳＥ２１自体に対する
実行可能コードが常に存在するだけでな（、エディタ１
０と（モジュール１２のように）開発中の原始コードの
全て、少なくとも一つのコンパイラ１１、デバッガ２２
、リンカ１５、ビルゾも同時に活動する。モジュールの
集まりはスラッシングを回避するように仮想メモリシス
テムと対話しなければならない。エディツトコンパイル
−リンク−ランのサイクルの７クテイビテイの自然のフ
ェーズによってホストメモリシステムは実行中のＲＣＡ
ＳＥセツションの実行可能構成部分のオーバレイを効率
的に管理することができる。状態をセーブする大部分の
構成部分は１回に一つだけの原始モジュールを処理し、
原始バッファ毎にメモリを割当てなければならない。

このことはゾーン、又は周知のプロシージャｍａｉｌｏ
ｃ（）とｒｅａｌｌｏｃ（）とにより初歩的な形で行う
ことができる。増分コンパイラ１１は、メモリの割当て
において合理的でなければならない。

【図面の簡単な説明】

第１図は本発明の環境を使用して実行可能な古典的エデ
ィツト−コンパイル−リンク−ランサイクルの概略チャ
ート、 第２図は本発明の一例による環境の構成部分の概略線図
、 第３図は本発明の環境を使用するコンピュータシステム
例のブロック線図、 第３ａ図は本発明の一つの特徴により使用される仮想メ
モリシステムのメモリマツプ、第３ｂ図は、第３ａ図の
仮想メモリ構成の隣接しあうページにおける一つのアプ
リケーションモジュールからの原始テキストイメージ図
、第４図は本発明のソフトウェア開発システムのメモリ
要求全体と、本システム中のモジュール間関係と種々の
アクティビティフェーズを示すメモリマツプ、 第５図はＲＣＡＳＥ、エディタ、原始テキスト、および
関連モジュール間の関係を示す本発明の環境の一部の線
図、 第６図は、エディタ、ＲＣＡＳＥモジュール、および本
発明システムのコンパイラ間の関係と、増分コンパイラ
が位置するコンテキストを示す線図、 第６ａ図は各モジュール１２毎にコンパイラ１１によっ
て作成されるリンカテーブルのフォーマットの線図、 第６ｂ図は本発明の一例の環境の「メイク」機能により
使用するためにコンパイラ１１により作成される増分依
存性解析テーブルのフォーマットの線図、 第７図は本発明の一例により設計された増分コンパイラ
のフロント／バックエンドの全体構造の線図、 第７ａ図は第７図のコンパイラによって生成される記号
テーブルと記号テーブルエントリの線図、第８図は第７
図のコンパイラ内に生成されるトークンテーブルの構造
の線図、 第９図は第７図のコンパイラの処理における原始テキス
ト、レキシカル増分、およびセマンティック増分の関係
を示す線図、 第９ａ図は第９図に示すレキシカル増分の２つのトーク
ンハンドルリストの内容を示す図、第９ｂ図はセマンテ
ィック増分テーブルの内容を示す図、 第９Ｃ図は第９図の増分に対応するコード増分テーブル
の編成図。 ０ １ ５ ８ ２ ３ エディタ、 コンパイラ、 リンカ、 実行装置、 デバッガ、 バッチコンパイラ。 図面の浄書（内容に変更なし） ｉｇ ■ ｉｇ 仮想メモリ Ｆｉｇ ｂ 仮想メモリ内 リンカ情報 コンパイラによって準備された必要２定義テーブル増分
シンボルテーブル ＦＩＧ ａ へのインデツクス） トークン テーブル ｉｇ 原始テキスト レキシカル増分 セマンティク増分 ｉｇ ｂ コード索引テーブル コード断片テーブル コード増分テーブル ｉｇ Ｃ

Claims (1)

1. 【特許請求の範囲】 １、プログラミング開発システムのエディット−コンパ
   イル−リンク−ランサイクルにおけるターンアラウンド
   タイムを減少する方法において、 ａ）ファイルシステム内に常駐し、全エディット活動中
   に、複数のラインを含む原始テキストバッファ内の仮想
   メモリ内に保持されるアプリケーション原始テキストの
   モジュールをエディットし、 ｂ）上記アプリケーション原始テキストのモジュールを
   増分的にコンパイルしてメモリ内に実行可能なアプリケ
   ーションコードのモジュールをつくりだし、 ｃ）上記実行可能なアプリケーションコードのモジュー
   ルを増分的にリンクしてメモリ内に実行可能な形式のア
   プリケーションプログラムをつくりだし、 ｄ）上記実行可能な形式のアプリケーションプログラム
   を所定位置で実行する、 ステップより成る前記方法。 ２、上記原始テキストバッファ内の各ラインについて原
   始テキストの行が変化したかどうかを示す関連変更タグ
   をつくりだすことを含む請求項１の方法。 ３、上記原始テキストの各行について上記行のテキスト
   に対するロケータと、上記行に続く非変更行の数の表示
   を有するテーブルエントリを有するクリーンラインテー
   ブルをつくりだすステップを含む請求項１の方法。 ４、上記エディット・コンパイル、リンクのステップが
   一連の上記モジュールに対して実行される請求項１の方
   法。 ５、エラーの検出後、コンパイル、リンク又は実行のス
   テップの何れかを停止することによってユーザが上記エ
   ディットのステップを介して同エラーを訂正することが
   できる請求項１の方法。 ６、ａ）エディタを用いて複数行として原始テキストバ
   ッファ内にストアされた原始テキストのモジュールをエ
   ディットし、 ｂ）上記原始テキストバッファをコンパイルしてコード
   テーブルをつくりだし、 ｃ）上記コードテーブルをリンクしてコードイメージを
   つくりだし、 ｄ）上記コードを上記コードイメージを介してランし、 ｅ）上記コンパイルステップが ｉ）各増分が上記原始テキストのレキシカル増分を表わ
   すような増分テーブルを生成し、上記増分テーブルをメ
   モリ内にセーブし、対応する増分が上記原始テキストバ
   ッファの先のバージョンから上記増分テーブル内にセー
   ブされ対応する増分が変更されていないレキシカル増分
   をスキップし、 ｉｉ）上記原始テキスト内にセマンティック増分を検出
   し各セマンティック増分について上記文を含んでいる行
   が変更しているかどうかをチェックし、もし否であれば
   、上記セマンティック増分をスキップして、上記スキッ
   プされたセマンティック増分に対して上記コードテーブ
   ルのコードを再使用する、ステップを含み、 ｉｉｉ）上記リンクステップがその内部の各エントリが
   上記コードテーブルにより必要とされるか又は供給され
   る一要素の識別とロケーションを含むリンクテーブルを
   生成し、上記リンクテーブル内に必要とされ又は供給さ
   れる上記要素をつきあわせ一つのリンクリストを生成す
   ることを含む、 原始コード開発方法。 ７、上記原始テキストバッファ内の各行が原始テキスト
   の行が変更したかどうかを示す関連する変更タグを有し
   、上記原始コードの各行について上記行のロケータと上
   記行に続くクリーンラインの数の表示を有するテーブル
   エントリを含むクリーンラインテーブルを生成し、クリ
   ーンライン数が上記セマンティック増分の行数よりも大
   きいかどうかを見るために上記クリーンラインテーブル
   をチェックするステップを含む請求項６の方法。 ８、コンパイル、リンク、およびランの上記ステップの
   各々が中止されて上記ステップの系列を完了せずにエラ
   ーが検出されたかどうかのエラー表示を戻す請求項６の
   方法。 ９、ａ）各モジュールについて複数の行として複数の別
   個の原始テキストバッファのうちの一つにストアされる
   複数の原始テキストモジュールをエディットし、 ｂ）上記原始テキストバッファをコンパイルして一つが
   各々の原始テキストバッファに対する複数のコードテー
   ブルをつくりだし、 ｃ）上記コードテーブルのアイテムどうしをリンクして
   １つのリンクテーブルをつくりだし、ｄ）コードを上記
   コードテーブルとリンクリストを介して実行し、 ｅ）上記コンパイルステップが、 ｉ）各増分が上記原始テキストのレキシカル増分を表わ
   すような増分テーブルを生成し、上記増分をメモリ内に
   セーブし、対応する増分が先の原始テキストバッファの
   バージョンからセーブされ対応する原始テキストが変更
   されていないレキシカル増分をスキップし、ｉｉ）上記
   原始テキスト内のセマンティック増分を検出し、各セマ
   ンティック増分について、上記セマンティック増分に対
   応する原始テキストの行が変更されたかどうかを見るた
   めにチェックし、もし否であれば、上記セマンティック
   増分をスキップして上記スキップされたセマンティック
   増分のセーブコードを再使用する、ことを含む、 原始コード開発方法。 １０、上記原始テキストバッファの各々について、上記
   原始コードの各行毎に上記行のロケータと上記行に続く
   クリーンラインの数の表示を有するテーブルエントリを
   含むクリーンラインテーブルを生成し、上記クリーンラ
   インテーブルをィック増分の行数よりも大きいかどうか
   を見るステップを含む請求項９の方法。 １１、上記コンパイリングが上記原始テキストバッファ
   の各々について上記トークンリスト内に宣言文用の記号
   テーブルをつくりだし、記号テーブル内の各エントリが
   上記宣言文の一つに対応する請求項９の方法。 １２、上記複数の別個の原始テキストバッファ、コード
   テーブル、コードイメージ、トークンリストが全て仮想
   メモリ内に維持される請求項９の方法。 １３、上記複数の別個の原始テキストバッファ、コード
   テーブル、増分テーブル、および上記リンクテーブルが
   、上記実行ステップ後に全て仮想メモリ内にセーブされ
   、もう一つのエディットステップ後に使用される請求項
   ９の方法。 １４、ａ）原始テキストのモジュールをエディットし上
   記原始テキストを各々が関連する変更タグを有する複数
   の行として原始テキストバッファ内にストアする手段と
   、 ｂ）上記原始テキストバッファをコンパイルしてコード
   テーブルをつくりだす手段と、 ｃ）上記コードテーブルをリンクしてコードイメージを
   つくりだす手段と、 ｄ）上記コードイメージを介してコードをランする手段
   と、 を備え、 ｅ）上記コンパイル手段が、 ｉ）各エントリが１行内の原始テキストの増分を表わす
   増分テーブルを生成し、上記増分テーブルをメモリ内に
   セーブし、対応するエントリが先の原始テキストバッフ
   ァのバージョンからセーブされその対応する増分が変更
   していない増分をスキップする手段と、 ｉｉ）上記原始コード内にセマンティック増分を検出し
   、各セマンティック増分について上記文を含む行が変更
   されたかどうかを見るために上記変更タグを介してチェ
   ックし、もし否であれば、上記セマンティック増分をス
   キップし、上記セマンティック増分に対応するコードを
   再使用する手段と、を備える 原始コード開発システム。 １５、上記コンパイル手段が、上記原始コードの各行に
   ついて上記行のロケータと上記行に続くクリーンライン
   の数の表示を有するテーブルエントリを含むクリーンラ
   インテーブルを生成し、上記クリーンラインテーブルを
   チェックしてクリーンラインの数が上記セマンティック
   増分の行数よりも大きいかどうかを見る手段を含む請求
   項１４のシステム。 １６、ａ）原始テキストバッファ内に複数の行としてス
   トアされる原始テキストのモジュールをエディットし、 ｂ）上記原始テキストの各行をコンパイルして上記原始
   テキスト内に実行可能文用のコードテーブルを作成し、 上記コンパイルが、 ｉ）各エントリが上記原始テキストのレキシカル増分を
   表す増分テーブルを生成し、上記増分テーブルをメモリ
   内にセーブし、対応する増分が先の上記原始テキストバ
   ッファのコンパイルステップから増分テーブル内にセー
   ブされ対応する原始テキストの行が変更されていないレ
   キシカル増分をスキップすることを含む、 コードを増分的にコンパイルする方法。 １７、上記コンパイルステップがセマンティック増分を
   上記原始テキスト中に検出し、各セマンティック増分に
   ついて上記文を含む行が変更されているかどうかを見る
   ためにチェックし、もし否であれば、上記セマンティッ
   ク増分をスキップして、上記スキップされたセマンティ
   ック増分を再使用することを含み、上記原始テキストバ
   ッファ内の各行が原始テキストの行が変更しているかど
   うかを表示する関連変更タグを有し、上記原始コードの
   各行について上記行のロケータを上記行に続くクリーン
   ラインの数の表示を有するテーブルエントリを備えるク
   リーンラインテーブルを生成するステップを含み、上記
   クリーンラインテーブルをチェックしてクリーンライン
   の数が上記セマンティック増分の行数よりも大きいかど
   うかを見るステップを含み、上記クリーンラインをチェ
   ックしてレキシカル増分が変更していない行であるかど
   うかを見るステップを含む請求項１６の方法。 １８、ａ）エディタを用いて原始テキストバッファ内の
   メモリに複数の行としてストアされる原始テキストのモ
   ジュールをエディットし、 ｂ）上記原始テキストバッファをコンパイルしてメモリ
   内にコードテーブルをつくりだし、ｃ）上記コードテー
   ブルをリンクしてメモリ内にバッファ内のコードイメー
   ジをつくりだし、ｄ）上記バッファ内のコードイメージ
   からコードをランする ステップを含む原始コード開発方法。 １９、上記原始テキストバッファとコードテーブルと、
   コードイメージをメモリ内にセーブし、別のエディット
   ステップ後に再使用し、上記原始テキストバッファの各
   ラインが関連する変更タグを有し、上記原始コードの行
   が上記エディットステップで変更されたかどうかを表示
   する請求項１８の方法。 ２０、上記コンパイル工程が実行可能文のコードテーブ
   ル用のコードを生成し、上記原始テキストの宣言文用に
   記号テーブルをメモリ内につくりだし、記号テーブル内
   の各エントリが上記宣言文の一つに対応する請求項１８
   の方法。 ２１、ａ）原始テキストのモジュールをエディットし、
   エディットされた原始テキストを原始テキストバッファ
   内のメモリ内に複数の行としてストアし、各行が先のモ
   ジュールエディットステップ以後変更されたかどうかを
   表示する関連する変更タグを有し ｂ）上記原始テキストバッファをコンパイルしてメモリ
   内にコードテーブルをつくりだし、ｃ）上記コードテー
   ブルをリンクしてメモリ内のバッファにコードイメージ
   をつくりだし、ｄ）メモリバッファ内のコードイメージ
   からコードをランするステップを含み、 ｅ）上記コンパイルステップが上記原始テキストの実行
   可能文用のコードテーブルを生成し、メモリ内に上記原
   始テキストの宣言用記号表を生成し、記号テーブル内の
   各エントリが上記宣言文の一つに対応し、 ｆ）上記リンキングステップが上記リンクテーブル内の
   各エントリが上記コードテーブルにより必要とされる又
   は供給される要素の識別とロケーションを含むリンクテ
   ーブルをメモリ内に生成し、上記リンクテーブル内に必
   要とされ又は供給される上記要素をつき合わせてメモリ
   内に上記ランステップで使用されるリンクリストを生成
   することを含む、 原始コード開発方法。 ２２、上記コンパイル、リンク、ランのステップの各々
   が停止されてもしエラーが発見されれば上記ステップの
   系列を完了せずにエラー表示を戻し、上記原始テキスト
   バッファ、コードテーブル、記号テーブル、リンクテー
   ブルを仮想メモリ内にセーブし、仮想メモリ内にセーブ
   された上記原始テキストバッファ、コードテーブル、記
   号テーブル、リンクテーブルが要求に応じて実メモリ内
   外にページングされる請求項２１の方法。 ２３、上記原始テキストバッファ、コードテーブル、記
   号テーブル、リンクテーブルがそれぞれ仮想メモリ内の
   隣接しあうページ内にセーブされ、要求に応じて実メモ
   リ内外にページングされ、複数の上記原始テキストモジ
   ュールが存在し、仮想メモリ内の隣接するページ内に上
   記モジュールの各々について一つの原始テキストバッフ
   ァ、コードテーブル、記号テーブルがセーブされる請求
   項２１の方法。 ２４、ａ）原始テキストバッファ内に複数の行としてス
   トアされる原始テキストのモジュールをエディットし、 ｂ）上記原始テキストバッファをコンパイルしてコード
   バッファをつくりだし ｃ）上記コードテーブルをリンクして一つのリンクテー
   ブルをつくりだし、 ｄ）コードを上記コードテーブルとリンクテーブルを介
   してランする、ステップを含み、ｅ）上記コンパイルス
   テップが、上記原始テキストの行を走査し、上記原始テ
   キストのレキシカル増分のテーブルを生成し、上記レキ
   シカル増分テーブルをメモリ内にセーブするステップを
   含み、上記走査が、対応するレキシカル増分が先の走査
   ステップからセーブされ関連するテキスト行が変更され
   なかったレキシカル増分をスキップすることを含む、 コードコンパイル方法。 ２５、上記原始テキストバッファの各行が関連する変更
   タグを備え、上記原始コードが先のエディットステップ
   以後変更されたかどうかを示すようになった請求項２４
   の方法。 ２６、上記原始テキストバッファ、コードテーブル、リ
   ンクテーブル、およびセマンティック増分テーブルが全
   て仮想メモリ内に維持される請求項２４の方法。 ２７、ａ）エディタを用いて原始テキストバッファ内に
   複数の行としてストアされる原始テキストのモジュール
   をエディットし、 ｂ）上記原始テキストバッファをコンパイルしてメモリ
   内にコードテーブルをつくりだし、 ｃ）上記コードテーブルをリンクしてメモリのバッファ
   内にリンクテーブルをつくりだし、 ｄ）上記コードテーブルとリンクテーブルを介してメモ
   リからコードをランし、 ｅ）上記コンパイルステップが上記原始テキストの行を
   走査して上記原始テキストのレキシカル増分のテーブル
   を生成し、上記レキシカル増分テーブルをメモリ内にセ
   ーブする段階を含み、上記走査が、対応するレキシカル
   増分が先の走査ステップからセーブされ関連する原始テ
   キスト行が変更されなかったレキシカル増分をスキップ
   する段階より成る、請求項２４の方法。 ２８、上記レキシカル増分が上記原始コードテキストの
   行に対応し、上記原始テキストバッファの各行が、上記
   行が変更したかどうかを示す関連する変更タグを有し、
   上記スキッピングが、上記コンパイル、リンキング、ラ
   ン後に上記原始テキストバッファ、コードテーブル、リ
   ンクテーブル、レキシカル増分のテーブルが全て仮想メ
   モリ内にセーブされる変更タグに対する参照を伴い、上
   記原始テキストバッファの行の各々について１つのエン
   トリを備えるクリーンラインテーブルを生成し、上記エ
   ントリがどれ程の後続行が変更されなかったかの表示を
   含み、上記走査がクリーンラインテーブルに対する参照
   を伴い、上記コンパイルステップがコードを生成して上
   記コードテーブルを上記トークンリスト内の実行可能文
   から構成し、上記トークンリスト内の宣言文から記号表
   を生成し、記号テーブル内の各エントリが上記宣言文の
   一つに対応する請求項２７の方法。 ２９、ａ）原始テキストのモジュールをエディットし、
   エディットされた原始テキストを原始テキストバッファ
   内にストアし、 ｂ）上記原始テキストバッファをコンパイルしてメモリ
   内にコードテーブルをつくりだし、ｃ）上記コードテー
   ブルをリンクしてメモリのバッファ内にコードイメージ
   をつくりだし、ｄ）コードを上記コードイメージを介し
   てランし、 ｅ）上記コンパイルステップが上記原始テキストの各行
   を走査してコードを生成し、上記原始テキストの実行可
   能文に対するコードテーブルを構成して上記原始テキス
   ト内の宣言文用の記号テーブルを生成し、 ｆ）上記リンキングステップが ｉ）上記リンクテーブル内のエントリが上記コードテー
   ブルにより必要とされ供給される要素の識別とロケーシ
   ョンを含むメモリ内にリンクテーブルを生成し、 ｉｉ）上記リンクテーブル内に必要とされるか供給され
   る上記要素どうしを突合わせてリンクリストを生成する
   、段階を含み、 ｇ）上記コンパイル、リンキング、ランステップの完了
   後に、上記リンクテーブルとリンクリストをメモリ内に
   セーブしてもう一つのエディットステップ後に再使用す
   る、ステップより成るリンキング方法。 ３０、前記リンクリストが必要とされかつ供給される前
   記突合せられた要素の各一つに対するエントリを含み、
   前記エントリの各々が、エディティングの現在のステッ
   プの前に前記要素が存在するか否かを示す使用タグを有
   し、前記使用タグが指示する前記エントリの全てに対し
   て、エントリが前存在し、リンキングステップで前記エ
   ントリを再使用することを特徴とする請求項２９記載の
   方法。 ３１、上記コンパイル、リンキング、ランのステップの
   各々が停止されエラーが発見された場合に上記ステップ
   のシーケンスを完了することなくエラー表示を戻す請求
   項２９の方法。 ３２、ａ）原始テキストのモジュールをエディットし、
   エディットされた原始テキストを複数の行として原始テ
   キストバッファ内にストアし、各行が先の上記モジュー
   ルエディットステップ以後変更したかどうかを表示する
   関連変更タグを備え、 ｂ）上記原始テキストバッファをコンパイルしてメモリ
   内にコードテーブルを生成し、 ｃ）上記テーブルをリンクしてメモリ内のバッファ内に
   コードイメージを生成し、 ｄ）コードを上記コードイメージを介してランし、 ｅ）上記コンパイルステップが上記原始テキストの各行
   の表示を走査してコードを発生し、上記原始テキストの
   実行可能文用の上記コードテーブルを構成し、上記原始
   コード内の宣言文用の記号表を生成し、記号表内の各エ
   ントリが上記宣言文の一つに対応し、 ｆ）上記リンキングステップが、上記リンクテーブル内
   のエントリが上記コードテーブルにより必要とされるか
   又は供給される要素の識別とロケーションを含むリンク
   テーブルをメモリ内に生成し、上記リンクテーブル内に
   必要とされるか供給される上記要素どうしを突合せて上
   記ランステップ内で使用されるリンクリストを生成し、
   上記変更タグを介して上記エントリの各々とリンクリス
   トが再使用できるかを判断チェックすることを含み、 ｇ）上記コンパイル、リンク、ランのステップの完了後
   、上記リンクテーブルとリンクリストをメモリ内にセー
   ブして別のエディットステップ後に再使用する、ステッ
   プを含む 原始コード開発方法。 ３３、上記コンパイル、リンク、ランのステップの各々
   が停止されエラーが検出された場合に、上記ステップの
   系列を完了することなくエラー表示を戻し、上記コンパ
   イルステップが上記原始テキストを走査して、各トーク
   ンが一行内の原始テキストのレキシカル増分を表わすト
   ークンリストを生成し、上記リンクリストが必要とされ
   供給される上記突合わされた要素の各々に対するエント
   リを含み、上記各エントリが現在のエディットステップ
   前に上記要素が存在したかどうかを示す使用タグを有し
   、上記使用タグがエントリが先に存在したことを表示す
   る上記エントリの全てにおいて上記エントリを上記リン
   キングステップ内で再使用する請求項３２の方法。 ３４、ｉ）上記リンクテーブル内のエントリがコンパイ
   ラによりつくりだされたコードテーブルにより必要とさ
   れるか又は供給される要素の識別とロケーションを含む
   リンクテーブルをメモリ内に生成する手段と、 ｉｉ）上記リンクテーブル内に必要とされるか又は供給
   される上記要素どうしを突合せる手段と、 ｉｉｉ）上記リンクテーブルとリンクリストをメモリ内
   にセーブして別のエディットステップ後に再使用し、上
   記コンパイルの完了後にリンク又はランする手段と、 から成るコードリンクシステム。 ３５、上記リンクテーブルのエントリが上記要素の各々
   につき、上記要素が先に存在したかどうかを示す使用タ
   グを含みエントリが先に存在したことを上記使用タグが
   示すエントリの全てについて上記エントリが上記リンク
   手段内に再使用される請求項３４のシステム。 ３６、ａ）原始テキストのモジュールをエディットし、
   エディットされた原始テキストを原始テキストバッファ
   内にストアする手段と、 ｂ）上記原始テキストバッファをコンパイルしてメモリ
   内にコードテーブルを生成する手段と、 ｃ）上記コードテーブルをリンクしてメモリのバッファ
   内にコードイメージを生成する手段と、 ｄ）コードを上記コードイメージを介してランする手段
   と、 から成り、 ｅ）上記コンパイル手段が、上記原始テキストの各行の
   表示を走査し実行可能文の上記コードテーブル用コード
   を生成し宣言文用記号テーブルを生成する、 請求項３４のシステム。 ３７、原始コードをコンパイルする際に増分依存性解析
   を実行する方法において、 ａ）エディタを用いて複数の原始テキストバッファのメ
   モリ内に複数の行としてストアされる複数の原始テキス
   トのモジュールをエディットし、 ｂ）上記バッファがメモリ内にある間に上記複数の原始
   テキストバッファに対して依存性解析を実行し、上記依
   存性解析が変化した行内の上記バッファの各々に上記バ
   ッファの他のものの内部の文に依存する文を発見してコ
   ンパイルされなければならないバッファを選択し、 ｃ）上記選択された原始テキストバッファを増分的にコ
   ンパイルして複数のコードテーブルを生成又は更新し、 ｄ）上記コードテーブルをリンクしてバッファ内にリン
   クテーブルを生成し、 ｅ）上記コードテーブルとリンクテーブルからのコード
   をランする、 ステップより成る前記方法。 ３８、別のエディットステップ後に再使用すべく上記原
   始テキストバッファ、コードテーブル、リンクテーブル
   をメモリ内にセーブするステップを含み、上記複数の原
   始テキストバッファの各々のラインが関連する変更タグ
   を有し、先のエディットステップ以後原始コードが変更
   されたかどうかを表示し、上記コンパイルが実行文のコ
   ードテーブル用コードを生成し、宣言文用にメモリ内に
   記号テーブルをつくりだし、記号テーブル内の各エント
   リが上記宣言文の一つに対応するようになった請求項３
   ７の方法。 ３９、ａ）原始テキストのモジュールをエディットし、
   エディットされた原始テキストを原始テキストバッファ
   のメモリ内に複数の行としてストアし、各行が先のモジ
   ュールエディットステップ以後変化したかどうかを表示
   する変更タグを備え、 ｂ）上記バッファがメモリ内にある間上記複数の原始テ
   キストバッファ上に対する依存性解析を実行し、上記依
   存性解析が変更した行の上記バッファの各々に上記バッ
   ファの他のものの文に依存する文を発見することによっ
   てコンパイルすべきバッファを選択し、 ｃ）上記原始テキストバッファをコンパイルしてコード
   テーブルをメモリ内に生成又は更新し、 ｄ）上記コードテーブルをリンクしてメモリのバッファ
   内にリンクテーブルをつくりだし、ｅ）メモリのバッフ
   ァ内の上記コードテーブルとリンクテーブルからのコー
   ドをランし、 ｆ）上記コンパイルステップがコードを生成して上記コ
   ードテーブルを実行可能文から構成し、記号テーブルを
   メモリの上記原始テキストバッファ内の宣言文から生成
   し、 ｇ）上記リンクステップが上記リンクテーブル内の各リ
   ンクが上記コードテーブルにより必要とされるか又は供
   給される要素の識別とロケーションであるようなリンク
   テーブルをメモリ内に生成し、上記リンクテーブル内で
   必要とされるか供給される上記要素どうしを突合せる、 ステップより成る原始コード開発方法。 ４０、上記原始テキストバッファ内の各行が上記行が変
   化したかどうかを示す変更タグを備え、上記スキップス
   テップが上記変更タグをチェックし、上記原始テキスト
   バッファ、コードテーブル、記号テーブル、およびリン
   クテーブルが全て上記コンパイル、リンク、ランステッ
   プ後にメモリ内にセーブされ、上記原始テキストバッフ
   ァの各ラインにつき一つのエントリを有するクリーンラ
   インテーブルを生成し、上記エントリがどれ程の後続行
   が変更されていないかを表示する請求項３９の方法。 ４１、ａ）原始テキストバッファ内に複数の行としてス
   トアされる原始テキストのモジュールをエディットし、 ｂ）上記原始テキストをコンパイルしてコードテーブル
   を作成し、上記コンパイルステップが、 ｉ）上記原始テキストバッファを走査して上記原始テキ
   ストの行に対するレキシカル増分のテーブルを生成し、
   もしレキシカル増分を含む原始テキストの行が上記エデ
   ィットステップ中に変更していなければ、上記走査にお
   いて上記レキシカル増分をスキップする、コードコンパ
   イル方法。 ４２、上記原始テキストバッファの各行が原始テキスト
   の行が変更したかどうかを示す関連変更タグを有し、上
   記原始コードの各行につき上記行のロケータと同行に続
   くクリーンラインの数の表示を備えるテーブルエントリ
   を含むディスクリプタテーブルを生成し、上記ディスク
   リプタテーブルをチェックしてクリーンラインの数が上
   記セマンティック増分の行数よりも大きいかどうかを見
   るステップを備える請求項４１の方法。 ４３、ａ）原始テキストバッファ内に複数の行としてス
   トアされる原始テキストのモジュールをエディットし、 ｂ）上記原始テキストバッファをコンパイルして一つの
   コードテーブルを生成し、 ｃ）上記コードテーブルをリンクして一つのリンクテー
   ブルを生成し、 ｄ）上記コードテーブルとリンクテーブルを介してコー
   ドをランし、 ｅ）上記コンパイルステップが ｉ）上記原始テキストバッファを走査して上記原始テキ
   ストの行に対応するレキシカル増分のテーブルを生成し
   、もしレキシカル増分を含む原始テキストの行が上記エ
   ディットステップ中に変化していなければ、上記走査に
   おいて上記レキシカル増分をスキップし、 ｆ）上記リンクステップが上記リンクテーブル内の各エ
   ントリが上記コードテーブルにより必要とされるか又は
   供給される要素の識別とロケーションを含むリンクテー
   ブルを生成し、上記リンクテーブル内で必要とされるか
   又は供給される上記要素どうしを突合せることを含む、
   原始コード開発方法。 ４４、上記原始テキストバッファ内の各行が原始テキス
   トの行が変更したかどうかを示す関連変更タグを備え、
   上記原始テキストの各行につき上記行のロケータと、同
   行に続くクリーンラインの数の表示を備えるテーブルエ
   ントリを含むディスクリプタテーブルを生成し、上記デ
   ィスクリプタテーブルをチェックしてクリーンライン数
   がセマンティック増分の行数よりも大きいかどうかを見
   るステップを含む請求項４３の方法。 ４５、ａ）各モジュールにつき複数の別個の原始テキス
   トバッファのうちの一に複数の行としてストアされる複
   数の原始テキストモジュールをエディットし、 ｂ）上記原始テキストバッファをコンパイルして各々が
   一つの原始テキストバッファに対する複数のコードテー
   ブルを生成し、 ｃ）上記コードテーブルの各々をリンクしてリンクテー
   ブルを生成し、 ｄ）上記コードテーブルとリンクテーブルを介してコー
   ドをランし、 ｅ）上記コンパイルステップが上記原始テキストバッフ
   ァの各々につき、 ｉ）上記原始テキストバッファを走査して上記原始テキ
   ストの行に対応するレキシカル増分のテーブルを生成し
   、もしレキシカル増分を含む原始テキストの行が上記エ
   ディットステップ中に変更していなければ、上記走査に
   おいてレキシカル増分をスキップするようになった、 原始コード開発方法。 ４６、上記原始テキストバッファの各々につき、上記原
   始コードの各行につき上記行のロケータと同行に続くク
   リーンラインの数の表示を備えるテーブルエントリを含
   むディスクリプタテーブルを生成し、上記ディスクリプ
   タテーブルをチェックしてクリーンラインの数がセマン
   ティック増分の行数よりも大きいかどうかを見るステッ
   プを含む請求項４５の方法。 ４７、上記コンパイリングが、上記原始テキストバッフ
   ァの各々について上記レキシカル増分の宣言文用の記号
   テーブルをつくりだし、記号テーブル内の各エントリが
   上記宣言文の一つに対応し、上記複数の別個の原始テキ
   ストバッファ、コードテーブル、リンクテーブル、およ
   びレキシカル増分テーブルが全て仮想メモリ内に維持さ
   れ、上記複数の別個の原始テキストバッファ、コードテ
   ーブル、およびレキシカル増分テーブルが上記ランステ
   ップ後に全てセーブされ、もう一つのエディットステッ
   プ後に再使用される請求項４５の方法。 ４８、ページングされる仮想メモリと、揮発性メモリ非
   揮発性メモリとを有し、上記揮発性メモリが上記非揮発
   性メモリよりもずっと高速のアクセスを有する仮想メモ
   リシステムの管理方法において、 ａ）仮想メモリ内に、種々の大きさで、その大きさにか
   かわりなくデータがインターリーブされないように上記
   仮想メモリの別々のページ上にストアされる複数の別個
   のデータモジュールをストアし、 ｂ）各々が上記データモジュールの一つもしくはそれ以
   上に対して一定の処理を実行する複数の別個の処理フェ
   ーズ用コードを仮想メモリ内にストアし、 ｃ）上記データモジュールの少なくとも一つのページと
   上記コードのページを少なくとも上記処理フェーズの一
   つの間、上記非揮発性メモリから揮発性メモリへとスワ
   ッピングして上記処理フェーズの各々を実行し、 ｄ）上記処理フェーズの各々が実行された後に上記デー
   タモジュールを配分しなおして、データをインターリー
   ブせずに上記モジュールをページ内に維持する、 ステップより成る前記方法。 ４９、上記別個のフェーズの各々に対するコードが、そ
   の大きさにかかわりなくデータをインターリーブさせず
   に上記仮想メモリ内の別個のページ上にストアされる請
   求項４８の方法。 ５０、原始コード開発プログラム内に使用され、上記デ
   ータモジュールが原始コードのモジュールを含み、上記
   処理フェーズがエディット、コンパイル、リンク、ラン
   を上記原始コードに対して行う請求項４８の方法。 ５１、上記コンパイルとリンクステップが上記原始コー
   ドから目的コードを生成し、上記目的コードが上記モジ
   ュールの一つに維持され、上記目的コードを含む上記モ
   ジュールの一つが上記処理フェーズ中に上記不揮発性メ
   モリ内のファイルに書込まれず、データモジュールが、
   上記原始コードの各モジュールについて、別個のモジュ
   ール、ディスクリプタテーブル、トークンテーブル、記
   号テーブル、およびコードストリングのテーブルを備え
   、上記揮発性メモリが上記揮発性メモリシステム内の実
   メモリであって、上記不揮発性メモリがディスクメモリ
   である請求項５０の方法。 ５２、ページングされる仮想メモリと、実メモリと、デ
   ィスクメモリを有する仮想メモリシステムを有するコン
   ピュータを使用する原始コード開発プログラムを実行す
   る方法において、 ａ）原始コードテキストモジュールを備える複数の別々
   のデータモジュールをエディットし、各モジュールがそ
   の大きさにかかわりなくデータをインターリーブせずに
   仮想メモリ内の別々のページ上にストアされ、 ｂ）仮想メモリ内に上記開発プログラムの別個の複数の
   処理フェーズ用のコードをストアし、上記処理フェーズ
   が上記エディットと共にコンパイル、リンクのフェーズ
   を備え、同フェーズが各々上記データモジュールの一つ
   もしくはそれ以上に対して処理を実行し、 ｃ）上記データモジュールの少なくとも一つのページと
   上記コードのページを、少なくとも上記処理フェーズの
   少なくとも一つの間、上記実メモリへ移動させて上記処
   理フェーズを実行し、 ｄ）上記データモジュールとテーブルを上記処理フェー
   ズが実行された後に配分しなおして上記モジュールとテ
   ーブルの各々をデータをインターリーブさせずにページ
   内に維持する、ステップよりなる前記方法。 ５３、上記別個のフェーズの各々のコードが上記仮想メ
   モリ内の別々のページ上に、その大きさにもかかわりな
   く、データをインターリーブさせずにストアし、上記処
   理フェーズが、それぞれ仮想メモリ内のページ上に、デ
   ータをインターリーブさせずにストアされるデータモジ
   ュールの各々と関連する複数のテーブルを生成するエデ
   ィット、コンパイル、リンクのステップを含み、上記処
   理フェーズが上記原始コードから目的コードを生成する
   請求項５２の方法。 ５４、ページングされる仮想メモリと、実メモリと、デ
   ィスクメモリを備える仮想メモリシステムを有するコン
   ピュータを使用する原始コード開発プログラムを実行す
   る方法において、 ａ）仮想メモリ内に原始コードテキストモジュールを含
   む複数の別個のデータモジュールをストアし、上記モジ
   ュールが可変の大きさで、それぞれその大きさに関わり
   なくデータをインターリーブさせずに上記仮想メモリの
   別々のページ上にストアされ、 ｂ）それぞれが上記データモジュールの一つもしくはそ
   れ以上に対して一定の処理を実行する上記開発プログラ
   ムの複数の別々の処理フェーズに対するコードを仮想メ
   モリ内にストアし、 ｃ）上記データモジュールの少なくとも一つのページと
   上記コードのページを少なくとも上記処理フェーズの少
   なくとも一つの間、上記実メモリに移動して上記処理フ
   ェーズを実行し、 ｄ）上記データモジュールを処理フェーズが実行された
   後に配分しなおして、データをインターリーブさせずに
   上記モジュールをページ内に維持する、 ステップより成る前記方法。 ５５、上記別々のフェーズの各々に対するコードが上記
   仮想メモリ内に、その大きさにかかわりなく、データを
   インターリーブさせずに、別々のページ上にストアされ
   、上記処理フェーズがエディット、コンパイル、リンク
   を含むようになった請求項５４の方法。 ５６、上記処理フェーズが上記原始コードから目的コー
   ドを生成する請求項５４の方法。５７、データモジュー
   ルが上記原始コードの各モジュールにつき、別々のモジ
   ュールとして、ディスクリプタテーブルと、トークンテ
   ーブルと、記号テーブルと、コードストリングテーブル
   とを備える請求項５４の方法。