JPH03208187A - 拡張グラフィック機能を与える方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は全体として、コンピュータ処ｌｌ、殊ニ、ホス
トプロセソサとグラフィソクブ１コセソサを共に備える
システム用のソフトウェアインターフェースに関する。

〔従来の技術〕

今日の、グラフィンクディスプレイを使用するコンピエ
ータシステムは、相異なる一連のアーキテクチャをイ丁
している。システムによってはホストプロセソサとディ
スプレイコントローラを備えるものがある。これらは本
質上、ハードヮイアド・ビノ１・マップシステムであっ
て、ホストプロセソサが全てのグラフインク処理を実行
することが要求される。しかし、かかるシステムの欠点
は、解像度の如き図形に課される要求が厳しくなるにつ
れて、ホストプロセソサに対する処理上の負担もまた大
きくなり、その結果、処理速度が低下することである。

ディスプレイコントローラに代わる選択肢として、他の
システムではグラフィンク処理の任務をグラフィノク処
理サブシステムに委ねているものがある。かかるシステ
ムにはグラフインク機能の実行を専らハーハウエアが行
うという形に依存しているものもある。その他のグラフ
ィンク処理サブシステムはプログラルブルなグラフイン
クプロセッサを使用して、プログラマが機能性を追加で
きるようにしたものがある。

グラフィックブロセソササブシステムは高い解像度と高
速な実行を可能にするけれども、かかるシステムの多く
の欠点は、ハードワイヤド方式のものであれ、プログラ
マプルなものであれ、それらの拡張が容易でないという
点である。プログラマブルプロセソサを有するサブシス
テムでさえ、ホストシステムとそのアプリケーションプ
ログラムとを統合することは困難であり、この理由から
、それらは本質上、固定機能システムとなっている。

かかるシステムはできる限り、汎用的であろうと努めて
いるため、余りに多くの機能をサブシステムに追加する
ためにその機能性は効率性を犠牲にして得られることに
なり、いわゆる「輪廻」効果を有することになりがちで
ある。固定された組のａ能を有するか、拡張困難なシス
テムの有するもう一つの問題点は、それらが、新たなグ
ラフインクアルゴリズムが間断なく開発されているグラ
フインクソフトウエアと歩調をあわせることができない
点である。

拡張可能性の他に、グラフィソクシステムを設計する際
に考慮すべきもう一つの問題は規格化の問題である。ハ
ードウエアメーカの観点からは、グラフィンク規格の目
的は、一つのグラフインクシステムが多くのアプリケー
ションプログラムと共に使用できるようにすることであ
る。ソフトウエア開発汗の観点からは、一つの規格は一
つのプログラムがどんなグラフィソクシステム上でも走
ることができるようにしなければならない。

ＣＧＡ，ＥＧＡ、ＶＧＡの如き多くの規枯は、グラフィ
ノクサブブロセノサシステムよりも単一のプロセノサシ
ステムに対して向けられたものであり、それらはソフｌ
・ウエアとグラフィックハードウエアのインターフェー
スをとる点では或功しているけれども、ホストとグラフ
ィソクシステム間のインターフェースを提供することに
は成功していない。

そのため、効率性を落とさずに拡張可能性を提供できる
グラフィックサブシステムインターフェースに対する二
−ズが存在している。更に、拡張可能性を実現するため
の機構は、適用業務プログラマーとハードウエアメーカ
の双方が彼らの製品を対象とすることの可能なインター
フェースを提供する必要がある。上記インターフェース
は、規格化を促進するだけの十分に高い水準にあるが、
しかも処理速度を促進するに十分低いレベルになければ
ならない。

〔発明が解決しようとする課題〕　〔課題を解決するた
めの手段〕 本発明を一面から述べると、グラフインクプロセソササ
ブシステムにより実行されるが、ホストプロセソサシス
テム上を走るメインプログラムから呼出される関数を拡
張する方法に関する。上記方法の基本的なステップは、
グラフインクブロセソサにより実現されるサブプログラ
ムをつくりだし、同サブプログラムを定義することによ
ってその引き数がランタイム時にパスできるようにし、
サブプログラムをグラフインクプロセソサ用にコンパイ
ル又はアセンブリし、そのサブプログラムをグラフィソ
クブロセソサヘロードし、同しサブプログラムを先にロ
ードされた関数にリンクすることである。

本発明をもう一つの面から表現すると、ホストコンピュ
ータシステム中にグラフインクサブシステムを使用する
方法に関する。同方法は、グラフィソクサブシステムを
使用して組の原始コア関数を提供し、ホストシステムを
使用して拡張関数をグラフィソクサブシステムへダウン
ロードし、ソフｌ・ウエアインターフェースを用いてホ
ストシステムからサブシステムへ引数をパスし、更にグ
ラフインクサブシステムを用いて拡張関数とコア関数を
実行する基本的ステップより構成される。

本発明をハードウエアの面から見ると、第ｌのプロセソ
サ上で単一のソフトウエアプロヂラムを実行することに
よってそのプログラムが第２のプロセッサによって実行
さるべき指定関数を呼出すことができるようにした多重
処理コンピュータシステムである。同システムは、プロ
グラマブルホストブロセソサシステムと、プログラマブ
ルグラフィックプロセッサシステムより成り、上記ホス
トシステムは、拡張関数がグラフィソクブロセッサへダ
ウンロードされ実行可能にするソフトウェアインターフ
ェースを使用している。

本発明をもう一つの面から見ると、多重処理コンピュー
タシステムのホストブロセソサとグラフィンクプロセッ
ササブシステムとのインターフェースをとるためのソフ
トウェアインターフェースである。本発明は、種々のソ
フトウエアプログラムを含み、それらが一つのアプリケ
ーションプログラムによって提供されるデータを処理す
ることによってそのアプリケーションプログラムがグラ
フィックプロセソサにより実行される関数を呼出すこと
ができるようになっている。

〔発明の効果］ 本発明の技術的な利点は、それがグラフインクサブシス
テムを効率的であると共に容易に拡張可能とする点であ
る。

実行速度は、ソフトウエア開発者がそのアプリケーショ
ンに最も良く適合するグラフインク関数のカスタム集合
をつくりだすことができるために最適化される。本発明
のもう一つの利点は、それが、グラフィノクサブシステ
ムの機能性を拡張するために使用される方法を標準化で
きる点である。

本発咽は、ハードウエアメーカとソフトウエア開発者の
双方が対象とする彼らの製品に対するインターフェース
を提供するものである。

［実施例］ 本発明がオベレートするハードウエア環境は、−ｔＣ的
に表現すれば、ホストブロセノサとグラフィノク処理用
プロセソサの少なくとも２個のブロセノサを有する多重
処理コンピュータシステムである。かかるシステムの通
用業務は、コンピュータ支援設計（ＣＡＤ）　、デスク
トノプバプリソシング、画像処理、プレゼンテーション
グラフィソクスの如き高解像度グラフインク処理である
。本発明のハードウエア的側面は、第３図に関して詳論
する。

本発明の利点の一つは、一つの言語で書かれたメインソ
フトウエアプログラムをホストシステム上で走らせるこ
とができるが、グラフィソクプロセソサにより実行さる
べく指名された関数を呼出すことができることである。

それ故、暗黙上、本発明の場合に使用されるプロセソサ
は高水準言語でプログラミングすることが可能であり、
上記言語は両プロセッサについて同一の言語とすること
ができる。かくして、各フ“ロセフサは、それ自身の命
令集合とコンパイラと関わりあうことによって、そのプ
ロセッサの低水準言語がつくりだれさる。

本発明の基本にある思想は、グラフィックサブシステム
上で実行されるべきグラフィック関数がコア原始関数と
拡張関数の２つのグループで最もよく実行されるという
ことである。

コア原妬関数は、常時、グラフィンクプロセッサから利
用可能である。これらのコア原始関数は、少数の基本グ
ラフィックユーティリティ関数を含んでいるが、同時に
、システム初期化、グラフィンク属性制御、メモリ管理
、スクリーンクリア、カーソル操作、通信、および拡張
用の関数をも備えている。拡張関数は、必要に応してロ
ードされ、アプリケーションプログラムにより使用され
るグラフィンク関数を提供する。

本発明のソフトウエア的側面に関する以下の記述は、主
として、Ｃ言語で書かれたプログラムを対象とするもの
である。然しなから、本発明がオペレートするプログラ
ミング環境はＣ言語に固有なものではなく、本文中に解
説したプログラミング構造と関数性は任意の高水準言語
へ容易に翻訳することが可能である。

その特殊なインプリメンテーションは、本明細書を検討
すれば、当該技術分野において通常の技能を有するプロ
グラマの能力の範囲内にあると考えられる。本発明の開
示は種々の適用業務に対して今日利用可能な無数の言語
とシステムで本発明を実施するために行うものである。

また拡張関数もアセンブラ言語で容易にプログラミング
でき、その場合にはそれらは同様な方法で呼出される。

拡張関数コードがコンパイルされるのではなくアンセプ
ルされる点を除いては同じ方法が使用される。それ故、
本解説上“アセンブル”は“コンパイル”と置換するこ
とが可能である。

本発明の「ユーザ」は、一つの多重処理システムの諸々
の一部を提供する種々の人物であって差支えない。例え
ば、ユーザは上記ユーザはソフトウエア開発者で、シス
テム上で使用するために作威中のアプリケーション又は
ドライバに対する拡張関数を追加したいと欲しているも
のであってもよい。あるいは、単に他のプログラマが使
用できるようにするために拡張関数を提供するプログラ
マであってもよい．その代わりに、ボードメーカの如き
ハードウエアメーカが、グラフインクシステム用の関数
をブログラξングすることもできる．また、上記ユーザ
は、そのインターフェースを使用するプログラムを実際
に実行させる者であってもよい。更に、計算方法とプロ
グラムについて特徴的なことであるが、ユーザは、コン
ピュータ上でランする他のソフトウエアであってもよい
。

