(57)【特許請求の範囲】
【請求項１】
命令列をコンパイルし、ソフトウェアを構成する複数のオブジェクトをリンクしてアドレスを固定した組込みプログラムを作成するソフトウェア開発装置において、
組込みソフトウェアとして一体化された該組込みソフトウェアを細分化してモジュールを設定して、該モジュール間にまたがってシンボル参照する関係を抽出するモジュール間参照関係抽出部と、
上記モジュール間参照関係にある被参照モジュールにおいて、他モジュールからシンボル参照される受け入れ参照アドレスを定めたテーブルを定め、かつ該受け入れ参照アドレスと自モジュール内の上記シンボル参照先の実アドレスとを結びつけるベクタテーブル作成部と、
他モジュールからの被参照アドレスを上記ベクタテーブルの受け入れ参照アドレスに書換えるベクタテーブル・シンボル情報作成部、とを備え、
各モジュールの領域にアドレスを割当てる際に、共通の余裕領域を設けるようにしたことを特徴とする組込みソフトウェア開発装置。
【請求項２】
モジュール間参照関係抽出部は、レジスタへのロード命令か、サイズ情報を出力しているかでデータ参照であると判定し、それ以外であれば関数参照であると判定するようにしたことを特徴とする請求項１記載の組込みソフトウェア開発装置。
【請求項３】
ベクタテーブル作成部は、プログラムを記憶するメモリが複数種類ある場合は、あるモジュールに所定のメモリを割当てると、該モジュールのベクタテーブルの領域を該モジュールの実アドレスと同一のメモリ内に設定することを特徴とする請求項１記載の組込みソフトウェア開発装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は携帯電話などの組み込み型の小型情報処理機器の補助記憶装置、とくにフラッシュメモリ上へ配置するプログラムの開発装置および方法に関するものである。
【０００２】
【従来の技術】
携帯電話などの組み込み型の小型情報処理機器上へのソフトウェアの開発は、コンパイラやリンカを利用してオブジェクトコードを生成し、このオブジェクトコードを機器上のフラッシュＲＯＭにダウンロードする手法をとることを特徴としている。ソフトウェアの修正があった場合は、そのソースコードのみ再度コンパイルし、再び全体をリンクするという手法をとる。
しかし、バグの修正などでソースコードの修正を行うと、一部の関数が小さくなったり大きくなったりとメモリのアドレスがずれることも多い。
【０００３】
ここで、関数呼び出しなどジャンプで実現している場合は、オブジェクトコードのアドレス情報が変更されてしまう。アドレスを集めたテーブルから読み出す形にした場合はレジスタでアクセスするために前もって実行する命令コードが増えてしまうという欠点もある。また、通常のコンパイル、リンク手段では実現できないという問題もある。
【０００４】
そこで、自動的に様々条件を判断しながら、ソフトウェアの変更時に備えたコードを出力する装置を得る必要がある。
例えば特許文献１「リンク処理装置」、特許文献２「プログラムリンケージ方式」、特許文献３「プログラムのコンパイル・リンク方式」に開示された技術においては、ベクタエントリテーブルを導入し、自動生成するようにすることにより、一部を修正しても全体としてアドレスが変わる部分は一部のみに限定され、全体をリンクしなおす必要がないという技術が開示されている。しかし、ここで開示されている技術では、各ファイル内で宣言している外部参照宣言部によりベクタエントリテーブルを作成しているので、モジュール化を複数段にするなど巨大なプログラムを扱う場合にはベクタエントリテーブルが大きくなりすぎたり、後からモジュール構成を変更するということができないという欠点がある。
【０００５】
例えば、特許文献４「プログラム処理装置および記憶媒体」に開示された技術によれば、プログラムの各モジュールを最適配置するために未解決のシンボル情報の数を利用する技術が開示されている。しかしながら、ソフトウェアの更新時の移動などを考慮する場合、未解決シンボル即ち外部シンボルの数とはなんら関係ないのでソフトウェア更新時を考慮した解決策にはなってないという欠点がある。
また、特許文献５「再配置可能なアドインソフト管理システム」に開示されたアドインソフトのためにベクタテーブルなどを予め確保しておく技術においては、後から追加するソフトがあるわけではなく、修正するためのソフトウェアに領域が増加する場合にはその領域を有効には利用できるかもしれないが、想定していない関数が新たに追加された場合などには有効に利用できないという欠点がある。
【０００６】
また、非特許文献１「携帯電話機のバグをユーザの手元で修正へ」（Ｐ．２２，Ｐ．２３）によれば、ソフトウェア更新時の更新ファイルを小さくする方法が開示されており、この中にソフトウェアを複数ブロックに分割し、そのブロックごとに差分を取る方式が示されているが、具体的な方法は示されておらず、目的も通信断のときに引き続き処理する方式であることと、メモリを節約できることが提案されているにすぎず、プログラムの差分が小さくなるという問題を十分に解決できているわけではない。
【０００７】
【特許文献１】
特開昭６３−２３４３２４号公報
【特許文献２】
特開平１−２３７８３２号公報
【特許文献３】
特開平７−１１０７５８号公報
【特許文献４】
特開平１１−２９６３７９号公報
【特許文献５】
特開２０００−３２２２６８号公報
【非特許文献１】
「携帯電話機のバグをユーザの手元で修正へ」日経エレクトロニクス、２００２年３月２５日号
【０００８】
【発明が解決しようとする課題】
組み込みソフトウェアのバージョンアップ時には、ソフトウェア全体を置き換えるか、差分データを追加する方法が考えられるが、これには人手で対処する必要がある。工場等に設置された機器の場合は、点検などにあわせて行うこともできるが、携帯電話のような消費者向けの機器の場合は、人手で行うにしても、ユーザが自分で無線などの通信手段を利用して行ないたいという要求がある。そうしないと、メーカ、販売店などの人が改修する必要がある。しかしながら、改修作業を考えると、当然、無線上に流すデータ量を抑える必要がある。従来の技術ではデータの差分を小さくすることはできており、ある程度自動的に処理手順を行えるようにはなっているが、ソフトウェア開発時には開発者は多数おり、プログラム分割単位であるモジュール構成などは考えにくく、徐々に出来上がってくるにもかかわらず、単純な外部シンボル情報のみを見て判断しているにすぎず、開発時のコストがかかるという課題がある。
【０００９】
この発明は上記の課題を解決するためになされたもので、一体化される組込みソフトウェアに対して分割を行ない、かつ分割されたモジュール間の参照をアドレスを固定した参照関係として、後の改修時には、全体の交換に代えて改修対象のモジュールのみを入れ換えればよいようにする。
【００１０】
【課題を解決するための手段】
この発明に係る組込みソフトウェア開発装置は、命令列をコンパイルし、ソフトウェアを構成する複数のオブジェクトをリンクしてアドレスを固定した組込みプログラムを作成するソフトウェア開発装置において、
組込みソフトウェアとして一体化されたこの組込みソフトウェアを細分化してモジュールを設定して、このモジュール間にまたがってシンボル参照する関係を抽出するモジュール間参照関係抽出部と、
モジュール間参照関係にある被参照モジュールにおいて、他モジュールからシンボル参照される受け入れ参照アドレスを定めたテーブルを定め、かつ受け入れ参照アドレスと自モジュール内のシンボル参照先の実アドレスとを結びつけるベクタテーブル作成部と、
他モジュールからの被参照アドレスをベクタテーブルの受け入れ参照アドレスに書換えるベクタテーブル・シンボル情報作成部、とを備え、
各モジュールの領域にアドレスを割当てる際に、共通の余裕領域を設けるようにした。
【００１２】
【発明の実施の形態】
実施の形態１．
コンパクトなメモリ使用量とするため、またそれ自体で完結するため、組込みソフトウェアは全体を一体化して作成するのが常である。またその場合、ソフトウェアの部分担当者は、他の部分担当者との連携はその時点では考える必要はなく、あとでコンパイルされる。ところでこうした組込みソフトウェアにおいても、各部分で改修が生じた場合に、全体を入れかえるのは大変なので、改修対象の部分のみを入れ換えたい。
この実施の形態においては、一体化された組込みソフトウェアを、後の改修に伴う入れ換えが容易なように、モジュール化し、かつ一体化ソフトウェアにおける参照を、モジュール間の参照に置き換え、従って改修モジュールを入れ換えても、他のモジュールには影響が及ばない組込みソフトウェア、を生成する開発装置、または開発方法を説明する。
【００１３】
以下に本発明の実施の形態を述べる。図１〜図５及び一般的な動作図である図１２を用いて本発明の構成と動作を説明する。図１は、本発明における装置の構成と、それらが全体として行う、目的プログラムの生成手順を示したフロー図である。
図において、モジュール定義ファイルというのは、ユーザが作成した複数のファイルや関数からなるプログラムのソースファイル１００であり、通常、管理者により作成されるものである。本発明に関係のあるモジュール定義ファイル１０１は、作成したソースファイルをモジュールに分割するためのユーザが指定する定義ファイルであり、本来プログラム間の関数呼び出し関係が最小になるように指定する方が良いファイルであるが、開発途上ではすぐに変わるため、変更可能なようにしておくべきファイルである。図２にその例を示し、どのアドレスでモジュールｍ０、ｍ１等が分割されるかを指定している。コンパイラ１２０は従来からあるコンパイラと同じで、図１２のステップ２１１で、ソースプログラムを解釈し、機械語命令に置き換えていくが、複数のプログラム間の関係となるアドレス解決はせずにシンボル情報としてもオブジェクトファイル内に格納しておく装置であり、プログラムごとにオブジェクトファイル１１１を出力する。
【００１４】
リンカ１２１は、従来からあるリンカであり、図１２のステップ２１２で、複数のオブジェクトファイル１１１から未解決のシンボル情報を解決してひとつのオブジェクトにしたリンク済みオブジェクトファイル１１２を生成し、リンク時に解決したシンボルの情報をシンボル情報ファイル１１３として出力する。また、アドレスが全部解決できなかった場合はエラーとし、どの部分が解決できなかったかを示す。このほか、従来のリンカでは、複数のオブジェクトファイルで、シンボル解決に足りないものがあっても、別の機会にリンカで解決したシンボル情報ファイルを入力として全体として解決することもできる。
【００１５】
ユーザ指定モジュール間参照関係抽出部１２２は、ユーザが指定するモジュール定義ファイル１０１を入力として、ユーザが指定した部分プログラムの集合をひとつのモジュールとして、この間の参照関係のみをシンボル情報ファイル１１３の中から抽出して、モジュール間参照関係表１１４を出力する。
シンボル情報ファイル１１３の中から抽出して、モジュール間参照関係表１１４を出力する。図３はそれを説明する図であり、図３（ａ）はシンボル情報ファイル中のｆｕｎｃ＿ａがアドレス０００００ｄ０４にあって、他の０１８ｆ３１ｅａを初めとする１４個所のアドレスから参照されることを示している。モジュール間参照関係抽出部１２２は、これを上記で説明したように異なるモジュールから参照される関係のみを抽出する。この場合ｆｕｎｃ＿ａはモジュール定義ファイル１０１を参照してモジュール０にあることを知り、図３（ａ）の１４個所のうち、同一のモジュール０内の参照を除いて、他のモジュールからは６個所から参照されることを抽出し、外部定義する関数名を並べて、シンボルと、シンボルがあるアドレスと、参照されるアドレス、とを組にして、図３（ｂ）のように出力する。
更に、関数の参照か、データの参照かは、参照元のアドレスの命令がジャンプ系の命令であれば関数参照とし、レジスタへのロード命令であればデータ参照であるとする。更にアセンブラレベルのプログラムであれば、データはサイズ情報の出力をするので、これを用いてサイズ情報があればデータ参照とする。
【００１６】
命令参照ベクタテーブル作成部１２３は、モジュール間参照関係表１１４から、モジュール間の参照に関する関数の入り口を決まった位置に固定するための関数の入り口へのジャンプまたは関数の入り口のアドレスを保持する情報テーブルとしてベクタテーブル１１５を出力する。
図４はベクタテーブルの概念を説明する図であり、図４（ａ）は図３（ｂ）のモジュール間参照関係表１１４を示しており、ベクタテーブル作成部１２３は、具体的には、この関係表からベクタテーブルとして固定の入口アドレスを先頭部分に設定した部分と、この分割されたモジュール内の実アドレスと設定した固定アドレスとを結びつけるジャンプ命令の記述を行ない、これらジャンプ命令列で構成される、図４（ｂ）に示される出力をする。
【００１７】
ベクタテーブル・シンボル情報作成部１２４は、上記ベクタテーブル１１５を入力として、他からこのモジュールの参照に関しては直接関数をコールするのではなく、上記ベクタテーブル１１５を経由してコールさせるために、シンボルを解決するときに利用するべきベクタテーブル向けシンボルファイル１１６を出力する。
図５（ｂ）はベクタテーブル向けシンボルファイル１１６の概念を示す図である。即ち図５（ａ）に示されるベクタテーブルに対して、他のモジュールから参照される実アドレスに代えて、ベクタテーブルの受け入れ参照アドレスを指定する。図５の例では、参照受け入れアドレスはベクタテーブルのアドレス１００番地にあって、ここには実アドレスｄ０４番地に飛ぶ命令が入っており、その実アドレスｄ０４番地に＿＿ｆｕｎｃ＿０ａの命令がある。
【００１８】
このように指定すると、ベクタテーブル１１５に記載された固定の受け入れ参照アドレスには、実アドレスへジャンプする命令が入っているので、モジュール内の実アドレスにある関数を参照しに行く。
なお詳細には、分割したモジュールが改修等でメモリの使用領域が拡大することを予想して、各モジュールに余裕領域を付加したアドレスでモジュールを設定するので、設定アドレスと実アドレスは変更される。
この後、コンパイラ１２０と、リンカ１２１にこのデータをコンパイル、リンクさせて目的の一体化した組み込み用の目的プログラム１１７を得る。この際、自身のモジュールのシンボル未解決のオブジェクトとリンクし、リンクした結果のオブジェクトを同時に結合する。図５（ｃ）はこの組込みソフトウェアの最終状態を示す図である。図５（ｃ）の左側に示す従来の一体化組込みソフトウェアは、本実施の形態では、命令参照ベクタテーブル作成部１２３によるベクタテーブル１１５と、ベクタテーブル・シンボル情報作成部１２４によるベクタテーブル向けシンボルファイル１１６により、モジュールＡを始めとする分割された各モジュールＢ，Ｃ等になる。更にそれらが連結されて、かつ各モジュールに余裕領域を設け、他モジュールからは先ず先頭のベクタテーブルの固定アドレスに参照される構造となる、図５（ｃ）の右側に示す、一つの組込みソフトウェアになる。
【００１９】
なお、上記の実施の形態において、ソースプログラムは、Ｃ言語やアセンブリ言語によるプログラム記述言語で書かれたものであってよく、その場合は参照関係出力部は、上記言語で書かれたテキストファイルの内容を見て参照関係を判断する。
また元のプログラムコードが関数呼び出し形式で書かれているか、またはアセンブリ言語のジャンプ命令で書かれているか、スタックへの退避命令で書かれているか、を判断する機能を持たせてもよい。
または、目的プログラム中の命令コードから参照関係を判定する機能を持たせてもよい。
【００２０】
以上のような構成をすることにより、ユーザが定義した各モジュール間の関数の呼び出しはベクタテーブル経由となり、モジュール内の場合は、複数のプログラムの集まりで外部呼出し宣言がされていたとしてもモジュール内参照の扱いで直接ジャンプする形式となり、ベクタテーブルはモジュール間のみ参照だけで小さくすることができるとともに、呼び出し位置はモジュールの先頭で固定とできる。
【００２１】
更に、一体化した組込みソフトウェアをモジュール化したので、ソフトウェアの改修があっても改修部分のモジュールのみを更新すればよいので、更新量が抑えられ、ユーザ等により容易に行なえる。
上記説明では、モジュール間参照関係出力部、ベクタテーブル作成部、ベクタテーブル・シンボル情報作成部をハードウェアで構成する例を説明したが、これらを汎用の計算機による機能ソフトウェアで構成し、同等ステップを持たせた開発方法としてもよい。
【００２２】
上記実施の形態では、シンボル参照は関数の参照をする場合を説明したが、関数参照に代えてデータ参照をするプログラムに対して、モジュール化をする開発装置、または方法を説明する。
図６は、参照関係がデータである場合の開発装置構成と、生成手順を示す図である。図において図１の構成と異なる部分は、ベクタテーブル作成部とベクタテーブル・シンボル情報作成部に換えて、共通データ作成部を設けた構成となっている。
即ち参照関係がデータ参照である場合には、参照関数の演算機能が必要無く、単にデータが判ればよいので、これら参照されるデータ群を共通データとしてテーブル（表）にまとめればよい。
【００２３】
図７（ａ）は、シンボル情報ファイル１１３がデータである場合の例を示す図であり、モジュール間参照関係抽出部１２２は参照がデータであると判定すると、図７（ｂ）のモジュール間データ参照表（テーブル）５１０を、ベクタテーブル作成部にではなく、共通データ作成部５０２に出力する。この図７（ｂ）の例では、モジュールｍ０の参照０ａのデータが、実アドレスは０００００ｄ０４にあり、他のモジュールの０１８ｆ３１ｅ６等から参照されている。
共通データ作成部５０２は、図８（ａ）に示すモジュール間データ参照表５１０から、モジュール間のデータ参照に関するデータを共通データとし、データ構造を定義した図８（ａ）に示す共通データ５１１を出力する。
即ち共通にすべきデータが示されているので、その内容を共通データとしてまとめて固定アドレスを確保してそこにテーブルとして用意する。
【００２４】
図６において、各ソフトウェアの部分担当者が作成したソースファイル１００をコンパイラ１２０にかけてコンパイルし（図１２の作業２１０、２１１）、リンカ１２１でリンク作業２１２を行なう。このとき対象としたソースプログラム外の関数参照や、外部からの参照を許可する部分に関しては、未解決であることを示すエラーのままで出力し、リンク済みオブジェクトファイル１１２とシンボル情報ファイル１１３を得る。
ステップ２１２では、前記ステップ２１１の出力であるアドレス未解決状態のオブジェクトファイルを繋ぎ合わせて、お互いのアドレスで解決できるものは解決し、リンク済みオブジェクトファイル１１２とシンボルの解決時に利用したシンボルとアドレスの参照関係を示すシンボル情報ファイル１１３を出力する。
また、アドレスが全部解決できなかった場合はエラーを発生し、どの部分が解決できなかったかを示す。
【００２５】
上記得られたリンク済みオブジェクトファイル１１２とシンボル情報ファイル１１３に、モジュール分割を指定したモジュール定義ファイル１０１を用いて、モジュール間参照関係抽出部１２２がモジュール間データ参照表５１０を抽出する。
更に共通データ作成部５０２が共通データ５１１を作成する。
最後にベクタテーブル１１５とベクタテーブル向けシンボルファイル１１６、または共通データ（テーブル）５１１を用いてコンパイル・リンク処理を行って、目的とする組込み用一体化プログラム（目的プログラム）が得られる。
【００２６】
以上のような構成をすることにより、ユーザが定義した各モジュール間の関数のデータ参照は共通データへの参照となり、モジュール内の場合は、複数のプログラムの集まりで外部参照宣言がされていたとしてもモジュール内参照の扱いで直接アクセスする形式となり、共通データはモジュール間のみ参照だけで小さくすることができるとともに、呼び出し位置はモジュールの先頭で固定とできる効果がある。また、頻繁に変更するデータは共通データとせず関数経由でのアクセスとすることにより、共通データ領域に持っていかないとともに、必ずこの関数を経由することによりデバッグもしやすくなる効果がある。
【００２７】
また共通データは固定位置におかれるため、最終的にはソフトウェアを更新する際の差分量を抑えることができるとともに、開発時にはモジュールの指定変更を行うことにより、容易に構成変更を行うことができる。
【００２８】
図１の構成において、ベクタテーブル作成部はベクタテーブル１１５の作成に際してその領域については言及しなかった。しかし後のソフトウェア改修を考えれば、空き領域を設けておくことが望ましい。
この空き領域を各モジュールの量に比例して設けて、各モジュール毎の改修に対処してもよいし、あるいは全体として共通の空き領域を確保して、ソフトウェアの改修が発生すると、この共通の空き領域を使用するようにしてもよい。
【００２９】
実施の形態２．
実施の形態１ではメモリの種類について触れなかったが、一般的に組込み機器は複数の異なる特性をもつメモリ、例えばフラッシュＲＯＭやＳＲＡＭ、擬似ＳＲＡＭ等から構成される。実施の形態２では複数のメモリを考慮した開発装置について説明する。
本実施の形態における装置の構成と目的プログラムの生成手順は、図１に示す実施の形態１と同じである。以下では実施の形態１と異なる部分についてのみ図９、図１０、図１１を用いて説明する。なお、組込み機器のメモリはフラッシュＲＯＭ（以下、ＲＯＭ）とＳＲＡＭ（以下、ＲＡＭ）から構成されているものとする。
【００３０】
モジュール定義ファイル１０１には、モジュールの情報とともに組込み機器を構成するメモリのアドレス情報も記載する。図２にその例を示し、２種類のメモリＲＡＭとＲＯＭのアドレスの範囲を示している。この情報を元にシンボルがＲＡＭに配置されているか、ＲＯＭに配置されているかを判断することができる。
【００３１】
実施の形態２では、命令参照ベクタテーブル作成部１２３はモジュール定義ファイル１０１とモジュール間参照関係表１１４から、ベクタテーブル１１５の代わりに、図９に示すＲＡＭ用ベクタテーブル１１５ＡとＲＯＭ用ベクタテーブル１１５Ｂの２種類のベクタテーブルを作成する。
ＲＡＭ用ベクタテーブル１１５ＡにはＲＡＭ上の関数シンボルへのジャンプ命令、ＲＯＭ用ベクタテーブル１１５ＢにはＲＯＭ上の関数シンボルへのジャンプ命令が格納される。
【００３２】
ベクタテーブル・シンボル情報作成部１２４は、上記ベクタテーブル１１５Ａ、１１５Ｂを入力として、他からこのモジュールの参照に関しては直接関数をコールするのではなく、上記ベクタテーブル１１５Ａもしくは１１５Ｂを経由してコールさせるために、シンボルを解決する時に利用するベクタテーブル向けシンボルファイル１１６’を図１０のように出力する。
また、実施の形態２では、コンパイラ１２０とリンカ１２１を用いて目的プログラム１１７を得る際に、各モジュールのアドレス配置では、図１１に示したように各モジュールのＲＡＭ領域、ＲＯＭ領域のそれぞれに余裕領域を設けることで、メモリの使用領域の拡大に対応する。
【００３３】
以上では関数参照の場合について説明したが、以下では関数参照に代えてデータ参照をするプログラムに対して、モジュール化をする場合について説明する。参照されるデータ群を共通データとしてテーブルにまとめる際、モジュール定義ファイル１０１のメモリのアドレス情報から、参照されるデータがどのメモリに配置されるかがわかるので、配置されるメモリの種類ごとに共通データのテーブルを作成する。これらの共通データテーブルは、固定アドレスを確保して配置するが、この際、共通データテーブルの配置先アドレスは、共通データが元々配置されていたメモリと同じメモリ上のアドレスとする。
【００３４】
以上のような構成にすることにより、実施の形態１で示した開発装置を複数のメモリから構成される組込み機器のプログラムに適用することが可能になる。さらに、以上のような構成にすることで、モジュールのあるメモリ上での変更が発生した場合でも、そのモジュールの当該メモリの内容のみを変更すれば良いので、さらに更新量を抑えられる。
【００３５】
【発明の効果】
以上のようにこの発明によれば、組込みソフトウェアの開発に際して、モジュール分割を行ない、このモジュール間参照関係を抽出し、ベクタテーブルを作成し、モジュール間参照のアドレスを解決したので、ソフトウェアの改修があっても、該当するモジュールのみの交換で対処できるソフトウェアを開発できる効果がある。
【図面の簡単な説明】
【図１】  この発明の実施の形態１における開発装置の構成と目的プログラム生成の手順を示す図である。
【図２】  実施の形態１におけるモジュール定義ファイルの例を示す図である。
【図３】  実施の形態１におけるシンボル情報ファイルの例と、モジュール間参照関係表の例を示す図である。
【図４】  実施の形態１におけるベクタテーブルの例を示す図である。
【図５】  実施の形態１におけるベクタテーブル向けシンボルファイルの例と、目的プログラムの例を示す図である。
【図６】  実施の形態１における開発装置の他の構成と目的プログラム生成の手順を示す図である。
【図７】  実施の形態１におけるモジュール間データ参照表の例を示す図である。
【図８】  実施の形態１における共通データ表の例を示す図である。
【図９】  この発明の実施の形態２における２種類のベクタテーブルの例を示す図である。
【図１０】  実施の形態２におけるベクタテーブル向けシンボルファイルの例を示す図である。
【図１１】  実施の形態２における２種類のメモリに展開した目的プログラムの例を記す図である。
【図１２】  一般的なコンパイル・リンク手順を示す図である。
【符号の説明】
１００  ソースファイル、１０１  モジュール定義ファイル、１１１  オブジェクトファイル、１１２  リンク済みオブジェクトファイル、１１３  シンボル情報ファイル、１１４  モジュール間参照関係表、１１５  ベクタテーブル、１１６  ベクタテーブル向けシンボルファイル、１１７  目的プログラム、１２０コンパイラ、１２１  リンカ、１２２  モジュール間参照関係抽出部、１２３ベクタテーブル作成部、１２４  ベクタテーブル・シンボル情報作成部、５０２  共通データ作成部、５１０  モジュール間データ参照表、５１１  共通データ。
【図１】
0003682050.tif 000002
【図２】
0003682050.tif 000003
【図３】
0003682050.tif 000004
【図４】
0003682050.tif 000005
【図５】
0003682050.tif 000006
【図６】
0003682050.tif 000007
【図７】
0003682050.tif 000008
【図８】
0003682050.tif 000009
【図９】
0003682050.tif 000010
【図１０】
0003682050.tif 000011
【図１１】
0003682050.tif 000012
【図１２】
0003682050.tif 000013