(57)【要約】【課題】プログラムの実行にあたり、ライブラリのリンク処理をより適切に行うことを目的とする。【解決手段】プログラムがライブラリとリンクして実行される情報処理装置が、プログラムの実行に際し、ライブラリの実施状況に応じてプログラムのヘッダ情報を書き換える更新手段と、更新手段で更新されたヘッダ情報に基づいてライブラリへのリンク処理を遅延させる遅延手段とを備えることによって課題を解決する。【選択図】図６
2013033427.tif 000002
【特許請求の範囲】
【請求項１】
プログラムがライブラリとリンクして実行される情報処理装置であって、
プログラムの実行に際し、ライブラリの実施状況に応じて前記プログラムのヘッダ情報を書き換える更新手段と、
前記更新手段で更新された前記ヘッダ情報に基づいてライブラリへのリンク処理を遅延させる遅延手段とを備えることを特徴とする情報処理装置。
【請求項２】
前記更新手段は、リンク処理を遅延させるライブラリを決めるための識別子を前記ヘッダ情報に書き込むことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記遅延手段は、前記プログラムがライブラリの関数を呼び出すにあたり、前記更新手段で前記ヘッダ情報に書き込まれた識別子を認識して前記ライブラリへのリンク処理を遅延させることを特徴とする請求項２記載の情報処理装置。
【請求項４】
プログラムがライブラリとリンクして実行される情報処理装置における情報処理方法であって、
プログラムの実行に際し、ライブラリの実施状況に応じて前記プログラムのヘッダ情報を書き換える更新工程と、
前記更新工程で更新された前記ヘッダ情報に基づいてライブラリへのリンク処理を遅延させる遅延工程とを備えることを特徴とする情報処理方法。
【請求項５】
請求項４記載の情報処理方法の各工程をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、及びプログラムに関する。
【背景技術】
【０００２】
従来、ライブラリを使用するプログラムが動作する情報処理装置としては、静的リンク方式と動的リンク方式とがある。動的リンク方式と静的リンク方式とを比べると、動的リンク方式では、プログラム中にライブラリのコードを含んでおらず、ライブラリがプログラムとは独立したオブジェクトであるので、プログラムを変更することなくライブラリの更新が可能である。また、複数のプログラムが同一のライブラリを使用する場合、ライブラリのコードを夫々のプログラムに含む静的リンク方式に比べ、プログラムの実行時に必要なライブラリを動的にリンクして共通に利用する動的リンク方式は、使用するメモリの削減が可能となる。
【０００３】
一方で、動的リンク方式には、実行時に必要とするライブラリのシンボルアドレスを解決し、プログラムが共有ライブラリの関数を使用できるようにする処理が必要である。これは、プログラムの実行時に遅延を有することを意味する。さらに、この遅延は、プログラムの実行時には毎回発生する。
この遅延を短縮する方法として、モジュールをリンクする際に予めテーブルを作成しておくことで、テーブルを参照してリンクする処理を高速に行い、かつ動的リンク方式のコンパクト性の維持を実現するものが開示されている（特許文献１参照）。
また、UNIX（登録商標）、Linux（登録商標又は商標）等のオペレーティングシステム（ＯＳ）では、様々なプログラムが共通に使用する関数群をまとめた共有ライブラリの必要なものだけをリンクして使用する動的リンク方式を用いることが一般的である。なお、共有ライブラリは、様々なプログラムから呼ばれる関数群を提供するため、構造が汎用的になっており、その内部構成は、ライブラリによって様々である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平０５−１８９２１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、特許文献１の技術では、前記遅延を改善するため、ライブラリのアドレスを再配置した後の状態をテーブルとして残しておき、プログラムの実行時にはテーブルを用いてプログラムの実行時における遅延の削減を実現している。
しかしながら、特許文献１の技術では、プログラム及び複数のライブラリのうちどれかの内部構成を大きく変更する必要が生じた場合、これまでのテーブルを使用することができない。そのため、ライブラリのみの更新であった場合でも、プログラム、ライブラリ、及びテーブル全ての更新が必要となる。
【０００６】
本発明はこのような問題点に鑑みなされたもので、プログラムの実行にあたり、ライブラリのリンク処理をより適切に行うことを目的とする。
【課題を解決するための手段】
【０００７】
そこで、本発明に係る情報処理装置は、プログラムがライブラリとリンクして実行される情報処理装置であって、プログラムの実行に際し、ライブラリの実施状況に応じて前記プログラムのヘッダ情報を書き換える更新手段と、前記更新手段で更新された前記ヘッダ情報に基づいてライブラリへのリンク処理を遅延させる遅延手段とを備えることを特徴とする。
【０００８】
また、本発明は、記録媒体などとしてもよい。
【発明の効果】
【０００９】
本発明によれば、プログラムの実行にあたり、ライブラリのリンク処理をより適切に行うことができる。
【図面の簡単な説明】
【００１０】
【図１】情報処理装置の一例を示す図である。
【図２】プログラムが共有ライブラリをリンクする仕組みの一例を示す図である。
【図３】プログラムが共有ライブラリをリンクする仕組みの一例を示す図である。
【図４】プログラムの作成方法の一例を示す図である。
【図５】遅延対象のライブラリの決定に用いるリストの一例を示す図である。
【図６】プログラムの作成方法の一例を示す図である。
【図７】プログラムの実行例を示す図である。
【図８】プログラムを実行する処理に係るフローチャートの一例を示す図である。
【図９】プログラムを実行する処理に係るフローチャートの一例を示す図である。
【図１０】ライブラリ関数処理部の一例を示す図である。
【図１１】プログラムの作成方法の一例を示す図である。
【図１２】プログラムの作成方法の一例を示す図である。
【図１３】ライブラリ関数処理部の一例を示す図である。
【図１４】呼び出し履歴の一例を示す図である。
【図１５】呼び出し履歴を作成する処理に係るフローチャートの一例を示す図である。
【図１６】遅延対象のライブラリの決定に用いるリストの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態について図面に基づいて説明する。なお、実施形態は、本発明を限定するものではなく、また、実施形態で説明されている全ての構成が本発明の課題を解決するための手段に必須であるとは限らない。
【００１２】
＜第１の実施形態＞
本実施形態を図１から図１０を用いて説明する。本実施形態は、共有ライブラリを動的にリンク（動的リンク）して実行する情報処理装置（コンピュータ）等に関するものである。
図１は、本実施形態に係るプログラムの実行の対象となる情報処理装置１００のハードウェアの構成の一例を示す図である。ＣＰＵ１０１は、情報処理装置１００全体を制御するCentral Processing Unit（ＣＰＵ）である。情報処理装置１００では、ＣＰＵ１０１の制御のもとオペレーティングシステム（ＯＳ）、アプリケーションなどが動作している。
主記憶装置１０２は、プログラムやデータを一時記憶するRandom Access Memory（ＲＡＭ）である。二次記憶装置１０３は、ハードディスクドライブ（ＨＤＤ）やフラッシュメモリのようなデータやプログラムを記録しておくことができる不揮発な記録媒体である。デバイス１０４は、ネットワーク機器やシリアル通信機器などの情報処理装置１００に接続された周辺機器である。バス１０５は、各ユニットを通信可能に接続するシステムバスである。
【００１３】
図２、図３は、共有ライブラリを動的リンクしてプログラムを使用する際の仕組みの一例を示す図である。図２、図３を用いて動的リンクの概要を説明する。なお、ＣＰＵ１０１が、二次記憶装置１０３に格納されたプログラムの手順に従って処理を行うことによって、後述のダイナミックリンカ・ローダ２０１の機能、後述のフローチャートの処理が実現される。
ここでは、あるプログラムＡ２１１がライブラリＡ２２１とライブラリＢ２２３というライブラリを動的リンクして実行されるものとする。また、プログラムＡ２１１は、ライブラリＡ２２１の関数Ａ２２０とライブラリＢ２２３の関数Ｂ２２２とを呼び出す構成である。
【００１４】
上記の場合、プログラムＡ２１１を実行するにあたり、ダイナミックリンカ・ローダ２０１は、プログラムヘッダ情報部３１０を参照し、プログラムＡ２１１にはライブラリＡ２３０及びライブラリＢ２３１が必要であることを検出する。
そして、ダイナミックリンカ・ローダ２０１は、二次記憶装置１０３よりライブラリＡ２３０及びライブラリＢ２３１をロードする。なお、ロードされたライブラリＡ２３０及びライブラリＢ２３１は、主記憶装置１０２にライブラリＡ２２１及びライブラリＢ２２３として展開される。
【００１５】
また、ロードされたライブラリＡ２２１及びライブラリＢ２２３は、この時点では、まだプログラムＡ２１１が呼び出すことができる状態ではない。そこで、ダイナミックリンカ・ローダ２０１は、ライブラリＡ２２１及びライブラリＢ２２３のアドレス情報に関する再配置を行い、プログラムＡ２１１が呼び出すことが可能な状態にする。ここで、呼び出し可能となった状態を仮想記憶３０１に展開されたプログラムＡ３０２とする。再配置されたライブラリの情報は、ライブラリロード部３０４のようになるものとする。
以上が、プログラムＡ２１１で用いられる共有ライブラリを動的リンクする際の処理の一例である。
【００１６】
一般的に、ライブラリのアドレス情報の再配置に関する処理には時間がかかる。特に、プログラムが共有ライブラリを多く必要とすればするほど、その再配置に関する処理時間は増大し、プログラムの実行までの遅延における主要因となる。
そこで、本実施形態では、後述のコンパイラ・リンカ４００等でプログラムが更新され、更新されたプログラム（実行オブジェクト）がダイナミックリンカ・ローダ２０１で用いられる構成を採用し、プログラムの実行までの遅延を低減する方法について説明する。
より具体的には、本実施形態では、図４に示すプログラムＢ４１０が共有ライブラリＡの関数Ａ、共有ライブラリＢの関数Ｂ、共有ライブラリＣの関数Ｃをそれぞれ呼び出して実行するプログラムである場合について説明する。さらに、共有ライブラリＣの関数Ｃは、エラー処理のような、プログラムＢ４１０を実行するために必ずしも急を要するものではないことが自明であることがわかっている場合について説明する。
なお、ＣＰＵ１０１が、二次記憶装置１０３に格納されたプログラムの手順に従って処理を行うことによって、後述のコンパイラ・リンカ４００の機能、後述のフローチャートに係る処理が実現される。
【００１７】
プログラムＢ４１０は、情報処理装置１００上で実行される際、共有ライブラリＡ、共有ライブラリＢ、共有ライブラリＣを必要としている。故に、コンパイラ・リンカ４００によりプログラムＢ４１０が実行オブジェクトとして生成されるとき、共有ライブラリをリンクする処理（リンク処理）が予め必要であるフラグがプログラムヘッダ情報部４１１に記述される。本実施形態では、このフラグをNEEDEDと表すことにする。
ここで、一般的には、NEEDEDフラグは、プログラムＢ４１０が実施される直前に用いる全てのライブラリのリンク処理が行われることを意味する。
ただし、本実施形態では、NEEDEDフラグは、プログラムＢ４１０を実施するにあたり必須のライブラリであることを表すフラグであるとする。これに該当するものがライブラリＡ、及びライブラリＢであるとする。他方、プログラムＢ４１０を実行するにあたり、必ずしも必須ではないライブラリに対しては相当のフラグ（本実施形態ではこのフラグをMAY_NEEDEDと表すことにする。）が付与されるものとする。これに該当するものがライブラリＣであるとする。
【００１８】
このようなプログラムＢ４１０とライブラリとの情報を図５に示すリンクリスト５００に予め記述し、用意しておく。なお、リンクリスト５００は、二次記憶装置１０３等の記憶装置に記憶されている。
また、プログラムＢ４１０は、図６に示すように、リンクリスト５００に記述された情報を元に、ライブラリ関数処理部更新部６０１によってライブラリ関数処理部６１２が書き換えられる。また、プログラムヘッダ情報更新部６００によって実施状況に応じてプログラムヘッダ情報部６１１のように書き換えられる。
最終的に、ライブラリ関数処理部６１２及びプログラムヘッダ情報部６１１を書き換えられるプログラムＢ４１０は、プログラムＢ６１０となり、情報処理装置１００上で実行される。
なお、ＣＰＵ１０１が、二次記憶装置１０３に格納されたプログラムの手順に従って処理を行うことによって、プログラムヘッダ情報更新部６００の機能、後述のフローチャートに係る処理が実現される。また、ライブラリ関数処理部更新部６０１についても同様である。
【００１９】
次に、プログラムＢ６１０が情報処理装置１００で実行されるときの処理について図７、図８を用いて説明する。まず、ダイナミックリンカ・ローダ２０１は、プログラムＢ６１０の開始を検出すると（Ｓ８０１）、スタックなどライブラリ以外に関するプログラムＢ６１０の開始準備を行う（Ｓ８０２）。次に、共有ライブラリのアドレス解決や再配置などのリンク処理が行われる（Ｓ８０３）。
より具体的には、Ｓ８０３では、ダイナミックリンカ・ローダ２０１は、プログラムヘッダ情報部６１１に記述されたライブラリ情報のフラグうち、ライブラリＡやライブラリＢのようにNEEDEDと記述されたもののみリンク処理を行う（Ｓ８０４、Ｓ８０５）。一方、ライブラリロード予約部７１０は、ライブラリＣのようにフラグにMAY_NEEDEDと記述されたものについては、Ｓ８０６にてリンク処理は行わず、ライブラリがロードされる領域であるライブラリＣロード予約部７０４の予約のみを行う（Ｓ８０６）。なお、ＣＰＵ１０１が、二次記憶装置１０３に格納されたプログラムの手順に従って処理を行うことによって、ライブラリロード予約部７１０の機能、Ｓ８０６等に係る処理が実現される。
【００２０】
次に、プログラムＢ６１０から各ライブラリの関数（ライブラリ関数）が呼ばれたときの処理について、図９、図１０を用いて説明する。まず、ダイナミックリンカ・ローダ２０１は、ライブラリ関数が呼び出されたことを検出する（Ｓ９０１）。ここで、通常（NEEDEDフラグのあるライブラリ）のライブラリ関数処理部６１２の詳細は、図１０のようになっている。ライブラリ関数処理部６１２は、例えばＧＯＴ（Global Offset Table）のような場所を指す。
ライブラリ関数処理部６１２に従って、即ち関数Ａの場合では、NEEDEDフラグが付与されたライブラリの関数であるので（Ｓ９０２でＹＥＳであるので）、Ｓ９０４にて関数シンボル解決処理が行われる。より具体的には、ポインタ１００２に関数シンボル解決処理へのポインタが格納されており、関数シンボル解決処理が実行される。関数シンボル解決処理が終了すると、ライブラリ関数へのポインタ１００３に実際のライブラリ関数へのポインタが格納される。以降、同様のライブラリ関数が呼び出された場合、ライブラリ関数へのポインタ（識別子）１００３が呼び出されるようになる。
【００２１】
一方、MAY_NEEDEDと記述された共有ライブラリに関しては、ライブラリ関数が呼び出されたことが検出されると（Ｓ９０１）、Ｓ９０２でNEEDEDのライブラリではないと判定され、Ｓ９０３のライブラリのロード・再配置処理が実行される。
このロード・再配置処理は、NEEDEDフラグが付与された共有ライブラリがプログラムの開始時に実行されるべきライブラリのロード・再配置処理と同様である。なお、共有ライブラリがロードされるべき領域は、プログラムの実行時に予め予約された領域であり、例えば、ライブラリＣではライブラリＣロード予約部７０４となる。
Ｓ９０３のライブラリのロード・再配置処理が完了した後は、MAY_NEEDEDフラグが付与された共有ライブラリもNEEDEDフラグが付与された共有ライブラリと同等の処理が行われる。このため、Ｓ９０４の関数シンボル解決処理が実行されたのち、Ｓ９０５にて実際に共有ライブラリの関数呼び出しが行われる。
【００２２】
このように、即時に必要がないライブラリについては、プログラムの実行時においてリンク処理などの当該ライブラリの使用準備が行われない。そして、当該ライブラリが必要となったときに初めて当該ライブラリを使用可能にする使用準備が行われる。
即ち、上述した構成によれば、即時に必要がないライブラリのリンク処理が遅延されるので、プログラムの実行開始までの処理時間を削減することができる。また、上述した構成によれば、一部のライブラリが更新などにより変更されるような場合があっても、他のプログラム、ライブラリには影響を及ぼすことのなく実行可能である。
【００２３】
＜第２の実施形態＞
本実施形態について図１１〜図１６を用いて説明する。なお、本実施形態では、第１の実施形態の構成と同一の構成については同一の符号を用いて、その説明を適宜省略する。
本実施形態では、第１の実施形態とは異なり、図１１に示すプログラムＣ１１００が、どのような共有ライブラリをリンクし、ライブラリ関数をどのような頻度で呼び出しているかわからない。そのため、情報処理装置１００は、プログラムＣ１１００を一度または複数回実行し、実行中の共有ライブラリ関数の呼び出し履歴を記録する。この呼び出し履歴を元に、次回のプログラムの作成時にライブラリに付与すべきフラグがNEEDEDであるのか、又はMAY_NEEDEDにすべきであるかどうかが決定される。
例えば、プログラムＣ１１００では、共有ライブラリＡの関数Ａは、頻繁に呼び出されるが、共有ライブラリＢの関数Ｂ及び共有ライブラリＣの関数Ｃについては条件によって呼び出されるかどうか予測ができないとする。
【００２４】
まず、プログラムＣ１１００は、コンパイラ・リンカ４００によって実行可能なオブジェクトとして生成される。この時点では、プログラムＣ１１００のプログラムヘッダ情報部１１０１に記述される共有ライブラリに付与するフラグは全てNEEDEDとなる。
次に、図１２のようにライブラリ関数処理部更新部６０１がプログラムＣ１１００のライブラリ関数処理部１２０１を変更する。変更する内容の一例を図１３に示す。まず、それぞれの関数が呼び出されたときには、関数の呼び出し履歴を収集できるような関数呼び出し履歴収集処理へのポインタ１３０２、１３０６を用意しておく。
【００２５】
また、関数呼び出し履歴収集処理の結果（呼び出し履歴）は、例えば図１４のようなリスト１４００になっており、関数を呼び出したプログラム名１４０１が記録される。以下同様に、使用されたライブラリ名１４０２、呼び出された関数名１４０３、呼び出し回数１４０４、呼び出し時間１４０５が呼び出し履歴に記録される。呼び出し時間１４０５については、該当関数が最初に呼び出されたときの時間が記録され、以降複数回呼び出されたときには記録されないものとする。
呼び出し履歴に記録された後は、通常通り関数シンボル解決処理へのポインタ１３０３、１３０７により関数シンボル解決処理が行われ、最終的にライブラリ関数が呼び出し可能となる。
なお、関数呼び出し履歴収集処理へのポインタ１３０２及び１３０６については、関数の呼び出し履歴を収集するか否かの切り替えが可能である。関数の呼び出し履歴の収集を行わない場合、通常通り関数シンボル解決処理から実行されるようになる。詳細は以後説明する。
【００２６】
次に、プログラムＣ１１００が情報処理装置１００上で共有ライブラリをリンクしながら実行される処理について図１５を用いて説明する。なお、プログラムの開始時に行われる共有ライブラリのロード処理、再配置処理などはこれまでと同様である。
まず、Ｓ１５０１では、ダイナミックリンカ・ローダ２０１は、共有ライブラリの関数が呼び出されたことを検出する。Ｓ１５０２では、ダイナミックリンカ・ローダ２０１は、関数の呼び出し履歴を記録するかどうかの判定を行う。このとき、ダイナミックリンカ・ローダ２０１は、呼び出し履歴を記録しないと判断した場合、通常通りＳ１５０４にて関数のシンボル解決処理を行い、Ｓ１５０５にて関数の呼び出しを行う。
一方、ダイナミックリンカ・ローダ２０１は、Ｓ１５０２にて関数の呼び出し履歴を記録すると判断した場合、Ｓ１５０３にて関数呼び出し履歴収集処理を実行し、図１４の呼び出し履歴に共有ライブラリ関数を呼び出した情報を記録する。関数呼び出し履歴収集処理が完了すると、ダイナミックリンカ・ローダ２０１は、通常通り、Ｓ１５０４の関数シンボル解決処理を実行し、最終的にＳ１５０５において共有ライブラリの関数の呼び出しを行う。
【００２７】
次に、遅延ライブラリ決定部は、プログラムＣ１１００を実行した後に得られた呼び出し履歴（リスト１４００）を元に、ライブラリのロード・再配置処理を遅延することが可能な共有ライブラリを決定する。遅延ライブラリ決定部は、ライブラリのロード・再配置処理が遅延可能な共有ライブラリを認識した場合は、MAY_NEEDEDフラグを付与するために図５と同様にリンクリストを作成し、遅延させたい共有ライブラリについてMAY_NEEDEDと記述する。
なお、遅延ライブラリ決定部については、図示を省略する。また、ＣＰＵ１０１が、二次記憶装置１０３に格納されたプログラムの手順に従って処理を行うことによって、遅延ライブラリ決定部の機能が実現される。
【００２８】
ここで、呼び出し履歴（リスト１４００）の情報を元にどの共有ライブラリのロード・再配置処理を遅延させるかを決定するかは様々な方法があるが、本実施形態では、図１６のような２通りの方法により、リンクリスト１、及びリンクリスト２が作成される。
リンクリスト１（１６００）は、遅延ライブラリ決定部がリスト１４００から共有ライブラリ関数の呼び出し回数１４０４を抽出し、呼び出し回数の少ないものを遅延させるべきライブラリであると決定したリストである。例えば、遅延ライブラリ決定部は、呼び出し回数１４０４から、ライブラリＢの関数Ｂの呼び出し回数が規定の回数よりも少ない１回であるので、遅延対象のライブラリであると判断し、リストにMAY_NEEDEDと記述する。
【００２９】
他方、リンクリスト２（１６０１）は、遅延ライブラリ決定部がリスト１４００から共有ライブラリ関数の呼び出し時間１４０５を抽出し、呼び出し時間が遅いものを遅延させるべきライブラリであると決定したリストである。
ここで、呼び出し時間１４０５には、関数が最初に呼び出された時間が記録されている。即ち、呼び出し時間１４０５が遅い関数は、該当ライブラリのロード・再配置処理の緊急性を要しない関数であると考えることができる。例えば、リスト１４００では、共有ライブラリＣの関数Ｃは、１０回呼び出されてはいるが、その呼び出し時間１４０５は規定の時間よりも遅かったとする。そのため、共有ライブラリＣは、プログラムの開始時にロード・再配置処理を行わなければならないような緊急性を要するライブラリではないので、遅延ライブラリ決定部は、リンクリスト２（１６０１）においてライブラリＣにMAY_NEEDEDフラグを付ける。
【００３０】
上述した構成によれば、プログラムＣがどのように関数を呼び出すかわからない場合でも、実行結果の履歴を取得し、その履歴からライブラリの処理を遅延すべき共有ライブラリを選定することが可能となる。
なお、作成されたリンクリスト１（１６００）及びリンクリスト２（１６０１）の形式は、第１の実施形態で用いた図５のリンクリスト５００と同様である。故に、リンクリスト１（１６００）又はリンクリスト２（１６０１）を用いてプログラムＣを実行する方法については、第１の実施形態のリンクリスト５００を用いた場合と同様である。
【００３１】
＜その他の実施形態＞
本実施形態は、コンピュータ内のプログラムの実行によっても実現できることは当然である。また、本実施形態は、フローチャートに係る処理の一部、又は全部を専用のハードウェアを用いて構成してもよい。また、本実施形態では、上述の処理の主体を適宜変更してもよい。
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００３２】
上述した実施形態の構成によれば、プログラムの実行にあたり、ライブラリのリンク処理をより適切に行うことができる。
【００３３】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００３４】
１０１  ＣＰＵ、１０２  主記憶装置、１０３  二次記憶装置、１０４  デバイス、１０５  バス
【図１】
2013033427.tif 000003
【図２】
2013033427.tif 000004
【図３】
2013033427.tif 000005
【図４】
2013033427.tif 000006
【図５】
2013033427.tif 000007
【図６】
2013033427.tif 000008
【図７】
2013033427.tif 000009
【図８】
2013033427.tif 000010
【図９】
2013033427.tif 000011
【図１０】
2013033427.tif 000012
【図１１】
2013033427.tif 000013
【図１２】
2013033427.tif 000014
【図１３】
2013033427.tif 000015
【図１４】
2013033427.tif 000016
【図１５】
2013033427.tif 000017
【図１６】
2013033427.tif 000018