本解説の目的上、一人のユーザが多重処理システムに付
加したいと希望しているようなサブプログラムは「拡張
関数」と称することにする。メインプログラムを実行す
るシステムは「ホストブロセノサシステム」あるいは「
ホストシステム」と称することにする。そして、その際
、そのブロセノサは「ホストブロセソサ」と称する。拡
張関数がその上で実行されるシステムは、「グラフィッ
ク処理システム」であり、そのブロセソサは「グラフィ
ノクプロセノサ」又は「グラフインクシステムプロセノ
サＪ　　（ＧＳＰ）と称することにする。

第１図は、マルチブロセソサシステムと共に使用される
拡張関数をつくりだす基本的ステップを示すブロソク線
図であって、上記システムはホストプロセノサとグラフ
インクプロセフサを備えている。この方法を使用して、
コア原始関数内に含まれないグラフィンク関数を一人の
プログラマがつくりだすことができる。これらの拡張関
数はダイナミックロードモジュール（ＤＬＭ）内に組込
まれ、エンドユーザによって使用され、エンドユーザは
普通、それらを初期化時にグラフィソクシステムへダウ
ンロードする。その後、それらはホストシステム上で実
行中のメインプログラムから呼出すことができる。

上記方法の基本的ステップは、グラフィックブロセソサ
が実行するに適当なサブプロセソサを作成し、同サブプ
ログラムをその引数が実行中にパス可能なように定義し
、グラフィックプロセソサ用にコンパイルし、そのサブ
プログラムを一部リンクしてＤＬＭを形成することであ
る。最終的に、ＤＬＭはグラフィンクプロセッサへダウ
ンロードされ、そこで現存のサブプロセッサ関数とコア
原始関数とリンクされる。

ステソプ１ｌにおいて、プログラマは、グラフインクプ
ロセッサが実行するに適当な、少なくとも一つの、通常
は一連の関数を有するサブプログラムを開発する。これ
らの関数は、高水準言語又はアセンブラ言語で書くこと
ができる。本発明の特徴の一つは、拡張関数がメインプ
ログラムと同一の言語で記述でき、グラフインクプロセ
ッサ用にコンパイル又はアンセブル可能な点である。関
数定数は、本文中では、本発明を実施するために使用さ
れるその他のコンピュータプログラミンクと同様に、そ
の“コードと称することにずる。

ステンプ１２では、サブプログラムはランタイム中にサ
ブプログラム引数がグラフインクプロセッナへパスでき
るような形に定義される。ステ・ノプ１３は、メインプ
ログラム中のサブプログラムの呼出しがステソプ１２の
定義によって理解可能な形に表現されなければならない
点でステップ１２と関連している。ステップｌ２と１３
を実行するには少なくとも２つの異なる方法が存在する
。

これらの方法は、それぞれ「マルチプロセッサブロセノ
サにおけるソフトウエアパーティショニング」と「マル
チプロセソサシステム用拡張ソフトウエア関数」（権利
者テキサス・インスッルメント社、ケース番号＃　１３
６２５号、および１　１４４４３号）と題する同時係属
出願に解説されている。上記第１の出願は、拡張関数を
マルチブロセソサシステムに付加するパケット法を記述
し、第２の出願はダイレクト法について記述している。

上記両出願の開示事項は、参考のため本文中に組込んで
ある。

上記パケット法は、ユーザ側でのプログラミング労力量
が最小になるようにグラフィソクシステムを拡張できる
ように設計されている。同方法によれば、Ｃ言語のよう
な高水準言語で記述された関数をホストシステム上でラ
ン中のメインプログラムから呼出してグラフィックシス
テムによって実行することができる．事実、上記同時係
属出願中に説明されているように、バケソト法によれば
、一人のユーザがホストシステム上をラン中の一関数を
グラフインクシステムに移動させ、それを同じパラメー
タによって呼出すことができる。パケ・ノト法では、関
数の引数は、送られるデータのサイズと型を記述するバ
ケソトの形で送られる。

ダイレクト法は、バケソト法のように引数をスタソク上
に配置することはない。関数は、１個の引数と共にグラ
フィソクサブシステムにより呼出される。上記引数は、
通信バ・ノファのポインタで、そこにホストは関数の引
数をダウンロードする。

上記関数は、付加ロードを含み、同コードは、グラフィ
ソクプロセソサに対して上記バソファからパラメータを
得て、それらを局所的変数と突合わせるように指令する
。上記関数は、直接入口点法を用いてメインプログラム
から呼出される。入口点は関数の引数のフォーマノトと
復帰条件を判断する。これらの直接入口点については同
時係属の「拡張関数」出願中に詳説されている通りであ
る．ステノブ１４はグラフィソクブロセッサ用にサブプ
ログラムをコンパイルする。もし、サブプログラムがグ
ラフィノクプロセソサ用にアセンブラ言語で書かれてい
れば、ステノプｌ４はそのコードをアセンブリすること
はいうまでもない。コンパイルとアセンブルの技法は周
知の通りである。

ステソプ１　５　−　１．　７は、サブプログラムの一
部リンクとロードを喚起する。これらステップの実行は
「マルチプロセソサシステムに使用されるソフトウエア
用ロードタイムリンカゴ　（権利者テキスト・インスト
ルメント社、ケース番号＃　１４４４２号）と題する同
時係属出願中に説明されている。

本願は参考のため本文中に組込まれてある。本発明の重
要な特徴点は特定のアプリケーションプログラムの要求
に応じてランタイム時に拡張関数がロードされリングで
きる点にあるため、上記リンク・ロードのステップは、
本文中、「ダイナミックダウンローデイング」と称する
ことにする。

同時係属出願に解説されているロードタイムリンカの方
法論に従って、ステップ１５はサブプログラムを一部リ
ンクしてＤＬＭを形成する。この一部リンキングステソ
プによってサブプログラム内部の変数と関数に対する参
照が全て分解される。

サブプログラムにより外部参照されたそれらの変数と関
数は分解されないままにとどまる。ステソブ１６はＤＬ
Ｍをグラフィ・ノクシステムにロードする。ランタイム
中にロードが行われることによって、アプリケーション
プログラムは、それと共に使用されるハードウエアとは
別個に市販することができるようにすることが望ましい
。ステソプ１７は、Ｄ　Ｌ．　Ｍのリンクを完了し、サ
ブプロセッサシステム中に常駐する外部参照変数と関数
を全て分解する。これらの常駐関数はコア原価関数であ
るのが通常であろうが、本発明の方法によりロードされ
る他の拡張関数であってもよい。ソフトウエア開発段階
中において、ステップ１６とｌ７は、当該アプリケーシ
ョンが最終的に使用されることになるグラフィ・７クサ
ブシステム上でなく、特殊なテストグラフインクサブシ
ステム上で行わうことかできる。にもかかわらず、上記
テストシステムは、グラフィックプロセソサとエミュレ
ータを備えるものと想定され、上記方法は基本的に同一
である。エンドユーザは、また、ランタイム時にステッ
プ１６とｌ７を実行することもできる。

第２図は、本発明の第２の面であるホストコンピュータ
システム中にグラフィックサブシステムを使用する方法
を示す。第２図は、システムフローダイアグラムの形を
とっており、その方法のステップはそれらを実行するソ
フトウエアプログラムと関連している。全体として、第
２図は、ホストメモリ２１０とグラフインクメモリ２２
０内に共に常駐するソフトウェアより構成される。メモ
リ２１０内に常駐するソフトウェアは、通信ドライバ２
１１と、アプリケーションプログラムオブジェクトファ
イル２１４と、拡張関数オブジェクトファイル２１６で
あり、後者は以下に論ずるようにグラフインクメモリ２
２０ヘロードされる。

２１２と２１５の番号をふったコンポーネントは、アプ
リケーションファイル２１４と拡張関数ＤＬＭファイル
２１６がソースコードモジュールからコンパイルされた
ことを示す。アプリケーションファイル２１４の一つは
、メインプログラム２１３である。メモリ２２０内に常
駐するソフトウェアは、コマンド実行ルーチン２２１と
、拡張関数定義の実行可能ファイル２２６と、インクル
ードファイル２２５と、コア原始関数２２２、２２３、
２２４である。これらコンポーネントは第４図に関連し
て更に解説する。

第２図の方法は、プロセソサどうしの間の交信手段を備
える多種処理コンピュータシステム上で使用するための
ものである。従って、かかるシステムのブロソク線図で
ある第３図を参照することによって最も良く理解するこ
とができる。同システムはホストブロセソサシステム３
１０と、グラフィノクブ口セノササブシステム３２０を
共に備えている。グラフィノクシステム３２０は、グラ
フィソクブロセソサ３２１がホストブロセノサ３１１と
平行してランし、グラフィンク情報を計算・処理する一
方、ホストプロセソサ３１１が他の処理タスクを続行処
理可能なように構成することが望ましい。

ホストプロセソサ３１１は、インテル社製の８０２８６
と８０３８６ブロセノサの如き周辺制御用に最適化され
るのがｇ通である。これらのプロセソサはＤＯＳをベー
スとしたパーソナルコンピュータシステムと共に使用さ
れるが、本発明はＤＯＳオペレーティングシステムに限
定されるものではない。事実、本文中に解説した方法と
メカニズムは各種のプロセソサとオペレーティングシス
テムを使用して実施することが可能である。ホストコン
ピュータ３１１と関係するメモリ２１０は、ランダムア
クセスメモリ　（ＲＡＭ）を備えることによって、同メ
モリがその処理を指示するプログラムにアクセス可能と
することができる。

