JP4741313B2 - プログラム生成装置、プログラム生成方法及びコンパイラ - Google Patents

Description

本発明は、小型のネットワーク装置に搭載されるいわゆるプロトコルスタックのソフトウエアをより小型かつより容易に実装するための技術に関する。

Internet Protocol(IP)等の、電子機器間を有線および無線で接続する方式の規格に準拠したネットワーク装置には、パケットデータを処理するためのソフトウエア群、いわゆるプロトコルスタックが搭載されている。このようなネットワーク装置を、大型計算機及びパーソナルコンピュータだけでなく、ＡＶ(Audio Visual)家電機器、白物家電機器、設備機器、センサ、携帯型情報機器、携帯電話等の電子機器にも搭載することが検討されている。

これらの電子機器のうち、小型の電子機器（携帯型情報機器、携帯電話、ＡＶ家電機器、センサ等）に搭載されるネットワーク装置には、小型かつ低消費電力であること、白物家電機器、設備機器に搭載されるネットワーク装置には、安価であることが要求される。

ところで、例えば特許文献１には、オブジェクト指向言語処理システムにおいて、生成されるオブジェクトコードのサイズを最小化する技術が記載されている。この技術によれば、クラス宣言の意味解析処理時に、メソッドの所属するクラス名と入力ファイル名との比較が行われ、その結果、両者が一致していればメソッドアドレス格納テーブルの実体および宣言が、両者が一致していなければメソッドアドレス格納テーブルの宣言のみが出力オブジェクトコード内に生成される。これにより、目的のオブジェクトコード内にメソッドアドレス格納テーブルの実体が１つだけ生成されるため、そのサイズを削減することができる。

特開平６−２６６５６２号公報

上述の要求に対応するため、上述のような電子機器への搭載が検討されるネットワーク装置には、ネットワーク装置のメモリサイズ及びプロセッサ性能等の制約が課せられる。このような制約が課されるなかで、ネットワーク機器に十分な機能を発揮させるには、それに組み込まれるソフトウエアが、より小さなサイズのメモリ上でより高速に動作可能であることが求められる。

しかし、そのようなソフトウエアを汎用プログラミング言語（例えばＣ言語）で記述することは困難である。例えば、上記メソッドアドレス格納テーブルの使用により実現される実行時決定機能を利用すると、実行コードを搭載するときにメソッドアドレス格納テーブル及び不要なインスタンスが生成される。このため、実行コードのサイズが大きくなり、上述のような制約のある小型のネットワーク装置では実行が困難である。また、動的に構文解析を行う機構も実行コードを大きくさせる。

そこで、本発明は、よりコンパクトかつより高速に実行可能な、プロトコルスタックのソフトウエアを、より簡単に実装することを目的とする。

本発明は、
複数のデータ要素を含む一連のデータ列をネットワークを介して受け付けるネットワーク装置に前記データ列を処理させるためのプログラムを、記憶手段及び演算手段を有する情報処理装置に生成させるプログラム生成方法であって、
前記記憶手段には、前記ネットワーク装置が受け付けるデータ列内の各データ要素のサイズ情報を含むアイテム情報が、当該データ列内におけるデータ要素の順番にしたがって記述された定義ファイルが格納されており、
当該プログラム生成方法は、
前記演算手段が、前記定義ファイルを参照する処理と、
前記演算手段が、前記プログラムとして、前記データ列の先頭からの順番にしたがって、当該データ列内の各データ要素を、予め定めたサイズのデータずつ処理するためのプログラムを、前記定義ファイル内における前記各データ要素のアイテム情報の記述順番及び前記各データ要素のサイズ情報に基づき生成する処理と、
を含むことを特徴とするプログラム生成方法を提供する。

本発明によれば、よりコンパクトかつより高速に実行可能な、プロトコルスタックのソフトウエアを、より簡単に生成することができる。

以下、添付の図面を参照しながら、本発明に係る実施の形態について説明する。

まず、図１及び図２により、本実施形態に係るプロトコルスタックを生成する情報処理システムの構成について説明する。

本実施の形態に係る情報処理システムは、ユーザからの指示に応じて所定のプログラムを実行可能なハードウエア構成を有している。例えば、図２に示すように、後述のプロトコルスタックコード生成処理を実行するプログラム（プロトコルスタックコンパイラ、汎用コンパイラ、OS等）及びデータ（プロトコルスタックの処理対象となるネットワークメッセージの形式及び構造が所定のフォーマットで記述された、ASCII(American Standard Code for Information Interchang)コード等の符号方法によるテキスト形式の電子化ファイル：以下、プロトコルスタック定義ファイルと呼ぶ）等が格納されるハードディスク等の外部記憶装置２０１、主記憶装置２０３、外部記憶装置２０１等から主記憶装置２０３上にロードされたプログラムを実行するプロセッサ２０２、可搬型記憶媒体のデータ読み書きを実行するドライブ２０４、ユーザからのデータ入力を受け付ける入力装置（キーボード、マウス等）２０５、ユーザへの提示情報（例えばプログラムの実行状態等）を出力するディスプレイ等の出力装置２０６、等を有している。

なお、プロトコルスタックコンパイラ及び汎用コンパイラは、ドライブ２０４を介して可搬型記憶媒体から外部記憶装置２０１にインストールされたものであってもよいし、情報処理システムがネットワーク接続可能な環境であれば、ネットワークを介して外部記憶装置２０１にインストールされたものであってもよい。また、プロトコルスタック定義ファイルは、ドライブ２０４を介して可搬型記憶媒体から外部記憶装置２０１にコピーされたものであってもよいし、ユーザが、入力装置２０５を用いて作成し、外部記憶装置２０１に保存したものであってもよい。

このようなハードウエア構成上における上述のプログラムの実行により、この情報処理システムは、プロトコルスタック定義ファイルからプロトコルスタックを自動生成するための機能構成を実現する。すなわち、図１に示すように、プロトコルスタック定義ファイル１０１が格納されたデータ記憶部１００、プロトコルスタック定義ファイル１０１に記述されたメッセージデータの形式の解析結果に基づきプロトコルスタックの処理コード（オートマトン及びこれを実行するオートマトン実行プログラム：以下、プロトコルスタックコード）１０３を生成するプロトコルスタックコンパイラ部１０２、ネットワーク装置１１６のプロセッサ１１５が実行可能な実行コード１０５をプロトコルスタックコード１０３から生成する汎用コンパイラ部１０４が実現される。

