JP2014197291A - プログラム処理方法およびプログラム - Google Patents

Abstract

【課題】ハードウェア依存を低減したプログラミングが可能なプログラム処理方法を提供する。【解決手段】パケットには、それを格納するメモリの種類に応じて複数種類のデータ表現が付与される。パケットに対して操作を行う際、そのパケットに付与されたデータ表現が識別され、識別されたデータ表現に従って処理が行われる。これにより、メモリの様なハードウェアへの依存を低減したプログラム開発が可能となる。また、プログラム開発に用いられるプログラム処理方法（コンパイラ）においては、パケットに対して処理を行う際に、その事前条件を把握し、生成されるオブジェクト・プログラムの高速化を図る。【選択図】図８Ａ

Description

本発明は、プログラム処理方法およびプログラムに関し、特に複数のドメインにまたがるコンピュータ・ネットワークまたは仮想ネットワークの設定あるいは管理を行うためのプログラムを開発するために用いられるプログラム処理方法およびプログラムに関する。

先ず、背景となる技術を、次の４項目に分けて、説明する。すなわち、第1として、プログラムを開発するために用いられるコンパイラにおける複数のデータ表現の使い分けに関する技術である。第2には、ネットワークをプログラマブルにするためのハードウェア技術である。特に、ネットワーク・プロセッサとそこで用いられるＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）の使い分けの技術である。第3としては、ネットワークをプログラマブルにするためのソフトウェア技術であり、そのなかでも特に高級言語に関する技術である。最後に、ネットワーク仮想化技術であり、そのなかでも特にネットワークをプログラマブルにするための技術である。

先ず、コンパイラにおける複数のデータ表現の使い分けに関する技術について説明する。ハードウェア要素の使い分けは複数のデータ表現の使い分けの一種だと考えられる。特許文献１には、コンパイラにおいて複数のデータ表現を使い分ける方法が示されている。特許文献１に示された方法においては、異なるデータ表現毎に、異なるモジュール（ｄａｔａ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｉｍｐｌｅｍｅｎｔｏｒ）が使用される。この方法は、特定のデータ表現を首尾一貫して使用するときには、適していると考えられるが、複数のデータ表現を混合して使用する必要があるときには、適用が困難であると考えられる。

次に、ネットワークをプログラマブルにするためのハードウェア技術、特にネットワーク・プロセッサとそこで用いられるメモリ、特にＳＲＡＭとＤＲＡＭの使い分けの技術について説明する。

高速なマルチコアのネットワーク・プロセッサにおいては、ワイヤ・レート（高速）の処理のためには、データをＳＲＡＭに格納することが望ましい。ところが、処理中の全てのパケット全体を格納（保管）できる程の記憶容量を有するＳＲＡＭを、ネットワーク・プロセッサあるいはシステムが備えていないのが通常である。そのため、処理上重要なパケットのディスクリプタまたは先頭部分だけをＳＲＡＭに格納しておき、残りの部分もしくはパケット全体はＤＲＡＭに格納することが行われている。例えば、Ｃａｖｉｕｍ社のネットワーク・プロセッサＯｃｔｅｏｎ（ＴＭ）あるいはＴｉｌｅｒａ社のネットワーク・プロセッサＴｉｌｅ―Ｇｘ（ＴＭ）においては、パケットの到着時に、ハードウェアで、上記した様な使い分けを行う様な処理が行われている。この様に、全てのパケットの全データを、ＳＲＡＭに格納しないのは、それだけの記憶容量を有するＳＲＡＭを用意すると、コストアップにつながるためである。

また、高速処理のためには、パケット到着時に、パケットの内容を、ＳＲＡＭあるいはＤＲＡＭに割り当て、それらにパケットの内容を自動的に格納する機能、また、マルチコアにより並列処理された出力パケットを入力順序通りに並べ替えたり、キューイングしたりする処理をハードウェアで行うことが望ましい。これらの機能も前記したＯｃｔｅｏｎ（ＴＭ）等のネットワーク・プロセッサにおいては実現されている。

この様なＳＲＡＭとＤＲＡＭの使い分けにおいては、ＳＲＡＭの記憶容量が制限されているため、従来のコンパイラにおける複数のデータ表現の使い分けにおけるような首尾一貫した使い分けは困難である。例えば、計算処理によって、ＳＲＡＭに格納されるべきデータ量が増加したときには、その一部をＤＲＡＭへ移動させる様な処理が発生するため、首尾一貫してＳＲＡＭを記憶用のメモリとして使用することは困難となる。一方、演算のためには、ＤＲＡＭに格納されていたデータを、ＳＲＡＭ、すなわちレジスタなどへ移動させる必要が生じる。そのため、首尾一貫して、ＤＲＡＭをメモリとして、使用することも困難となる。

さらに、ネットワークをプログラマブルにするためのソフトウェア技術、特に高級言語に関する技術として、Ｓｈａｎｇｒｉ−ｌａと、ＮｅｔＶＭについて述べる。まず、非特許文献１に開示されているＩｎｔｅｌ社などによるＳｈａｎｇｒｉ−ｌａと言われているシステムのために開発されたＢａｋｅｒ言語について説明する。Ｂａｋｅｒ言語においては、パケット本体はＤＲＡＭに格納され、そのパケットのディスクリプタが、ＳＲＡＭに格納されると仮定することにより、パケットがＤＲＡＭに格納されているのかＳＲＡＭに格納されているのかを、プログラマは意識せずに扱える様にしている。しかしながら、ＳＲＡＭでのデータ構造は、プログラマが決めなければならず、またネットワーク・プロセッサのアーキテクチャに依存する。さらに、ＤＲＡＭとＳＲＡＭとの間のデータ転送もプログラマが記述しなければならないため、キャッシュの操作もプログラマが行わなければならない。

最後に、ネットワーク仮想化技術、特にネットワークをプログラマブルにするために技術について、次に述べる。（独）情報通信研究機構により推進されている「仮想化ノード・プロジェクト」において開発された仮想化基盤では、スライス定義を管理系に与えると、仮想化基盤を構成する各仮想化ノードに、そのノードに関連する仮想ノードと仮想リンクの定義が配布され、各仮想化ノードが仮想化基盤を実現する。ここで仮想ノードは仮想のノードであり、実ノードである仮想化ノードとは全く異なる概念である。仮想ノードはノードスリバーとも呼ばれる。また、仮想リンクはリンクスリバーとも呼ばれる。

仮想ノードにおいて、ネットワーク・プロセッサのような専用化されたプロセッサ（ファストパスと呼ばれることもある）を使用するときは、そのプロセッサにロードするべきプログラムをスライス定義に指定する。仮想リンクはプログラマブルでないが、ＧＲＥ（Ｇｅｎｅｒｉｃ Ｒｏｕｔｉｎｇ Ｅｎｃａｐｓｕｌａｔｉｏｎ：ＩＥＴＦ標準）の実装には、ネットワーク・プロセッサが使用されている。仮想ノード内外の仮想リンク部分をつなぐためのパラメタ（ＩＰアドレス、ＧＲＥキー、ＭＡＣアドレス）は、スライス生成時にネットワーク・プロセッサに渡される。これらのパラメタは、仮想化ノードの管理系からネットワーク・プロセッサにＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）によって与えられる。

米国特許第６，４５７，１７２号公報

Ｃｈｅｎ， Ｍ． Ｋ．， Ｘｉａｏ， Ｆｅｎｇ Ｌｉ ， Ｌｉａｎ， Ｒ．， Ｌｉｎ， Ｊ． Ｈ．， Ｌｉｘｉａ Ｌｉｕ， Ｔａｏ Ｌｉｕ， ａｎｄ Ｊｕ， Ｒ．， "Ｓｈａｎｇｒｉ−Ｌａ： Ａｃｈｉｅｖｉｎｇ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ ｆｒｏｍ Ｃｏｍｐｉｌｅｄ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎｓ ｗｈｉｌｅ Ｅｎａｂｌｉｎｇ Ｅａｓｅ ｏｆ Ｐｒｏｇｒａｍｍｉｎｇ"， ２００５ ＡＣＭ ＳＩＧＰＬＡＮ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ （ＰＬＤＩ‘０５）， ｐｐ．２２４−２３６，２００５。

ネットワークのハードウェアに依存したプログラミングを行うと次の様な課題が生じる。すなわち、ネットワーク・プロセッサのハードウェアを意識してプログラムを記述することになり、次の様な課題が生じる。
（１）プログラミングが困難になるため、開発コストがかかり、開発期間も長期化する。また、スキルのあるプログラマはかぎられるため、プログラマを確保するのも容易ではない。
（２）ハードウェア・ベンダ、あるいはハードウェアに依存するライブラリなどを提供するソフトウェア・ベンダの非公開の独自技術に、プログラムが依存する。そのため、開発に必要な知識を得ることが困難になり、成果を公開または他社に展開するのが困難になる。

特に、高速（ワイヤ・レート）なパケット処理のためには、パケットを適切にＳＲＡＭとＤＲＡＭに格納し、データがどちらのメモリ（ＳＲＡＭ、ＤＲＡＭ）にあるかを意識したプログラミングが必要となる。特に、パケットにおけるヘッダの編集（追加、削除および／あるいは変更）などの加工が必要なときには、パケットにおけるヘッダをＳＲＡＭに格納し、加工の必要がない後続部分（残り部分）は、ＤＲＡＭに格納することが望ましい。なぜならば、パケット全体（ヘッダと残り部分）を、格納できるだけの記憶容量を有するＳＲＡＭを、ネットワーク・プロセッサ等に搭載することは、コスト面等できわめて困難であるためである。また、パケットにおけるヘッダが、ＳＲＡＭに格納されていない場合には、パケットにおけるヘッダを加工するとき、ＤＲＡＭへのアクセスが必要とされる。ＳＲＡＭに比べると、ＤＲＡＭのアクセスには時間が掛かる。すなわち、ＳＲＡＭに比べると、ＤＲＡＭのアクセス時間は長くなる。そのため、ＤＲＡＭに格納されたヘッダを加工しようとすると、ＤＲＡＭの比較的長いアクセス時間のために、ワイヤ・レートでの処理が不可能になるからである。

従って、ＳＲＡＭ、ＤＲＡＭ等のハードウェアに依存せずに、オープンな言語仕様に従って高速でパケット処理を行うことが可能なプログラムを提供することが望まれる。また、その様なプログラムを開発できる環境を提供することが望まれる。特に、プログラムにおいては、ＳＲＡＭとＤＲＡＭとを区別する必要をなくすとともに、ＳＲＡＭとＤＲＡＭのどちらに処理すべきデータがあるかをプログラミング言語処理系が管理することが望ましい。また、ＳＲＡＭとＤＲＡＭ間のデータ転送も、処理系が自動的に行う様にすることによって、プログラマの負担を軽減し、プログラミングに掛かるコストを低減させることも可能となる。さらに、プログラムが非公開の独自技術に依存しない様にすることにより、コストの更なる低減を図ることも可能となる。

