JP2001518217A - コンピュータ・メモリ構成 - Google Patents

Abstract

(57)【要約】 コンピュータ・システムのメモリにおいて、複数のバッファ・ゾーンがバッファ管理システムによって定義される。コマンドは、公用バッファ・ゾーン中のバッファのプールの数ＮＰを定義し、且つ各プールについて、プール中のバッファの数であるプール・サイズＰＳ、そのプール中のバッファのサイズＢＳを定義する。バッファ管理システムは、各バッファ・ゾーンについて、バッファ・サイズを記憶すると共にプール・サイズを累積及び記憶するように初期設定される。バッファをアドレスするために、バッファ管理システムは、記憶された情報を使用して、所望のプール及びバッファ番号からバッファの開始部のアドレスを決定する。更に、バッファ管理システムは各バッファの開始部でヘッダを定義する。限度外の条件もチェックすることができる。それぞれの異なったクライアントに割り振られる各種の私用バッファ・ゾーンを、同様に定義することができる。

Description

【発明の詳細な説明】 コンピュータ・メモリ構成 本発明はコンピュータに関し、更に具体的には、メモリ領域をバッファリング 目的のために分割することに関する。「コンピュータ」の用語は広い意味で使用 され、データの処理及び操作がシステムの主たる目的であろうと、デジタル・テ レビジョン・システム用の受信器／デコーダのように更に特殊な機能に従属又は 付随したものであろうと、そのような処理及び操作を実行するシステムを包含す ることが理解されるであろう。しかし、それは、そのタイプのシステムに制限さ れるものではなく、もっと一般的に広範な種類のコンピュータ・システムに適用 可能なことが了解されるであろう。ここで使用されるように、「デジタル・テレ ビジョン・システム」の用語は、例えば衛星、地上、ケーブル及び他のシステム を含むものである。 主としてテレビジョン信号を放送することを意図されたデジタル伝送システム 、特に、排他的意味ではなく、衛星テレビジョン・システムの出現は、そのよう なシステムを多様な目的に使用する可能性を開いた。それらの１つはエンドユー ザ（最終利用者）との対話性を提供することである。ここで使用されるように、 「デジタル伝送システム」の用語は、例えば、主としてオーディオビジュアル又 はマルチメディア・デジタル・データを伝送又は放送する任意の伝送システムを 含む。本発明は特に放送デジタル・テレビジョン・システムに適用可能であるが 、更に本発明はマルチメディア・インターネット・アプリケーションその他の固 定式遠隔通信用回路網にも適用可能である。 本発明は、受信信号が受信器／デコーダへ渡され、そこからテレビジョン・セ ットへ渡される放送デジタル・テレビジョン・システムに特別の応用を有する。 ここで使用される「受信器／デコーダ」の用語は、符号化された信号又は符号化 されていない信号、例えばテレビジョン及び／又は無線信号を受信する受信器を 意味する。更に、この用語は受信信号を復号化するデコーダ（復号器）を意味す る。そのような受信器／デコーダの実施形態は、例えば「セット・トップ・ボッ クス」の中で受信信号をデコードするために受信器と一体化したデコーダ、又は 物理的に分離された受信器と一緒になって機能するこのようなデコーダを含むも のである。 受信器／デコーダは、圧縮されたＭＰＥＧタイプの信号をテレビジョン・セッ ト用のテレビジョン信号に復号化する。受信器／デコーダは、受信器／デコーダ 内のインタフェースを介してリモート・コントローラ・ハンドセットによって制 御される。受信器／デコーダは、到着ビット・ストリームを処理するために使用 され、多様な制御及び他の機能をコンピュータ・システムに実行させる多様なア プリケーション・モジュールを含むコンピュータ・システムを具備する。 そのような受信器／デコーダは、例えば、どのようなサービスの使用をユーザ が許可されているかを確認するためにユーザが許可カードを通すカード読み取り 装置、ハンドヘルドＴＶ受信機制御ワンド、ＴＶ表示ユニット、及びホーム・バ ンキング機能をユーザに実行させる銀行カードと共に使用される第２のカード読 み取り装置などの多様な装置をそれに結台させる。更に、それは、例えばインタ 一ネットにアクセスしたり、ホーム・バンキング取引を実行するためのモデム、 ホーム・コンピュータなどの多様なポートをそれに結合させる。 前述した対話性を提供する１つの方法は、テレビジョン信号が受信される受信 器／デコーダでアプリケーションを実行することである。多様なアプリケーショ ンが透過方式で多様な物理的装置と通信できるようにするのが望ましい。我々の 関連出願ＰＣＴ／ＥＰ９７／０２１１５及びＰＣＴ／ＥＰ９７／０２１１６は、 １つ又は複数のアプリケーションが受信器／デコーダによってダウンロードされ 、各装置用のデバイス・ドライバ及び全体的なデバイス・マネージャによって、 並列及び直列インタフェース及びスマートカード読み取り装置のような、受信器 ／デコーダ内の物理的装置と通信することができるシステムを説明している。 モデム、直列チャネル、並列チャネル、ＭＰＥＧ（圧縮及び符号化ビデオ信号 ）チャネル、スワイプ・カード読み取り装置などのような、異なった多様な信号 チャネルとインタフェースできる能力を受信器／デコーダに付与することが提案 されている。受信器／デコーダは、ラン・タイム（実行時）・エンジンを含む仮 想マシンを有する。仮想マシンはデバイス・マネージャに結合され、デバイス・ マ ネージャは装置及びデバイス・ドライバを介して多様なチャネルの物理インタフ ェースへ順次結合される。 コンピュータ・システム、特にデジタル・テレビジョン又はラジオ用の受信器 ／デコーダのように、より大きいシステムに組み込まれた特定のシステムにおい て、メモリの量が度々制限される。これは、システムに必要な各種の機能によっ て使用されるメモリ空間を最小にするように、メモリを構成しなければならない ことを意味する。更に、メモリの少なくとも或る部分にアクセスするために必要 な時間を最小にすることも必要であろう。 本発明は、特にメモリ内にバッファを設けること、又はバッファを構成するこ とに関する。 バッファを設ける通常の手法は、動的システムによって必要なバッファを割り 振る方法である。しかし、本発明との関連では、この標準方式は或る不利益な点 を有する。それはメモリの分断化を生じやすく、その速度はオーバヘッド・オペ レーションの必要性によって制限される。更に、バッファの拡張が必要な場合に 、拡張用の空間を作るためにメモリ・ブロックの移動を必要とするかも知れない 。 従って、本発明は、コンピュータ・システムのメモリにおいて、バッファ・ゾ ーンの中にバッファを定義及びアドレスするバッファ管理システムを提供するも ので、複数のプール・サイズを記憶するプール・サイズ記憶手段と、各プールに ついて、バッファ・サイズを記憶するバッファ・サイズ記憶手段と、これらから 所望のプール内の、所望のバッファのアドレスを計算する計算手段とを具備する 。 更に、本発明は、コンピュータ・システムのメモリにおいて、複数のバッファ ・ゾーンの中にバッファを定義及びアドレスするバッファ管理システムを提供す るもので、各バッファ・ゾーンについて、複数のプール・サイズを記憶するプー ル・サイズ記憶手段と、各プールについてバッファ・サイズを記憶するバッファ ・サイズ記憶手段と、これらから所望のプール内の所望のバッファのアドレスを 計算する計算手段とを具備する。 効率性と簡単な管理を目的として、バッファ・ゾーンは異なった固定サイズの バッファへ区分され、同一サイズのバッファはバッファ・プールへまとめられる 。バッファ管理システムは必要に応じてバッファをアプリケーションへ割り振り 、 それぞれメモリを必要とするアプリケーション間の衝突を避けることができる。 好ましくは、プール・サイズを累積形式で決定し、それらをその形式でプール ・サイズ記憶手段に記憶する手段が含まれる。予約領域が各プールの開始部に定 義され、直接的な累積プール・サイズ又は計算手段の出力を選択する手段が設け らる。所望のプール番号、所望のバッファ番号、及び所望のバイトが制限外の値 であるかどうかをチェックされる。 好ましくは、異なったバッファ・ゾーンのオーバラップを検出する手段が含ま れる。 更に、該システムはバッファ・ゾーンの開始アドレスを記憶する手段及びバッ ファ・ゾーンの終端アドレスを記憶する手段を含むことができ、オーバラップ検 出手段は、記憶手段から各バッファ・ゾーンの開始及び終端アドレスを受け取る 手段、及びバッファ・ゾーンの開始アドレスが前のバッファ・ゾーンの終端アド レスよりも大きいかどうかを決定する手段を更に具備している。 更に、本発明は前述したようなバッファ管理システムを含む受信器／デコーダ へ拡張される。 受信器／デコーダは複数のアプリケーションを記憶する手段を含むことができ 、前記システムは、１つのアプリケーションにのみ割り振るためにバッファ・ゾ ーンの中でバッファを定義及びアドレスし、他のアプリケーションに割り振るた めに別のバッファ・ゾーンの中でバッファを定義及びアドレスするように構成さ れている。 更に、本発明は、コンピュータ・システムのメモリにおいて、バッファ・ゾー ンの中にバッファを定義及びアドレスする方法を提供するもので、次のステップ 、則ち、 複数のプール・サイズを記憶するステップ、 各プールについて、バッファ・サイズを記憶するステップ、および これらから所望のプール内の、所望のバッファのアドレスを計算するステッぷ 、を具備する。 更に、本発明は、コンピュータ・システムのメモリにおいて、複数のバッフ ァ・ゾーンの中にバッファを定義及びアドレスする方法へ拡張され、各バッファ ・ ゾーンについて次のステップ、即ち、 複数のプール・サイズを記憶するステップ、 各プールについて、バッファ・サイズを記憶するステップ、および、 これらから所望のプール内の所望のバッファのアドレスを計算するステップ、 を具備している。 更に、本方法は、各バッファ・ゾーンについて、次のステップを含むことがで きる。 プール・サイズを累積形式で決定するステップ、および プール・サイズをその形式で記憶するステップ。 更に、本方法は、各バッファ・ゾーンについて、各プールの開始部に予約領域 を定義するステップを含むことができる。 本方法は、各バッファ・ゾーンについて、直接的な累積プール・サイズ又はバ ッファ・プールのアドレスを選択するステップを更に含むことができる。 更に、本方法は、各バッファ・ゾーンについて、所望のプール番号、所望のバ ッファ番号、及び所望のバイトの制限外の値を検査するステップを含むことがで きる。 更に、本方法は、異なったバッファ・ゾーンのオーバラップを検出するステッ プを含むことができる。もしそうであれば、本方法は次のステップを更に含むこ とができる。 バッファ・ゾーンの開始アドレスを記憶するステップ、 バッファ・ゾーンの終端アドレスを記憶するステップ、及び バッファ・ゾーンの開始アドレスが、前のバッファ・ゾーンの終端アドレスよ りも大きいかどうかを決定するステップ。 バッファ管理システムの多様な機能が、ハードウェア、例えば専用集積回路で 実現されてよい。これは改善された速度のオペレーションを提供することができ る。しかし、好ましくは、機能の少なくとも幾つかはソフトウェアで実現され、 好ましくはアプリケーションを実行する処理手段によって実行される。これは、 より大きな柔軟性、より少ないコンポーネント数を可能にし、更に容易にシステ ムが更新されることを可能にする。 本発明を具体化したコンピュータ・システムを含む受信器／デコーダを、例示 的に、以下の図面を参照して説明する。 第１図は受信器／デコーダのインタフェースを示す概略図である。 第２図は受信器／デコーダの機能的ブロック図である。 第３図は受信器／デコーダのＲＡＭメモリと他のメモリ・ユニットとの関係を 示す簡略図である。 第４図はＲＡＭメモリの一部の構成を示す図である。 第５図はセット・バッファ・アウトライン（Ｓｅｔ＿Ｂｕｆｆｅｒ＿Ｏｕｔｌ ｉｎｅ）コマンドの構造を示す。 第６図はメモリ管理ユニットの構造の図である。 第７図はＲＡＭメモリの構成の変更形式を示す図である。 第８図は第７図のメモリ構成のためのメモリ管理ユニットの構造を示す簡略図 である。 第９Ａ図から第９Ｃ図までは、バッファの使用が、異なったクライアント及び 装置に関連づけられる様子を図示する。 コンピュータ・システムの理解を助けるために、先ずデジタル衛星受信器／デ コーダを簡単に説明する。 第１図を参照すると、本実施例のデバイス・ドライバの組み込みが意図される デジタル対話型テレビジョン・システム内で使用される受信器／デコーダ２０２ ０又はセット・トップ・ボックスが概略的に示される。適切なデジタル対話型テ レビジョン・システムの詳細は、我々の関連出願ＰＣＴ／ＥＰ９７／０２１０６ 〜０２１１７に見出すことができる。これらの開示は参照してここに組み込まれ る。参照を容易にするために、前記の明細書により詳細に説明される部分は、一 般的にそれらの明細書に使用される参照番号によって示される。 前記の明細書により詳細に説明されるように、第１図及び第２図を参照すると 、受信器／デコーダ２０２０は幾つかのポート、具体的には、ＭＰＥＧ信号フロ ー用のチューナ４０２８、直列インタフェース４０３０、並列インタフェース４ ０３２、及び２つのカード読み取り装置４０３６を含む。カード読み取り装置の １つはシステムの一部を形成するスマートカード用であり、他の１つは銀行カー ド （支払い、ホーム・バンキング、などに使用される）用である。更に、受信器／ デコーダは、テレビジョン信号（番組）発生器へ行くモデム・バック・チャネル ４００２へのインタフェース４０３４を含み、従って、ユーザはテレビジョン信 号（プログラム）発生器に戻って優先選択などを指示することができる。更に、 受信器はラン・タイム・エンジン４００８、デバイス・マネージャ４０６８、及 び１つ又は複数のアプリケーション４０５６を実行するための複数の装置４０６ ２及びデバイス・ドライバ４０６６を具備する。 この明細書の目的としては、アプリケーションは、好ましくは受信器／デコー ダ２０２０の高レベル機能を制御する１つのコンピュータ・コードである。例え ば、エンドユーザが、遠隔コントローラの焦点を、テレビジョン・セット２０２ ２のスクリーン上に見えるボタン対象の上に置いて有効キーを押すと、ボタンで 関連づけられた命令シーケンスが実行される。 対話型アプリケーションはエンドユーザの要求に応じてメニューを提示すると 共にコマンドを実行し、アプリケーションの目的に関連したデータを提供する。 アプリケーションは常駐アプリケーション、即ち受信器／デコーダ２０２０のＲ ＯＭ（又はフラッシュメモリ又は他の不揮発性メモリ）に記憶されたものである か、受信器／デコーダ２０２０のＲＡＭ又はフラッシュメモリへ放送及びダウン ロードされたものであってよい。 アプリケーションは受信器／デコーダ２０２０中のメモリ位置に記憶され、リ ソース・ファイルとして表される。リソース・ファイルは、前述した特許明細書 でより詳細に説明されるように、グラフィック・オブジェクト記述ユニット・フ ァイル、可変ブロック・ユニット・ファイル、命令シーケンス・ファイル、アプ リケーション・ファイル、及びデータ・ファイルを含む。 受信器／デコーダはＲＡＭ容量、フラッシュメモリ容量、及びＲＯＭ容量に分 割されたメモリを含むが、この物理的構成は論理構成とは区別される。更に、メ モリは各種のインタフェースに関連づけられたメモリ容量に分割され得る。１つ の観点からは、このメモリはハードウェアの一部と見なすことができ、他の観点 からは、メモリはハードウェアを離れて示されるシステム全体をサポート又は包 含するものと見なすことができる。 コンピュータ・システムは、仮想マシン４００７の一部を形成するラン・タイ ム・エンジン４００８に集中していると考えることができる。仮想マシン４００ ７は１つの側（「高レベル」側）でアプリケーションに結合され、他の側（「低 レベル」側）で、以下で説明する多様な中間論理ユニットを介して受信器／デコ ーダ・ハードウェア４０６１へ結合される。受信器／デコーダ・ハードウェアは 前述したような各種のポート（ハンドセット２０２６用のインタフェース２０３ ０，ＭＰＥＧストリーム・インタフェース４０２８、直列インタフェース４０３ ０、並列インタフェース４０３２、カード読み取り装置４０３６へのインタフェ ース、及びモデム・バック・チャネル４００２へのインタフェース４０３４）を 含むものと考えることができる。 第２図を特定して参照すると、各種のアプリケーション４０５７が仮想マシン ４００７へ結合される。より通常的に使用されるアプリケーションの幾つかは、 ４０５７で示されるようにシステム中でおおよそ永久的に常駐し、一方他のアプ リケーションは、例えばＭＰＥＧデータ・ストリームから又は必要に応じて他の ポートからシステムへダウンロードされる。 仮想マシン４００７は、ラン・タイム・エンジン４００８に加えて、ツールボ ックス４０５８を含む幾つかの常駐ライブラリ機能４００６を含む。ライブラリ は、エンジン４００８によって使用されるＣ言語の諸機能を含む。これらの機能 は、データ構造の圧縮、拡張、又は比較のようなデータ操作、描図などの機能を 含む。更に、ライブラリ４００６は、ハードウェア及びソフトウェアのバージョ ン・ナンバー及び利用可能なＲＡＭ空間などの、受信器／デコーダ２０２０内の ファームウェア４０６０に関する情報、及び新しい装置４０６２をダウンロード するときに使用される機能を含む。機能はライブラリヘダウンロードされ、フラ ッシュメモリ又はＲＡＭメモリに記憶することができる。 ラン・タイム・エンジン４００８はデバイス・マネージャ４０６８へ結合され 、デバイス・マネージャ４０６８は一組の装置４０６４へ結合され、一組の装置 ４０６４はデバイス・ドライバ４０６０へ結合され、順次デバイス・ドライバ４ ０６０はポート又はインタフェースへ結合される。広い意味では、デバイス・ド ライバは論理インタフェースを定義するものと考えることができ、従って２つの 異 なったデバイス・ドライバが共通の物理ポートへ結合可能である。装置は、通常 、１つ以上のデバイス・ドライバへ結合される。もし装置が１つだけのデバイス ・ドライバへ結合されるのであれば、装置は、通常、通信に必要な全機能を組み 込むように設計され、従って別個のデバイス・ドライバは不要となる。或る装置 はそれらの間で通信することができる。 以下で説明するように、装置４０６４からラン・タイム・エンジンまでの通信 には、３つの形式がある。即ち、変数、バッファ、及び一組の事象待ち行列へ渡 される事象の３つである。 受信器／デコーダ２０２０の各機能は装置４０６２として表される。装置はロ ーカルかリモートである。ローカル装置４０６４はスマートカード、ＳＣＡＲＴ コネクタ信号、モデム、直列及び並列インタフェース、ＭＰＥＧビデオ及びオー ディオ・プレーヤ、及びＭＰＥＧセクション及び表抽出器を含む。遠隔位置で実 行されるリモート装置４０６６は、ポート及び手順が、受信器／デコーダの製造 業者によって提供され設計される装置及びデバイス・ドライバによってではなく システムの専門家又は設計者によって定義されなければならない点で、ローカル 装置とは異なる。 ラン・タイム・エンジン４００８は、マイクロプロセッサ及び共通アプリケー ション・プログラミング・インタフェースの制御のもとで実行される。それらは すべての受信器／デコーダ２０２０に導入され、従って、すべての受信器／デコ ーダ２０２０はアプリケーションの観点からは同一である。 エンジン４００８は受信器／デコーダ２０２０上のアプリケーション４０５６ を実行する。それは対話型アプリケーション４０５６を実行し、受信器／デコー ダ２０２０の外部から事象を受け取り、グラフィックス及びテキストを表示し、 サービス用の装置を呼び出し、特定の計算のためにエンジン４００８に接続され たライブラリ４００６の機能を使用する。 ラン・タイム・エンジン４００８は各受信器／デコーダ２０２０に導入された 実行可能コードであり、アプリケーションを解釈及び実行するインタープリター 〔解釈実行系〕を含む。エンジン４００８は、シングル・タスク・オペレーティ ング・システム（例えば、ＭＳ−ＤＯＳ）を含む任意のオペレーティング・シス テムに適合可能である。エンジン４００８はプロセス・シーケンサ・ユニット（ これは多様なアクションを実行するために、キーの押し下げのような多様な事象 を取る）に基づいており、異なったハードウェア・インタフェースからの事象待 ち行列を管理するそれ自身のスケジューラを含む。更に、それはグラフィックス 及びテキストの表示を処理する。プロセス・シーケンサ・ユニットは一組のアク ション・グループを含む。各事象によって、プロセス・シーケンサ・ユニットは 、事象の性質に従って、その現在のアクション・グループから他のアクション・ グループへ動かされ、新しいアクション・グループのアクションを実行するよう にされる。 エンジン４００８はアプリケーション４０５６を受信器／デコーダ・メモリ２ ０２８へロード及びダウンロードするコード・ローダーを含む。最適使用を保証 するため、必要なコードのみがＲＡＭ又はＦＬＡＳＨメモリにロードされる。ダ ウンロードされたデータは、アプリケーション４０５６の変更又は許可されてい ないアプリケーションの実行を禁止するため、認証機構によって照合される。更 に、エンジン４００８は解凍器を含む。アプリケーション・コード（中間コード の一形式）は空間の節約及びＭＰＥＧ−２トランスポート・ストリームからの、 又は組み込み受信器／デコーダ・モードを介する迅速なダウンロードのために圧 縮されているので、コードはＲＡＭへロードする前に解凍しなければならない。 更に、エンジン４００８は、各種の可変値を更新すると共に状況変化を決定する ためアプリケーション・コードを解釈するインタープリターと、エラー・チェッ カーとを含む。 装置４０６２のサービスを使用する前に、プログラム（例えば、アプリケーシ ョン命令シーケンス）は「クライアント」、即ち装置４０６６又はデバイス・マ ネージャ４０６８への論理アクセス方式として宣言されなければならない。マネ ージャはクライアントに装置へのすべてのアクセスで参照されるクライアント番 号を与える。装置４０６６は幾つかのクライアントを有することができ、各装置 ４０６６のためのクライアントの数は、装置４０６６のタイプに従って指定され る。クライアントは手順「Ｄｅｖｉｃｅ：Ｏｐｅｎ Ｃｈａｎｎｅｌ」によって 装置４０６６へ導入される。この手順はクライアント番号をクライアントへ割 り当てる。クライアントは手順「Ｄｅｖｉｃｅ：Ｃｌｏｓｅ Ｃｈａｎｎｅｌ」 によってデバイス・マネージャ４０６８のクライアント・リストから外すことが できる。 デバイス・マネージャ４０６８によって提供される装置４０６２へのアクセス は、同期又は非同期とすることができる。同期アクセスの場合、手順「Ｄｅｖｉ ｃｅ：Ｃａｌｌ」が使用される。これは直ちに利用できるデータか、所望の応答 の待機を含まない機能にアクセスする手段である。非同期アクセスの場合、手順 「Ｄｅｖｉｃｅ：Ｉ／Ｏ」が使用される。これは、例えばマルチプレックスを発 見するためチューナ周波数を走査したり、ＭＰＥＧストリームからテーブルを取 り戻したりする場合のように、応答の待機（を含む）データにアクセスする手段 である。要求された結果が利用可能であれば、その到着を知らせるために事象が エンジンの待ち行列に置かれる。別の手順「Ｄｅｖｉｃｅ：Ｅｖｅｎｔ」は予想 外の事象を管理する手段を提供する。 前述したように、ラン・タイム・エンジンのメイン・ループは、各種のプロセ ス・シーケンサ・ユニットへ結合され、メイン・ループが適切な事象に出会うと 、制御は一時的にプロセス・シーケンサ・ユニットの１つへ移される。 従って、コンピュータ・システムは、アプリケーションが種々の装置と通信で きるようにする大きな柔軟性を有するプラットフォームを提供することが分かる 。 第３図を参照すると、受信器／デコーダはマイクロプロセッサ２０へ結合され たＲＡＭメモリ４０２２を含む。更に、マイクロプロセッサ２０はバス２１を介 してＦＬＡＳＨメモリ４０２４、ＥＥＰＲＯＭメモリ４０２４’、及びＲＯＭメ モリ４０２６に結合されている。更に、ＲＡＭメモリ４０２２はＤＭＡ（直接メ モリ・アクセス）ユニット２２へ結合される。データ（例えば、ＭＰＥＧビット ・ストリームからの）はＤＭＡユニット２２を介してＲＡＭメモリへ直接入れる ことができる。 ＲＡＭメモリ４０２２は２５６ｋバイトの長さであり、３つの領域に分割され る。即ち、コンピュータ・システムの製造者によって使用されるために予約され た領域２４、仮想マシン（ＶＭ）４００７によって使用されるために予約された 領域２５、及びバッファ、アプリケーション３０、３０’、３０”、データ、な ど多様な情報を含むために使用されるユーザ領域２６である。コンピュータ・シ ステムは機能的仕様によって定義され、この事は、製造業者がシステムを実現す るためにハードウェアを設計するとき、かなりの自由度を与える。メモリ領域２ ４は実際に機能仕様によって指定された機能とハードウェアとの間のインタフェ ースとして使用される。ＶＭ４００７及びマイクロプロセッサ２０は一緒になっ てラン・タイム・エンジン（ＲＴＥ）４００８と考えることができる。異なった 多様なアプリケーションが異なった時点でメモリへロードされてよい。 ＶＭ４００７とアプリケーションとの間、及び異なったアプリケーション相互 間で通信が必要である。この通信は、主としてＶＭ及び各種のアプリケーション に共通のバッファによって処理される。 コンピュータ・システムにおいて、複数のバッファ・ゾーンがユーザ領域２６ のバッファ領域３２において定義される。各バッファ・ゾーンはコマンドによっ て定義され、このコマンドは更にそのバッファ・ゾーンを個々のバッファへの分 割を定義する。コマンドはバッファ・ゾーン内のバッファ・プールの数を定義す る。各プールについて、プール中のバッファのサイズ及びプール中のバッファの 数が与えられる。 命令「Ｓｅｔ＿Ｏｕｔｌｉｎｅ＿Ｂｕｆｆｅｒｓ」は「公用」バッファ・ゾー ンを区分する。公用バッファ・ゾーン中のバッファは任意のクライアントによっ て割り振られ解放されることができる。命令「Ｄｅｖｉｃｅ＿Ｏｐｅｎ＿Ｃｈａ ｎｎｅｌ＿Ｐａｒｔｉｔｉｏｎ」は、効率的メモリ使用のために１つのクライア ントの「私用」バッファ・ゾーンを区分する。私用バッファ・ゾーン内のバッフ ァは、区分を行うクライアントによってのみ割り振ることができるが、任意のク ライアントによって解放されることができる。１つだけの公用バッファ・ゾーン が定義されてよいが、之に反して複数の私用バッファ・ゾーンが同時に存在して よい。各クライアントは高々１つのみの私用バッファ・ゾーンを区分できること が望ましい。 公用バッファ・ゾーンは、作成された後にクライアントによって変更されるこ とはできないが、私用バッファ・ゾーンは、それに関連づけられたクライアント によって要求に応じて作成及び削除が可能である。クライアントが私用バッフ ァ・ゾーンを区分したとき、バッファは公用バッファ・ゾーンではなく私用バッ ファ・ゾーンからクライアントのために割り振られる。同様に、バッファがロッ クされるか、その割り振りの後に割り振りを解かれることを、そのクライアント が要求したとき、私用バッファ・ゾーン内のバッファは、それぞれロックされる か割り振りを解かれる。 第５図は、公用バッファ・ゾーン用のＳｅｔ＿Ｂｕｆｆｅｒ＿Ｏｕｔｌｉｎｅ 命令の論理形式を示す。これは、プールの数ＮＰを定義する最初のエントリー１ ５を含み、それに続いて各プールのために一組ずつのエントリー１６、１６’な どの集合を含む。そこで各プール・エントリーは、プールのプール・サイズＰＳ （即ち、プール中のバッファの数）を定義する第１のサブエントリー１７、及び プールにおけるバッファのバッファ・サイズＢＳ（即ち、バッファ中のバイトの 数）を定義する第２のサブエントリー１８から構成される。 便宜上これら及び以下に使用される他のパラメータをリストする。 ＮＰ： プールの数 プールごとに、 ＰＳ： プール・サイズ（プール中のバッファの数） ＢＳ： バッファ・サイズ ＰＮ： プール番号 ＢＮ： バッファ番号（プール中の） ＢｙＮ： バイト番号（バッファ中の） ユーザ・メモリ領域２６では、第４図に示されるように、バッファのプールは その領域の開始部から逐次に配置される。示される実際のレイアウトは３つのプ ールであって、プール１は５つのバッファから構成され、プール２は６つのバッ ファから構成され、プール３は１つのバッファから構成される。更に注意すべき は、各バッファがその開始部に１６バイトのヘッダを含むことである。このヘッ ダは、ユーザがバッファ・フラグ等として使用することのできる１２バイトのセ クション、及び仮想マシン４００７の使用に予約される４バイトのセクションに 分割される。 ラン・タイム・エンジン４００８は、バス２１とＲＡＭメモリ４０２２のユー ザ領域２６との間のアドレシング・パス２７を形成するものと考えることのでき るバッファ・マネージャを実行する。第６図は公用バッファ・ゾーン用のバッフ ァ・マネージャの論理構成を示す。これは先ずマイクロプロセッサ２０の制御の もとでＳｅｔ＿Ｂｕｆｆｅｒ＿Ｏｕｔｌｉｎｅの命令によって初期設定される。 次に、それは任意の所望のバッファをアドレスするために使用される。 第６図を参照すると、各プールのためのサブエントリーＰＳ及びＢＳは、順次 それらの積ＰＳ＊ＢＳを形成する乗算器３５へ送られる。累算器３６は値６４ｋ （これは、ハードワイヤの値発生器４２から与えられる、ＲＡＭ４０２２のユー ザ領域２６の開始アドレスを表す）で初期設定され、１６を各積に加算する加算 器３７を介して積ＰＳ＊ＢＳの系列を与えられる。前記の１６は各プールの開始 部における予約セクションのサイズを表す。従って、累算器３６は、連続的に、 連続するバッファ・プールの各々の開始アドレスを含む。これらのプール開始ア ドレスは累積アドレス・レジスタ３８へ送られ、そこで順次に記憶される。又初 期設定の間に、プールの数ＮＰがプール数レジスタ３９に記憶され、プール・サ イズがプール・サイズ・レジスタ４０に記憶され、バッファ・サイズＢＳが同じ 順序でバッファ・サイズ・レジスタ４１に記憶される。 初期設定に続いて、バッファをアドレスすることができる。バッファをアドレ スするためには、所望のバッファが所望のプールのためのプール番号ＰＮ、その プール内の所望のバッファのためのバッファ番号ＢＮ、及びそのバッファ内の所 望のバイトのためのバイト番号ＢｙＮによって定義される。 プール番号ＰＮは、累積レジスタ３８及びバッファ・サイズ・レジスタ４０か ら、そのプールのための適切なエントリーを選択するために使用される。固定サ イズであるバッファ・サイズＢＳは乗算器４５へ送られ、そこでバッファ番号Ｂ Ｎによって乗算される。結果の積は、１６をその積に加算するインクリメンタ４ ６に送られる。累積レジスタ３８の出力は加算器４７へ送られ、そこでバイト番 号ＢｙＮを加算される。インクリメンタ４６の出力は加算器４８へ送られ、そこ で加算器４７の出力へ加算される。加算器４８の出力は、所望のアドレス、即ち 、所望のプールの所望のバッファの所望のバイトのアドレスとして、マルチプレ クサ４９を通過する。 更に、バッファ・マネージャはエラー・チェッキング回路を含む。プール番号 ＰＮは、選択されたプール番号がプール数よりも大きくないかをチェックするた め、即ち、選択されたプールがバッファ・ゾーンの中にあるかをチェックするた め、レジスタ３９から又プール数ＮＰを与えられた比較器５３へ送られる。バッ ファ番号ＢＮは、選択されたバッファ番号が選択されたプール内のバッファ数よ りも大きくないかをチェックするため、即ち、選択されたバッファが選択された プール内にあるかをチェックするため、プール・サイズ・レジスタ４０内の選択 されたエントリーの出力を与えられる比較器５４へ送られる。選択されたバイト 番号は、所望のバイト番号がバッファの長さよりも大きくないかをチェックする ため、即ち、選択されたバイトが選択されたバッファ内にあるかをチェックする ため、選択されたプール内のバッファのサイズを与えられる比較器５５へ送られ る。これらの比較器はすべて共通の出力を送り出し、チエックのいずれかが失敗 すると、エラー信号ＥＲＲを発生する。 これまでの説明は、バッファ（公用バッファ・ゾーン内の）がアドレスされて いることを想定した。しかし、バッファの１６バイト・ヘッダをアドレスしたい 場合もある。これら２つのオプション間の選択は信号Ｎ／Ｃによって制御される 。信号Ｎ／Ｃは、正規のバッファ・アクセスと、便宜上バッファ制御オペレーシ ョンと呼ばれるものとを選択する。正規のアクセスの場合、バッファが選択され 、バッファのヘッダは制御オペレーションのためにのみ選択される。 Ｎ／Ｃ信号はマルチプレクサ４９へ送られる。正規のバッファ・アクセスの場 合、この信号は前述したように加算器４８の出力を選択する。しかし、バッファ のヘッダにおける制御オペレーションの場合、その代わりにマルチプレクサが加 算器４７の出力を直接選択する。累積レジスタ３８からのこのパスはインクリメ ンタ４６を通過しないので、これはヘッダに続くバッファではなく、ヘッダ内の 所望のバイトの選択を生じる。 バッファ上の制御オペレーションの場合、比較器５５を無能化する必要がある 。従って、この比較器は信号Ｎ／Ｃによって正規のバッファ・アクセスの場合に は能動化され、制御オペレーションの場合には無能化される。更に、他の比較器 ５６がバイト番号ＢｙＮ及びヘッダ中のバイト数、即ち１６を与えられ、システ ム・ アクセスの場合信号Ｎ／Ｃによって能動化される。この比較器は、所望のバイト 番号が１６よりも大きくないことをチェックする。即ち、それは、選択されたバ イトが、選択されたバッファの開始部における予約領域内にあることをチェック する。明らかに、このチェックは、ユーザがバッファ・フラグとして使用に利用 できる１２バイト・セクションへのアクセスと、ＲＴＥの使用に予約された４バ イト・セクションへのアクセスとを識別するために精密に区別することができる 。 もし所望であれば、Ｓｅｔ＿Ｂｕｆｆｅｒ＿Ｏｕｔｌｉｎｅの命令は、第５図 に示されるように、ユーザ・メモリ領域２６の終わりを定義するユーザ・メモリ 終端パラメータ１４を含んでよい。コマンドへの最後のエントリーは、適切なレ ジスタに記憶され、バッファ領域がユーザ・メモリ領域２６の終わりを越えなか ったことをチェックするために使用することができる。（これは一般的には全く 起こらないことである。なぜなら、アプリケーション３０、３０’、３０”など のために空間を残しておく必要があるからである。しかし、バッファ・ゾーンが 、前述したようなユーザ領域の開始部ではなくその中央部のどこかに置かれるよ うにシステムが設計された場合には、起こる可能性がある。） 原理的には、Ｓｅｔ＿Ｂｕｆｆｅｒｓ＿Ｏｕｔｌｉｎｅの命令は、任意の時点 で公用バッファ・ゾーンを初期設定するために使用することができる。しかし、 バッファ・ゾーンの再初期設定はバッファ内の既存の情報のすべて（又は、ほと んどすべて）を実際に失う結果となる。従って、Ｓｅｔ＿Ｂｕｆｆｅｒ＿Ｏｕｔ ｌｉｎｅコマンドは通常はシステムの初期設定の時にのみ実行される。 これまで説明したシステムでは、バッファ領域３２は第４図に示されるような 公用バッファ・プールの集合を含む。第７図及び第８図は、どのようにして私用 バッファ・ゾーンが受信器／デコーダの中で実施されるかを示す。上記したよう に、公用バッファ・ゾーンは多数の私用バッファ・ゾーン６０、６０’、６０” などによって補足される。各私用バッファ・ゾーンはクライアントへ割り当てら れ、そのクライアントは私用バッファ・ゾーンを作成し、もし所望すればそれを 消去する。従って、私用バッファ・ゾーンは、或る意味では、それを作成したク ライアントの所有物である。しかし、他のクライアントは、それを所有するクラ イアントとの間で情報を転送するために、それにアクセスすることができる。 バッファ管理システムは、私用バッファ・ゾーンがユーザ・メモリ領域２６の 中で自由に配置できるようにしてもよい。しかし、第７図に示されるように、そ れらは、好ましくは、すべてクライアントを含むメモリ領域とは別のメモリ領域 ３２Ａに含まれる。これは、メモリ領域の使用が可能性として衝突する場合の検 出を簡単にする。 私用バッファ・ゾーン６０、６０’、６０”などは、公用バッファ・ゾーンと 同じ構造を有し、第５図に示されるＳｅｔ＿Ｂｕｆｆｅｒ＿Ｏｕｔｌｉｎｅコマ ンドと類似したＤｅｖｉｃｅ＿Ｏｐｅｎ＿Ｃｈａｎｎｅｌ＿Ｐａｒｔｉｔｉｏｎ コマンドによって定義される。Ｄｅｖｉｃｅ＿Ｏｐｅｎ＿Ｃｈａｎｎｅｌ＿Ｐａ ｒｔｉｔｉｏｎコマンドは２つの追加フィールドを含む。第１の追加フィールド はコマンドを発生するクライアントの識別子を含み、第２の追加フィールドはバ ッファ・ゾーンの開始部の．メモリ・アドレスを含む。メモリ終端フィールド（ 第５図の１４で示される）を省略するのが便宜的である。 第８図は私用バッファ・ゾーン用のバッファ・マネージャ２７の論理構成を示 す。第６図の回路はブロック６５として示される。更に、一組の別のブロック６ ６が存在し、そのひとつ一つはアプリケーションの各々に対応する。これらのブ ロックの各々は実質的にブロック６５と同じである。ブロック６６の各々の中で 、レジスタ４２Ａは対応するアプリケーションのために私用バッファ・ゾーンの 開始アドレスを記憶するために使用される。（前述したように、Ｄｅｖｉｃｅ＿ Ｏｐｅｎ＿Ｃｈａｎｎｅｌ＿Ｐａｒｔｉｔｉｏｎコマンドのフォーマットは、バ ッファの開始アドレス用のフィールドを含む。）ブロック６５及び６６は、すべ て公用バッファ・ゾーン又は私用バッファ・ゾーンの所望の１つを選択するため に使用されるマルチプレクサ６７へ接続される。 ユニット６５及び６６からのエラー信号は、すべて相互に結合することができ る。しかし、更に、異なったバッファ・ゾーンの間の衝突を検出するために、エ ラー・ユニット６８が備えられる。 バッファ・ゾーンの開始部のアドレスは、レジスタ４２及びレジスタ４２Ａか ら直接に得ることができる。終端アドレスについては、第６図の回路及びその初 期設定がやや変更される。累積アドレス・レジスタ３８はバッファ・ゾーン内の 各種のプールの開始アドレスを含む。このレジスタは３８Ａで示されるように１ つの場所だけ拡張される。更に、初期設定手順は、バッファ・ゾーンの最後のプ ールの開始アドレスの発生後、最後のプールのサイズとそのバッファ・サイズと を乗算することによって継続され、その積は累算器３６の中で累積され、その結 果はレジスタ拡張部３８Ａへ転送される。従って、レジスタ拡張部３８Ａはバッ ファ・ゾーンの終端アドレスを含む。 エラー・ユニット６８は各バッファ・ゾーンの開始及び終端アドレスを与えら れ、これらを処理して、オーバラップが存在するかどうかを決定する。これは、 例えば、バッファ開始アドレスを順次に配置して、各開始アドレスが前のバッフ ァ・ゾーンの終端アドレスよりも大きいかどうかをチェックすることによって行 うことができる。更に、このユニットは、新しいバッファ・ゾーンが発生されな ければならないとき、所望の新しいバッファ・ゾーンよりも大きな２つの既存の バッファ・ゾーン間のギャップを探すことによって、適切なメモリ領域を探索す るために使用されることができる。 ここでは、実質的に小さな食い違いが存在する。レジスタ拡張部３８Ａ内のア ドレスは、実際には真のバッファ終端アドレスではなく、バッファ・ゾーンの終 端の直後のアドレスである。しかし、この食い違いは小さなもので、例えばユニ ット６５及び６６とエラー・ユニット６８との間で終端アドレスを１ビットだけ 減少することによって解決することができる。 第９Ａ図から第９Ｃ図までは、バッファの使用が、異なったクライアント及び 装置に関連づけられる様子を示す。第９Ａ図は、マネージャが５つのバッファＢ Ｆ１〜ＢＦ５を割り振るために様々なプロセス（命令）を使用した初期状態を示 す。 アンロックされているバッファＢＦ１は、割り振りコマンドＡＬＬＯＣによっ て、クライアントＣＬ１が割り振る（作成する）。 バッファＢＦ２もクライアントＣＬ１によって割り振られた。このバッファは 、現在、まだ終了していないＩ／Ｏオペレーションの時に装置ＤＶＩによって、 コマンドＩ／Ｏを介して使用されている。それは、Ｉ／Ｏオペレーションが終了 するまで、割り振り解除コマンド（ＦＲＥＥ）を受け入れないであろう。 バッファＢＦ３はクライアントＣＬ１によってロックされた。このバッファの 原初の割り振りは未知である。それはクライアントＣＬ１、他のクライアント、 クライアントＣＬ１によってアドレスされた装置、又は他のクライアントによっ てアドレスされた装置によって割り振られたのかも知れない。 バッファＢＦ４は、クライアントＣＬ１へアドレスされた予想外の事象に関連 づけられるように装置ＤＶ１によって割り振られた。この事象はまだ送られてい ない。 バッファＢＦ５は装置ＤＶ２で実行されている同期アクセスのためにクライア ントＣＬ１によって割り振られた。更に、バッファは装置によって割り振られる ことができた。アプリケーションの実行は、このオペレーションの後でのみ継続 することができる。 第９Ｂ図は、バッファＢＦ５に関連する同期アクセスが生じた後で、バッファ ＢＦ１に関連するＩ／Ｏ非同期アクセスの終了前に、クライアントＣＬ１が装置 １用のリストから外された後の状態を示す。 バッファＢＦ１及びＢＦ２の双方は存在し続ける。これらのいずれも装置ＤＶ １へリンクされない。 バッファＢＦ３はロックされているので存在し続けた。しかし、クライアント ＣＬ１又は他のクライアントはそれを割り振り解除することができた。 バッファＢＦ４はクライアントＣＬ１へアドレスされた装置ＤＶ１によって割 り振られ、従って、割り振り解除された。即ち、それは存在しなくなった。これ は、予想外の事象がまだ送られていない（即ち、アプリケーション・エンジンの 待ち行列に置かれていない）場合でもそうである。更に、このバッファが装置Ｄ Ｖ１からのＬＯＣＫコマンドによってロックされていない限り、事象が送られた 場合でもそうである。 バッファＢＦ５は、その使用に続いてクライアントＣＬ１によって割り振り解 除されなかった。 第９Ｃ図は、クライアントＣＬ１がＤｅｖｉｃｅ：Ｃｌｏｓｅ Ｃｈａｎｎｅ ｌコマンドを用いてデバイス・マネージャのリストからそれ自身を外した後の状 態を示す。 バッファＢＦ１、ＢＦ２、及びＢＦ５は、メモリをクリアするためにデバイス ・マネージャによって割り振り解除（削除）された。 バッファＢＦ３は、ロックされているので割り振り解除されなかった。それは 他のクライアントによって割り振り解除される。 これまで説明した各種の機能の実施形態の詳細、及びそれらをハードウェア及 びソフトウェアの間で分散することは、実施者の選択の問題であり詳細に説明し ない。しかし、注意すべきは、必要なオペレーションを実行することのできる専 用集積回路は、市販されているか容易に設計することができ、それらは、必要な 種々のオペレーションを実行するために、ハードウェア・アクセラレータの基礎 として使用することができるか、更に好ましくは専用ハードウェア・アクセラレ ータを製造するために変更することができ、それによってソフトウェアを実行す るのに必要な処理能力を低減することができる。しかし、必要なオペレーション は、もし十分な処理能力が利用可能であれば、ソフトウェアで実行されてよい。 モジュール及び他のコンポーネントが、オプション及び好ましい特徴と共に、 各コンポーネントによって提供される特徴及び機能に関して説明された。与えら れた情報及び提供された仕様を用いれば、これら特徴の実際の実施形態は、当業 者にとっては容易であり、精密な詳細は実施者に任せられている。例として、或 るモジュールはソフトウェアで実現することができ、好ましくはＣプログラミン グ言語で書かれ、また好ましくはアプリケーションを実行するために使用される プロセッサの上で実行するためにコンパイルされる。しかし、幾つかのコンポー ネントは別個のプロセッサで実行され、コンポーネントの幾つか又はすべては専 用ハードウェアで実現されてよい。 前記のモジュール及びコンポーネントは単に例示的なもので、本発明は多様な 方式で実現されてよい。特に、幾つかのコンポーネントは同様な機能を実行する 他のコンポーネントと結合されてよく、又は幾つかのコンポーネントは簡単な実 施形態では省略されてよい。各機能のハードウェア及びソフトウェア実施形態は 、コンポーネント間及び単一コンポーネント内で自由に混合されてよい。 ハードウェア、コンピュータ・ソフトウェア、などによって実行される機能は 電気信号などの上で、又はそれらを使用して実行されることは容易に理解される であろう。ソフトウェアの実施形態はＲＯＭに記憶されるか、ＦＬＡＳＨの中で パッチされてよい。 本発明の好ましい実施形態を要約すると、コンピュータ・システム内のメモリ の中に、複数のバッファ・ゾーンがバッファ管理システムによって定義される。 コマンドが公用バッファ・ゾーンの中でバッファのプールの数ＮＰを定義し、ま た各プールのために、プール内のバッファの数であるプール・サイズＰＳ、及び そのプール内のバッファのサイズＢＳを定義する。バッファ管理システムは、各 バッファ・ゾーンについて、バッファ・サイズを記憶すると共にプール・サイズ を累積及び記憶するように初期設定される。バッファをアドレスするためには、 バッファ管理システムが、記憶された情報を使用して、所望のプール及びバッフ ァ番号からバッファの開始部のアドレスを決定する。更に、バッファ管理システ ムは各バッファの開始部でヘッダを定義する。限度外条件のチェックも提供され る。それぞれの異なったクライアントによって割り振られる様々な私用バッファ ・ゾーンを、同様に定義することができる。 本発明のこれまでの説明は単に例としてなされたこと、本発明の範囲内で詳細 部の変更がなされ得ることが理解されるであろう。説明中で開示された各特徴、 及び（適切な場合には）特許請求の範囲及び図面は独立に又は任意の適切な組み 合わせで提供されてよい。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ９７１２１７４１．９ (32)優先日 平成９年12月10日(1997．12．10) (33)優先権主張国 ヨーロッパ特許庁（ＥＰ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，Ｍ Ｗ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，Ｅ Ｓ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ， ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，Ｍ Ｇ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ， ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，Ｖ Ｎ，ＹＵ，ＺＷ (72)発明者 レツルニュール，パトライス フランス国 エフ―92150 シュレヌ ル ー クルセール 44 (72)発明者 ビューク，ジャン−ベルナール ゲラルド モーリス フランス国 エフ―92270 ブワ―コロー ブ ルー ビクトル―ユゴー 132 (72)発明者 リャオ，ホンタオ フランス国 エフ―78180 モンチニ―ビ ーティーエクス ルー デュ カナル ４

