エンディアン変換のための方法および装置
【課題】バイトオーダ依存コードを逆のバイトオーダ依存アーキテクチャまたはシステム上で実行することのできるコンパイラを提供する。
【解決手段】コンパイラは、コード（例えばソースコード）を分析して、逆のバイトオーダ依存アーキテクチャまたはシステムと互換性を有する「エンディアン中立」ソースコードバージョン等を生成するために、ソースコードの変更が望ましい箇所を示す診断レポートを生成する（１１０）。例えば、プログラマは、ソースコードの特定のコード領域に望ましいバイトオーダを指定することができ、これによりコンパイラは、プログラマがこれら望ましいエンディアン構成を実行するのに必要な変更を行う助けをする。
【解決手段】コンパイラは、コード（例えばソースコード）を分析して、逆のバイトオーダ依存アーキテクチャまたはシステムと互換性を有する「エンディアン中立」ソースコードバージョン等を生成するために、ソースコードの変更が望ましい箇所を示す診断レポートを生成する（１１０）。例えば、プログラマは、ソースコードの特定のコード領域に望ましいバイトオーダを指定することができ、これによりコンパイラは、プログラマがこれら望ましいエンディアン構成を実行するのに必要な変更を行う助けをする。
【発明の詳細な説明】
【背景技術】
【０００１】
バイトエンディアンネスは、データの格納および取得の属性である。ビッグエンディアンデータは、リトルエンディアンデータとは逆のバイトオーダでメモリに格納することができる。リトルエンディアンデータは、最低メモリバイトアドレスに最下位バイトで格納され、ビッグエンディアンデータは、最低メモリバイトアドレスに最上位バイトで格納されてよい。互いに同じ値を有するビッグエンディアン変数およびリトルエンディアン変数は、ＣＰＵレジスタ内では同等であっても、メモリ内では異なるオーダを有する場合がある。
【０００２】
１バイトエンディアンネス変換を用いて書き込まれるソースコードは、別のエンディアンネス変換を利用するプラットフォーム上では、メモリ内にデータが格納されているオーダの差異を認識しないことには実行できない。例えば、プログラムに対して書き込まれる、またはプログラムから読み出されるデータ内におけるエンディアンバイトオーダを維持することが望ましいと思われる。
【０００３】
エンディアン変換は、複数の技術による実行が可能であり、あるエンディアンネス変換で書き込まれたコードを、別のエンディアンネス変換のコンピュータシステムプラットフォームで実行する際に利用することができる。第１の方法としては、プログラマが、手動のエンディアン変換技術を利用して、手動でコードを分析して、バイトオーダ依存性の存在する箇所を検出しようと試みる、というものがある。次にプログラマは、例えばバイトスワップ（エンディアンフリップ）命令を挿入して、特定された依存性を解決しようとする。しかしながら、手動でこれら依存性を有する領域を見つけようとすることは難しい。第２の方法としては、プログラマが、バイエンディアンコンパイラを利用してコード領域のバイトオーダを指定する、というものがある。次段階としては、バイエンディアンコンパイラが、バイトスワップを、逆のバイトオーダのセマンティックスで実行可能なコンパイル済みの実行ファイルに挿入する。しかし、このような専用のコンパイラを利用すると、ソースコードを適用可能なプラットフォームが制限されることが考えられる。第３の方法としては、バイナリ翻訳によって命令をある命令セットから別の命令セットへと動的翻訳して異なるアーキテクチャ用の実行ファイルを実行しながらも、一方ではバイトオーダのセマンティックスを維持する、というものがある。しかしこのような翻訳法は速度が遅く、システム性能に影響を及ぼす。
【図面の簡単な説明】
【０００４】
本発明の実施形態の特徴および利点は、添付請求項、以下の１以上の例示的な実施形態の詳細な説明、および対応する図面により明らかになる。
【図１】本発明の一実施形態における方法のブロック図である。
【図２Ａ】本発明の実施形態における方法の疑似コードを含む。
【図２Ｂ】本発明の実施形態における方法の疑似コードを含む。
【図２Ｃ】本発明の実施形態における方法の疑似コードを含む。
【図３】本発明の一実施形態で利用されるシステムのブロック図である。
【発明を実施するための形態】
【０００５】
以下の記載においては多くの特定の詳細を述べる。しかし、本発明の実施形態はこれら特定の詳細なしに実行可能である。また公知の回路、構造、および技術に関しては詳細に示さないことにより、記載の理解を曖昧にしないようにしている。「一実施形態（one embodiment）（an embodiment）」、「例示的な実施形態（example embodiment）」「様々な実施形態（various embodiments）」およびこれらに類似した表現を用いている場合には、記載されている実施形態が特定の特徴、構造、または特性を有する、ということを示しており、全ての実施形態がこれら特定の特徴、構造、または特性を有する必要があるという意味ではない。さらに、一部の実施形態では、他の実施形態で記載されている特徴の一部または全てを含むこともでき、これら特徴を全く含まないこともできる。さらに、本明細書で利用されている「第１」「第２」「第３」といった言い回しは、共通のオブジェクトを示すのに利用されており、同様のオブジェクトの異なるインスタンスを示している。これら形容詞は、それらが修飾するオブジェクトがある一定の時間的、空間的、ランク上の、あるいはその他のいかなる順序でなければならないと示しているわけではない。
【０００６】
本発明の一実施形態は、バイトオーダ依存コードを逆のバイトオーダ依存アーキテクチャまたはシステム上で実行することのできるコンパイラ等のコードを含む。コンパイラは、コード（例えばソースコード）を分析して、逆のバイトオーダ依存アーキテクチャまたはシステムと互換性を有する「エンディアン中立」ソースコードバージョン等を生成するために、ソースコードの変更が望ましい箇所を示す診断レポートを生成する。例えば、プログラマは、ソースコードの特定のコード領域に望ましいバイトオーダを指定することができ、これによりコンパイラは、プログラマがこれら望ましいエンディアン構成を実行するのに必要な変更を行う助けをすることができる。こうして生成されるソースコードの修正版は、望ましいエンディアン変換のセマンティックスを含むことができ、これは適切なエンディアンフォーマットを含むがコードを適用可能なアーキテクチャを制限するような実行可能コードとは対照的である。さらに本発明の実施形態は、ネーティブの実行可能コードにコンパイルされうるエンディアンスワップ命令をソースコードの修正版に生成することができ、これは、翻訳中に課されるバイトスワップを含む翻訳された実行ファイルよりも速く実行することができる。
【０００７】
明瞭化のために示される例示的な実施形態の多くが、コンパイラ（例えばＣ／Ｃ＋＋コンパイラ）そのソースコードへの適用、および、ビッグエンディアンコンベンションおよびリトルエンディアンコンベンションの間のスワッピングに関した記載となっているが、本発明の実施形態は必ずしもこれに限定されない。例えば、ある実施形態ではコンパイラに含まれた分析ツール等の分析コードが含まれていても、他の実施形態では、静的分析チェックツールに含まれる分析コードが含まれる場合がある。さらに、ここに記載するエンディアン変換は多くの場合バイトスワップ命令との関連で説明されるが、様々な実施形態が必ずしもエンディアン変換を行う、または、促進する目的に、特定の種類の命令を必ず利用しなければならないという意味ではない。
【０００８】
図１は、本発明の一実施形態における方法１００のブロック図である。ブロック１０５で、プログラマはプログラムを用いて、ビッグエンディアンセマンティックスまたはリトルエンディアンセマンティックスのいずれかを有するデータにアクセスを望むソースコードの部分（例えばデータ構造）を指定する。ソースコード部分またはセクションによっては、元はビッグエンディアンとして指定されているがリトルエンディアンへの変換が意図されているもの（この逆もまた然り）がある。またコードセクションによっては、元々ビッグエンディアンとして指定されており、これからもビッグエンディアンである必要があるとして指定されているものもある（その一例はＩＥＴＦ（Internet Engineering Task Force）プロトコルヘッダである）。
【０００９】
例えば、ビッグエンディアンアーキテクチャとして開発されたコード等のコードの部分に対する制約が存在する場合がある。しかしユーザは、そのコードをポートして、リトルエンディアンアーキテクチャ上での実行を望む場合がある。ポートが生じた場合には、リトルエンディアンコンベンションが配置されていると仮定されるライブラリ等の一定のライブラリ（および／またはビッグエンディアンコンベンションが配置されていると仮定される他のライブラリ）を修正されたコードに含めることができる。修正されたコードのこれらライブラリと相互作用する未修正のコードのコード部分は、修正されたコードのエンディアンコンベンションの変化を利用しうるコードとして指定することができる。コード部分は、コードが自身のエンディアンコンベンションを修正されたコードに維持することが望ましいコードとして指定されてよい。従ってプログラマはこれら指定を、例えばコンパイラ言語構造（例えばコマンドライン、プラグマ、および／または、属性）を利用して生成することができる。
【００１０】
ブロック１１０で、コンパイラはシステムプロセッサを利用してソースコードおよびソースコードが指定するコード部分を分析して分析（第１の診断等）を生成し、システムメモリに格納することができる。診断には、例えばプログラマの注意を特定の事項に向けるインストルメントが含まれてよい。診断には、レポート、メッセージ、インジケータ、識別子等が含まれてよい。一実施形態では、診断レポート（ＤＲ１）が、手動のバイトオーダ変換が望ましいコード部分（例えばデータ構造）にフラグを立てたり特定したりすることができる。このようなデータ構造には、例えば、バイトオーダ分析が望ましい異なるサイズのビットフィールドおよび／または異なるサイズのフィールドを有するユニオンが含まれてよい。ＤＲ１を利用する実施形態では、コンパイラが現在様々なユニオンと関連付けているバイトオーダについて文書化しておくことで、開発者がユニオンの「元の」バイトオーダを確認しやすくさせることができる。
【００１１】
ブロック１１５では、プログラマが手動で、ＤＲ１においてハイライトされている部分（例えばデータ構造）を銘々の逆のバイトオーダ表現に変換することができる。本発明の一実施形態では、プログラマは新たな言語構造（例えば属性）をソースコードに追加して、コンパイラがＤＲ１の既に変換された構造（または、既に分析済みではあるがプログラマが変換すると選択しなかった構造）のリストが、将来コンパイルで発行されうるＤＲ１内に作成されないようにすることができる。
【００１２】
図２Ａは、ＤＲ１レポートに関する本発明の一実施形態における疑似コード２０５を含む。ＤＲ１を生成するべく、コンパイラは、ソースコードで定義されている様々なデータ構造に関する情報を格納したシンボルテーブルを作成することができる。シンボルテーブルは、プログラムのコンパイル（またはアセンブル）時に遭遇する全ての識別子、そのプログラムにおける位置、その属性（変数、ルーチン等）のリストを含むことができる。そしてシンボルテーブルに含まれるデータ構造（ｘ）の一部または各々について、その構造が例えばビットフィールドを含む場合であれば、コンパイラはＤＲ１のデータ構造を特定してよい。というのも、ビットフィールドが存在するということは、プログラマには、エンディアンフォーマット問題が潜んでいる可能性が示唆されるからである。別の例としては、データ構造ｘが互いに異なるサイズのフィールドを有するユニオンを含む場合に、コンパイラはＤＲ１のデータ構造を特定してよい。コンパイラはさらに、特定のコード部分が前の反復処理で既に分析済みであるという示唆を探して検索を行うことができる。この場合には、既に分析済みの部分が現在のＤＲ１に記述されていなくてもよい。
【００１３】
図１の参照に戻ると、方法はブロック１２０でブロック１１０に戻り、ＤＲ１にリストされている診断がなくなるまでブロック１１０および１１５を繰り返す。未処理の診断がなくなると（あるいは、診断に対して処理しないという決定が下されると）、ブロック１２５で一実施形態では、ソースコードを分析してさらなる分析を生成する（例えば第２の診断レポート（ＤＲ２））。
【００１４】
ＤＲ２は、バイトオーダ・バウンダリクロシングを生成する結果となるデータに対するコード処理を特定することができる。例えば、リトルエンディアンアーキテクチャ上でバイトオーダ・バウンダリクロシングを生成する条件としては、（ａ）ビッグエンディアン値が、該値に対する算術演算が始まる前にレジスタにロードされた場合、または（ｂ）ビッグエンディアンバイトオーダを有する値を、リトルエンディアンバイトオーダに格納されている変数に割り当てた場合、といったケースが例として挙げられる。加えて、ＤＲ２は、実装ファイル（例えばヘッダファイル）を、ＤＲ２で検出される各タイプの１つの定義といったバイトスワップ関数の定義とともに、含むことができる。
【００１５】
ブロック１３０で、プログラマはＤＲ２およびその定義を利用して、手動で、ＤＲ２で特定された特定の変数タイプに対応するバイトスワップ関数の呼び出しを、ソースコードのこの変数への参照付近の位置に挿入することができる。それは左側が未処理の場合にバイトオーダ・バウンダリクロシングを生じさせる値を、その逆のバイトオーダ表現に変換させる効果を持ちうる。一実施形態では、再度コンパイルが行われると、コンパイラは、正しいバイトスワップ関数を利用している間は、将来のＤＲ２に診断を行わない。
【００１６】
図２Ｂは、ＤＲ２レポートに関する本発明の一実施形態の疑似コード２２５を含む。コンパイラは、アサインメントを含むソースコードの中間言語表現を含む制御フローグラフを作成することができる。そしてコンパイラは、新たなヘッダファイルを作成してこれを開くことができる。中間言語表現のアサインメント（ｘ）の一部または全てについて、コンパイラは以下の処理を行うことができる。例えば、アサインメントの左側のタイプのバイトオーダがアサインメントの右側のタイプのバイトオーダに整合しない場合には、コンパイラはＤＲ２のアサインメント（ｘ）を特定して、問題およびソースコード位置を記述することができる。コンパイラは、オープンヘッダファイルに、バイトスワップ関数を利用する変換関数の定義を追加して、アサインメントの右側のタイプからアサインメントの左側のタイプに変換することができる（例えば、ビッグエンディアンからリトルエンディアンに変換する等）。図１の参照に戻ると、方法はブロック１３５でブロック１２５に戻り、ＤＲ２にリストされている診断がなくなるまでブロック１２５および１３０を繰り返す。全ての診断の処理が終わると（あるいは診断に対して処理しないという決定が下されると）、ブロック１４０で一実施形態では、ソースコードを分析してさらなる分析を生成する（例えば第３の診断レポート（ＤＲ３））。
【００１７】
ＤＲ３は、明示的または暗示的なバイトオーダ変換が存在するときにプログラマに警告を与える診断を含むことができる。例えばＤＲ３診断では、キャストが明示的なバイトオーダ変換を生じるときに、および／または、アサインメントが暗示的なバイトオーダ変換を生じるときに、プログラマに対して警告することができる。
【００１８】
明示的な変換は、プログラマが明示的に例えば以下のようなキャスト式を記述する際に生じる。
{
int beint;
void *p = (void*)&beint; // converts from big-endian int pointer to void pointer
}
【００１９】
ここでソースコードは、１つのエンディアンタイプからボイドポインタへのキャストを含む。明示的な変換の別の例としては、ＤＲ３が、あるデータタイプから別のデータタイプへのプログラマ特定データ変換（例えば、整数から浮動小数点への変換）を含むキャストを含む場合がある。また別の例としては、ソースコードが、互いに異なるサイズのオブジェクトへのポインタを含むユニオンを有する場合が挙げられる。さらにソースコードは、互いに異なるサイズの参照データへキャストするポインタを含むことができる。ＤＲ３にこれらの明示的な変換を記述することができる。
【００２０】
プログラマが、参照されるデータの元のバイトオーダとしてユーザが特定したバイトオーダを不変に保つことを望む場合があってもよい。このような場合にバイトオーダが変更された場合、コンパイラはＤＲ３の診断を生成してよく、診断は例えば手動でバイトスワップの挿入することで言及されてよい。一実施形態では、このユニオンの検出は、ＤＲ１では言及されなくてよい。というのも、このような実施形態におけるＤＲ１は、互いに異なるサイズのフィールドを有するユニオンを取り出す、または特定するが、互いに異なるサイズのデータを指し示すポインタを有するユニオンに関しては取り出す、または特定しないからである。
【００２１】
明示的な変換に対して、暗示的な変換は、あるタイプの値へのポインタが、異なるタイプの値へのポインタを予期する関数に渡される場合に生じる。このコンテキストにおいては、これらデータタイプは、バイトオーダが異なることになる。以下では、ＤＲ３が特定しうる他の暗示的な変換の一部を提起する。暗示的な変換の一例は、上述した明示的な変換に類似しているが、キャスト式を利用しない（例えばvoid *p = &beint; // converts from big-endian int pointer to void pointer）。
【００２２】
ＤＲ３が診断しうる暗示的な変換の別の例としては、ソースコードが、エンディアン中立的に宣言していないフィールドとしてアレイを含むユニオンを含みうる場合が挙げられる。ＤＲ３がプログラマに対してこの点を注意喚起した後で、このアレイを変換して、名前付けされたフィールドに変換して、そのなかの変換をより明示的なものにする。さらにＤＲ３でこのアレイへのアクセスにフラグを立てるが、これは、アレイへのアクセスの正しいオフセットがバイトオーダに依存している場合があることに起因している。一実施形態では、上述したアレイを含むユニオンの検出は、ＤＲ１でパスされて、ＤＲ１で言及されない。
【００２３】
以下は、ＤＲ３で診断されうる暗示的な変換の別の例である。
{
void func(int *be_int);
le_int x;
func(&x);
}
【００２４】
この場合、小さいエンディアン値のアドレスをビッグエンディアンフォーマットのいずれかの上に行うよう予期される関数に渡すことができる。この関数に関しては、値に示されるのはビッグエンディアンであるので、ｘは暗示的に変換されたものであることになる（つまり、変換が暗示的である）。
【００２５】
ＤＲ３が特定する暗示的な変換に関する場合、プログラマは（ブロック１４５で）、暗示的なバイトオーダ変換を有するソースコードを、明示的なバイトオーダ変更を有する修正されたソースコードに変換することができる。プログラマはその後本明細書に記載する技術を適用してコード（例えばバイトスワップ）を挿入して、明示的なバイトオーダ変更を処理することができる。
【００２６】
明示的または暗示的な変換に関する変更は、ＤＲ３が受信され、方法またはその一部が繰り返されて、ＤＲ１、ＤＲ２、および／または、ＤＲ３よりも後のバージョンが生成された後であってよい。しかし一部の実施形態では、一部のレポート（例えばＤＲ１）は、二度とは生成されない場合がある。さらに、一実施形態では、コンパイラが判断を行えない場合であっても、プログラマがある構造を安全であると判断すれば、その構造のＤＲ３診断を抑制することのできる属性またはキャストシーケンスがある場合もある。
【００２７】
図２Ｃは、ＤＲ３レポートに関する本発明の一実施形態の疑似コード２５５を含む。上述した幾らかの例でも提示されたように、診断されたアサインメントが、暗示的な変換が存在していることを示している場合がある。さらに診断されたキャストが、明示的な変換が存在していることを示している場合がある。プログラマは、暗示的な変換を明示的な変換とする選択を行うことができる。さらにプログラマは、修正されたソースコードにおいてプログラマが望むバイト変換により、コードを変換するオプション（例えばバイトスワップオプション）を提示されてよい。
【００２８】
図１の参照に戻ると、方法はブロック１５０でブロック１２５に戻り、ブロック１２５から１４５までを繰り返して、ＤＲ３にリストされている診断が少なくなるまで、またはなくなるまで、修正されたソースコード用にＤＲ２およびＤＲ３を生成する。一部または全ての診断の処理が終わると（あるいは診断に対して処理しないという決定が下されると）、ブロック１５５で方法が終了する。
【００２９】
宣言されたバイトオーダが変更されると、バイトスワップが望ましいポイントは変更されてもよい。故にプログラマは方法１００またはその一部を繰り返し、修正されたソースプログラムに所望の命令（例えばバイトスワップ命令）を組み込むことにより、より高度なものとし、逆のエンディアンコンベンションのシステムで動作可能にすることができる。
【００３０】
従って本発明の実施形態では、コンパイラが自動的にコード（例えばバイトスワップ）を挿入してコードをコンパイルする代わりに、プログラマがコード（例えばバイトスワップ）を挿入する必要がある。これにより、数多くの標準的なコンパイラによるコンパイルが可能なソースコードを生成することができる。本発明の実施形態ではプログラマが一式の定義を記述することができる。その後、コード（コンパイラ）は、（データフローにより）エンディアンフォーマット変更が望ましいこれらの定義と相互作用する一式の値を、ユーザに気づかせる。こうすることでユーザは、効率的にソースコードを修正することができ、様々なアーキテクチャで利用可能な別のバージョンのソースコード等を作成することができるようになる。
【００３１】
実施形態は、数多くの互いに異なるシステムタイプでの実装が可能である。図３は、本発明の一実施形態におけるシステムのブロック図を示す。マルチプロセッサシステム５００はポイントツーポイントインターコネクト５５０であり、ポイントツーポイントインターコネクト５５０を介して連結された第１のプロセッサ５７０および第２のプロセッサ５８０を含む。プロセッサ５７０および５８０の各々はマルチプロセッサであり、第１および第２のプロセッサコア（プロセッサコア５７４ａおよび５７４ｂ並びにプロセッサコア５８４ａおよび５８４ｂ）を含むが、これより多くのコアがプロセッサ内に存在する場合が多い。「プロセッサ」という用語は、レジスタおよび／またはメモリからの電子データを、レジスタおよび／またはメモリに格納可能な他の電子データに処理により変換する任意のデバイスまたはデバイスの一部のことであってよい。
【００３２】
第１のプロセッサ５７０はさらに、メモリコントローラハブ（ＭＣＨ）５７２およびポイントツーポイント（Ｐ−Ｐ）インタフェース５７６および５７８を含む。同様に、第２のプロセッサ５８０はＭＣＨ５８２およびＰ−Ｐインタフェース５８６および５８８を含む。ＭＣＨ５７２および５８２はこれらプロセッサを銘々のメモリ（つまりメモリ５３２およびメモリ５３４）に連結し、これらメモリは、銘々のプロセッサに局所的に接続されるメインメモリ（例えばＤＲＡＭ）の一部であってよい。第１のプロセッサ５７０および第２のプロセッサ５８０は、Ｐ−Ｐインターコネクト５５２および５５４をそれぞれ介してチップセット５９０に連結されてよい。チップセット５９０はＰ−Ｐインタフェース５９４および５９８を含む。
【００３３】
さらにチップセット５９０は、チップセット５９０を高性能グラフィックエンジン５３８にＰ−Ｐインターコネクト５３９により連結するインタフェース５９２を含む。さらにチップセット５９０は、インタフェース５９６を介して第１のバス５１６に連結されてよい。様々な入出力（Ｉ／Ｏ）デバイス５１４が、バスブリッジ５１８とともに、第１のバス５１６に連結されてもよく、バスブリッジ５１８が第１のバス５１６を第２のバス５２０に連結する。一実施形態では、様々なデバイスが第２のバス５２０に連結されてよく、これには例えばキーボード／マウス５２２、通信デバイス５２６、およびコード５３０を含みうるデータ格納ユニット５２８（ディスクドライブその他の大容量格納デバイス等）が含まれる。さらに、オーディオＩ／Ｏ５２４を第２のバス５２０に連結することができる。
【００３４】
実施形態はコードで実装されてよく、システムをプログラムして命令を実行させるのに利用できる命令を格納する格納媒体に格納されてよい。格納媒体は、任意の種類のディスク（例えばフロッピー（登録商標）ディスク、光ディスク、固体ドライブ（ＳＳＤ）、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、および光磁気ディスク、半導体素子（ＲＯＭ、ＤＲＡＭ等のＲＡＭ、エスラム（ＳＲＡＭ）、ＥＰＲＯＭ、フラッシュメモリ、ＥＥＰＲＯＭ（登録商標）、磁気カードまたは光カード））、あるいは電子命令の格納に適した任意のその他の種類の媒体を含む。
【００３５】
本発明の実施形態を命令、関数（function）、プロシージャ、データ構造、アプリケーションプログラム、構成設定、コード等を参照しながら説明してきた。機械がデータにアクセスすると、機械はタスクを行い、抽象的なデータタイプを定義して、低レベルハードウェアコンテキストを構築し、および／または、他の動作を行うことにより応答することができることが本明細書の詳細な記載から明らかであろう。データは揮発性および／または不揮発性データ記憶装置に格納可能である。本開示の主旨においては、「コード」「プログラム」という用語は、アプリケーション、ドライバ、プロセス、ルーチン、方法、モジュール、およびサブプログラムといった、広範なコンポーネントおよび構造を含むことが意図されている。従って「コード」「プログラム」という用語は、処理システムにより実行されることで所望の１つの動作または複数の動作を行う任意の命令集合体のことであってよい。さらに、他の実施形態には、開示された動作全てよりも少ない数の動作、さらなる動作を利用する処理、同じ動作を異なるシーケンスで利用する処理、ここで開示する個々の動作が組み合わせられたり、分割されたり、あるいは変更されたりした結果である処理を含むものもある。
【００３６】
本発明は、限られた数の実施形態を参照しながら記載してきたが、当業者であれば多くの変更例および変形例について想到するであろう。添付請求項は、これら全ての変更例および変形例を本発明の真の精神および範囲内に含めることを意図している。
【背景技術】
【０００１】
バイトエンディアンネスは、データの格納および取得の属性である。ビッグエンディアンデータは、リトルエンディアンデータとは逆のバイトオーダでメモリに格納することができる。リトルエンディアンデータは、最低メモリバイトアドレスに最下位バイトで格納され、ビッグエンディアンデータは、最低メモリバイトアドレスに最上位バイトで格納されてよい。互いに同じ値を有するビッグエンディアン変数およびリトルエンディアン変数は、ＣＰＵレジスタ内では同等であっても、メモリ内では異なるオーダを有する場合がある。
【０００２】
１バイトエンディアンネス変換を用いて書き込まれるソースコードは、別のエンディアンネス変換を利用するプラットフォーム上では、メモリ内にデータが格納されているオーダの差異を認識しないことには実行できない。例えば、プログラムに対して書き込まれる、またはプログラムから読み出されるデータ内におけるエンディアンバイトオーダを維持することが望ましいと思われる。
【０００３】
エンディアン変換は、複数の技術による実行が可能であり、あるエンディアンネス変換で書き込まれたコードを、別のエンディアンネス変換のコンピュータシステムプラットフォームで実行する際に利用することができる。第１の方法としては、プログラマが、手動のエンディアン変換技術を利用して、手動でコードを分析して、バイトオーダ依存性の存在する箇所を検出しようと試みる、というものがある。次にプログラマは、例えばバイトスワップ（エンディアンフリップ）命令を挿入して、特定された依存性を解決しようとする。しかしながら、手動でこれら依存性を有する領域を見つけようとすることは難しい。第２の方法としては、プログラマが、バイエンディアンコンパイラを利用してコード領域のバイトオーダを指定する、というものがある。次段階としては、バイエンディアンコンパイラが、バイトスワップを、逆のバイトオーダのセマンティックスで実行可能なコンパイル済みの実行ファイルに挿入する。しかし、このような専用のコンパイラを利用すると、ソースコードを適用可能なプラットフォームが制限されることが考えられる。第３の方法としては、バイナリ翻訳によって命令をある命令セットから別の命令セットへと動的翻訳して異なるアーキテクチャ用の実行ファイルを実行しながらも、一方ではバイトオーダのセマンティックスを維持する、というものがある。しかしこのような翻訳法は速度が遅く、システム性能に影響を及ぼす。
【図面の簡単な説明】
【０００４】
本発明の実施形態の特徴および利点は、添付請求項、以下の１以上の例示的な実施形態の詳細な説明、および対応する図面により明らかになる。
【図１】本発明の一実施形態における方法のブロック図である。
【図２Ａ】本発明の実施形態における方法の疑似コードを含む。
【図２Ｂ】本発明の実施形態における方法の疑似コードを含む。
【図２Ｃ】本発明の実施形態における方法の疑似コードを含む。
【図３】本発明の一実施形態で利用されるシステムのブロック図である。
【発明を実施するための形態】
【０００５】
以下の記載においては多くの特定の詳細を述べる。しかし、本発明の実施形態はこれら特定の詳細なしに実行可能である。また公知の回路、構造、および技術に関しては詳細に示さないことにより、記載の理解を曖昧にしないようにしている。「一実施形態（one embodiment）（an embodiment）」、「例示的な実施形態（example embodiment）」「様々な実施形態（various embodiments）」およびこれらに類似した表現を用いている場合には、記載されている実施形態が特定の特徴、構造、または特性を有する、ということを示しており、全ての実施形態がこれら特定の特徴、構造、または特性を有する必要があるという意味ではない。さらに、一部の実施形態では、他の実施形態で記載されている特徴の一部または全てを含むこともでき、これら特徴を全く含まないこともできる。さらに、本明細書で利用されている「第１」「第２」「第３」といった言い回しは、共通のオブジェクトを示すのに利用されており、同様のオブジェクトの異なるインスタンスを示している。これら形容詞は、それらが修飾するオブジェクトがある一定の時間的、空間的、ランク上の、あるいはその他のいかなる順序でなければならないと示しているわけではない。
【０００６】
本発明の一実施形態は、バイトオーダ依存コードを逆のバイトオーダ依存アーキテクチャまたはシステム上で実行することのできるコンパイラ等のコードを含む。コンパイラは、コード（例えばソースコード）を分析して、逆のバイトオーダ依存アーキテクチャまたはシステムと互換性を有する「エンディアン中立」ソースコードバージョン等を生成するために、ソースコードの変更が望ましい箇所を示す診断レポートを生成する。例えば、プログラマは、ソースコードの特定のコード領域に望ましいバイトオーダを指定することができ、これによりコンパイラは、プログラマがこれら望ましいエンディアン構成を実行するのに必要な変更を行う助けをすることができる。こうして生成されるソースコードの修正版は、望ましいエンディアン変換のセマンティックスを含むことができ、これは適切なエンディアンフォーマットを含むがコードを適用可能なアーキテクチャを制限するような実行可能コードとは対照的である。さらに本発明の実施形態は、ネーティブの実行可能コードにコンパイルされうるエンディアンスワップ命令をソースコードの修正版に生成することができ、これは、翻訳中に課されるバイトスワップを含む翻訳された実行ファイルよりも速く実行することができる。
【０００７】
明瞭化のために示される例示的な実施形態の多くが、コンパイラ（例えばＣ／Ｃ＋＋コンパイラ）そのソースコードへの適用、および、ビッグエンディアンコンベンションおよびリトルエンディアンコンベンションの間のスワッピングに関した記載となっているが、本発明の実施形態は必ずしもこれに限定されない。例えば、ある実施形態ではコンパイラに含まれた分析ツール等の分析コードが含まれていても、他の実施形態では、静的分析チェックツールに含まれる分析コードが含まれる場合がある。さらに、ここに記載するエンディアン変換は多くの場合バイトスワップ命令との関連で説明されるが、様々な実施形態が必ずしもエンディアン変換を行う、または、促進する目的に、特定の種類の命令を必ず利用しなければならないという意味ではない。
【０００８】
図１は、本発明の一実施形態における方法１００のブロック図である。ブロック１０５で、プログラマはプログラムを用いて、ビッグエンディアンセマンティックスまたはリトルエンディアンセマンティックスのいずれかを有するデータにアクセスを望むソースコードの部分（例えばデータ構造）を指定する。ソースコード部分またはセクションによっては、元はビッグエンディアンとして指定されているがリトルエンディアンへの変換が意図されているもの（この逆もまた然り）がある。またコードセクションによっては、元々ビッグエンディアンとして指定されており、これからもビッグエンディアンである必要があるとして指定されているものもある（その一例はＩＥＴＦ（Internet Engineering Task Force）プロトコルヘッダである）。
【０００９】
例えば、ビッグエンディアンアーキテクチャとして開発されたコード等のコードの部分に対する制約が存在する場合がある。しかしユーザは、そのコードをポートして、リトルエンディアンアーキテクチャ上での実行を望む場合がある。ポートが生じた場合には、リトルエンディアンコンベンションが配置されていると仮定されるライブラリ等の一定のライブラリ（および／またはビッグエンディアンコンベンションが配置されていると仮定される他のライブラリ）を修正されたコードに含めることができる。修正されたコードのこれらライブラリと相互作用する未修正のコードのコード部分は、修正されたコードのエンディアンコンベンションの変化を利用しうるコードとして指定することができる。コード部分は、コードが自身のエンディアンコンベンションを修正されたコードに維持することが望ましいコードとして指定されてよい。従ってプログラマはこれら指定を、例えばコンパイラ言語構造（例えばコマンドライン、プラグマ、および／または、属性）を利用して生成することができる。
【００１０】
ブロック１１０で、コンパイラはシステムプロセッサを利用してソースコードおよびソースコードが指定するコード部分を分析して分析（第１の診断等）を生成し、システムメモリに格納することができる。診断には、例えばプログラマの注意を特定の事項に向けるインストルメントが含まれてよい。診断には、レポート、メッセージ、インジケータ、識別子等が含まれてよい。一実施形態では、診断レポート（ＤＲ１）が、手動のバイトオーダ変換が望ましいコード部分（例えばデータ構造）にフラグを立てたり特定したりすることができる。このようなデータ構造には、例えば、バイトオーダ分析が望ましい異なるサイズのビットフィールドおよび／または異なるサイズのフィールドを有するユニオンが含まれてよい。ＤＲ１を利用する実施形態では、コンパイラが現在様々なユニオンと関連付けているバイトオーダについて文書化しておくことで、開発者がユニオンの「元の」バイトオーダを確認しやすくさせることができる。
【００１１】
ブロック１１５では、プログラマが手動で、ＤＲ１においてハイライトされている部分（例えばデータ構造）を銘々の逆のバイトオーダ表現に変換することができる。本発明の一実施形態では、プログラマは新たな言語構造（例えば属性）をソースコードに追加して、コンパイラがＤＲ１の既に変換された構造（または、既に分析済みではあるがプログラマが変換すると選択しなかった構造）のリストが、将来コンパイルで発行されうるＤＲ１内に作成されないようにすることができる。
【００１２】
図２Ａは、ＤＲ１レポートに関する本発明の一実施形態における疑似コード２０５を含む。ＤＲ１を生成するべく、コンパイラは、ソースコードで定義されている様々なデータ構造に関する情報を格納したシンボルテーブルを作成することができる。シンボルテーブルは、プログラムのコンパイル（またはアセンブル）時に遭遇する全ての識別子、そのプログラムにおける位置、その属性（変数、ルーチン等）のリストを含むことができる。そしてシンボルテーブルに含まれるデータ構造（ｘ）の一部または各々について、その構造が例えばビットフィールドを含む場合であれば、コンパイラはＤＲ１のデータ構造を特定してよい。というのも、ビットフィールドが存在するということは、プログラマには、エンディアンフォーマット問題が潜んでいる可能性が示唆されるからである。別の例としては、データ構造ｘが互いに異なるサイズのフィールドを有するユニオンを含む場合に、コンパイラはＤＲ１のデータ構造を特定してよい。コンパイラはさらに、特定のコード部分が前の反復処理で既に分析済みであるという示唆を探して検索を行うことができる。この場合には、既に分析済みの部分が現在のＤＲ１に記述されていなくてもよい。
【００１３】
図１の参照に戻ると、方法はブロック１２０でブロック１１０に戻り、ＤＲ１にリストされている診断がなくなるまでブロック１１０および１１５を繰り返す。未処理の診断がなくなると（あるいは、診断に対して処理しないという決定が下されると）、ブロック１２５で一実施形態では、ソースコードを分析してさらなる分析を生成する（例えば第２の診断レポート（ＤＲ２））。
【００１４】
ＤＲ２は、バイトオーダ・バウンダリクロシングを生成する結果となるデータに対するコード処理を特定することができる。例えば、リトルエンディアンアーキテクチャ上でバイトオーダ・バウンダリクロシングを生成する条件としては、（ａ）ビッグエンディアン値が、該値に対する算術演算が始まる前にレジスタにロードされた場合、または（ｂ）ビッグエンディアンバイトオーダを有する値を、リトルエンディアンバイトオーダに格納されている変数に割り当てた場合、といったケースが例として挙げられる。加えて、ＤＲ２は、実装ファイル（例えばヘッダファイル）を、ＤＲ２で検出される各タイプの１つの定義といったバイトスワップ関数の定義とともに、含むことができる。
【００１５】
ブロック１３０で、プログラマはＤＲ２およびその定義を利用して、手動で、ＤＲ２で特定された特定の変数タイプに対応するバイトスワップ関数の呼び出しを、ソースコードのこの変数への参照付近の位置に挿入することができる。それは左側が未処理の場合にバイトオーダ・バウンダリクロシングを生じさせる値を、その逆のバイトオーダ表現に変換させる効果を持ちうる。一実施形態では、再度コンパイルが行われると、コンパイラは、正しいバイトスワップ関数を利用している間は、将来のＤＲ２に診断を行わない。
【００１６】
図２Ｂは、ＤＲ２レポートに関する本発明の一実施形態の疑似コード２２５を含む。コンパイラは、アサインメントを含むソースコードの中間言語表現を含む制御フローグラフを作成することができる。そしてコンパイラは、新たなヘッダファイルを作成してこれを開くことができる。中間言語表現のアサインメント（ｘ）の一部または全てについて、コンパイラは以下の処理を行うことができる。例えば、アサインメントの左側のタイプのバイトオーダがアサインメントの右側のタイプのバイトオーダに整合しない場合には、コンパイラはＤＲ２のアサインメント（ｘ）を特定して、問題およびソースコード位置を記述することができる。コンパイラは、オープンヘッダファイルに、バイトスワップ関数を利用する変換関数の定義を追加して、アサインメントの右側のタイプからアサインメントの左側のタイプに変換することができる（例えば、ビッグエンディアンからリトルエンディアンに変換する等）。図１の参照に戻ると、方法はブロック１３５でブロック１２５に戻り、ＤＲ２にリストされている診断がなくなるまでブロック１２５および１３０を繰り返す。全ての診断の処理が終わると（あるいは診断に対して処理しないという決定が下されると）、ブロック１４０で一実施形態では、ソースコードを分析してさらなる分析を生成する（例えば第３の診断レポート（ＤＲ３））。
【００１７】
ＤＲ３は、明示的または暗示的なバイトオーダ変換が存在するときにプログラマに警告を与える診断を含むことができる。例えばＤＲ３診断では、キャストが明示的なバイトオーダ変換を生じるときに、および／または、アサインメントが暗示的なバイトオーダ変換を生じるときに、プログラマに対して警告することができる。
【００１８】
明示的な変換は、プログラマが明示的に例えば以下のようなキャスト式を記述する際に生じる。
{
int beint;
void *p = (void*)&beint; // converts from big-endian int pointer to void pointer
}
【００１９】
ここでソースコードは、１つのエンディアンタイプからボイドポインタへのキャストを含む。明示的な変換の別の例としては、ＤＲ３が、あるデータタイプから別のデータタイプへのプログラマ特定データ変換（例えば、整数から浮動小数点への変換）を含むキャストを含む場合がある。また別の例としては、ソースコードが、互いに異なるサイズのオブジェクトへのポインタを含むユニオンを有する場合が挙げられる。さらにソースコードは、互いに異なるサイズの参照データへキャストするポインタを含むことができる。ＤＲ３にこれらの明示的な変換を記述することができる。
【００２０】
プログラマが、参照されるデータの元のバイトオーダとしてユーザが特定したバイトオーダを不変に保つことを望む場合があってもよい。このような場合にバイトオーダが変更された場合、コンパイラはＤＲ３の診断を生成してよく、診断は例えば手動でバイトスワップの挿入することで言及されてよい。一実施形態では、このユニオンの検出は、ＤＲ１では言及されなくてよい。というのも、このような実施形態におけるＤＲ１は、互いに異なるサイズのフィールドを有するユニオンを取り出す、または特定するが、互いに異なるサイズのデータを指し示すポインタを有するユニオンに関しては取り出す、または特定しないからである。
【００２１】
明示的な変換に対して、暗示的な変換は、あるタイプの値へのポインタが、異なるタイプの値へのポインタを予期する関数に渡される場合に生じる。このコンテキストにおいては、これらデータタイプは、バイトオーダが異なることになる。以下では、ＤＲ３が特定しうる他の暗示的な変換の一部を提起する。暗示的な変換の一例は、上述した明示的な変換に類似しているが、キャスト式を利用しない（例えばvoid *p = &beint; // converts from big-endian int pointer to void pointer）。
【００２２】
ＤＲ３が診断しうる暗示的な変換の別の例としては、ソースコードが、エンディアン中立的に宣言していないフィールドとしてアレイを含むユニオンを含みうる場合が挙げられる。ＤＲ３がプログラマに対してこの点を注意喚起した後で、このアレイを変換して、名前付けされたフィールドに変換して、そのなかの変換をより明示的なものにする。さらにＤＲ３でこのアレイへのアクセスにフラグを立てるが、これは、アレイへのアクセスの正しいオフセットがバイトオーダに依存している場合があることに起因している。一実施形態では、上述したアレイを含むユニオンの検出は、ＤＲ１でパスされて、ＤＲ１で言及されない。
【００２３】
以下は、ＤＲ３で診断されうる暗示的な変換の別の例である。
{
void func(int *be_int);
le_int x;
func(&x);
}
【００２４】
この場合、小さいエンディアン値のアドレスをビッグエンディアンフォーマットのいずれかの上に行うよう予期される関数に渡すことができる。この関数に関しては、値に示されるのはビッグエンディアンであるので、ｘは暗示的に変換されたものであることになる（つまり、変換が暗示的である）。
【００２５】
ＤＲ３が特定する暗示的な変換に関する場合、プログラマは（ブロック１４５で）、暗示的なバイトオーダ変換を有するソースコードを、明示的なバイトオーダ変更を有する修正されたソースコードに変換することができる。プログラマはその後本明細書に記載する技術を適用してコード（例えばバイトスワップ）を挿入して、明示的なバイトオーダ変更を処理することができる。
【００２６】
明示的または暗示的な変換に関する変更は、ＤＲ３が受信され、方法またはその一部が繰り返されて、ＤＲ１、ＤＲ２、および／または、ＤＲ３よりも後のバージョンが生成された後であってよい。しかし一部の実施形態では、一部のレポート（例えばＤＲ１）は、二度とは生成されない場合がある。さらに、一実施形態では、コンパイラが判断を行えない場合であっても、プログラマがある構造を安全であると判断すれば、その構造のＤＲ３診断を抑制することのできる属性またはキャストシーケンスがある場合もある。
【００２７】
図２Ｃは、ＤＲ３レポートに関する本発明の一実施形態の疑似コード２５５を含む。上述した幾らかの例でも提示されたように、診断されたアサインメントが、暗示的な変換が存在していることを示している場合がある。さらに診断されたキャストが、明示的な変換が存在していることを示している場合がある。プログラマは、暗示的な変換を明示的な変換とする選択を行うことができる。さらにプログラマは、修正されたソースコードにおいてプログラマが望むバイト変換により、コードを変換するオプション（例えばバイトスワップオプション）を提示されてよい。
【００２８】
図１の参照に戻ると、方法はブロック１５０でブロック１２５に戻り、ブロック１２５から１４５までを繰り返して、ＤＲ３にリストされている診断が少なくなるまで、またはなくなるまで、修正されたソースコード用にＤＲ２およびＤＲ３を生成する。一部または全ての診断の処理が終わると（あるいは診断に対して処理しないという決定が下されると）、ブロック１５５で方法が終了する。
【００２９】
宣言されたバイトオーダが変更されると、バイトスワップが望ましいポイントは変更されてもよい。故にプログラマは方法１００またはその一部を繰り返し、修正されたソースプログラムに所望の命令（例えばバイトスワップ命令）を組み込むことにより、より高度なものとし、逆のエンディアンコンベンションのシステムで動作可能にすることができる。
【００３０】
従って本発明の実施形態では、コンパイラが自動的にコード（例えばバイトスワップ）を挿入してコードをコンパイルする代わりに、プログラマがコード（例えばバイトスワップ）を挿入する必要がある。これにより、数多くの標準的なコンパイラによるコンパイルが可能なソースコードを生成することができる。本発明の実施形態ではプログラマが一式の定義を記述することができる。その後、コード（コンパイラ）は、（データフローにより）エンディアンフォーマット変更が望ましいこれらの定義と相互作用する一式の値を、ユーザに気づかせる。こうすることでユーザは、効率的にソースコードを修正することができ、様々なアーキテクチャで利用可能な別のバージョンのソースコード等を作成することができるようになる。
【００３１】
実施形態は、数多くの互いに異なるシステムタイプでの実装が可能である。図３は、本発明の一実施形態におけるシステムのブロック図を示す。マルチプロセッサシステム５００はポイントツーポイントインターコネクト５５０であり、ポイントツーポイントインターコネクト５５０を介して連結された第１のプロセッサ５７０および第２のプロセッサ５８０を含む。プロセッサ５７０および５８０の各々はマルチプロセッサであり、第１および第２のプロセッサコア（プロセッサコア５７４ａおよび５７４ｂ並びにプロセッサコア５８４ａおよび５８４ｂ）を含むが、これより多くのコアがプロセッサ内に存在する場合が多い。「プロセッサ」という用語は、レジスタおよび／またはメモリからの電子データを、レジスタおよび／またはメモリに格納可能な他の電子データに処理により変換する任意のデバイスまたはデバイスの一部のことであってよい。
【００３２】
第１のプロセッサ５７０はさらに、メモリコントローラハブ（ＭＣＨ）５７２およびポイントツーポイント（Ｐ−Ｐ）インタフェース５７６および５７８を含む。同様に、第２のプロセッサ５８０はＭＣＨ５８２およびＰ−Ｐインタフェース５８６および５８８を含む。ＭＣＨ５７２および５８２はこれらプロセッサを銘々のメモリ（つまりメモリ５３２およびメモリ５３４）に連結し、これらメモリは、銘々のプロセッサに局所的に接続されるメインメモリ（例えばＤＲＡＭ）の一部であってよい。第１のプロセッサ５７０および第２のプロセッサ５８０は、Ｐ−Ｐインターコネクト５５２および５５４をそれぞれ介してチップセット５９０に連結されてよい。チップセット５９０はＰ−Ｐインタフェース５９４および５９８を含む。
【００３３】
さらにチップセット５９０は、チップセット５９０を高性能グラフィックエンジン５３８にＰ−Ｐインターコネクト５３９により連結するインタフェース５９２を含む。さらにチップセット５９０は、インタフェース５９６を介して第１のバス５１６に連結されてよい。様々な入出力（Ｉ／Ｏ）デバイス５１４が、バスブリッジ５１８とともに、第１のバス５１６に連結されてもよく、バスブリッジ５１８が第１のバス５１６を第２のバス５２０に連結する。一実施形態では、様々なデバイスが第２のバス５２０に連結されてよく、これには例えばキーボード／マウス５２２、通信デバイス５２６、およびコード５３０を含みうるデータ格納ユニット５２８（ディスクドライブその他の大容量格納デバイス等）が含まれる。さらに、オーディオＩ／Ｏ５２４を第２のバス５２０に連結することができる。
【００３４】
実施形態はコードで実装されてよく、システムをプログラムして命令を実行させるのに利用できる命令を格納する格納媒体に格納されてよい。格納媒体は、任意の種類のディスク（例えばフロッピー（登録商標）ディスク、光ディスク、固体ドライブ（ＳＳＤ）、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、および光磁気ディスク、半導体素子（ＲＯＭ、ＤＲＡＭ等のＲＡＭ、エスラム（ＳＲＡＭ）、ＥＰＲＯＭ、フラッシュメモリ、ＥＥＰＲＯＭ（登録商標）、磁気カードまたは光カード））、あるいは電子命令の格納に適した任意のその他の種類の媒体を含む。
【００３５】
本発明の実施形態を命令、関数（function）、プロシージャ、データ構造、アプリケーションプログラム、構成設定、コード等を参照しながら説明してきた。機械がデータにアクセスすると、機械はタスクを行い、抽象的なデータタイプを定義して、低レベルハードウェアコンテキストを構築し、および／または、他の動作を行うことにより応答することができることが本明細書の詳細な記載から明らかであろう。データは揮発性および／または不揮発性データ記憶装置に格納可能である。本開示の主旨においては、「コード」「プログラム」という用語は、アプリケーション、ドライバ、プロセス、ルーチン、方法、モジュール、およびサブプログラムといった、広範なコンポーネントおよび構造を含むことが意図されている。従って「コード」「プログラム」という用語は、処理システムにより実行されることで所望の１つの動作または複数の動作を行う任意の命令集合体のことであってよい。さらに、他の実施形態には、開示された動作全てよりも少ない数の動作、さらなる動作を利用する処理、同じ動作を異なるシーケンスで利用する処理、ここで開示する個々の動作が組み合わせられたり、分割されたり、あるいは変更されたりした結果である処理を含むものもある。
【００３６】
本発明は、限られた数の実施形態を参照しながら記載してきたが、当業者であれば多くの変更例および変形例について想到するであろう。添付請求項は、これら全ての変更例および変形例を本発明の真の精神および範囲内に含めることを意図している。
【特許請求の範囲】
【請求項１】
第１のソースコード部分について第１のエンディアンフォーマットを指定し、かつ、第２のソースコード部分について第２のエンディアンフォーマットを指定する段階と、
メモリに連結されているプロセッサを利用して、前記第１のソースコード部分の前記指定に応じて実行されると、前記第１のソースコード部分がバイトオーダ・バウンダリクロシングを生成するか否かの判断に基づいて第１の診断を生成する段階と、
前記第２のソースコード部分の前記指定に応じて実行されると、前記第２のソースコード部分が暗示的なバイトオーダ変換を生成するか否かの判断に基づいて第２の診断を生成する段階と、
前記第１の診断および前記第２の診断を前記メモリに格納する段階と
を備える方法。
【請求項２】
第３のソースコード部分が、ビットフィールドおよび互いに異なるサイズのフィールドを含むユニオンのいずれかを含むかについての判断に基づいて第３の診断を生成する段階と、
前記第３の診断を前記メモリに格納する段階とを備える請求項１に記載の方法。
【請求項３】
エンディアンフォーマットを有する値を、逆のエンディアンフォーマットを有する変数に割り当てるコードを含む前記第１のソースコード部分に基づいて実行されると、前記第１のソースコード部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断する段階を備える請求項１に記載の方法。
【請求項４】
キャスト命令を利用せずにエンディアン変換を行うコードを含む前記第２のソースコード部分に基づいて実行されると、前記第２のソースコード部分が暗示的なバイトオーダ変換を生成するか否かを判断する段階を備える請求項１に記載の方法。
【請求項５】
ユニオンを含む前記第２のソースコード部分に基づいて実行されると、前記第２のソースコード部分が暗示的なバイトオーダ変換を生成するか否かを判断する段階を備える請求項１に記載の方法。
【請求項６】
前記第２のソースコード部分の前記指定に基づいて実行されると、前記第２のソースコード部分が明示的なバイトオーダ変換を生成するか否かを判断する段階を備える請求項１に記載の方法。
【請求項７】
キャスト命令を含む前記第２のソースコード部分に基づいて実行されると、前記第２のソースコード部分が明示的なバイトオーダ変換を生成するか否かを判断する段階を備える請求項６に記載の方法。
【請求項８】
前記第１の診断および前記第２の診断に基づいて、修正されたソースコードを生成する段階を備え、
前記第１のエンディアンコンベンションは前記第２のエンディアンコンベンションの逆である請求項１に記載の方法。
【請求項９】
命令を有する媒体を備える物品であって、前記命令はプロセッサベースのシステムに、
実行されるとソースコードの第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断させ、
実行されると前記ソースコードの第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断させ、
実行されると前記第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かの判断に基づいて第１の診断レポートを生成させ、
実行されると前記第２の部分が暗示的なバイトオーダ変換を生成するか否かの判断に基づいて第２の診断レポートを生成させる物品。
【請求項１０】
前記プロセッサベースのシステムに、前記ソースコードの第３の部分が、ビットフィールドおよび互いに異なるサイズのフィールドを含むユニオンのいずれかを含むかについての判断に基づいて第３の診断レポートを生成させる命令をさらに備える請求項９に記載の物品。
【請求項１１】
前記プロセッサベースのシステムに、エンディアンフォーマットを有する値を、逆のエンディアンフォーマットを有する変数に割り当てるコードを含む前記第１の部分に基づいて実行されると、前記第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断させる命令をさらに備える請求項９に記載の物品。
【請求項１２】
前記プロセッサベースのシステムに、キャスト命令を利用せずにエンディアン変換を行うコードを含む前記第２の部分に基づいて実行されると、前記第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断させる命令をさらに備える請求項９に記載の物品。
【請求項１３】
前記プロセッサベースのシステムに、エンディアン変換を行わせるユニオンを含む前記第２の部分に基づいて実行されると、前記第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断させる命令をさらに備える請求項９に記載の物品。
【請求項１４】
前記プロセッサベースのシステムに、前記第２の部分の指定に基づいて実行されると、前記第２の部分が明示的なバイトオーダ変換を生成するか否かを判断させる命令をさらに備え、前記レポートにはプロンプトが含まれる請求項９に記載の物品。
【請求項１５】
前記プロセッサベースのシステムに、キャスト命令を含む前記第２の部分に基づいて実行されると、前記第２の部分が明示的なバイトオーダ変換を生成するか否かを判断させる命令をさらに備える請求項９に記載の物品。
【請求項１６】
前記プロセッサベースのシステムに、前記第１の診断レポートおよび前記第２の診断レポートを実行不可能な形式で生成させる命令をさらに備える請求項９に記載の物品。
【請求項１７】
プロセッサを備える装置であって、
前記プロセッサは、第１のメモリに連結され、（１）実行されるとソースコードの第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断し、（２）実行されると前記ソースコードの第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断し、（３）実行されると前記第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かの判断に基づいて第１の診断を生成し、（４）実行されると前記第２の部分が暗示的なバイトオーダ変換を生成するか否かの判断に基づいて第２の診断を生成する装置。
【請求項１８】
前記プロセッサは、前記ソースコードの第３の部分が、ビットフィールドおよびユニオンのいずれかを含むかについての判断に基づいて第３の診断を生成する請求項１７に記載の装置。
【請求項１９】
前記プロセッサは、第１のエンディアンフォーマットの値を、前記第１のエンディアンフォーマットとは逆の第２のエンディアンフォーマットを有する変数に割り当てるコードを含む前記第１の部分に基づいて実行されると、前記第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断する請求項１７に記載の装置。
【請求項２０】
前記プロセッサは、キャスト命令を利用せずにエンディアン変換を行うコードを含む前記第２の部分に基づいて実行されると、前記第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断する請求項１７に記載の装置。
【請求項１】
第１のソースコード部分について第１のエンディアンフォーマットを指定し、かつ、第２のソースコード部分について第２のエンディアンフォーマットを指定する段階と、
メモリに連結されているプロセッサを利用して、前記第１のソースコード部分の前記指定に応じて実行されると、前記第１のソースコード部分がバイトオーダ・バウンダリクロシングを生成するか否かの判断に基づいて第１の診断を生成する段階と、
前記第２のソースコード部分の前記指定に応じて実行されると、前記第２のソースコード部分が暗示的なバイトオーダ変換を生成するか否かの判断に基づいて第２の診断を生成する段階と、
前記第１の診断および前記第２の診断を前記メモリに格納する段階と
を備える方法。
【請求項２】
第３のソースコード部分が、ビットフィールドおよび互いに異なるサイズのフィールドを含むユニオンのいずれかを含むかについての判断に基づいて第３の診断を生成する段階と、
前記第３の診断を前記メモリに格納する段階とを備える請求項１に記載の方法。
【請求項３】
エンディアンフォーマットを有する値を、逆のエンディアンフォーマットを有する変数に割り当てるコードを含む前記第１のソースコード部分に基づいて実行されると、前記第１のソースコード部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断する段階を備える請求項１に記載の方法。
【請求項４】
キャスト命令を利用せずにエンディアン変換を行うコードを含む前記第２のソースコード部分に基づいて実行されると、前記第２のソースコード部分が暗示的なバイトオーダ変換を生成するか否かを判断する段階を備える請求項１に記載の方法。
【請求項５】
ユニオンを含む前記第２のソースコード部分に基づいて実行されると、前記第２のソースコード部分が暗示的なバイトオーダ変換を生成するか否かを判断する段階を備える請求項１に記載の方法。
【請求項６】
前記第２のソースコード部分の前記指定に基づいて実行されると、前記第２のソースコード部分が明示的なバイトオーダ変換を生成するか否かを判断する段階を備える請求項１に記載の方法。
【請求項７】
キャスト命令を含む前記第２のソースコード部分に基づいて実行されると、前記第２のソースコード部分が明示的なバイトオーダ変換を生成するか否かを判断する段階を備える請求項６に記載の方法。
【請求項８】
前記第１の診断および前記第２の診断に基づいて、修正されたソースコードを生成する段階を備え、
前記第１のエンディアンコンベンションは前記第２のエンディアンコンベンションの逆である請求項１に記載の方法。
【請求項９】
命令を有する媒体を備える物品であって、前記命令はプロセッサベースのシステムに、
実行されるとソースコードの第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断させ、
実行されると前記ソースコードの第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断させ、
実行されると前記第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かの判断に基づいて第１の診断レポートを生成させ、
実行されると前記第２の部分が暗示的なバイトオーダ変換を生成するか否かの判断に基づいて第２の診断レポートを生成させる物品。
【請求項１０】
前記プロセッサベースのシステムに、前記ソースコードの第３の部分が、ビットフィールドおよび互いに異なるサイズのフィールドを含むユニオンのいずれかを含むかについての判断に基づいて第３の診断レポートを生成させる命令をさらに備える請求項９に記載の物品。
【請求項１１】
前記プロセッサベースのシステムに、エンディアンフォーマットを有する値を、逆のエンディアンフォーマットを有する変数に割り当てるコードを含む前記第１の部分に基づいて実行されると、前記第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断させる命令をさらに備える請求項９に記載の物品。
【請求項１２】
前記プロセッサベースのシステムに、キャスト命令を利用せずにエンディアン変換を行うコードを含む前記第２の部分に基づいて実行されると、前記第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断させる命令をさらに備える請求項９に記載の物品。
【請求項１３】
前記プロセッサベースのシステムに、エンディアン変換を行わせるユニオンを含む前記第２の部分に基づいて実行されると、前記第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断させる命令をさらに備える請求項９に記載の物品。
【請求項１４】
前記プロセッサベースのシステムに、前記第２の部分の指定に基づいて実行されると、前記第２の部分が明示的なバイトオーダ変換を生成するか否かを判断させる命令をさらに備え、前記レポートにはプロンプトが含まれる請求項９に記載の物品。
【請求項１５】
前記プロセッサベースのシステムに、キャスト命令を含む前記第２の部分に基づいて実行されると、前記第２の部分が明示的なバイトオーダ変換を生成するか否かを判断させる命令をさらに備える請求項９に記載の物品。
【請求項１６】
前記プロセッサベースのシステムに、前記第１の診断レポートおよび前記第２の診断レポートを実行不可能な形式で生成させる命令をさらに備える請求項９に記載の物品。
【請求項１７】
プロセッサを備える装置であって、
前記プロセッサは、第１のメモリに連結され、（１）実行されるとソースコードの第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断し、（２）実行されると前記ソースコードの第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断し、（３）実行されると前記第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かの判断に基づいて第１の診断を生成し、（４）実行されると前記第２の部分が暗示的なバイトオーダ変換を生成するか否かの判断に基づいて第２の診断を生成する装置。
【請求項１８】
前記プロセッサは、前記ソースコードの第３の部分が、ビットフィールドおよびユニオンのいずれかを含むかについての判断に基づいて第３の診断を生成する請求項１７に記載の装置。
【請求項１９】
前記プロセッサは、第１のエンディアンフォーマットの値を、前記第１のエンディアンフォーマットとは逆の第２のエンディアンフォーマットを有する変数に割り当てるコードを含む前記第１の部分に基づいて実行されると、前記第１の部分がバイトオーダ・バウンダリクロシングを生成するか否かを判断する請求項１７に記載の装置。
【請求項２０】
前記プロセッサは、キャスト命令を利用せずにエンディアン変換を行うコードを含む前記第２の部分に基づいて実行されると、前記第２の部分が暗示的なバイトオーダ変換を生成するか否かを判断する請求項１７に記載の装置。
【図１】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図３】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図３】
【公開番号】特開２０１１−１２９１０２（Ｐ２０１１−１２９１０２Ａ）
【公開日】平成２３年６月３０日（２０１１．６．３０）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−２４７１２３（Ｐ２０１０−２４７１２３）
【出願日】平成２２年１１月４日（２０１０．１１．４）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
【公開日】平成２３年６月３０日（２０１１．６．３０）
【国際特許分類】
【出願番号】特願２０１０−２４７１２３（Ｐ２０１０−２４７１２３）
【出願日】平成２２年１１月４日（２０１０．１１．４）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
[ Back to top ]