パケットのヘッダを編集することを考えた場合、特許文献１におけるようにＳＲＡＭのみ、あるいはＤＲＡＭのみを首尾一貫して使用することは、高速の処理に適さない。そのため、パケットを処理するために適したメモリ（ＳＲＡＭとＤＲＡＭ）の使い分け、およびメモリ間でデータ転送を行うことが可能なオブジェクト・プログラムを生成することが可能な開発環境の提供も望まれる。

特許文献１および非特許文献１には、パケットを処理する際に、処理されるべきデータがどのメモリに格納されているかをプログラムにおいて区別しなくても良い様にすると言うことは、示唆されていない。

本発明の目的は、ハードウェア（ＳＲＡＭ、ＤＲＡＭ等）依存を低減したプログラミングが可能なプログラム処理方法を提供することにある。

本発明の前記ならびにそのほかの目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。

すなわち、パケットは、それが格納される、あるいは格納されているメモリに応じて、データ表現が付与される。例えば、メモリの種類（ＳＲＡＭ、ＤＲＡＭ）と、メモリに格納されるパケットの部分（部位）とによって、４種類（４状態）の内の１つのデータ表現がパケットに付与される。

例えば、メモリとしてＳＲＡＭだけを使用して、その全体が格納されるパケットには、キャッシュド（ｃａｃｈｅｄ）のデータ表現が付与される。また、メモリとしてＤＲＡＭだけを使用して、その全体が格納されるパケットには、アンキャッシュド（ｕｎｃａｃｈｅｄ）のデータ表現が付与される。

その全体が、ＤＲＡＭに格納され、その先頭部分だけが、ＳＲＡＭにキャッシュされるパケットに対しては、ミックスド（ｍｉｘｅｄ）のデータ表現が付与される。それが分割され、分割された一部がＳＲＡＭに格納され、残りの部分がＤＲＡＭに格納されるパケットに対しては、フラグメンテッド（ｆｒａｇｍｅｎｔｅｄ）のデータ表現が付与される。

パケットに対する処理（操作）の際に、そのパケットに付与されているデータ表現が識別され、識別したデータ表現に従った処理が実行される。これにより、パケットに対する処理を行うプログラムは、ハードウェア（ＳＲＡＭ、ＤＲＡＭ）に対する依存を低減したプログラムとすることが可能となる。

本願において開示される一実施の形態においては、パケットに対する操作によって生じるデータ表現の変化が、状態遷移により推定される。プログラムを開発するためのプログラム処理方法においては、推定したデータ表現に対応した固有のオブジェクト・プログラムが生成される。これにより、開発の効率化を図ることが可能となる。また、推定することができない場合には、そのオブジェクト・プログラムに、実行時に注意を促すコードを挿入することにより、開発のより効率化を図ることが可能となる。

本願においては、上記したデータ表現は、識別に用いられるため、識別子と見なすことができる。識別子は、各パケットに設けられている。なお、本願においては、データ表現は、単に表現と述べる場合も有る。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。

ハードウェア依存を低減したプログラミングが可能なプログラム処理方法を提供することができる。

本発明の一実施の形態に係わるネットワークの物理構成図である。 本発明の一実施の形態に係わる仮想ネットワークの構成図である。 本発明の一実施の形態に係わるコンパイラの構成図である。 本発明の一実施の形態に係わるソース・プログラムの内容を示す図である。 本発明の一実施の形態に係わる中間語プログラムの内容を示す図である。 本発明の一実施の形態に係わるパケットのデータ表現を示す図である。 本発明の一実施の形態に係わるパケットのデータ表現間の状態遷移を示す図である。 本発明の一実施の形態に係わるオブジェクト・プログラムの一部であるサブストリング（ｓｕｂｓｔｒｉｎｇ）操作の手順を示すフローチャートである。 本発明の一実施の形態に係わるオブジェクト・プログラムの一部であるサブパケット（ｓｕｂｐａｃｋｅｔ）操作の手順を示すフローチャートである。 本発明の一実施の形態に係わるオブジェクト・プログラムの一部であるコンキャット（ｃｏｎｃａｔ）操作の手順を示すフローチャートである。 本発明の一実施の形態に係わるパケットの構成図である。 仮想ネットワークの概念図である。 ネットワーク・プロセッサの構成図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部分には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態）
本発明に係わる実施の形態について説明する。先ず、ネットワーク・プロセッサが用いられるネットワークの物理的な構成を、図１を用いて説明する。図１は、仮想ネットワークの実験等をおこなうためのネットワーク全体の物理的な構成を示す構成図である。同図において、破線で囲まれた１０１はネットワーク仮想化基盤、１０２はオペレータ・コンソール、１１１はネットワーク管理サーバ（Ｎｅｔｗｏｒｋ ｍａｎａｇｅｒ）、１１２から１１５は物理ノードを示している。仮想ネットワークには、さらにゲートウェイ１１６、１１７が含まれ、上記したゲートウェイ１１６、１１７には、それぞれパーソナルコンピュータ（以下、ＰＣと称する）１１８、１１９が接続されている。この実施の形態においては、物理ノード１１２から１１５のそれぞれは、物理ノード１１２を例として示してあるが、ノードマネジャーＮｏＭ、仮想ノードマネジャーＶＮＭ、仮想リンクマネジャーＶＬＭを含んでいる。

＜実ネットワークとスライス＞
以下、管理情報が仮想ネットワークを扱う場合について、実ネットワークと仮想ネットワーク、すなわちスライスとの関係を図１、図１０を用いて説明する。図１０において、１１２１および１１２６は、実ネットワークを示しており、実ネットワーク１１２１と１１２６上のそれぞれには、物理ノード１１０１と１１１１とが存在している。これらの実ネットワーク上に生成される仮想ネットワークは、複数のスライス１１２２、１１２３、１１２４および１１２５（スライス４からスライス１）を有している。物理ノード１１０１上には、仮想ノード１１０２、１１０３および１１０４が、生成され、物理ノード１１１１上には、仮想ノード１１１２、１１１３および１１１４が生成されている。

生成されている仮想ノード１１０４、１１１４は、スライス１１２５に属し、相互に、仮想リンクによって結合されている。同様に、仮想ノード１１０２、１１１３は、スライス１１２３に属し、相互に、仮想リンクによって結合されている。スライスの構造は、実ネットワークと同一にすることも可能だが、仮想リンクはトンネル等を使用することによって物理リンクに制約されずに生成することができるため、スライスを実ネットワークとは異なる構造にすることもできる。

＜スライスとスライス情報＞
スライスは、通常、複数の仮想ノードと仮想ノード間を結ぶ仮想リンク（仮想データ転送パス）とで構成される。仮想ノードは、物理ノード上に作られるが、仮想ノード間の接続は、物理ノードの接続とは独立である。すなわち、仮想リンクは実リンクによってしばられない。それぞれの仮想ノードは、スイッチング、ルーティングをはじめとするネットワーク・プロトコルの処理機能を有するが、その機能は、その仮想ノードをふくむ物理ノードのプロトコル処理機能とは独立でありうる。

ドメイン間にまたがる仮想ネットワークの設定をおこなうために、本実施の形態においては、仮想ノードのリストと仮想リンクのリストとで構成されるスライスの構成情報が、スライス情報として、管理メッセージに包含される。スライス情報は、上記の様な仮想ネットワークにおける仮想ノードの属性やその資源量、仮想リンクの属性、仮想ノードと仮想リンクとの接続関係などで構成される情報である。ここで、仮想ノードの資源量とは、例えば、その仮想ノードに対応付けられたプロセッサ（ネットワーク・プロセッサ：ＣＰＵ）の個数やメモリの記憶容量に関する情報である。また、仮想リンクの属性とは、例えば、その仮想リンクが使用することができる帯域に関する情報である。しかしながら、かならずしもスライス情報が、そのスライスが含んでいるところの全ての仮想ノードおよび仮想リンクの情報を含んでいる必要はない。

また、スライス情報は、かならずしも仮想ネットワークに関する情報であるとはかぎらない。例えば、物理ノードや物理リンク（実データ転送パス）を管理するための情報であってもよい。この場合、スライス情報は物理ノードの設定情報や状態に関する情報、物理リンクの状態に関する情報（例えば使用可能性やトラフィック量）などの情報を含むことができる。

＜スライス情報の内容＞
本実施の形態において使用するスライスＳのスライス情報を、図２を用いて説明する。スライスＳは、イーサネット（登録商標）やインターネット・プロトコル（ＩＰ）に制約されない新しいプロトコル（以下、非ＩＰプロトコルと呼ぶ）を、実験するための仮想ネットワークである。スライス情報は、コンソール１０２（図１）を通じてネットワーク管理サーバ１１１（図１）に与えられるが、その際には、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの形式で作成して、使用する。ここでは理解を容易にするために、図を用いて示しているが、本質的にはかわらない。

スライスＳ（仮想ネットワーク２００）は、仮想ノード（１）２１３、仮想ノード（２）２１２、仮想ノード（３）２１５、仮想ノード（４）２１４、ゲートウェイ２０１、２０６によって構成されている。この実施の形態においては、仮想ノード（４）２１４と、ユーザのＰＣ２１８とが、ゲートウェイ２１６を経由して仮想リンク（１）２０１と結合されている。仮想ノード（１）２１３と仮想ノード（２）２１２とが仮想リンク（２）２０２によって結合され、仮想ノード（１）２１３と仮想ノード（３）２１５とが仮想リンク（３）２０３によって結合されている。同様に、仮想ノード（２）２１２と仮想ノード（３）２１５とが仮想リンク（４）２０４によって結合され、仮想ノード（４）２１４と仮想ノード（３）２１５とが仮想リンク（５）２０５によって結合され、仮想ノード（３）２１５とユーザのＰＣ２１９とがゲートウェイ２１７を経由して、仮想リンク（６）２０６によって結合されている。特に制限されないが、仮想ノード（１）２１３は、物理ノード１１３（図１）内に生成され、仮想ノード（２）２１２は、物理ノード１１２（図１）内に生成され、仮想ノード（３）２１５は、物理ノード１１５（図１）内に生成され、仮想ノード（４）２１４は、物理ノード１１４（図１）内に生成される。なお、図２には、物理ノード１１２（図１）と物理ノード１１４（図１）との間が物理リンクにより接続され、物理ノード１１３と物理ノード１１５との間が物理リンクで接続されている例が示されている。図２においては、物理リンクは、細線で示されており、仮想リンクは太線で示されている。

仮想ノード（１）２１３、仮想ノード（２）２１２、仮想ノード（３）２１５およびＰＣ２１９は、非ＩＰプロトコルを処理するノードである。しかし、この実施の形態においては、ＰＣ２１８は、非ＩＰプロトコルを扱うことができず、イーサネットしか扱うことができない。そのため、仮想ノード（４）２１４において、そこに設けられているプロセッサであるところのネットワーク・プロセッサを使用して、ＰＣ２１８から受信したパケットから、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダを削除して、仮想ノード（３）２１５に転送する。一方、仮想ノード（４）２１４におけるネットワーク・プロセッサは、仮想ノード（３）２１５からパケットを受信した場合、その受信したパケットに、ＭＡＣヘッダを付加して、ＰＣ２１８へ送信する。すなわち、仮想ノード（４）２１４上のネットワーク・プロセッサにおいては、ＭＡＣヘッダを編集（付加および／あるいは削除）するプログラムを動作させることになる。