このような機能構成により、ネットワーク１１２上の他の装置（例えばコントロール装置１１１）との間の送受信メッセージに関する処理をネットワーク装置１１６に実行させる実行コード１０５、すなわち、プロトコルスタックのソフトウエアが自動的に生成される。なお、生成された実行コード１０５は、ネットワーク装置１１６のプロセッサ１１５による実行のため、適当な媒体を介してネットワーク装置１１６上のメモリ１１４に転送される。

つぎに、図３及び図４により、本情報処理システムにより生成されるプロトコルスタックのソフトウエアにより処理されるメッセージデータ（以下、処理対象メッセージデータ）のデータ構造と、プロトコルスタック定義ファイル１０１内の記述とについて説明する。ここでは、処理対象メッセージデータの具体例として、ネットワーク装置間でやり取りされるパケット、特に、照明器具を制御及び監視するための３種類のパケット（照明器具を点灯させるためのパケット、照明器具を消灯させるためのパケット、照明機器であるか否かを問合せるためのパケット）を挙げる。

図３に示すように、照明器具を点灯させるためのパケット（点灯指示パケット）３０１、照明器具を消灯させるためのパケット（消灯指示パケット）３０２、及び、照明器具であるか否かを問い合わせるためのパケット（問合せパケット）３０３には、送信元機器のネットワークアドレス（送信元アドレス）が格納される送信元アドレス格納フィールド３１０、送信先機器のネットワークアドレス（送信先アドレス）が格納される送信先アドレス格納フィールド３１１、照明機器に与えるためのコマンドが格納されるコマンド格納フィールド３１２、予約フィールド３１３、が設けられている。

ここで、送信元アドレス格納フィールド３１０には、照明機器用のコントロール機器１１１のネットワークアドレスの一例として「０００１」、送信先アドレス格納フィールド３１１には、照明機器内のネットワーク装置１１６のネットワークアドレスの一例として「０００２」が格納されている。また、コマンド格納フィールド３１２には、パケットの種類に応じて、照明点灯コマンド「０１」、消灯コマンド「０２」、及び、問合せコマンド「０３」のうちのいずれかのコマンドが格納されている。

さらに、点灯指示パケット３０１及び消灯指示パケット３０２には、送信先機器の機器コードが格納される機器コード格納フィールド３１４が設けられている。ここでは、照明機器に割り当てられた識別子の一例として「０００１」が機器コード格納フィールド３１４に格納されている。

これら３種類のパケット３０１〜３０３のデータ形式及びデータ構造を表す記述、すなわちプロトコルスタック定義ファイル１０１に所定のフォーマットにしたがって記述されたテキストデータを図４に示す。

プロトコルスタック定義ファイル１０１内の記述データは、処理対象パケットの種類と同数の要素（ここでは３つの要素４２０,４２１,４２２）から構成される。各要素４２０,４２１,４２２には、コメント記号（／／）付きメモ書きであるコメント４０５と、対応メッセージであるパケットの形式的な定義を表すメッセージ定義４０２と、が含まれている。ここでは、各要素にコメント４０５が含まれているが、各要素には必ずしもコメント４０５が含まれている必要はない。なお、以下においては、説明の便宜上、照明点灯パケット３０１に対応するメッセージ定義を第１メッセージ定義、照明消灯パケット３０２に対応するメッセージ定義を第２メッセージ定義、問合せパケット３０３に対応するメッセージ定義を第３メッセージ定義と呼ぶこととする。
各メッセージ定義４０２には、メッセージクラス名４０６、対応パケット内の各フィールドに対応するアイテムのリスト４０４、対応パケットの識別子（メッセージ識別子）４０７が含まれる。なお、リスト４０４には対応パケット内の各フィールドに対応するアイテムが、対応パケット内におけるフィールドの順番にしたがって並べられている。

各アイテムには、対応フィールドのデータ格納形式を示す修飾子４０８、アイテム名４０９、対応フィールドの占有サイズ４１０、対応フィールドのデータに対する制約条件４１１が含まれている。

ここで、修飾子４０８の具体例としては、フィールドの内容がビッグエンディアン形式で格納されることを示す「bigendian」、フィールドの内容がリトルエンディアン形式で格納されることを示す「littleendian」、フィールドの内容が任意形式で格納されることを示す「any」等が挙げられる。なお、各アイテムにそれぞれ修飾子４０８を含ませる代わりに、すべてのアイテムの対応フィールドのデータ格納形式を示す修飾子４１２をメッセージクラス名４０６の前にしてもよい。

占有サイズ４１０は、例えば、１０進数表記（「２」「１００」等）の数値データであってもよいし、１６基数指示による１６進数表記（「０ｘ」等）の数値データ、メッセージ定義内で用いられている他のアイテム名を用いた指定、及び、これらの組み合わせによって構成される数式であってもよい。

制約条件４１１の具体例としては、対応フィールド内のデータの値を特定値に制限する条件「=特定の値」、不等号を用いた条件指定、ビットフィールドの制約、これらの要素を組み合わせた数式で表される条件が挙げられる。

なお、プロトコルスタックは、通常、複数のレイヤーから構成されるため、処理対象となるパケットは、複数の入れ子となった要素から構成される。このようなパケットに関するメッセージ定義には、下位レイヤーのパケットのペイロード部分に上位レイヤーのパケットの一部または全部が格納されたことを示すアイテム型を用いてもよい。上位レイヤーのパケットデータの一部または全部を格納するフィールドを指定するため、このようなメッセージ定義には、例えば、上位レイヤーのパケットのデータ形式があるメッセージクラスで記述され、さらに、このメッセージクラス名を伴うアイテムが記述される。

また、ここでは、プロトコルスタックの処理対象メッセージの具体例として、照明機器宛のパケットを挙げたが、プロトコルスタックの処理対象メッセージは、これに限られない。例えば、ホームネットワーク装置（白物家電、ＡＶ家電機器等）、ネットワーク装置（パーソナルコンピュータ、携帯電話、ネットワーク制御装置等）、設備系ネットワーク装置（設備機器、監視装置等）等が送受信するパケットも、プロトコルスタックの処理対象メッセージとなり得る。これらのパケットを処理対象メッセージとする場合には、その形式及び構造が、照明機器宛のパケットと同様、所定のフォーマットでプロトコルスタック定義ファイルに記述される。