グラフィックプロセッサ３２１はグラフィソク処理用に
設計され、ブログラξング可能である。

かかるプロセッサの一例は、テキサス・インスッルメン
ト社製の３４０１０グラフィックプロセソサであって、
同プロセッサは、ディスプレイ装置制御とリフレッシュ
操作用のハードウエアと共に、グラフィンク処理用の命
令集合を拡張した３２ビットマイクロプロセッサである
。メモリ２２０はＲＡＭメモリを備えることによって、
グラフインクブロセソサ３２１が同メモリに如何にして
グラフィンク情報を処理すべきかを命令するプログラム
を格納することができるようになっている。

上記２個のプロセッサどうしの間の通信手段は、パス３
３０と通信バソファ３２３により具体化する。パス３３
０は双方向性であって、データ通路と制御ラインを提供
する。通信バソファ３２３は、両方のプロセソサシステ
ム３１０と３２０とによってアクセス可能であり、第５
図に関して詳説する。通信千段のその他のハードウエア
製作も可能であって、その場合の第一次的な要求条件は
、各ブロセッＩＪ−　３　１　１と３２１とが、通信バ
ッファ３２３にアクセスでき、同バソファ３２３が、プ
ロセソサどうしの間をハンドシェイクさせるためのメソ
セージデー夕と、呼出し中の関数を識別するための識別
空間と、コマンド引数と追加データをパスするためのデ
ータ空間より構成されていることである。第３図に示す
形は、プロセ・ツサ間の交信を可能にするための数多く
の手段のうちの一つにすぎず、その他の手段も容易に開
発することができる。更に、第３図は２プロセソサシス
テム３１０、３２０で別々のメモリ２１０と２２０を備
えたものを示しているが、通信手段は共用メモリであっ
ても差支えない。

第３図のマルチプロセソサシステムは、種々の標準的な
周辺装置群、殊に、ディスプレイ３４０、大容量メモリ
３５０、およびキーボードやマウスの如き人力装置３６
０と共に動作する。これらの人出力装置とその他のホス
トシステム３　１　０　部分間でホストシステムパス３
１４を介して適当な形で情報を交信するためにＩ／Ｏ回
路３１３を使用する。人力装置３６０によってユーザは
、ホストブロセノサシステム３１０と対話することがで
きる。ディスプレイ３４０は、周知の制御技法と人出力
技法を介してグラフインクプロセソサ３２１へ接続され
る。

再び第２図について見ると、上記方法は、ＤＬＭファイ
ル２１６からグラフィックサブシステム３２０へ拡張関
数をダウンロードし、上記拡張関数をメインプログラム
２１３から呼出し、同関数の引数をホストシステム３１
０からサブシステム３２０ヘパスし、拡張関数を実行す
るという基本的なステップより構或される。コア原始関
数は、メインプログラム２１３がサブシステム３２０内
に常駐する関数を呼出す前に、グラフインクサブシステ
ム３２０内ヘロードされる。このことによってロードと
リンクがグラフィソクプロセソサ３２１によって実行さ
れることが可能になると共に、拡張関数によって一定の
基本的なグラフィンクタスクを呼出すことが可能になる
。

第２図の方法は、一つのアプリケーションブログラ人が
実行されることになるまで行われる必要はないから、同
方法２はランタイム法と称することにする。然しなから
、上記アプリケーションプログラムは再びその拡張関数
をロードしリンクすることなく再実行可能な点を理解さ
れたい。

かくして、ステップ２２では、拡張関数ＤＬＭ２１６が
グラフィソクメモリ２２０ヘロードされ、同関数をそれ
が呼出す他の任意のコードとリンクされる。このことは
、コア関数であるダイナミ，ノクリンカ２２４によって
実現される。同リンカ２２４は、第１図に関して先に説
明したロードとリンクのステソプを実行する。

殊に、ステノブ２２のロードとリンクによって拡張関数
ＤＬＭ２１６がメモリ２２０ヘロードされ、ランタイム
時に他の拡張関数とコア原始関数にリンクされ、実行可
能ファイル２２６を形戒することが可能になる。ダイナ
旦ソクリンカ２２４は、インクルードファイル２２５の
一部である記号テーブルファイルを用いて拡張関数を含
む実行可能なファイル２２６をつくりだし、システム残
部に対する関数を識別する。本発明の特徴の一つは、拡
張関数がコードモジュール２１５としてホストシステム
３１０上で開発され、オブジェクｌ・ファイル２１６へ
とコンパイルされ、グラフイノクシステム３２０ヘダウ
ンロードできる点である。

ステップ２３２では、現在は実行可能なファイル２２６
の形をとった拡張関数がホストシステム３】０上をラン
するメインプログラム２１３から呼出される。メインプ
ログラム２１３はオブジェクトファイル２１４から導出
される実行可能ファイルである。

ステップ２４では拡張関数２２６の引数がホストシステ
ム３１０からサブシステム３２０ヘパスされる。ステノ
プ２４を実行するために、ホストシステム３１０は通信
ドライバ２１１を供給され、グラフインクシステム３２
０は、コマンド実行プログラム２２１を供給される。通
信ドライバ２１１の詳細は、第４図と第５図に関して以
下に説明するが、要するに、通信ドライバ２１１は、ホ
ス１・システム３１０とグラフインクシステム３２０間
を交信するために使用されるプログラムを格納している
。また、コマンド実行プログラム２２１も、第４図に関
して以下に説明する。通信ドライバ２１１どコマンド実
行プログラム２２１双方の働きは、バケソト法又は引数
をパスするダイレクト法の何れか一方、又はその両方を
包含する。

ステソブ２５では、グラフインクサブシステム３１０を
用いて拡張関数２２６が実行される。もし拡張関数２２
６がコアアプリケーション原始関数２２３を呼出す場合
には、ステップ２５はその原始関数の実行を伴うことに
なる。

ステノブ２６では、グラフィソクサブシステム３２０を
使用してコア原始関数２２２、２２３、２２４をザブシ
ステム３２０内ヘロードする。上記関数は常に呼出し可
能である。コア原始関数は、システム原始関数２２２と
、アプリケーション原始プログラム２２３の２つの基本
的な関数型にグループ分けすることができる。システム
原始関数２２２は、サブシステム初期化、出力、メモリ
管理、通信、および拡張の如き処理を実行するための関
数を含む。システム原始関数の後者の型、拡張関数は、
拡張関数をロードし、リンクすることに関連して使用さ
れ、ダイナミックリンカ２２４として別個に命令する特
殊プログラムを含んでいる。アプリケーション原始関数
２２３は、第１図の方法によりリンクされた後に、メイ
ンプログラム２１３から呼出して利用される。コア原始
関数２２２、２２３、２２４のインプリメンテーション
の特殊例は、“ＴＩＧＡ−３４０インターフェースユー
ザガイド″　（テキサス・インスツルメント社刊）と題
する刊行物に見ることができる。

第４図は、メモリ２１０と２２０を有する第３図のプロ
セフサ３１１と３２１の如き２個の異なるプロセノサに
ロードされる一連のソフトウエア案を示したものである
。この解説はスタソク群を使用することを対象としてい
るが、本発明の他の実施例では、１スタノク以外の構造
を使用することもできよう。その本質的な特徴は、メモ
リの一エリアが両方のプロセソサ３１１と３２１とにと
って同一に見える点である。上記構造はまた、つの共用
メモリとすることも可能であろう。メモリとメモリ内容
の共用性によって、ファンクションコールが両ブロセソ
サ３１１と３２１により容易に交信しあえ、了解可能と
なる。

全体として、第４図は、第１のプロセソサシステム３１
０にロードされアプリケーションインターフェースライ
ブラリ２１７とリンクされる、実行可能なコード形式２
１４のアプリケーションプログラムを示す。ホストシス
テム３１０は同時に通信ドライバ２１１と１スタノク４
１４を備えている。拡張関数定義２２６は、グラフィン
クシステム３２０のメモリ２２０内にロードされ、コマ
ント実行ルーチン２２１によってアクセスされる。

また、グラフィソクシステム３２０は１スタソク４２３
を備えている。第３図について説明したように、通信バ
ッファ３２３は、データをプロセソサどうしの間でパス
しあうためのスペースを備えている。引数ハンドラ４４
１ａと４４１ｂとは、拡張関数のパケソト形に関連して
使用される。

本発明のホストグラフィソクインターフェースは、アプ
リケーションインターフェース４１７と、通信ドライバ
２１１と、コマンド実行ルーチン２２１と、拡張関数を
インストールするために使用されるコア原始関数の５つ
の基本的部分から構戊される。もし関数定義のパケソト
形が使用される場合には、インターフェースの第５番目
のコンポーネントが４４　１ａと４４１ｂとして示すよ
うな引数ハンドラとなる。

アプリケーションインターフェース２１７は、ヘッダフ
ァイルとアプリケーションインターフェースライブラリ
より成る。ヘソダファイルは、コアと拡張関数の定義２
２３、２２６を参照する。

それらは同時に、コアと拡張ファンクションの呼出しを
適当な入口点呼出しにマ・ツビングしなおす。

これらの入口点呼出しは、スソテプ１２に関して上記し
たように、関数にパスされるパラメータ型に応して、ダ
イレクト又はパケソト型のものとすることができる。

アプリケーションインターフェースライブラリは、アプ
リケーションオブジェクトファイルとリンクされて、実
行可能なアプリケーションファイルを形威する。上記ア
プリケーションインターフェースライブラリは、アプリ
ケーションプログラム用の手段を提供して、情報を通信
ドライバ２１１間でパスさせる。アプリケーションによ
り行われる最初のファンクションコールは、初期化作用
である。この作用によって既にメモリ内に常駐している
通信ドライバ２１１に対してその人口点ジャソブテーブ
ルの出発点メモリをパスすることが知らされる。このテ
ーブルは、通信ドライバ２１１により提供される各通信
入口点のアドレスのリストである。一たんアプリケーシ
ョンインターフェース２１７がジャンプテーブルのアク
セスを知るや、アプリケーションにより呼出された適当
な入口点関数ヘジャンブすることが可能になる。

