(57)【要約】【解決手段】本発明は異種混合アーキテクチャからの複数のオブジェクトファイルを統合する方法である。第１プロセッサが第２プロセッサの名前空間からプログラムを参照するために、第２プロセッサのプログラム用のオブジェクトコードをラッパーの形で同封させて、第１プロセッサの名前空間におけるオブジェクトコードを生成する。ラップされたオブジェクトのヘッダは、第１プロセッサの名前空間において新しいシンボルを定義する。そのシンボルはラップされたオブジェクトコードに含まれる第２プロセッサのオブジェクトコードへのポインタである。第２プロセッサのオブジェクトコードを直接参照する代わりに、第１プロセッサ上の参照する側のプログラムがラップされたオブジェクトコードを参照する。第２プロセッサ上で動作するオブジェクトコードをラップするためにシステムツールを利用することができる。【選択図】図２
2008518355.tif 000002
【特許請求の範囲】
【請求項１】
第１プロセッサと第２プロセッサとを含むマルチプロセッサであって、
当該マルチプロセッサは、第２プロセッサ上で動作するオブジェクトコードであるＯＣ２コードに対応させて第１プロセッサ上で動作するオブジェクトコードであるＯＣ１コードを生成するように構成されており、前記ＯＣ１コードは前記ＯＣ２コードへのポインタであるシンボルの定義を含むことを特徴とするマルチプロセッサ。
【請求項２】
当該マルチプロセッサは、前記第２プロセッサ上での前記ＯＣ２コードの実行を生じさせるために、前記ＯＣ２コードに対応する前記ＯＣ１コードを前記第１プロセッサ上で実行するように構成されることを特徴とする請求項１に記載のマルチプロセッサ。
【請求項３】
前記ＯＣ２コードに対応する前記ＯＣ１コードを生成するように構成されたシステムツールをさらに含むことを特徴とする請求項１に記載のマルチプロセッサ。
【請求項４】
ＤＭＡコントローラをさらに含み、前記第１プロセッサはシステムメモリを含み、前記第２プロセッサはローカルストアを含み、当該マルチプロセッサは、データが前記第１プロセッサのシステムメモリにロードされ、ＤＭＡコントローラによって前記第２プロセッサの前記ローカルストアに転送されることによって、そのデータが前記第２プロセッサに渡されるように構成されることを特徴とする請求項１に記載のマルチプロセッサ。
【請求項５】
前記ＯＣ２コードに対応する前記ＯＣ１コードは、前記ＯＣ２コードをラッパーの形で同封することにより生成されることを特徴とする請求項４に記載のマルチプロセッサ。
【請求項６】
前記ＯＣ２コードをラッパーの形で同封することにより前記ＯＣ２コードに対応する前記ＯＣ１コードを生成するように構成されたシステムツールをさらに含むことを特徴とする請求項５に記載のマルチプロセッサ。
【請求項７】
前記ＯＣ２コードに対応して生成された前記ＯＣ１コードは、
シンボルの定義をもつヘッダ部と、前記ＯＣ２コードとを含み、
前記シンボルは前記ＯＣ２コードへのポインタであることを特徴とする請求項５に記載のマルチプロセッサ。
【請求項８】
マルチプロセッサ上の異種混合アーキテクチャからの複数のオブジェクトファイルを統合するための方法であって、
第２プロセッサ上で動作するオブジェクトコードであるＯＣ２コードへのポインタをもたせて、第１プロセッサ上で動作するオブジェクトコードであるＯＣ１コードを生成し、前記第１プロセッサ上で前記生成されたＯＣ１コードを実行することにより、前記第２プロセッサ上での前記ＯＣ２コードの実行を生じさせることを特徴とする方法。
【請求項９】
前記ＯＣ１コードを生成するためにシステムツールが供給されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記生成されたＯＣ１コードは前記ＯＣ２コードを含むことを特徴とする請求項８に記載の方法。
【請求項１１】
前記生成されたＯＣ１コードは、
シンボルの定義をもつヘッダ部と、前記ＯＣ２コードとを含み、
前記シンボルは前記生成されたＯＣ１コードに含まれた前記ＯＣ２コードへのポインタであることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記第１プロセッサから前記第２プロセッサへオブジェクトコードを実行のために渡すステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１３】
前記ＯＣ１コードによる前記ＯＣ２コードへの参照を前記生成されたＯＣ１コードに対する参照として解決するステップをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１４】
前記生成されたＯＣ１コードを実行可能なプログラムに変換するステップをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１５】
前記生成されたＯＣ１コードをアーカイブに変換するステップをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１６】
前記生成されたＯＣ１コードをダイナミック共有ライブラリに変換するステップをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１７】
マルチプロセッサ上の異種混合アーキテクチャからの複数のオブジェクトファイルを統合するためのコンピュータプログラム製品であって、前記コンピュータプログラム製品はコンピュータプログラムが具体化された媒体を有し、前記コンピュータプログラムは、
第１プロセッサ上で動作するオブジェクトコードであるＯＣ１コードであって、第２プロセッサ上で動作するオブジェクトコードであるＯＣ２コードへのポインタを含むＯＣ１コードを生成するためのコンピュータコードと、前記第１プロセッサ上で前記生成されたＯＣ１コードを実行することにより、前記第２プロセッサ上での前記ＯＣ２コードの実行を生じさせるためのコンピュータコードとを含むことを特徴とするコンピュータプログラム製品。
【請求項１８】
前記ＯＣ１コードを生成するためにシステムツールが供給されることを特徴とする請求項１７に記載のコンピュータプログラム製品。
【請求項１９】
前記生成されたＯＣ１コードは前記ＯＣ２コードを含むことを特徴とする請求項１７に記載のコンピュータプログラム製品。
【請求項２０】
前記生成されたＯＣ１コードは、
シンボルの定義をもつヘッダ部と、
前記ＯＣ２コードとを含み、
前記シンボルは前記生成されたＯＣ１コードに含まれた前記ＯＣ２コードへのポインタであることを特徴とする請求項１９に記載のコンピュータプログラム製品。
【請求項２１】
前記第１プロセッサから前記第２プロセッサへオブジェクトコードを実行のために渡すためのコンピュータコードをさらに含むことを特徴とする請求項１９に記載のコンピュータプログラム製品。
【請求項２２】
前記ＯＣ１コードによる前記ＯＣ２コードへの参照を前記生成されたＯＣ１コードに対する参照として解決するためのコンピュータコードをさらに含むことを特徴とする請求項１７に記載のコンピュータプログラム製品。
【請求項２３】
前記生成されたＯＣ１コードを実行可能なプログラムに変換するためのコンピュータコードをさらに含むことを特徴とする請求項１７に記載のコンピュータプログラム製品。
【請求項２４】
前記生成されたＯＣ１コードをアーカイブに変換するためのコンピュータコードをさらに含むことを特徴とする請求項１７に記載のコンピュータプログラム製品。
【請求項２５】
前記生成されたＯＣ１コードをダイナミック共有ライブラリに変換するためのコンピュータコードをさらに含むことを特徴とする請求項１７に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、オブジェクトファイルの処理に関し、特に、異種混合アーキテクチャからの複数のオブジェクトファイルを統合することに関する。
【背景技術】
【０００２】
異なるプロセッサに対応して別々の名前空間が設けられたマルチプロセッサにおいて、一つの名前空間で定められたプログラムは、もう一つの名前空間の上で定められたプログラムにリファレンスをつけることができる。これらのプロセッサは、異なるマシンタイプを構成しており、異なるアーキテクチャ、異なるインストラクションセット、および異なるオブジェクトファイルの形式をもつことがある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
リファレンスを解決するための従来の方法には、いくつかの問題がある。たとえば、リンカーは別のプロセッサで生成されたオブジェクトコードを誤って解釈することがあり、不正確にコードを処理することがあった。プログラマは、あるプロセッサで動いているプログラムから別のプロセッサの名前空間にあるプログラムへの呼び出しをハードコーディング（決め打ち）することもできるが、その手順はわずらわしいものになる。仮にハードコーディングを使ったとしても、オブジェクトコードをランタイム参照することはできないし、動的リンクやオブジェクト共有もできず、あるいは、マルチプロセッサの結合された名前空間からのオブジェクトを実行時に取り扱うこともできない。
【０００４】
したがって、異種混合アーキテクチャからの複数のオブジェクトファイルを統合する方法が必要であり、それによって、リンカーやローダーのようなシステムツールがオブジェクトファイルを適切に処理することができるようになり、そして、オブジェクトファイルへのランタイム参照、動的リンクとオブジェクト共有、マルチプロセッサの結合された名前空間からのオブジェクトの実行時の取り扱いも可能になる。
【課題を解決するための手段】
【０００５】
本発明は異種混合アーキテクチャからの複数のオブジェクトコードを統合するための方法である。第１プロセッサが第２プロセッサの名前空間からプログラムを参照するために、第２プロセッサのプログラム用のオブジェクトコードをラッパー（wrapper；包み込み）の形で同封させて、第１プロセッサの名前空間におけるオブジェクトコードを生成する。ラップされた（wrapped；包まれた）オブジェクトのヘッダは、第１プロセッサの名前空間において新しいシンボルを定義する。そのシンボルはラップされたオブジェクトコードに含まれる第２プロセッサのオブジェクトコードへのポインタである。第２プロセッサのオブジェクトコードを直接参照する代わりに、第１プロセッサ上の参照する側のプログラムがラップされたオブジェクトコードを参照する。
【発明を実施するための最良の形態】
【０００６】
本発明とその有利な点をより完全に理解するために、添付の図面と合わせて以下の説明を参照する。
【０００７】
以下の議論において、本発明を完全に理解するために、多数の具体的で詳細なことを述べるが、本発明はそのような具体的で詳細な事項がなくても実施できることは当業者にとって明らかである。他の例では、本発明を不必要なほど詳細にすることでかえってわかりにくくならないように、周知の構成要素については、概略図またはブロックダイヤグラムで説明した。
【０００８】
さらに、ここで述べられたすべての機能は、特に断らない限り、ハードウエアまたはソフトウエア、あるいはそれらの組み合わせで実行できることに留意する。しかしながら、より好ましい実施の形態では、特に断らない限り、これらの機能はコンピュータや電子データプロセッサのようなプロセッサによって、そのような機能を実行するためにコード化されたコンピュータプログラムコード、ソフトウエア、および／または集積回路にしたがって実行される。
【０００９】
図１は、異なったアーキテクチャをもつプロセッサを含むマルチプロセッサのブロック図を示す。マルチプロセッサ１００は２つのプロセッサ、ＰＵ１０２とＳＰＵ１１０を含む異種混合アーキテクチャである。あるプロセッサで動作するオブジェクトファイルは、他のプロセッサ上では動作しない。そこで、ＰＵ１０２上で動作しているコードが、ＳＰＵ１１０上で動作するように設計されたコードを参照できるようにした。２つのプロセッサＰＵ１０２とＳＰＵ１１０は、データのアクセスの仕方が異なる。ＰＵ１０２は、第１ＤＭＡコントローラ１０６の管理下でシステムメモリ１０８とキャッシュ１０４にアクセスする。ＤＭＡコントローラ１０６は、システムメモリ１０８、キャッシュ１０４、およびＰＵ１０２との間でデータを転送するためのロード命令とストア命令を処理する。システムメモリ１０８との間で移動するデータは、システムバス１１６上で伝送される。
【００１０】
ＳＰＵ１１０は、ロード命令とストア命令によってシステムメモリ１０８をアクセスすることはない。第２ＤＭＡコントローラ１１４は、データをシステムメモリ１０８からローカルストア１１２へ転送し、ＳＰＵ１１０はそこからロードしたりストアすることができる。このＤＭＡコントローラ１１４は、システムバス１１６を介してシステムメモリ１０８に接続されている。
【００１１】
本発明の他の実施の形態では、マルチプロセッサ１００のアーキテクチャが異なる。ある実施の形態では、マルチプロセッサ１００は複数のＰＵ１０２を含み、全てが一つのシステムメモリを共有する。ある実施の形態では、複数のＰＵ１０２は一つのキャッシュを共有する。別の実施の形態では、一つ以上のＰＵのグループがキャッシュを共有する一方、他のＰＵはキャッシュにアクセスしない。ある実施の形態では、複数のＳＰＵが存在する。ある実施の形態では、ＳＰＵ１００はそれ自身で独立したメモリを有する。
【００１２】
図２は、ＥＬＦ形式のオブジェクトコードをラッパーに同封する様子を例示する。ＳＰＵ１１０ルーチン用のＥＬＦ形式のオブジェクトコード２００は、ＥＬＦヘッダ部２０２と、残りの部分である当該ルーチン用のオブジェクトコード２０４とを含む。その残りの部分は、プログラムとデータを含む。オブジェクトコード２００は、ラッパー（包み込み）２１０を加えることによって、ＰＵ１０２のオブジェクトであるオブジェクトコード２０８に変換される。ラッパー２１０は、ＳＰＵ１１０ルーチンと同じ名前をもつＰＵ１０２オブジェクトのシンボル定義を含んでいる。たとえば、ＳＰＵ１１０ルーチンがＢＡＲ−ＳＰＵであるなら、ラッパー２１０はＰＵ１０２オブジェクトであるシンボルＢＡＲ−ＳＰＵを定義している。オブジェクトコード２０８もまた、オブジェクトコード２００をもち、ＥＬＦヘッダ２１２とその残りの部分であるオブジェクトコード２１４を含む。シンボルＢＡＲ−ＳＰＵは、オブジェクトコード２０８内のオブジェクトコード２００へのポインタもしくは参照である。ＳＰＵオブジェクトコード２００は、一つのＳＰＵオブジェクトＢＡＲ−ＳＰＵ．ｏであり、ラップされた（包まれた）コード２０８は、一つのＰＵオブジェクトＢＡＲ−ＳＰＵ−ＰＵ．ｏである。
【００１３】
ラッピング（包み込み）のプロセスによって、異種混合アーキテクチャからの複数のオブジェクトファイルを統合することが可能になる。ＳＰＵ１１０オブジェクトをラッピングすることにより、他の任意のＰＵ１０２オブジェクトとしてリンクしたり、ロードする目的で扱うことができる一つのＰＵ１０２オブジェクトが作られる。実行の間、ラップされたＳＰＵ１１０オブジェクトは、正しく処理される。結果的に、ラッピング処理により、ＰＵ１０２オブジェクトとＳＰＵ１１０オブジェクトの統合が可能になる。
【００１４】
たとえば、ＳＰＵ１１０オブジェクトＢＡＲ−ＳＰＵに対するリファレンスを解決するために、リンカーはＰＵ１０２オブジェクトＢＡＲ−ＳＰＵ−ＰＵ．ｏにリンクする。この方法は、静的および動的リンクと、ＳＰＵ１１０オブジェクトのオブジェクト共有をサポートする。同様に、ラッピングにより任意のＳＰＵ１１０のファイルフォーマットをロードすることが可能になる。ラップされたＰＵオブジェクト２０８がロードされる。さらに、ＰＵ１０２のランタイム参照がＳＰＵ１１０オブジェクトに対してなされる。このＰＵ１０２上のランタイム参照は、ＰＵ１０２オブジェクトＢＡＲ−ＳＰＵ−ＰＵに対するものである。
【００１５】
また、ラッピングはＰＵ１０２オブジェクトの名前空間とＳＰＵ１１０オブジェクトの名前空間の明確な分離を可能にする。ＰＵ１０２上で実行中のコードは、直接的にはＳＰＵ１１０オブジェクトを参照する必要はない。その代わり、ＳＰＵ１１０オブジェクトをラップしてＰＵ１０２オブジェクトを生成し、ＰＵ１０２コードは、ラップされたオブジェクトであるＰＵ１０２オブジェクトを参照する。その結果はＰＵ１０２のプログラム参照のための単純なシンボル関連付け（association）でもある。ＰＵ１０２コードが、ＳＰＵ１１０オブジェクトへのポインタであるＰＵ１０２シンボルを参照する。結果的に、ＰＵ１０２オブジェクトとＳＰＵ１１０オブジェクトをあらかじめリンク（pre-linking）して混合する能力が与えられる。最後に、ラッピングプロセスは、静的および動的両方のニーズのためにライブラリをパッケージングするのに好都合である。
【００１６】
図３は、別のプロセッサからの呼び出しの後、あるプロセッサ上でオブジェクトコードを実行する手順を示すフローチャート３００である。ＰＵ１０２上で実行中のプログラムＦＯＯがＳＰＵ１１０上で動くルーチンＢＡＲを呼び出すと、ＢＡＲへの呼び出しは、ＰＵ１０２オブジェクトＢＡＲ−ＳＰＵ−ＰＵ．ｏへの呼び出しであると解釈される。ステップ３０２において、ラップされたコードＢＡＲ−ＳＰＵ−ＰＵ．ｏがＰＵ１０２上で実行される。その後、ステップ３０４において、ラップされたコードＢＡＲ−ＳＰＵ−ＰＵ．ｏに含まれるＢＡＲ用のＳＰＵオブジェクトコードは、ＳＰＵ１１０のローカルストア１１２にＤＭＡ転送される。ステップ３０６において、ＳＰＵ１１０がそのコードを実行し始める。実行が終了すると、ステップ３０８において、その結果がＰＵ１０２にＤＭＡ転送で戻される。
【００１７】
図４は、ＳＰＵ１１０オブジェクトコードを含むラップされたオブジェクトの生成手順を示すフローチャート４００である。一例として、ＳＰＵ１１０ルーチンは、ＢＡＲという名前をつけられている。ステップ４０２において、ＳＰＵ１１０オブジェクトファイルＢＡＲ−ＳＰＵ．ｏがＥＬＦ形式でＢＡＲ用に作成される。このオブジェクトファイルは、プロセッサＳＰＵ１１０と互換性を持つコンパイラまたはアセンブラで作成される。ステップ４０４において、ＰＵ１０２オブジェクトコードＢＡＲ−ＳＰＵ−ＰＵ．ｏを作成するためにこのコード上にラッパーが配置される。ある実施の形態では、ラッパーを作成するためのシステムツールがマルチプロセッサ１００で利用可能である。ステップ４０６において、システムツールは、ラッパー内でＰＵ１０２シンボルＢＡＲ−ＳＰＵを、ＰＵ１０２オブジェクトＢＡＲ−ＳＰＵ−ＰＵ．ｏ内に含まれるＳＰＵ１１０オブジェクトＢＡＲ−ＳＰＵ．ｏへのポインタとして定義する。いったんＳＰＵ１１０ファイルがＰＵ１０２オブジェクトファイル内に埋め込まれると、それは通常のＰＵ１０２ファイルとして扱うことができ、ステップ４０８において、ユーザーはそれを任意のファイルフォーマット、例えば実行可能なダイナミック共用ライブラリやアーカイブ形式などに変換することができる。
【００１８】
以上、好ましい実施の形態を参照して本発明を説明したが、開示された実施形態は例示であり、何ら限定するものではなく、上記の開示内容には幅広いバリエーション、変形、変更、および置換が考えられること、そして、事例によっては、本発明のいくつかの特徴は、他の特徴を使うことなく利用することもできることに留意する。そのような多くのバリエーションや変形は、当業者が好ましい実施の形態についての上記の説明を再考することにより、望ましいものであるとみなされることもある。したがって、添付の請求項は広く、かつ、本発明の範囲から逸脱することなく解釈されることが適当である。
【図面の簡単な説明】
【００１９】
【図１】異なったアーキテクチャをもつプロセッサを含むマルチプロセッサのブロック図である。
【図２】オブジェクトコードをＥＬＦフォーマットでラッパーに同封する様子を例示する図である。
【図３】別のプロセッサからの呼び出しの後、あるプロセッサ上でオブジェクトコードを実行する手順を示すフローチャートである。
【図４】オブジェクトコードを含むラップされたオブジェクトの生成手順を示すフローチャートである。
【図１】
2008518355.tif 000003
【図２】
2008518355.tif 000004
【図３】
2008518355.tif 000005
【図４】
2008518355.tif 000006
【国際調査報告】
2008518355.tif 000007
2008518355.tif 000008