つぎに、図５により、このようなプロトコルスタック定義ファイル１０１の記述内容に基づきプロトコルスタックコンパイラ部１０２が実行するプロトコルスタックコード生成処理について説明する。ここでは、説明の便宜上、プロトコルスタックコード生成処理の流れの概略を説明してから、一部の処理（コード変換処理Ｓ６０３）の詳細について説明することとする。

プロトコルスタックコンパイラ部１０２は、プロトコルスタック定義ファイル１０１から各メッセージ定義４０２を読み込んでメモリ上に配置し（Ｓ６０１）、各メッセージ定義４０２の構文エラーをチェックする（Ｓ６０２）。

その結果、いずれかのメッセージ定義４０２に構文エラーが存在していれば、プロトコルスタックコンパイラ部１０２は、構文エラーの詳細内容を含むエラーメッセージを出力装置２０６に表示させ（Ｓ６０５）、処理を終了させる。

一方、いずれのメッセージ定義４０２にも構文エラーが存在していなければ、プロトコルスタックコンパイラ部１０２は、後述のコード変換処理によって、各メッセージ定義４０２を汎用言語コードへ変換し（Ｓ６０３）、その変換結果を、プロトコルスタックコード１０３として電子ファイルに出力する（Ｓ６０４）。これによりプロトコルスタックコードが生成される。

ここで、上述した通り、コード変換処理Ｓ６０３の詳細について説明する。

プロトコルスタックコンパイラ部１０２は、各メッセージ定義４０２の記述に基づいて構造木を作成する（Ｓ６０６）。このとき生成される構造木は、メッセージクラス名をルート、各アイテムをノード、メッセージ識別子４０７をリーフ（終端ノード）とするツリー構造を有する。

例えば、第１メッセージ定義４０２から生成される構造木は、図６に示すように、メッセージクラス名「LightControlMsg」４０６から生成されたルート要素７０１、５つのアイテム「bigendian sourceAddress [２]」「bigendian destAddress [２] =MYSELF」「command [１] =０x０１」「any reserved [１]」「bigendian objectCode [２] =０x０a」から生成されたノード７０２〜７０６と、属性「関数」の設定値としてメッセージ識別子「lightTurenOn」４０７を含むリーフ７０７と、を有している。

各ノード７０２〜７０６のtypeは、対応アイテムの修飾子４０８及び制約条件４１１の少なくとも一方に基づき定まる。例えば、修飾子「any」を含むアイテムに対応するノードのtypeは「任意要素」となり、制約条件４１１を含むアイテムに対応するノードのtypeは「制約」となり、制約条件４１１を含まず、かつ、修飾子「any」も含まないアイテムに対応するノードのtypeは「記録」となる。

ここで、互いに同じメッセージクラス名４０６を含む複数のメッセージ定義からは、部分木を有する構造木が生成される。例えば、共通のメッセージクラス名４０６を含む第１〜第３メッセージ定義４０２（図４参照）からは、図７に示すような構造木が生成される。第１〜第３メッセージ定義４０２は、共通のメッセージクラス名、共通の制約条件を含む１〜２番目のアイテムを有している。これらのメッセージ定義４０２から生成される構造木は、図７に示すようにノード８０３から分岐する。すなわち、第１メッセージ定義４０２に基づき、図６と同様な構造木（ルート要素８０１、ノード８０２〜８０６及びリーフ８０７）が生成され、第２及び第３メッセージ定義４０２の３番目以降のアイテム及びメッセージ識別子に基づき、その構造木のノード８０３を起点とする２つの部分木（すなわち、第２メッセージ定義４０２に対応するノード８０８〜８１０及びリーフ８１１、第３メッセージ定義４０２に対応するノード８１２〜８１３及びリール８１４）が追加される。

このようにして、プロトコルスタック定義ファイル１０１の記述内容に基づきメッセージクラスごとの構造木を生成すると、プロトコルスタックコンパイラ部１０２は、プロトコルスタックコンパイラ部１０２は、後述の最適化サブルーチン（ツリー統合サブルーチン）を呼び出すことによって、この構造木に含まれる共通の部分木を統合する（Ｓ６０７）。なお、この最適化サブルーチンは、オプションにより呼び出しを指定された場合にだけ呼び出されるようにしてもよい。

その後、構造木をステートマシン、各ノードをステート、及び、各リーフを外部関数読み出し処理に変換することによってオートマトンを生成する。図７の構造木から生成されるオートマトンを図８に示す。

図８のオートマトンは、図７の構造木をステートマシン、各ノード８０１〜８０６,８０８〜８１０,８１２,８１３をステート１００１〜１０１５、各リーフ８０７,８１２,８１４の属性「関数」の値で特徴付けられる外部関数の読み出し処理１００９,１０１３,１０１５に変換することによって生成される。ここで、ノードからステートへの変換は、例えば、以下のルール（１）〜（３）にしたがって行われる。

（１）Type=記録のノード
このノードは、属性「長さ」の値に相当する数だけ繰り返されるステート「Ｃ」に変換される。例えば、長さ属性値「２」のノード８０２は、連続する２つのステート「Ｃ」１００１,１００２に変換される。これらのステート「Ｃ」においては、上位レイヤーから受け取った１文字のコードが、ＲＡＭ上の２バイト分の特定エリアに保存され、さらに次のステートに状態が進められる。ここで、文字コードの保存エリアは、変換元ノードの属性「名称」の値によって特徴付けられ、その保持方法は、変換元ノードの属性「型」の値に応じて定まる。

例えば、処理対象系がbigendianである場合、ノード８０２から生成された２つのステート「Ｃ」１００１,１００２のうち、１番目のステート１００１には、変換元ノード８０２の名称属性値「sourceAddress」によって特徴付けられるＲＡＭエリア内の上位に、上位エリアからの文字コードを保持させるためのコードが記述され、２番目のステート１００２には、同ＲＡＭエリア内の下位に上位エリアからの文字コードを保持させるためのコードが記述される。ここでは、変換元ノード８０２の型属性値が「bigendian」であるため、このような順番でコードが生成されているが、変換元ノード８０２の型属性値が「littleendian」であれば、これとは逆の順番でコードが生成される。