このプログラムは、その開発者が高級言語によって、そのプログラムを開発し、コンパイラを使用して、それをオブジェクト・プログラムに翻訳して前記したネットワーク・プロセッサ（仮想ノード（４）上のプロセッサ）にロードさせ、実行させる。

＜コンパイラの構成＞
次に、図３を使用して、仮想ノード（１）２１３、仮想ノード（２）２１２、仮想ノード（３）２１５、仮想ノード（４）２１４のそれぞれにおけるネットワーク・プロセッサにロードされるプログラムをコンパイルするコンパイラの構成を説明する。

本実施の形態におけるコンパイラは、Ｊａｖａ（登録商標）風のパケット処理用の高級言語を、ネットワーク・プロセッサが実行可能なオブジェクト・プログラムに翻訳するソフトウェアである。このコンパイラに、開発者によって作成されたソース・プログラム３１１が与えられると、ステップ３０１により、中間語プログラム３１２へ翻訳される。翻訳された中間語プログラム３１２は、ハードウェア依存性がないプログラムである。すなわち、ハードウェア非依存の中間語プログラム３１２が生成される。中間語プログラム３１２は、次に、オブジェクト・プログラムへの翻訳のステップ３０２において、ネットワーク・プロセッサのためのオブジェクト・プログラム３１３へ翻訳される。

オブジェクト・プログラム３１３は、ネットワーク・プロセッサのハードウェア（物理的構成）に依存したプログラムである。すなわち、ステップ３０２において、ネットワーク・プロセッサの特性が考慮され、複数のデータ表現を使い分けるオブジェクト・プログラム３１３が生成される。例えば、ソース・プログラム３１１において記述されていた抽象データ構造は、ネットワーク・プロセッサのハードウェア上のデータ構造すなわちＳＲＡＭ上のデータ、ＤＲＡＭ上のデータ、ディスクリプタ等に翻訳される。また、ソース・プログラム３１１において記述されていた実行文は、ベンダ独自仕様のＣ言語または機械語に翻訳される。本実施の形態においては、コンパイルの手順を２段階としているが、１段階で行うことも可能であり、また最適化などを含む３段階以上の手順で実行することも可能である。

＜言語仕様＞
本実施の形態においては、いわゆる高級言語により、パケット処理用のプログラムが記述される。この高級言語は、Ｊａｖａに近いが、既存の高級言語とは異なる。以下、本実施の形態で用いるパケット処理用プログラム言語を、Ｓと呼ぶ。以下、言語Ｓの仕様について述べる。

言語Ｓにおいては、パケットを表現するクラス（データ型）が定義され、言語Ｓでは、そのクラス（以下、Ｐａｃｋｅｔとする）に対する自然な操作を定義することにより、パケット処理用のプログラムが作成される。既存の高級言語においては、パケット処理は、イーサネット（Ｅｔｈｅｒｎｅｔ）、ＩＰ、ＴＣＰ、ＵＤＰの様な特定のプロトコルに従うものとして定義されることが多かった。これに対して、言語Ｓにおいては、任意のプロトコルによるパケット処理を記述することができる様にするため、パケットをバイト列とみなし、パケット処理はバイト列に対する処理として実行する。ただし、パケット処理においては、バイト境界に拘束されない操作もあるが、このような操作はパケットから部分列を文字列として取り出した状態で実行するものとする。すなわち、パケットに対する操作としては定義しない。この様に、任意のプロトコルを扱えるようにすることで、例えば仮想ネットワークで用いるプロトコルの自由度を向上させることができる。

文字列は、通常はバイト列の一種であるが、その文字列に対する基本的な操作は、部分列生成（ｓｕｂｓｔｒｉｎｇ：サブストリング）と、連接（ｃｏｎｃａｔｅｎａｔｉｏｎ：コンキャティネイト）である。部分列生成は、文字列から、それが含む部分文字列を生成する操作であり、連接は、複数個の文字列を連結する処理である。

パケット処理においては、通常、２種類の部分列生成操作がおこなわれる。第１は、入力されたパケットから、一部のパケット・ヘッダが取り出される操作であり、第２は、入力されたパケットから、パケット本体すなわち一部のパケット・ヘッダを除いた部分が取り出される操作である。これらの操作はできるだけ、高速（ワイヤ・レート）で実行できるように最適化することが望ましい。これ以外の部分列生成操作、例えばパケットの途中の部分を取り出す操作もありうるが、本実施の形態においては、それに対してはコンパイラの性能上の向上は配慮をしないものとする。

これらの２種類の操作は、バイト列に対する操作としては同一のものだと考えることができるが、パケット処理においてはパケット・ヘッダとパケット本体とを区別するのは自然だと考えられるので、上記した第１の操作は、サブストリング（ｓｕｂｓｔｒｉｎｇ）と呼び、上記した第２の操作は、サブパケット（ｓｕｂｐａｃｋｅｔ）と呼んで、言語Ｓにおいては区別する。言語Ｓにおいては、文字列に対する部分列操作も存在するので、つぎの３個のメソッド（１）から（３）が存在する。ここでｆｒｏｍ、ｔｏのそれぞれは、非負整数（負とならない整数）である。

（１）Ｐａｃｋｅｔ Ｐａｃｋｅｔ．ｓｕｂｐａｃｋｅｔ（ｆｒｏｍ）：このメソッド（操作）は、「パケットの途中から末尾までの部分列をパケットとして返す」操作を行う。なお、途中は、ｆｒｏｍによって与えられる。

（２）Ｓｔｒｉｎｇ Ｐａｃｋｅｔ．ｓｕｂｓｔｒｉｎｇ（ｆｒｏｍ、ｔｏ）：このメソッドは、「パケットの途中（ｆｒｏｍからｔｏまで）の部分列を文字列として返す」操作を行う。

（３）Ｓｔｒｉｎｇ Ｓｔｒｉｎｇ．ｓｕｂｓｔｒｉｎｇ（ｆｒｏｍ、ｔｏ）：このメソッドは、「文字列の途中（ｆｒｏｍからｔｏまで）を、部分列として取り出して、文字列として返す」操作を行う。

なお、上記した第２メソッド（２）においては、パケットのｔｏで指示される部分が、ＳＲＡＭ上にあるときだけ性能を保証するものとする。その部分がＤＲＡＭ上にしか存在しないときは、次の２つのうちのいずれかの方法をとることができる。第１は、性能は低下するが、ＤＲＡＭからＳＲＡＭへ、その部分列をロードする方法である。第２は、エラーとして処理する方法である。この第２の方法の場合、ｔｏの値が、言語Ｓで記述されたプログラムをコンパイルする時に、判定できれば、コンパイル時にエラーとすることができる。しかしながら、コンパイルの時に、その値を判定できない場合には、コンパイルすることによって得たオブジェクト・プログラムを実行する際にエラーとする。すなわち、オブジェクト・プログラムの実行時エラーとする。

パケット処理における連接操作は、通常、パケット・ヘッダとパケット本体とを連結する操作である。パケット・ヘッダは、１個または複数個存在するが、それらすべてが文字列であり、それらがＳＲＡＭ上に存在しているときだけ、性能を保証する。連接操作において、パケット本体は、ＳＲＡＭ上にある必要はない。言語Ｓにおいては、文字列に対する連接操作も存在するので、次の2 個のメソッドが存在する。

（４）Ｐａｃｋｅｔ Ｐａｃｋｅｔ．ｃｏｎｃａｔ（Ｓｔｒｉｎｇ）：このメソッドは、「パケットに、Ｓｔｒｉｎｇで示されているパケットを連結し、パケットとして返す」操作を行う。

（５）Ｓｔｒｉｎｇ Ｓｔｒｉｎｇ．ｃｏｎｃａｔ（Ｓｔｒｉｎｇ）：このメソッドは、「文字列に、Ｓｔｒｉｎｇで示されている文字列を連結し、文字列として返す」操作を行う。

３個以上の文字列およびパケットの連接は、これらのメソッド（４）、（５）を繰り返して適用することによって実現することができる。なお、上記したメソッド（１）から（５）のそれぞれにおいて、先頭部分は、操作により得られたデータ型を示し、中間部分は、操作する前のデータ型を示し、記号“．”以降の後段部分は、操作内容を示している。例えば、上記したメソッド（５）を例にすると、先頭部分は、Ｓｔｒｉｎｇであり、このメソッドを実行したことにより得られるデータはそのデータ型が、文字列であることを示している。また、記号“．”前の中間部分は、Ｓｔｒｉｎｇであり、操作前のデータのデータ型が、文字列であることを示している。記号“。”以降である後段部分はｃｏｎｃａｔ（ｃｏｎｃａｔｅｎａｔｉｏｎ）であり、連結を意味している。

＜ソース・プログラム＞
コンパイラはさまざまな内容のソース・プログラムを翻訳することができる。図４には、ソース・プログラムの一例が、３１１として示されている。このプログラムは、仮想ネットワーク２００（図２）において、仮想ネットワーク２００内とＰＣ２１８（図２）との間のパケット・データ表現の差を埋めるためのプログラムである。すなわち、このプログラムは、ＮｅｔＳｔｒｅａｍ１、ＮｅｔＳｔｒｅａｍ２と命名されたデータ・ストリームを入出力する。データ・ストリームＮｅｔＳｔｒｅａｍ１、ＮｅｔＳｔｒｅａｍ２に対する処理は、図９に、模式的に示されている。図９を参照にしながら、プログラム３１１により実施される処理を説明する。

ＮｅｔＳｔｒｅａｍ１経由で、仮想ノード（３）２１５（図２）から入力されたパケット９０１は、プログラム３１１（図３）においてパケット・ヘッダ（ＭＡＣヘッダ：Ｈｅａｄｅｒ）を追加され、パケット９０２として、ＮｅｔＳｔｒｅａｍ２経由で、ＰＣ２１８（図２）に出力される。一方、ＰＣ２１８から、ＮｅｔＳｔｒｅａｍ２経由で入力されたパケット９０４は、プログラム３１１により、パケット・ヘッダ（ＭＡＣヘッダ：Ｈｅａｄｅｒ）が削除され、パケット９０３として、ＮｅｔＳｔｒｅａｍ１経由で、仮想ノード（３）２１５に出力される。この様にすることにより、非ＩＰプロトコルを扱わないＰＣ２１８と非ＩＰプロトコルの仮想ネットワーク２００（図２）との間でパケットの送受信が可能となる。

次に、プログラム３１１の意味を、部分毎に説明する。このプログラムは、図９に示す様に、２個のパケット入出力（ネットワーク・インターフェース）ＮｅｔＳｔｒｅａｍ１、ＮｅｔＳｔｒｅａｍ２をもち、ＮｅｔＳｔｒｅａｍ１から入力されたパケットには、ＭＡＣヘッダ（Ｈｅａｄｅｒ）を付加して、ＮｅｔＳｔｒｅａｍ２へ出力する。一方、ＮｅｔＳｔｒｅａｍ２から入力されたパケットからは、ＭＡＣヘッダ（Ｈｅａｄｅｒ）を削除して、ＮｅｔＳｔｒｅａｍ１へ出力するプログラムである。