通信ドライバ２１１は、アプリケーションプログラム２
１２からデータを受取り、それを通信ハソファ３２３へ
送る。同バソファ３２３はグラフインクシステム３２０
ヘアクセス可能である。通信ドライバ２１１は、ホスト
システム３１０上をランする終端・ステー常駐（ＴＳＲ
）プログラムであることが望ましいが、ＴＳＲコンフィ
ギュレーションは必ずしも必要な特徴ではない。通信ド
ライバ２１１は、グラフィックシステム３１０のハード
ウエアに特有のものであるが、インターフェースをポー
タブルにすることによって異なるハードウエア向けに変
形することもできる。

通信ドライバ２１１の特性は、それが幾つかのコマンド
系列を待ち行列状態にする能力を備え、非割当バソファ
リングシステムを可能にするという点である。通信ドラ
イバ２１１により使用される通信バソファ３２３の基本
形は、第５図に示す。

基本エリアはコマンドバソファ５１０とデータバッファ
５２０であり、通信ドライバ２１１により実行されるハ
ンドシエイクルーチンと共に使用される。ポストとグラ
フィンクハードウエア間を交信するために使用される定
義済みメノセージは以下の通りである。

ＧＳＰ　ホスト間の通信メッセージ ＧＳＰ　　ＩＤＬＥ＝０．ＧＳＰはコマンドを待機中。

ＧＳＰ　　ＢＵＳｒ＝１；ＧＳＰはコマンドを実行中。

Ｇ　Ｓ　Ｐ　　ＦＩＮＩＳＩＩＥＤ＝　２　；　Ｇ　Ｓ
　Ｐはコマンドを完了した。

ＧＳＰ　　ｔｌＮＩＮＩＴ　　＝３　．ＧＳＰは初期化
されていない。

Ｇ　Ｓ　Ｉ）　　ホスト間の通信メソセージＨＳＴ　　
ＩＤＬＥ＝０；ホストはｃｓｐを待機中。

ＨＳＴ　　ＣＭＤ　　＝１；ホストはセットアソブコマ
ンドレディ状態。

ＨＳＴ　　ｆｌｌＴ＝３：ホストはＧＳＰの初期化を期
待中。

上記−ＩＮＩＴコマンドはドライバ初期中に使用される
。

再び第５図について述べると、メッセージフィールドを
使用してコマンドを次の如く処理する。

（１）　　ホストは呼出し中の関数のパラメータをデー
タバソファ内に配置する。それと同時にこの関数のコマ
ンド識別子をコマンド識別フィールド内へ書込む。この
識別子はダイレクト法又はバケソト法の何れかと、呼出
し中の関数を含むＤＬＭに対応するモジュール番号と、
Ｄ　Ｌ　Ｍ内の適当な関数を識別する関数番号とを用い
て実行中の人口点呼出しの型を指定する。その後、この
ホストはＩ｛　Ｓ　Ｔ　　Ｃ　Ｍ　Ｄメッセージをメソ
セージフィールド内にセソトする。

（２）ＧＳＰはＧＳＰ　　ＢＵＳＹをＧＳＰメソセージ
フィールド内にセントしてコマンドを実行する。

＋３１ＧＳＰはホストメッセージフィールド内のＣＯＭ
ＭＡＮＤ　　ＰＥＮＤＩＮＧをクリアして、ＧＳＰメソ
セージフィールド内にＣ　Ｓ　Ｐ　　ＦＩＮＩＳＩＩＥ
Ｄメソセジをセソトする・ （４）ホストはＣ　Ｓ　Ｐ　　ＦＩＮＩＳＩＩＥＤメソ
セージをチェノクして、それをクリアした後、なんらか
の復Ｊｉｂパラメータを読み取るか、バノファを再使用
する。

ハンドシェイクは２ワードを使用して行われる。

そのうちｌワードはホストからのメソセージに対しての
もので、もう一つはＧＳＰからのノソセジに対するもの
である。ホスｌ・はＧＳＰからのメソセージをクリアす
る働きを行い、ＧＳＰはホストメノセージをクリアする
。このことによって１メノセージ肯定応答」や「肯定応
答確認」のタイプのメソセージをやりとりする必要なく
完全なハンドシェイクが確保できる。メモリが使用され
るため、システムは１時に活動可能なコマンド待ち行列
の数に限定されない。

再び、第４図について述べると、コマンド実行ルーチン
２２１は全体としてホストシステム３１０からデータを
受取りグラフインクプロセノサ３２１に対してグラフイ
ンク処理を実行するように命ずるソフトウエアプログラ
ムである。普通の場合、コマンド実行ルーヂン２２１は
メモリ２２０のＲＡ．Ｍ内に常駐し、バヮーア・７ブ後
にロードされるが、このことは必要条件ではない．通信
ドライバ２１１と同様に、コマンド実行ルーチン２２１
は、インターフェースが異なるハードウェアシステムと
ボート接続できるように修飾することが可能である。

コマント実行ルーチン２２１は通信ドライバ２１１に対
するスレーブとしてグラフィ・７クシステム３１０上で
ランし、ホストＧＳＰハシドシェイキングのＧＳＰ側を
処理し、ホストにより送られるコマンドを受取り、それ
らがパケソト法コマンドであるかダイレクト法コマンド
であるかを判断し、それによって呼出された関数を呼出
す。グレイクトモードコマンドの場合、コマンド実行ル
ーチン２２１は、関数に対するパラメータデータの大域
的ポインタをセントアンプして、関数を呼出す。パケソ
トコマンドの場合、コマンド実行ル一チン２２１は、引
数ハンドラ４４ｌｂを呼出す。

同ハントラ４４１ｂはダイレクト法と同一の大域的デー
タポインタを使用して上記説明したようにデータを配列
しなおす。コア原始関数とアセンブリａ　３ｆｉ関数は
同一の方法で呼出すことができる。

引数ハントラ４４１ａと４４１ｂ内に含まれる引数ハン
ドラブログラムは特殊な引数をパスするプログラムで、
引数をホストシステム３１０のスタノク４１４から除去
してそれらをグラフィックシステム３２０ヘパスし、そ
れらがパスされた後にそれらをアセンブリしなおすこと
によって高水Ｙ＄Ｍ語のフォーマノトでグラフィソクシ
ステム３２０のスタノク４２３ヘブソシュできるように
するランクイムタスクを実行する。第４図の実施例では
、引数ハンドラは、システム３１０と３２０上に常駐し
、単方向通信用に設計される。然しなから、引数ハンド
ラどうしを対称形にすることｔこよって２方向パラメー
タ交換を可能にすることもできることを理解すべきであ
る。その後、各々の引数ハントラは、バケソトを再構成
して１スタノクにプソシュすると共にそれらをスタソク
から分解することの両方を実行することができよう。更
に、統合型マルチブロセソサシステムの場合、システム
内の全プロセッサについて一個の引数ハンドラが存在す
るようにすることもできよう。がくしで、第４図では、
引数ハンドラ４４１ａは通信ドライバ２１１にリンクさ
れ、スタック４１４と交信する。引数ハンドラ４４１ｂ
はコマンド実行ルーチン２２１にリンクされ、スタック
４２３と連絡する。

プログラごングの利便性上、インターフェースは一定の
インクルードファイルを備えることによって反復定義を
回避するようにすることも可能である。これらのインク
ルードファイルは次の２つのグループに分割できる。即
ち、（１）ホストシステム３］０上でランするように設
計されたソースファイル内に包含されるファイルと、（
２）グラフインクシステム３２０上でランするソースフ
ァイル内に包まれるファイル、である。第１のグループ
のインクルードファイルは、アプリケーションインター
フェース４１２の一部であり、第２のグループは、参照
番号２２５を有する第２図のグラフィノクシステム３２
０を構築するために使用される。

ホス｛・システム３１０のインクルードファイルは以下
の通りである。

ｅｘｔｅｎｄ．ｌ＋　　　拡張原始関数を呼出す。

ｇｒａｐｈｉｃｓ．ｈ　　バケソト法の場合に使用され
るデータ型を定義する。

ｔｙｐｅｄｅ４ｓ．ｈ　　インターフェースに関して使
用される構造定義用。

グラフインクシステム３２０用のインクルードファイル
２２５は以下の通りである。

ｇｓｐｃｘｔｅｎｄ．ｈ　　　拡張原始関数の外部宣言
ｇｓｐｇｌｏｂａｌｓ．ｂ　　　大域的変数全ての外部
宣言ｇｓｐｒｅｇｓ．ｈ　　　　グラフィノクシステム
レジスタの定義 ｇｓｐｇｒａｐｈｉｃｓ．ｈ　　コア原始関数全ての外
部宣言通信ドライバ２１１とコマンド実行ルーヂン２２
１に関して先に示した如く、本発明の特徴は、それがハ
ードウエア依存性であるということである。この特徴は
、一部はコア原始関数２２４の一部であるインクヮイア
リ関数により実現され、通信ドライバ２１１やコマンド
実行ルーチン２２１の修飾を要しない。上記関数によっ
て、アプリケーションプログラムはグラフィンクシステ
ム３２０の構威を切断し、ビント表現によるピクセル深
度や、水平方向と垂直方向の解像度や、グラフィックシ
ステム上のランダムアクセスメモリ量の如き情報を復帰
させることができる。その後、アプリケーションプログ
ラムはその出力をスケーリングして任意のディスプレイ
解像度にフィットさせることができる． 表Ａは２個の関数、ｇｅＬｃｏｎｆｉｇとｓｅｔ−ｃｏ
ｎｆｉｇを使用してこのハードウエア依存特徴の一実施
例である。関数ｇｅｌｃｏｎｆｉｇは、ボードとモード
に特有の情報を全て含む構造を復帰させる。ｓｅｌｃｏ
ｎｆｉｇ関数は、デフォルトグラフィックモードにパス
されるインデクスにより選択されるグラフィックモード
をセントする。その場合、ボードは次のｓｅｔ−ｃｏｎ
ｆｉｇに対する呼出しが行われるまで残留する。