なお、ここでは、対象処理系がbigendianである場合を例に挙げたが、対象処理系がlittleendianであれば、対象処理系がbigendianである場合とは逆の順番でコードが生成される。bigendian及びlittleendanのいずれの対象処理系にも対応できるように、対象処理系がbigendian及びlittleendanのうちのいずれであるかの指定をオプションで受け付けるようにしてもよい。この場合には、オプション指定の内容に応じた分岐処理が実行されるようにすればよい。

（２）Type＝制約のノード
このノードは、属性「長さ」の値に相当する数だけ繰り返されるステート「Ｂ」に変換される。例えば、長さ属性値「１」の各ノード８０４,８０８,８１２は、ステート「Ｂ」１００５に変換される。

これらのステート「Ｂ」においては、上位レイヤーから受け取った１文字のコードに応じて次のステートが決定される。例えば、現在の実行ステートがステート１００５である場合、上位レイヤーからの文字コードが「０１」であればステート１００６、上位レイヤーからの文字コードが「０２」であればステート１０１０、上位レイヤーからの文字コードが「０３」であればステート１０１４、それぞれ状態を遷移させる。

また、Type＝制約のノードに対応するステート「Ｂ」においては、上位レイヤーからの文字コードが、対応ノードの制約条件を満たさなければ（すなわち、対応ノードの属性「値」の値のいずれかにも一致しなければ）、受け取ったパケット全体を不正として処理する必要がある。このため、Type＝制約のノードに対応するステート「Ｂ」に関しては、上位レイヤーからの文字コードが対応ノードの制約条件を満たさないときに遷移すべき特別なステート「Ｄ」１０１６が用意されている。例えば、Type＝制約のノード８０５,８０９,８１３に対応するステート「Ｂ」１００５には、上位レイヤーからの文字コードが各対応ノード８０５,８０９,８１３の値属性値「０１」「０２」「０３」のいずれにも該当しないときに、なにも処理が行われないステート「Ｄ」１０１６に遷移するようなコードが記述される。

なお、このようなステート「Ｄ」は、すべてのメッセージクラスにおいて生成される。

（３）Type＝任意要素のノード
このノードは、属性「長さ」の値に相当する数だけ繰り返されるステート「Ａ」に変換される。例えば、長さ属性値「１」のノード８０５,８０９,８１３は、それぞれ、１つのステート「Ａ」１００１,１０１０,１０１４に変換される。これらのステート「Ａ」では、たんに、次ステートに状態を移す処理が行われる。例えば、現在の実行ステートがステート１００１である場合には、次ステート１００２に状態が遷移するだけである。

さらに、プロトコルスタックコンパイラ部１０２は、このようにして生成したオートマトンを実行する汎用記述言語形式のプログラム（オートマトン実行プログラム）を生成する（Ｓ６０８）。これによりメッセージクラスごとに共通に生成されるオートマトン実行プログラムのフローチャートを図９に示す。

そして、最終的に、プロトコルスタックコンパイラ部１０２は、後述の最適化サブルーチン（コード統合サブルーチン、ＲＡＮエリア最適化サブルーチン）を呼び出すことによって、生成したプロトコルスタックコードを最適化する（Ｓ６０９）。なお、最適化サブルーチンは、オプションにより呼び出しを指定された場合にだけ呼び出されるようにしてもよい。

さて、以上の処理によって生成されるオートマトン実行プログラムによって、オートマトンは、以下のように実行される（図９参照）。

まず、ＲＡＭ上の１バイト分の所定領域（実行ステート位置情報格納エリア）に、オートマトンの現在の実行ステートを表す実行ステート位置情報として、オートマトンの最初のステート１００１の位置情報が設定され（Ｓ９０１）、その後、パケット内の一定サイズのデータが上位レイヤーから取得される（Ｓ９０２）。なお、上位ステートから取得されるデータのサイズは任意であるが、ここでは、１文字のコード（すなわち２バイトのデータ）が取得されることとする。

その後、取得したデータに基づき、実行ステート位置情報が示す位置のステートのコードが実行される。

例えば、このとき実行ステート位置情報がステート「Ｂ」の位置を示していれば、上位レイヤーから取得した文字コードに応じて定まるステートの位置情報で実行ステート位置情報が更新される。例えば、現在の実行ステートがステート「Ｂ」１００３である場合、文字コードが「００」であれば、次ステート「Ｂ」１００４の位置情報で実行ステート位置情報が更新され、文字コードがその他の値であれば、ステート「Ｄ」１０１６の位置情報で実行ステート位置情報が更新される。また、現在の実行ステートがステート「Ｂ」１００５である場合、文字コードが「０１」であれば次ステート「Ａ」１００６の位置情報で、文字コードが「０２」であれば次ステート「Ａ」１０１０の位置情報で、文字コードが「０３」であれば次ステート「Ａ」１０１４の位置情報で、文字コードがそれら以外の値であれば、ステート「Ｄ」１０１６の位置情報で実行ステート位置情報が更新される。

また、実行ステート位置情報がステート「Ａ」の位置を示していれば、現在の実行ステートの次ステートの位置情報で実行ステート位置情報が更新される。例えば、現在の実行ステートがステート「Ａ」１００６である場合、次ステート１００７の位置情報で実行ステート位置情報が更新される。

また、実行ステート位置情報がステート「Ｃ」の位置を示していれば、ＲＡＭ上の特定エリアに文字コードが保存され、さらに、現在の実行ステートの次ステートの位置情報で実行ステート位置情報が更新される。例えば、現在の実行ステートがステート１００１である場合には、「sourceAddress」で特徴付けられるＲＡＭエリアの１バイト目に文字コードが保存され、次ステート１００２の位置情報で実行ステート位置情報が変更される。また、現在の実行ステートがステート１００２である場合には、「sourceAddress」で特徴付けられるＲＡＭエリアの２バイト目に文字コードが保存され、次ステート１００３の位置情報で実行ステート位置情報が変更される。