ソース・プログラム３１１（図４）には、各行の先頭に行番号がつけられているが、これは本来のソース・プログラムには含まれないものであり、説明の便宜上付けたものである。ソース・プログラム３１１は、インポート宣言４０１、４０２と、クラス宣言４０３から４２３とで構成されている。インポート宣言４０１、４０２のそれぞれにおいて、このプログラムが、パケット・ストリームＮｅｔＳｔｒｅａｍ１とＮｅｔＳｔｒｅａｍ２を入出力することを宣言している。

ＡｄｄＲｅｍＭＡＣクラスのクラス宣言４０３〜４２３においては、まず変数宣言４０４、４０５でパケット・ストリーム用の変数ｏｕｔ１、ｏｕｔ２が宣言されている。ＡｄｄＲｅｍＭＡＣクラスのオブジェクトを生成するコンストラクタが、行４０６〜４１０において宣言されている。行４０６において宣言されている引数ｐｏｒｔ１およびｐｏｒｔ２は、生成されたＡｄｄＲｅｍＭＡＣクラスのオブジェクトが、送受信するパケット・ストリームを表している。ｐｏｒｔ１ストリームに入力されたパケットは、記号“＞”の直後に記述されたｐｒｏｃｅｓｓ１というメソッドによって処理され、ｐｏｒｔ２ストリームに入力されたパケットは、記号“＞”の直後に記述されたｐｒｏｃｅｓｓ２というメソッドによって処理される。

行４０８、４０９においては、変数ｏｕｔ１にｐｏｒｔ１ストリームを代入し、変数ｏｕｔ２にｐｏｒｔ２ストリームを代入している。すなわち、ＡｄｄＲｅｍＭＡＣクラスにおいて、ｏｕｔ１に出力されるパケットが、ｐｏｒｔ１ストリームに出力され、ｏｕｔ２に出力されるパケットが、ｐｏｒｔ２ストリームに出力されることを意味している。

ｐｒｏｃｅｓｓ１メソッドは、行４１１〜４１４において定義されている。すなわち、ｐｒｏｃｅｓｓ１メソッドは、行４１１に記述されている様に、引数としてパケットｉを受け取るが、ｐｏｒｔ１にストリームの要素すなわちパケットが入力される毎に、ｐｒｏｃｅｓｓ１が実行され、そのパケットがｉとして入力される。行４１２においては、まず、（ｉ．ｓｕｂｓｔｒｉｎｇ（０，１４））によってパケットｉの先頭（バイト０）から１４バイト目までの部分列が文字列として生成され、ｃｏｎｃａｔ操作により、生成された文字列とパケットｉとが連接され、連結されたパケットが、ｎｅｗ Ｐａｃｋｅｔ（）によって生成される。この生成されたパケットは、ｏに代入され、行４１３において、ストリームｏｕｔ２に出力される。

ｐｒｏｃｅｓｓ２メソッドは、行４１５〜４１８において定義されている。すなわち、ｐｒｏｃｅｓｓ２メソッドは、行４１５に記述されている様に引数として、パケットｉを受け取るが、ｐｏｒｔ２にストリームの要素すなわちパケットが入力される毎に、ｐｒｏｃｅｓｓ２が実行され、そのパケットがｉとして入力される。行４１６においては、まずｉ．ｓｕｂｐａｃｋｅｔ（１４）によってパケットｉの１４バイト目から末尾までの部分列がパケットとして生成される。生成されたパケットは、ｏに代入され、行４１７においてストリームｏｕｔ１に出力される。

行４１９〜４２２において定義された関数ｍａｉｎは、ＡｄｄＲｅｍＭＡＣクラスの唯一のインスタンス（ｓｉｎｇｌｅｔｏｎ）が生成される際に実行される。行４２０〜４２１において、ＮｅｔＳｔｒｅａｍ１、ＮｅｔＳｔｒｅａｍ２に対応するオブジェクトが生成され、外部ネットワークと接続される。これらのオブジェクトは、ＡｄｄＲｅｍＭＡＣクラスのコンストラクタに渡される。すなわち、ＮｅｔＳｔｒｅａｍ１からの入力は、ｐｒｏｃｅｓｓ１メソッドにおいて処理され、そこからの出力がＮｅｔＳｔｒｅａｍ２に出力される。一方、ＮｅｔＳｔｒｅａｍ２からの入力は、ｐｒｏｃｅｓｓ２メソッドにおいて処理され、そこからの出力がＮｅｔＳｔｒｅａｍ１に出力される。

上記したソース・プログラム３１１において、行４１２における「ｉ．ｓｕｂｓｔｒｉｎｇ（０，１４）」が、上記したメソッド（２）に該当し、同じ行４１２における「ｉ．ｃｏｎｃａｔ（）」が、上記したメソッド（４）に該当する。また、行４１６における「ｉ．ｓｕｂｐａｃｋｅｔ（１４）」が、上記したメソッド（１）に該当する。

＜中間語プログラム＞
図５には、図４のソース・プログラム３１１を翻訳して得られる中間語プログラム３１２が記述されている。図５においては、中間語プログラム３１２が、文字列の形式で記述されているが、実際には木構造のデータである。すなわち、表現｛ｋｅｙ１＝＞ｖａｌｕｅ１、ｋｅｙ２＝＞ｖａｌｕｅ２、・・・｝は、木のノード（親データ）において、ｋｅｙ１とラベルづけされた子データの値が、ｖａｌｕｅ１であり、ｋｅｙ２とラベルづけされた子データの値が、ｖａｌｕｅ２であり、以下同様に子データが表現されていることを表している。

中間語プログラム３１２は、ソース・プログラム３１１（図４）と同様にハードウェア依存のないプログラムである。ソース・プログラム３１１（図４）における行４０１〜４０２が、中間語プログラム３１２（図５）の行５０１に翻訳される。また、ソース・プログラム３１１（図４）における行４０３〜４２３が、中間語プログラム３１２（図５）の行５０３〜５５２に翻訳されている。すなわち、行４０４〜４０５（図４）は、行５０５〜５０６（図５）に翻訳され、行４０６〜４１０（図４）は、行５４０〜５５２（図５）に翻訳され、行４１１〜４１４（図４）は、行５１４〜５２７（図５）に翻訳される。同様に、行４１５〜４１８（図４）は、行５２８〜５３９（図５）に翻訳され、行４１９〜４２２（図４）は、行５０７〜５１１（図５）に翻訳されている。

ステップ３０１（図３） による翻訳、すなわちソース・プログラム３１１（図４）から中間語プログラム３１２（図 ５）への翻訳は、通常のコンパイラにおけるのと同様に、おもに文字列として記述された多様なソース・プログラムの構文を、ステップ３０１において統一的な木構造にするために行っている。

＜パケット・データ表現＞
図６には、ネットワーク・プロセッサにおける４種類のパケット・データ表現が示されている。この４種類のパケット・データ表現を説明する前に、ネットワーク・プロセッサの構成を説明する。図１１は、本実施の形態で用いられるネットワーク・プロセッサの構成を示すブロック図である。

図１１において、１１００は、特に制限されないが１個の半導体集積回路装置として構成されたネットワーク・プロセッサである。ネットワーク・プロセッサ１１００は、複数のプロセッサ（ＣＰＵ）コア１１０１、１１０２と、ＳＲＡＭ１１０３と、データバス１１０４とを具備している。上記したＣＰＵコア１１０１、１１０２と、ＳＲＡＭ１１０３とは、データおよびアドレスのバス１１０４を介して互いに接続されている。また、ネットワーク・プロセッサ１１００である半導体集積回路装置の外部には、ＤＲＡＭ１１０５が設けられ、このＤＲＡＭ１１０５も、上記したデータおよびアドレスのバス１１０４に接続されている。特に制限されないが、ＤＲＡＭ１１０５には、ＣＰＵコア１１０１および１１０２を動作させるためのプログラムも格納される。ネットワーク・プロセッサ１１００とＤＲＡＭ１１０５とによって、処理装置が構成されていると見なすこともできる。

ＣＰＵコア１１０１および１１０２は、ＤＲＡＭ１１０５に格納されたプログラムに従って、ＳＲＡＭ１１０３およびＤＲＡＭ１１０５を用いながら、パケットに対する処理等を行う。

ＳＲＡＭ１１０３は、ＤＲＡＭ１１０５に比べて、そのアクセス時間が早い。しかしながら、半導体集積回路装置に内蔵可能な記憶容量には、制限が生じる。すなわち、ネットワーク・プロセッサ１１００のコストアップを抑制するためには、大記憶容量のＳＲＡＭをネットワーク・プロセッサ１１００に内蔵させることが困難となる。また、ネットワーク・プロセッサ１１００の外部に、ＤＲＡＭと同様に、ＳＲＡＭを設けることも可能であるが、ＤＲＡＭと同じ記憶容量のＳＲＡＭは、ＤＲＡＭに比べて、コストアップとなる。そのため、ネットワーク・プロセッサ１１００の外部にＳＲＡＭを設けるようにしても、コストアップの観点から、制限が生じる。

上記したＤＲＡＭ１１０５には、例えばパケット処理用のオブジェクト・プログラムが、格納される。この場合、該オブジェクト・プログラムは、図３で説明した様にして生成される。このＤＲＡＭ１１０５は、プログラム（パケット処理用のオブジェクト・プログラム）を格納した記憶媒体と見なすことができる。

図６に戻り、４種類のパケット・データ表現について説明を行う。４種類のパケット・データは、同一のデータ型（パケット）である。そのため、これらは、ソース・プログラムにおいては、同一のクラスに属するオブジェクトであり、同一の型のデータである。しかしながら、本実施の形態においては、パケットの高速処理のために、パケット・サイズやパケットの入力条件、処理条件などに応じて、異なる表現が使用される。図６において、６０１は、ＳＲＡＭ（例えば、図１１の１１０３）のメモリ空間を示しており、６０２は、ＤＲＡＭ（例えば、図１１の１１０５）のメモリ空間を示している。パケットを受信したとき、あるいはパケットを操作しているとき、パケットを構成するデータ（例えば、図９に示したヘッダＨｅａｄｅｒと、本体Ｂｏｄｙ）は、ＳＲＡＭおよび／あるいはＤＲＡＭに格納される。

上記した４種類のデータ表現とは、後で述べるが、（１）キャッシュド（Ｃａｃｈｅｄ）表現、（２）ミックスド（Ｍｉｘｅｄ）表現、（３）フラグメンテッド（Ｆｒａｇｍｅｎｔｅｄ）表現、（４）アンキャッシュド（Ｕｎｃａｃｈｅｄ）表現である。以下では、上記した（１）はＣａｃｈｅｄ表現、（２）はＭｉｘｅｄ表現、（３）はＦｒａｇｍｅｎｔｅｄ表現、（４）はＵｎｃａｃｈｅｄ表現とも称する。