ｓｅｌｃｏｎｆｉｇについて表Ａを見ると、もしｇｒａ
ｐｈｉｃｓｍｏｄｅ引数が妥当であるならば、関数は新
たなグラフィンクモードをセソトアノプし、適当なＧＳ
Ｐレジスクを初期化する。もしｉｎｉＬｄｒａ−フラグ
が真であれば、関数は作図環境を初期化する。

「コア原始関数」は、サブプロセッサシステム中に永久
的にインスｌ一一ルされ常時ロード用に利用可能な基本
的関数である。これらのコア原始関数は、システム原始
関数とアブリゲーション原始関数との２つの基本的関数
型へグループ分けできる。システム原始関数は、サブシ
ステム初期化、出力、メモリ管理、通信、および拡張の
如き処理を実行する関数を含んでいる。後者のタイプの
システム原始関数である拡張関数は、本発明の方法と関
連して使用され、以下により詳細に論ずることにする。

アブリケーシジン原始関数は、もしそれが本発明を使用
してリンクされた場合、ホスト上を走るアプリケーショ
ンプログラムから呼出されて利用される。

本発明の以下の説明は、第一義的にはＣプログラミング
言語を対象としたものであるが、本発明を実施するため
のプログラミングは、Ｃ言語に固有のものではなく、本
文中に解説したプログラξング構造と関数は任意の高水
準言語へ容易に翻訳することができる。本発明を実施す
るために必要な実際の言語とプログラムは、本発明が実
施される特定のシステムに依存する。その特定のプログ
ラムは、本発明を検討した後に当該技術分野における通
常の技能を有するプログラマの能力の範囲内にあると考
えられる。

本発明の前提は、サブプロセソサシステムはそれがその
コア原始関数とは独立にロード、リンク、ならびに使用
可能な拡張関数を備えた場合に最もよく活用できるとい
うことである。この前提に従って、本発明は、他のマル
チプロセソサシステムのプログラミング有する拡張関数
を組込む方法を提供することができる。上記方法は、何
時また何処で関数がコーディングされたかに関わりなく
、一つのアプリケーションプログラムに使用される種々
の関数をダイナミソクにリンクするソフトウエアメカニ
ズムを実装することができる。

第６図は、サブシステムプロセッサ用の拡張関数を開発
したいと欲しているプログラマの見地から本発明の方法
を図解したものである。これら拡張関数は、最終的にア
プリケーションプログラム内で呼出されてユーザに対し
て一定のタスクを実行する関数群より構威される。基本
的に、そのステソブは一組の拡張関数と、各関数に対す
るアドレス参照セクションをつくりだす。拡張関数をセ
クション参照とリンクすることによって一つのロードモ
ジュールがつくりだされ、同モジュールは、一部、現存
のコードにリンクされ、参照をランタイムに分解される
他のコードに任せることが可能になる。

本発明のリンクとロードのステップに関して、以下の記
述はこれらのタスクを実行するソフトウエアプログラミ
ングに共通な処理と構造に関するものである。殊に、リ
ンカは当該技術分野では周知のフォーマントである共通
のオブジェクトファイルフォーマソトでオブジェクトフ
ァイルをつくりだすものと想定される。このフォーマソ
１・は各モジュールがセクションと称される小さなコー
ドとデータのフ゛口・冫クを有するモジュラ−フ゛ログ
ラミングを有利にするものである。１セクションはｌオ
ブジェクトファイルの最も小さな再配置可能な単位であ
って、最終的に、それがロードされるメモリ内に隣接す
る空間を占めることになろう。

ＣＯＦＦフォーマットによれば、拡張関数を数多くの高
水準言語のうちの一つ、又はアセンブラ言語で書くこと
ができる。然しなから、ＣＯＦＦは、再配置可能な、一
部リンクされた関数モジュールをつくりだすために十分
なオブジェクトフォーマノトのただ一つの形にすぎない
ことを理解すべきである。

ステソプ１１１では、拡張関数を含むプログラムコード
のモジュールがつくりだされる。通常の場合、この関数
の集合は、如何なる関数が必要となっても特定アプリケ
ーションプログラムの指定タスクを実行することになろ
う。ステップ１１では拡張関数がコーディングされるが
、それは拡張関数がホスト上を走るアプリケーションプ
ログラムから呼出されサブプロセソサによって実行可能
なものであればどんな形でも実行することが可能である
。かかる一連の方法は、関数定義によって関数の実パラ
メータがホストからサブプロセソサヘパスされ何れの戻
り値もホストに復帰できるということを第一次的な要求
条件として活用することができよう。

かかる方法の例はパケソト法とダイレクトアクセス法で
あり、両方とも同時係属出願中に解説されている．，（
「マルチプロセッサシステムにおけるソフトウエアパー
ティショニング」、「マルチブロセ・７サシステム用拡
張ソフトウエア関数」）関数が定義された後、それらは
集められ、コンパイル又はアセンブルされて一連の共通
のオブジェクトファイルの如き一定形のロード可能なコ
ドにリンクされる。ステソプｌ１の結果の例を一つあげ
ると、■ｙｆｕｎｃｓ．　ｏｂｊと称されるファイルで
あって、＋ｗｙ−ｆｕｎｃｌとＩｌｙ−ｆｕｎｃ２の２
つの関数を含む。

本発明の利点は、拡張関数のモジュールが、それらを使
用するアプリケーションプログラムをつくりだす同じプ
ログラマによってつくりだすことができる点である。そ
のため、特定の１アプリケーションの実行中にロードさ
れて使用されるべきモジュールはそのアブリケーシヲン
により必要とされる関数を含むだけで足りる。更に、そ
の関数を呼出しそれをパラメータ化する方法は、プロセ
ッサどうしの間でのパラメータのパスに必要とされる何
れかの特殊技法に従ってプログラマが選択することがで
きる。

ステップ１１２では参照セクションがつくりだされ、ス
テップ１１ｌでつくりだされるモジュール内のそれぞれ
の拡張関数についてアドレス参照が宣言される。ステソ
ブ１１２の一例は次のプログラミングで、ｍｙ−ｆｕｎ
ｃｌ　とｍｙ−ｆｕｎｃ２の２個の関数を引用する。

；外部引用 ゜ｇｌｏｂｌ−ｍｙ−ｆｕｎｃｌ＋　−ｍｙ−ｆｕｎｃ
２；スタートセクション宣言 ・ｓｅｃｔ　　”．ＥＸＴ’ ・ｌｏｎｇ　　劃ｙ−ｆｕｎｃｌ　；モジュール内のコ
マンド数Ｏ ｌｏｎｇ　　−ｍｙ−ｆｕｎｃ２　：モジュール内のコ
マｍｏｄｕｌｅ　　　ンド数１ ・ｔｅｘ　ｔ　　　　　　　　；エンドセクションコマ
ンド数は特定命令中で定義されるべきロートモジュール
内の関数を宣言する。これは関数を引用する手段を提供
する。殊に、一つの関数のコマンド番号は同関数を呼出
すアプリケーションプログラム内のファンクションコー
ル内に組込むことができる。引用セクションは、コンパ
イル又はアセンブルされて、例えばｅｘｔ．　ｏｂｊ．
の如き共通のオブジェクトフォーマソ１・ファイルが生
成される。

ステソブ１１３では、ステソプ１１１でつくりだされた
モジュールを、ステップ１１２でつくりだされたセクシ
ョンとが一部リンクされて一つのロードモジュールが形
成される。このリンクステップはモジュール内の関数間
に引用値を分解するが、上記モジュールは、モジュール
外部の関数を引用する又は同関数によって引用される関
数を含むことができることを理解されたい。もし外部引
用が存在すれば、そのリンキングは部分的にしかすぎず
、その引用は未解決であることになる。

部リンクされたファイルは配置替え情報と記号情報を備
えていなければならない。一部リンキングは出力セクシ
ョンの形成に関係し、配分には関係しない．割当て、束
縛、メモリ指令は全て次のリンクでのランタイム時に実
行される。

一部リンキングの例は、モジュールがコア原始関数を呼
出す関数を有する場合である。未解決の引用は、サブプ
ロセッサシステム内に既にストアされているモジュール
の外部にあり、引用関数はそれに対するアドレスを有し
ない。ステップ１１３で使用されるリンカの本質的特徴
は、それがランタイムまで解決不可能な呼出しを関数に
対して持たせることができるという点である。第２図、
第３図、第４図に関して以下に説明するように、関数が
サブブロセソサシステムのメモリ内にロードされる時、
これらの引用は解決される。ダイナミソクリンカはアド
レスをコード内にインサートすることによって呼出しを
解決する。

以下は、リン力を一個有するコンピュータを使用してス
テノプ１１３を実行するためのコマンドの一例である。

その場合、ステップ１１１中で定義された２つの関数と
、ステノプ１１２でつくりだされたセクションとがリン
クされることになっている。一例として、リンカは以下
のコマンドで呼出される。

ｌｉｎｋ　ＬＯＡＤ．　ＭＯＤ　ａｙｆｕｎｃｓ．　ｏ
ｂｊ　ｅｘｔ．　ｏｂｊその粘果はＬＯＡＤ．　ＭＵＤ
と題する再配置可能なロードモジュールで、ステップ１
１１と１１２でつくりだされたオブジェクトモジュール
の組合せである。