また、実行ステート位置情報が外部関数の呼び出し処理の位置を示していれば、その外部関数が呼び出される。例えば、現在の実行ステートが処理１００９,１０１３,１０１５のいずれかを示している場合には、対応アイテムの属性「関数」の値に対応する名称の外部関数（lightTurnOn, lightTurnOff, lightModeRequest）が呼び出される。

このようにしてステートのコードが実行されると、更新後の実行ステート位置情報が示す位置のステートに状態が遷移し（Ｓ９０３）、Ｓ９０２で取得したデータがパケット内の最後の文字のコードであるか否かがチェックされる（Ｓ９０４）。その結果、最後の文字のコードでなければ、Ｓ９０２以降の処理が繰り返し実行され、最後の文字のコードであれば、処理が終了する。

なお、その後、このようにして生成されたプロトコルスタックコード１０３は、汎用コンパイラ部１０４によって最適化等され、実行コード１０５へと変換される。

このようなオートマトン及びオートマトン実行プログラムによれば、例えば、ネットワーク装置１１６が消灯指示パケット３０２を受け付けた場合には、Ｓ９０２〜Ｓ９０４の繰り返し実行によって、ステート１００１→ステート１００２→ステート１００３→ステート１００４→ステート１００５→ステート１０１０→ステート１０１１→ステート１０１２→処理１０１３、というように状態が順次遷移する。これにより、最終的に、「lightTurnOn」で特徴付けられる外部関数が呼び出され、その結果、照明機器が点灯する。この関数「lightTurnOn」は、照明消灯パケット３０２の送信元の確認及び応答を行うために、照明消灯パケット３０２の送信元アドレス格納フィールドの格納値、すなわちパケット送信元のネットワークアドレスを利用する必要がある。その値は、Ｓ９０２〜Ｓ９０４の繰り返し実行により、sourceAddressで特徴付けられるＲＡＭエリアに書き込まれるため、この関数によって利用可能である。

また、受信パケットの送信先アドレス格納フィールド３１１に、ネットワーク装置１１６のネットワークアドレス「０００２」以外のネットワークアドレス「０１０３」が格納されている場合には、実行ステートが、１００１→１００２→１００３→１０１６→１０１６→１０１６→１０１６→１０１６と変化するため、このパケットに応じた処理（照明機器に対する操作処理）は実行されない。

このように、本実施の形態に係る情報処理システムが生成するオートマトン及びオートマトン実行プログラムによれば、パケットの格納情報が正しく判断されるため、パケットを処理することができる。

通常のネットワーク装置のパケット受信処理においては、受信パケット全体を、ＲＡＭにコピーしてから処理するため、例えば、上述の３種類のパケット３０１〜３０３の処理には、少なくとも８バイトのメモリ領域を要する。また、受信パケット全体をＲＡＭにコピーしてから処理を開始しているため、その分、処理に時間を要する。

これに対して、本実施の形態に係るプロトコルスタックコード生成処理により自動生成されるオートマトン及びオートマトン実行プログラムによれば、ＲＡＭ上に３バイト分のエリア（ノードの名称属性値で特徴付けられる２バイト分のＲＡＭエリア、及び、１バイト分の実行ステート位置情報格納エリア）が確保されれば足りる。また、パケットの受信を開始すると、予め定めたサイズのデータを受信するごとに、そのデータを解析するため、受信パケット全体をいったんメモリに格納してから解析を開始する場合と比較して処理を早期に終了させることができる。

このため、ＲＡＭエリアを節約し、かつ、プログラムの高速化を図ることができる。すなわち、本実施の形態によれば、より小型のプロトコルスタックのソフトウエア、つまり、ネットワークシステム上の小型ネットワーク装置への搭載に適した、省メモリかつ高速なプロトコルスタックをより容易に実装することをできる。

また、プロトコルスタック定義ファイル１０１には、同一のメッセージクラスに属する複数のメッセージ定義から、適宜、必要なメッセージ定義（ネットワーク装置が処理すべきメッセージに関するメッセージ定義）だけを選択して記述することができるため、ネットワーク装置がサポートすべきパケットだけをサポートする必要最小限のコードを生成することができる。すなわち、ネットワーク装置が処理する必要がないメッセージに関するメッセージ定義を排除することができるため、最終的なコードサイズを縮小させることができる。

例えば、上述の３種類のパケット３０１〜３０３のうち、ネットワーク装置の処理対象パケットが２種類のパケット（例えば３０１,３０２）だけである場合、プロトコルスタック定義ファイル１０１には、図４に示した３つの要素４２０〜４２２のうち、処理対象パケット３０１,３０２に対応する２つの要素４２０,４２１だけを記述すれば足りる。その結果、２つの要素４２０,４２１に含まれるメッセージ定義のみからプロトコルスタックコード１０３が生成される。このため、プロトコルスタックコード１０３のサイズが小さくなり、結果として、このプロトコルスタックコード１０３から生成される実行コード１０５のサイズも小さくなる。

なお、プロトコルスタックの処理対象としてパケットを挙げたが、プロセッサで連続的に処理可能な一連のデータ列であれば、パケット以外のデータ（ＸＭＬ形式のテキストデータ等の上位通信データ形式データ、表形式データ等）であってもプロトコルスタックの処理対象となり得る。このような、パケットデータ以外のデータを処理対象とするプログラムも、以上と同様な処理によって自動生成することができる。

また、以上においては、プロトコルスタックコンパイラ部１０２が、汎用コンパイラ部１０４によって実行コードにコンパイルされるオートマトン及びオートマトン実行プログラムをプロトコルスタック定義ファイル１０１から生成しているが、プロトコルスタックコンパイラ部１０２が、特定のネットワーク装置上で動作する機械語形式またはバイナリ形式のコード（すなわち実行コード１０５）をプロトコルスタック定義ファイル１０１から直接生成するようにしてもよい。または、ネットワーク装置において逐次的に解釈実行される中間的な実行コードを生成してもよい。

また、以上においては、すべてのパケットに関するメッセージ定義からソースコードを生成しているが、必ずしも、このようにする必要はない。例えば、一部のパケットに関するメッセージ定義から構造木を生成してから、残りのパケットに関するメッセージ定義についても同様の処理を行い、最終的に、内部的に生成された構造木をグラフ結合（マージ）してもよい。なお、生成された部分的な木構造を保存可能な形式で外部記憶メモリに保存しておき、最終的なソースコードの生成時に、それらを外部記憶メモリから呼び出すようにすれば、処理の高速化を図ることができる。