（１）Ｃａｃｈｅｄ表現のパケットは、ＳＲＡＭだけに格納されたパケットを意味する。言い換えるならば、パケット全体が、ＳＲＡＭだけにキャッシュされている場合、そのパケットは、Ｃａｃｈｅｄ表現とされる。（２）Ｍｉｘｅｄ表現のパケットは、その全体がＤＲＡＭに格納され、その先頭だけがＳＲＡＭにキャッシ（Ｃａｃｈｅ）されたパケットである。（３）Ｆｒａｇｍｅｎｔｅｄ表現は、パケットが複数に分断（分割）され、それぞれの断片が、ＤＲＡＭに格納されているパケットに対して与えられる。この場合、断片はＤＲＡＭにおいて、非連続のアドレス空間に格納される。また、この表現においては、断片の一部が、ＳＲＡＭに格納されている場合も含む。（４）Ｕｎｃａｃｈｅｄ表現は、その全体が、ＤＲＡＭに格納されたパケットに対して与えられる。パケットが、これらの４種類の表現のいずれに該当するかは、そのパケットが指定するポインタに含まれている識別子によって判定される。

図６において、図の左側には、パケットに対応し、パケットを指定するポインタが、（１）から（４）として示されている。同図において、（１）は、Ｃａｃｈｅｄ表現のパケット（Ｃａｃｈｅｄ ｐａｃｋｅｔ）であり、それを指定するポインタが６１１として示されており、（２）は、Ｍｉｘｅｄ表現のパケット（Ｍｉｘｅｄ ｐａｃｋｅｔ）であり、それを指定するポインタが６１２として示されている。同様に、（３）は、Ｆｒａｇｍｅｎｔｅｄ表現のパケット（Ｆｒａｇｍｅｎｔｅｄ ｐａｃｋｅｔ）であり、それを指定するポインタが６１３として示されており、（４）は、Ｕｎｃａｃｈｅｄ表現のパケット（Ｕｎｃａｃｈｅｄ ｐａｃｋｅｔ）であり、それを指定するポインタが６１４として示されている。

ポインタ６１１、６１２、６１３および６１４のそれぞれは、それがどの表現を示しているかを表す識別子を格納するフィールド、パケットのサイズを示すサイズ情報（ｓｉｚｅ）を格納するフィールド、ＳＲＡＭあるいはＤＲＡＭの格納先（例えば、アドレス）を指定する情報を格納するフィールドを有している。また、Ｆｒａｇｍｅｎｔｅｄ表現の場合には、複数の断片がＤＲＡＭ（一部がＳＲＡＭの場合もある）に格納されるため、断片数に関する情報を格納するフィールド＃が設けられている。

パケットにどの表現を割り当てるかは、そのパケットの入力時に、ハードウェアおよびソフトウェア (すなわち実行時ルーティンとコンパイラ) によって選択され、決定される。すなわち、パケットのどの部分ＳＲＡＭおよび／あるいはＤＲＡＭにおくかは、基本的にネットワーク・プロセッサのハードウェアによって決められる。言語Ｓにおいては、その処理の都合によりソフトウェアによって、表現は調整される。決められたあるいは調整された表現は、識別子として、そのパケットに対応するポインタの該当フィールドに格納される。該当するフィールドに格納される識別子としては、特に制限されないが、例えば、上記（１）のパケットに対応するポインタに対しては、Ｃａｃｈｅｄが用いられ、上記（２）に対しては、Ｍｉｘｅｄが用いられ、上記（３）に対しては、Ｆｒａｇが用いられ、上記（４）に対しては、Ｕｎｃａｃｈが用いられる。

パケットのデータが、ＳＲＡＭおよび／あるいはＤＲＡＭに格納される際、上記した（１）および（２）の場合には、ＳＲＡＭ（図１１の１１０３）に構造体が形成されて、格納される。すなわち、（１）Ｃａｃｈｅｄ表現のパケットの場合には、ＳＲＡＭのアドレス空間に構造体６２１が形成され、パケット全体が、構造体６２１内のデータ６２２（ｃａｃｈｅｄ ｄａｔａ）として格納される。また、（２）Ｍｉｘｅｄ表現のパケットの場合には、そのパケット全体がＤＲＡＭ（図１１の１１０５）のアドレス空間６０２内のアドレス領域に、データ６２５（ｓｔｏｒｅｄ ｄａｔａ）として格納される。また、この場合、Ｍｉｘｅｄ表現に対応した構造体６２３が、ＳＲＡＭのアドレス空間６０１に形成される。形成された構造体６２３には、パケットの先頭におけるデータが、キャッシュされ、キャッシュデータ（ｃａｃｈｅｄ ｄａｔａ）６２６として格納される。さらに構造体６２３には、パケット全体を格納したＤＲＡＭのアドレス空間内のアドレスを指定するポインタ情報６２４が格納される。上記（１）および（２）で形成された構造体は、ポインタにより指定される。すなわち、Ｃａｃｈｅｄ表現のパケットの格納に対応して形成された構造体６２１は、Ｃａｃｈｅｄ表現のポインタ６１１により指定され、Ｍｉｘｅｄ表現のパケットの格納に対応して形成された構造体６２３は、Ｍｉｘｅｄ表現のポインタ６１２により指定される。これにより、各表現に合わせて、ポインタから構造体を把握し、パケットの格納先を把握することができる。

格納されるパケットが、（３）Ｆｒａｇｍｅｎｔｅｄ表現のパケットの場合、パケットが複数に分断されているため、複数の断片が、ＤＲＡＭ内のアドレスにデータ（ｓｔｏｒｅｄ ｄａｔａ１〜３）６３０、６３２、６３１として、分散されて格納される。この場合にも、ＳＲＡＭのアドレス空間には、分散されて格納されたＤＲＡＭ内のアドレスを指定するポインタ６２７、６２８、６２９の配列が格納される。本明細書では、これらの断片へのアドレスからなる配列をポインタ配列と呼ぶ。図６においては、すべての断片がＤＲＡＭに格納されているが、一部またはすべての断片がＳＲＡＭに格納されている場合もある。この場合にも、ポインタ配列で、格納したアドレスを管理する。このポインタ配列は、Ｆｒａｇｍｅｎｔｅｄ表現のポインタ６１３により指定される。従って、ポインタ６１３から、分断されて格納されているパッケージのデータを把握することができる。

格納されるパケットが、（４）Ｕｎｃａｃｈｅｄ表現のパケットの場合、パケット全体が、データ（ｓｔｏｒｅｄ ｄａｔａ）６３３としてＤＲＡＭに格納される。この場合には、Ｕｎｃａｃｈｅｄ表現のポインタ６１４には、パケット全体を格納したＤＲＡＭのアドレスを指定するアドレス情報が、該当するフィールドに格納される。これにより、Ｕｎｃａｃｈｅｄ表現のパケットであっても、ポインタ６１４により、格納先を把握することができる。

図 6 においては、Ｃａｃｈｅｄ表現およびＭｉｘｅｄ表現におけるＳＲＡＭ上の構造体６２１および６２３は、同一の構造をしている。しかしながら、これらの構造体は異なる様にしてもよい。例えば、構造体６２１には、ＤＲＡＭのアドレスを指定するポインタとして、０を設定し、この値が無視される様にすればよいが、他の値を設定するようにしてもよい。また、構造体はパケットだけでなく文字列を表現することもできる。なお、キャッシュされたデータは、ＳＲＡＭのメモリ空間６０１において、連続した領域に格納される。

これらの構造体６２１、６２３を、本明細書では、ディスクリプタと呼ぶ。上記した様に、ディスクリプタはＳＲＡＭ上に形成され、パケットの先頭部分の値を含む。また、ディスクリプタ６２３は、ＤＲＡＭのアドレスを指定するポインタも含む。ＤＲＡＭへのポインタは、ディスクリプタがＣａｃｈｅｄ表現のパケットだけを表すとき、あるいは文字列を表すときは使用されない。ディスクリプタがＤＲＡＭへのポインタを含むときは、ＤＲＡＭ上でのデータのサイズを示すサイズ情報６２０が含まれる。また、図６においては、Ｆｒａｇｍｅｎｔｅｄ表現におけるポインタ６１３は、ポインタ配列の要素数＃を示す情報を格納するフィールド６１５を含んでいる。

＜データ表現間の状態遷移＞
図７は、１個のパケット・データを入力し、１個のパケット・データを出力する操作（演算）における入力パケットと出力パケットとのデータ表現の関係を表す図である。図７においては、データ表現を状態とみなした状態遷移の形で記述している。コンパイラは、図４のソース・プログラム３１１からオブジェクト・プログラム３１２（図３）の一部を生成する際に、この状態遷移と等価なデータ構造を使用することにより、各操作の適用前の事前条件とその適用後の事後条件との関係を把握することが可能となる。その方法については後述する。なお、この状態遷移は、パケット処理プログラム全体あるいはプロセッサ全体の状態遷移ではなく、１個のパケットに関する状態遷移を表している。

ここで第１に、Ｃａｃｈｅｄ状態（入力のパケットが、Ｃａｃｈｅｄ表現のとき）７０１のパケットに、サブパケット（ｓｕｂｐａｃｋｅｔ）操作を適用すると、その結果はＣａｃｈｅｄ状態となる。すなわち、パケット全体がＳＲＡＭに格納されているときに、サブパケット（ｓｕｂｐａｃｋｅｔ）操作を行っても、生成されるパケットは、必ず全体がＳＲＡＭに格納される。従って、Ｃａｃｈｅｄ状態のままである。

第２に、Ｃａｃｈｅｄ状態７０１のパケットに、コンキャット（ｃｏｎｃａｔ）操作を適用すると、結果はＦｒａｇｍｅｎｔｅｄ状態（パケットが、Ｆｒａｇｍｅｎｔｅｄ表現）７０４となる。すなわち、Ｃａｃｈｅｄ状態７０１のパケットの前に文字列を連接するときは、連接すべき文字列をそのパケットのキャッシュされたデータ６２２（図６）の直前に格納できるだけの領域を確保することは通常はできない。そのため、２個の断片（要素）を含むＦｒａｇｍｅｎｔｅｄ状態７０４のデータ表現を生成し（Ｆｒａｇｍｅｎｔｅｄ７０４状態に遷移）、それらのデータを指示するポインタを断片として格納する。

第３に、Ｍｉｘｅｄ状態（パケットが、Ｍｉｘｅｄ表現）７０３のパケットに、サブパケット（ｓｕｂｐａｃｋｅｔ）操作を適用すると、結果は、Ｍｉｘｅｄ状態７０３またはＵｎｃａｃｈｅｄ状態（パケットが、Ｕｎｃａｃｈｅｄ表現）７０２になる。すなわち、サブパケット（ｓｕｂｐａｃｋｅｔ）操作によって、ＳＲＡＭ上のデータが一部の残されるときは、Ｍｉｘｅｄ状態７０３に遷移し、それがすべて除去されるときはＵｎｃａｃｈｅｄ状態７０２に遷移する。

第４に、Ｍｉｘｅｄ状態７０３のパケットにコンキャット（ｃｏｎｃａｔ）操作を適用すると、結果は、Ｆｒａｇｍｅｎｔｅｄ状態７０４となる。すなわち、Ｍｉｘｅｄ状態７０３のパケットを含むＳＲＡＭおよびＤＲＡＭの領域の直前に、連結すべき文字列を格納することができないので、Ｆｒａｇｍｅｎｔｅｄ状態７０４に遷移（変換）する必要がある。