その後、ロードモジュールは一連の相異なる方法で使用
できる。それが本発明の利点の一つである。例えば、モ
ジュールは他のモジュールへ供給され、モジュールをメ
インプログラムにリンクしたりサブシステムにロードし
てコア原始関数とリソクさせることができる。その代わ
り、同じユーザはロードモジュールを使用して、マクチ
プロセッサシステム用のアプリケーションプログラムを
開発することができる。かくして、第４図に示すように
、次のステップはｌ１４ａとなり、モジュールをサブシ
ステムにロードしたり、あるいはステップ１１４ｂとな
ってモジュールをアプリケーションプログラムへリンク
させたりすることができる。エンドユーザの観点からす
ると、ロードモジュールは一部リンクされた状態でユー
ザのホストシステムメモリ内に常駐し、最終的にサブプ
ロセフサシステムへダウンロードされ、第２図に関して
以下に説明するように、特定のアプリケーションプログ
ラムと共に使用することができる。

第２、３、および７図は、本発明の第２の面であるコン
ピュータを使用してマルチブロセソサシステム内に拡張
関数をロードしダイナミックにリンクする方法を示した
ものである。上記リンキングは拡張関数がつくりだされ
る時に拡張関数が呼出すその他の関数のアドレスが未知
であるという意味でグイナミノクである。これらのアド
レスは、アプリケーションプログラムが走るまで未知の
状態にある。

本発明のダイナミソクダウンロ一ド法のステップは、第
７図に示す。一般的にいって、上記方法は、ホストプロ
セッサシステム３１０をサブプロセッサシステム３２０
へ一組の拡張関数をロードし、この時未解決な拡張関数
の引用をリンクするステップより構成される。

まづ、ステソプ１４１−４３では、グイナミソクリンカ
２２４はそれが必要とする２個のファイル、即ち、記号
テーブルファイル２２５と、先にリンクされたオブジェ
クトファイル２１６のように現在メモリ２１０内にス１
・アされたロードモジュール２１５とが存在することを
チェソクする。

記号テーブルファイル２２５は、コア原始関Ｂ２２２内
の記号テーブル関数によって維持され、サブプロセソサ
システム３２０のメモリ２２０に既にロードされた関数
と、それぞれの関数について関連するメモリアドレスを
表現する記号情報を格納する。かくして、もし先につく
りだされたロードモジュールが使用される場合には、そ
れらはロードされ、それらの記号とアドレスは記号テー
ブルファイル２２５内に配置される必要がある。

かくして、本発明の方法を実行するに先立ち、記号テー
ブルファイル２２５は、ロードモジュール２１５外部の
関数を表わす。即ち、それらはロードモジュール２１５
内で定義されない。このタスクを実行する記号テーブル
関数の例は次のＣ言語関数である． ｉｎＬ　ｃｒｅａｔｅ．．．ｓｙｍｂｏｌ−ｆｉｌｅ（
ｎａｍｅ）ｃｈａｒ　ｆａｒ　”　ｎａｍｅ　； 但し、ｎａｍｅは関数を含むファイルの通路名である。

記号とそれらの各々の絶対アドレスは、それらが続くロ
ーダの呼出し中にアクセスできるような具合にストアさ
れる． 記号テーブルファイル２２５のインテグリティを確保す
るために、ダイナミソクリンカ２２４は、コマンド実行
ルーチン２２１に対して制限呼出しを実行し、上記ルー
チン２２１は特殊でコアシステム原始関数を使用してサ
ブプロセソサシステムメモリ２２０内に先にインストー
ルされたモジュールの状態について間合わせる。このス
テソブの目的は、かかるモジュールと記号テーブルファ
イル２２５内のモジュール記号との間の畢離が存在する
かどうかを判断することである。もし存在すれば、記号
テーブルファイル２２５は、それに従って調節される。

もし存在しなければ、エラーメノセージがユーザに対し
て伝達される。

ステノプ１４４では、ダイナ旦ソクリンカ２２４は、所
望のロードモジュールオブジェクトファイル２１６に対
して必要とされるメモリサイズを取得ずる。上記リンカ
はコアシステム原始関数から特殊な割当て関数を呼出し
てロードモジュールを格納するに十分な大きなのメモリ
ブロンクを取得する。かかる割当て関数を表わすコマン
ドの例は以下の通りである。

ｌｏｎｇ　ａｌｌｏｃ　（ｓｉｚｅ） ｌｏｎｇ　ｓｉｚｅ　； 但しｌｏｎｇ　ｓｉｚｅとはバイト表現によるモジュー
ルの大きさである。この関数は指定サイズのサブプロセ
ソサシステムメモリ２２０のフ゛ロフクを割当て、ポイ
ンタを復帰させる。

ステップ１４５−４６において、ダイナミックリンカ２
２４は、サブブロセソサシステム３２０により実行され
るオブジェクトファイルを実行可能なイメージファイル
２２６内へ結合するというその第一次的な任務を実行ず
る。ダイナミソクリンカ２２４が実行可能ファイル２２
６をつくりだすと、オブジェクトファイル２１６をメモ
リ２２０ヘロードし、外部引用を解決する。そうする際
、上記リン力は、アプリケーション原始ファイル２２３
と共にロードファイル２１６を入力として受取る。殊に
、グイナミソクリンカ２２４は所望のＣＯＦＦセクショ
ンをサブシステムのメモリマップ内へ再配置する。先に
未解決の外部関数即ち、ロードモジュール２１５内で定
義されなかった関数に対する参照を解決するために、ダ
イナミソクリンカ２２４は記号テーブルファイル２２５
を参照してその関数を表わす記号を発見する。その後、
ダイナミソクリンカ２２４はロードモジュール２１６内
の引用を引用された関数のアドレスと置換する。このよ
うにして、ダイナミックリンカ２２４は、ロードモジュ
ール２１６の引用セクション内にリストされた全ての拡
張関数をサブプロセソサシステム３２０内にロードされ
たその他のコードにリンクする。同様にして、ダイナミ
ックリンカ２２４はロードモジュール２　１　６内で定
義された関数を表わす記号を記号テーブルファイル２２
５へ付加することによって、続い“ζインストルされた
ロードモジュールがロードモジュール２１６ヘアクセス
できるようになっている。

概して、ステップ１４６をリンクするプログラミング方
法は、一プロセソサシステムの場合に使用されるその他
のダイナミソクリンクツールのそれと同様なプログラ鑓
ング手法を使用する。いうまでもなく、それらのシステ
ムは本発明によって行われるような２個のプロセッサシ
ステムどうしを関連づけるという余分な任務を必要とし
ない．ステップ１４７でロードモジュール２１６がメモ
リ２２０内にロードされ終った後に、ダイナミックリン
カ２２４は、ロードモジュールの参照セクション内の情
報を活用してモジュール内の関数がアプリケーションプ
ログラム２１２から呼出すことができるようにする。殊
に、グイナミソクリンカ２２４はコマンド実行ルーチン
２２１により使用される拡張関数アドレスを表わすテー
ブル（図示せず）を構築する。

ステップ１４８では、グイナミソクリンカ２２４は、現
在、アプリケーションプログラムによって必要とされな
い関数でメモリ２２０ヘロードされたものが存在するか
どうか判断する。もし存在するならば、これらの関数は
活動中のメモリから廃棄される． 最後に、ステソブ１４９において、ダイナミソクリンカ
２２４は、モジュール識別子をアプリケーションプログ
ラムへ復帰させる．上記モジュール識別子はアプリケー
ションプログラム２１２から拡張関数に対する呼出しに
際して使用され、それらの関数を呼出す。例として、モ
ジュール識別子は第１図に関して論じた参照セクシヲン
中のモジュール数と同一とすることができる。ステソブ
１４８は一個以上のモジュールがサブプロセッサシステ
ム３２０上にロードされることになっている場合に有益
である。

第２図に示すグイナミソクリンキングは、インストール
プロセスの一部であって、その間に、ユーザはコンピュ
ータを使用してインストールプロシージャを呼出し、同
プロシージャ自体は今度はグイナミソクリンカ２２４を
呼出すことが望ましい。インストール命令の例はＣ言語
で書かれた次の関数である。

ｉｎｔ　ｉｎｓｔａｌｌｌｍ（１＋＋−ｎａｎ＋ｅ）ｃ
ｈａｒ　ｆｏｒ　”ｌｍ−ｎａｎ＋ｅ　；但し、ｌｍ−
ｎａｍｅはロードモジュール名である。上記ステソプに
続いて、この関数は、ロードモジュール名により指定さ
れるロードモジュールは何れもインストールしてモジュ
ール識別子を復帰させる。

ひとたびロードモジュール２１６がダウンロードされリ
ンクされると、マルチプロセッサシステムのランタイム
処理は２個のプロセッサシステム間の一定種類のパラメ
ータパス手法の使用を喚起する。第１図に関して上記し
た如く、このことは引数データと復帰データがプロセン
サシステム間を転送され両プロセッサ３１１と３２１と
によって理解できるように設計された特殊関数定義と呼
出しと共にプログラミング段階で行うことができる。

上記した如く、一個以上のロードモジュール２１６がロ
ード可能で、その各々はそれ自身のモジュール識別番号
を受取る。ダイナミックリンカ２２４をプログラミング
することによって、モジュールと同モジュール内の拡張
関数とを共に識別する識別子を復帰させることができる
。識別を可能にする一つの方法例は、それがインストー
ルされる順序に従って各ロードモジュール２１５にモジ
ュール番号を付与することである。この識別子は、モジ
ュール内の一関数がプログラムから呼出されることにな
っている場合には常に、第６図のステップ１１２で付与
されたような関数番号をモジュール識別子に接続するこ
とによって使用される。Ｃ言語の場合、このことはピン
ト毎のＯＲ演算子によって実行することができる。その
後リンキングは全てのロードモジュールを含むことにな
ろう。