つぎに、Ｓ６０９において呼び出される最適化サブルーチンについて説明する。なお、各最適化サブルーチンは、前述したように、オプションによってその呼び出しの有無が指定されてもよい。

（１）ツリー統合サブルーチン
Ｓ６０７においてツリー統合サブルーチンが呼び出されると、以下に示すように、図１０のツリー統合処理によって、同一の部分木が統合される。

すべてのツリーの各ノードを順次第１処理対象ノードaとして、以下の処理を繰り返し実行する（Ｓ１１０１）。すなわち、すべてのツリーの各ノードについて、それぞれ、以下の処理を実行する。

すべてのツリーの各ノードを順次第２処理対象ノードｂとして、以下の処理を繰り返し実行する（Ｓ１１０２）。すなわち、新たなノードを第１処理対象ノードａとするごとに、それぞれ、すべてのツリーの各ノードをそれぞれ第２処理対象ノードｂとして以下の処理を実行する。

第２処理対象ノードｂと第１処理対象ノードの順序を比較する（Ｓ１１０３）。その結果、第１処理対象ノードａの順序が第２処理対象ノードｂの順序よりも早くなければ、次ノードを第２処理対象ノードｂとしてＳ１１０３を実行する。一方、第１処理対象ノードａの順序が第２処理対象ノードｂの順序よりも早ければ、第１処理対象ノードａの次ノードを順次第３処理対象ノードａｎとして、以下の処理を繰り返し実行する（Ｓ１１０４）。すなわち、第１処理対象ノードａのすべての次ノードについて、それぞれ、以下の処理を実行する。

第２処理対象ノードｂの次ノードを順次第４処理対象ノードbnとして、以下の処理を繰り返し実行する（Ｓ１１０５）。すなわち、新たなノードが第４処理対象ノードｂｎとなるごとに、第２処理対象ノードｂのすべての次ノードについて、それぞれ、以下の処理を実行する。

第３処理対象ノードanを起点とするサブツリーと第４処理対象ノードbnを起点とするサブツリーを比較する。その結果、両者が一致していれば、第１処理対象ノードaが次ノードａｎを指す部分を第４処理対象ノードｂｎに変更し（Ｓ１１０７）、第２処理対象ノードｂの次ノードのうちの他のノードを第４処理対象ノードbnとして再度Ｓ１１０６を実行する。一方、両者が一致していなければ、第２処理対象ノードｂの次ノードのうちの他のノードを第４処理対象ノードbnとして再度Ｓ１１０６を実行する。

このような処理によりすべての同一の部分木が同一化されたら、参照されていないノードを廃棄する（Ｓ１１０９）。

このような処理によれば、同一の部分木が統合されるため、ノード数が減少し、その結果、生成されるオートマトンのステート数を減少させることができる。このため、最終的な出力コード量が減少させることができる。

（２）コード統合サブルーチン
Ｓ６０９においてコード統合サブルーチンが呼び出されると、以下に示すように、図１２のコード統合処理によって、ステート間に存在する、ＲＡＭメモリ操作処理を実行させるための同一のコードが統合される。ここでは、図８のオートマトンに基づきコードを生成する場合を例に挙げる。ここでは、説明の便宜上、ステート１００１の位置を番号「１」、ステート１００２のステート位置を番号「２」、ステート１００３の位置を番号「３」、実行ステート位置情報格納エリアの識別子を「state」、上位レイヤーから受け取った一文字の識別子を「ｃ」と表す。

ステート１００１において、名称sourceAddressで特徴付けられるＲＡＭエリアの第１バイト目に上位レイヤーからの一文字を格納し、さらに実行ステート位置情報を次ステートの番号「２」に変更するコードは、例えば、図１１に示した３種類のコードＡ「sourceAddress[０]←ｃ」１３０１,「sourceAddress[state−１]←ｃ」１３０２,「sourceAddress[１−state]←ｃ」１３０３のいずれかと、２種類のコードＢ「state←state+１」１３０４,「state←２」１３０５のいずれかと組み合わせから構成される。

また、ステート１００２において、名称sourceAddressで特徴付けられるＲＡＭエリアの第２バイト目に上位レイヤーからの一文字を格納し、実行ステート位置情報を次ステートの番号「３」に変更するコードは、例えば、図１１に示す３種類のコードＡ「sourceAddress[１]←ｃ」１３１１,「sourceAddress[state−１]←ｃ」１３１２,「sourceAddress[３−state]←ｃ」１３１３のいずれかと、２種類のコードＢ「state←state＋１」１３１４,「state←３」１３１５のいずれかとの組み合わせにより構成される。

そこで、２つのステート１００１,１００２のコードを、共通の組合せコード「sourceAddress[state−１]←ｃ、state←state＋１」（コード１３０２,１３０４の組み合わせ、コード１３１２,１３１４の組み合わせ）とすれば、２つのステート１００１,１００２のコードを統合することができるため、コードサイズを減少させることができる。

このようなコードの統合を図るには、プロトコルスタックコンパイラ部１０２は、図１２に示す以下の処理を実行する。まず、プロトコルスタックコンパイラ部１０２は、全ツリーのすべてのノードについて、それぞれ、割り当て可能なコード断片をすべて生成する（Ｓ１４０１）。例えば、ステート１００１におけるコード断片として、６種類の組合せコード、すなわち、「sourceAddress[０]←ｃ、state←state+１」（コード１３０１,１３０４の組合せ）、「sourceAddress[state-１]←ｃ、state←state+１」（コード１３０２,１３０４の組合せ）、「sourceAddress[１-state]←c、state←state+１」（コード１３０３,１３０４の組合せ）、「sourceAddress[０]←c、state←２」（コード１３０１,１３０５の組合せ）、「sourceAddress[state-１]←c、state←２」（コード１３０２,１３０５の組合せ）、「sourceAddress[１-state]←c、state←２」（コード１３０３,１３０５の組合せ）が生成される。また、ステート１００２におけるコード断片として、６種類の組合せコード、すなわち、「sourceAddress[１]←ｃ、state←state+１」（コード１３１１,１３１４の組合せ）、「sourceAddress[state-１]←ｃ、state←state+１」（コード１３１２,１３１４の組合せ）、「sourceAddress[３-state]←c、state←state+１」（コード１３１３,１３１４の組合せ）、「sourceAddress[１]←c、state←３」（コード１３１１,１３１５の組合せ）、「sourceAddress[state-１]←c、state←３」（コード１３１２,１３１５の組合せ）、「sourceAddress[３-state]←c、state←３」（コード１３１３,１３１５の組合せ）が生成される。