第５に、Ｕｎｃａｃｈｅｄ状態７０２のパケットに、サブパケット（ｓｕｂｐａｃｋｅｔ）操作を適用すると、結果はＵｎｃａｃｈｅｄ状態７０２となる。すなわち、パケット全体が、ＤＲＡＭに格納されているときに、サブパケット（ｓｕｂｐａｃｋｅｔ）操作を行っても、生成されるパケットは必ず全体がＤＲＡＭに格納されているので、Ｕｎｃａｃｈｅｄ状態のままである。

第６に、Ｕｎｃａｃｈｅｄ状態７０２のパケットに、コンキャット（ｃｏｎｃａｔ：ｎｅｗ Ｐａｃｋｅｔ）操作を適用すると、結果はＭｉｘｅｄ状態７０３またはＦｒａｇｍｅｎｔｅｄ状態７０４となる。すなわち、パケットの前に、連接される文字列が、ＳＲＡＭ上に存在していれば、元のパケットはＤＲＡＭ上にあるので、そこへのポインタをディスクリプタ内に格納することによって、Ｍｉｘｅｄ表現を生成することができる。

第７に、Ｆｒａｇｍｅｎｔｅｄ状態７０４のパケットに、サブパケット（ｓｕｂｐａｃｋｅｔ）操作を適用するのは困難である。そのため、このような操作は状態遷移図に記述していない。この様な場合、すなわち、サブパケット（ｓｕｂｐａｃｋｅｔ）操作が指定された時はエラーとするか、または性能低下を許容し、パケット・データの一部を、ＤＲＡＭからＳＲＡＭにロードしてから、扱う様にする。

＜オブジェクト・プログラム＞
図８Ａ、図８Ｂおよび図８Ｃには、図４のソース・プログラム３１１からオブジェクト・プログラム３１３（図３）の一部を生成する際に使用されるオブジェクト・プログラム・テンプレートをあらわすフローチャートが記述されている。これらのオブジェクト・プログラム・テンプレートは、データ表現がコンパイル時には不明なときにも適用できるが、データ表現が、Ｃａｃｈｅｄ、Ｍｉｘｅｄ、Ｕｎｃａｃｈｅｄ、Ｆｒａｇｍｅｎｔｅｄのいずれか確定すればその一部を省略することが可能である。これにより、より最適化されたオブジェクト・プログラムを生成することができる。また、データ表現が確定しないが、いくつかの可能性が排除されるときにも、排除されるデータ表現に対応する部分を省略することによって、より最適化されたオブジェクト・プログラムを生成することができる。

＜ｓｕｂｓｔｒｉｎｇのオブジェクト・プログラム・テンプレート＞
図８Ａには、サブストリング（ｓｕｂｓｔｒｉｎｇ）操作のオブジェクト・プログラム・テンプレート８１０のフローチャートが示されている。図８Ａを用いて、このオブジェクト・プログラム・テンプレート８１０を説明する。このテンプレートが表現するオブジェクト・プログラムには、このプログラムの実行に際して、入力されたパケットのポインタｐと、求めるべき部分列の範囲を指定するデータが入力される（ステップ８１１）。求めるべき部分列の範囲は、ｆｒｏｍ、ｔｏ−１で与えられる。パケットに対するサブストリング（ｓｕｂｓｔｒｉｎｇ）操作は、上記したメソッド（２）に該当する。求めるべき部分列の範囲を指定するところの変数ｆｒｏｍおよびｔｏは、メソッド（２）を呼び出した際に、与えられる。メソッド（２）でも説明した様に、変数ｆｒｏｍおよびｔｏは、負とならない整数である。なお、ｔｏ−１は、変数ｔｏから１を減算した値を意味する。ポインタｐは、図６において説明したポインタを意味する。すなわち、ポインタｐは、入力されたパケットが、Ｃａｃｈｅｄ表現、Ｍｉｘｅｄ表現、Ｆｒａｇｍｅｎｔｅｄ表現およびＵｎｃａｃｈｅｄ表現のいずれかに応じて、Ｃａｃｈｅｄ、Ｍｉｘｅｄ、Ｆｒａｇ、Ｕｎｃａｃｈを示す識別子を有している。なお、本明細書においては、ポインタｐは、パケット・ポインタｐと称することもある。

次に、ステップ８１２において、文字列ポインタｓが初期化され、文字列ポインタｓが含むサイズ・フィールドｓｉｚｅに、変数ｔｏ―変数ｆｒｏｍの値が代入される。すなわち、結果としてえられる文字列のサイズが、ｔｏ―ｆｒｏｍとされる。ステップ８１３において、入力されたパケットのポインタ（パケット・ポインタ）ｐの識別子から、入力されたパケットのデータ表現を判定する。識別子が、Ｍｉｘｅｄであれば、次にステップ８１４が実行され、Ｃａｃｈｅｄであれば、次にステップ８１５が実行され、これ以外すなわち識別子がＵｎｃａｃｈあるいはＦｒａｇであれば、ステップ８６３が実行される。ステップ８６３においては、実行時エラーとしてプログラム３１３の実行を終了する様な所定のコードに変換して、組み込む。ただし、作成したプログラム３１３の実行効率が低下しても、それを実行するべきであれば、エラーで終了するかわりに、ＤＲＡＭから部分列の値をＳＲＡＭにロードして、結果として返す様にしてもよい。

ステップ８１４においては入力パケット・ポインタｐが含むアドレス（図６においては、構造体あるいはポインタ配列を指定するアドレス）を、文字列ポインタｓに含まれているアドレス用のフィールドにコピーする。これにより、パケット・ポインタｐと文字列ポインタｓは、同一の領域を共有することになる。しかしながら、サブストリング（ｓｕｂｓｔｒｉｎｇ）操作においては、列の値を書き換えないため、このように同一の領域を参照することができる。ステップ８１４が終了すると、文字列ポインタｓの値を、戻り値として、サブストリング（ｓｕｂｓｔｒｉｎｇ）操作の実行は終了する。

一方、ステップ８１５が実行された場合には、ステップ８１５において、文字列ポインタｓに含まれているアドレス用のフィールドに、パケット・ポインタｐが含むアドレスとｆｒｏｍとを加算した値を代入する。すなわち、Ｃａｃｈｅｄ表現のパケットにおいては、ポインタが含むアドレスを、ｆｒｏｍだけ進めたものをアドレスとして有するポインタを返す。この場合にも、パケット・ポインタｐと文字列ポインタｓは、同一の領域を共有する。ステップ８１５が終了すると、文字列ポインタｓの値を戻り値として、サブストリング（ｓｕｂｓｔｒｉｎｇ）操作の実行は終了する。

なお、ステップ８１１において、与えられたｆｒｏｍとｔｏとの間の値（範囲）が、適切な値で有るかチェックする様にしてもよい。この様にすることにより、エラーの指摘が可能となる。一方、この実施の形態の様に、チェックを省略することにより、効率化を図ることが可能となる。

＜ｓｕｂｐａｃｋｅｔのオブジェクト・プログラム・テンプレート＞
次に、サブパケット（ｓｕｂｐａｃｋｅｔ）操作のオブジェクト・プログラム・テンプレート８２０の意味を、図８Ｂを用いて、説明する。このテンプレートが表現するオブジェクト・プログラムには、ステップ８２１に記述したように、パケット・ポインタｐ、求めるべき部分列の先頭位置を示すｆｒｏｍが、入力される。このオブジェクト・プログラム８２０は、上記したメソッド（１）に対応し、変数ｆｒｏｍは、非負整数で与えられる。なお、求めるべき部分列の末尾は、パケット・ポインタｐと一致するため、入力はない。

実行が開始されると、ステップ８２２において、パケット・ポインタｐ’が初期化される。初期化後、パケット・ポインタｐ’が含むサイズ・フィールドｓｉｚｅに、ｓｉｚｅ０―ｆｒｏｍの値が代入される。すなわち、結果として得られるパケットのサイズを、ｓｉｚｅ０―ｆｒｏｍとする。ここで、ｓｉｚｅ０は、入力されたパケット・ポインタｐにより示されていたパケットのサイズであり、パケット・ポインタｐに含まれるサイズ・フィールドｓｉｚｅに格納されている値である。

ステップ８２３においては、入力パケット・ポインタｐのデータ表現を判定する。データ表現の判定は、図８Ａで述べたのと同様に、識別子を判定することにより、行われる。入力されたパケットのデータ表現が、Ｍｉｘｅｄ表現であれば、次にステップ８２４が実行される。また、データ表現が、Ｃａｃｈｅｄ表現あるいはＵｎｃａｃｈｅｄ表現であれば、次にステップ８２９が実行される。これら以外、すなわちＦｒａｇｍｅｎｔｅｄ表現であれば、ステップ８７５が実行される。ステップ８７５においては、オブジェクト・プログラムの実行時にエラーとして、プログラム３１３の実行を終了する。ただし、実行効率が低下しても実行するべきであれば、図８Ａで述べたとのと同様に、エラーで終了するかわりにＤＲＡＭから部分列の値を、ＳＲＡＭにロードして、結果として返す様にしてもよい。

ステップ８２４においては、サブパケット（ｓｕｂｐａｃｋｅｔ）操作を実行することによって、ＳＲＡＭに格納されていた部分が、全て無くなるかどうかの判定が行われる。これは、ＳＲＡＭに格納されている部分が、ｆｒｏｍで示されているバイト以下であるか否かの判定を行うことにより達成される。すなわち、ＳＲＡＭに格納されている部分が、ｆｒｏｍで示されているバイト以下であれば、サブパケット（ｓｕｂｐａｃｋｅｔ）操作を実行することによって、パケットの先頭からＤＲＡＭだけに格納された状態になる。この判定の結果、ＳＲＡＭ部分に残っていると判定した場合には、次にステップ８２５が実行される。一方、残っていないと判定した場合には、次にステップ８２７が実行される。

ステップ８２５において、パケット・ポインタｐ’のデータ表現を、Ｍｉｘｅｄ表現とする。すなわち、パケット・ポインタｐ’のデータ表現フィールドに、Ｍｉｘｅｄという値（例えば整数値）を識別子として代入する。次に、ステップ８２６において、パケット・ポインタｐ’に含まれる指示アドレス（ＳＲＡＭにおける構造体：ディスクリプタを指定するアドレス）を格納するフィールドへ、入力パケット・ポインタｐの指示アドレスをコピーする。すなわち、Ｍｉｘｅｄ表現において、パケット・ポインタｐ’は、ディスクリプタの先頭を指示するべきなので、指定アドレスの値（ポインタの値）は変化しない。パケットの先頭位置はディスクリプタにふくまれるサイズ（この操作によって変化しない）と、ポインタｐ’が含むサイズとの差によって表現される。ステップ８２６が終了すると、パケット・ポインタｐ’の値を、戻り値として、サブパケット（ｓｕｂｐａｃｋｅｔ）操作の実行は終了する。