本発明の代替例では、拡張関数ではなく、アプリケーシ
ョンプログラムにより使用される割込みサービスルーチ
ンがマルチブロセソサシステムに追加される。第１図に
示す方法は、ロードモジュールが割込みサービスルーヂ
ンを格納する点を除いては本質上同一である。後者は、
サブシステムの割込みハンドラを介して割込みを受ける
とすぐ呼出される。ステソプ１２では、モジュール内の
全ての割込みサービスルーチンについて２つの人口を含
む参照セクションがつくりだされる。これらの人口は割
込みサービスルーチンに対するアドレス参照と、同ルー
チンの割込み数を指定する。

例えば、＋＊ｙ−ｉｎｆｌとｍｙ−　ｉｎｆ２の２個の
ルーチンがステンプ１１のモジュール内に格納されてい
る場合、セクション宣言は以下のようになろう。

；外部参照 ・ｇｌｏｂＬｍｙ−ｉｎｆｌ，　−ＩＩＩｙ−ｉｎｆ２
；スタートセクション宣言 ・ｓｅｃｆ　　”．ＩＳＲ”　； ｏｎｇ　　−鎮ｙ−ｉｎｆｌ ｏｎｇ　　　　−ｍｙ−ｉｎｆｌ ｏｎｇ　　　１　　　；割込み数１ ０ｎｇ　　−ｓ＋ｙ−ｉｎｆ２ ｏｎｇ　　　２　　　；割込み数２ ・ｔｅｘｔ　　　　　　ｉ　エンドセクション割込みサ
ービスルーチンを追加することに関連するロードタイム
方法もまた、第２図に関して上記したものと本質上同一
である。もう一つ余分に考慮すべき点は、各ルーチンと
関連する優先順位の情報がモジュールの擾先１頑位リス
トにアクセスすることによって検索可能なことである。

かくして、同じ割込みレベルに鎖状結合された割込みサ
ービスルーチンは特別にアクセス又は参照可能となる。

以上の記載に関して以下の各項を開示する。

ｌ．　ホストブロセソサシステムとグラフィンクプロセ
ソサシステムを共に備え、ホスト上を走るメインプログ
ラムにより呼出され上記グラフィソクブロセソサにより
実行可能な関数を拡張するためのマルチブロセソサシス
テムにおいて使用される方法において、 上記グラフィックプロセノサにより実行されるサブプロ
グラムをつくりだし、 上記サブプログラムを定義することによってその引数が
ランタイム時に上記グラフィソクブｌコセソサシステム
にパスできるようにし、上記メインプログラム内のサブ
プログラムに対してサブプログラムにより使用されるパ
ラメータを含む呼出しを宣言し、 上記サブプログラムをコンパイルして上記グラフィック
プロセッサシステム上で実行し、上記サブプログラムを
上記グラフィンクプロセノサシステムヘロードし、 上記ザブプログラムを上記グラフィックプロセッサシス
テム上にロードされる他のコードにリンクする、 ステップより或る前記方法。

２，　ホスｌ・プロセソサシステムとグラフイソクブロ
センサシステムを備えることによって上記ホストコンピ
ュータ上を走るメインプログラムによって呼出されグラ
フィックプロセンサによって実行される拡張関数を実行
するマルチプロセッサコンピュータシステムを使用する
方法において、 上記拡張関数を上記グラフィックプロセッサシステムヘ
ロードし、 上記メインプログラムから上記拡張関数を呼出し、 上記ホストシステムから上記グラフイノクシステムへ上
記拡張関数の引数をパスし、上記拡張関数を上記グラフ
ィックプロセソサによって実行する、ステソプより成る
前記方法。

３．第１のプロセッサ上で一つのソフトウエアプログラ
ムを実行することによって同プログラムが第２のプロセ
ッサにより実行さるべき指定拡張関数を呼出すことがで
きるようにしたマルチブロセソサコンピュータシステム
において、プログラマブルホストプロセソサと、 上記ホストブロセソサによりアクセス可能なメモリと、 プログラマブルグラフインクプロセッサと、上記グラフ
ィノクプロセソサによりアクセス可能なメモリと、 を備え、上記ホストブロセソサとグラフィックブロセノ
サがソフトウエアインターフェースによりプログラミン
グされ、同インターフェースによって上記拡張関数が上
記グラフインクプロセッサメモリにダイナミックにダウ
ンロードされ、上記グラフインクプロセソサにより実行
できるようになった前記システム。

４，　ホストプロセソサシステムとグラフィックプロセ
ッサシステムを備え、ホストシステム上を走るメインプ
ログラムにより呼出されグラフインクブロセソサにより
実行される拡張関数を実行するマルチプロセッサコンピ
ュータシステムと共に使用されるソフトウエアインター
フェースにおいて、 上記拡張関数を上記グラフィックプロセッサシステム上
にロードされた他のコードヘダイナξ・ノクにダウンロ
ードしリンクするリンカと、上記ホストシステムから引
数を受取り、上記拡張関数を識別し、上記拡張関数を呼
出すコマンド実行ルーチンと、から威り、 上記コマンド実行ルーチンとリンカとが一体となったツ
ールの集合を備え、拡張関数をダイナミックにダウンロ
ードしてそれらの引き数を上記ホストプロセッサシステ
ムから受取る前記インターフェース． ５．　ホストプロセッサとサブプロセッサとを備えるマ
ルチプロセッサシステム内にサブシステムプロセッサの
メモリにロードされる拡張関数を追加する方法において
、 上記サブプロセンサにより実行さるべき少なくとも一つ
の関数を備えるロードモジュールをプログラミングし、 上記ロードモジュールに対する再配置可能なアドレス引
用を含む上記モジュールの引用セクションをつくりだし
、 上記ロートモジュールを部分的にリンクして内部引用が
全て解決され、外部引用が未解決のまま残されることに
よって上記ロードモジュールがランタイム時に完全にリ
ンクできるようにする、ステップより或る前記方法。

６．　サブシステムプロセソサにより実行さるべき拡張
関数をロードすることによって同関数がホストプロセッ
サシステム上を走るアプリケーションプログラムから呼
出せるようにするマルチブロセソサシステムにおいて使
用される方法において、 上記サブプロセノサシステム内のメモリを上記拡張関数
の定義を含むロードモジュールに対して割当て、 上記ロードモジュールを上記サブプロセソサシステムに
ロードし、 上記ロードモジュールを上記サブプロセソサシステムに
ロードされる他のコードにリンクすることによって上記
ロードモジュールの未解決の引用が解決されるようにす
る、 ステップより威る前記方法。

７．拡張関数をサブプロセッサシステムヘロードしリン
クすることによって上記関数がホストプロセッサシステ
ム上を走るアプリケーションプログラムと共に使用可能
になったマルチプロセッサコンピュータシステムにおい
て、プログラマブルホストプロセッサと、 上記ホストプロセッサによりアクセス可能なメモリ、よ
り成り、 上記サブプロセッサが上記ホストプロセソサのメモリ内
ヘロードされる拡張関数を上記第２のプロセンサのメモ
リへダウンロードして上記拡張関数を上記サブプロセッ
サ上にロードされた他のコードにダイナミソクにリンク
するようにプログラミングされる前記システム。

８．　ホストプロセッサシステム上を走るアプリケ一シ
ョンプログラムのロード中にサブシステムブロセノサに
より実行されべき拡張関数を上記サブシステムブロセソ
サの他のコードにリンクするためのマルチブロセソサシ
ステム中に使用されるグイナミソクリンカプログラ旦ン
グ機構において、 」二記アフ゜リケーシヲンフ゜ログラムのロードに呼応
して実行開始の呼出しを受取る入口点と、上記拡張関数
を含むロードモジュールのメモリサイズを取得する命令
と、 上記ホストのメモリから上記サブプロセッサシステムの
メモリ内へ上記ロードモジュールを再配置するための命
令と、 上記ロードモジュール外部の関数に対する未解決の参照
を解決するための命令と、より成り、上記入口点と命令
とが上記サブシステムプロセソサにより実行可能な一つ
の構文と文とへ構成される前記機構。

９．　ホストプロセッサシステムとグラフィソクプロセ
ソサシステムを有するマルチプロセッサコンビュータシ
ステムと共に使用されるインターフェースによって、拡
張関数がホストシステム又は別のシステム上で開発され
、次いでグラフィックブロセソサシステムにロードする
ことが可能になる．上記インターフェースは、ホストシ
ステム側とグラフィンクシステム側に常駐するソフトウ
エアにより成り、ランタイムにオペレートして上記関数
がホスト上を走るメインプログラムから呼出すことが可
能になる。関数の引数はグラフィックシステムにパスさ
れることによって、同関数はグラフィックブロセソサに
よって実行される。

【図面の簡単な説明】