プロトコルスタックコンパイラ部１０２は、このとき生成した各コード断片のコストをそれぞれ算出する（Ｓ１４０２）。ここで算出されるコストは、例えば、生成したコードの文字列の長さ、生成したコードをコンパイルしたときのバイナリのサイズ、生成したコードの演算回数の見積もり量等であってもよい。

さらに、プロトコルスタックコンパイラ部１０２は、生成した全コード断片のうち、重複しているコード断片の数をカウントする（Ｓ１４０３）。例えば、ステート１００１について生成されたコード断片「sourceAddress[state-１]←ｃ、state←state+１」は、ステート１００２について生成されたコード断片群にも含まれているから、その重複数は２である。そして、プロトコルスタックコンパイラ部１０２は、すべてのツリーの各ノードについて、それぞれ、生成したコード断片群のなかから、コスト値を重複数で割った値が最小となるコード断片を選択し、このコード断片を、そのノードに割り当てられるコード断片とする（Ｓ１４０４）。

このような処理によれば、よりコストの小さいコードを優先的に割り当てられるとともに、重複するコードの統合が図られる。

（３）ＲＡＭエリア最適化ルーチン
例えば、ノードＡからノードＢ及びノードＣへ分岐するツリーが生成された場合、ノードＢ及びその子ノードから生成されるコードが利用するＲＡＭエリアＤと、ノードC及びその子ノードから生成されるコードが利用するＲＡＭエリアＥとが同時に使用されることはない。これらのＲＡＭエリアＤ,Ｅを共通化すれば、実行コードのＲＡＭサイズを減少させることができる。このように、いくつかのノードから生成されるコードがＲＡＭエリアを使用する場合には、ＲＡＭエリアの最適化により、より高性能で省メモリなプロトコルスタックを生成することができる。以下、この処理について説明する。

Ｓ６０９においてＲＡＭエリア最適化ルーチンが呼び出されると、図１３のＲＡＭエリア共通化処理によって、同時使用されないＲＡＭエリアが統合される。ここでは、以下の定義を用い、対象とするクラスを、Ｃに対してＳ←Ｖ(Ｃ)とする。

Ｖ(Ｃ)＝{ｖ１,ｖ２...}：クラスＣで使用されるＲＡＭエリアの識別情報の集合
Ｄ(Ｃ)＝{ｄ１,ｄ２,... ,ｄm}：クラスCのメッセージ定義の集合
Ｍ(ｄ)＝{ｖｉ,ｖｊ,ｖｋ,...}：メッセージ定義ｄで使用されるＲＡＭエリアの識別情報の集合

まず、プロトコルスタックコンパイラ部１０２は、集合Ｓが空集合φであるかどうかチェックし（Ｓ１５０１）、その結果、空集合φであれば処理を終了させる。一方、空集合φでなければ、以下の数式を満たすメッセージ定義ｄを探す（Ｓ１５０２）。

（M（ｄ）∩Ｓ）∩（M（ｄ'）∩Ｓ）＝φ, ∀ｄ'≠ｄ かつ
Ｓ∩Ｍ（ｄ）≠φ かつ
Ｓ−Ｍ（ｄ）Ｓ≠φ

その結果、該当するメッセージ定義dが存在していれば (Ｓ１５０３)、プロトコルスタックコンパイラ部１０２は、Ｓを、Ｓ１←Ｓ∩Ｍ(ｄ)とＳ２←Ｓ−Ｍ（ｄ）とに分割し、それらＳ１及びＳ２をそれぞれＳとみなして、このアルゴリズムを再帰的に呼び出す。この再帰的処理が終了したら、これにより得られたＳ１及びＳ２を、ＲＡＭエリアを共有する要素として出力する（Ｓ１５０４）。例えば、Ｓ１及びＳ２について、それぞれ、上記条件を満たすメッセージ定義ｄが存在していれば、Ｓ１、Ｓ２、Ｓ１をＳとした再帰的処理により得られるＳ１及びＳ２、Ｓ２をＳとした再帰的処理により得られるＳ１及びＳ２の合計４つが、ＲＡＭエリアを共有する要素となる。もちろん、ＲＡＭエリアを共有する要素ととして最終的に得られる要素は、４つより小さくなることも、４つより大きくなることもある。

一方、該当するメッセージ定義ｄが存在しなければ(Ｓ１５０３)、プロトコルスタックコンパイラ部１０２は、クラスＣで使用される全ＲＡＭエリアの識別情報ｖ∈Ｓに対して、以下の数式を満たすすべてのｒの集合Ｉ(ｖ)を求める（Ｓ１５０５）。

∀ｄ∈Ｄ(Ｃ), ｒ∈Ｍ(ｄ) xor ｖ∈Ｍ(ｄ)

その後、プロトコルスタックコンパイラ部１０２は、集合Ｓ１←(ｖｉ,ｖｊ,...)と集合Ｓ２←(Ｉ(ｖｉ)∩Ｉ(ｖｊ)∩...)の共有ＲＡＭエリアのサイズが最小になるように、Ｓ１及びＳ２に属する要素の組み合わせを選択する。Ｓ１、Ｓ２、Ｓ−Ｓ１−Ｓ２をそれぞれＳとみなして、このアルゴリズムを再帰的に呼び出し、それが終了すると、Ｓ１及びＳ２を、ＲＡＭエリアを共有する要素として出力する（Ｓ１５０６）。例えば、Ｓ−Ｓ１−Ｓ２が空集合φとなり、かつ、Ｓ１及びＳ２の同サイズである場合には、Ｓ１及びＳ２の共通化により、必要なＲＡＭエリアのサイズが当初の半分となる。