Claims (1)

1. 【特許請求の範囲】 １． コンピュータ・システムのメモリにおいて、バッファ・ゾーンの中でバッ ファを定義及びアドレスするバッファ管理システムであって、該システムは、 複数のプール・サイズを記憶するプール・サイズ記憶手段と、 各プールについて、バッファ・サイズを記憶するバッファ・サイズ記憶手段と 、及び、 それらから所望のプール内の所望のバッファにおけるアドレスを計算する計算 手段とを具備することを特徴とする、バッファ管理システム。 ２． コンピュータ・システムのメモリにおいて、複数のバッファ・ゾーンの中 でバッファを定義及びアドレスするバッファ管理システムであって、各バッファ ・ゾーンについて、 複数のプール・サイズを記憶するプール・サイズ記憶手段と、 各プールについて、バッファ・サイズを記憶するバッファ・サイズ記憶手段と 、および それらから所望のプール内の所望のバッファのアドレスを計算する計算手段、 とを具備することを特徴とする、バッファ管理システム。 ３． 異なったバッファ・ゾーンのオーバラップを検出する手段を含む、請求項 ２に記載のシステム。 ４． バッファ・ゾーンの開始アドレスを記憶する手段とバッファ・ゾーンの終 端アドレスを記憶する手段を備え、前記オーバラップ検出手段は、該記憶手段か ら各バッファ・ゾーンの開始及び終端アドレスを受信する手段、及びバッファ・ ゾーンの開始アドレスが先のバッファ・ゾーンの終端アドレスよりも大きいかど うかを決定する手段とを備えた、請求項３に記載のシステム。 ５． 上記又はそれぞれのバッファ・ゾーンについて、プール・サイズを累積形 式で決定し、それらを該形式でプール・サイズ記憶手段に記憶する手段を備えた 、請求項１から４までのいずれか１項に記載のシステム。 ６． 上記又はそれぞれのバッファ・ゾーンについて、各プールの開始部に予約 領域を規定する手段を備えた、請求項１から５までのいずれか１項に 記載のシステム。 ７． バッファ・ゾーンについて、直接の累積プール・サイズ又は計算手段の出 力のいずれかを選択する手段を備えた、請求項５又は６に記載のシステム 。 ８． バッファ・ゾーンについて、所望のプール番号、所望のバッファ番号、及 び所望のバイトの制御対象外の値をチェックする手段を備えた、請求項１から７ のいずれか１項に記載のシステム。 ９． 請求項１から８のいずれか１項に記載のバッファ管理システムを備えた受 信器／デコーダ。 １０． 複数のアプリケーションを記憶する手段を備え、前記システムは、１つ だけのアプリケーションに割り振るためにバッファ・ゾーン内でバッファを定義 及びアドレスし、他のアプリケーションに割り振るために別のバッファ・ゾーン 内でバッファを定義及びアドレスするように構成された、請求項９に記載の受信 器／デコーダ。 １１． コンピュータ・システムのメモリにおけるバッファ・ゾーンの中でバッ ファを定義及びアドレスする方法であって、 複数のプール・サイズを記憶するステップと、 各プールについて、バッファ・サイズを記憶するステップと、および それらから所望のプール内の所望のバッファのアドレスを計算するステップと を具備したバッファを定義及びアドレスする方法。 １２． コンピュータ・システムのメモリの複数のバッファ・ゾーンの中でバッ ファを定義及びアドレスする方法であって、各バッファ・ゾーンについて、 複数のプール・サイズを記憶するステップと、 各プールについて、バッファ・サイズを記憶するステップと、および それらから所望のプール内の所望のバッファのアドレスを計算するステップと を具備した、バッファを定義及びアドレスする方法。 １３． 異なったバッファ・ゾーンのオーバラップを検出するステップを更に具 備する請求項１２に記載の方法。 １４． バッファ・ゾーンの開始アドレスを記憶するステップと、 バッファ・ゾーンの終端アドレスを記憶するステップと、および バッファ・ゾーンの開始アドレスが先のバッファ・ゾーンの終端アドレスより も大きいかどうかを決定するステップとを具備する、請求項１３に記載の方法。 １５． バッファ・ゾーンについて、 プール・サイズを累積形式で決定するステップと、および プール・サイズをその形式で記憶するステップとを更に具備する、請求項１１ から１４までのいずれか１項に記載の方法。 １６． バッファ・ゾーンについて、各プールの開始部で予約領域を定義するス テップを具備する、請求項１１から１５までのいずれか１項に記載の方法。 １７． バッファ・ゾーンについて、直接の累積プール・サイズ又はバッファ・ プールのアドレスのいずれかを選択するステップを更に具備する、請求項１５又 は１６に記載の方法。 １８． バッファ・ゾーンについて、所望のプール番号、所望のバッファ番号、 及び所望のバイトの制御対象外の値をチエックするステップを更に具備する、請 求項１１から１７までのいずれか１項に記載の方法。 １９． 実質的に添付の図面を参照して説明され且つ例示されるようなバッファ 管理システム。 ２０． 実質的に添付の図面を参照して説明されたようなコンピュータ・システ ムのメモリにおけるバッファ・ゾーンの中でバッファを定義及びアドレスする方 法。