第１図はグラフインクサブシステムの機能性を拡張段階
を示すフローダイアグラム、 第２図はホストプロセッサとグラフインクプロセッサを
有するコンピュータシステムを使用するステップを示す
フローダイアダラム、 第３図はホストプロセッサとグラフインクブロセソサヲ
有スるマルチブロセソサコンビュータシステムのブロソ
ク線図、 第４図は第３図のマルチプロセソサシステムと共に使用
されるソフトウエアインターフェースを示すブロノク線
図、 第５図はホストブロセソサとグラフィックプロセノサ間
の通信用に使用される通信バンファの構造を示す図、 第６図は、サブプロセッサシステムに共も使用される拡
張関数を格納するモジュールをつくりだすステップを示
す図 第７図は拡張関数を第１のプロセソサから第２のプロセ
ソサヘロードし、未解決の参照をグイナミソクにリンク
するステップを示す図。 ２１２・・・アプリケーションプログラム、２１１・・
・通ｆ３ドライハ、２１６・・・オブジェクトファイル
、２１５・・・拡張関数、２３３・・・コアアプリケー
ション原始関数、２２４・・・ダイナミソクリンカ、２
２５・・・インクルードファイル、２２２・・・コアシ
ステム原始関数、４２３・・・スタック、３２３・・・
バソファ● 表ＡＩ ｇｅｔ−ｃｏｎｆｉｇの構文 ｔｙｐｅｄｅｆ　　ｓｔｒｕｃｔ ｛ 夏ｏｎｇ　　ｄｒｓｐ−ｐＨｃｈ　　；ｓｈｏｒＬ　ｄ
ｉｓｐ−ｖｒｅｓ　　；ｓｈｏｒｔ　ｄｉｓｐＪｒｅｓ
　　； ｓｈｏｒｔ　ｓｃｒｅｅｎ−ｗｉｄｅ　　；ｓｈｏｒｔ
　ｓｃｒｅｅｎＪｉｇｈ　　：ｓｈｏｒｔ　ｄｉｓｐ−
ｐｓｉｚｅ　　；ｌｏｎｇ　ｐｉｘｅＬｍａｓｋ　　； ｓｈｏｒｔ　ｐａｌｅｔ−ｇｕｎ−ｄｅｐＬｈ　　ｉｌ
ｏｎｇ　　ｐａｌｅＬｓｉｚｅ　　；ｓｈｏｒｔ　ｐａ
ｌｅｔ−ｉｎｓｅｔ　　；ｓｈｏｒｔ　　ｎｕ麟一ｐａ
ｇｅｓ　　；ｓｈｏｒｔ　ｎｕｎ−ｏｆｆｓｃｒｎ−ａ
ｒｅａｓ　　；ｌｏｎｇ　ｗｋｓｐ−ａｄｄｒ　　； ｌｏｎｇ　ｗｋｓｐ−ｐｉｔｃｈ　　：｝　　ＭＯＤＥ
ＩＮＦＯ　； ｔｙｐｅｄｃｆ　ｓｔｒｕｃｔ ｛ ｌｏｎｇ　ｃｏｍｍ−ｂｕｆｆ−ｓｉｚｅ　；ｓｈｏｒ
ｔ　ｎｕｎ−ｍｏｄｅｓ　　；ｓｈｏｒｔ　ｃｕｒｒｅ
ｎｔ−ｍｏｄｅ　Ｓｌｏｎｇ　ｐｒｏｇｒａｍ−ｍｅｍ
−ｓｔａｒｔ　；１ｏＢ　ｐｒｏｇｒａ＋ｉ−ｍｅｍ−
ｅｎｄ　；ｌｏｎｇ　ｄｉｓｐｌａｙ−ｍｅａｌ−ｓｔ
ａｒｔ　；ｌｏｎｇ　ｄｉｓｐｌａｙ−ｍｅｍ−ｅｎｄ
　；ｌｏｎｇ　ｓｔａｃｋ−ｓｉｚｅ　； ｌｏｎｇ　ｓｈａｒｅｄ−ｓｅｗ−ｓｉｚｅ　：ｃｈａ
ｒ　ｆｏｒ　”ｓｈａｒｅｄ−ｈｏｓｔ−ａｄｄｒ　；
ＰＴＲ　ｓｈａｒｅｄ−ｇｓｐ−ａｄｄｒ　；ＭＯＤＥ
ＩＮＦＯ　ｔｍｏｄｅ　　； ）ｃｏ肝ＸＧ； ｖｏｉｄ　ｇｅｔ−ｃｏｎｆｉｇ　（ｃｏｎｆｉｇ）Ｃ
ＯＮＦＩＧ　ｆａｒ　”　ｃｏｎｆｉｇ　；上記の構造
定義におけるフイーノレト′ムよ次の通りであるＯ ｃｏｍｍ−ｂｕｆｆ−ｓｉｚｅ　：通信ノＮ７ファのノ
Ｘイトサイズ．ｎｕｎ＋−ａ＋ｏｄｅｓ　　： アプリケーションは、送られ たデータがこのバソファをオ ーバーフローさせない必要が ある．これは、グラフィソク プロセフサにダウンロードさ れるデータの大きさをチェッ クしない命令に関して有益で ある。 異なる表示セソトアップ間をスイ ッチングするグラフィソクボード 用の拡張モード数 表Ａ２ ｃｕｒｒｅｎ　ｌｍｏｄｅ：現在操作モードに対応する
モード数 ｐｒｏｇｒａｍ−ｍｅｍ−ｓｔａｒｔ：プログラムメモ
リのスタートアドレス ｐｒｏｇｒａｍ−ｍｅｍ−ｅｎｄ　：プログラムメモリ
のエンドアドレス ｄｉｓｐｌａｙ−ｍｅＩＩＩ−ｓｔａｒｔ：ディスプレ
イメモリのスタートアドレス ｄｉｓｐｌａｙ劃ｅｍ−ｅｎｄ：ディスプレイメモリの
エンドアドレス ｓｔａｃｋ−ｓｉｚｅ：デフォルトスタソクサイズｓｈ
’ａｒｅ−ｍｅｍ−ｓｉｚｅ：使用すべきアプリケーシ
ョンに利用可能な共用メモリのバ イトサイズ ｓｈａｒｅＪｏｓｔ−ａｄｄｒ：　もしｓｈａｒｅ−ｍ
ｅＩｌｌ−ｓｉｚｅがゼロでなければ、これは共用メモ リのホストメモリ中のスター トアドレスである。 ｓｈａｒｅ４ｓｐ−ａｄｄｒ＋　もしｓｈａｒｅ−＋ａ
ｅｍ−ｓｉｚｅがゼロでなければ、これは共用メモリの ＧＳＰメモリのスタートアドレ スである。 ｄｊｓｐ−ｐｉｔｃｈ：　　ディスプレイピッチ、即ち
、２本の走査線間の線間差のビソト表示 ｄｉｓｐ−ｖｒｅｓ：走査線の垂直解像度ｄｉｓｐＪｒ
ｅｓ：　ピクセルの水平方向解像度ｓｃｒｅｅｎ−ｗｔ
ｄｅ：　モニタの幅と高さ（ミリメートル単位〉 ｓｃｒｅｅｎＪｉｇｈ： ｄｉｓｐ−ｐｓｆｚｅ：　　ビクセルサイズｐｉｘｅｌ
ｓ＋ａｓｋ：　　１ピクセルに使用されるビットのマス
ク。通常２の（ｄｉｓ−　ｐｓｉｚｅ−１）乗の値を含
むことになろう。ピクセ ルデータの全ビットが妥当であるこ とを示す。 ｐａｌｅｔ−ｇｕｎ−ｄｅｐｔｈ：バレソト内のガンあ
たりビッ１・数 ｐａｌｅｌｓｉｚｅ：パレット内の人口の数ｐａ　Ｉｅ
　ｔ−　ｉｎｓｅ　ｔ　二大抵のシステムの場合、この
フィールドは零となろう。しかし、フレー ムバッファ内にパレットをストアす るシステムの場合には、これは走査 線の開始から第１のピクセルデータ へ至るオフセットとなる。 表Ａ３ ｎｕｎ−ｐａｇｅｓ：多重バッファシステムの表示ペー
ジ数ｎｕｍ−ｏｆｆｓｃｒｅｅｎ：利用可能なオフスク
リーンメモリブロックの数。もしゼロでなければ オフスクリーンアレイ用の空間を割 当てるために使用される。上記アレ イはもう一つの関数（ｇｅｌｏｆｆｓｃｒｅｅｎｓｅｗ
．）に対する呼出しを介してＧＳＰから得ることができ
る。 ｗｋｓｐ−ａｄｄｒ：オフスクリーンワークスペースエ
リアのメモリ中における開始線形アド レス ｗｋｓｐ−ｐｉｔｃｈ：オフスクリーンワークベースエ
リアアのピンチ．もしピッチが０ならば、 オフスクリーンワークスペースは割 当てられない。 Ｓｅｔ−ｃｏｎｔｉｇの構文 ｉｎｔ　ｓｅＬｃｏｎｆ）ｇ　（ｇｒａｐｈｉｃｓ−ｍ
ｏｄｅ＋　ｉｎｉｔ−ｄｒａｗ）ｓｈｏｒｔ　ｇｒａｐ
ｈｉｃｓ−ｍｏｄｅ；ｓｈｏｒｔ　ｉｎｉｌｄｒａｗ　
； 第４図 第５図 第６図 第７図

Claims (1)

【特許請求の範囲】
1. （１）ホストプロセッサシステムとグラフィックプロセ
   ッサシステムとを共に備え、ホスト上を走るメインプロ
   グラムにより呼出され 上記グラフィックプロセッサにより実行可能な関数を拡
   張するためのマルチプロセッサシステムにおいて使用さ
   れる方法において、 上記グラフィックプロセッサにより実行されるサブプロ
   グラムをつくりだし、 上記サブプログラムを定義することによってその引数が
   ランタイム時に 上記グラフィックプロセッサシステムにパスできるよう
   にし、 上記メインプログラム内のサブシステムに対してサブプ
   ログラムにより使用されるパラメータを含む呼出しを宣
   言し、 上記サブプログラムをコンパイルして上記グラフィック
   プロセッサシステム上で実行し、上記サブプロセッサを
   上記グラフィックプロセッサシステムへロードし、 上記サブプログラムを上記グラフィックプロセッサシス
   テム上にロードされる他のコードにリンクする、 ステップより成る前記方法。