以上説明した最適化サブルーチン（ツリー統合サブルーチン、コード統合サブルーチン、ＲＡＮエリア最適化サブルーチン）のうち、読み出すべきサブルーチンの組み合わせを変えることによって（例えば、すべてのサブルーチンを呼び出す、１つのサブルーチンだけを呼び出す等）、複数のプロトコルスタックコードを選択候補として得て、それらの選択候補のなかから、目的に適合する選択候補（例えば、処理性能、メモリの使用量等の実行コストが最小のもの）を最終プロトコルスタックコードとして選択するようにしてみよい。これにより、例えば小型のネットワーク装置への搭載に適した、より高性能で、メモリ使用量の小さなプロトコルスタックを生成することができる。

なお、以上においては、ネットワーク装置に組み込まれるプロトコルスタックコードを情報処理システム上で生成しているが、必ずしも、このようにする必要はない。例えば、プロトコルスタックコードの自動生成処理の実行機能をネットワーク装置に持たせ、そのネットワーク装置が、自身の処理する各種パケットに関するプロトコルスタック定義ファイルの記述内容からプロトコルスタックコードを生成するようにしてもよい。

さらに、さまざまな仮想的な生成結果のなかから、実行コスト（処理性能、必要メモリサイズ等）が最小のものを選択し、それを、プロトコルスタックコードとして出力する。その後、汎用コンパイラ部１０４は、このプロトコルスタックコードから、ネットワーク装置１１６上で実行可能な実行コード１０５を生成する。

本発明の実施形態に係る情報処理システムの機能構成を説明するための図である。 本発明の実施形態に係る情報処理システムの概略ハードウエア構成図ある。 プロトコルスタックの処理対象となるメッセージデータの構造例を説明するための図である。 本発明の実施の形態に係るプロトコルスタック定義ファイルの記述データを説明するための図である。 本発明の実施の形態に係るプロトコルスタックコンパイラが実行するプロトコルスタックコード生成処理のフローチャートである。 １つのメッセージ定義から生成された構造木を示した図である。 同じメッセージクラス名を有する複数のメッセージ定義から生成された構造木を示した図である。 図７の構造木から生成されたオートマトンを示した図である。 図８のオートマトンを実行するオートマトン実行プログラムの処理のフローチャートである。 本発明の実施の形態に係る最適化処理（ツリー統合処理）のフローチャートである。 生成されるコードの例である。 本発明の実施の形態に係る最適化処理（コード統合処理）のフローチャートである。 本発明の実施の形態に係る最適化処理（ＲＡＭエリア共通化処理）のフローチャートである。

符号の説明

１０１：プロトコルスタック定義ファイル、１０２：プロトコルスタックコンパイラ部、１０３：プロトコルスタックコード、１０４：汎用コンパイラ部、１０５：実行コード

Claims (3)

1. 複数のデータ要素を含む一連のデータ列をネットワークを介して受け付けるネットワーク装置に前記データ列を処理させるためのデータ列処理プログラムを、記憶手段及び演算手段を有する情報処理装置に生成させるプログラム生成方法であって、
   前記記憶手段には、前記ネットワーク装置が受け付けるデータ列内の各データ要素のサイズ情報を含むアイテム情報が、当該データ列内におけるデータ要素の順番にしたがって記述された定義ファイルが格納されており、
   当該プログラム生成方法は、
   前記演算手段が、前記定義ファイルを参照する第１の処理と、
   前記演算手段が、前記データ列処理プログラムとして、前記データ列の先頭からの順番にしたがって、当該データ列内の各データ要素を、予め定めたサイズのデータずつ処理するためのプログラムを、前記定義ファイル内における前記各データ要素のアイテム情報の記述順番及び前記各データ要素のサイズ情報に基づき生成する第２の処理と、を含み、
   前記第２の処理では、
   前記定義ファイル内における前記各データ要素のアイテム情報の記述に基づき、処理順序を定義する構造木を生成し、
   前記構造木に含まれる１つのノードから分岐したそれぞれのノード群での処理において、利用するＲＡＭエリアを共通化する、
   ことを特徴とするプログラム生成方法。
2. 複数のデータ要素を含む一連のデータ列をネットワークを介して受け付けるネットワーク装置に前記データ列を処理させるためのデータ列処理プログラムを生成するプログラム生成装置であって、
   前記ネットワーク装置が受け付けるデータ列内の各データ要素のサイズ情報を含むアイテム情報が、当該データ列内におけるデータ要素の順番にしたがって記述された定義ファイルが格納された記憶手段と、
   前記データ列処理プログラムとして、前記データ列の先頭からの順番にしたがって、当該データ列内の各データ要素を、予め定めたサイズのデータずつ処理するためのプログラムを、前記定義ファイル内における前記各データ要素のアイテム情報の記述順番及び前記各データ要素のサイズ情報に基づき生成する演算手段と、を備え、
   前記演算手段は、
   前記定義ファイル内における前記各データ要素のアイテム情報の記述に基づき、処理順序を定義する構造木を生成し、
   前記構造木に含まれる１つのノードから分岐したそれぞれのノード群での処理において、利用するＲＡＭエリアを共通化する、
   ことを特徴とするプログラム生成装置。
3. 複数のデータ要素を含む一連のデータ列をネットワークを介して受け付けるネットワーク装置に前記データ列を処理させるためのデータ列処理プログラムの生成処理を、記憶手段及び演算手段を有する情報処理装置に実行させるコンパイラであって、
   前記記憶手段には、前記ネットワーク装置が受け付けるデータ列内の各データ要素のサイズ情報を含むアイテム情報が、当該データ列内におけるデータ要素の順番にしたがって記述された定義ファイルが格納されており、
   当該コンパイラは、
   前記演算手段が、前記定義ファイルを参照する第１の処理と、
   前記演算手段が、前記データ列処理プログラムとして、前記データ列の先頭からの順番にしたがって、当該データ列内の各データ要素を、予め定めたサイズのデータずつ処理するためのプログラムを、前記定義ファイル内における前記各データ要素のアイテム情報の記述順番及び前記各データ要素のサイズ情報に基づき生成する第２の処理と、を前記情報処理装置に実行させ、
   前記第２の処理では、
   前記定義ファイル内における前記各データ要素のアイテム情報の記述に基づき、処理順序を定義する構造木を生成し、
   前記構造木に含まれる１つのノードから分岐したそれぞれのノード群での処理において、利用するＲＡＭエリアを共通化する、
   ことを特徴とするコンパイラ。

Images