JP2014197291A - プログラム処理方法およびプログラム - Google Patents
プログラム処理方法およびプログラム Download PDFInfo
- Publication number
- JP2014197291A JP2014197291A JP2013072185A JP2013072185A JP2014197291A JP 2014197291 A JP2014197291 A JP 2014197291A JP 2013072185 A JP2013072185 A JP 2013072185A JP 2013072185 A JP2013072185 A JP 2013072185A JP 2014197291 A JP2014197291 A JP 2014197291A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- program
- data
- stored
- procedure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
【課題】ハードウェア依存を低減したプログラミングが可能なプログラム処理方法を提供する。【解決手段】パケットには、それを格納するメモリの種類に応じて複数種類のデータ表現が付与される。パケットに対して操作を行う際、そのパケットに付与されたデータ表現が識別され、識別されたデータ表現に従って処理が行われる。これにより、メモリの様なハードウェアへの依存を低減したプログラム開発が可能となる。また、プログラム開発に用いられるプログラム処理方法(コンパイラ)においては、パケットに対して処理を行う際に、その事前条件を把握し、生成されるオブジェクト・プログラムの高速化を図る。【選択図】図8A
Description
本発明は、プログラム処理方法およびプログラムに関し、特に複数のドメインにまたがるコンピュータ・ネットワークまたは仮想ネットワークの設定あるいは管理を行うためのプログラムを開発するために用いられるプログラム処理方法およびプログラムに関する。
先ず、背景となる技術を、次の4項目に分けて、説明する。すなわち、第1として、プログラムを開発するために用いられるコンパイラにおける複数のデータ表現の使い分けに関する技術である。第2には、ネットワークをプログラマブルにするためのハードウェア技術である。特に、ネットワーク・プロセッサとそこで用いられるSRAM(Static Random Access Memory)およびDRAM(Dynamic Random Access Memory)の使い分けの技術である。第3としては、ネットワークをプログラマブルにするためのソフトウェア技術であり、そのなかでも特に高級言語に関する技術である。最後に、ネットワーク仮想化技術であり、そのなかでも特にネットワークをプログラマブルにするための技術である。
先ず、コンパイラにおける複数のデータ表現の使い分けに関する技術について説明する。ハードウェア要素の使い分けは複数のデータ表現の使い分けの一種だと考えられる。特許文献1には、コンパイラにおいて複数のデータ表現を使い分ける方法が示されている。特許文献1に示された方法においては、異なるデータ表現毎に、異なるモジュール(data representation implementor)が使用される。この方法は、特定のデータ表現を首尾一貫して使用するときには、適していると考えられるが、複数のデータ表現を混合して使用する必要があるときには、適用が困難であると考えられる。
次に、ネットワークをプログラマブルにするためのハードウェア技術、特にネットワーク・プロセッサとそこで用いられるメモリ、特にSRAMとDRAMの使い分けの技術について説明する。
高速なマルチコアのネットワーク・プロセッサにおいては、ワイヤ・レート(高速)の処理のためには、データをSRAMに格納することが望ましい。ところが、処理中の全てのパケット全体を格納(保管)できる程の記憶容量を有するSRAMを、ネットワーク・プロセッサあるいはシステムが備えていないのが通常である。そのため、処理上重要なパケットのディスクリプタまたは先頭部分だけをSRAMに格納しておき、残りの部分もしくはパケット全体はDRAMに格納することが行われている。例えば、Cavium社のネットワーク・プロセッサOcteon(TM)あるいはTilera社のネットワーク・プロセッサTile―Gx(TM)においては、パケットの到着時に、ハードウェアで、上記した様な使い分けを行う様な処理が行われている。この様に、全てのパケットの全データを、SRAMに格納しないのは、それだけの記憶容量を有するSRAMを用意すると、コストアップにつながるためである。
また、高速処理のためには、パケット到着時に、パケットの内容を、SRAMあるいはDRAMに割り当て、それらにパケットの内容を自動的に格納する機能、また、マルチコアにより並列処理された出力パケットを入力順序通りに並べ替えたり、キューイングしたりする処理をハードウェアで行うことが望ましい。これらの機能も前記したOcteon(TM)等のネットワーク・プロセッサにおいては実現されている。
この様なSRAMとDRAMの使い分けにおいては、SRAMの記憶容量が制限されているため、従来のコンパイラにおける複数のデータ表現の使い分けにおけるような首尾一貫した使い分けは困難である。例えば、計算処理によって、SRAMに格納されるべきデータ量が増加したときには、その一部をDRAMへ移動させる様な処理が発生するため、首尾一貫してSRAMを記憶用のメモリとして使用することは困難となる。一方、演算のためには、DRAMに格納されていたデータを、SRAM、すなわちレジスタなどへ移動させる必要が生じる。そのため、首尾一貫して、DRAMをメモリとして、使用することも困難となる。
さらに、ネットワークをプログラマブルにするためのソフトウェア技術、特に高級言語に関する技術として、Shangri−laと、NetVMについて述べる。まず、非特許文献1に開示されているIntel社などによるShangri−laと言われているシステムのために開発されたBaker言語について説明する。Baker言語においては、パケット本体はDRAMに格納され、そのパケットのディスクリプタが、SRAMに格納されると仮定することにより、パケットがDRAMに格納されているのかSRAMに格納されているのかを、プログラマは意識せずに扱える様にしている。しかしながら、SRAMでのデータ構造は、プログラマが決めなければならず、またネットワーク・プロセッサのアーキテクチャに依存する。さらに、DRAMとSRAMとの間のデータ転送もプログラマが記述しなければならないため、キャッシュの操作もプログラマが行わなければならない。
最後に、ネットワーク仮想化技術、特にネットワークをプログラマブルにするために技術について、次に述べる。(独)情報通信研究機構により推進されている「仮想化ノード・プロジェクト」において開発された仮想化基盤では、スライス定義を管理系に与えると、仮想化基盤を構成する各仮想化ノードに、そのノードに関連する仮想ノードと仮想リンクの定義が配布され、各仮想化ノードが仮想化基盤を実現する。ここで仮想ノードは仮想のノードであり、実ノードである仮想化ノードとは全く異なる概念である。仮想ノードはノードスリバーとも呼ばれる。また、仮想リンクはリンクスリバーとも呼ばれる。
仮想ノードにおいて、ネットワーク・プロセッサのような専用化されたプロセッサ(ファストパスと呼ばれることもある)を使用するときは、そのプロセッサにロードするべきプログラムをスライス定義に指定する。仮想リンクはプログラマブルでないが、GRE(Generic Routing Encapsulation:IETF標準)の実装には、ネットワーク・プロセッサが使用されている。仮想ノード内外の仮想リンク部分をつなぐためのパラメタ(IPアドレス、GREキー、MACアドレス)は、スライス生成時にネットワーク・プロセッサに渡される。これらのパラメタは、仮想化ノードの管理系からネットワーク・プロセッサにCLI(Command Line Interface)によって与えられる。
Chen, M. K., Xiao, Feng Li , Lian, R., Lin, J. H., Lixia Liu, Tao Liu, and Ju, R., "Shangri−La: Achieving High Performance from Compiled Network Applications while Enabling Ease of Programming", 2005 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI‘05), pp.224−236,2005。
ネットワークのハードウェアに依存したプログラミングを行うと次の様な課題が生じる。すなわち、ネットワーク・プロセッサのハードウェアを意識してプログラムを記述することになり、次の様な課題が生じる。
(1)プログラミングが困難になるため、開発コストがかかり、開発期間も長期化する。また、スキルのあるプログラマはかぎられるため、プログラマを確保するのも容易ではない。
(2)ハードウェア・ベンダ、あるいはハードウェアに依存するライブラリなどを提供するソフトウェア・ベンダの非公開の独自技術に、プログラムが依存する。そのため、開発に必要な知識を得ることが困難になり、成果を公開または他社に展開するのが困難になる。
(1)プログラミングが困難になるため、開発コストがかかり、開発期間も長期化する。また、スキルのあるプログラマはかぎられるため、プログラマを確保するのも容易ではない。
(2)ハードウェア・ベンダ、あるいはハードウェアに依存するライブラリなどを提供するソフトウェア・ベンダの非公開の独自技術に、プログラムが依存する。そのため、開発に必要な知識を得ることが困難になり、成果を公開または他社に展開するのが困難になる。
特に、高速(ワイヤ・レート)なパケット処理のためには、パケットを適切にSRAMとDRAMに格納し、データがどちらのメモリ(SRAM、DRAM)にあるかを意識したプログラミングが必要となる。特に、パケットにおけるヘッダの編集(追加、削除および/あるいは変更)などの加工が必要なときには、パケットにおけるヘッダをSRAMに格納し、加工の必要がない後続部分(残り部分)は、DRAMに格納することが望ましい。なぜならば、パケット全体(ヘッダと残り部分)を、格納できるだけの記憶容量を有するSRAMを、ネットワーク・プロセッサ等に搭載することは、コスト面等できわめて困難であるためである。また、パケットにおけるヘッダが、SRAMに格納されていない場合には、パケットにおけるヘッダを加工するとき、DRAMへのアクセスが必要とされる。SRAMに比べると、DRAMのアクセスには時間が掛かる。すなわち、SRAMに比べると、DRAMのアクセス時間は長くなる。そのため、DRAMに格納されたヘッダを加工しようとすると、DRAMの比較的長いアクセス時間のために、ワイヤ・レートでの処理が不可能になるからである。
従って、SRAM、DRAM等のハードウェアに依存せずに、オープンな言語仕様に従って高速でパケット処理を行うことが可能なプログラムを提供することが望まれる。また、その様なプログラムを開発できる環境を提供することが望まれる。特に、プログラムにおいては、SRAMとDRAMとを区別する必要をなくすとともに、SRAMとDRAMのどちらに処理すべきデータがあるかをプログラミング言語処理系が管理することが望ましい。また、SRAMとDRAM間のデータ転送も、処理系が自動的に行う様にすることによって、プログラマの負担を軽減し、プログラミングに掛かるコストを低減させることも可能となる。さらに、プログラムが非公開の独自技術に依存しない様にすることにより、コストの更なる低減を図ることも可能となる。
パケットのヘッダを編集することを考えた場合、特許文献1におけるようにSRAMのみ、あるいはDRAMのみを首尾一貫して使用することは、高速の処理に適さない。そのため、パケットを処理するために適したメモリ(SRAMとDRAM)の使い分け、およびメモリ間でデータ転送を行うことが可能なオブジェクト・プログラムを生成することが可能な開発環境の提供も望まれる。
特許文献1および非特許文献1には、パケットを処理する際に、処理されるべきデータがどのメモリに格納されているかをプログラムにおいて区別しなくても良い様にすると言うことは、示唆されていない。
本発明の目的は、ハードウェア(SRAM、DRAM等)依存を低減したプログラミングが可能なプログラム処理方法を提供することにある。
本発明の前記ならびにそのほかの目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。
すなわち、パケットは、それが格納される、あるいは格納されているメモリに応じて、データ表現が付与される。例えば、メモリの種類(SRAM、DRAM)と、メモリに格納されるパケットの部分(部位)とによって、4種類(4状態)の内の1つのデータ表現がパケットに付与される。
例えば、メモリとしてSRAMだけを使用して、その全体が格納されるパケットには、キャッシュド(cached)のデータ表現が付与される。また、メモリとしてDRAMだけを使用して、その全体が格納されるパケットには、アンキャッシュド(uncached)のデータ表現が付与される。
その全体が、DRAMに格納され、その先頭部分だけが、SRAMにキャッシュされるパケットに対しては、ミックスド(mixed)のデータ表現が付与される。それが分割され、分割された一部がSRAMに格納され、残りの部分がDRAMに格納されるパケットに対しては、フラグメンテッド(fragmented)のデータ表現が付与される。
パケットに対する処理(操作)の際に、そのパケットに付与されているデータ表現が識別され、識別したデータ表現に従った処理が実行される。これにより、パケットに対する処理を行うプログラムは、ハードウェア(SRAM、DRAM)に対する依存を低減したプログラムとすることが可能となる。
本願において開示される一実施の形態においては、パケットに対する操作によって生じるデータ表現の変化が、状態遷移により推定される。プログラムを開発するためのプログラム処理方法においては、推定したデータ表現に対応した固有のオブジェクト・プログラムが生成される。これにより、開発の効率化を図ることが可能となる。また、推定することができない場合には、そのオブジェクト・プログラムに、実行時に注意を促すコードを挿入することにより、開発のより効率化を図ることが可能となる。
本願においては、上記したデータ表現は、識別に用いられるため、識別子と見なすことができる。識別子は、各パケットに設けられている。なお、本願においては、データ表現は、単に表現と述べる場合も有る。
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。
ハードウェア依存を低減したプログラミングが可能なプログラム処理方法を提供することができる。
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部分には原則として同一の符号を付し、その繰り返しの説明は省略する。
(実施の形態)
本発明に係わる実施の形態について説明する。先ず、ネットワーク・プロセッサが用いられるネットワークの物理的な構成を、図1を用いて説明する。図1は、仮想ネットワークの実験等をおこなうためのネットワーク全体の物理的な構成を示す構成図である。同図において、破線で囲まれた101はネットワーク仮想化基盤、102はオペレータ・コンソール、111はネットワーク管理サーバ(Network manager)、112から115は物理ノードを示している。仮想ネットワークには、さらにゲートウェイ116、117が含まれ、上記したゲートウェイ116、117には、それぞれパーソナルコンピュータ(以下、PCと称する)118、119が接続されている。この実施の形態においては、物理ノード112から115のそれぞれは、物理ノード112を例として示してあるが、ノードマネジャーNoM、仮想ノードマネジャーVNM、仮想リンクマネジャーVLMを含んでいる。
本発明に係わる実施の形態について説明する。先ず、ネットワーク・プロセッサが用いられるネットワークの物理的な構成を、図1を用いて説明する。図1は、仮想ネットワークの実験等をおこなうためのネットワーク全体の物理的な構成を示す構成図である。同図において、破線で囲まれた101はネットワーク仮想化基盤、102はオペレータ・コンソール、111はネットワーク管理サーバ(Network manager)、112から115は物理ノードを示している。仮想ネットワークには、さらにゲートウェイ116、117が含まれ、上記したゲートウェイ116、117には、それぞれパーソナルコンピュータ(以下、PCと称する)118、119が接続されている。この実施の形態においては、物理ノード112から115のそれぞれは、物理ノード112を例として示してあるが、ノードマネジャーNoM、仮想ノードマネジャーVNM、仮想リンクマネジャーVLMを含んでいる。
<実ネットワークとスライス>
以下、管理情報が仮想ネットワークを扱う場合について、実ネットワークと仮想ネットワーク、すなわちスライスとの関係を図1、図10を用いて説明する。図10において、1121および1126は、実ネットワークを示しており、実ネットワーク1121と1126上のそれぞれには、物理ノード1101と1111とが存在している。これらの実ネットワーク上に生成される仮想ネットワークは、複数のスライス1122、1123、1124および1125(スライス4からスライス1)を有している。物理ノード1101上には、仮想ノード1102、1103および1104が、生成され、物理ノード1111上には、仮想ノード1112、1113および1114が生成されている。
以下、管理情報が仮想ネットワークを扱う場合について、実ネットワークと仮想ネットワーク、すなわちスライスとの関係を図1、図10を用いて説明する。図10において、1121および1126は、実ネットワークを示しており、実ネットワーク1121と1126上のそれぞれには、物理ノード1101と1111とが存在している。これらの実ネットワーク上に生成される仮想ネットワークは、複数のスライス1122、1123、1124および1125(スライス4からスライス1)を有している。物理ノード1101上には、仮想ノード1102、1103および1104が、生成され、物理ノード1111上には、仮想ノード1112、1113および1114が生成されている。
生成されている仮想ノード1104、1114は、スライス1125に属し、相互に、仮想リンクによって結合されている。同様に、仮想ノード1102、1113は、スライス1123に属し、相互に、仮想リンクによって結合されている。スライスの構造は、実ネットワークと同一にすることも可能だが、仮想リンクはトンネル等を使用することによって物理リンクに制約されずに生成することができるため、スライスを実ネットワークとは異なる構造にすることもできる。
<スライスとスライス情報>
スライスは、通常、複数の仮想ノードと仮想ノード間を結ぶ仮想リンク(仮想データ転送パス)とで構成される。仮想ノードは、物理ノード上に作られるが、仮想ノード間の接続は、物理ノードの接続とは独立である。すなわち、仮想リンクは実リンクによってしばられない。それぞれの仮想ノードは、スイッチング、ルーティングをはじめとするネットワーク・プロトコルの処理機能を有するが、その機能は、その仮想ノードをふくむ物理ノードのプロトコル処理機能とは独立でありうる。
スライスは、通常、複数の仮想ノードと仮想ノード間を結ぶ仮想リンク(仮想データ転送パス)とで構成される。仮想ノードは、物理ノード上に作られるが、仮想ノード間の接続は、物理ノードの接続とは独立である。すなわち、仮想リンクは実リンクによってしばられない。それぞれの仮想ノードは、スイッチング、ルーティングをはじめとするネットワーク・プロトコルの処理機能を有するが、その機能は、その仮想ノードをふくむ物理ノードのプロトコル処理機能とは独立でありうる。
ドメイン間にまたがる仮想ネットワークの設定をおこなうために、本実施の形態においては、仮想ノードのリストと仮想リンクのリストとで構成されるスライスの構成情報が、スライス情報として、管理メッセージに包含される。スライス情報は、上記の様な仮想ネットワークにおける仮想ノードの属性やその資源量、仮想リンクの属性、仮想ノードと仮想リンクとの接続関係などで構成される情報である。ここで、仮想ノードの資源量とは、例えば、その仮想ノードに対応付けられたプロセッサ(ネットワーク・プロセッサ:CPU)の個数やメモリの記憶容量に関する情報である。また、仮想リンクの属性とは、例えば、その仮想リンクが使用することができる帯域に関する情報である。しかしながら、かならずしもスライス情報が、そのスライスが含んでいるところの全ての仮想ノードおよび仮想リンクの情報を含んでいる必要はない。
また、スライス情報は、かならずしも仮想ネットワークに関する情報であるとはかぎらない。例えば、物理ノードや物理リンク(実データ転送パス)を管理するための情報であってもよい。この場合、スライス情報は物理ノードの設定情報や状態に関する情報、物理リンクの状態に関する情報(例えば使用可能性やトラフィック量)などの情報を含むことができる。
<スライス情報の内容>
本実施の形態において使用するスライスSのスライス情報を、図2を用いて説明する。スライスSは、イーサネット(登録商標)やインターネット・プロトコル(IP)に制約されない新しいプロトコル(以下、非IPプロトコルと呼ぶ)を、実験するための仮想ネットワークである。スライス情報は、コンソール102(図1)を通じてネットワーク管理サーバ111(図1)に与えられるが、その際には、XML(Extensible Markup Language)などの形式で作成して、使用する。ここでは理解を容易にするために、図を用いて示しているが、本質的にはかわらない。
本実施の形態において使用するスライスSのスライス情報を、図2を用いて説明する。スライスSは、イーサネット(登録商標)やインターネット・プロトコル(IP)に制約されない新しいプロトコル(以下、非IPプロトコルと呼ぶ)を、実験するための仮想ネットワークである。スライス情報は、コンソール102(図1)を通じてネットワーク管理サーバ111(図1)に与えられるが、その際には、XML(Extensible Markup Language)などの形式で作成して、使用する。ここでは理解を容易にするために、図を用いて示しているが、本質的にはかわらない。
スライスS(仮想ネットワーク200)は、仮想ノード(1)213、仮想ノード(2)212、仮想ノード(3)215、仮想ノード(4)214、ゲートウェイ201、206によって構成されている。この実施の形態においては、仮想ノード(4)214と、ユーザのPC218とが、ゲートウェイ216を経由して仮想リンク(1)201と結合されている。仮想ノード(1)213と仮想ノード(2)212とが仮想リンク(2)202によって結合され、仮想ノード(1)213と仮想ノード(3)215とが仮想リンク(3)203によって結合されている。同様に、仮想ノード(2)212と仮想ノード(3)215とが仮想リンク(4)204によって結合され、仮想ノード(4)214と仮想ノード(3)215とが仮想リンク(5)205によって結合され、仮想ノード(3)215とユーザのPC219とがゲートウェイ217を経由して、仮想リンク(6)206によって結合されている。特に制限されないが、仮想ノード(1)213は、物理ノード113(図1)内に生成され、仮想ノード(2)212は、物理ノード112(図1)内に生成され、仮想ノード(3)215は、物理ノード115(図1)内に生成され、仮想ノード(4)214は、物理ノード114(図1)内に生成される。なお、図2には、物理ノード112(図1)と物理ノード114(図1)との間が物理リンクにより接続され、物理ノード113と物理ノード115との間が物理リンクで接続されている例が示されている。図2においては、物理リンクは、細線で示されており、仮想リンクは太線で示されている。
仮想ノード(1)213、仮想ノード(2)212、仮想ノード(3)215およびPC219は、非IPプロトコルを処理するノードである。しかし、この実施の形態においては、PC218は、非IPプロトコルを扱うことができず、イーサネットしか扱うことができない。そのため、仮想ノード(4)214において、そこに設けられているプロセッサであるところのネットワーク・プロセッサを使用して、PC218から受信したパケットから、MAC(Media Access Control)ヘッダを削除して、仮想ノード(3)215に転送する。一方、仮想ノード(4)214におけるネットワーク・プロセッサは、仮想ノード(3)215からパケットを受信した場合、その受信したパケットに、MACヘッダを付加して、PC218へ送信する。すなわち、仮想ノード(4)214上のネットワーク・プロセッサにおいては、MACヘッダを編集(付加および/あるいは削除)するプログラムを動作させることになる。
このプログラムは、その開発者が高級言語によって、そのプログラムを開発し、コンパイラを使用して、それをオブジェクト・プログラムに翻訳して前記したネットワーク・プロセッサ(仮想ノード(4)上のプロセッサ)にロードさせ、実行させる。
<コンパイラの構成>
次に、図3を使用して、仮想ノード(1)213、仮想ノード(2)212、仮想ノード(3)215、仮想ノード(4)214のそれぞれにおけるネットワーク・プロセッサにロードされるプログラムをコンパイルするコンパイラの構成を説明する。
次に、図3を使用して、仮想ノード(1)213、仮想ノード(2)212、仮想ノード(3)215、仮想ノード(4)214のそれぞれにおけるネットワーク・プロセッサにロードされるプログラムをコンパイルするコンパイラの構成を説明する。
本実施の形態におけるコンパイラは、Java(登録商標)風のパケット処理用の高級言語を、ネットワーク・プロセッサが実行可能なオブジェクト・プログラムに翻訳するソフトウェアである。このコンパイラに、開発者によって作成されたソース・プログラム311が与えられると、ステップ301により、中間語プログラム312へ翻訳される。翻訳された中間語プログラム312は、ハードウェア依存性がないプログラムである。すなわち、ハードウェア非依存の中間語プログラム312が生成される。中間語プログラム312は、次に、オブジェクト・プログラムへの翻訳のステップ302において、ネットワーク・プロセッサのためのオブジェクト・プログラム313へ翻訳される。
オブジェクト・プログラム313は、ネットワーク・プロセッサのハードウェア(物理的構成)に依存したプログラムである。すなわち、ステップ302において、ネットワーク・プロセッサの特性が考慮され、複数のデータ表現を使い分けるオブジェクト・プログラム313が生成される。例えば、ソース・プログラム311において記述されていた抽象データ構造は、ネットワーク・プロセッサのハードウェア上のデータ構造すなわちSRAM上のデータ、DRAM上のデータ、ディスクリプタ等に翻訳される。また、ソース・プログラム311において記述されていた実行文は、ベンダ独自仕様のC言語または機械語に翻訳される。本実施の形態においては、コンパイルの手順を2段階としているが、1段階で行うことも可能であり、また最適化などを含む3段階以上の手順で実行することも可能である。
<言語仕様>
本実施の形態においては、いわゆる高級言語により、パケット処理用のプログラムが記述される。この高級言語は、Javaに近いが、既存の高級言語とは異なる。以下、本実施の形態で用いるパケット処理用プログラム言語を、Sと呼ぶ。以下、言語Sの仕様について述べる。
本実施の形態においては、いわゆる高級言語により、パケット処理用のプログラムが記述される。この高級言語は、Javaに近いが、既存の高級言語とは異なる。以下、本実施の形態で用いるパケット処理用プログラム言語を、Sと呼ぶ。以下、言語Sの仕様について述べる。
言語Sにおいては、パケットを表現するクラス(データ型)が定義され、言語Sでは、そのクラス(以下、Packetとする)に対する自然な操作を定義することにより、パケット処理用のプログラムが作成される。既存の高級言語においては、パケット処理は、イーサネット(Ethernet)、IP、TCP、UDPの様な特定のプロトコルに従うものとして定義されることが多かった。これに対して、言語Sにおいては、任意のプロトコルによるパケット処理を記述することができる様にするため、パケットをバイト列とみなし、パケット処理はバイト列に対する処理として実行する。ただし、パケット処理においては、バイト境界に拘束されない操作もあるが、このような操作はパケットから部分列を文字列として取り出した状態で実行するものとする。すなわち、パケットに対する操作としては定義しない。この様に、任意のプロトコルを扱えるようにすることで、例えば仮想ネットワークで用いるプロトコルの自由度を向上させることができる。
文字列は、通常はバイト列の一種であるが、その文字列に対する基本的な操作は、部分列生成(substring:サブストリング)と、連接(concatenation:コンキャティネイト)である。部分列生成は、文字列から、それが含む部分文字列を生成する操作であり、連接は、複数個の文字列を連結する処理である。
パケット処理においては、通常、2種類の部分列生成操作がおこなわれる。第1は、入力されたパケットから、一部のパケット・ヘッダが取り出される操作であり、第2は、入力されたパケットから、パケット本体すなわち一部のパケット・ヘッダを除いた部分が取り出される操作である。これらの操作はできるだけ、高速(ワイヤ・レート)で実行できるように最適化することが望ましい。これ以外の部分列生成操作、例えばパケットの途中の部分を取り出す操作もありうるが、本実施の形態においては、それに対してはコンパイラの性能上の向上は配慮をしないものとする。
これらの2種類の操作は、バイト列に対する操作としては同一のものだと考えることができるが、パケット処理においてはパケット・ヘッダとパケット本体とを区別するのは自然だと考えられるので、上記した第1の操作は、サブストリング(substring)と呼び、上記した第2の操作は、サブパケット(subpacket)と呼んで、言語Sにおいては区別する。言語Sにおいては、文字列に対する部分列操作も存在するので、つぎの3個のメソッド(1)から(3)が存在する。ここでfrom、toのそれぞれは、非負整数(負とならない整数)である。
(1)Packet Packet.subpacket(from):このメソッド(操作)は、「パケットの途中から末尾までの部分列をパケットとして返す」操作を行う。なお、途中は、fromによって与えられる。
(2)String Packet.substring(from、to):このメソッドは、「パケットの途中(fromからtoまで)の部分列を文字列として返す」操作を行う。
(3)String String.substring(from、to):このメソッドは、「文字列の途中(fromからtoまで)を、部分列として取り出して、文字列として返す」操作を行う。
なお、上記した第2メソッド(2)においては、パケットのtoで指示される部分が、SRAM上にあるときだけ性能を保証するものとする。その部分がDRAM上にしか存在しないときは、次の2つのうちのいずれかの方法をとることができる。第1は、性能は低下するが、DRAMからSRAMへ、その部分列をロードする方法である。第2は、エラーとして処理する方法である。この第2の方法の場合、toの値が、言語Sで記述されたプログラムをコンパイルする時に、判定できれば、コンパイル時にエラーとすることができる。しかしながら、コンパイルの時に、その値を判定できない場合には、コンパイルすることによって得たオブジェクト・プログラムを実行する際にエラーとする。すなわち、オブジェクト・プログラムの実行時エラーとする。
パケット処理における連接操作は、通常、パケット・ヘッダとパケット本体とを連結する操作である。パケット・ヘッダは、1個または複数個存在するが、それらすべてが文字列であり、それらがSRAM上に存在しているときだけ、性能を保証する。連接操作において、パケット本体は、SRAM上にある必要はない。言語Sにおいては、文字列に対する連接操作も存在するので、次の2 個のメソッドが存在する。
(4)Packet Packet.concat(String):このメソッドは、「パケットに、Stringで示されているパケットを連結し、パケットとして返す」操作を行う。
(5)String String.concat(String):このメソッドは、「文字列に、Stringで示されている文字列を連結し、文字列として返す」操作を行う。
3個以上の文字列およびパケットの連接は、これらのメソッド(4)、(5)を繰り返して適用することによって実現することができる。なお、上記したメソッド(1)から(5)のそれぞれにおいて、先頭部分は、操作により得られたデータ型を示し、中間部分は、操作する前のデータ型を示し、記号“.”以降の後段部分は、操作内容を示している。例えば、上記したメソッド(5)を例にすると、先頭部分は、Stringであり、このメソッドを実行したことにより得られるデータはそのデータ型が、文字列であることを示している。また、記号“.”前の中間部分は、Stringであり、操作前のデータのデータ型が、文字列であることを示している。記号“。”以降である後段部分はconcat(concatenation)であり、連結を意味している。
<ソース・プログラム>
コンパイラはさまざまな内容のソース・プログラムを翻訳することができる。図4には、ソース・プログラムの一例が、311として示されている。このプログラムは、仮想ネットワーク200(図2)において、仮想ネットワーク200内とPC218(図2)との間のパケット・データ表現の差を埋めるためのプログラムである。すなわち、このプログラムは、NetStream1、NetStream2と命名されたデータ・ストリームを入出力する。データ・ストリームNetStream1、NetStream2に対する処理は、図9に、模式的に示されている。図9を参照にしながら、プログラム311により実施される処理を説明する。
コンパイラはさまざまな内容のソース・プログラムを翻訳することができる。図4には、ソース・プログラムの一例が、311として示されている。このプログラムは、仮想ネットワーク200(図2)において、仮想ネットワーク200内とPC218(図2)との間のパケット・データ表現の差を埋めるためのプログラムである。すなわち、このプログラムは、NetStream1、NetStream2と命名されたデータ・ストリームを入出力する。データ・ストリームNetStream1、NetStream2に対する処理は、図9に、模式的に示されている。図9を参照にしながら、プログラム311により実施される処理を説明する。
NetStream1経由で、仮想ノード(3)215(図2)から入力されたパケット901は、プログラム311(図3)においてパケット・ヘッダ(MACヘッダ:Header)を追加され、パケット902として、NetStream2経由で、PC218(図2)に出力される。一方、PC218から、NetStream2経由で入力されたパケット904は、プログラム311により、パケット・ヘッダ(MACヘッダ:Header)が削除され、パケット903として、NetStream1経由で、仮想ノード(3)215に出力される。この様にすることにより、非IPプロトコルを扱わないPC218と非IPプロトコルの仮想ネットワーク200(図2)との間でパケットの送受信が可能となる。
次に、プログラム311の意味を、部分毎に説明する。このプログラムは、図9に示す様に、2個のパケット入出力(ネットワーク・インターフェース)NetStream1、NetStream2をもち、NetStream1から入力されたパケットには、MACヘッダ(Header)を付加して、NetStream2へ出力する。一方、NetStream2から入力されたパケットからは、MACヘッダ(Header)を削除して、NetStream1へ出力するプログラムである。
ソース・プログラム311(図4)には、各行の先頭に行番号がつけられているが、これは本来のソース・プログラムには含まれないものであり、説明の便宜上付けたものである。ソース・プログラム311は、インポート宣言401、402と、クラス宣言403から423とで構成されている。インポート宣言401、402のそれぞれにおいて、このプログラムが、パケット・ストリームNetStream1とNetStream2を入出力することを宣言している。
AddRemMACクラスのクラス宣言403〜423においては、まず変数宣言404、405でパケット・ストリーム用の変数out1、out2が宣言されている。AddRemMACクラスのオブジェクトを生成するコンストラクタが、行406〜410において宣言されている。行406において宣言されている引数port1およびport2は、生成されたAddRemMACクラスのオブジェクトが、送受信するパケット・ストリームを表している。port1ストリームに入力されたパケットは、記号“>”の直後に記述されたprocess1というメソッドによって処理され、port2ストリームに入力されたパケットは、記号“>”の直後に記述されたprocess2というメソッドによって処理される。
行408、409においては、変数out1にport1ストリームを代入し、変数out2にport2ストリームを代入している。すなわち、AddRemMACクラスにおいて、out1に出力されるパケットが、port1ストリームに出力され、out2に出力されるパケットが、port2ストリームに出力されることを意味している。
process1メソッドは、行411〜414において定義されている。すなわち、process1メソッドは、行411に記述されている様に、引数としてパケットiを受け取るが、port1にストリームの要素すなわちパケットが入力される毎に、process1が実行され、そのパケットがiとして入力される。行412においては、まず、(i.substring(0,14))によってパケットiの先頭(バイト0)から14バイト目までの部分列が文字列として生成され、concat操作により、生成された文字列とパケットiとが連接され、連結されたパケットが、new Packet()によって生成される。この生成されたパケットは、oに代入され、行413において、ストリームout2に出力される。
process2メソッドは、行415〜418において定義されている。すなわち、process2メソッドは、行415に記述されている様に引数として、パケットiを受け取るが、port2にストリームの要素すなわちパケットが入力される毎に、process2が実行され、そのパケットがiとして入力される。行416においては、まずi.subpacket(14)によってパケットiの14バイト目から末尾までの部分列がパケットとして生成される。生成されたパケットは、oに代入され、行417においてストリームout1に出力される。
行419〜422において定義された関数mainは、AddRemMACクラスの唯一のインスタンス(singleton)が生成される際に実行される。行420〜421において、NetStream1、NetStream2に対応するオブジェクトが生成され、外部ネットワークと接続される。これらのオブジェクトは、AddRemMACクラスのコンストラクタに渡される。すなわち、NetStream1からの入力は、process1メソッドにおいて処理され、そこからの出力がNetStream2に出力される。一方、NetStream2からの入力は、process2メソッドにおいて処理され、そこからの出力がNetStream1に出力される。
上記したソース・プログラム311において、行412における「i.substring(0,14)」が、上記したメソッド(2)に該当し、同じ行412における「i.concat()」が、上記したメソッド(4)に該当する。また、行416における「i.subpacket(14)」が、上記したメソッド(1)に該当する。
<中間語プログラム>
図5には、図4のソース・プログラム311を翻訳して得られる中間語プログラム312が記述されている。図5においては、中間語プログラム312が、文字列の形式で記述されているが、実際には木構造のデータである。すなわち、表現{key1=>value1、key2=>value2、・・・}は、木のノード(親データ)において、key1とラベルづけされた子データの値が、value1であり、key2とラベルづけされた子データの値が、value2であり、以下同様に子データが表現されていることを表している。
図5には、図4のソース・プログラム311を翻訳して得られる中間語プログラム312が記述されている。図5においては、中間語プログラム312が、文字列の形式で記述されているが、実際には木構造のデータである。すなわち、表現{key1=>value1、key2=>value2、・・・}は、木のノード(親データ)において、key1とラベルづけされた子データの値が、value1であり、key2とラベルづけされた子データの値が、value2であり、以下同様に子データが表現されていることを表している。
中間語プログラム312は、ソース・プログラム311(図4)と同様にハードウェア依存のないプログラムである。ソース・プログラム311(図4)における行401〜402が、中間語プログラム312(図5)の行501に翻訳される。また、ソース・プログラム311(図4)における行403〜423が、中間語プログラム312(図5)の行503〜552に翻訳されている。すなわち、行404〜405(図4)は、行505〜506(図5)に翻訳され、行406〜410(図4)は、行540〜552(図5)に翻訳され、行411〜414(図4)は、行514〜527(図5)に翻訳される。同様に、行415〜418(図4)は、行528〜539(図5)に翻訳され、行419〜422(図4)は、行507〜511(図5)に翻訳されている。
ステップ301(図3) による翻訳、すなわちソース・プログラム311(図4)から中間語プログラム312(図 5)への翻訳は、通常のコンパイラにおけるのと同様に、おもに文字列として記述された多様なソース・プログラムの構文を、ステップ301において統一的な木構造にするために行っている。
<パケット・データ表現>
図6には、ネットワーク・プロセッサにおける4種類のパケット・データ表現が示されている。この4種類のパケット・データ表現を説明する前に、ネットワーク・プロセッサの構成を説明する。図11は、本実施の形態で用いられるネットワーク・プロセッサの構成を示すブロック図である。
図6には、ネットワーク・プロセッサにおける4種類のパケット・データ表現が示されている。この4種類のパケット・データ表現を説明する前に、ネットワーク・プロセッサの構成を説明する。図11は、本実施の形態で用いられるネットワーク・プロセッサの構成を示すブロック図である。
図11において、1100は、特に制限されないが1個の半導体集積回路装置として構成されたネットワーク・プロセッサである。ネットワーク・プロセッサ1100は、複数のプロセッサ(CPU)コア1101、1102と、SRAM1103と、データバス1104とを具備している。上記したCPUコア1101、1102と、SRAM1103とは、データおよびアドレスのバス1104を介して互いに接続されている。また、ネットワーク・プロセッサ1100である半導体集積回路装置の外部には、DRAM1105が設けられ、このDRAM1105も、上記したデータおよびアドレスのバス1104に接続されている。特に制限されないが、DRAM1105には、CPUコア1101および1102を動作させるためのプログラムも格納される。ネットワーク・プロセッサ1100とDRAM1105とによって、処理装置が構成されていると見なすこともできる。
CPUコア1101および1102は、DRAM1105に格納されたプログラムに従って、SRAM1103およびDRAM1105を用いながら、パケットに対する処理等を行う。
SRAM1103は、DRAM1105に比べて、そのアクセス時間が早い。しかしながら、半導体集積回路装置に内蔵可能な記憶容量には、制限が生じる。すなわち、ネットワーク・プロセッサ1100のコストアップを抑制するためには、大記憶容量のSRAMをネットワーク・プロセッサ1100に内蔵させることが困難となる。また、ネットワーク・プロセッサ1100の外部に、DRAMと同様に、SRAMを設けることも可能であるが、DRAMと同じ記憶容量のSRAMは、DRAMに比べて、コストアップとなる。そのため、ネットワーク・プロセッサ1100の外部にSRAMを設けるようにしても、コストアップの観点から、制限が生じる。
上記したDRAM1105には、例えばパケット処理用のオブジェクト・プログラムが、格納される。この場合、該オブジェクト・プログラムは、図3で説明した様にして生成される。このDRAM1105は、プログラム(パケット処理用のオブジェクト・プログラム)を格納した記憶媒体と見なすことができる。
図6に戻り、4種類のパケット・データ表現について説明を行う。4種類のパケット・データは、同一のデータ型(パケット)である。そのため、これらは、ソース・プログラムにおいては、同一のクラスに属するオブジェクトであり、同一の型のデータである。しかしながら、本実施の形態においては、パケットの高速処理のために、パケット・サイズやパケットの入力条件、処理条件などに応じて、異なる表現が使用される。図6において、601は、SRAM(例えば、図11の1103)のメモリ空間を示しており、602は、DRAM(例えば、図11の1105)のメモリ空間を示している。パケットを受信したとき、あるいはパケットを操作しているとき、パケットを構成するデータ(例えば、図9に示したヘッダHeaderと、本体Body)は、SRAMおよび/あるいはDRAMに格納される。
上記した4種類のデータ表現とは、後で述べるが、(1)キャッシュド(Cached)表現、(2)ミックスド(Mixed)表現、(3)フラグメンテッド(Fragmented)表現、(4)アンキャッシュド(Uncached)表現である。以下では、上記した(1)はCached表現、(2)はMixed表現、(3)はFragmented表現、(4)はUncached表現とも称する。
(1)Cached表現のパケットは、SRAMだけに格納されたパケットを意味する。言い換えるならば、パケット全体が、SRAMだけにキャッシュされている場合、そのパケットは、Cached表現とされる。(2)Mixed表現のパケットは、その全体がDRAMに格納され、その先頭だけがSRAMにキャッシ(Cache)されたパケットである。(3)Fragmented表現は、パケットが複数に分断(分割)され、それぞれの断片が、DRAMに格納されているパケットに対して与えられる。この場合、断片はDRAMにおいて、非連続のアドレス空間に格納される。また、この表現においては、断片の一部が、SRAMに格納されている場合も含む。(4)Uncached表現は、その全体が、DRAMに格納されたパケットに対して与えられる。パケットが、これらの4種類の表現のいずれに該当するかは、そのパケットが指定するポインタに含まれている識別子によって判定される。
図6において、図の左側には、パケットに対応し、パケットを指定するポインタが、(1)から(4)として示されている。同図において、(1)は、Cached表現のパケット(Cached packet)であり、それを指定するポインタが611として示されており、(2)は、Mixed表現のパケット(Mixed packet)であり、それを指定するポインタが612として示されている。同様に、(3)は、Fragmented表現のパケット(Fragmented packet)であり、それを指定するポインタが613として示されており、(4)は、Uncached表現のパケット(Uncached packet)であり、それを指定するポインタが614として示されている。
ポインタ611、612、613および614のそれぞれは、それがどの表現を示しているかを表す識別子を格納するフィールド、パケットのサイズを示すサイズ情報(size)を格納するフィールド、SRAMあるいはDRAMの格納先(例えば、アドレス)を指定する情報を格納するフィールドを有している。また、Fragmented表現の場合には、複数の断片がDRAM(一部がSRAMの場合もある)に格納されるため、断片数に関する情報を格納するフィールド#が設けられている。
パケットにどの表現を割り当てるかは、そのパケットの入力時に、ハードウェアおよびソフトウェア (すなわち実行時ルーティンとコンパイラ) によって選択され、決定される。すなわち、パケットのどの部分SRAMおよび/あるいはDRAMにおくかは、基本的にネットワーク・プロセッサのハードウェアによって決められる。言語Sにおいては、その処理の都合によりソフトウェアによって、表現は調整される。決められたあるいは調整された表現は、識別子として、そのパケットに対応するポインタの該当フィールドに格納される。該当するフィールドに格納される識別子としては、特に制限されないが、例えば、上記(1)のパケットに対応するポインタに対しては、Cachedが用いられ、上記(2)に対しては、Mixedが用いられ、上記(3)に対しては、Fragが用いられ、上記(4)に対しては、Uncachが用いられる。
パケットのデータが、SRAMおよび/あるいはDRAMに格納される際、上記した(1)および(2)の場合には、SRAM(図11の1103)に構造体が形成されて、格納される。すなわち、(1)Cached表現のパケットの場合には、SRAMのアドレス空間に構造体621が形成され、パケット全体が、構造体621内のデータ622(cached data)として格納される。また、(2)Mixed表現のパケットの場合には、そのパケット全体がDRAM(図11の1105)のアドレス空間602内のアドレス領域に、データ625(stored data)として格納される。また、この場合、Mixed表現に対応した構造体623が、SRAMのアドレス空間601に形成される。形成された構造体623には、パケットの先頭におけるデータが、キャッシュされ、キャッシュデータ(cached data)626として格納される。さらに構造体623には、パケット全体を格納したDRAMのアドレス空間内のアドレスを指定するポインタ情報624が格納される。上記(1)および(2)で形成された構造体は、ポインタにより指定される。すなわち、Cached表現のパケットの格納に対応して形成された構造体621は、Cached表現のポインタ611により指定され、Mixed表現のパケットの格納に対応して形成された構造体623は、Mixed表現のポインタ612により指定される。これにより、各表現に合わせて、ポインタから構造体を把握し、パケットの格納先を把握することができる。
格納されるパケットが、(3)Fragmented表現のパケットの場合、パケットが複数に分断されているため、複数の断片が、DRAM内のアドレスにデータ(stored data1〜3)630、632、631として、分散されて格納される。この場合にも、SRAMのアドレス空間には、分散されて格納されたDRAM内のアドレスを指定するポインタ627、628、629の配列が格納される。本明細書では、これらの断片へのアドレスからなる配列をポインタ配列と呼ぶ。図6においては、すべての断片がDRAMに格納されているが、一部またはすべての断片がSRAMに格納されている場合もある。この場合にも、ポインタ配列で、格納したアドレスを管理する。このポインタ配列は、Fragmented表現のポインタ613により指定される。従って、ポインタ613から、分断されて格納されているパッケージのデータを把握することができる。
格納されるパケットが、(4)Uncached表現のパケットの場合、パケット全体が、データ(stored data)633としてDRAMに格納される。この場合には、Uncached表現のポインタ614には、パケット全体を格納したDRAMのアドレスを指定するアドレス情報が、該当するフィールドに格納される。これにより、Uncached表現のパケットであっても、ポインタ614により、格納先を把握することができる。
図 6 においては、Cached表現およびMixed表現におけるSRAM上の構造体621および623は、同一の構造をしている。しかしながら、これらの構造体は異なる様にしてもよい。例えば、構造体621には、DRAMのアドレスを指定するポインタとして、0を設定し、この値が無視される様にすればよいが、他の値を設定するようにしてもよい。また、構造体はパケットだけでなく文字列を表現することもできる。なお、キャッシュされたデータは、SRAMのメモリ空間601において、連続した領域に格納される。
これらの構造体621、623を、本明細書では、ディスクリプタと呼ぶ。上記した様に、ディスクリプタはSRAM上に形成され、パケットの先頭部分の値を含む。また、ディスクリプタ623は、DRAMのアドレスを指定するポインタも含む。DRAMへのポインタは、ディスクリプタがCached表現のパケットだけを表すとき、あるいは文字列を表すときは使用されない。ディスクリプタがDRAMへのポインタを含むときは、DRAM上でのデータのサイズを示すサイズ情報620が含まれる。また、図6においては、Fragmented表現におけるポインタ613は、ポインタ配列の要素数#を示す情報を格納するフィールド615を含んでいる。
<データ表現間の状態遷移>
図7は、1個のパケット・データを入力し、1個のパケット・データを出力する操作(演算)における入力パケットと出力パケットとのデータ表現の関係を表す図である。図7においては、データ表現を状態とみなした状態遷移の形で記述している。コンパイラは、図4のソース・プログラム311からオブジェクト・プログラム312(図3)の一部を生成する際に、この状態遷移と等価なデータ構造を使用することにより、各操作の適用前の事前条件とその適用後の事後条件との関係を把握することが可能となる。その方法については後述する。なお、この状態遷移は、パケット処理プログラム全体あるいはプロセッサ全体の状態遷移ではなく、1個のパケットに関する状態遷移を表している。
図7は、1個のパケット・データを入力し、1個のパケット・データを出力する操作(演算)における入力パケットと出力パケットとのデータ表現の関係を表す図である。図7においては、データ表現を状態とみなした状態遷移の形で記述している。コンパイラは、図4のソース・プログラム311からオブジェクト・プログラム312(図3)の一部を生成する際に、この状態遷移と等価なデータ構造を使用することにより、各操作の適用前の事前条件とその適用後の事後条件との関係を把握することが可能となる。その方法については後述する。なお、この状態遷移は、パケット処理プログラム全体あるいはプロセッサ全体の状態遷移ではなく、1個のパケットに関する状態遷移を表している。
ここで第1に、Cached状態(入力のパケットが、Cached表現のとき)701のパケットに、サブパケット(subpacket)操作を適用すると、その結果はCached状態となる。すなわち、パケット全体がSRAMに格納されているときに、サブパケット(subpacket)操作を行っても、生成されるパケットは、必ず全体がSRAMに格納される。従って、Cached状態のままである。
第2に、Cached状態701のパケットに、コンキャット(concat)操作を適用すると、結果はFragmented状態(パケットが、Fragmented表現)704となる。すなわち、Cached状態701のパケットの前に文字列を連接するときは、連接すべき文字列をそのパケットのキャッシュされたデータ622(図6)の直前に格納できるだけの領域を確保することは通常はできない。そのため、2個の断片(要素)を含むFragmented状態704のデータ表現を生成し(Fragmented704状態に遷移)、それらのデータを指示するポインタを断片として格納する。
第3に、Mixed状態(パケットが、Mixed表現)703のパケットに、サブパケット(subpacket)操作を適用すると、結果は、Mixed状態703またはUncached状態(パケットが、Uncached表現)702になる。すなわち、サブパケット(subpacket)操作によって、SRAM上のデータが一部の残されるときは、Mixed状態703に遷移し、それがすべて除去されるときはUncached状態702に遷移する。
第4に、Mixed状態703のパケットにコンキャット(concat)操作を適用すると、結果は、Fragmented状態704となる。すなわち、Mixed状態703のパケットを含むSRAMおよびDRAMの領域の直前に、連結すべき文字列を格納することができないので、Fragmented状態704に遷移(変換)する必要がある。
第5に、Uncached状態702のパケットに、サブパケット(subpacket)操作を適用すると、結果はUncached状態702となる。すなわち、パケット全体が、DRAMに格納されているときに、サブパケット(subpacket)操作を行っても、生成されるパケットは必ず全体がDRAMに格納されているので、Uncached状態のままである。
第6に、Uncached状態702のパケットに、コンキャット(concat:new Packet)操作を適用すると、結果はMixed状態703またはFragmented状態704となる。すなわち、パケットの前に、連接される文字列が、SRAM上に存在していれば、元のパケットはDRAM上にあるので、そこへのポインタをディスクリプタ内に格納することによって、Mixed表現を生成することができる。
第7に、Fragmented状態704のパケットに、サブパケット(subpacket)操作を適用するのは困難である。そのため、このような操作は状態遷移図に記述していない。この様な場合、すなわち、サブパケット(subpacket)操作が指定された時はエラーとするか、または性能低下を許容し、パケット・データの一部を、DRAMからSRAMにロードしてから、扱う様にする。
<オブジェクト・プログラム>
図8A、図8Bおよび図8Cには、図4のソース・プログラム311からオブジェクト・プログラム313(図3)の一部を生成する際に使用されるオブジェクト・プログラム・テンプレートをあらわすフローチャートが記述されている。これらのオブジェクト・プログラム・テンプレートは、データ表現がコンパイル時には不明なときにも適用できるが、データ表現が、Cached、Mixed、Uncached、Fragmentedのいずれか確定すればその一部を省略することが可能である。これにより、より最適化されたオブジェクト・プログラムを生成することができる。また、データ表現が確定しないが、いくつかの可能性が排除されるときにも、排除されるデータ表現に対応する部分を省略することによって、より最適化されたオブジェクト・プログラムを生成することができる。
図8A、図8Bおよび図8Cには、図4のソース・プログラム311からオブジェクト・プログラム313(図3)の一部を生成する際に使用されるオブジェクト・プログラム・テンプレートをあらわすフローチャートが記述されている。これらのオブジェクト・プログラム・テンプレートは、データ表現がコンパイル時には不明なときにも適用できるが、データ表現が、Cached、Mixed、Uncached、Fragmentedのいずれか確定すればその一部を省略することが可能である。これにより、より最適化されたオブジェクト・プログラムを生成することができる。また、データ表現が確定しないが、いくつかの可能性が排除されるときにも、排除されるデータ表現に対応する部分を省略することによって、より最適化されたオブジェクト・プログラムを生成することができる。
<substringのオブジェクト・プログラム・テンプレート>
図8Aには、サブストリング(substring)操作のオブジェクト・プログラム・テンプレート810のフローチャートが示されている。図8Aを用いて、このオブジェクト・プログラム・テンプレート810を説明する。このテンプレートが表現するオブジェクト・プログラムには、このプログラムの実行に際して、入力されたパケットのポインタpと、求めるべき部分列の範囲を指定するデータが入力される(ステップ811)。求めるべき部分列の範囲は、from、to−1で与えられる。パケットに対するサブストリング(substring)操作は、上記したメソッド(2)に該当する。求めるべき部分列の範囲を指定するところの変数fromおよびtoは、メソッド(2)を呼び出した際に、与えられる。メソッド(2)でも説明した様に、変数fromおよびtoは、負とならない整数である。なお、to−1は、変数toから1を減算した値を意味する。ポインタpは、図6において説明したポインタを意味する。すなわち、ポインタpは、入力されたパケットが、Cached表現、Mixed表現、Fragmented表現およびUncached表現のいずれかに応じて、Cached、Mixed、Frag、Uncachを示す識別子を有している。なお、本明細書においては、ポインタpは、パケット・ポインタpと称することもある。
図8Aには、サブストリング(substring)操作のオブジェクト・プログラム・テンプレート810のフローチャートが示されている。図8Aを用いて、このオブジェクト・プログラム・テンプレート810を説明する。このテンプレートが表現するオブジェクト・プログラムには、このプログラムの実行に際して、入力されたパケットのポインタpと、求めるべき部分列の範囲を指定するデータが入力される(ステップ811)。求めるべき部分列の範囲は、from、to−1で与えられる。パケットに対するサブストリング(substring)操作は、上記したメソッド(2)に該当する。求めるべき部分列の範囲を指定するところの変数fromおよびtoは、メソッド(2)を呼び出した際に、与えられる。メソッド(2)でも説明した様に、変数fromおよびtoは、負とならない整数である。なお、to−1は、変数toから1を減算した値を意味する。ポインタpは、図6において説明したポインタを意味する。すなわち、ポインタpは、入力されたパケットが、Cached表現、Mixed表現、Fragmented表現およびUncached表現のいずれかに応じて、Cached、Mixed、Frag、Uncachを示す識別子を有している。なお、本明細書においては、ポインタpは、パケット・ポインタpと称することもある。
次に、ステップ812において、文字列ポインタsが初期化され、文字列ポインタsが含むサイズ・フィールドsizeに、変数to―変数fromの値が代入される。すなわち、結果としてえられる文字列のサイズが、to―fromとされる。ステップ813において、入力されたパケットのポインタ(パケット・ポインタ)pの識別子から、入力されたパケットのデータ表現を判定する。識別子が、Mixedであれば、次にステップ814が実行され、Cachedであれば、次にステップ815が実行され、これ以外すなわち識別子がUncachあるいはFragであれば、ステップ863が実行される。ステップ863においては、実行時エラーとしてプログラム313の実行を終了する様な所定のコードに変換して、組み込む。ただし、作成したプログラム313の実行効率が低下しても、それを実行するべきであれば、エラーで終了するかわりに、DRAMから部分列の値をSRAMにロードして、結果として返す様にしてもよい。
ステップ814においては入力パケット・ポインタpが含むアドレス(図6においては、構造体あるいはポインタ配列を指定するアドレス)を、文字列ポインタsに含まれているアドレス用のフィールドにコピーする。これにより、パケット・ポインタpと文字列ポインタsは、同一の領域を共有することになる。しかしながら、サブストリング(substring)操作においては、列の値を書き換えないため、このように同一の領域を参照することができる。ステップ814が終了すると、文字列ポインタsの値を、戻り値として、サブストリング(substring)操作の実行は終了する。
一方、ステップ815が実行された場合には、ステップ815において、文字列ポインタsに含まれているアドレス用のフィールドに、パケット・ポインタpが含むアドレスとfromとを加算した値を代入する。すなわち、Cached表現のパケットにおいては、ポインタが含むアドレスを、fromだけ進めたものをアドレスとして有するポインタを返す。この場合にも、パケット・ポインタpと文字列ポインタsは、同一の領域を共有する。ステップ815が終了すると、文字列ポインタsの値を戻り値として、サブストリング(substring)操作の実行は終了する。
なお、ステップ811において、与えられたfromとtoとの間の値(範囲)が、適切な値で有るかチェックする様にしてもよい。この様にすることにより、エラーの指摘が可能となる。一方、この実施の形態の様に、チェックを省略することにより、効率化を図ることが可能となる。
<subpacketのオブジェクト・プログラム・テンプレート>
次に、サブパケット(subpacket)操作のオブジェクト・プログラム・テンプレート820の意味を、図8Bを用いて、説明する。このテンプレートが表現するオブジェクト・プログラムには、ステップ821に記述したように、パケット・ポインタp、求めるべき部分列の先頭位置を示すfromが、入力される。このオブジェクト・プログラム820は、上記したメソッド(1)に対応し、変数fromは、非負整数で与えられる。なお、求めるべき部分列の末尾は、パケット・ポインタpと一致するため、入力はない。
次に、サブパケット(subpacket)操作のオブジェクト・プログラム・テンプレート820の意味を、図8Bを用いて、説明する。このテンプレートが表現するオブジェクト・プログラムには、ステップ821に記述したように、パケット・ポインタp、求めるべき部分列の先頭位置を示すfromが、入力される。このオブジェクト・プログラム820は、上記したメソッド(1)に対応し、変数fromは、非負整数で与えられる。なお、求めるべき部分列の末尾は、パケット・ポインタpと一致するため、入力はない。
実行が開始されると、ステップ822において、パケット・ポインタp’が初期化される。初期化後、パケット・ポインタp’が含むサイズ・フィールドsizeに、size0―fromの値が代入される。すなわち、結果として得られるパケットのサイズを、size0―fromとする。ここで、size0は、入力されたパケット・ポインタpにより示されていたパケットのサイズであり、パケット・ポインタpに含まれるサイズ・フィールドsizeに格納されている値である。
ステップ823においては、入力パケット・ポインタpのデータ表現を判定する。データ表現の判定は、図8Aで述べたのと同様に、識別子を判定することにより、行われる。入力されたパケットのデータ表現が、Mixed表現であれば、次にステップ824が実行される。また、データ表現が、Cached表現あるいはUncached表現であれば、次にステップ829が実行される。これら以外、すなわちFragmented表現であれば、ステップ875が実行される。ステップ875においては、オブジェクト・プログラムの実行時にエラーとして、プログラム313の実行を終了する。ただし、実行効率が低下しても実行するべきであれば、図8Aで述べたとのと同様に、エラーで終了するかわりにDRAMから部分列の値を、SRAMにロードして、結果として返す様にしてもよい。
ステップ824においては、サブパケット(subpacket)操作を実行することによって、SRAMに格納されていた部分が、全て無くなるかどうかの判定が行われる。これは、SRAMに格納されている部分が、fromで示されているバイト以下であるか否かの判定を行うことにより達成される。すなわち、SRAMに格納されている部分が、fromで示されているバイト以下であれば、サブパケット(subpacket)操作を実行することによって、パケットの先頭からDRAMだけに格納された状態になる。この判定の結果、SRAM部分に残っていると判定した場合には、次にステップ825が実行される。一方、残っていないと判定した場合には、次にステップ827が実行される。
ステップ825において、パケット・ポインタp’のデータ表現を、Mixed表現とする。すなわち、パケット・ポインタp’のデータ表現フィールドに、Mixedという値(例えば整数値)を識別子として代入する。次に、ステップ826において、パケット・ポインタp’に含まれる指示アドレス(SRAMにおける構造体:ディスクリプタを指定するアドレス)を格納するフィールドへ、入力パケット・ポインタpの指示アドレスをコピーする。すなわち、Mixed表現において、パケット・ポインタp’は、ディスクリプタの先頭を指示するべきなので、指定アドレスの値(ポインタの値)は変化しない。パケットの先頭位置はディスクリプタにふくまれるサイズ(この操作によって変化しない)と、ポインタp’が含むサイズとの差によって表現される。ステップ826が終了すると、パケット・ポインタp’の値を、戻り値として、サブパケット(subpacket)操作の実行は終了する。
ステップ827において、パケット・ポインタp’のデータ表現をUncached表現に設定する。すなわち、ポインタp’のデータ表現フィールドに、Uncachという値(例えば整数値)を、識別子として代入する。次に、ステップ828において、パケット・ポインタp’の指示アドレスを、入力パケット・ポインタpが指示するディスクリプタがふくむDRAMへのポインタの値(dとする)にfromの値を加算したものとする。ここで、上記したポインタの値dは、入力パケット・ポインタpが指すパケットの先頭アドレスであるから、パケット・ポインタp’は、パケットの先頭からfromバイト目を指示するようになる。ステップ828が終了すると、パケット・ポインタp’の値を、戻り値として、サブパケット(subpacket)操作の実行は終了する。
ステップ829においては、ポインタp’のデータ表現を、入力パケット・ポインタpのそれと一致させる。すなわち、ポインタp’のデータ表現フィールドへ、入力パケット・ポインタpのデータ表現フィールドに格納されている値を、識別子として代入する。次に、ステップ830において、ポインタp’の指示アドレスを格納するフィールドへ、入力パケット・ポインタpの指示アドレスとfromとして示されている値とを加算して、加算により得た値を格納する。すなわち、入力パケット・ポインタpによる指示アドレスを、fromとして示されている値だけ進め、進めた指示アドレスが、ポインタp’から出力される様にする。ステップ830が終了すると、ポインタp’の値をパケット・ポインタとして、戻り値にし、サブパケット(subpacket)操作の実行は終了する。
<concatのオブジェクト・プログラム・テンプレート>
次に、図8Cを用いて、コンキャット(concat)操作のオブジェクト・プログラム・テンプレート840の意味を説明する。このテンプレートが表現するオブジェクト・プログラムは、ステップ841に記述した様に、入力された文字列のポインタsと入力されたパケットのパケット・ポインタpとが、入力として与えられる。このオブジェクト・プログラム840は、上記したメソッド(4)に対応する。
次に、図8Cを用いて、コンキャット(concat)操作のオブジェクト・プログラム・テンプレート840の意味を説明する。このテンプレートが表現するオブジェクト・プログラムは、ステップ841に記述した様に、入力された文字列のポインタsと入力されたパケットのパケット・ポインタpとが、入力として与えられる。このオブジェクト・プログラム840は、上記したメソッド(4)に対応する。
実行が開始されると、ステップ842において、パケット・ポインタp’が初期化される。このポインタp’が含むサイズ・フィールドに、パケット・ポインタsおよびpのそれぞれにおけるサイズ・フィールドに格納されていたサイズの和が格納される。すなわち、ポインタsに格納されていたサイズとポインタpに格納されていたサイズとの和か求められ、その求められた和が、ポインタp’のサイズ・フィールドに代入される。
次のステップ843において、コンキャット(concat)操作を実行した際の結果として、返すべきポインタ配列領域を、SRAMに確保し、割り当てを行う。割り当てたポインタ配列領域の先頭アドレス(SRAM内のアドレス)が、ポインタp’によって指示される様に、ポインタp’における指定アドレスのフィールドに、上記した先頭アドレスを格納する。すなわち、ポインタp’の指示アドレスとして、上記した先頭アドレスを代入する。次に、ステップ844において、ポインタp’のデータ表現を、Fragmented表現にする。すなわち、ポインタp’のデータ表現フィールドに、Fragという値 (例えば整数値)を、識別子として代入する。次のステップ845において、ポインタp’が指示するところのポインタ配列の先頭要素の指示アドレスを、ポインタpの指示アドレスと一致させる。すなわち、ポインタpが含む指示アドレスを、ポインタp’によって指示されるポインタ配列における先頭要素へ代入する。
ステップ846において、先に入力したパケット・ポインタpのデータ表現を判定する。この判定は、図8Aと同じである。判定の結果として、パケット・ポインタpのデータ表現が、Fragmented表現であれば、次にステップ847が実行される。また、パケット・ポインタpのデータ表現が、Cached表現あるいはUncached表現であれば、ステップ849が実行される。一方、データ表現が、Mixed表現であれば、次にステップ848が実行される。
入力パケットが、Fragmented状態の場合、この入力パケットのポインタpは、ポインタ配列を指定する。そのため、ステップ847においては、パケット・ポインタpが指示するポインタ配列の各要素を、ポインタp’が指示するポインタ配列の第 2 要素以下にコピーする。すなわち、ポインタp’が含むポインタ配列の要素数を、パケット・ポインタpが含むポインタ配列の要素数に、1を加算したものとする。ステップ847が終了すると、ポインタp’の値を、戻り値として、コンキャット(concat)操作の実行は終了する。
ステップ848においては、入力パケット・ポインタpが指示するディスクリプタにおけるDRAMへのポインタの値を、ポインタp’が指示するポインタ配列の第 2 要素とし、ポインタp’が含むポインタ配列要素数#を2とする。ステップ848が終了すると、ポインタp’の値を戻り値として、コンキャット(concat)操作の実行は終了する。
ステップ849においては、ポインタpの指示アドレスを、ポインタp’が指示するポインタ配列の第2要素の指示アドレスとする。ステップ849が終了すると、ポインタp’の値を戻り値として、コンキャット(concat)操作の実行は終了する。
<オブジェクト・プログラムの生成手順>
以下、機械語への翻訳302(図3)の手順を説明する。機械語への翻訳302においては、中間語プログラム312(図3)全体を、オブジェクト・プログラム313に翻訳する。この翻訳の流れは、従来のコンパイラにおけるのと同様だが、中間語プログラム312におけるパケット・データに対する操作、すなわちメソッド呼び出しの翻訳は、従来のコンパイラとは異なっている。すなわち、中間語プログラム312に含まれているところのサブストリング(substring)操作、サブパケット(subpacket)操作、コンキャット(concat)操作等のメソッド呼び出しの部分を次の様にして翻訳する。これらのメソッド呼び出しに対しては、オブジェクト・プログラム・テンプレート810、820、840が定められている。すなわち、これらのメソッドの呼び出しに応じて、対応するオブジェクト・プログラム・テンプレートが選択され、選択されたテンプレートに従って動作する。
以下、機械語への翻訳302(図3)の手順を説明する。機械語への翻訳302においては、中間語プログラム312(図3)全体を、オブジェクト・プログラム313に翻訳する。この翻訳の流れは、従来のコンパイラにおけるのと同様だが、中間語プログラム312におけるパケット・データに対する操作、すなわちメソッド呼び出しの翻訳は、従来のコンパイラとは異なっている。すなわち、中間語プログラム312に含まれているところのサブストリング(substring)操作、サブパケット(subpacket)操作、コンキャット(concat)操作等のメソッド呼び出しの部分を次の様にして翻訳する。これらのメソッド呼び出しに対しては、オブジェクト・プログラム・テンプレート810、820、840が定められている。すなわち、これらのメソッドの呼び出しに応じて、対応するオブジェクト・プログラム・テンプレートが選択され、選択されたテンプレートに従って動作する。
このとき、メソッド呼び出しの直前において、とりうるデータ表現にしたがってテンプレートの可変部分を書き換えてオブジェクト・プログラムを生成する。以下、サブストリング(substring)操作、サブパケット(subpacket)操作、コンキャット(concat)操作のそれぞれについて、オブジェクト・プログラム生成方法を説明する。
第1に、サブストリング(substring)操作を行うメソッド呼び出しの処理を説明する。オブジェクト・プログラム・テンプレート810(図8A)においては、ステップ861、862、863、864(図8A)の各部分が可変である。すなわち、オブジェクト・プログラム・テンプレート810を適用するべきサブストリング操作の適用前において、成立する事前条件に従って、ステップ861、862、863、864の各部分を省略あるいは簡素化することができる。省略および簡素化の方法を以下説明する。
図8Aにおいては、ステップ813においてデータ表現を判定し、その結果に応じて処理を行っている。しかし、このような条件分岐は比較的計算時間がかかるため、ワイヤ・レート(高速)の処理が不可能になる場合がある。したがって、最適化のためには、このような条件分岐をなくすことが望ましい。このような最適化が可能な場合を、以下3通り説明する。
一つ目は、入力されるパケットのサイズが比較的小さくて、常にCached表現であるとコンパイラにわかる場合である。この場合には、ステップ813および814に対応する機械語(オブジェクト・プログラム)を生成する必要はなく、ステップ812の次にステップ815に対応する機械語を生成すればよい。これによって、条件分岐をなくすことができる。すなわち、ステップ813を含む判定ステップ861、ステップ814を含むMixed表現時の処理ステップ862およびエラー処理行うエラー処理ステップ863に相当する機械語を削除することができる。
二つ目は、substring操作の対象となるパケットが、ネットワークから入力されたままの状態で適用されていることがコンパイラにわかる場合、あるいはネットワークから入力される場合である。この場合には、パケットが、Cached状態あるいはMixed状態のうちのいずれかの状態であって、Uncached状態およびFragmented状態になることはないとわかるときは、エラーで終了するケースを生成する必要がない。このケースを省くことによって、Mixed状態またはCached状態のうちのいずれか、あるいは両方の状態において実行効率を高められる場合がある。すなわち、ステップ861(図8A)の部分におけるUncached表現かFragmented表現かという判定を省略することができ、エラー処理に関するエラー処理ステップ863を削除することができる。
最後は、substring操作が他の操作の直後に適用されることがプログラム上からわかり、かつ図7に示した状態遷移を使用することによって事前条件を絞ることができる場合である。直前の操作が、concat操作であれば、図7においてconcat操作の適用後の状態、すなわちconcatとラベルづけされた矢印の先頭が達している状態は、Mixed703とFragmented704だけである。この場合、事前条件は「MixedあるいはFragmented」となる。すなわち、CachedおよびUncachedという2つの状態は排除される。それにより、判定ステップ861における判定813において、CachedおよびUncachedは考慮する必要がなくなり、Cached状態を処理するステップ864を削除したオブジェクト・プログラムを生成することができる。
なお、上記では直前の操作はconcat操作に限定したが、直前の操作がsubstring操作でもsubpacket操作でも、図7に示した状態遷移を適用して事前条件を求めることができ、それに従ってオブジェクト・プログラムを生成することができる。
次に、subpacket操作のメソッド呼び出しの処理を説明する。オブジェクト・プログラム・テンプレート820(図8B)においては、ステップ871、872、873、874、875、876の各部分が可変である。すなわち、オブジェクト・プログラム・テンプレート820を適用するべきsubpacket操作の適用前において成立する事前条件に従って、ステップ871、872、873、874、875、876の各部分を省略あるいは簡素化することができる。その方法を、以下説明する。
図8Bにおいては、ステップ823においてデータ表現を判定し、その結果に応じて処理を行っている。しかし、このような条件分岐をなくす最適化が可能な場合を、次に説明する。入力されるパケットのサイズが比較的小さくて、常にCached表現であるとコンパイラにわかるときは、ステップ823から828までのステップを生成する必要はなく、ステップ822の次にステップ829を実行する機械語を生成すればよい。これによって、条件分岐をなくすことができる。すなわち、判定ステップ871、Mixed判定ステップ872、Mixed処理ステップ873、Uncached処理ステップ874およびエラー処理ステップ875の部分を削除することができる。なお、ここではオブジェクト・プログラムにおける条件の削除についてだけ記述したが、事前条件の限定によるオブジェクト・プログラムの簡素化、とくに直前の操作による限定も可能である。
最後に、concat操作のメソッド呼び出しの処理を説明する。オブジェクト・プログラム・テンプレート840(図8C)においては、ステップ881、882、883、884の各部分が可変である。すなわち、オブジェクト・プログラム・テンプレート840を適用するべきconcat操作の適用前において成立する事前条件に従って、ステップ881、882、883、884の各部分を省略または簡素化することができる。省略の方法の一例は、以下のとおりである。
図8Cにおいては、ステップ846においてデータ表現を判定し、その結果に応じて処理を行っている。しかしながら、このような条件分岐をなくす最適化が可能な場合を、以下説明する。入力されるパケットのサイズが比較的小さくて、常にCached表現であるとコンパイラにわかるときは、ステップ881、882、883までの部分を生成する必要はなく、ステップ845の次にステップ849に対応する機械語を生成すればよい。これによって、条件分岐をなくすことができる。すなわち、判定ステップ881、処理ステップ882およびエラー処理ステップ883の部分を削除することができる。なお、ここではオブジェクト・プログラムにおける条件の削除についてだけ記述したが、事前条件の限定によるオブジェクト・プログラムの簡素化、とくに直前の操作による限定も可能である。
本実施の形態においては、入力可能なデータ表現によってオブジェクト・プログラム・テンプレートの可変部分を書き換えるという方法を採用したが、その代わりに、次の様な方法をとることもできる。すなわち、あらかじめ複数のオブジェクト・プログラムまたはオブジェクト・プログラム・テンプレートを用意して、入力可能なデータ表現に従ってそのうちの1個を選択する様にしてもよい。この場合、選択した1個は、入力条件、例えば引数の値の範囲などに従って、さらに可変部分を書き換えることができる。
上記した実施の形態においては、テンプレート810(図8A)、820(図8B)および840(図8C)のそれぞれを簡素化することにより、生成される機械語(オブジェクト・プログラム)の高速化を図る様にしていた。しかしながら、オブジェクト・プログラム313(図3)を動作させて、エラーを発生させ、発生したエラーに基づいて、ソース・プログラム311(図3)あるいは中間語プログラム312(図3)を見直し、プログラムの改良を図ってもよい。すなわち、実行時エラーから、プログラムの見直しを行い、改良を行い、高速化を図る様にしてもよい。
この場合、オブジェクト・プログラムには、図8Aで示したサブストリング操作に対応する処理を行うコード(機械語)、図8Bに示したサブパケット操作に対応する処理を行うコードおよび図8Cに示したコンキャット操作に対応した処理を行うコードが含まれることになる。含まれたところのこれらのコードは、プログラムにおいて、適時呼び出され、実行されることになる。この様にすることにより、実行時にエラーが発生する場合があり、そのエラーに基づいて、プログラムの改良を行うことができる。もちろん、3種類の操作を全て、プログラムに含ませる必要はない。実行時にエラーを発生させ、それに基づいて改良を行うという観点に立った場合、データ表現を判定するステップ813(図8A)、823(図8B)および846(図8C)に対応する処理を行うコードを、オブジェクト・プログラムが有していることが望ましい。実行時にエラーを示すステップ、例えばステップ863(図8A)も、オブジェクト・プログラムに残すことが望ましいが、他のエラーを示す処理と兼用することも可能である。
この様にして作成したオブジェクト・プログラム(データ表現を判定するステップに対応するコードを有する)は、例えば、記憶媒体に格納して、頒布してもよいし、図11に示したDRAM1105に格納して、ネットワーク・プロセッサとして頒布してもよい。この場合には、DRAM1105を、記憶媒体と見なすことができる。
パケットと、それに対応するポインタ(図6において、611から614)とを含めてパケットと見なすこともできる。この場合、パケットが、それに付与された識別子を有することになる。
以上本発明者によってなされた発明を、前記実施形態に基づき具体的に説明したが、本発明は、前記実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。
601 SRAMのアドレス空間
602 DRAMのアドレス空間
611、612、613、614 ポインタ
621、623 ディスクリプタ
1100 ネットワーク・プロセッサ
602 DRAMのアドレス空間
611、612、613、614 ポインタ
621、623 ディスクリプタ
1100 ネットワーク・プロセッサ
Claims (11)
- 高級言語によって記述されたプログラムを、処理装置のオブジェクト・プログラムに翻訳するプログラム処理方法であって、
前記プログラムは、特定データ型の第1データを入力し、前記特定データ型の第2データを出力する第1手続きを含むところの複数の手続きを有し、
前記プログラムの翻訳において、前記第1手続きが呼び出された場合、該呼び出し時における前記第1データが、第1表現であるか、該第1表現とは異なる第2表現であるかを判定し、該判定と前記第1手続きの呼び出しの直前における条件とに基づいて、前記第1手続きを、第1実行法を適用するオブジェクト・プログラムあるいは前記第1実行法とは異なる第2実行法を適用するオブジェクト・プログラムへ翻訳する、プログラム処理方法。 - 請求項1に記載のプログラム処理方法において、
前記特定データ型は、パケット型であり、
前記第1表現は、前記第1データであるパケットの全体が連続した記憶領域に格納されることを表し、前記第2表現は、前記パケットが複数の記憶領域に分散して格納されることを表し、前記第1手続きの呼び出し時に、前記第1データが前記第1表現であり、前記第1手続きの呼び出しが、前記第1データであるパケットの入力直後であったとき、前記第1手続きを前記第1実行法を適用するオブジェクト・プログラムへ翻訳し、前記処理装置における該翻訳されたオブジェクト・プログラムの実行において、前記第1表現の前記第2データを出力する、プログラム処理方法。 - 請求項1に記載のプログラム処理方法において、
前記特定データ型はパケット型であり、
前記第1表現においては、パケット全体がSRAMに格納され、前記第2表現においては、前記パケットの先頭部分が前記SRAMに格納され、前記パケットの残り部分がDRAMに格納され、
前記第1手続きの呼び出し時に、前記第1データが前記第1表現であり、前記第1手続きの呼び出しが、前記第1データであるパケットの入力直後であったとき、前記第1手続きを前記第1実行法を適用するオブジェクト・プログラムへ翻訳し、前記処理装置における該翻訳されたオブジェクト・プログラムの実行において、前記第2データであるパケットは、SRAMに格納される、プログラム処理方法。 - 請求項1に記載のプログラム処理方法おいて、
前記第1手続きの直後に呼び出される第2手続きにおいて、前記第2表現のデータが形成されないとき、前記第2手続きを、前記第1実行法を適用するオブジェクト・プログラムへ翻訳する、プログラム処理方法。 - 高級言語によって記述されたプログラムを、処理装置のオブジェクト・プログラムに翻訳するプログラム処理方法であって、
前記プログラムは、特定データ型の第 1 データを入力し、前記特定データ型の第 2 データを出力する第1手続きを含むところの複数の手続きを有し、
前記第1データおよび前記第2データのそれぞれは、それがメモリへ格納される際の情報を表す識別子を有し、
前記プログラムの翻訳において、前記第1手続きが呼び出された場合、該呼び出し時における前記第1データが有する前記識別子を判定し、該識別子が第1表現であるとき、前記第1手続きを、第1実行法を適用するオブジェクト・プログラムへ翻訳し、前記識別子が、前記第1表現とは異なる第2表現であるとき、前記第1手続きを、前記第1実行法とは異なる第2実行法を適用するオブジェクト・プログラムへ翻訳する、プログラム処理方法。 - 請求項5に記載のプログラム処理方法において、
前記特定データ型はパケット型であり、
前記処理装置は、ネットワークプロセッサと、該ネットワークプロセッサに接続されたSRAMとDRAMと、を有し、
前記識別子の前記第1表現は、パケットの全データが前記SRAMに格納されることを表し、前記第2表現は、前記パケットの全データが、前記SRAMと前記DRAMに分散されて格納されることを表す、プログラム処理方法。 - 請求項6に記載のプログラム処理方法において、
前記第2表現によって表される前記SRAMには、前記DRAMの領域を指定する情報が格納され、指定された前記DRAMの領域に、前記パケットから分散されたデータが格納される、プログラム処理方法。 - 第1のアクセスタイムを有する第1メモリと、前記第1のアクセスタイムよりも遅いアクセスタイムを有する第2メモリとを用いて、複数のパケットを処理するところのネットワークプロセッサにより実行されるプログラムであって、
前記複数のパケットのそれぞれは識別子を有し、前記複数のパケットは、前記識別子として、そのパケットに含まれるデータが、前記第1メモリに収まることを表す第1識別子を有するパケットと、前記識別子として、そのパケットに含まれるデータが、前記第1メモリと前記第2メモリに分割されて格納されていることを表す第2識別子を有するパケットを含み、
前記複数のパケットのそれぞれに対する操作において、パケットに含まれている前記識別子が、前記第1識別子か前記第2識別子かの判定が行われ、判定の結果に従って互いに異なる手続きが行われる様にする、プログラム。 - 請求項8に記載のプログラムにおいて、
前記複数のパケットは、その識別子として、そのパケットのデータが、分割されることなく、前記第2メモリに格納されていることを表す第3識別子を有するパケットを含み、
前記判定において、前記第3識別子と判定されたとき、前記第1識別子を有するパケットに対する手続きおよび前記第2識別子を有するパケットに対する手続きとは異なる手続きが行われる、プログラム。 - 請求項9記載のプログラムにおいて、
前記プログラムは、記憶媒体に格納されている、プログラム。 - 請求項9に記載のプログラムにおいて、
前記第1メモリは、SRAMであり、前記第2メモリは、DRAMである、プログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013072185A JP2014197291A (ja) | 2013-03-29 | 2013-03-29 | プログラム処理方法およびプログラム |
US14/229,461 US20140298303A1 (en) | 2013-03-29 | 2014-03-28 | Method of processing program and program |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013072185A JP2014197291A (ja) | 2013-03-29 | 2013-03-29 | プログラム処理方法およびプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2014197291A true JP2014197291A (ja) | 2014-10-16 |
Family
ID=51622154
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013072185A Pending JP2014197291A (ja) | 2013-03-29 | 2013-03-29 | プログラム処理方法およびプログラム |
Country Status (2)
Country | Link |
---|---|
US (1) | US20140298303A1 (ja) |
JP (1) | JP2014197291A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017162215A (ja) * | 2016-03-09 | 2017-09-14 | ソフトバンク株式会社 | コマンド処理装置及びプログラム |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111417137B (zh) | 2016-08-15 | 2021-05-04 | 华为技术有限公司 | 一种网络切片配置方法及装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6457172B1 (en) * | 1999-04-13 | 2002-09-24 | International Business Machines Corporation | Compiler for supporting multiple runtime data representations |
US6760905B1 (en) * | 2000-09-21 | 2004-07-06 | Curl Corporation | Lazy compilation of template-generated classes in dynamic compilation execution environments |
-
2013
- 2013-03-29 JP JP2013072185A patent/JP2014197291A/ja active Pending
-
2014
- 2014-03-28 US US14/229,461 patent/US20140298303A1/en not_active Abandoned
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017162215A (ja) * | 2016-03-09 | 2017-09-14 | ソフトバンク株式会社 | コマンド処理装置及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
US20140298303A1 (en) | 2014-10-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Hauser et al. | A survey on data plane programming with p4: Fundamentals, advances, and applied research | |
US9891898B1 (en) | Low-level programming language plugin to augment high-level programming language setup of an SDN switch | |
Soni et al. | Composing dataplane programs with μP4 | |
US10419242B1 (en) | Low-level programming language plugin to augment high-level programming language setup of an SDN switch | |
TWI453671B (zh) | 用於程式碼轉換期間之本機碼和目標碼的組合執行之方法與裝置 | |
US20210365253A1 (en) | Heterogeneity-agnostic and topology-agnostic data plane programming | |
US10303449B2 (en) | Compiling non-native constants | |
CN108563448B (zh) | 程序文件的编译方法、***、计算机设备和存储介质 | |
Sommer et al. | Spicy: a unified deep packet inspection framework for safely dissecting all your data | |
US10579366B2 (en) | Data upgrade framework for distributed systems | |
JP2021128760A (ja) | Opc uaサーバ、opc uaを用いたシステム処理、及びopc uaシステムを実行する方法 | |
Osiński et al. | P4rt-OVS: Programming Protocol-Independent, Runtime Extensions for Open vSwitch with P4 | |
US9426033B2 (en) | Target mapping and implementation of abstract device model | |
JP2014197291A (ja) | プログラム処理方法およびプログラム | |
CN111736844B (zh) | 一种数据库云服务标准接口及实现方法 | |
US8929362B1 (en) | Capability negotiation for abstract candidate device model | |
Henrio et al. | Integrated environment for verifying and running distributed components | |
KR20210120937A (ko) | 딥 러닝 프레임워크 중의 모드 전환 방법, 장치, 전자 기기, 컴퓨터 저장 매체 및 컴퓨터 프로그램 제품 | |
EP3907602A1 (en) | Trustworthy application integration | |
CN108614691B (zh) | 网络功能的开发方法、***、计算机设备和存储介质 | |
Sommer et al. | Spicy: A unified deep packet inspection framework dissecting all your data | |
Wang et al. | Dawn: Co-Programming Distributed Applications with Network Control | |
CN116954571B (zh) | 小程序插件的开发处理方法及装置、计算机可读存储介质 | |
Hyseni et al. | Microcontrollers as components of service oriented architectures | |
CN115796190B (zh) | 基于vue和webpack的前端国际化多语言转换方法及*** |