ステップ８２７において、パケット・ポインタｐ’のデータ表現をＵｎｃａｃｈｅｄ表現に設定する。すなわち、ポインタｐ’のデータ表現フィールドに、Ｕｎｃａｃｈという値（例えば整数値）を、識別子として代入する。次に、ステップ８２８において、パケット・ポインタｐ’の指示アドレスを、入力パケット・ポインタｐが指示するディスクリプタがふくむＤＲＡＭへのポインタの値（ｄとする）にｆｒｏｍの値を加算したものとする。ここで、上記したポインタの値ｄは、入力パケット・ポインタｐが指すパケットの先頭アドレスであるから、パケット・ポインタｐ’は、パケットの先頭からｆｒｏｍバイト目を指示するようになる。ステップ８２８が終了すると、パケット・ポインタｐ’の値を、戻り値として、サブパケット（ｓｕｂｐａｃｋｅｔ）操作の実行は終了する。

ステップ８２９においては、ポインタｐ’のデータ表現を、入力パケット・ポインタｐのそれと一致させる。すなわち、ポインタｐ’のデータ表現フィールドへ、入力パケット・ポインタｐのデータ表現フィールドに格納されている値を、識別子として代入する。次に、ステップ８３０において、ポインタｐ’の指示アドレスを格納するフィールドへ、入力パケット・ポインタｐの指示アドレスとｆｒｏｍとして示されている値とを加算して、加算により得た値を格納する。すなわち、入力パケット・ポインタｐによる指示アドレスを、ｆｒｏｍとして示されている値だけ進め、進めた指示アドレスが、ポインタｐ’から出力される様にする。ステップ８３０が終了すると、ポインタｐ’の値をパケット・ポインタとして、戻り値にし、サブパケット（ｓｕｂｐａｃｋｅｔ）操作の実行は終了する。

＜ｃｏｎｃａｔのオブジェクト・プログラム・テンプレート＞
次に、図８Ｃを用いて、コンキャット（ｃｏｎｃａｔ）操作のオブジェクト・プログラム・テンプレート８４０の意味を説明する。このテンプレートが表現するオブジェクト・プログラムは、ステップ８４１に記述した様に、入力された文字列のポインタｓと入力されたパケットのパケット・ポインタｐとが、入力として与えられる。このオブジェクト・プログラム８４０は、上記したメソッド（４）に対応する。

実行が開始されると、ステップ８４２において、パケット・ポインタｐ’が初期化される。このポインタｐ’が含むサイズ・フィールドに、パケット・ポインタｓおよびｐのそれぞれにおけるサイズ・フィールドに格納されていたサイズの和が格納される。すなわち、ポインタｓに格納されていたサイズとポインタｐに格納されていたサイズとの和か求められ、その求められた和が、ポインタｐ’のサイズ・フィールドに代入される。

次のステップ８４３において、コンキャット（ｃｏｎｃａｔ）操作を実行した際の結果として、返すべきポインタ配列領域を、ＳＲＡＭに確保し、割り当てを行う。割り当てたポインタ配列領域の先頭アドレス（ＳＲＡＭ内のアドレス）が、ポインタｐ’によって指示される様に、ポインタｐ’における指定アドレスのフィールドに、上記した先頭アドレスを格納する。すなわち、ポインタｐ’の指示アドレスとして、上記した先頭アドレスを代入する。次に、ステップ８４４において、ポインタｐ’のデータ表現を、Ｆｒａｇｍｅｎｔｅｄ表現にする。すなわち、ポインタｐ’のデータ表現フィールドに、Ｆｒａｇという値 (例えば整数値)を、識別子として代入する。次のステップ８４５において、ポインタｐ’が指示するところのポインタ配列の先頭要素の指示アドレスを、ポインタｐの指示アドレスと一致させる。すなわち、ポインタｐが含む指示アドレスを、ポインタｐ’によって指示されるポインタ配列における先頭要素へ代入する。

ステップ８４６において、先に入力したパケット・ポインタｐのデータ表現を判定する。この判定は、図８Ａと同じである。判定の結果として、パケット・ポインタｐのデータ表現が、Ｆｒａｇｍｅｎｔｅｄ表現であれば、次にステップ８４７が実行される。また、パケット・ポインタｐのデータ表現が、Ｃａｃｈｅｄ表現あるいはＵｎｃａｃｈｅｄ表現であれば、ステップ８４９が実行される。一方、データ表現が、Ｍｉｘｅｄ表現であれば、次にステップ８４８が実行される。

入力パケットが、Ｆｒａｇｍｅｎｔｅｄ状態の場合、この入力パケットのポインタｐは、ポインタ配列を指定する。そのため、ステップ８４７においては、パケット・ポインタｐが指示するポインタ配列の各要素を、ポインタｐ’が指示するポインタ配列の第 2 要素以下にコピーする。すなわち、ポインタｐ’が含むポインタ配列の要素数を、パケット・ポインタｐが含むポインタ配列の要素数に、１を加算したものとする。ステップ８４７が終了すると、ポインタｐ’の値を、戻り値として、コンキャット（ｃｏｎｃａｔ）操作の実行は終了する。

ステップ８４８においては、入力パケット・ポインタｐが指示するディスクリプタにおけるＤＲＡＭへのポインタの値を、ポインタｐ’が指示するポインタ配列の第 2 要素とし、ポインタｐ’が含むポインタ配列要素数＃を２とする。ステップ８４８が終了すると、ポインタｐ’の値を戻り値として、コンキャット（ｃｏｎｃａｔ）操作の実行は終了する。

ステップ８４９においては、ポインタｐの指示アドレスを、ポインタｐ’が指示するポインタ配列の第２要素の指示アドレスとする。ステップ８４９が終了すると、ポインタｐ’の値を戻り値として、コンキャット（ｃｏｎｃａｔ）操作の実行は終了する。

＜オブジェクト・プログラムの生成手順＞
以下、機械語への翻訳３０２（図３）の手順を説明する。機械語への翻訳３０２においては、中間語プログラム３１２（図３）全体を、オブジェクト・プログラム３１３に翻訳する。この翻訳の流れは、従来のコンパイラにおけるのと同様だが、中間語プログラム３１２におけるパケット・データに対する操作、すなわちメソッド呼び出しの翻訳は、従来のコンパイラとは異なっている。すなわち、中間語プログラム３１２に含まれているところのサブストリング（ｓｕｂｓｔｒｉｎｇ）操作、サブパケット（ｓｕｂｐａｃｋｅｔ）操作、コンキャット（ｃｏｎｃａｔ）操作等のメソッド呼び出しの部分を次の様にして翻訳する。これらのメソッド呼び出しに対しては、オブジェクト・プログラム・テンプレート８１０、８２０、８４０が定められている。すなわち、これらのメソッドの呼び出しに応じて、対応するオブジェクト・プログラム・テンプレートが選択され、選択されたテンプレートに従って動作する。

このとき、メソッド呼び出しの直前において、とりうるデータ表現にしたがってテンプレートの可変部分を書き換えてオブジェクト・プログラムを生成する。以下、サブストリング（ｓｕｂｓｔｒｉｎｇ）操作、サブパケット（ｓｕｂｐａｃｋｅｔ）操作、コンキャット（ｃｏｎｃａｔ）操作のそれぞれについて、オブジェクト・プログラム生成方法を説明する。

第１に、サブストリング（ｓｕｂｓｔｒｉｎｇ）操作を行うメソッド呼び出しの処理を説明する。オブジェクト・プログラム・テンプレート８１０（図８Ａ）においては、ステップ８６１、８６２、８６３、８６４（図８Ａ）の各部分が可変である。すなわち、オブジェクト・プログラム・テンプレート８１０を適用するべきサブストリング操作の適用前において、成立する事前条件に従って、ステップ８６１、８６２、８６３、８６４の各部分を省略あるいは簡素化することができる。省略および簡素化の方法を以下説明する。

図８Ａにおいては、ステップ８１３においてデータ表現を判定し、その結果に応じて処理を行っている。しかし、このような条件分岐は比較的計算時間がかかるため、ワイヤ・レート（高速）の処理が不可能になる場合がある。したがって、最適化のためには、このような条件分岐をなくすことが望ましい。このような最適化が可能な場合を、以下３通り説明する。

一つ目は、入力されるパケットのサイズが比較的小さくて、常にＣａｃｈｅｄ表現であるとコンパイラにわかる場合である。この場合には、ステップ８１３および８１４に対応する機械語（オブジェクト・プログラム）を生成する必要はなく、ステップ８１２の次にステップ８１５に対応する機械語を生成すればよい。これによって、条件分岐をなくすことができる。すなわち、ステップ８１３を含む判定ステップ８６１、ステップ８１４を含むＭｉｘｅｄ表現時の処理ステップ８６２およびエラー処理行うエラー処理ステップ８６３に相当する機械語を削除することができる。

二つ目は、ｓｕｂｓｔｒｉｎｇ操作の対象となるパケットが、ネットワークから入力されたままの状態で適用されていることがコンパイラにわかる場合、あるいはネットワークから入力される場合である。この場合には、パケットが、Ｃａｃｈｅｄ状態あるいはＭｉｘｅｄ状態のうちのいずれかの状態であって、Ｕｎｃａｃｈｅｄ状態およびＦｒａｇｍｅｎｔｅｄ状態になることはないとわかるときは、エラーで終了するケースを生成する必要がない。このケースを省くことによって、Ｍｉｘｅｄ状態またはＣａｃｈｅｄ状態のうちのいずれか、あるいは両方の状態において実行効率を高められる場合がある。すなわち、ステップ８６１（図８Ａ）の部分におけるＵｎｃａｃｈｅｄ表現かＦｒａｇｍｅｎｔｅｄ表現かという判定を省略することができ、エラー処理に関するエラー処理ステップ８６３を削除することができる。

最後は、ｓｕｂｓｔｒｉｎｇ操作が他の操作の直後に適用されることがプログラム上からわかり、かつ図７に示した状態遷移を使用することによって事前条件を絞ることができる場合である。直前の操作が、ｃｏｎｃａｔ操作であれば、図７においてｃｏｎｃａｔ操作の適用後の状態、すなわちｃｏｎｃａｔとラベルづけされた矢印の先頭が達している状態は、Ｍｉｘｅｄ７０３とＦｒａｇｍｅｎｔｅｄ７０４だけである。この場合、事前条件は「ＭｉｘｅｄあるいはＦｒａｇｍｅｎｔｅｄ」となる。すなわち、ＣａｃｈｅｄおよびＵｎｃａｃｈｅｄという２つの状態は排除される。それにより、判定ステップ８６１における判定８１３において、ＣａｃｈｅｄおよびＵｎｃａｃｈｅｄは考慮する必要がなくなり、Ｃａｃｈｅｄ状態を処理するステップ８６４を削除したオブジェクト・プログラムを生成することができる。

なお、上記では直前の操作はｃｏｎｃａｔ操作に限定したが、直前の操作がｓｕｂｓｔｒｉｎｇ操作でもｓｕｂｐａｃｋｅｔ操作でも、図７に示した状態遷移を適用して事前条件を求めることができ、それに従ってオブジェクト・プログラムを生成することができる。

次に、ｓｕｂｐａｃｋｅｔ操作のメソッド呼び出しの処理を説明する。オブジェクト・プログラム・テンプレート８２０（図８Ｂ）においては、ステップ８７１、８７２、８７３、８７４、８７５、８７６の各部分が可変である。すなわち、オブジェクト・プログラム・テンプレート８２０を適用するべきｓｕｂｐａｃｋｅｔ操作の適用前において成立する事前条件に従って、ステップ８７１、８７２、８７３、８７４、８７５、８７６の各部分を省略あるいは簡素化することができる。その方法を、以下説明する。

