(57)【要約】【課題】メモリ領域の記憶容量が限られているので、プログラム内で用いられる変数をより効率的に配置できる技術が要望されている。【解決手段】複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理プログラムが提供される。ソースプログラムまたはソースプログラムから生成されたオブジェクトコードから、ソースプログラム内で用いられる各変数を複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報が配置判断情報として出力される。配置判断情報は、ソースプログラム内で用いられる集成体変数については、当該集成体変数の要素別の情報を含む。【選択図】図７
2017068343.tif 000002
【特許請求の範囲】
【請求項１】
複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理プログラムであって、前記プログラミング言語処理プログラムはコンピュータに、
ソースプログラムまたはソースプログラムから生成されたオブジェクトコードを読み込むステップと、
前記読み込まれたソースプログラムまたはオブジェクトコードから、前記ソースプログラム内で用いられる各変数を前記複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集し、配置判断情報として出力するステップとを実行させ、
前記出力するステップは、前記ソースプログラム内で用いられる集成体変数について、当該集成体変数の要素別に情報を収集するステップを含む、プログラミング言語処理プログラム。
【請求項２】
前記プログラミング言語処理プログラムはコンピュータに、
前記配置判断情報に基づいて、前記集成体変数以外の各変数および前記集成体変数の各要素について、前記複数のメモリ領域のうち特定のメモリ領域に配置すべき度合い、または、前記複数のメモリ領域のうち特定のメモリ領域以外に配置すべき度合いを算出するステップと、
前記算出された度合いに基づいて、いずれかの集成体変数の要素を前記特定のメモリ領域に配置すべきと決定されると、前記ソースプログラム内の当該集成体変数をスカラ化するステップとをさらに実行させる、請求項１に記載のプログラミング言語処理プログラム。
【請求項３】
前記プログラミング言語処理プログラムはコンピュータに、
前記集成体変数がスカラ化された状態でオブジェクトコードを生成するステップをさらに実行させる、請求項２に記載のプログラミング言語処理プログラム。
【請求項４】
前記プログラミング言語処理プログラムはコンピュータに、
前記ソースプログラム内で用いられる集成体変数のうち、内包するいずれかの要素が当該集成体変数の変数シンボル名を指定する方法とは異なる方法で指定されている集成体変数を特定するステップをさらに実行させ、
前記スカラ化するステップは、内包する要素が前記異なる方法で指定されている集成体変数をスカラ化の対象から除外するステップを含む、請求項２に記載のプログラミング言語処理プログラム。
【請求項５】
前記プログラミング言語処理プログラムはコンピュータに、
前記オブジェクトコードから実行可能ファイルを生成するステップと、
前記実行可能ファイルが前記マイクロコンピュータで実行されたときの情報に基づいて、前記配置判断情報の内容を更新するステップとをさらに実行させる、請求項１に記載のプログラミング言語処理プログラム。
【請求項６】
前記配置判断情報は、各変数が参照される総回数、各変数が示すデータの大きさ、各変数が参照されるソースプログラムの区間、各変数がループ命令において参照されているか否か、のうち少なくとも１つを含む、請求項１に記載のプログラミング言語処理プログラム。
【請求項７】
前記出力するステップは、前記オブジェクトコードが読み込まれると、前記配置判断情報において、前記ソースプログラム内で用いられる集成体変数の各要素を、集成体変数のシンボル名と１または複数のオフセット値との組み合わせを用いて特定するステップを含む、請求項１に記載のプログラミング言語処理プログラム。
【請求項８】
前記特定のメモリ領域は、他のメモリ領域に比較して記憶容量が小さい、請求項２に記載のプログラミング言語処理プログラム。
【請求項９】
複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理装置であって、
ソースプログラムまたはソースプログラムから生成されたオブジェクトコードを受け付ける入力手段と、
前記ソースプログラムまたは前記オブジェクトコードから、前記ソースプログラム内で用いられる各変数を前記複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集し、配置判断情報として出力する出力手段とを備え、
前記出力手段は、前記ソースプログラム内で用いられる集成体変数について、当該集成体変数の要素別に情報を収集する、プログラミング言語処理装置。
【請求項１０】
複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理方法であって、
コンピュータが、ソースプログラムまたはソースプログラムから生成されたオブジェクトコードを読み込むステップと、
コンピュータが、前記読み込まれたソースプログラムまたはオブジェクトコードから、前記ソースプログラム内で用いられる各変数を前記複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集し、配置判断情報として出力するステップとを備え、
前記出力するステップは、前記ソースプログラム内で用いられる集成体変数について、当該集成体変数の要素別に情報を収集するステップを含む、プログラミング言語処理方法。
【請求項１１】
複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理プログラムであって、前記プログラミング言語処理プログラムはコンピュータに、
ソースプログラムまたはソースプログラムから生成されたオブジェクトコードから、前記ソースプログラム内で用いられる各変数を前記複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集するステップと、
前記収集した情報に基づいて、前記ソースプログラム内で用いられる集成体変数以外の各変数および集成体変数の各要素のうち、前記複数のメモリ領域のうち特定のメモリ領域に配置すべきものを決定し、前記特定のメモリ領域に配置すべきと決定された要素を内包する集成体変数をスカラ化するステップとを実行させる、プログラミング言語処理プログラム。
【請求項１２】
前記プログラミング言語処理プログラムはコンピュータに、
前記集成体変数がスカラ化された状態でオブジェクトコードを生成するステップをさらに実行させる、請求項１１に記載のプログラミング言語処理プログラム。
【請求項１３】
前記スカラ化するステップは、前記収集した情報に基づいて、前記集成体変数以外の各変数および前記集成体変数の各要素について、前記複数のメモリ領域のうち特定のメモリ領域に配置すべき度合い、または、前記複数のメモリ領域のうち特定のメモリ領域以外に配置すべき度合いを算出するステップを含む、請求項１１に記載のプログラミング言語処理プログラム。
【請求項１４】
前記プログラミング言語処理プログラムはコンピュータに、
前記ソースプログラム内で用いられる集成体変数のうち、内包するいずれかの要素が当該集成体変数の変数シンボル名を指定する方法とは異なる方法で指定されている集成体変数を特定するステップをさらに実行させ、
前記スカラ化するステップは、内包する要素が前記異なる方法で指定されている集成体変数をスカラ化の対象から除外するステップを含む、請求項１１に記載のプログラミング言語処理プログラム。
【請求項１５】
前記プログラミング言語処理プログラムはコンピュータに、
前記オブジェクトコードから実行可能ファイルを生成するステップと、
前記実行可能ファイルが前記マイクロコンピュータで実行されたときの情報に基づいて、前記集成体変数以外の各変数および前記集成体変数の各要素のうち、前記特定のメモリ領域に配置すべきものを更新するステップとをさらに実行させる、請求項１１に記載のプログラミング言語処理プログラム。
【請求項１６】
前記スカラ化するステップは、各変数が参照される総回数、各変数が示すデータの大きさ、各変数が参照されるソースプログラムの区間、各変数がループ命令において参照されているか否か、のうち少なくとも１つに基づいて、前記集成体変数以外の各変数および前記集成体変数の各要素のうち、前記特定のメモリ領域に配置すべきものを決定するステップを含む、請求項１１に記載のプログラミング言語処理プログラム。
【請求項１７】
前記特定のメモリ領域は、他のメモリ領域に比較して記憶容量が小さい、請求項１１に記載のプログラミング言語処理プログラム。
【請求項１８】
複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理装置であって、
ソースプログラムまたはソースプログラムから生成されたオブジェクトコードから、前記ソースプログラム内で用いられる各変数を前記複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集する収集手段と、
前記収集した情報に基づいて、前記ソースプログラム内で用いられる集成体変数以外の各変数および集成体変数の各要素のうち、前記複数のメモリ領域のうち特定のメモリ領域に配置すべきものを決定し、前記特定のメモリ領域に配置すべきと決定された要素を内包する集成体変数をスカラ化するスカラ化手段とを備える、プログラミング言語処理装置。
【請求項１９】
複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理方法であって、
コンピュータが、ソースプログラムまたはソースプログラムから生成されたオブジェクトコードから、前記ソースプログラム内で用いられる各変数を前記複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集するステップと、
コンピュータが、前記収集した情報に基づいて、前記ソースプログラム内で用いられる集成体変数以外の各変数および集成体変数の各要素のうち、前記複数のメモリ領域のうち特定のメモリ領域に配置すべきものを決定し、前記特定のメモリ領域に配置すべきと決定された要素を内包する集成体変数をスカラ化するステップとを実行させる、プログラミング言語処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理プログラム、プログラミング言語処理装置、およびプログラミング言語処理方法に関する。
【背景技術】
【０００２】
プログラムの実行速度を向上させる目的で、通常のメモリ領域に加えて、データ読み出し／書き込みおよび命令の実行を高速に行うことのできる特定メモリ領域を内蔵したマイクロコンピュータが開示されている。例えば、特開平０９−０４４３６３号公報（特許文献１）は、このようなマイクロコンピュータにおいて、メモリ管理の実施をユーザにより行うことが不必要となり、これによりプログラムの作成時におけるユーザとしての所要工数を低減するための言語処理プログラムの処理方式を開示する。
【０００３】
「CubeSuite+ V2.00.00  統合開発環境  ユーザーズマニュアル  RL78,78K0R  ビルド編Rev.1.00」（非特許文献１）は、マイクロコンピュータのメモリ領域として、ショート・ダイレクト・アドレッシング（ｓａｄｄｒアドレッシング）というアドレスを８ビットで特定できる領域（ｓａｄｄｒ領域）が用意されていることを開示する（例えば、非特許文献１の６９６ページ）。ｓａｄｄｒ領域を参照するために専用命令が用意されており、この専用命令は、通常のメモリ領域を参照するための命令に比較してその命令長（サイズ）が１バイトだけ小さいという特長を有している。このような専用命令を用いることで、ユーザプログラムのサイズが小さくなり、ユーザシステムのコストを低減できる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平０９−０４４３６３号公報
【非特許文献】
【０００５】
【非特許文献１】「CubeSuite+ V2.00.00  統合開発環境  ユーザーズマニュアル  RL78,78K0R  ビルド編Rev.1.00」、［online］、２０１３年１２月、ルネサスエレクトロニクス、［２０１５年９月１日検索］、インターネット〈URL：http://documentation.renesas.com/doc/products/tool/doc/r20ut2623jj0100_qsbd78.pdf〉
【発明の概要】
【発明が解決しようとする課題】
【０００６】
例えば、非特許文献１に開示されるｓａｄｄｒ領域には、汎用レジスタおよびポートも配置されるため、変数／関数情報ファイル生成ツールがデータを配置できる領域の記憶容量は１９２バイトであるとされている。このように、メモリ領域の記憶容量が限られているので、プログラム内で用いられる変数をより効率的に配置できる技術が要望されている。
【０００７】
その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【０００８】
ある実施の形態に従えば、複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理プログラムが提供される。ソースプログラムまたはソースプログラムから生成されたオブジェクトコードから、ソースプログラム内で用いられる各変数を複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報が配置判断情報として出力される。配置判断情報は、ソースプログラム内で用いられる集成体変数については、当該集成体変数の要素別の情報を含む。
【０００９】
別の実施の形態に従えば、複数のメモリ領域を有するマイクロコンピュータに向けられたプログラミング言語処理プログラムが提供される。ソースプログラム内で用いられる集成体変数以外の各変数および集成体変数の各要素のうち、複数のメモリ領域のうち特定のメモリ領域に配置すべきものを決定し、特定のメモリ領域に配置すべきと決定された要素を内包する集成体変数をスカラ化する。
【発明の効果】
【００１０】
ある実施の形態によれば、プログラム内で用いられる変数をより効率的に配置できる。
【図面の簡単な説明】
【００１１】
【図１】特許文献１に開示される言語処理手段のブロック図である。
【図２】非特許文献１に開示される統合開発環境の機能構成を示す模式図である。
【図３】ソースプログラムの一例を示す図である。
【図４】図３に示すソースプログラムに対してリンカが出力した変数／関数情報ファイルの一例を示す図である。
【図５】図４に示す変数／関数情報ファイルを用いて図３に示すソースプログラムをコンパイルした結果を示す図である。
【図６】本実施の形態に従うプログラミング言語処理系での課題解決の一手法を説明する概念図である。
【図７】本実施の形態に従うプログラミング言語処理系での課題解決の一手法を説明する概念図である。
【図８】実施の形態１に従うプログラミング言語処理装置のハードウェア構成を示す模式図である。
【図９】本実施の形態に従うプログラミング言語処理系が想定するマイクロコンピュータのハードウェア構成の要部を示す模式図である。
【図１０】本実施の形態に従うプログラミング言語処理系が想定するマイクロコンピュータのハードウェア構成の要部を示す模式図である。
【図１１】本実施の形態に従うプログラミング言語処理系が想定するマイクロコンピュータのハードウェア構成の要部を示す模式図である。
【図１２】実施の形態１に従うプログラミング言語処理装置の機能構成を示す模式図である。
【図１３】配置判断情報をファイルに書き出した配置判断情報ファイルの一例を示す図である。
【図１４】実施の形態１に従うプログラミング言語処理装置でのスカラ化の一例を説明するための図である。
【図１５】実施の形態１に従うプログラミング言語処理装置での処理手順を示すフローチャートである。
【図１６】実施の形態２に従うプログラミング言語処理装置の機能構成を示す模式図である。
【図１７】配置判断情報をファイルに書き出した配置判断情報ファイルの一例を示す図である。
【図１８】実施の形態２に従うプログラミング言語処理装置での処理手順を示すフローチャートである。
【図１９】実施の形態３に従うプログラミング言語処理装置の機能構成を示す模式図である。
【図２０】実施の形態３に従うプログラミング言語処理装置での処理手順を示すフローチャートである。
【図２１】実施の形態４に従う統合開発環境での処理および機能を説明する模式図である。
【発明を実施するための形態】
【００１２】
本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。
【００１３】
［Ａ．関連技術］
まず、本実施の形態に従うプログラミング言語処理系の技術的意義をより明りょう化するために、上述の先行技術に開示される関連技術について説明する。
【００１４】
（ａ１：特許文献１に開示される言語処理手段）
図１は、特許文献１に開示される言語処理手段のブロック図である。図１に開示される言語処理手段９０２は、プログラミング言語を用いて記述されたソースファイル９０１を入力として、オブジェクトファイル９０３を出力する。より具体的には、言語処理手段９０２は、ソースファイル９０１の入力を受け付ける入力部９０４と、ソースファイル９０１に記述されたソースプログラムを内部表現に変換する構文解析部９０５と、配置指定情報ファイル９０８を出力する配置指定情報出力部９０６と、オブジェクトファイル９０３を生成するオブジェクトコード出力部９０７とを含む。なお、図１には、特許文献１に開示される言語処理手段のうち、特に、メモリへの変数配置の処理に関する部分を模式的に示す。
【００１５】
配置指定情報出力部９０６は、構文解析部９０５による構文解析の結果に基づいて、特定メモリ領域に配置すべき変数を抽出して、その結果を配置指定情報ファイル９０８として出力する。配置指定情報ファイル９０８は、オブジェクトコード出力部９０７に含まれる配置指定情報ファイル入力部９１２によって読み込まれ、オブジェクトコード出力部９０７は、配置指定情報ファイル９０８において指定されている変数を特定メモリ領域に配置するようなオブジェクトコードを生成する。
【００１６】
以上のように、特許文献１に開示される言語処理手段は、ソースファイル９０１を解析して変数のメモリ配置を決定し、その決定したメモリ配置の内容を配置指定情報ファイル９０８として出力し、配置指定情報ファイル９０８に基づいてオブジェクトファイル９０３を生成する。このような技術を採用することで、汎用のプログラミング言語を用いて記述したソースプログラムから特定メモリ領域を活用するオブジェクトファイルを自動的に生成できる。
【００１７】
（ａ２：非特許文献１に開示される統合開発環境）
非特許文献１は、本願出願人が製造販売するマイクロコンピュータに向けられた統合開発環境のマニュアルであり、特許文献１に開示される技術の一つの応用例を説明するものである。
【００１８】
図２は、非特許文献１に開示される統合開発環境の機能構成を示す模式図である。図２を参照して、非特許文献１に開示される統合開発環境は、プログラミング言語を用いて記述されたソースプログラム９５１が入力されると、オブジェクトコード９５３への変換を経て、最終的に実行可能ファイル９５６を出力する。図２に示す統合開発環境は、コンパイラ９５２およびリンカ９５４を含む。コンパイラ９５２は、ソースプログラム９５１を構文解析してオブジェクトコード９５３を生成する。リンカ９５４は、入力されたオブジェクトコード９５３内で用いられる変数に対して順序付けを行い、この順序に基づいて、各変数単位でｓａｄｄｒ領域へ配置できるか否かを判断する。リンカ９５４は、ｓａｄｄｒ領域へ配置できると判断した変数についての情報を、変数／関数情報ファイル９５５として出力する。その後、ソースプログラム９５１が変数／関数情報ファイル９５５とともに、コンパイラ９５２へ再度入力されることで、リンカ９５４によって配置可能と判断された変数をｓａｄｄｒ領域に配置したオブジェクトコード９５３および実行可能ファイル９５６が生成される。
【００１９】
（ａ３：非特許文献１に開示される統合開発環境のユーザプログラム例）
次に、非特許文献１に開示される統合開発環境を用いたユーザプログラムの一例について説明する。図３は、ソースプログラム９５１の一例を示す図である。図３に示すソースプログラム９５１では、５つの変数ｃ，ｉ，ｊ，ｌ，ｓが定義されている（１〜４行目参照）。
【００２０】
１行目に定義される変数ｃは、ｃｈａｒ型（文字型）であり、データサイズは１バイトである。２行目に定義される変数ｉおよびｊは、ｉｎｔ型（整数型）であり、データサイズは２バイトである。３行目に定義される変数ｌは、ｌｏｎｇ型（倍長整数型）であり、データサイズは４バイトである。４行目に定義される変数ｓは、ｓｔｒｕｃｔ（構造体）として定義されており、ｉｎｔ型（整数型）の変数ａおよび変数ｂ、ならびに、ｉｎｔ型（整数型）の要素数２００の配列ｃとの集成体変数である。その結果、変数ｓのデータサイズは４０４バイト（＝２＋２＋２×２００）となる。
【００２１】
また、参照回数についてみると、変数ｃの参照回数は１回（６行目）であり、変数ｉの参照回数は１回（７行目）であり、変数ｊの参照回数は２回（７行目および８行目）であり、変数ｌの参照回数は２回（８行目）であり、変数ｓの参照回数は４回（１１行目）である。変数ｌはｌｏｎｇ型（倍長整数型）のデータであるので、ソースプログラム９５１上での１回の使用によって、上位バイトおよび下位バイトの２回の参照が発生する。
【００２２】
なお、ソースプログラム９５１上とオブジェクトコード９５３上との間で、参照回数は必ずしも一致しない。例えば、図３に示すソースプログラム９５１の８行目に記述されている変数ｊの値と、９行目に記述されている２が加算される変数ｊ（被加算変数）の値とは同じである。そのため、オブジェクトコード９５３上では、８行目でメモリ領域にある変数ｊの値を参照した後、９行目で再度メモリ領域を参照するのではなく、内部レジスタに一時格納されている変数ｊの値を再利用するように最適化される。
【００２３】
図４は、図３に示すソースプログラム９５１に対してリンカ９５４が出力した変数／関数情報ファイル９５５の一例を示す図である。
【００２４】
非特許文献１の統合開発環境は、データサイズあたりの参照回数が多い変数から順にｓａｄｄｒ領域に配置する。すなわち、各変数について、（参照回数／データサイズ）を評価値として算出し、その評価値が大きいものからｓａｄｄｒ領域に配置する。
【００２５】
図４に示す変数／関数情報ファイル９５５の各行に含まれる「／＊」と「＊／」との対は、コメントであることを意味し、「／＊」から始まり、「＊／」で終わる部分までは、無効な記述であり、処理には用いられない。したがって、上述の変数／関数情報ファイル９５５は、２行目から５行目の各行にある「＃ｐｒａｇｍａ  ｓａｄｄｒ  （変数シンボル名）」という記述のみが有効な記述となる。「＃ｐｒａｇｍａ  ｓａｄｄｒ  （変数シンボル名）」という記述は、（変数シンボル名）に示した名前の変数をｓａｄｄｒ領域に配置するためのコンパイラ９５２に対する指示文に相当する。
【００２６】
また、２行目から５行目のコメント部分に含まれる「ｃｏｕｎｔ」は参照回数を示し、「ｓｉｚｅ」はデータサイズ（バイト）を示す。
【００２７】
図４に示す変数／関数情報ファイル９５５の記述によれば、変数ｃ，ｉ，ｊ，ｌは、ｓａｄｄｒ領域に配置されるが、変数ｓはｓａｄｄｒ領域には配置されない。これは、変数ｃ，ｉ，ｊ，ｌをｓａｄｄｒ領域（例えば、１９２バイト）に配置すると、ｓａｄｄｒ領域には、変数ｓを配置するだけの空き領域が残らないからである。
【００２８】
図５は、図４に示す変数／関数情報ファイル９５５を用いて図３に示すソースプログラム９５１をコンパイルした結果を示す図である。図５に示すコンパイル結果によれば、変数ｃ，ｉ，ｊ，ｌは、ｓａｄｄｒ領域（．ｓｂｓｓセクション）に配置されているのに対し、変数ｓは、通常のメモリ領域（．ｂｓｓセクション）に配置されていることがわかる。
【００２９】
［Ｂ．新たな課題の着想および課題解決の手法］
本願出願人らは、その鋭意研究によって、上述したような現象から以下のような新たな課題を見出し、そして、その新たな課題に対する解決手段に想到した。すなわち、本願出願人らは、既存の統合開発環境において、以下のような課題の存在を見出した。
【００３０】
（ｂ１：新たな課題の着想）
非特許文献１に開示される統合開発環境では、特定メモリ領域に配置すべきか否かを判断する最小のデータ単位は、ソースプログラムに定義される変数である。このように変数単位で特定メモリ領域に配置すべきか否かを判断する場合には、以下の（１）および（２）のような問題が生じ得る。
【００３１】
（１）集成体変数は通常の変数（スカラ変数）に比べて特定メモリ領域に配置される優先度は低く見積もられやすい。
【００３２】
スカラ変数は、１個のデータを表す変数を意味し、上述のソースプログラム９５１において定義される変数ｃ，ｉ，ｊ，ｌに相当する。集成体変数は、複数のデータをまとめて扱うための変数を意味し、上述のソースプログラム９５１において定義される変数ｓに相当する。すなわち、集成体変数は、複数種類のデータを内包する。
【００３３】
集成体変数は、スカラ変数に比較して、データサイズが大きくなりやすく、内包される個々のデータの参照回数に偏りがあるため、データサイズあたりの参照回数（参照回数／データサイズ）は、スカラ変数に比べて小さくなりやすい。その結果、集成体変数は、特定メモリ領域へ配置されるべき順序が上位とはなりにくい傾向がある。
【００３４】
集成体変数に内包される個々のデータは要素またはメンバとも称され、以下の説明では、これらを「要素」と記載する。すなわち、本明細書において、「集成体変数の要素」とは、集成体変数に内包される個々のデータを意味する。
【００３５】
上述のソースプログラム９５１を例に取ると、各変数の参照回数は、ｓ＞ｊ＝ｌ＞ｃ＝ｉであるが、データサイズあたりの参照回数は、ｃ＝ｊ＞ｉ＝ｌ＞ｓとなる。すなわち、参照回数自体は多いが、全体としてのデータサイズが大きいので、データサイズあたりの参照回数としては小さい値になってしまう。
【００３６】
（２）集成体変数は特定メモリ領域への配置対象にはできない場合がある。
一般的に、集成体変数にまとめられるデータの数はソースプログラムの内容に依存し、さらに他の集成体変数を入れ子にして内包することもできる。そのため、集成体変数のデータサイズが特定メモリ領域の記憶容量を超過することがある。特定メモリ領域の記憶容量を超過した集成体変数は、いくら参照回数が多くても特定メモリ領域への配置対象にはできない。上述のソースプログラム９５１を例に取ると、変数ｓは他のいずれの変数よりも多い４回参照されるにもかかわらず、そもそもデータサイズが４０４バイトもあり、特定メモリ領域の記憶容量（例えば、１９２バイト）を超過しているため、必ず通常メモリ領域に配置されることになる。
【００３７】
（ｂ２：課題解決の一手法）
図６および図７は、本実施の形態に従うプログラミング言語処理系での課題解決の一手法を説明する概念図である。本実施の形態に従うプログラミング言語処理系は、複数のメモリ領域を有するマイクロコンピュータに向けられる。
【００３８】
図６には、先行技術に従う変数の配置処理を模式的に示す。互いに異なる特性を有する複数のメモリ領域が実装されたマイクロコンピュータについて、集成体変数の全体としてデータサイズまたは評価値が算出されると、記憶容量の小さなメモリ領域（特定メモリ領域）には、集成体変数を配置できない場合がある。図６には、集成体変数の全体のデータサイズが特定メモリ領域の記憶容量を超過している例を示す。
【００３９】
これに対して、図７に示す、本実施の形態に従うプログラミング言語処理系においては、変数の配置先を決定するために必要な情報として、配置判断情報２０を生成および更新する。配置判断情報２０は、ソースプログラム内で用いられる各変数を、複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報である。
【００４０】
本実施の形態に従うプログラミング言語処理系においては、ソースプログラムまたはソースプログラムから生成されたオブジェクトコードから、配置判断情報２０を収集する。配置判断情報２０は、典型的には、ファイルとして出力され、外部アプリケーションなどからも参照可能になっている。
【００４１】
本実施の形態に従うプログラミング言語処理系において出力される配置判断情報２０は、変数の配置先について既に決定した情報ではなく、これから配置するかどうかを判断するのに必要な情報である。この意味において、配置判断情報２０は、変数の配置先を指定するための、図１に示す配置指定情報ファイル９０８、および、図２に示す変数／関数情報ファイル９５５とは本質的に異なっている。
【００４２】
特に、変数単位で一律に情報を格納するのではなく、集成体変数については要素単位で出力される。すなわち、配置判断情報２０には、情報が集成体変数の要素単位で格納される。このような配置判断情報２０を用いることで、集成体変数の要素単位の情報を考慮して、変数の配置先などを最適化することができる。
【００４３】
ソースプログラム内で使用される集成体変数は、配置判断情報２０に基づいて選択的にスカラ化されてもよい。本実施の形態に従うプログラミング言語処理系においては、集成体変数に内包される要素のうち、特定の要素を特定メモリ領域に配置すべきと判断されると、該当する要素を内包する集成体変数を優先的にスカラ化する。スカラ変数単位および要素単位で配置判断情報２０が生成されるので、集成体変数に内包される要素の各々をあたかも別個のスカラ変数とみなして、特定メモリ領域への配置の要否を判断できる。
【００４４】
このように、本実施の形態に従うプログラミング言語処理系においては、収集した配置判断情報２０に基づいて、ソースプログラム内で用いられる集成体変数以外の各変数および集成体変数の各要素のうち、複数のメモリ領域のうち特定のメモリ領域に配置すべきものを決定し、特定のメモリ領域に配置すべきと決定された要素を内包する集成体変数をスカラ化する。配置判断情報２０に含まれる情報の内容については、後に詳述する。
【００４５】
図７には、ソースプログラム内で集成体変数ｓ１および集成体変数ｓ２が用いられている例を示す。配置判断情報２０に基づく判断の結果、集成体変数ｓ１については、スカラ化して、それに内包される変数ａ，ｂ，ｃ０，ｃ１を特定メモリ領域に配置すべきと判断されている。一方、集成体変数ｓ２については、スカラ化することなく、集成体変数のまま通常メモリ領域に配置すべきと判断されている。
【００４６】
このように、配置判断情報２０に基づいてスカラ化する対象の集成体変数を選択することで、スカラ化による弊害を抑制しつつ、全体としてのプログラムの実行速度を向上させることができる。このスカラ化の手順およびスカラ化による弊害については、後に詳述する。
【００４７】
本実施の形態に従うプログラミング言語処理系にて扱う「集成体（Aggregates）」または「集成体変数」は、特定のプログラミング言語において用いられる狭義の意味の他、複数のデータを包含するデータの集合を含み得る。すなわち、本明細書において「集成体」は、複数のデータ（要素またはメンバ）を１つのシンボル名で扱うことのできるものであれば、どのようなものであってもよい。本明細書における「集成体」には、「配列」および「共用体」を含み得る。
【００４８】
［Ｃ．実施の形態１］
次に、本発明の実施の形態１に従うプログラミング言語処理系について説明する。
【００４９】
（ｃ１：プログラミング言語処理装置のハードウェア構成）
実施の形態１に従うプログラミング言語処理装置１００は、典型的には、パーソナルコンピュータなどの汎用コンピュータがプログラムを実行することで実現される。以下、汎用コンピュータを用いたプログラミング言語処理装置１００の実装例について説明する。
【００５０】
図８は、実施の形態１に従うプログラミング言語処理装置１００のハードウェア構成を示す模式図である。図８を参照して、プログラミング言語処理装置１００は、主たるコンポーネントとして、プロセッサ１０２と、主メモリ１０４と、入力部１０６と、表示部１０８と、補助記憶装置１１０と、光学ドライブ１２０と、ローカル通信インターフェイス１２４と、ネットワークインターフェイス１２６とを含む。これらのコンポーネントは、バス１２８を介して、互いにデータ通信可能に構成される。
【００５１】
プロセッサ１０２は、プログラムに従って、指定された命令を指定された順序で実行する演算主体であり、例えば、１または複数のＣＰＵ（Central Processing Unit）またはＭＰＵ（Micro Processing Unit）などで構成される。複数のコアを有するようなＣＰＵまたはＭＰＵを用いてもよい。
【００５２】
主メモリ１０４は、プロセッサ１０２がプログラムに従って処理を実行するために必要なデータなどを一時的に格納するワーキングメモリとして機能し、例えば、ＤＲＡＭ（Dynamic Random Access Memory）などの揮発性記憶装置で構成される。
【００５３】
入力部１０６は、ユーザ操作または外部装置からの指示を受け付けるコンポーネントであり、例えば、キーボード、マウス、タッチパネル、ペンタブレットなどで構成される。
【００５４】
表示部１０８は、プロセッサ１０２による情報処理の結果などをユーザへ通知するコンポーネントであり、例えば、ディスプレイまたは各種インジケータなどで構成される。
【００５５】
補助記憶装置１１０は、プロセッサ１０２にて実行されるプログラム、任意のプログラムに入力されるデータ、および、任意のプログラムの実行により生成されるデータなどを記憶するコンポーネントであり、例えば、ハードディスク、ＳＳＤ（Solid State Drive）などの不揮発性記憶装置で構成される。
【００５６】
プログラミング言語処理装置１００の補助記憶装置１１０には、典型的には、ＯＳ（Operating System）１１２、および、プログラミング言語処理プログラム１１４（以下、「処理プログラム１１４」とも略称する。）が格納される。ＯＳ１１２は、各種プログラムの実行環境を提供するためのプログラムモジュール群を含む。処理プログラム１１４は、後述するような本実施の形態に従うプログラミング言語処理系を実現するためのプログラムモジュール群を含む。
【００５７】
光学ドライブ１２０は、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＤＶＤ（Digital Versatile Disc）などの光学ディスク１２２に格納されている情報を読出して、バス１２８を介して他のコンポーネントへ出力する。光学ディスク１２２は、非一時的（non-transitory）な記録媒体の一例であり、処理プログラム１１４などを不揮発的に格納した状態で流通する。光学ドライブ１２０が光学ディスク１２２から処理プログラム１１４を読み出して、処理プログラム１１４を補助記憶装置１１０にインストールすることで、汎用コンピュータであるパーソナルコンピュータがプログラミング言語処理装置１００として機能するようになる。したがって、本発明の主題は、処理プログラム１１４自体、または、処理プログラム１１４が格納された光学ディスク１２２などの記録媒体でもあり得る。
【００５８】
ローカル通信インターフェイス１２４は、マイクロコンピュータなどの周辺機器と通信するためのコンポーネントであり、例えば、ＵＳＢ（Universal Serial Bus）、シリアルバス、パラレルバス、イーサネット（登録商標）、無線ＬＡＮ（Local Area Network）、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの任意の通信方式を採用できる。
【００５９】
ネットワークインターフェイス１２６は、インターネット上またはイントラネット上のサーバ装置などとの間でデータを遣り取りするためのコンポーネントであり、例えば、イーサネット（登録商標）、無線ＬＡＮ（Local Area Network）、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの任意の通信方式を採用できる。
【００６０】
図８には、非一時的な記録媒体の一例として光学ディスク１２２などの光学記録媒体を示すが、これに限らず、フラッシュメモリなどの半導体記録媒体、ハードディスクまたはストレージテープなどの磁気記録媒体、ＭＯ（Magneto-Optical disk）などの光磁気記録媒体を用いてもよい。
【００６１】
処理プログラム１１４は、上述したような何らかの記録媒体に格納されて流通するだけでなく、インターネットまたはイントラネットを介してサーバ装置からダウンロードされてもよい。
【００６２】
図８には、典型例として、後述するようなプログラミング言語処理系を実現する処理プログラム１１４がインストールされている例を示すが、処理プログラム１１４がそれ単体で存在するか否かは特に制限されない。例えば、処理プログラム１１４は、統合開発環境アプリケーションの一部の機能モジュールとして組み込まれていてもよい。あるいは、複数のプログラムモジュールが連携することで、処理プログラム１１４に相当する機能を実現するようにしてもよい。さらに、処理プログラム１１４に必要な機能モジュールの一部を、ＯＳ１１２により提供される機能またはライブラリを用いて実現するようにしてもよい。この場合には、処理プログラム１１４単体は、本実施の形態に従うプログラミング言語処理系を実現するために必要なプログラムモジュールのすべてを含むわけではないが、ＯＳ１１２が提供する実行環境下にインストールされることで、プログラミング言語処理系を実現することができる。このような一部のプログラムモジュールを含まない処理プログラムであっても、本発明の技術的範囲に含まれ得る。
【００６３】
図８には、プログラミング言語処理装置１００単体で本実施の形態に従うプログラミング言語処理系を実現する例を示すが、これに限らず、処理の一部または全部をネットワーク上の１または複数のサーバ装置にて実行するようにしてもよいし、補助記憶装置１１０に格納される任意のデータをネットワーク上の１または複数のサーバ装置に格納するようにしてもよい。
【００６４】
さらに、コンピュータ（プロセッサ１０２）がプログラムを実行することで実現される機能の全部または一部を、集積回路などのハードワイヤード回路（hard-wired circuit）を用いて実現してもよい。例えば、プログラミング言語処理装置１００をＡＳＩＣ（Application Specific Integrated Circuit）を用いて実現してもよい。あるいは、ＦＰＧＡ（Field-Programmable Gate Array）などを用いてもよい。
【００６５】
当業者であれば、本発明が実施される時代に応じた技術を適宜用いて、本実施の形態に従うプログラミング言語処理装置を実現するであろう。
【００６６】
（ｃ２：マイクロコンピュータの構成）
次に、本実施の形態に従うプログラミング言語処理系が想定するマイクロコンピュータの構成について説明する。実施の形態１および他の実施の形態においては、複数のメモリ領域を有するマイクロコンピュータを想定している。図９〜図１１は、本実施の形態に従うプログラミング言語処理系が想定するマイクロコンピュータのハードウェア構成の要部を示す模式図である。
【００６７】
図９を参照して、マイクロコンピュータ２００は、演算処理部２１０と、第１メモリ２２２および第２メモリ２２４を含むメモリ群２２０と、演算処理部２１０およびメモリ群２２０を接続するバス２３０を含む。
【００６８】
演算処理部２１０は、典型的には、プログラムカウンタ（ＰＣ：Program Counter）２０２と、命令メモリ２０４と、レジスタ２０６と、算術論理演算装置（ＡＬＵ：Arithmetic and Logic Unit）２０８とを含む。
【００６９】
第１メモリ２２２および第２メモリ２２４は、互いに異なる特性を有する。典型的には、第１メモリ２２２は、第２メモリ２２４に比較して記憶容量は小さいが、アクセスに要する時間は短いという特性を有している。これに加えて、例えば、第１メモリ２２２は、短縮化されたアドレス付けがなされており、第２メモリ２２４を参照するための命令に比較して、その命令長が小さくなっていてもよい。
【００７０】
図１０に示すマイクロコンピュータ２００Ａは、図９に示すマイクロコンピュータ２００に比較して、メモリ群２２０に代えて、バス２３０に接続されるメモリ２２６、および、レジスタ２０６の一部に設けられる特殊領域２０７を有している。マイクロコンピュータ２００Ａにおいては、特殊領域２０７へのアクセスは、バス２３０を介して行う必要がないので、特殊領域２０７の参照に要する時間は、メモリ２２６の参照に要する時間に比較して短くなる。
【００７１】
図１１に示すマイクロコンピュータ２００Ｂは、図１０に示すマイクロコンピュータ２００Ａに比較して、レジスタ２０６の一部に設けられる特殊領域２０７に代えて、バスコネクション２５４およびバス２５０を介して接続されるメモリ２５２が設けられている。図１１に示す構成においては、メモリ２５２へのアクセス経路は、メモリ２２６へのアクセス経路に比較して長くなるので、メモリ２５２の参照に要する時間は、メモリ２２６の参照に要する時間に比較して長くなる。一方で、メモリ２５２は、演算処理部２１０とは独立して構成することができるので、メモリ２２６の記憶容量に比較してより大きな記憶容量を有するメモリ２５２を実装することができる。
【００７２】
図９〜図１１に示すマイクロコンピュータの構成は一例であって、これらに限られるものではない。本実施の形態に従うプログラミング言語処理系は、複数のメモリ領域（図９〜図１１に示すような２種類に限られず、より多くの種類が実装されていてもよい）に対して、変数として参照され得るデータを効率的に配置する手法に向けられている。典型的には、プログラムの実行中に参照される回数（頻度）が相対的に多い変数については、参照に要する時間が相対的に短いメモリ領域に配置される。逆に、プログラムの実行中に参照される回数が相対的に少ない変数については、参照に要する時間が相対的に長いメモリ領域に配置される。本実施の形態に従うプログラミング言語処理系は、データの配置先として複数の候補が存在し得る構成であれば、その具体的な構成に限定されず広く適用可能である。
【００７３】
以下の説明においては、参照に要する時間が相対的に短いメモリ領域を「特定メモリ領域」と称し、参照に要する時間が相対的に長いメモリ領域を「通常メモリ領域」と称す。図９〜図１１の構成例で見ると、「特定メモリ領域」は、図９の第１メモリ２２２、図１０の特殊領域２０７、図１１のメモリ２２６に相当する。一方、「通常メモリ領域」は、図９の第２メモリ２２４、図１０のメモリ２２６、図１１のメモリ２５２に相当する。
【００７４】
本実施の形態においては、典型例として、「特定メモリ領域」は「通常メモリ領域」に比較して記憶容量が小さい場合を想定する。但し、本実施の形態に従うプログラミング言語処理系は、複数のメモリ領域を有するマイクロコンピュータに対して広汎に適用でき、「特定メモリ領域」と「通常メモリ領域」との間の記憶容量の大小、および、参照に要する時間の長短などについては、任意に選択できる。
【００７５】
（ｃ３：プログラミング言語処理装置の機能構成）
次に、実施の形態１に従うプログラミング言語処理装置１００の機能構成および実行される処理の内容について説明する。
【００７６】
図１２は、実施の形態１に従うプログラミング言語処理装置１００の機能構成を示す模式図である。図１２を参照して、プログラミング言語処理装置１００は、プログラミング言語を用いて記述されたソースプログラム１０が入力されると、構文解析および後述するような処理を経て、オブジェクトコード３０を出力する。すなわち、プログラミング言語処理装置１００は、一種のコンパイラとして機能する。
【００７７】
より具体的には、プログラミング言語処理装置１００は、その機能として、入力モジュール１５０と、構文解析モジュール１５２と、配置判断情報出力モジュール１５４と、別名解析モジュール１５６と、スカラ化処理モジュール１６０と、オブジェクトコード生成モジュール１６４とを含む。
【００７８】
入力モジュール１５０は、ソースプログラム１０の入力を受け付ける。ユーザは、プログラミング言語を用いて、マイクロコンピュータ上で実現する処理を記述し、ファイルに格納して、プログラミング言語処理系であるプログラミング言語処理装置１００に入力する。ユーザが記述した処理の内容がソースプログラム１０であり、ソースプログラム１０を格納したファイルをソースプログラムファイルと称することもある。本実施の形態に従うプログラミング言語処理系を実現するための処理プログラム１１４と区別するため、ソースプログラム１０を「ユーザプログラム」と称することもある。
【００７９】
構文解析モジュール１５２は、入力モジュール１５０が受け付けたソースプログラム１０に対して構文解析を実行する。すなわち、構文解析モジュール１５２は、ソースプログラム１０を、プログラミング言語処理系での処理に適した内部表現に変換する。
【００８０】
配置判断情報出力モジュール１５４は、ソースプログラム１０から、ソースプログラム１０内で用いられる各変数を複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集し、配置判断情報２０として出力する。より具体的には、配置判断情報出力モジュール１５４は、構文解析モジュール１５２による構文解析の結果（内部表現）を解析して、ソースプログラム１０に含まれる変数の情報を収集する。
【００８１】
配置判断情報２０は、ソースプログラム１０に含まれる各変数を特定メモリ領域に配置すべきか否かを判断するのに必要な情報を、変数ごとにまとめたものである。配置判断情報出力モジュール１５４は、ソースプログラム１０内で用いられる集成体変数について、当該集成体変数の要素別に情報を収集する。すなわち、集成体変数については、内包される要素ごとに情報が収集される。
【００８２】
配置判断情報２０に含まれる情報としては、以下のようなものが挙げられる。
（１）参照回数
参照回数は、プログラムの実行に際して各変数が参照される総回数を意味する。参照回数が多い変数を特定メモリ領域に配置することで、メモリ参照に要する時間を短縮できるので、プログラムの実行速度を向上できる。また、特定メモリ領域を参照するための命令長が小さい専用命令が容易される場合には、参照回数が多い変数を特定メモリ領域に配置することで、当該専用命令の回数が増加し、ユーザプログラムサイズの削減効果を高めることができる。
（２）データサイズ
データサイズは、各変数が示すデータの大きさを意味する。データサイズの小さい変数を特定メモリ領域に配置することで、特定メモリ領域に配置できる変数の個数を増加させることができるため、より効率的に特定メモリ領域を利用できる。
（３）参照される区間
参照される区間は、各変数がソースプログラムのいずれの区間で参照されるのかを意味する。同じ参照回数の変数同士でも、短期間に集中して参照されるものを特定メモリ領域に配置する方が、特定メモリ領域の占有期間が少なくて済むため、より効率的に特定メモリ領域を利用できる。参照される区間は、例えば、「ソースプログラムのＸ行からＹ行まで参照されている」というように表すことができる。
（４）ループの位置する側（ループ内またはループ外）
ループの位置する側は、各変数がソースプログラムに記述された繰り返し実行されるループ命令において参照されている（ループ内）か、あるいは、当該ループ命令とは異なる命令で参照されている（ループ外）かを意味する。すなわち、各変数がループ命令において参照されているか否かを意味する。一般的に、ループ命令は何度も繰り返し実行されるため、ループ内の命令はループ外の命令よりも多く実行されると考えられる。そのため、ループ内でより高い頻度で参照される変数を特定メモリ領域に配置することで、プログラム実行時には、通常メモリ領域ではなく、特定メモリ領域を参照する回数が増加するために、より高速なプログラム実行が期待できる。
【００８３】
以下に、配置判断情報２０の一例を示す。
【００８４】
【表１】
2017068343.tif 000003
【００８５】
なお、上述の配置判断情報２０に含まれる情報は一例であり、すべての情報を常に含む必要はなく、例えば、上述した種類のうち少なくとも一つを含めることでも十分である。対象のマイクロコンピュータのアーキテクチャ、または、プログラミング言語の言語体系などに応じて、必要な情報が適宜選択される。
【００８６】
配置判断情報出力モジュール１５４は、生成した配置判断情報２０をスカラ化処理モジュール１６０へ内部的に渡すこともできるが、ファイルに書き出して、プログラミング言語処理系の外部に出力することもできる。
【００８７】
図１３は、配置判断情報２０をファイルに書き出した配置判断情報ファイルの一例を示す図である。図１３に示す配置判断情報ファイルにおいては、配置判断情報２０がＣＳＶ（Comma Separated Values）形式で表現されているが、これに限らず、必要な情報を不足なく表現できる形式でどのようなデータ形式またはファイル形式であってもよい。
【００８８】
別名解析モジュール１５６は、集成体変数のうちスカラ化できない集成体変数を特定する。ソースプログラム１０に含まれる変数に対して、そのシンボル名以外での参照手段がある場合には、それを「別名」と称す。例えば、ある変数ｖの配置アドレスをポインタ変数ｐに格納した場合には、ポインタ変数ｐに格納されたアドレスを参照することで変数ｖを参照できる。このようなポインタ変数ｐが示すアドレスを参照する処理は、「参照はがし」または「参照外し」と称される。この場合には、ポインタ変数ｐを用いて変数ｖを参照できるので、このポインタ変数ｐは変数ｖの別名となる。
【００８９】
集成体変数、または、その要素に別名が存在する場合、要素の配置および並びが制約されるため、スカラ化を行うことができない。すなわち、集成体変数をスカラ化すると、別名による変数の参照ができなくなる。別名解析モジュール１５６は、スカラ化の対象にできない集成体変数、または、その要素の情報を解析し、その結果（別名解析結果）を出力する。
【００９０】
このように、別名解析モジュール１５６は、ソースプログラム１０内で用いられる集成体変数のうち、内包するいずれかの要素が当該集成体変数の変数シンボル名を指定する方法とは異なる方法で指定されている集成体変数を特定する。
【００９１】
スカラ化処理モジュール１６０は、配置判断情報２０および別名解析結果に基づいて、ソースプログラムに相当する内部表現に含まれる集成体変数の一部または全部をスカラ化し、そのスカラ化後の内部表現をオブジェクトコード生成モジュール１６４へ出力する。スカラ化処理モジュール１６０は、スカラ化した集成体変数の情報を配置判断情報２０に反映する。
【００９２】
より具体的には、スカラ化処理モジュール１６０は、配置判断情報２０に基づいて、集成体変数以外の各変数（スカラ変数）および集成体変数の各要素について、複数のメモリ領域のうち特定メモリ領域に配置すべき度合い、または、複数のメモリ領域のうち特定メモリ領域以外に配置すべき度合いを算出する。本実施の形態においては、前者、すなわち複数のメモリ領域のうち特定メモリ領域に配置すべき度合いを、特定メモリ領域への配置優先度として算出する。配置優先度は、ソースプログラム１０に含まれる変数のうち、いずれの変数を特定メモリ領域に配置すべきであるかを示す指標である。
【００９３】
但し、複数のメモリ領域のうち特定メモリ領域以外に配置すべき度合いを算出するようにしてもよい。この場合には、算出される度合いが小さいほど、特定メモリ領域へ配置される優先度が高いことになる。
【００９４】
配置優先度は、配置判断情報２０に含まれる情報に基づいて算出される。配置判断情報２０には複数種類の情報が含まれ得るが、特定メモリ領域に配置する効果が大きい変数ほど配置優先度が高く算出されるように、算出に用いる情報の種類、各情報に与える重み、算出式などが適宜決定される。
【００９５】
例えば、配置優先度として、各変数について、参照回数をデータサイズで割った値を用いてもよい。このような配置優先度を用いることで、参照回数が多い変数ほど配置優先度が高く算出されるとともに、データサイズの大きな変数ほど配置優先度が低く算出される。すなわち、参照回数が多い変数ほど特定メモリ領域に優先的に配置されるようになり、また、より多くの種類の変数を配置するために、データサイズの大きな変数ほど特定メモリ領域に配置されにくくなる。
【００９６】
ループ中の参照を複数回とみなすことで、プログラムの実行性能を加味した配置優先度を算出することもできる。
【００９７】
集成体変数については、別名解析モジュール１５６による別名解析結果から、スカラ化可能であり、かつ、スカラ化することに充分なメリットがあると判断された場合に、要素ごとに特定メモリ領域への配置が判断される。
【００９８】
配置優先度の算出後、スカラ化処理モジュール１６０は、配置優先度の高い変数から順に、特定メモリ領域を利用できる順番で仮配置してゆく。配置優先度の降順に従って、対応する変数を特定メモリ領域に仮配置してもよいし、逆に、配置優先度の昇順に従って、対応する変数を通常メモリ領域に仮配置してもよい。スカラ化処理モジュール１６０は、このような仮配置を、特定メモリ領域に配置可能な変数がなくなるか、あるいは、特定メモリ領域に空きがなくなるまで繰り返す。このような配置優先度に基づく変数の仮配置によって、特定メモリ領域を配置優先度の高い変数で満たすことができる。
【００９９】
以上のように、スカラ化処理モジュール１６０は、配置判断情報２０に含まれる複数種類の情報（各変数が参照される総回数、各変数が示すデータの大きさ、各変数が参照されるソースプログラムの区間、各変数がループ命令において参照されているか否か）のうち少なくとも１つに基づいて、集成体変数以外の各変数および集成体変数の各要素のうち、特定メモリ領域に配置すべきものを決定する。
【０１００】
変数の仮配置処理に続いて、スカラ化処理モジュール１６０は、仮配置した変数がすべて特定メモリ領域に配置されると仮定して、特定メモリ領域に仮配置された変数のうち集成体変数をスカラ化する。すなわち、スカラ化処理モジュール１６０は、算出された配置優先度に基づいて、いずれかの集成体変数の要素を特定メモリ領域に配置すべきと決定されると、ソースプログラム１０内の当該集成体変数をスカラ化する。
【０１０１】
スカラ化処理は、集成体変数を、それに内包される個々の要素ごとに独立したスカラ変数へと分解する処理である。図１４は、実施の形態１に従うプログラミング言語処理装置１００でのスカラ化の一例を説明するための図である。
【０１０２】
図１４（Ａ）には、図３に示すソースプログラム９５１を示し、図１４（Ｂ）には、図３に示すソースプログラム９５１をスカラ化した結果を示す。図１４（Ａ）と図１４（Ｂ）とを比較すると、「ｓｔｒｕｃｔ  ｛ｉｎｔ  ａ，ｂ，ｃ［２００］；｝ｓ；」という定義（４行目）が、「ｉｎｔ  ｓ＿ａ，ｓ＿ｂ，ｓ＿ｃ０，...，ｓ＿ｃ１９９；」という定義（４行目）に変換されていることがわかる。
【０１０３】
スカラ化処理モジュール１６０は、特定メモリ領域に配置すべきと判断された変数を含む集成体変数をスカラ化する。このようなスカラ化によって、集成体変数に内包される特定の要素を特定メモリ領域に配置することができる。
【０１０４】
但し、スカラ化処理モジュール１６０は、別名解析モジュール１５６によって、スカラ化できないと判断された集成体変数は、スカラ化しない。すなわち、スカラ化処理モジュール１６０は、内包する要素が異なる方法で指定されている集成体変数をスカラ化の対象から除外する。
【０１０５】
最終的に、スカラ化処理モジュール１６０は、集成体変数をスカラ化することで生成されるスカラ変数の情報を配置判断情報２０に追加するとともに、スカラ化前の集成体変数の情報を配置判断情報２０から削除する。併せて、スカラ化処理モジュール１６０は、仮配置したすべての変数について、配置先が決定済であることを配置判断情報２０に記録する。
【０１０６】
なお、各変数の配置先に関する記述は、上述の図４に記載の変数／関数情報ファイル９５５に類似した記載を採用することができる。例えば、仮配置した変数のうち、最終的に特定メモリ領域に配置すべきとは判断されなかった変数については、コメントアウトするようにしてもよい。但し、スカラ化した集成体変数の配置先を外部ファイルなどとして出力する必要はなく、内部情報として保持しておき、関連する処理で参照するようにしてもよい。内部情報として保持しておくことで、コンパイル処理の複雑化を回避できる。
【０１０７】
オブジェクトコード生成モジュール１６４は、集成体変数がスカラ化された状態でオブジェクトコード３０を生成する。より具体的には、オブジェクトコード生成モジュール１６４は、スカラ化処理モジュール１６０によりスカラ化後の内部表現と、配置判断情報２０とに基づいて、オブジェクトコード３０を生成する。生成されたオブジェクトコード３０は、オブジェクトコードファイルとして出力される。より具体的には、オブジェクトコード生成モジュール１６４は、配置判断情報２０に基づいて、特定メモリ領域に配置すべき変数を特定し、その特定に応じてオブジェクトコード３０を生成する。
【０１０８】
以上のような各モジュールの連携によって、特定メモリ領域を活用したオブジェクトコード３０の生成を実現できる。
【０１０９】
（ｃ４：処理手順）
次に、図１２に示すプログラミング言語処理装置１００での処理手順について説明する。図１５は、実施の形態１に従うプログラミング言語処理装置１００での処理手順を示すフローチャートである。図１５に示す各ステップは、典型的には、プロセッサ１０２が処理プログラム１１４（いずれも図８参照）を実行することで実現される。
【０１１０】
図１５を参照して、入力モジュール１５０として機能するプロセッサ１０２は、ソースプログラム１０を読み込む（ステップＳ１００）。続いて、構文解析モジュール１５２として機能するプロセッサ１０２は、読み込んだソースプログラム１０に対して構文解析を実行して内部表現に変換する（ステップＳ１０２）。配置判断情報出力モジュール１５４として機能するプロセッサ１０２は、ソースプログラム１０を変換した内部表現を解析して、ソースプログラム１０に含まれる変数の情報を収集し、収集した情報を配置判断情報２０として出力する（ステップＳ１０４）。すなわち、プロセッサ１０２は、ソースプログラム１０から、ソースプログラム１０内で用いられる各変数を複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集し、配置判断情報２０として出力する。このとき、ソースプログラム１０内で用いられる集成体変数について、当該集成体変数の要素別に情報が収集される。
【０１１１】
また、別名解析モジュール１５６として機能するプロセッサ１０２は、ソースプログラム１０を変換した内部表現を解析して、用いられている集成体変数のうちスカラ化できない集成体変数を特定する（ステップＳ１０６）。すなわち、プロセッサ１０２は、ソースプログラム１０内で用いられる集成体変数のうち、内包するいずれかの要素が当該集成体変数の変数シンボル名を指定する方法とは異なる方法で指定されるかもしれない集成体変数を特定する。なお、ステップＳ１０６の処理は、ステップＳ１０４の処理と並行して実行されてもよいし、ステップＳ１０４の実行前に実行されてもよい。
【０１１２】
その後、スカラ化処理モジュール１６０として機能するプロセッサ１０２は、配置判断情報２０に基づいて、各変数について、特定メモリ領域への配置優先度を算出する（ステップＳ１０８）。すなわち、配置判断情報２０に基づいて、集成体変数以外の各変数および集成体変数の各要素について、複数のメモリ領域のうち特定メモリ領域に配置すべき度合いが算出される。
【０１１３】
続いて、スカラ化処理モジュール１６０として機能するプロセッサ１０２は、算出した配置優先度に基づいて、各変数（集成体変数に内包されるデータについては、要素ごと）を特定メモリ領域および通常メモリ領域のいずれに配置すべきかを決定し（ステップＳ１１０）、続いて、特定メモリ領域に配置すべきと判断された変数のうち、集成体変数に内包される要素であるものが存在するか否かを判断する（ステップＳ１１２）。集成体変数に内包される要素であるものが存在する場合（ステップＳ１１２においてＹＥＳの場合）には、スカラ化処理モジュール１６０として機能するプロセッサ１０２は、該当する変数が属する集成体変数をスカラ化する（ステップＳ１１４）。但し、ステップＳ１０６において、スカラ化できないと特定された集成体変数については、スカラ化の対象から除外される。
【０１１４】
上述のステップＳ１１０〜Ｓ１１４において、スカラ化処理モジュール１６０として機能するプロセッサ１０２は、算出された配置優先度に基づいて、いずれかの集成体変数の要素を特定メモリ領域に配置すべきと決定されると、ソースプログラム１０内の当該集成体変数をスカラ化する。
【０１１５】
スカラ化処理モジュール１６０として機能するプロセッサ１０２は、集成体変数をスカラ化することで生成されるスカラ変数の情報を配置判断情報２０に追加するとともに、スカラ化前の集成体変数の情報を配置判断情報２０から削除する（ステップＳ１１６）。
【０１１６】
集成体変数に内包される要素であるものが存在しない場合（ステップＳ１１２においてＮＯの場合）には、ステップＳ１１４およびＳ１１６の処理はスキップされる。
【０１１７】
スカラ化処理モジュール１６０として機能するプロセッサ１０２は、各変数の最終的な配置先を配置判断情報２０に記録する（ステップＳ１１８）。オブジェクトコード生成モジュール１６４として機能するプロセッサ１０２は、集成体変数がスカラ化された状態でオブジェクトコードを生成する。より具体的には、オブジェクトコード生成モジュール１６４として機能するプロセッサ１０２は、内部表現（ステップＳ１１４においてスカラ化処理が実行されている場合には、スカラ化処理後の内部表現）と、配置判断情報２０とに基づいて、オブジェクトコード３０を生成する（ステップＳ１２０）。
【０１１８】
以上の処理により、ソースプログラム１０から、変数の配置先を最適化した上でオブジェクトコード３０が生成される。
【０１１９】
（ｃ５：利点）
本実施の形態に従うプログラミング言語処理系においては、集成体変数に含まれる各要素についての配置判断情報を生成または更新した上で、特定メモリ領域へ配置すべき変数を決定する。その決定された変数が集成体変数の要素である場合に限って、当該集成体変数をスカラ化する。すなわち、ソースプログラム内で用いられる集成体変数のすべてを先にスカラ化するのではなく、配置判断情報を生成または更新した上で、スカラ化の対象となる集成体変数を決定する。
【０１２０】
一方で、すべての集成体変数をスカラ化してしまうと、別の面から弊害が生じ得る。例えば、集成体変数に内包される要素に由来するスカラ変数の一部は、特定メモリ領域に配置されるが、残りのスカラ変数は、他の変数と同様に、レジスタ割り付けの対象になる。一般的に、レジスタの数は特定メモリ領域以上に限られているため、レジスタが不足する可能性もある。また、集成体変数に内包される要素に由来するスカラ変数には、ほとんど参照されないものもあり、このようなスカラ変数の存在がレジスタリソースの圧迫にもつながり得る。
【０１２１】
これに対して、上述したような選択的なスカラ化を行うことで、スカラ化の弊害を抑制しつつ、プログラムの実行速度を向上させることができる。
【０１２２】
［Ｄ．実施の形態２］
上述の実施の形態１においては、ソースプログラム１０に対してスカラ化処理を行ってオブジェクトコードを生成する構成を例示したが、実施の形態２においては、一旦作成されたオブジェクトコードからスカラ化処理を最適化する構成について例示する。
【０１２３】
実施の形態２に従うプログラミング言語処理装置１００Ａは、以下に説明するような機能構成を除いて、実施の形態１に従うプログラミング言語処理装置１００と同様であるので、詳細な説明は繰り返さない。
【０１２４】
（ｄ１：プログラミング言語処理装置の機能構成）
図１６は、実施の形態２に従うプログラミング言語処理装置１００Ａの機能構成を示す模式図である。図１６を参照して、プログラミング言語処理装置１００Ａは、プログラミング言語を用いて記述されたソースプログラム１０が入力されると、構文解析および後述するような処理を経て、オブジェクトコード３０を出力する。より具体的には、プログラミング言語処理装置１００Ａは、その機能として、入力モジュール１５０と、構文解析モジュール１５２Ａと、配置判断情報出力モジュール１５４Ａと、別名解析モジュール１５６と、スカラ化処理モジュール１６０Ａと、オブジェクトコード生成モジュール１６４とを含む。図１２に示すモジュールと同一の参照符号が付与されているモジュールは、実施の形態１に従うプログラミング言語処理装置１００における対応するモジュールと機能が実質的に同一であるので、詳細な説明は繰り返さない。
【０１２５】
実施の形態２に従うプログラミング言語処理装置１００Ａにおいて、配置判断情報出力モジュール１５４Ａは、プログラミング言語処理系から独立して配置される。すなわち、実施の形態１とは異なり、実施の形態２においては、配置判断情報出力モジュール１５４Ａは、同一のソースプログラム１０から予め作成されたオブジェクトコード３０Ａが入力される。
【０１２６】
配置判断情報出力モジュール１５４Ａは、ソースプログラム１０から生成されたオブジェクトコード３０Ａの入力を受け付ける。そして、配置判断情報出力モジュール１５４Ａは、オブジェクトコード３０Ａから、ソースプログラム１０内で用いられる各変数を複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集し、配置判断情報２０Ａとして出力する。より具体的には、配置判断情報出力モジュール１５４Ａは、オブジェクトコード３０Ａを参照して、オブジェクトコード上で実際に参照されている変数の情報を収集する。
【０１２７】
オブジェクトコード３０Ａは、典型的には、実施の形態１に従うプログラミング言語処理装置１００により生成されるが、これに限らず、通常のコンパイラを用いて作成してもよい。
【０１２８】
スカラ化処理モジュール１６０Ａは、配置判断情報出力モジュール１５４Ａにより更新された配置判断情報２０Ａに基づいて、一部の集成体変数を優先的にスカラ化する。すなわち、スカラ化処理モジュール１６０Ａは、配置判断情報２０Ａから算出された配置優先度に基づいて、いずれかの集成体変数の要素を特定メモリ領域に配置すべきと決定されると、ソースプログラム１０内の当該集成体変数をスカラ化する。
【０１２９】
オブジェクトコード生成モジュール１６４は、集成体変数がスカラ化された状態でオブジェクトコード３０を生成する。このとき、オブジェクトコード生成モジュール１６４は、配置判断情報２０Ａに基づいて特定メモリ領域に配置すべき変数を決定し、それに応じたオブジェクトコード３０を生成する。
【０１３０】
このように、実施の形態２と実施の形態１との相違点の一つは、配置判断情報２０Ａが既存のオブジェクトコード３０Ａから生成される点である。オブジェクトコード３０Ａに基づいて配置判断情報２０Ａを生成することにより、スカラ化処理モジュール１６０Ａでのスカラ化処理後において不要と判断される変数を、特定メモリ領域への配置対象から除外することができる。すなわち、スカラ化処理モジュール１６０Ａによるスカラ化処理後以降の処理において、特定メモリ領域に配置する必要はないと判断される場合もある。上述の実施の形態１においては、一旦オブジェクトコード３０が生成されると、再度のスカラ化処理は実行されないので、特定メモリ領域を効率的に利用できない場合もある。これに対して、実施の形態２に従うプログラミング言語処理装置１００Ａでは、スカラ化処理後の結果を反映して、スカラ化処理の対象とする変数を見直すことができるので、より効率的に特定メモリ領域を利用できる。
【０１３１】
実施の形態２と実施の形態１との相違点の別の一つは、構文解析モジュール１５２Ａが集成体変数構造復元モジュール１６６を有している点である。集成体変数構造復元モジュール１６６は、オブジェクトコードに含まれる集成体変数を内部表現としてフィードバックする。例えば、オブジェクトコードにおいて、集成体変数の要素は、「変数シンボル（先頭アドレス）＋オフセット」の形で格納される。これを内部表現としてフィードバックするためには、内部表現で利用可能な形に集成体変数の構造を復元する必要がある。
【０１３２】
集成体変数構造復元モジュール１６６は、ソースプログラム１０と配置判断情報２０Ａとを比較することで、集成体変数の構造を復元する。そのため、配置判断情報２０Ａが最終的に配置判断情報ファイルとして出力される段階ではなく、その前段階で復元される。このような処理の相違に起因して、実施の形態２においては、実施の形態１において用いられる配置判断情報２０とは異なる形式の配置判断情報２０Ａが用いられる。
【０１３３】
図１７は、配置判断情報２０Ａをファイルに書き出した配置判断情報ファイルの一例を示す図である。図１７に示す配置判断情報ファイルでは、集成体変数の要素を特定するために、要素の名前ではなく、「集成体変数シンボル名＋オフセット値」の表記が採用されている。例えば、要素ａ（５行目）は、変数ｓの最初の要素なのでオフセットは０となるから、「ｓ＋０」と表記される。同様に、要素ｂ（６行目）は、変数ｓの２番目の要素であり、要素ａ（２バイト）の後ろに続くため、「ｓ＋２」と表記される。
【０１３４】
さらに要素ｓ．ｃは配列であるため、要素ｓ．ｃ自身のオフセット４に加えて、配列内の各要素のオフセットが後置されて、「ｓ＋４」，「ｓ＋６」，…と表記される。
【０１３５】
このように、オブジェクトコード３０Ａから出力される配置判断情報２０Ａにおいては、ソースプログラム１０内で用いられる集成体変数の各要素は、集成体変数のシンボル名と１または複数のオフセット値との組み合わせを用いて特定される。
【０１３６】
（ｄ２：プログラミング言語処理装置の処理手順）
次に、図１６に示すプログラミング言語処理装置１００Ａでの処理手順について説明する。図１８は、実施の形態２に従うプログラミング言語処理装置１００Ａでの処理手順を示すフローチャートである。図１８に示す各ステップは、典型的には、プロセッサ１０２が処理プログラム１１４（いずれも図８参照）を実行することで実現される。なお、図１５において説明したのと同様の処理についての詳細な説明は繰り返さない。
【０１３７】
図１８を参照して、入力モジュール１５０として機能するプロセッサ１０２は、ソースプログラム１０を読み込む（ステップＳ２００）。併せて、配置判断情報出力モジュール１５４Ａとして機能するプロセッサ１０２は、ソースプログラム１０から予め作成されたオブジェクトコード３０Ａを読み込み、読み込んだオブジェクトコード３０Ａを解析して、オブジェクトコード３０Ａに含まれる変数の情報を収集し、収集した情報を配置判断情報２０Ａとして出力する（ステップＳ２０２）。なお、オブジェクトコード３０Ａは、上述の実施の形態１などに記載の処理などに従って生成されてもよい。テップＳ２０２の処理は、ステップＳ２００の処理と並行して実行されてもよいし、ステップＳ２００の実行前に実行されてもよい。
【０１３８】
配置判断情報出力モジュール１５４Ａとして機能するプロセッサ１０２は、オブジェクトコード３０Ａから、ソースプログラム１０内で用いられる各変数を複数のメモリ領域のうちいずれのメモリ領域に配置すべきかを判断するための情報を収集し、配置判断情報２０Ａとして出力する。このとき、ソースプログラム１０内で用いられる集成体変数について、当該集成体変数の要素別に情報が収集される。
【０１３９】
構文解析モジュール１５２として機能するプロセッサ１０２は、読み込んだソースプログラム１０に対して構文解析を実行して内部表現に変換する（ステップＳ２０４）。別名解析モジュール１５６として機能するプロセッサ１０２は、ソースプログラム１０を変換した内部表現を解析して、用いられている集成体変数のうちスカラ化できない集成体変数を特定する（ステップＳ２０６）。
【０１４０】
また、集成体変数構造復元モジュール１６６として機能するプロセッサ１０２は、ステップＳ２００において読み込まれたソースプログラム１０と、ステップＳ２０２において出力された配置判断情報２０Ａとを比較することで、配置判断情報２０Ａに含まれる集成体変数の構造を復元する（ステップＳ２０８）。ステップＳ２０８の処理は、ステップＳ２０４およびＳ２０６の処理と並行して実行されてもよいし、ステップＳ２０４およびＳ２０６の実行前に実行されてもよい。
【０１４１】
スカラ化処理モジュール１６０Ａとして機能するプロセッサ１０２は、集成体変数の構造を復元された配置判断情報２０Ａに基づいて、各変数について、特定メモリ領域への配置優先度を算出する（ステップＳ２１０）。
【０１４２】
続いて、スカラ化処理モジュール１６０Ａとして機能するプロセッサ１０２は、算出した配置優先度に基づいて、各変数（集成体変数に内包されるデータについては、要素ごと）を特定メモリ領域および通常メモリ領域のいずれに配置すべきかを決定する（ステップＳ２１２）。特定メモリ領域に配置すべきと判断された変数のうち、集成体変数に内包される要素であるものが存在するか否かを判断する（ステップＳ２１４）。集成体変数に内包される要素であるものが存在する場合（ステップＳ２１４においてＹＥＳの場合）には、スカラ化処理モジュール１６０Ａとして機能するプロセッサ１０２は、該当する変数が属する集成体変数をスカラ化する（ステップＳ２１６）。但し、ステップＳ２０６において、スカラ化できないと特定された集成体変数については、スカラ化の対象から除外される。
【０１４３】
集成体変数に内包される要素であるものが存在しない場合（ステップＳ２１４においてＮＯの場合）には、ステップＳ２１６の処理はスキップされる。
【０１４４】
最終的に、オブジェクトコード生成モジュール１６４として機能するプロセッサ１０２は、集成体変数がスカラ化された状態でオブジェクトコードを生成する。より具体的には、オブジェクトコード生成モジュール１６４として機能するプロセッサ１０２は、内部表現（ステップＳ２１６においてスカラ化処理が実行されている場合には、スカラ化処理後の内部表現）と、配置判断情報２０Ａとに基づいて、オブジェクトコード３０を生成する（ステップＳ２１８）。
【０１４５】
以上の処理により、ソースプログラム１０から、オブジェクトコード３０Ａを参照して、変数の配置先を最適化した上でオブジェクトコード３０が生成される。
【０１４６】
（ｄ３：利点）
実施の形態２においては、オブジェクトコード３０Ａから変数の情報が収集されて配置判断情報として出力される。オブジェクトコード３０Ａを用いることで、コンパイルの途中結果ではなく、最終結果を配置判断情報の収集源とすることができ、無駄な情報を排除できる。そのため、より精細な配置判断情報に基づいて、変数の配置をより効率的に行うことができる。
【０１４７】
また、オブジェクトコード３０Ａでの変数の指定方法に応じて配置判断情報においても、集成体変数の各要素は、集成体変数のシンボル名と１または複数のオフセット値との組み合わせを用いて特定されるが、このような配置判断情報であっても、集成体変数の構造を復元することで、内部表現にフィードバックできる。そのため、配置判断情報ファイルが外部アプリケーションにより加工された場合でも、その対応を容易に実現できる。
【０１４８】
［Ｅ．実施の形態３］
上述の実施の形態２においては、一旦作成されたオブジェクトコードからスカラ化処理を最適化する構成を例示したが、実施の形態３においては、オブジェクトから生成される実行可能ファイルを実際に実行させたときの情報をフィードバックする構成について例示する。
【０１４９】
実施の形態３に従うプログラミング言語処理装置１００Ｂは、以下に説明するような機能構成を除いて、実施の形態１に従うプログラミング言語処理装置１００と同様であるので、詳細な説明は繰り返さない。
【０１５０】
（ｅ１：プログラミング言語処理装置の機能構成）
図１９は、実施の形態３に従うプログラミング言語処理装置１００Ｂの機能構成を示す模式図である。図１９を参照して、プログラミング言語処理装置１００Ｂは、プログラミング言語を用いて記述されたソースプログラム１０が入力されると、構文解析および後述するような処理を経て、オブジェクトコード３０および実行可能ファイル４０を出力する。
【０１５１】
プログラミング言語処理装置１００Ｂは、図１６に示すプログラミング言語処理装置１００Ａの機能構成に加えて、実行可能ファイル生成モジュール１７０および実行時情報収集モジュール１７２をさらに含む。
【０１５２】
実行可能ファイル生成モジュール１７０は、オブジェクトコード３０を入力として実行可能ファイル４０を生成する。典型的には、実行可能ファイル生成モジュール１７０は、リンカを用いて実現することができる。
【０１５３】
実行時情報収集モジュール１７２は、実行可能ファイル４０を実行した結果を収集および解析し、実行時情報として出力する。より具体的には、実行時情報収集モジュール１７２は、プロファイラを用いて実現することができ、実行頻度および入力データの偏りといった、プログラムの実行時にしか取得できない情報を、特定メモリ領域の利用状況に反映させるための情報を出力する。実行時情報は、配置判断情報出力モジュール１５４Ｂへ出力される。
【０１５４】
配置判断情報出力モジュール１５４Ｂは、入力された実行時情報に基づいて、配置判断情報２０Ｂを更新する。スカラ化処理モジュール１６０Ａは、配置判断情報出力モジュール１５４Ｂにより更新された配置判断情報２０Ｂに基づいて、一部の集成体変数を優先的にスカラ化する。オブジェクトコード生成モジュール１６４は、集成体変数がスカラ化された状態でオブジェクトコード３０を生成する。このとき、オブジェクトコード生成モジュール１６４は、配置判断情報２０Ｂに基づいて特定メモリ領域に配置すべき変数を決定し、それに応じたオブジェクトコード３０を生成する。
【０１５５】
このように、実行時情報収集モジュール１７２および配置判断情報出力モジュール１５４Ｂを用いることで、ユーザプログラム実行時の情報を配置判断情報２０Ｂに反映することができる。
【０１５６】
（ｅ２：プログラミング言語処理装置の処理手順）
次に、図１９に示すプログラミング言語処理装置１００Ｂでの処理手順について説明する。図２０は、実施の形態３に従うプログラミング言語処理装置１００Ｂでの処理手順を示すフローチャートである。図２０に示す各ステップは、典型的には、プロセッサ１０２が処理プログラム１１４（いずれも図８参照）を実行することで実現される。なお、図１５において説明したのと同様の処理についての詳細な説明は繰り返さない。
【０１５７】
図２０を参照して、図１８のステップＳ２００〜２１８と同様の処理が実行される。続いて、実行可能ファイル生成モジュール１７０として機能するプロセッサ１０２は、オブジェクトコード３０を入力として実行可能ファイル４０を生成する（ステップＳ２２０）。
【０１５８】
その後、プログラミング言語処理装置１００Ｂは、マイクロコンピュータ２００に実行可能ファイル４０を転送するとともに、実行可能ファイル４０の実行をマイクロコンピュータ２００に指示する（ステップＳ２２２）。実行時情報収集モジュール１７２として機能するプロセッサ１０２は、マイクロコンピュータ２００にて実行可能ファイル４０が実行された結果を収集および解析し、実行時情報として出力する（ステップＳ２２４）。なお、実際のマイクロコンピュータ２００にて実行させるのに代えて、マイクロコンピュータ２００の動作を模擬するシミュレータを用いて、実行可能ファイル４０が実行された結果を収集および解析してもよい。
【０１５９】
配置判断情報出力モジュール１５４Ｂとして機能するプロセッサ１０２は、ステップＳ２２４において出力された実行時情報に基づいて、配置判断情報２０Ｂを更新する（ステップＳ２２６）。すなわち、ステップＳ２２２〜Ｓ２２４において、プロセッサ１０２は、実行可能ファイル４０がマイクロコンピュータ２００で実行されたときの情報に基づいて、配置判断情報２０Ｂの内容を更新する。
【０１６０】
続いて、入力モジュール１５０として機能するプロセッサ１０２は、ソースプログラム１０を読み込む（ステップＳ２２８）。構文解析モジュール１５２として機能するプロセッサ１０２は、読み込んだソースプログラム１０に対して構文解析を実行して内部表現に変換する（ステップＳ２３０）。別名解析モジュール１５６として機能するプロセッサ１０２は、ソースプログラム１０を変換した内部表現を解析して、用いられている集成体変数のうちスカラ化できない集成体変数を特定する（ステップＳ２３２）。
【０１６１】
また、集成体変数構造復元モジュール１６６として機能するプロセッサ１０２は、ステップＳ２２８において読み込まれたソースプログラム１０と、ステップＳ２２６において更新された配置判断情報２０Ｂとを比較することで、更新後の配置判断情報２０Ｂに含まれる集成体変数の構造を復元する（ステップＳ２３４）。
【０１６２】
スカラ化処理モジュール１６０Ａとして機能するプロセッサ１０２は、集成体変数の構造を復元された配置判断情報２０Ｂに基づいて、各変数について、特定メモリ領域への配置優先度を算出する（ステップＳ２３６）。続いて、スカラ化処理モジュール１６０Ａとして機能するプロセッサ１０２は、算出した配置優先度に基づいて、各変数（集成体変数に内包されるデータについては、要素ごと）を特定メモリ領域および通常メモリ領域のいずれに配置すべきかを決定する（ステップＳ２３８）。特定メモリ領域に配置すべきと判断された変数のうち、集成体変数に内包される要素であるものが存在するか否かを判断する（ステップＳ２４０）。集成体変数に内包される要素であるものが存在する場合（ステップＳ２４０においてＹＥＳの場合）には、スカラ化処理モジュール１６０Ａとして機能するプロセッサ１０２は、該当する変数が属する集成体変数をスカラ化する（ステップＳ２４２）。但し、ステップＳ２３２において、スカラ化できないと特定された集成体変数については、スカラ化の対象から除外される。
【０１６３】
集成体変数に内包される要素であるものが存在しない場合（ステップＳ２４０においてＮＯの場合）には、ステップＳ２４２の処理はスキップされる。
【０１６４】
最終的に、オブジェクトコード生成モジュール１６４として機能するプロセッサ１０２は、集成体変数がスカラ化された状態でオブジェクトコードを生成する。より具体的には、オブジェクトコード生成モジュール１６４として機能するプロセッサ１０２は、内部表現（ステップＳ２４２においてスカラ化処理が実行されている場合には、スカラ化処理後の内部表現）と、配置判断情報２０Ｂとに基づいて、オブジェクトコード３０を生成する（ステップＳ２４４）。
【０１６５】
以上のように、実行可能ファイル４０がマイクロコンピュータ２００で実行されたときの情報に基づいて、集成体変数以外の各変数および集成体変数の各要素のうち、特定メモリ領域に配置すべきものが先に生成されたオブジェクトから更新される。このような処理により、ソースプログラム１０から、実行可能ファイル４０の実行結果を参照して、変数の配置先を最適化した上でオブジェクトコード３０を生成できる。
【０１６６】
（ｅ３：利点）
実施の形態３においては、マイクロコンピュータ２００での実行可能ファイル４０の実行結果（例えば、プロファイラなどの外部ツールによって取得されるプロファイリング結果）を反映して、各変数の配置先を最適化できる。そのため、実際のマイクロコンピュータ２００での実行状態を反映した、効率的な変数の配置を実現できる。
【０１６７】
［Ｆ．実施の形態４］
上述の実施の形態１〜３においてそれぞれ説明したように、配置判断情報は、ソースプログラムの内容、オブジェクトコードの内容、および、実行可能ファイルの実行結果に基づいて、作成または更新可能である。このような配置判断情報の作成または更新に係る処理を組み込んで統合開発環境として実装してもよい。このような統合開発環境をユーザへ提供することで、ユーザプログラムをより効率的に開発できる。以下、実施の形態４として、配置判断情報の処理を中心として、統合開発環境の一例を説明する。
【０１６８】
（ｆ１：機能構成）
図２１は、実施の形態４に従う統合開発環境１９０での処理および機能を説明する模式図である。図２１を参照して、実施の形態４に従う統合開発環境１９０は、本実施の形態に従うプログラミング言語処理系を含む、複数のメモリ領域を有するマイクロコンピュータ向けのプログラムの開発環境である。統合開発環境１９０は、典型的には、コンパイラ１９２と、リンカ１９４と、プロファイラ１９６とを含む。統合開発環境１９０は、さらに、ソースプログラムを作成するためのエディタおよびデバッガなどを含んでいてもよい。統合開発環境１９０は、処理プログラム１１４を含むアプリケーションプログラムが汎用コンピュータにインストールおよび実行されることで実現される。
【０１６９】
ユーザは、統合開発環境上でソースプログラム１０を作成し、これをソースプログラムファイルとして格納する。ユーザが統合開発環境上で指示を与えることで、コンパイラ１９２、リンカ１９４、およびプロファイラ１９６は、それぞれ以下のような処理を実行する。
【０１７０】
（１）ソースプログラム１０に基づく配置判断情報２０の作成および更新（ステージＳＴ１）
コンパイラ１９２は、ソースプログラム１０を解析して、ソースプログラム１０内で用いられる変数の情報を収集し、配置判断情報２０として出力する。コンパイラ１９２は、配置判断情報２０を参照して、一部の変数を特定メモリ領域に配置するようなオブジェクトコード３０を生成する。
【０１７１】
（２）オブジェクトコード３０に基づく配置判断情報２０の作成および更新（ステージＳＴ２）
リンカ１９４は、入力されたオブジェクトコード３０から実行可能ファイル４０を生成する。リンカ１９４は、実行可能ファイル４０の生成過程において、用いられる変数の情報を収集して配置判断情報２０に反映する。更新された配置判断情報２０は、コンパイラ１９２にフィードバックされて、一部の変数をより効率的に特定メモリ領域に配置するようなオブジェクトコード３０が再生成されてもよい。
【０１７２】
（３）実行可能ファイル４０の実行結果に基づく配置判断情報２０の作成および更新（ステージＳＴ３）
リンカ１９４により生成された実行可能ファイル４０は、マイクロコンピュータ２００のプログラムメモリに書き込まれて実行される。プロファイラ１９６は、実行可能ファイル４０の実行結果を収集し、実行時情報を配置判断情報２０に追加する。更新された配置判断情報２０は、コンパイラ１９２にフィードバックされて、一部の変数をより効率的に特定メモリ領域に配置するようなオブジェクトコード３０が再生成されてもよい。
【０１７３】
上述の説明においては、コンパイラ１９２、リンカ１９４、およびプロファイラ１９６がいずれも配置判断情報２０の作成または更新を行う構成例について説明したが、必ずしも、すべての機能を搭載しておく必要はなく、一部の機能のみを実装するようにしてもよい。
【０１７４】
図２１に示すステージＳＴ１〜ＳＴ３での処理は、それぞれ上述の実施の形態１〜３に従うプログラミング言語処理装置での処理手順と同様であるので、詳細な説明は繰り返さない。
【０１７５】
（ｆ２：利点）
上述したような実施の形態４に従う統合開発環境を提供することにより、マイクロコンピュータ２００が特定メモリ領域を有しているか否か、特定メモリ領域の容量はいくらか、どうすれば効率よく変数を配置できるか、などの問題に頭を悩ませることなくユーザプログラムを効率的に作成できる。
【０１７６】
［Ｇ．その他の実施の形態］
上述した本実施の形態に従うプログラミング言語処理系の説明においては、参照に要する時間が相対的に短いメモリ領域（特定メモリ領域）に配置すべき変数を決定する方法について説明したが、逆に、参照に要する時間が相対的に長いメモリ領域に配置すべき変数を決定するようにしてもよい。
【０１７７】
上述の実施の形態３においては、実施の形態２において説明したオブジェクトコードから取得した配置判断情報を用いた変数の配置先の最適化を併せて実行するように記載したが、実行可能ファイルの実行結果のみを反映するようにしてもよい。
【０１７８】
［Ｈ．まとめ］
本実施の形態に従うプログラミング言語処理系によれば、先行技術においては、特定メモリ領域に配置することのできなかった集成体変数などのデータを特定メモリ領域に配置することができるようになる。これにより、特定メモリ領域の利用効率が高まり、ユーザプログラムの実行動作の高速化、および、コードサイズの削減などが期待できる。
【０１７９】
以上、本発明者らによってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【符号の説明】
【０１８０】
１０，９５１  ソースプログラム、２０，２０Ａ，２０Ｂ  配置判断情報、３０，３０Ａ，９５３  オブジェクトコード、４０，９５６  実行可能ファイル、１００，１００Ａ，１００Ｂ  プログラミング言語処理装置、１０２  プロセッサ、１０４  主メモリ、１０６，９０４  入力部、１０８  表示部、１１０  補助記憶装置、１１２  ＯＳ、１１４  プログラミング言語処理プログラム（処理プログラム）、１２０  光学ドライブ、１２２  光学ディスク、１２４  ローカル通信インターフェイス、１２６  ネットワークインターフェイス、１２８，２３０，２５０  バス、１５０  入力モジュール、１５２，１５２Ａ  構文解析モジュール、１５４，１５４Ａ，１５４Ｂ  配置判断情報出力モジュール、１５６  別名解析モジュール、１６０，１６０Ａ  スカラ化処理モジュール、１６４  オブジェクトコード生成モジュール、１６６  集成体変数構造復元モジュール、１７０  実行可能ファイル生成モジュール、１７２  実行時情報収集モジュール、１９０  統合開発環境、１９２，９５２  コンパイラ、１９４，９５４  リンカ、１９６  プロファイラ、２００，２００Ａ，２００Ｂ  マイクロコンピュータ、２０４  命令メモリ、２０６  レジスタ、２０７  特殊領域、２１０  演算処理部、２２０  メモリ群、２２２  第１メモリ、２２４  第２メモリ、２２６，２５２  メモリ、２５４  バスコネクション、９０１  ソースファイル、９０２  言語処理手段、９０３  オブジェクトファイル、９０５  構文解析部、９０６  配置指定情報出力部、９０７  オブジェクトコード出力部、９０８  配置指定情報ファイル、９１２  配置指定情報ファイル入力部、９５５  関数情報ファイル。
【図１】
2017068343.tif 000004
【図２】
2017068343.tif 000005
【図６】
2017068343.tif 000006
【図７】
2017068343.tif 000007
【図８】
2017068343.tif 000008
【図９】
2017068343.tif 000009
【図１０】
2017068343.tif 000010
【図１１】
2017068343.tif 000011
【図１２】
2017068343.tif 000012
【図１５】
2017068343.tif 000013
【図１６】
2017068343.tif 000014
【図１８】
2017068343.tif 000015
【図１９】
2017068343.tif 000016
【図２０】
2017068343.tif 000017
【図２１】
2017068343.tif 000018
【図３】
2017068343.tif 000019
【図４】
2017068343.tif 000020
【図５】
2017068343.tif 000021
【図１３】
2017068343.tif 000022
【図１４】
2017068343.tif 000023
【図１７】
2017068343.tif 000024