図８Ｂにおいては、ステップ８２３においてデータ表現を判定し、その結果に応じて処理を行っている。しかし、このような条件分岐をなくす最適化が可能な場合を、次に説明する。入力されるパケットのサイズが比較的小さくて、常にＣａｃｈｅｄ表現であるとコンパイラにわかるときは、ステップ８２３から８２８までのステップを生成する必要はなく、ステップ８２２の次にステップ８２９を実行する機械語を生成すればよい。これによって、条件分岐をなくすことができる。すなわち、判定ステップ８７１、Ｍｉｘｅｄ判定ステップ８７２、Ｍｉｘｅｄ処理ステップ８７３、Ｕｎｃａｃｈｅｄ処理ステップ８７４およびエラー処理ステップ８７５の部分を削除することができる。なお、ここではオブジェクト・プログラムにおける条件の削除についてだけ記述したが、事前条件の限定によるオブジェクト・プログラムの簡素化、とくに直前の操作による限定も可能である。

最後に、ｃｏｎｃａｔ操作のメソッド呼び出しの処理を説明する。オブジェクト・プログラム・テンプレート８４０（図８Ｃ）においては、ステップ８８１、８８２、８８３、８８４の各部分が可変である。すなわち、オブジェクト・プログラム・テンプレート８４０を適用するべきｃｏｎｃａｔ操作の適用前において成立する事前条件に従って、ステップ８８１、８８２、８８３、８８４の各部分を省略または簡素化することができる。省略の方法の一例は、以下のとおりである。

図８Ｃにおいては、ステップ８４６においてデータ表現を判定し、その結果に応じて処理を行っている。しかしながら、このような条件分岐をなくす最適化が可能な場合を、以下説明する。入力されるパケットのサイズが比較的小さくて、常にＣａｃｈｅｄ表現であるとコンパイラにわかるときは、ステップ８８１、８８２、８８３までの部分を生成する必要はなく、ステップ８４５の次にステップ８４９に対応する機械語を生成すればよい。これによって、条件分岐をなくすことができる。すなわち、判定ステップ８８１、処理ステップ８８２およびエラー処理ステップ８８３の部分を削除することができる。なお、ここではオブジェクト・プログラムにおける条件の削除についてだけ記述したが、事前条件の限定によるオブジェクト・プログラムの簡素化、とくに直前の操作による限定も可能である。

本実施の形態においては、入力可能なデータ表現によってオブジェクト・プログラム・テンプレートの可変部分を書き換えるという方法を採用したが、その代わりに、次の様な方法をとることもできる。すなわち、あらかじめ複数のオブジェクト・プログラムまたはオブジェクト・プログラム・テンプレートを用意して、入力可能なデータ表現に従ってそのうちの１個を選択する様にしてもよい。この場合、選択した１個は、入力条件、例えば引数の値の範囲などに従って、さらに可変部分を書き換えることができる。

上記した実施の形態においては、テンプレート８１０（図８Ａ）、８２０（図８Ｂ）および８４０（図８Ｃ）のそれぞれを簡素化することにより、生成される機械語（オブジェクト・プログラム）の高速化を図る様にしていた。しかしながら、オブジェクト・プログラム３１３（図３）を動作させて、エラーを発生させ、発生したエラーに基づいて、ソース・プログラム３１１（図３）あるいは中間語プログラム３１２（図３）を見直し、プログラムの改良を図ってもよい。すなわち、実行時エラーから、プログラムの見直しを行い、改良を行い、高速化を図る様にしてもよい。

この場合、オブジェクト・プログラムには、図８Ａで示したサブストリング操作に対応する処理を行うコード（機械語）、図８Ｂに示したサブパケット操作に対応する処理を行うコードおよび図８Ｃに示したコンキャット操作に対応した処理を行うコードが含まれることになる。含まれたところのこれらのコードは、プログラムにおいて、適時呼び出され、実行されることになる。この様にすることにより、実行時にエラーが発生する場合があり、そのエラーに基づいて、プログラムの改良を行うことができる。もちろん、３種類の操作を全て、プログラムに含ませる必要はない。実行時にエラーを発生させ、それに基づいて改良を行うという観点に立った場合、データ表現を判定するステップ８１３（図８Ａ）、８２３（図８Ｂ）および８４６（図８Ｃ）に対応する処理を行うコードを、オブジェクト・プログラムが有していることが望ましい。実行時にエラーを示すステップ、例えばステップ８６３（図８Ａ）も、オブジェクト・プログラムに残すことが望ましいが、他のエラーを示す処理と兼用することも可能である。

この様にして作成したオブジェクト・プログラム（データ表現を判定するステップに対応するコードを有する）は、例えば、記憶媒体に格納して、頒布してもよいし、図１１に示したＤＲＡＭ１１０５に格納して、ネットワーク・プロセッサとして頒布してもよい。この場合には、ＤＲＡＭ１１０５を、記憶媒体と見なすことができる。

パケットと、それに対応するポインタ（図６において、６１１から６１４）とを含めてパケットと見なすこともできる。この場合、パケットが、それに付与された識別子を有することになる。

以上本発明者によってなされた発明を、前記実施形態に基づき具体的に説明したが、本発明は、前記実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。

６０１ ＳＲＡＭのアドレス空間
６０２ ＤＲＡＭのアドレス空間
６１１、６１２、６１３、６１４ ポインタ
６２１、６２３ ディスクリプタ
１１００ ネットワーク・プロセッサ

Claims (11)

1. 高級言語によって記述されたプログラムを、処理装置のオブジェクト・プログラムに翻訳するプログラム処理方法であって、
   前記プログラムは、特定データ型の第１データを入力し、前記特定データ型の第２データを出力する第１手続きを含むところの複数の手続きを有し、
   前記プログラムの翻訳において、前記第1手続きが呼び出された場合、該呼び出し時における前記第1データが、第1表現であるか、該第1表現とは異なる第2表現であるかを判定し、該判定と前記第１手続きの呼び出しの直前における条件とに基づいて、前記第1手続きを、第1実行法を適用するオブジェクト・プログラムあるいは前記第１実行法とは異なる第2実行法を適用するオブジェクト・プログラムへ翻訳する、プログラム処理方法。
2. 請求項１に記載のプログラム処理方法において、
   前記特定データ型は、パケット型であり、
   前記第１表現は、前記第１データであるパケットの全体が連続した記憶領域に格納されることを表し、前記第２表現は、前記パケットが複数の記憶領域に分散して格納されることを表し、前記第1手続きの呼び出し時に、前記第1データが前記第1表現であり、前記第1手続きの呼び出しが、前記第1データであるパケットの入力直後であったとき、前記第1手続きを前記第１実行法を適用するオブジェクト・プログラムへ翻訳し、前記処理装置における該翻訳されたオブジェクト・プログラムの実行において、前記第1表現の前記第2データを出力する、プログラム処理方法。
3. 請求項１に記載のプログラム処理方法において、
   前記特定データ型はパケット型であり、
   前記第１表現においては、パケット全体がＳＲＡＭに格納され、前記第２表現においては、前記パケットの先頭部分が前記ＳＲＡＭに格納され、前記パケットの残り部分がＤＲＡＭに格納され、
   前記第1手続きの呼び出し時に、前記第1データが前記第1表現であり、前記第1手続きの呼び出しが、前記第1データであるパケットの入力直後であったとき、前記第1手続きを前記第１実行法を適用するオブジェクト・プログラムへ翻訳し、前記処理装置における該翻訳されたオブジェクト・プログラムの実行において、前記第2データであるパケットは、ＳＲＡＭに格納される、プログラム処理方法。
4. 請求項１に記載のプログラム処理方法おいて、
   前記第1手続きの直後に呼び出される第2手続きにおいて、前記第2表現のデータが形成されないとき、前記第2手続きを、前記第1実行法を適用するオブジェクト・プログラムへ翻訳する、プログラム処理方法。
5. 高級言語によって記述されたプログラムを、処理装置のオブジェクト・プログラムに翻訳するプログラム処理方法であって、
   前記プログラムは、特定データ型の第 1 データを入力し、前記特定データ型の第 2 データを出力する第１手続きを含むところの複数の手続きを有し、
   前記第1データおよび前記第2データのそれぞれは、それがメモリへ格納される際の情報を表す識別子を有し、
   前記プログラムの翻訳において、前記第1手続きが呼び出された場合、該呼び出し時における前記第1データが有する前記識別子を判定し、該識別子が第1表現であるとき、前記第1手続きを、第1実行法を適用するオブジェクト・プログラムへ翻訳し、前記識別子が、前記第1表現とは異なる第2表現であるとき、前記第1手続きを、前記第１実行法とは異なる第2実行法を適用するオブジェクト・プログラムへ翻訳する、プログラム処理方法。
6. 請求項５に記載のプログラム処理方法において、
   前記特定データ型はパケット型であり、
   前記処理装置は、ネットワークプロセッサと、該ネットワークプロセッサに接続されたＳＲＡＭとＤＲＡＭと、を有し、
   前記識別子の前記第１表現は、パケットの全データが前記ＳＲＡＭに格納されることを表し、前記第2表現は、前記パケットの全データが、前記ＳＲＡＭと前記ＤＲＡＭに分散されて格納されることを表す、プログラム処理方法。
7. 請求項６に記載のプログラム処理方法において、
   前記第2表現によって表される前記ＳＲＡＭには、前記ＤＲＡＭの領域を指定する情報が格納され、指定された前記ＤＲＡＭの領域に、前記パケットから分散されたデータが格納される、プログラム処理方法。
8. 第１のアクセスタイムを有する第１メモリと、前記第1のアクセスタイムよりも遅いアクセスタイムを有する第2メモリとを用いて、複数のパケットを処理するところのネットワークプロセッサにより実行されるプログラムであって、
   前記複数のパケットのそれぞれは識別子を有し、前記複数のパケットは、前記識別子として、そのパケットに含まれるデータが、前記第1メモリに収まることを表す第1識別子を有するパケットと、前記識別子として、そのパケットに含まれるデータが、前記第1メモリと前記第2メモリに分割されて格納されていることを表す第２識別子を有するパケットを含み、
   前記複数のパケットのそれぞれに対する操作において、パケットに含まれている前記識別子が、前記第1識別子か前記第2識別子かの判定が行われ、判定の結果に従って互いに異なる手続きが行われる様にする、プログラム。
9. 請求項８に記載のプログラムにおいて、
   前記複数のパケットは、その識別子として、そのパケットのデータが、分割されることなく、前記第2メモリに格納されていることを表す第３識別子を有するパケットを含み、
   前記判定において、前記第３識別子と判定されたとき、前記第1識別子を有するパケットに対する手続きおよび前記第２識別子を有するパケットに対する手続きとは異なる手続きが行われる、プログラム。
10. 請求項９記載のプログラムにおいて、
    前記プログラムは、記憶媒体に格納されている、プログラム。
11. 請求項９に記載のプログラムにおいて、
    前記第1メモリは、ＳＲＡＭであり、前記第2メモリは、ＤＲＡＭである、プログラム。

Images