JP7315872B2 - プロセッサ、シミュレータプログラム、アセンブラプログラム、及び情報処理プログラム - Google Patents

プロセッサ、シミュレータプログラム、アセンブラプログラム、及び情報処理プログラム Download PDF

Info

Publication number
JP7315872B2
JP7315872B2 JP2021572135A JP2021572135A JP7315872B2 JP 7315872 B2 JP7315872 B2 JP 7315872B2 JP 2021572135 A JP2021572135 A JP 2021572135A JP 2021572135 A JP2021572135 A JP 2021572135A JP 7315872 B2 JP7315872 B2 JP 7315872B2
Authority
JP
Japan
Prior art keywords
register
instruction
exception
data
registers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021572135A
Other languages
English (en)
Other versions
JPWO2021149113A5 (ja
JPWO2021149113A1 (ja
Inventor
健太郎 川上
康志 栗原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2021149113A1 publication Critical patent/JPWO2021149113A1/ja
Publication of JPWO2021149113A5 publication Critical patent/JPWO2021149113A5/ja
Application granted granted Critical
Publication of JP7315872B2 publication Critical patent/JP7315872B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30101—Special purpose registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30094—Condition code generation, e.g. Carry, Zero flag
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Complex Calculations (AREA)

Description

本発明は、プロセッサ、シミュレータプログラム、アセンブラプログラム、及び情報処理プログラムに関する。
コンパイラがソースプログラムから生成したアセンブリ言語のコードには、プログラムの実行結果に影響を与えない不要な命令が含まれることがある。そのような命令はプログラムの実行速度を低下させてしまい、プロセッサの性能を限界まで引き出すのを阻む要因となる。また、コンパイラの最適化機能には限界があるため、複雑な処理が記述されたソースプログラムをコンパイルして得られた実行可能プログラムは、人手によって最適化がなされたアセンブリ言語のコードよりも実行速度が遅いケースがある。
そのため、プログラムの実行速度の高速化が求められるHPC(High Performance Computing)等の分野においては、そのプログラムに適したアセンブリ言語のコードを開発者が手作業で記述することがある。
しかし、C言語やC++等の高級言語と比較してアセンブリ言語は抽象度が低いため記述ミスが発生し易く、更にプログラムのどこに記述ミスがあるのかを発見し難い。
特開平５－１４３３３８号公報
一側面によれば、プログラムの記述ミスに起因した例外を検出することを目的とする。
一側面によれば、第１のレジスタと、前記第１のレジスタに係るステータス情報を格納する第２のレジスタと、前記第２のレジスタに格納されている前記ステータス情報に基づいて、前記第１のレジスタがオペランドに指定された命令における例外を検出する検出回路とを有し、前記ステータス情報は、前記命令の実行前に前記第１のレジスタが書き込み先のレジスタとして使用済みかどうかを示す第１のフラグと、前記命令の実行前に前記第１のレジスタが読み出し元のレジスタとして使用済みかどうかを示す第２のフラグとを有し、前記検出回路は、前記第１のレジスタが書き込み先のレジスタとして使用済みであることを前記第１のフラグが示しており、かつ前記第１のレジスタが読み出し元のレジスタとして使用済みではないことを前記第２のフラグが示している場合に前記例外を検出するプロセッサが提供される。
一側面によれば、プログラムの記述ミスに起因した例外を検出することが可能となる。
図１（ａ）は、プロセッサに設けられた汎用レジスタの模式図であり、図１（ｂ）は、プロセッサに設けられたベクトルレジスタの模式図である。 図２は、１２８ビット長のベクトルレジスタを指定するアセンブリ言語の書式を示す模式図である。 図３（ａ）、（ｂ）は、ベクトルレジスタを用いたアセンブリ言語の文法について示す模式図（その１）である。 図４（ａ）、（ｂ）は、ベクトルレジスタを用いたアセンブリ言語の文法について示す模式図（その２）である。 図５は、ベクトルレジスタを用いたアセンブリ言語の文法について示す模式図（その３）である。 図６（ａ）、（ｂ）は、汎用レジスタを用いたアセンブリ言語の文法について示す模式図である。 図７は、開発者が記述したアセンブリ言語のソースコードの正しいコーディング例を示す模式図である。 図８は、第１例に係る記述ミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。 図９は、ベクトルレジスタをオペランドに指定したときの第１例に係る記述ミスの例について説明するためのアセンブリ言語のソースコードを示す模式図である。 図１０は、第２例に係るミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。 図１１は、第３例に係るミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。 図１２は、第４例に係る記述ミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。 図１３は、第５例に係る記述ミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。 図１４は、第１例～第５例に係る記述ミスをまとめた図である。 図１５は、第１実施形態に係るプロセッサの構成図である。 図１６は、第１実施形態に係るステータスレジスタファイルと演算用レジスタファイルの各々の模式図である。 図１７は、第１実施形態に係る第２の例外検出部が例外を検出するときの検出ルールを模式的に示す図である。 図１８は、第１実施形態に係る第２の例外検出部のブロック図である。 図１９は、第１実施形態に係る例外処理回路の機能について説明するための模式図である。 図２０は、第１実施形態に係るstoreStatus命令とloadStatus命令について模式的に示す図である。 図２１は、第１実施形態に係るsaveStatus命令とloadStatus命令について模式的に示す図（その１）である。 図２２は、第１実施形態に係るsaveStatus命令とloadStatus命令について模式的に示す図（その２）である。 図２３（ａ）は、第１実施形態に係る例外検出回路の機能を抑制するときのアセンブリ言語のソースコードの模式図であり、図２３（ｂ）は、第１実施形態に係るdisableExeptGen命令にオペランドを記述した例の模式図であり、図２３（ｃ）は、第１実施形態に係るenableExeptGen命令にオペランドを記述した例の模式図である。 図２４は、第２実施形態に係るシミュレーションプログラムを実行する情報処理装置のハードウェア構成図である。 図２５は、第２実施形態に係る情報処理装置がシミュレーションプログラムを実行したときの情報処理装置の機能構成図である。 図２６は、第２実施形態に係る環境構築部が生成した疑似プロセッサの機能ブロック図である。 図２７は、第１実施形態に係るプロセッサの各部と、第２実施形態に係る疑似プロセッサの各部との対応関係を示す図である。 図２８は、第２実施形態に係るシミュレーション方法について説明するためのフローチャートである。 図２９は、第２実施形態に係る例外検出処理のフローチャートである。 図３０は、第３実施形態において実行可能プログラムを実行するターゲットマシンが備えるプロセッサの構成図である。 図３１は、第３実施形態に係るアセンブラプログラムを実行する情報処理装置のハードウェア構成図である。 図３２は、第３実施形態に係る情報処理装置がアセンブラプログラムを実行したときの情報処理装置の機能構成図である。 図３３は、第３実施形態に係るステータス情報を表すC++のソースコードの模式図である。 図３４（ａ）は、オペランドに汎用レジスタが指定された場合の第３実施形態に係る検出ルールについて模式的に示す図であり、図３４（ｂ）は、オペランドにベクトルレジスタが指定された場合の第３実施形態に係る検出ルールについて模式的に示す図である。 図３５は、第３実施形態に係る例外検出部の機能を抑制するときのアセンブリ言語のソースプログラムの模式図である。 図３６は、第３実施形態に係るコマンドライン引数の一例を示す模式図である。 図３７は、第３実施形態に係るアセンブラプログラムが実行する処理のフローチャートである。 図３８は、第３実施形態に係る例外検出処理のフローチャートである。 図３９は、AOT(Ahead Of Time)コンパイラ技術やJIT(Just In Time)コンパイラ技術により生成された実行可能プログラムを実行する第４実施形態に係る情報処理装置のハードウェア構成図である。 図４０（ａ）は、AOTコンパイラ技術でコンパイルすることを前提としたC++の疑似ソースコードの一例を示す模式図であり、図４０（ｂ）は、パラメータ「q」と配列「in」、「out」を宣言したC++の疑似ソースコードの一例を示す模式図であり、図４０（ｃ）は、配列「Tbl」の初期値を宣言したC++の疑似ソースコードの一例を示す模式図である。 図４１は、AOTコンパイラ技術でコンパイルして得られたアセンブリプログラムの疑似コードの模式図である。 図４２は、AOTコンパイラ技術で得られた実行可能プログラムの動作について示す模式図である。 図４３は、JITコンパイラ技術を使用したC++の疑似ソースコードの一例を示す模式図である。 図４４は、JITコンパイラ技術を使用したソースコードをコンパイルして得られた実行可能プログラムの実行中に、メモリにどのような機械語の命令列が書き込まれたかを示す模式図である。 図４５は、実行時に呼び出す関数を、JITコンパイラ技術で実行時に生成する実行可能プログラムの動作について示す模式図である。 図４６は、第１例に係る記述ミスについて説明するためのアプリケーションプログラム用のC++のソースコードの模式図である。 図４７は、第２例に係る記述ミスについて説明するためのアプリケーションプログラム用のC++のソースコードの模式図である。 図４８は、第３例と第４例に係る記述ミスについて説明するためのアプリケーションプログラム用のC++のソースコードの模式図である。 図４９は、第５例に係る記述ミスについて説明するためのアプリケーションプログラム用のC++のソースコードの模式図である。 図５０は、第１例～第５例の記述ミスをまとめた図である。 図５１は、第４実施形態に係るステータス情報を表すC++の疑似ソースコードを示す模式図である。 図５２（ａ）は、ニーモニック関数の引数に汎用レジスタが指定された場合の第４実施形態に係る検出ルールについて模式的に示す図であり、図５２（ｂ）は、ニーモニック関数の引数にベクトルレジスタが指定された場合の第４実施形態に係る検出ルールについて模式的に示す図である。 図５３（ａ）～（ｄ）は、第４実施形態に係るニーモニック関数で使用される種々の型を定義するC++の疑似ソースコードの模式図（その１）である。 図５４（ａ）～（ｄ）は、第４実施形態に係るニーモニック関数で使用される種々の型を定義するC++の疑似ソースコードの模式図（その２）である。 図５５は、第４実施形態に係るニーモニック関数multiplyを定義するC++のソースコードが記述されたソースファイルの模式図（その１）である。 図５６は、第４実施形態に係るニーモニック関数multiplyを定義するC++のソースコードが記述されたソースファイルの模式図（その２）である。 図５７は、第４実施形態に係るニーモニック関数float_multiplyを定義するC++のソースコードが記述されたソースファイルの模式図（その１）である。 図５８は、第４実施形態に係るニーモニック関数float_multiplyを定義するC++のソースコードが記述されたソースファイルの模式図（その２）である。 図５９は、第４実施形態において、８ビットのデータを読み込むニーモニック関数vloadを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６０は、第４実施形態において、１６ビットのデータを読み込むニーモニック関数vloadを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６１は、第４実施形態において、８ビットのデータを加算するニーモニック関数vaddを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６２は、第４実施形態において、１６ビットのデータを加算するニーモニック関数vaddを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６３は、第４実施形態において、８ビットのデータをメモリに保存するニーモニック関数vstoreを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６４は、第４実施形態において、３２ビットのデータをメモリに保存するニーモニック関数vstoreを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６５は、第４実施形態に係るニーモニック関数cvtssBtoHを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６６は、第４実施形態において、符号付き整数即値を読み込むニーモニック関数vmovを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６７は、第４実施形態において、符号無し整数即値を読み込むニーモニック関数vmovを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６８は、第４実施形態において、３２ビットの浮動小数即値を読み込むニーモニック関数vmovを定義するC++のソースコードが記述されたソースファイルの模式図である。 図６９は、第４実施形態に係るニーモニック関数cvtFloatSignedを定義するC++のソースコードが記述されたソースファイルの模式図である。 図７０（ａ）、（ｂ）は、第４実施形態において例外を検出する機能を抑制する方法について模式的に示す図である。 図７１は、第４実施形態において例外を検出する機能を抑制することができるニーモニック関数のC++の疑似ソースコードの模式図である。 図７２（ａ）は、第４実施形態において、例外を検出する機能を抑制するためのグローバル変数をニーモニック関数xorの内部に記述したときのソースファイルの模式図であり、図７２（ｂ）は、このニーモニック関数xorを利用したアプリケーションプログラム用のソースファイルのC++の疑似ソースコードを模式的に示す図である。 図７３は、第４実施形態において、MachineCodeEmitter関数のC++の疑似ソースコードが記述されたソースファイルの一例を示す模式図である。 図７４は、第４実施形態において、ニーモニック関数が定義されたソースファイルを利用した開発環境について示す模式図である。 図７５は、第４実施形態において、実行可能プログラムを得るためのアプリケーションプログラム用のソースファイルに記述されているC++の疑似ソースコードの模式図である。 図７６は、第４実施形態において、実行可能プログラムを実行するときの情報処理装置の動作について示すフローチャートである。 図７７は、ニーモニック関数の実行処理をするときの第４実施形態に係る情報処理装置の機能構成図である。 図７８は、第４実施形態に係る情報処理方法のフローチャートである。 図７９は、第４実施形態に係る例外検出処理のフローチャートである。
前述のように、C言語等の高級言語と比較して、アセンブリ言語でのコーディングには記述ミスが発生し易い。コーディング時の様々な場面で記述ミスは発生し得るが、特に命令のオペランドとしてレジスタを指定するときにミスを犯し易い。そこで、最初にプロセッサに設けられたレジスタについて説明する。
図１（ａ）は、プロセッサに設けられた汎用レジスタxn(n=0,1,2,…, 31)の模式図である。
汎用レジスタxn(n=0,1,2,…, 31)は、特定の用途に限定されないレジスタであって、例えばデータ、アドレス、及び即値等を格納するレジスタである。ここでは、インデックスn(=0,1,2,…, 31)で複数の汎用レジスタxnの各々を識別する。
一方、図１（ｂ）は、プロセッサに設けられたベクトルレジスタvn(n=0,1,2,…, 31)の模式図である。
ベクトルレジスタvn(n=0,1,2,…, 31)は、SIMD(Single Instruction Multiple Data)レジスタであって、ベクトル演算の対象となるベクトルデータを格納するためのレジスタである。汎用レジスタxn(n=0,1,2,…, 31)と同様に、本実施形態ではインデックスn(=0,1,2,…, 31)で複数のベクトルレジスタvn(n=0,1,2,…, 31)の各々を識別する。また、各々のベクトルレジスタvn(n=0,1,2,…, 31)のサイズは、例えば１２８ビットである。
図２は、ベクトルレジスタを指定可能な命令セットであるARM社のARMv8-Aアーキテクチャに基づくプロセッサにおいて、１２８ビット長のベクトルレジスタvn(n=0,1,2,…, 31)を指定するアセンブリ言語の書式を示す模式図である。
図２に示すように、アセンブリ言語においてベクトルレジスタvn(n=0,1,2,…31)を指定するには、「vn.x」、「vn.d」、「vn.s」、「vn.h」、「vn.b」という書式が採用される。
この書式において、「vn」は、インデックスが「n」のベクトルレジスタvnを指定する書式である。そして、ドット「.」の後に続く「x」、「d」、「s」、「h」、「b」は、一つのベクトルレジスタvnに格納されたベクトルデータの要素のサイズを示す書式である。例えば、「x」は要素のサイズが１２８ビットであることを示し、「d」は要素のサイズがダブルワード（６４ビット）であることを示す。
同様に、「s」、「h」、「b」は、要素のサイズがそれぞれシングルワード（３２ビット）、ハーフワード（１６ビット）、バイト（８ビット）であることを示す。
このように、この書式では、「vn」と「d」とをドット「．」で連結した「vn.d」等の文字列により、ベクトルレジスタvnとその要素のサイズとを指定する。
次に、ベクトルレジスタを用いたアセンブリ言語の文法について説明する。
図３～図５は、ベクトルレジスタを用いたアセンブリ言語の文法について示す模式図である。
このうち、図３（ａ）は、vadd命令の文法について示す模式図である。図３（ａ）のvadd命令は、二つのベクトルレジスタv0、v1の各々の対応する要素同士を加算し、その結果をベクトルレジスタv2の対応する要素に格納する符号あり整数の加算命令である。このように、vadd命令は、各ベクトルレジスタの要素ごとの加算命令であるため、各ベクトルレジスタv0、v1、v2の各々の要素のサイズが同一であることを前提とする。
そのため、開発者は、vadd命令のオペランドにおける全てのベクトルレジスタの要素のサイズを例えば「b」で同一にする。この場合、vadd命令は、各ベクトルレジスタの要素に格納されている８ビットの符号あり整数を加算する命令となる。
図３（ｂ）は、vadd命令の文法の他の例について示す模式図である。
図３（ｂ）の例では、vadd命令のオペランドに指定された各ベクトルレジスタの要素のサイズを「h」としている。この場合、vadd命令は、各ベクトルレジスタの要素に格納されている１６ビットの符号あり整数を加算する命令となる。
図４（ａ）は、vfadd命令の文法について示す模式図である。
図４（ａ）のvfadd命令は、二つのベクトルレジスタv0、v1の各々の対応する要素同士を加算し、その結果をベクトルレジスタv2の対応する要素に格納する浮動小数の加算命令である。前述のvadd命令と同様に、vfadd命令も各ベクトルレジスタの要素ごとの加算命令であるため、各ベクトルレジスタv0、v1、v2の各々の要素のサイズが同一であることを前提とした命令である。
よって、開発者は、vfadd命令のオペランドにおける全てのベクトルレジスタの要素のサイズを例えば「s」で同一にする。この場合は、vfadd命令は、各ベクトルレジスタの要素に格納されている３２ビットの浮動小数を加算する命令となる。
図４（ｂ）は、vfadd命令の文法の他の例について示す模式図である。
図４（ｂ）の例では、vfadd命令のオペランドに指定された各ベクトルレジスタの要素のサイズを「d」としている。この場合、vfadd命令は、各ベクトルレジスタの要素に格納されている６４ビットの浮動小数を加算する命令となる。
図５は、multiply命令の文法について示す模式図である。
図５のmultiply命令は、二つのベクトルレジスタv0、v1の各々の対応する要素同士を乗算し、その結果をベクトルレジスタv2の各々の要素に格納する整数の乗算命令である。multiply命令は、このように要素ごとの乗算命令であるため、各ベクトルレジスタv0、v1、v2の各々の要素のサイズが同一であることを前提とした命令である。この例では、各ベクトルレジスタv0、v1、v2の各々の要素のサイズを「h」で同一にしている。
更に、multiply命令は、整数と浮動小数点のようにデータタイプが異なるデータ同士の積をサポートしていない。そのため、multiply命令は、ソースレジスタのベクトルレジスタv0、v1の各々に同一のデータタイプのデータが書き込まれていることを前提とする命令である。
次に、汎用レジスタを用いたアセンブリ言語の文法について説明する。
図６（ａ）、（ｂ）は、汎用レジスタを用いたアセンブリ言語の文法について示す模式図である。
このうち、図６（ａ）は、add命令の文法について示す模式図である。add命令は、汎用レジスタを対象とした符号あり６４ビット整数の加算命令である。図６（ａ）の例では、二つの汎用レジスタx0、x1の各々に格納されているデータが加算され、その結果が汎用レジスタx2に書き込まれる。
ベクトルレジスタとは異なり、汎用レジスタにおいては要素同士の演算という考え方はない。そのため、add命令のオペランドにおいては、ドット「.」で要素のサイズを指定する必要はない。
また、図６（ｂ）は、fadd命令の文法について示す模式図である。
fadd命令は、汎用レジスタを対象とした６４ビットの浮動小数の加算命令である。図６（ｂ）の例では、二つの汎用レジスタx0、x1の各々に格納されているデータが加算され、その結果が汎用レジスタx2に書き込まれる。
add命令と同様に、fadd命令のオペランドにおいても、ドット「.」で要素のサイズを指定する必要はない。
次に、アセンブリ言語でのコーディング例について説明する。
図７は、開発者が記述したアセンブリ言語のソースコードの正しいコーディング例を示す模式図である。
アセンブリ言語のソースコードにおいては、命令のオペランドとして汎用レジスタxn(n=0,1,2,…, 31)、ベクトルレジスタvn(n=0,1,2,…, 31)、及びアドレス等の即値が指定される。
例えば、コードT1においては、load命令のオペランドとして「x0」と「アドレス１」が指定される。このコードT1は、即値として指定された「アドレス１」のメモリから６４ビットのデータを読み出し、それを汎用レジスタx0に書き込むコードである。
また、コードT2においては、vadd命令のオペランドとして「v2.b」、「v0.b」、及び「v1.b」が指定される。このコードT2は、ベクトルレジスタv0とベクトルレジスタv1の各々の要素に格納されているデータを読み出し、それらを８ビットの符号あり整数として加算して結果をベクトルレジスタv2に書き込む命令である。
以下では、コードT2におけるベクトルレジスタv0、v1のようにデータの読み出し元のレジスタをソース(src)レジスタとも呼ぶ。また、コードT1の汎用レジスタx0やコードT2のベクトルレジスタv2のようにデータの書き込み先のレジスタをデスティネーション(dst)レジスタとも呼ぶ。
次に、開発者が記述したアセンブリ言語のソースコードの記述ミスの例について説明する。その記述ミスのタイプとしては、以下の第１～第５例がある。
・第１例
図８は、第１例に係る記述ミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。
図８の例では、コードT3において、符号あり６４ビット整数の加算結果がデスティネーションレジスタである汎用レジスタx2に書き込まれている。そして、コードT4においては、その汎用レジスタx2がfadd命令のソースレジスタに指定されている。
fadd命令が演算の対象とするデータタイプは浮動小数であるから、fadd命令のソースレジスタである汎用レジスタx2には浮動小数が書き込まれていなければならない。しかし、この例では、コードT3において汎用レジスタx2に符号あり整数が書き込まれてしまっているため、このコーディングは誤りである。
コードT3、T4ではオペランドに汎用レジスタが指定されているが、ベクトルレジスタをオペランドに指定した場合にも同様の誤りは生じ得る。
図９は、ベクトルレジスタをオペランドに指定したときの第１例に係る記述ミスの例について説明するためのアセンブリ言語のソースコードを示す模式図である。
図９の例では、コードT5において、符号あり３２ビット整数の加算結果がデスティネーションレジスタであるベクトルレジスタv2に書き込まれている。そして、コードT6においては、そのベクトルレジスタv2がvfadd命令のソースレジスタに指定されている。
fadd命令と同様に、vfadd命令も浮動小数同士を加算する命令であるから、そのソースレジスタであるベクトルレジスタv2には浮動小数が書き込まれていなければならない。しかし、この例では、コードT5においてベクトルレジスタv2に整数が書き込まれてしまっているため、このコーディングは誤りである。
図８や図９のように、命令が演算の対象とするデータタイプと、実際にソースレジスタに書き込まれているデータのデータタイプとが一致しないコーディングは誤りである。
・第２例
図１０は、第２例に係るミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。
図１０の例では、コードT7のvadd命令において、デスティネーションレジスタのデータサイズとしてシングルワード「s」が指定されている。よって、コードT7のvadd命令を実行すると、データサイズがシングルワード「s」の要素を有するベクトルデータがベクトルレジスタv2に書き込まれる。
一方、次のコードT8のvadd命令においては、ソースレジスタとデスティネーションレジスタの各々のデータサイズとしてダブルワード「d」が指定されている。これによれば、開発者は、コードT8においてデータサイズがダブルワード「d」のデータ同士の演算を意図していることになる。
しかし、ソースレジスタのベクトルレジスタv2には、前述のコードT7によってデータサイズがシングルワード「s」の要素が書き込まれているため、コードT8を実行すると開発者の意図とは異なる結果が得られてしまう。
このように、先行命令のデスティネーションレジスタのデータサイズと、そのデスティネーションレジスタをソースレジスタとする後続命令の当該ソースレジスタのデータサイズとが異なる記述は誤りである。
・第３例
図１１は、第３例に係るミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。
図１１の例では、コードT9のadd命令において、ソースレジスタである汎用レジスタx0、x1のデータを加算して、その結果を汎用レジスタx2に書き込んでいる。但し、コードT9よりも以前に汎用レジスタx1をデスティネーションレジスタとして使用しているコードはない。よって、汎用レジスタx1にどのようなデータが書き込まれているかが不明であり、当該データは不定となる。このような状態でコードT9を実行しても、汎用レジスタx2に書き込まれるデータも不定となってしまう。
そのため、このようにデスティネーションレジスタとして使われたことがないレジスタをソースレジスタに指定するのは誤りである。
・第４例
図１２は、第４例に係る記述ミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。
図１２の例では、コードT10のadd命令において汎用レジスタx2をデスティネーションレジスタとして使用することにより、汎用レジスタx0、x1の各々のデータを加算した値を汎用レジスタx2に書き込んでいる。
但し、コードT10以降のコードでは、その汎用レジスタx2をソースレジスタとして使用することなく、コードT11のadd命令で汎用レジスタx2の内容を上書きしている。これでは、汎用レジスタx2に書き込まれているコードT10の実行結果を一度も使用していないことになるため、コードT10の存在意義が不明となり、コードT10又はコードT11におけるレジスタの指定ミスが疑われる。
そのため、このようにデスティネーションレジスタとして使ったレジスタを、その後にソースレジスタとして使うことなく再びデスティネーションレジスタに指定するのは誤りである。
・第５例
図１３は、第５例に係る記述ミスについて説明するためのアセンブリ言語のソースコードを示す模式図である。
図１３の例では、コードT12において、vfadd命令の実行結果である浮動小数がベクトルレジスタv0に書き込まれる。また、コードT13においては、vadd命令の実行結果である整数がベクトルレジスタv1に書き込まれる。
そして、コードT14のmultiply命令において、ソースレジスタのベクトルレジスタv0、v1の各々の要素のデータ同士が乗算され、その結果がデスティネーションレジスタのベクトルレジスタv2に書き込まれる。
但し、multiply命令は、前述のように二つのソースレジスタに書き込まれているデータのタイプが同一であることを前提とする命令である。この例では、ベクトルレジスタv0とベクトルレジスタv1の各々に書き込まれているデータタイプが浮動小数点型と整数型とで異なるため、このmultiply命令を実行すると開発者が意図したのとは異なる実行結果が得られてしまう。
よって、このように二つのソースレジスタに書き込まれているデータのデータタイプが異なる場合もコーディングの誤りとなる。
図１４は、前述の第１～第５例に係る記述ミスをまとめた図である。
以下に、図１４の各々の記述ミスやこれに等価なミスを検出できる各実施形態について説明する。
（第１実施形態）
本実施形態では、図１４の第１～第５例に係る記述ミスに起因した例外を検出することが可能なプロセッサについて説明する。
図１５は、本実施形態に係るプロセッサの構成図である。
図１５に示すように、このプロセッサ２０は、命令デコード回路２１、データフェッチ回路２２、命令実行回路２３、書き戻し回路２４、例外処理回路２５、ステータスレジスタファイル２６、及び演算用レジスタファイル２７を備える。
更に、プロセッサ２０の外部には、命令メモリ２８ａとデータメモリ２８ｂとを備えたメモリ２８が設けられる。このうち、命令メモリ２８ａは、プロセッサ２０で実行する機械語の命令列を記憶するメモリである。そして、データメモリ２８ｂは、命令の実行時に使用するデータを記憶するメモリである。
また、演算用レジスタファイル２７は、図１と図２に示した汎用レジスタxn(n=0,1,2,…, 31)とベクトルレジスタvn(n=0,1,2,…, 31)とを備えたハードウェアである。
また、ステータスレジスタファイル２６は、汎用レジスタxn(n=0,1,2,…, 31)とベクトルレジスタvn(n=0,1,2,…, 31)の各々のステータスを示すステータス情報を格納した複数のレジスタを備えたハードウェアである。
一方、命令実行回路２３は、命令メモリ２８ａに格納されている命令を実行する回路であって、実行回路３０、ステータス更新回路３１、第１の例外検出部３２ａ、及び第２の例外検出部３２ｂを有する。
このプロセッサ２０では以下のように命令が実行される。
まず、命令メモリ２８ａのアドレスのうち、不図示のプログラムカウンタが指すアドレスにある機械語の命令を命令デコード回路２１が読み出す。
そして、命令デコード回路２１がその命令をデコードし、デコード内容をデータフェッチ回路２２、命令実行回路２３、及び書き戻し回路２４の各々に出力する。デコード内容としては、命令の種類、ソースレジスタとデスティネーションレジスタの各々のインデックス、ソースレジスタの要素のデータサイズ、及びソースレジスタのデータタイプがある。
例えば、アセンブリ言語の「vfadd v2.s, v0.s, v1.s」に相当する命令をデコードする場合を考える。その場合、命令デコード回路２１は、命令メモリ２８ａから読み出した機械語をデコードすることにより命令の種類が「vfadd」であることを特定する。また、命令デコード回路２１は、命令メモリ２８ａから読み出した機械語をデコードすることにより、vfadd命令のソースレジスタが「v0」と「v1」であり、デスティネーションレジスタが「v2」であることを特定する。
更に、読み出した機械語のビット列に基づいて、命令デコード回路２１は、１番目のソースレジスタ「v0」の要素のサイズが「s」であることを特定し、かつ２番目のソースレジスタ「v1」の要素のサイズが「s」であることを特定する。
そして、前述のように命令の種類「vfadd」が浮動小数を対象とした演算であることから、命令デコード回路２１は、命令の種類「vfadd」に基づいてソースレジスタのデータタイプが浮動小数であることを特定する。なお、命令の種類が「add」の場合には、命令デコード回路２１は、ソースレジスタのデータタイプが符号あり整数であることを特定する。
次に、データフェッチ回路２２が、デコード内容に基づいて、演算用レジスタファイル２７とデータメモリ２８ｂのいずれか一方からデータを読み出し、それを命令実行回路２３に出力する。
例えば、前述の「vfadd v2.s, v0.s, v1.s」の例では、第１オペランドと第２オペランドの各々にレジスタが指定されている。よって、この場合は、データフェッチ回路２２は、演算用レジスタファイル２７にあるベクトルレジスタv0とベクトルレジスタv1の各々のデータを読み出し、それらのデータを命令実行回路２３に出力する。
なお、命令デコード回路２１がデコードした機械語が「load x0, アドレス1」の場合には、データフェッチ回路２２は、データメモリ２８ｂのアドレスのうち「アドレス1」にあるデータを読み出す。そして、データフェッチ回路２２は、読み出したデータを命令実行回路２３に出力する。
続いて、命令実行回路２３の第１の例外検出部３２ａと第２の例外検出部３２ｂの各々が、命令の実行によって例外が発生するかを検出する。
このうち、第２の例外検出部３２ｂは、アセンブリ言語の記述ミスに起因した例外を検出する回路である。本実施形態では、後述のようにステータスレジスタファイル２６に格納されているステータス情報と、命令デコード回路２１が出力したデコード内容とに基づいて第２の例外検出部３２ｂが例外を検出する。その検出方法やステータス情報の詳細については後述する。
一方、第１の例外検出部３２ａは、アセンブリ言語の記述ミスとは無関係の例外を検出する回路である。そのような例外としては、未実装命令を実行しようとしたときの例外や、０除算を実行したときの例外がある。
ここで、第１の例外検出部３２ａ又は第２の例外検出部３２ｂが例外を検出した場合は、これらの例外検出回路は例外信号を生成してそれを例外処理回路２５に出力する。例外処理回路２５は、その例外信号に応じた処理を行う回路である。
一方、第１の例外検出部３２ａと第２の例外検出部３２ｂのいずれもが例外を検出しなかった場合には、ステータス更新回路３１が、ステータスレジスタファイル２６にあるステータス情報を更新する。
これと共に、実行回路３０が命令を実行し、その実行結果を書き戻し回路２４に出力する。このとき、実行回路３０は、命令デコード回路２１が出力したデコード内容に含まれる命令の種類を特定し、その命令の種類に応じた演算を行う。
例えば、前述の「vfadd v2.s, v0.s, v1.s」の例では、実行回路３０は、命令の種類が「vfadd」であることを特定する。そして、実行回路３０は、ベクトルレジスタv0とベクトルレジスタv1の各々のデータを加算し、それにより得られた値を書き戻し回路２４に出力する。
続いて、書き戻し回路２４が、命令の実行結果を演算用レジスタファイル２７とデータメモリ２８ｂのいずれか一方に書き戻す。これらのうちのどちらに実行結果を書き戻すかは、命令デコード回路２１が出力したデコード内容に含まれる命令の種類に応じて書き戻し回路２４が判断する。
例えば、前述の「vfadd v2.s, v0.s, v1.s」の例を考える。この例における「vfadd」は、デスティネーションレジスタに実行結果を書き戻す命令である。よって、書き戻し回路２４は、ベクトルレジスタv0とベクトルレジスタv1の各々のデータを加算した値を演算用レジスタファイル２７のベクトルレジスタv2に書き戻す。
なお、命令デコード回路２１がデコードしたオペコードがstore命令を示している場合には、書き戻し回路２４は、実行結果をデータメモリ２８ｂに書き戻す。
以上により、一つの命令の実行を終える。
図１６は、ステータスレジスタファイル２６と演算用レジスタファイル２７の各々の模式図である。
図１６に示すように、演算用レジスタファイル２７は、汎用レジスタxn(n=0,1,2,…, 31)とベクトルレジスタvn(n=0,1,2,…, 31)とを備えたレジスタファイルである。これらのレジスタのサイズは特に限定されない。本実施形態では汎用レジスタxn(n=0,1,2,…, 31)のサイズを６４ビットとし、ベクトルレジスタvn(n=0,1,2,…, 31)のサイズを１２８ビットとする。
一方、ステータスレジスタファイル２６は、汎用レジスタxn(n=0,1,2,…, 31)の各々と対応付けられたステータスレジスタsxn(n=0,1,2,…, 31)を備えたハードウェアである。更に、そのステータスレジスタファイル２６は、ベクトルレジスタvn(n=0,1,2,…, 31)に対応付けられたステータスレジスタsvn(n=0,1,2,…, 31)も備える。
このうち、汎用レジスタxn(n=0,1,2,…, 31)に対応したステータスレジスタsxn(n=0,1,2,…, 31)は、汎用レジスタxn(n=0,1,2,…, 31)のステータス情報Qを格納するためのレジスタである。ステータス情報Qは、汎用レジスタxn(n=0,1,2,…, 31)のステータスを示す情報であって、第１のフラグW、第２のフラグR、及び型情報DTを備える。
このうち、第１のフラグWは、実行回路３０が命令を実行する前に汎用レジスタxn(n=0,1,2,…, 31)がデスティネーションレジスタとして使用済みかどうかを示す１ビットのデータである。例えば、汎用レジスタx0がデスティネーションレジスタとして使用済みである場合を考える。この場合は、ステータスレジスタsx0に格納されているステータス情報Qの第１のフラグWが「1」となる。また、その汎用レジスタx0がデスティネーションレジスタとして使用済ではない場合には、その第１のフラグWは「0」となる。
また、第２のフラグRは、命令実行回路２３が命令を実行する前に汎用レジスタxn(n=0,1,2,…, 31)がソースレジスタとして使用済みかどうかを示す１ビットのデータである。例えば、汎用レジスタx0がソースレジスタとして使用済の場合には、ステータスレジスタsx0における第２のフラグRが「1」となり、使用済ではない場合には第２のフラグRが「0」となる。
型情報DTは、汎用レジスタxnに格納されているデータのデータタイプを示すデータである。そのデータタイプとしては、符号あり整数、符号無し整数、浮動小数、及び不定の４種類がある。型情報DTは、これらの４種類のデータタイプの各々を一意に識別する２ビットの情報である。
一方、ベクトルレジスタvnに対応したステータスレジスタsvn(n=0,1,2,…, 31)は、ベクトルレジスタvn(n=0,1,2,…, 31)のステータス情報Qを格納するためのレジスタである。このステータス情報Qは、ベクトルレジスタvn(n=0,1,2,…, 31)のステータスを示す情報であって、前述の第１のフラグW、第２のフラグR、及び型情報DTの他にサイズ情報DSを有する。
サイズ情報DSは、ベクトルレジスタvn(n=0,1,2,…, 31)に格納されているベクトルデータの要素のサイズを示す情報である。図２を参照して説明したように、要素のサイズとしては、「x（１２８ビット）」、「d（ダブルワード）」、「s（シングルワード）」、「h（ハーフワード）」、「b（バイト）」、及び不定の６種類がある。サイズ情報DSは、これらの５種類のサイズを一意に識別するための３ビットの情報である。
上記のステータス情報Qは、各例外検出部３２ａ、３２ｂがいずれも例外を検出せずに実行回路３０が正常に命令を実行したときに、ステータス更新回路３１（図１５参照）によって更新される。ステータス情報Qの更新は、デコード内容に含まれる各レジスタのインデックスと命令の種類に基づいて以下のように行われる。
例えば、オペランドにソースレジスタが指定された命令を実行回路３０が実行したときに、ステータス更新回路３１は、そのソースレジスタのインデックスをデコード内容から特定する。そして、ステータス更新回路３１は、ステータスレジスタsxn、svn(n=0,1,2,…, 31)のうちで特定したインデックスを有するレジスタの第２のフラグRに「1」をセットする。
また、オペランドにデスティネーションレジスタが指定された命令を実行回路３０が実行したときには、ステータス更新回路３１は、そのデスティネーションレジスタのインデックスをデコード内容から特定する。そして、ステータス更新回路３１は、ステータスレジスタsxn、svn(n=0,1,2,…, 31)のうちで特定したインデックスを有するレジスタの第１のフラグWに「1」をセットする。更に、この場合は、ステータス更新回路３１は、当該ステータスレジスタの第２のフラグRを「0」にする。これにより、そのデスティネーションレジスタが、データが書き込まれてからまだソースレジスタとして使用されていない状態に設定されることになる。
また、オペランドにデスティネーションレジスタが指定された命令を実行回路３０が実行したときには、ステータス更新回路３１は、そのデスティネーションレジスタの型情報DTを更新する。例えば、実行回路３０が「add x2, x0, x1」という命令を実行した場合を考える。この場合は、ステータス更新回路３１は、デコード内容に基づいて、命令の種類が「add」であることと、デスティネーションレジスタのインデックスが「2」であることを特定する。このadd命令は、符号あり６４ビット整数の加算命令であり、命令の実行によってデスティネーションレジスタの汎用レジスタx2に符号あり整数が格納される。よって、この場合は、ステータス更新回路３１は、インデックスが「2」のステータスレジスタsx2に格納されている型情報DTが符号あり整数を示すようにステータス情報Qを更新する。なお、デスティネーションレジスタにベクトルレジスタvn(n=0,1,2,…, 31)が指定されている場合も、これと同様にしてステータス更新回路３１がステータス情報Qを更新する。
このように、ステータス更新回路３１は、レジスタにデータを書き込む命令を実行回路３０が実行したときに、その命令が演算の対象とするデータのデータタイプを型情報DTが示すように、そのレジスタに対応した型情報DTを更新する。
更に、ステータス更新回路３１は、オペランドにデスティネーションレジスタとしてベクトルレジスタ指定された命令を実行回路３０が実行したときには、そのデスティネーションレジスタのサイズ情報DSを更新する。例えば、実行回路３０が「vadd v3.s, v0.s, v1.s」という命令を実行した場合を考える。この場合は、ステータス更新回路３１は、デコード内容に基づいて、デスティネーションレジスタのインデックスとデータサイズがそれぞれ「3」とシングルワード「s」であることを特定する。そして、ステータス更新回路３１は、インデックスが「3」のステータスレジスタsv3に格納されているサイズ情報DSがシングルワードを示すようにステータス情報Qを更新する。
このように、ステータス更新回路３１は、ベクトルレジスタにデータを書き込む命令を実行回路３０が実行したときに、書き込まれたデータのデータサイズを示すようにそのレジスタに対応したサイズ情報DSを更新する。
次に、第２の例外検出部３２ｂが検出する例外について説明する。
図１７は、第２の例外検出部３２ｂが例外を検出するときの検出ルールを模式的に示す図である。
第２の例外検出部３２ｂが検出する例外の種類としては、「W例外」、「R例外」、「データタイプ例外」、「データサイズ例外」、及び「srcデータタイプ例外」がある。
このうち、W例外は、命令のソースレジスタが過去にデスティネーションレジスタとして使用されていない場合に発生する例外であり、図１４の第３例の記述ミスがあった場合に発生する。
W例外は、前述の第１のフラグWを利用して検出することができる。例えば、ソースレジスタの第１のフラグWが「0」の場合は、そのソースレジスタは過去にデスティネーションレジスタとして使用されていないことになる。よって、第２の例外検出部３２ｂは、第１のフラグWが「0」の場合にW例外が発生したことを検出する。
また、R例外は、先行命令がデータを書き込んだレジスタを後続命令がデスティネーションレジスタとして使用する場合に、先行命令と後続命令の間の全ての命令がそのレジスタをソースレジスタとして使用しない場合の例外である。このR命令は、図１４の第４例の記述ミスがあった場合に発生する。
R例外は、前述の第１のフラグWと第２のフラグRとを利用して検出することができる。例えば、命令のデスティネーションレジスタが、過去に別の命令でデスティネーションレジスタとして使用済みの場合には第１のフラグWは「1」となる。また、そのデスティネーションレジスタが、その後の命令でソースレジスタとして使用されていない場合には第２のフラグRは「0」となる。よって、第２の例外検出部３２ｂは、第１のフラグWが「1」であり、かつ第２のフラグRが「0」の場合にR例外が発生したことを検出する。
そして、データタイプ例外は、命令が演算の対象とするデータタイプと、実際にソースレジスタに書き込まれているデータのデータタイプとが一致しない場合に発生する例外であり、図１４の第１例の記述ミスがあった場合に発生する。
データタイプ例外は、前述の型情報DTを利用して検出することができる。例えば、その型情報DTが示すデータタイプと、命令が演算の対象とするデータタイプとが一致しない場合に、第２の例外検出部３２ｂはデータタイプ例外が発生したことを検出する。
一方、データサイズ例外は、図１４の第２例の記述ミスに起因して発生する例外である。そのデータサイズ例外は、先行命令がレジスタに書き込んだデータのデータサイズと、そのレジスタをソースレジスタとする後続命令において指定されたソースレジスタのデータサイズとが異なる場合に発生する。
このデータサイズ例外は、前述のサイズ情報DSを利用して検出することができる。例えば、ある命令のソースレジスタに指定されたデータサイズと、そのソースレジスタに対応したサイズ情報DSが示すデータサイズとが一致しない場合に、第２の例外検出部３２ｂはデータサイズ例外が発生したことを検出する。
そして、srcデータタイプ例外は、図１４の第５例の記述ミスがあった場合に発生する例外である。そのsrcデータタイプ例外は、二つのソースレジスタのデータタイプが同一であることを前提とする命令において、各ソースレジスタの各々のデータタイプが一致しない場合に発生する。
srcデータタイプ例外も、前述の型情報DTを利用して検出することができる。例えば、第２の例外検出部３２ｂは、二つのソースレジスタのデータタイプが同一であることを前提とする命令において、各ソースレジスタの型情報DTのデータタイプ同士が一致しない場合にsrcデータタイプ例外を検出する。
図１８は、第２の例外検出部３２ｂのブロック図である。
図１８に示すように、第２の例外検出部３２ｂは、選択回路４０、例外検出回路４１、及び例外信号生成回路４２を有する。
このうち、選択回路４０は、命令デコード回路２１が出力したデコード内容からソースレジスタとデスティネーションレジスタのそれぞれのインデックスを取得する。そして、選択回路４０は、汎用レジスタxn(n=0,1,2,…, 31)とベクトルレジスタvn(n=0,1,2,…, 31)の各々のうち、取得したインデックスに対応するレジスタを選択する。
一方、例外検出回路４１は種々の例外を検出する回路である。この例では、例外検出回路４１は、データタイプ例外検出回路４３、データサイズ例外検出回路４４、W例外検出回路４５、srcデータタイプ例外検出回路４６、及びR例外検出回路４７を有する。
このうち、データタイプ例外検出回路４３は、データタイプ例外を検出する回路である。データタイプ例外の検出を行うために、データタイプ例外検出回路４３は、命令デコード回路２１が出力したデコード内容からソースレジスタに格納されていることが期待されるデータタイプを取得する。更に、データタイプ例外検出回路４３は、そのソースレジスタに対応したステータス情報Qを選択回路４０を介して取得する。
そして、データタイプ例外検出回路４３は、ステータス情報Qの型情報DTが示すデータタイプと、命令デコード回路２１から取得したソースレジスタのデータタイプとが一致するかを判定する。そして、一致しないと判定した場合に、データタイプ例外検出回路４３は、データタイプ例外を検出したという検出結果を例外信号生成回路４２に出力する。
また、データサイズ例外検出回路４４は、データサイズ例外を検出する回路である。データサイズ例外の検出を行うために、データサイズ例外検出回路４４は、命令デコード回路２１が出力したデコード内容に基づいて、ソースレジスタに格納されていることが期待されるベクトルデータの要素のデータサイズを取得する。更に、データサイズ例外検出回路４４は、そのソースレジスタに対応したステータス情報Qを選択回路４０を介して取得する。
そして、データサイズ例外検出回路４４は、ステータス情報Qのサイズ情報DSが示すサイズと、命令デコード回路２１から取得したソースレジスタのサイズとが一致するかを判定する。そして、一致しないと判定した場合に、データサイズ例外検出回路４４は、データサイズ例外を検出したという検出結果を例外信号生成回路４２に出力する。
また、W例外検出回路４５は、W例外を検出する回路である。W例外の検出を行うために、W例外検出回路４５は、命令のソースレジスタに対応したステータス情報Qを選択回路４０を介して取得する。
そして、W例外検出回路４５は、そのステータス情報Qにおける第１のフラグWが「0」の場合に、W例外を検出したという検出結果を例外信号生成回路４２に出力する。
更に、srcデータタイプ例外検出回路４６は、命令デコード回路２１からデコード内容に含まれる命令の種類を取得する。そして、その命令の種類に基づいて、srcデータタイプ例外検出回路４６は、その命令が二つのソースレジスタに格納されているデータタイプが同一であることを前提としているかを判断する。
このとき、データタイプが同一であることを前提としていると判断したときは、srcデータタイプ例外検出回路４６は、命令の二つのソースレジスタの各々に対応したステータス情報Qを選択回路４０を介して取得する。
更に、srcデータタイプ例外検出回路４６は、そのステータス情報Qにおける型情報DTが、二つのソースレジスタの各々で一致しているかを判定する。そして、両者が一致しない場合に、srcデータタイプ例外検出回路４６は、srcデータタイプ例外を検出したという検出結果を例外信号生成回路４２に出力する。
そして、R例外検出回路４７は、R例外を検出する回路である。R例外の検出を行うために、R例外検出回路４７は、命令のソースレジスタに対応したステータス情報Qと、命令のデスティネーションレジスタに対応したステータス情報Qとを選択回路４０を介して取得する。そして、R例外検出回路４７は、デスティネーションレジスタに対応するステータス情報Qの第１のフラグWと、ソースレジスタに対応するステータス情報Qの第２のフラグRとを特定する。更に、R例外検出回路４７は、第１のフラグWが「1」であり、かつ第２のフラグRが「0」である場合に、R例外を検出したという検出結果を例外信号生成回路４２に出力する。
なお、例外検出回路４１は、実行回路３０から後述の無効信号を受信した場合には例外の検出を行わない。また、実行回路３０から後述の有効信号を受信した場合には、例外検出回路４１は、上記のようにして例外の検出を行う。
例外信号生成回路４２は、例外検出回路４１の検出結果に応じた例外信号を出力する。その例外信号には、例外の種類、命令のアドレス、及びレジスタのインデックスが含まれる。
このうち、例外の種類としては、「データタイプ例外」、「データサイズ例外」、「W例外」、「srcデータタイプ例外」、及び「R例外」がある。例えば、データタイプ例外検出回路４３が例外を検出したという検出結果を出した場合には、例外の種類として「データタイプ例外」が例外信号に含まれることになる。
また、命令のアドレスは、例外が発生した命令のアドレスである。例えば、命令デコード回路２１が保持しているアドレスを例外信号生成回路４２が取得することにより、例外信号生成回路４２が例外信号に命令のアドレスを含ませることができる。
そして、レジスタのインデックスは、例外が発生した命令のオペランドに指定されているレジスタのインデックスである。例えば、例外信号生成回路４２は、命令デコード回路２１が出力したデコード内容からソースレジスタとデスティネーションレジスタのそれぞれのインデックスを取得することにより、それを例外信号に含ませることができる。
次に、この例外信号の出力先である例外処理回路２５の機能について説明する。
図１９は、例外処理回路２５の機能について説明するための模式図である。
例外信号を受信すると、例外処理回路２５は、命令デコード回路２１、データフェッチ回路２２、命令実行回路２３、及び書き戻し回路２４の各々に対し、現在実行中の命令の実行を停止するように指示する。
そして、例外処理回路２５は、メモリ２８に格納されている例外ベクタテーブル５０を参照し、受信した例外信号に含まれる例外の種類に対応したジャンプ先のアドレスを特定する。図１９の例では、W例外のジャンプ先の命令メモリ２８ａのアドレスを「0xAAAAAAAA」とし、R例外のジャンプ先のアドレスを「0xBBBBBBBB」等としている。これらのアドレスにおける命令メモリ２８ａには、例外の種類に応じて実行する例外処理プログラムが予め格納されている。
その後、例外処理回路２５は、特定したジャンプ先のアドレスを命令デコード回路２１に通知する。そして、命令デコード回路２１が、通知されたアドレスにある命令をフェッチする。これにより、命令実行回路２３において、例外の種類に応じた例外処理プログラムが実行されることになる。
以上説明したプロセッサ２０によれば、ステータスレジスタsxn、svn(n=0,1,2,…, 31)に格納されているステータス情報Qを利用して、例外検出回路４１が、図１７の検出ルールに従って例外を検出する。これにより、アセンブリに記述ミスがあった場合に例外検出回路４１が例外を検出するようになり、その例外に基づいて開発者がアセンブリプログラムに記述ミスがあったことに気付くことができる。その結果、開発者がアセンブリプログラムを容易にデバッグすることができるようになり、プログラム開発の効率化を図ることができる。
しかも、このように記述ミスに起因した例外をプロセッサ２０が検出することで、記述ミスのあるプログラムをプロセッサ２０で無駄に実行する時間が減り、プロセッサ２０やメモリ２８等のハードウェア資源の無駄な消費を改善できる。
更に、ステータス情報Qには、第１のフラグW、第２のフラグR、型情報DT、及びサイズ情報DSがある。これらの情報を図１７の検出ルールに適用することにより、例外検出回路４１は、「R例外」、「W例外」、「データタイプ例外」、「データサイズ例外」、及び「srcデータタイプ例外」を検出することができる。そのため、これらのどの例外が検出されたかに応じ、開発者が、アセンブリにおける具体的な記述ミスの種類を特定することができる。
ところで、プログラムの実行時にはサブルーチン呼び出しやOS(Operating System)によるコンテキストスイッチが発生することがある。この場合は、呼び出されたサブルーチンや別のコンテキストによってレジスタのデータが上書きされるのを防ぐために、汎用レジスタxnとベクトルレジスタvnの各々にあるデータをデータメモリ２８ｂに退避させる必要がある。そして、元のルーチンの処理に戻ったときには、処理を中断したところからプログラムを再開できるようにするために、データメモリ２８ｂに退避させたデータを汎用レジスタxnとベクトルレジスタvnの各々に復元させる。
本実施形態では、汎用レジスタxnに対応付けて用いられているステータスレジスタsxnに格納されているステータス情報Qについても退避と復元を行うのが好ましい。同様の理由により、ステータスレジスタsvnについてもステータス情報Qの退避と復元を行うのが好ましい。
そこで、次に、ステータスレジスタsxn(n=0,1,2,…, 31)、svn(n=0,1,2,…, 31)の各々に格納されているステータス情報Qの退避と復元とを行うことが可能な命令について説明する。
図２０は、本実施形態に係るstoreStatus命令とloadStatus命令について模式的に示す図である。
storeStatus命令は、第１のストア命令の一例であって、ステータスレジスタsxn(n=0,1,2,…, 31)に格納されているステータス情報Qを汎用レジスタxn(n=0,1,2,…, 31)に保存する命令である。ここでは、storeStatus命令の第１オペランドにデスティネーションレジスタとして汎用レジスタxn(n=0,1,2,…, 31)の一つを指定する。そして、storeStatus命令の第２オペランドにソースレジスタとしてステータスレジスタsxn(n=0,1,2,…, 31)の一つを指定する。
実行回路３０（図１５参照）は、このstoreStatus命令を実行することにより、ステータスレジスタsxn(n=0,1,2,…, 31)にあるステータス情報Qを汎用レジスタxn(n=0,1,2,…, 31)に保存する。
なお、ソースレジスタとデスティネーションレジスタの各々のインデックスは同一である必要はなく、インデックスが異なるレジスタ間でステータス情報Qを移動させてもよい。
また、storeStatus命令で汎用レジスタxn(n=0,1,2,…, 31)の一つに保存したステータス情報Qをデータメモリ２８ｂに保存するには、汎用レジスタxn(n=0,1,2,…, 31)のデータをデータメモリに格納するstore命令を使用すればよい。
このように実行回路３０がstoreStatus命令とstore命令とを実行することにより、ステータスレジスタsxn(n=0,1,2,…, 31)のステータス情報Qをデータメモリ２８ｂに退避させることができる。
一方、loadStatus命令は、第１のロード命令の一例であって、汎用レジスタxn(n=0,1,2,…, 31)に保存されているステータス情報Qをステータスレジスタsxn(n=0,1,2,…, 31)に書き込む命令である。
ここでは、loadStatus命令の第１オペランドにデスティネーションレジスタとしてステータスレジスタsxn(n=0,1,2,…, 31)の一つを指定する。そして、loadStatus命令の第２オペランドにソースレジスタとして汎用レジスタxn(n=0,1,2,…, 31)の一つを指定する。
実行回路３０（図１５参照）は、このloadStatus命令を実行することにより、汎用レジスタxn(n=0,1,2,…, 31)に保存されているステータス情報Qをステータスレジスタsxn(n=0,1,2,…, 31)に書き込む。
storeStatus命令と同様に、loadStatus命令においてもソースレジスタとデスティネーションレジスタの各々のインデックスは同一である必要はなく、インデックスが異なるレジスタ間でステータス情報Qを移動させてもよい。
なお、データメモリ２８ｂに退避しておいたステータス情報Qを汎用レジスタxn(n=0,1,2,…, 31)の一つに保存するにはデータメモリ２８ｂのデータを汎用レジスタに書き込むload命令を使用すればよい。
上記のようなstoreStatus命令やloadStatus命令を実行回路３０（図１５参照）が実行することにより、ステータスレジスタsxn(n=0,1,2,…, 31)とデータメモリ２８ｂとの間でステータス情報Qの退避や復元を行うことができる。
なお、この例ではstoreStatus命令とloadStatus命令の各々のオペランドにステータスレジスタsxn(n=0,1,2,…, 31)を指定したが、これに代えてステータスレジスタsvn(n=0,1,2,…, 31)を指定してもよい。同様に、storeStatus命令とloadStatus命令の各々のオペランドに指定された汎用レジスタxn(n=0,1,2,…, 31)に代えてベクトルレジスタvn(n=0,1,2,…, 31)を使用してもよい。
ところで、図２０の例では、データメモリ２８ｂとステータスレジスタsxn(n=0,1,2,…, 31)との間でのステータス情報Qの退避と復元とを汎用レジスタxn(n=0,1,2,…, 31)を介して行った。
このように汎用レジスタxn(n=0,1,2,…, 31)を介してステータス情報Qの退避と復元とを行うのではなく、次のような命令を利用することにより、ステータスレジスタsxn(n=0,1,2,…, 31)とデータメモリ２８ｂとの間でステータス情報Qの退避と復元とを直接行ってもよい。
図２１は、本実施形態に係るsaveStatus命令とloadStatus命令について模式的に示す図（その１）である。
saveSatus命令は、第２のストア命令の一例であって、ステータスレジスタsxn(n=0,1,2,…, 31)に格納されているステータス情報Qをデータメモリ２８ｂに保存する命令である。
ここでは、saveStatus命令の第１オペランドにアドレスを指定し、第２オペランドにステータスレジスタsxn(n=0,1,2,…, 31)を指定する。実行回路３０は、このsaveStatus命令を実行することにより、第２オペランドのステータスレジスタsxn(n=0,1,2,…, 31)にあるステータス情報Qを、第１オペランドのアドレスのデータメモリ２８ｂに保存する。
なお、データメモリ２８ｂに保存されたステータス情報Qをステータスレジスタsxn(n=0,1,2,…, 31)に保存するにはloadStatus命令を利用すればよい。
但し、図２０のようにレジスタ間でのデータの転送を行うloadStatus命令と区別するために、ここでは図２０とは異なる書式でloadStatus命令を記述する。図２１の例では、loadStatus命令の第１オペランドにステータスレジスタsxn(n=0,1,2,…, 31)を指定し、第２オペランドにアドレスを指定する。実行回路３０は、この書式のloadStatus命令を実行することにより、第２オペランドのアドレスにあるデータメモリ２８ｂのステータス情報Qを、第１オペランドのステータスレジスタsxn(n=0,1,2,…, 31)に書き込む。なお、この書式を採用したloadStatus命令は、第２のロード命令の一例である。
このように実行回路３０がsaveStatus命令とloadStatus命令を実行すると、汎用レジスタxn(n=0,1,2,…, 31)を介さずにステータス情報Qの退避と復元とを行うことができるため、プログラムの実行速度を高速化できる。
なお、図２０と図２１の例では、ステータス情報Qの退避先や復元先が一つのレジスタのみであるが、次のように全てのレジスタで一括して退避と復元をすると便利な場合もある。
図２２は、本実施形態に係るsaveStatus命令とloadStatus命令について模式的に示す図（その２）である。
図２１の二つのオペランドをとるsaveStatus命令の書式とは異なり、この例では、開発者が一つのオペランドのみをとるようにsaveStatus命令を記述する。実行回路３０は、このsaveStatus命令を実行することにより、オペランドのアドレスのデータメモリ２８ｂに、全てのステータスレジスタsxn、svn(n=0, 1, …31)に格納されている全てのステータス情報Qを一括して保存する。なお、このsaveStatus命令は第３のストア命令の一例である。
一方、loadStatus命令についても、図２１のように二つのオペランドをとる書式とは異なり、アドレスを指定する一つのオペランドのみをとるように記述する。実行回路３０は、このloadStatus命令を実行することにより、指定されたアドレスのデータメモリ２８ｂにある全てのステータス情報Qの各々を、対応するステータスレジスタsxn、svn(n=0, 1, …31)の各々に一括して書き込む。なお、このloadStatus命令は第３のロード命令の一例である。
図２０～図２２のうちのどの命令を使用してステータス情報Qの退避と復元とを行うかは特に限定されない。但し、コンテキストスイッチの場合には、どの命令を使用するのかをABI(Application Binary Interface)に基づいて開発者が決定するのが好ましい。ABIは、サブルーチンを呼び出す側(caller)の責任で退避と復元とを行うレジスタと、呼び出された側(callee)の責任で退避と復元とを行うレジスタとをプロセッサごとに定めた規約である。
例えば、プロセッサ２０がARMv8-Aアーキテクチャに準拠している場合、callee側が汎用レジスタx19～x28とベクトルレジスタv8～v15の各々におけるデータの退避と復元とを行うことが定められている。この規約に従うと、データの退避と復元とをするのに合わせて、これらのレジスタに対応したステータスレジスタsx19～sx28、sv8～sv15に格納されているステータス情報Qについても退避と復元を行うことになる。この場合に図２２のように全てのステータスレジスタとデータメモリ２８ｂとの間で退避と復元とを行う命令を使用すると、退避や復元をする必要がないレジスタのデータまで処理する必要が生じ、プログラムの実行速度が低下する。よって、サブルーチンコールの場合には、図２０や図２１のようにステータスレジスタsxn、svn(n=0, 1, …31)ごとに退避や復元を行う命令を使用し、プログラムの実行速度を向上させるのが好ましい。
一方、OSのコンテキストスイッチの場合には、全ての汎用レジスタx0～x31と全てのベクトルレジスタv0～v31のデータに対して退避と復元とが行われる。よって、コンテキストスイッチの場合には、図２２のように全てのステータスレジスタとデータメモリ２８ｂとの間で退避と復元とを行う命令を使用し、プログラムのコードサイズを小さくするのが好ましい。
ところで、プロセッサ２０においては、上記のように開発者が自ら記述したアセンブリ言語のソースコードの記述ミスに対して例外信号生成回路４２が例外信号を出力するが、場合によっては例外信号が不要な場合もある。
例えば、開発者が手作業で記述したアセンブリ言語のソースコードではなく、コンパイラが出力したアセンブリ言語のソースコードには、コンパイラの最適化が不十分なことに起因して無意味な命令が含まれることがある。その命令に対して例外検出回路４１が例外を検出すると、手作業に由来したミスを検出するという目的から外れた場合にも例外が検出されることになり、例外の過検知となって煩わしい。
そこで、本実施形態では、以下のようにして例外検出回路４１の機能を抑制する。
図２３（ａ）は、例外検出回路４１の機能を抑制するときのアセンブリ言語のソースコードの模式図である。
このソースコード５３においては、開発者が、例外を検出したくない命令列５３ａの前にdisableExeptGen命令を記述する。そして、開発者が、その命令列５３ａの後にenableExeptGen命令を記述する。なお、disableExeptGen命令は無効命令の一例であり、enableExeptGen命令は有効命令の一例である。
実行回路３０がdisableExeptGen命令を実行すると、実行回路３０が例外検出回路４１（図１８参照）に無効信号を通知する。無効信号は、例外の検出を行うという例外検出回路４１の機能を無効にする信号である。よって、その無効信号を受けた例外検出回路４１は、命令列５３ａにおける例外の検出を行わない。その結果、仮に命令列５３ａに例外が発生するような記述ミスが含まれていても、例外信号生成回路４２は例外信号を生成しないことになる。
また、命令列５３ａの実行が終わって実行回路３０がenableExeptGen命令を実行すると、実行回路３０が例外検出回路４１に有効信号を通知する。有効信号は、例外を検出するという例外検出回路４１の機能を有効にする信号である。よって、その有効通知を受けた例外検出回路４１は、enableExeptGen命令の後続命令において例外の検出を行う。これにより、enableExeptGen命令の後続の命令列５３ｂで例外が発生した場合には、例外信号生成回路４２が例外信号を生成することになる。
このようにdisableExeptGen命令とenableExeptGen命令とを利用することにより、命令列５３ａの実行時に例外信号が発生するのを抑制したり、例外信号の発生を再開させたりすることができる。
なお、以下のようにdisableExeptGen命令とenableExeptGen命令の各々にオペランドを記述してもよい。
図２３（ｂ）は、disableExeptGen命令にオペランドを記述した例の模式図である。
この例では、disableExeptGen命令の第１オペランドに、開発者が複数のステータスレジスタsxn、svn(n=0,1,2,…, 31)のうちの一つを記述する。そして、第２オペランドには、複数の例外の種類の各々を識別する識別子を開発者が記述する。ここでは、W例外の識別子を「W」、R例外の識別子を「R」、データタイプ例外の識別子を「DataType」、データサイズ例外の識別子を「DataSize」、srcデータタイプ例外の識別子を「SrcDataType」とする。
この書式のdisableExeptGen命令を実行回路３０が実行すると、第１オペランドのステータスレジスタsxn、svnにあるステータス情報Qを用いて第２オペランドの例外を検出するという例外検出回路４１の機能が無効となる。例えば、「disableExeptGen sx0, W|R」と記述した場合には、ステータスレジスタsx0に格納されているステータス情報Qを用いてW例外とR例外とを検出する機能が無効となる。
一方、図２３（ｃ）は、enableExeptGen命令にオペランドを記述した例の模式図である。
この例では、enableExeptGen命令の第１オペランドに、開発者が複数のステータスレジスタsxn、svn(n=0, 1, …31)のうちの一つを記述する。そして、第２オペランドには、複数の例外の種類の各々を識別する識別子を開発者が記述する。
この書式のenableExeptGen命令を実行回路３０が実行すると、第１オペランドのステータスレジスタsxn、svn(n=0, 1, …31)にあるステータス情報Qを用いて第２オペランドの例外を検出するという例外検出回路４１の機能が有効となる。例えば、「enableExeptGen sx0, W」と記述した場合には、ステータスレジスタsx0に格納されているステータス情報Qを用いてW例外を生成するかを判定する機能が有効となる。
このように、disableExeptGen命令とenableExeptGen命令の各々にオペランドを記述することにより、検出対象の例外の種類を選択できる。更に、その例外を検出するのに使用するステータス情報Qの格納先であるステータスレジスタを指定することができ、開発者の利便性が向上する。
（第２実施形態）
本実施形態では、第１実施形態で説明したプロセッサ２０の動作を模擬するシミュレーションプログラムについて説明する。
図２４は、シミュレーションプログラムを実行する情報処理装置のハードウェア構成図である。
この情報処理装置６０は、PC(Personal Computer)等の計算機であって、記憶装置６０ａ、メモリ６０ｂ、プロセッサ６０ｃ、通信インターフェース６０ｄ、表示装置６０ｅ、及び入力装置６０ｆを有する。これらの各部は、バス６０ｇにより相互に接続される。
このうち、記憶装置６０ａは、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性のストレージデバイスであり、本実施形態に係るシミュレーションプログラム６１を記憶する。
なお、シミュレーションプログラム６１をコンピュータが読み取り可能な記録媒体６０ｈに記録させておき、プロセッサ６０ｃに記録媒体６０ｈのシミュレーションプログラム６１を読み取らせるようにしてもよい。
そのような記録媒体６０ｈとしては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体６０ｈとして使用してもよい。これらの記録媒体６０ｈは、物理的な形態を持たない搬送波のような一時的な媒体ではない。
更に、公衆回線、インターネット、及びLAN(Local Area Network)等に接続された装置にシミュレーションプログラム６１を記憶させておき、プロセッサ６０ｃがそのプログラム６１を読み出して実行するようにしてもよい。
一方、メモリ６０ｂは、DRAM等のようにデータを一時的に記憶するハードウェアであって、その上に前述のシミュレーションプログラム６１が展開される。
プロセッサ６０ｃは、情報処理装置６０の各部を制御したり、メモリ６０ｂと協働してシミュレーションプログラム６１を実行したりするCPU(Central Processing Unit)やGPU(Graphical Processing Unit)等のハードウェアである。
更に、通信インターフェース６０ｄは、情報処理装置６０をLAN等のネットワークに接続するためのインターフェースである。
そして、表示装置６０ｅは、液晶表示装置等のハードウェアであって、開発者に種々の情報を表示する。また、入力装置６０ｆは、キーボードやマウス等のハードウェアである。例えば、開発者は、入力装置６０ｆを操作することにより、情報処理装置６０に対して種々の指示を出すことになる。
図２５は、情報処理装置６０がシミュレーションプログラム６１を実行したときの情報処理装置６０の機能構成図である。
図２５に示すように、情報処理装置６０は、制御部６３と記憶部６４とを備える。
このうち、制御部６３は、プロセッサ６０ｃとメモリ６０ｂがシミュレーションプログラム６１を実行することにより実現される処理部であり、環境構築部６５とシミュレーション実行部６６とを有する。
環境構築部６５は、プロセッサ２０を模擬した疑似プロセッサを生成する処理部である。また、シミュレーション実行部６６は、開発者からの指示を受け付けて、環境構築部６５が生成した疑似プロセッサでシミュレーションを実行する処理部である。
一方、記憶部６４は、記憶装置６０ａとメモリ６０ｂとにより実現され、シミュレーション対象のプロセッサ２０（図１５参照）が実行する機械語の実行可能プログラム６７を記憶する。その実行可能プログラム６７は、開発者が手作業で記述したアセンブリ言語のソースコードをアセンブルして得られた機械語のプログラムである。
なお、情報処理装置６０におけるプロセッサ６０ｃは、シミュレーション対象のプロセッサ２０と同一である必要はなく、プロセッサ２０と異なる命令セットを実行するプロセッサでもよい。これにより、シミュレーション対象のプロセッサ２０が手元にない状況でもその動作を模擬でき、プロセッサ２０が実行する実行可能プログラムの開発効率が上がる。
図２６は、環境構築部６５が生成した疑似プロセッサ７０の機能ブロック図である。
疑似プロセッサ７０は、命令デコード部７１、データフェッチ部７２、命令実行部７３、書き戻し部７４、例外処理部７５、ステータスレジスタファイル部７６、及び演算用レジスタファイル部７７を有する。更に、疑似プロセッサ７０は、命令メモリ部７８ａとデータメモリ部７８ｂとを備えたメモリ部７８を有する。
これらの各部は、第１実施形態に係るプロセッサ２０の各部の機能をソフトウェア的に実現したものであり、メモリ６０ｂとプロセッサ６０ｃが協働してシミュレーションプログラム６１を実行することにより実現される。
図２７は、第１実施形態に係るプロセッサ２０の各部と、本実施形態に係る疑似プロセッサ７０の各部との対応関係を示す図である。
図２７においては、同一の機能を有する要素同士を矢印で示している。例えば、命令デコード部７１は、命令デコード回路２１をソフトウェア的に実現した機能ブロックであり、命令デコード回路２１と同一の機能を有する。
また、命令デコード部７１以外の各部も、プロセッサ２０において対応する要素と同一の機能を有する。その機能については第１実施形態で説明したため、以下ではその説明を省略する。
なお、疑似プロセッサ７０の各部をソフトウェアで実現する具体的な方法は特に限定されない。例えば、演算用レジスタファイル部７７は、メモリ６０ｂに確保された第１の記憶領域７７ａで実現される。そして、演算用レジスタファイル部７７の汎用レジスタxn(n=0,1,2,…, 31)とベクトルレジスタvn(n=0,1,2,…, 31)は、第１の記憶領域７７ａに格納される配列要素で実現され、配列要素のインデックスが各レジスタのインデックスとなる。
同様に、ステータスレジスタファイル部７６は、メモリ６０ｂに確保された第２の記憶領域７６ａで実現される。そして、ステータスレジスタファイル部７６のステータスレジスタsxn、svn(n=0,1,2,…, 31)は、第２の記憶領域７６ａに格納される配列要素で実現され、配列要素のインデックスが各ステータスレジスタのインデックスとなる。
また、メモリ２８は、メモリ６０ｂに確保された第３の記憶領域７８ｃで模擬することができる。
次に、本実施形態に係るシミュレーション方法について説明する。
図２８は、本実施形態に係るシミュレーション方法について説明するためのフローチャートである。
まず、環境構築部６５が、疑似プロセッサ７０の各部を生成する（ステップＳ１１）。例えば、環境構築部６５は、汎用レジスタxn(n=0,1,2,…, 31)とベクトルレジスタvn(n=0,1,2,…, 31)とを模擬する第１の記憶領域７７ａと、ステータスレジスタsxn、svn(n=0,1,2,…, 31)を模擬する第２の記憶領域７６ａとをメモリ６０ｂに確保する。また、メモリ２８を模擬するために、環境構築部６５は、メモリ６０ｂに第３の記憶領域７８ｃを確保する。
更に、環境構築部６５は、実行可能プログラム６７を読み込んでそれを命令メモリ部７８ａに格納する（ステップＳ１２）。
次に、環境構築部６５が、ステータスレジスタファイル部７６を初期化する（ステップＳ１３）。例えば、環境構築部６５は、ステータスレジスタファイル部７６におけるステータスレジスタsxn、svn(n=0,1,2,…, 31)を模擬する配列を初期化する。例えば、WフラグとRフラグの各々0に設定され、データタイプDTとデータサイズDSの各々は不定を表すビット列に設定される。
次に、命令デコード部７１が、命令メモリ部７８ａに格納されている機械語の命令を読み出す（ステップＳ１４）。
そして、命令デコード部７１がその命令をデコードし、デコード内容をデータフェッチ部７２、命令実行部７３、及び書き戻し部７４の各々に出力する（ステップＳ１５）。デコード内容としては、命令の種類、ソースレジスタとデスティネーションレジスタの各々のインデックス、ソースレジスタの要素のデータサイズ、ソースレジスタのデータタイプ等がある。
次に、データフェッチ部７２が、デコード内容に基づいて、演算用レジスタファイル部７７とデータメモリ部７８ｂのいずれか一方からデータを読み出し、それを命令実行部７３に出力する（ステップＳ１６）。
次いで、実行部８３が命令を実行する（ステップＳ１７）。
そして、命令実行部７３の第１の例外検出部８２ａが、アセンブリ言語の記述ミスとは無関係の例外を検出する（ステップＳ１８）。そのような例外としては、未実装命令を実行しようとしたときの例外や、０除算を使用としたときの例外がある。
更に、ステップＳ１８では、命令実行部７３の第２の例外検出部８２ｂが、アセンブリ言語の記述ミスに起因した例外を検出する。例えば、第２の例外検出部８２ｂは、ステータスレジスタファイル部７６にあるステータス情報Qと、命令デコード部７１が出力したデコード内容とに基づいて例外を検出する。なお、第２の例外検出部８２ｂが行う例外検出処理の詳細については後述する。
次いで、第１の例外検出部８２ａと第２の例外検出部８２ｂの各々が、例外検出処理の結果に基づいて、例外を検出したかどうかを判定する（ステップＳ１９）。
ここで、第１の例外検出部８２ａと第２の例外検出部８２ｂのいずれもが例外を検出しないと判断した場合（ステップＳ１９：否定）には、実行部８３が、命令の実行結果を書き戻し部７４に出力する（ステップＳ２０）。
一方、第１の例外検出部８２ａが例外を検出したと判断した場合（ステップＳ１９：肯定）は、第１の例外検出部８２ａは、例外信号を生成してそれを例外処理部７５に出力する（ステップＳ２０）。なお、第２の例外検出部８２ｂが例外を検出した判断した場合（ステップＳ１９：肯定）も、第２の例外検出部８２ｂは、例外信号を生成してそれを例外処理部７５に出力する（ステップＳ２０）。
そして、その例外信号を受けた例外処理部７５は、ジャンプ先のアドレスを例外ベクタテーブル５０（図１９参照）から特定し、特定したジャンプ先のアドレスを命令デコード部７１に通知する（ステップＳ２１）。
この後は、実行可能プログラム６７の各命令に対してステップＳ１４～Ｓ２２を繰り返して行う。そして、実行可能プログラム６７の全ての命令に対してＳ１４～Ｓ２２を終了すると、本実施形態に係るシミュレーション方法を終える。
次に、ステップＳ１８の例外検出処理について説明する。
図２９は、ステップＳ１８の例外検出処理のフローチャートである。
まず、第２の例外検出部８２ｂが、データタイプ例外があるかどうかをチェックする（ステップＳ３１）。例えば、第２の例外検出部８２ｂは、ステップＳ１７で実行した命令のソースレジスタのステータス情報Qをステータスレジスタファイル部７６から読み出す。そして、第２の例外検出部８２ｂは、そのステータス情報Qの型情報DTが示すデータタイプと、命令が演算の対象とするデータタイプとが一致しない場合にデータタイプ例外を検出する。
次に、第２の例外検出部８２ｂが、ステップＳ３１で読み出したステータス情報Qを用いて、データサイズ例外があるかどうかをチェックする（ステップＳ３２）。例えば、第２の例外検出部８２ｂは、そのステータス情報Qのサイズ情報DSが示すデータサイズと、ステップＳ１７で実行した命令においてソースレジスタに期待されるデータサイズとが一致しない場合にデータサイズ例外を検出する。
次いで、第２の例外検出部８２ｂが、W例外があるかどうかをチェックする（ステップＳ３３）。そのチェックは、ステップＳ３１で読み出したステータス情報Qを用いて行われる。例えば、第２の例外検出部８２ｂは、ステータス情報Qにおける第１のフラグWが「0」の場合にW例外を検出する。
続いて、第２の例外検出部８２ｂが、そのステータス情報Qの第１のフラグWと第２のフラグRとに基づいてR例外があるかどうかをチェックする（ステップＳ３４）。一例として、第２の例外検出部８２ｂは、第１のフラグWが「1」であり、かつ第２のフラグRが「0」の場合にR例外を検出する。
次に、第２の例外検出部８２ｂが、srcデータタイプ例外があるかどうかをチェックする（ステップＳ３５）。例えば、第２の例外検出部８２ｂは、ステップＳ１７で実行した命令が、二つのソースレジスタのデータタイプが同一であることを前提とする命令かどうかを判断する。ここで、二つのソースレジスタのデータタイプが同一であることを前提とする命令であると判断したときは、第２の例外検出部８２ｂは、当該命令の各ソースレジスタのステータス情報Qをステータスレジスタファイル部７６から読み出す。そして、例外検出部８２は、これらのステータス情報Qの各々の型情報DTが示すデータサイズ同士が一致しない場合にsrcデータタイプ例外を検出する。
以上により、ステップＳ１８の例外検出処理を終える。
以上説明した本実施形態によれば、第１実施形態に係るプロセッサ２０において実行可能プログラム６７の命令を実際に実行しなくても、その実行可能プログラム６７に記述ミスがあるかどうかを情報処理装置６０でチェックできる。
更に、このように情報処理装置６０で記述ミスをチェックできるため、記述ミスのあるプログラムをプロセッサ２０で無駄に実行する時間が減り、プロセッサ２０やメモリ２８等のハードウェア資源の無駄な消費を改善できる。
しかも、ステップＳ１８の例外検出処理においては、第１実施形態と同様にステータス情報Qを利用して例外を検出する。そのため、開発者が手作業でアセンブリを記述したときのミスに由来するデータタイプ例外、データサイズ例外、W例外、R例外、及びsrcデータタイプ例外の各々を検出することができる。そして、この例外に基づいて開発者がデバッグすることができ、アセンブリ言語のプログラムの開発効率を高めることができる。
なお、本実施形態は上記に限定されない。
例えば、第１実施形態の図２０～図２２で説明したloadStatus命令、storeStatus命令、及びsaveStatus命令を実行部８３が実行してもよい。これにより、第２の記憶領域７６ａ（図２７参照）で模擬されるステータスレジスタsxn、svn(n=0,1,2,…, 31)のデータの退避や復元をすることができ、サブルーチンコールやOSのコンテキストスイッチを模擬することができる。
更に、第１実施形態の図２３（ａ）～（ｃ）のdisableExceptGen命令やenableExceptGen命令を開発者がアセンブリ言語のソースコードに記述し、例外検出部８２が例外を検出する機能を無効にしたり有効にしたりしてもよい。
（第３実施形態）
第１実施形態では、プロセッサ２０が実行可能プログラムを実行するときに、アセンブリ言語の記述ミスに起因した例外をプロセッサ２０が検出した。
これに対し、本実施形態では、アセンブリ言語の記述ミスがあった場合に、アセンブリ言語から機械語の実行可能プログラムを生成するアセンブラプログラムがエラーを出力する。
図３０は、本実施形態において実行可能プログラムを実行するターゲットマシンが備えるプロセッサ９０の構成図である。
なお、図３０において、第１実施形態の図１５で説明したのと同じ要素には図１５におけるのと同じ符号を付し、以下ではその説明を省略する。
本実施形態では、第１実施形態とは異なり、ステータスレジスタファイル２６（図１５参照）に格納されたステータス情報Qを利用してプロセッサ９０が例外を検出しない。そのため、このプロセッサ９０は、第１実施形態に係るプロセッサ２０からステータスレジスタファイル２６、ステータス更新回路３１、及び第２の例外検出部３２ｂを省いたハードウェア構成を有する。これらの回路以外の各部の動作は第１実施形態と同様である。
このプロセッサ９０で実行される機械語の実行可能プログラムは、以下のように本実施形態に係るアセンブラプログラムで生成される。
図３１は、本実施形態に係るアセンブラプログラムを実行する情報処理装置のハードウェア構成図である。
この情報処理装置１００は、PC等の計算機であって、記憶装置１００ａ、メモリ１００ｂ、プロセッサ１００ｃ、通信インターフェース１００ｄ、表示装置１００ｅ、及び入力装置１００ｆを有する。これらの各部は、バス１００ｇにより相互に接続される。
記憶装置１００ａは、HDDやSSD等の不揮発性のストレージデバイスであり、本実施形態に係るアセンブラプログラム１１２を記憶する。
なお、アセンブラプログラム１１２をコンピュータが読み取り可能な記録媒体１００ｈに記録させておき、プロセッサ１００ｃに記録媒体１００ｈのアセンブラプログラム１１２を読み取らせるようにしてもよい。
そのような記録媒体１００ｈとしては、例えばCD-ROM、DVD、及びUSBメモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体１００ｈとして使用してもよい。これらの記録媒体１００ｈは、物理的な形態を持たない搬送波のような一時的な媒体ではない。
更に、公衆回線、インターネット、及びLAN等に接続された装置にアセンブラプログラム１１２を記憶させておき、プロセッサ１００ｃがそのアセンブラプログラム１１２を読み出して実行するようにしてもよい。
一方、メモリ１００ｂは、DRAM等のようにデータを一時的に記憶するハードウェアであって、その上に前述のアセンブラプログラム１１２が展開される。
プロセッサ１００ｃは、情報処理装置１００の各部を制御したり、メモリ１００ｂと協働してアセンブラプログラム１１２を実行したりするCPUやGPU等のハードウェアである。
更に、通信インターフェース１００ｄは、情報処理装置１００をLAN等のネットワークに接続するためのインターフェースである。
そして、表示装置１００ｅは、液晶表示装置等のハードウェアであって、開発者に種々の情報を表示する。また、入力装置１００ｆは、キーボードやマウス等のハードウェアである。例えば、開発者は、入力装置１００ｆを操作することにより、情報処理装置１００に対して種々の指示を出すことになる。
図３２は、情報処理装置１００がアセンブラプログラム１１２を実行したときの情報処理装置１００の機能構成図である。
図３２に示すように、情報処理装置１００は、制御部１０１と記憶部１０２とを備える。
このうち、記憶部１０２は、記憶装置１００ａとメモリ１００ｂとにより実現され、アセンブルの対象となるアセンブリ言語のソースプログラム１０９を記憶する。また、記憶部１０２は、そのアセンブリ言語のソースプログラム１０９に記述ミスがあるかを判定するのに使用されるステータス情報１１０も記憶する。このステータス情報１１０の詳細については後述する。
更に、記憶部１０２は、アセンブリ言語のソースプログラム１０９をアセンブルして得られた機械語の実行可能プログラム１１１も記憶する。
一方、制御部１０１は、初期化部１０３、取得部１０４、例外検出部１０５、エラー出力部１０６、ステータス更新部１０７、及び機械語生成部１０８を有する。
このうち、初期化部１０３は、アセンブルに先立ってステータス情報１１０を初期化する処理部である。また、取得部１０４は、アセンブル対象のアセンブリ言語のソースプログラム１０９を記憶部１０２から取得する処理部である。
例外検出部１０５は、ステータス情報１１０に基づいて、ソースプログラム１０９に記述された命令における例外を検出する処理部である。例えば、オペランドに汎用レジスタxn(n=0,1,2,…, 31)やベクトルレジスタvn(n=0,1,2,…, 31)が指定された命令を含むアセンブリ言語のコードを取得部１０４が取得すると、例外検出部１０５は、その命令における例外を検出する。
そして、エラー出力部１０６は、例外検出部１０５が例外を検出したときにエラーを出力する処理部である。
一方、ステータス更新部１０７は、例外検出部１０５が例外を検出しなかったときにステータス情報１１０の内容を更新する処理部である。そして、機械語生成部１０８は、例外検出部１０５が例外を検出しなかったときに、アセンブリ言語のコードをアセンブルして機械語を生成し、その機械語を含む実行可能プログラム１１１を記憶部１０２に書き出す処理部である。
次に、ステータス情報１１０について説明する。
ステータス情報１１０は、演算用レジスタファイル２７（図３０参照）に設けられた汎用レジスタxn(n=0,1,2,…, 31)とベクトルレジスタvn(n=0,1,2,…, 31)の各々のステータスを示す情報である。ステータス情報１１０の実現方法は特に限定されないが、本実施形態では配列でステータス情報１１０を実現する。
図３３は、本実施形態に係るステータス情報を表すC++のソースコードの模式図である。
このステータス情報１１０において、コードT20は、汎用レジスタxn(n=0,1,2,…, 31)とベクトルレジスタvn(n=0,1,2,…, 31)の各々のデータサイズを示す列挙型「dataSize_t」のメンバ変数を宣言するコードである。そのメンバ変数としては、バイトを示す「sizeB」、ハーフワードを示す「sizeH」、シングルワードを示す「sizeS」、ダブルワードを示す「sizeD」、及び１２８ビットを示す「sizeX」がある。
また、コードT20においては、汎用レジスタxn(n=0,1,2,…, 31)やベクトルレジスタvn(n=0,1,2,…, 31)にデータが格納されておらずデータサイズが不定であることを示す「CLEAN」も列挙型「dataSize_t」のメンバ変数として宣言される。
コードT21は、ベクトルレジスタvn(n=0, 1, …31)に格納されたベクトルデータの要素のデータサイズを格納するための配列を宣言するコードである。ここでは、ベクトルレジスタvn(n=0,1,2,…, 31)用の配列として配列「dataSizeVReg」を宣言する。
なお、この配列「dataSizeVReg」の各々の要素は、対応するベクトルレジスタに格納されているベクトルデータの要素のデータサイズを示す型情報の一例である。
また、本実施形態では、配列要素のインデックスがレジスタのインデックスを表すものとする。例えば、dataSizeVReg[0], dataSizeVReg [1],…dataSizeVReg [31]がベクトルレジスタv0、v1、…v31の各々のデータサイズ示す。
なお、この例ではコードT21において各配列「dataSizeVReg」の全ての要素を「CLEAN」に初期化しておく。
一方、コードT22は、汎用レジスタxn(n=0, 1, …31)とベクトルレジスタvn(n=0, 1, …31)の各々のデータタイプを示す列挙型「dataType」のメンバ変数を宣言するコードである。そのメンバ変数としては、符号なし整数を示す「typeUnsigned」、符号あり整数を示す「typeSigned」、及び浮動小数を示す「typeFloat」がある。
また、コードT22においては、汎用レジスタxn(n=0, 1, …31)やベクトルレジスタvn(n=0, 1, …31)にデータが格納されておらずデータタイプが不定であることを示す「CLEAN」も列挙型「dataType_t」のメンバ変数として宣言される。
コードT23は、汎用レジスタxn(n=0, 1, …31)とベクトルレジスタvn(n=0, 1, …31)の各々のデータタイプを格納するための配列を宣言するコードである。本実施形態では、汎用レジスタxn用の配列として配列「dataTypeGReg」を宣言し、ベクトルレジスタ用の配列として配列「dataTypeVReg」を宣言する。
なお、これらの配列「dataTypeGReg」、「dataTypeVReg」の各々の要素は、対応するレジスタに格納されているデータのデータタイプを示す型情報の一例である。
また、データサイズの例と同様に、コードT23においても配列要素のインデックスがレジスタのインデックスを表すものとする。例えば、dataTypeGReg[0], dataTypeGReg [1],…dataTypeGReg [31]が汎用レジスタx0、x1、…x31の各々のデータサイズ示し、dataTypeVReg[0], dataTypeVReg [1],…dataTypeVReg [31]がベクトルレジスタv0、v1、…v31の各々のデータサイズ示す。
なお、この例では、コードT23において配列「dataTypeGReg」、「dataTypeVReg」の全ての要素を「CLEAN」に初期化しておく。
そして、コードT24は、汎用レジスタxn(n=0, 1, …31)とベクトルレジスタvn(n=0, 1, …31)の各々がソースレジスタとして使用済みかどうかを示す列挙型「readAccess_t」のメンバ変数を宣言するコードである。そのメンバ変数としては、ソースレジスタとして使用済みではないことを示す「FALSE」と、ソースレジスタとして使用済みであることを示す「TRUE」とがある。
コードT25は、列挙型「readAccess_t」のメンバ変数を格納するための配列を宣言するコードである。ここでは、汎用レジスタxn(n=0, 1, …31)用の配列として配列「readAccessGReg」を宣言し、ベクトルレジスタvn(n=0, 1, …31)用の配列として配列「readAccessVReg」を宣言する。
なお、配列「readAccessGReg」、「readAccessVReg」の各々の要素は、対応するレジスタがソースレジスタとして使用済かどうかを示す第２のフラグの一例である。
また、これらの配列「readAccessGReg」、「readAccessVReg」の各々の要素のインデックスは、レジスタのインデックスに等しいものとする。例えば、readAccessGReg[0], readAccessGReg[1],…readAccessGReg[31]が汎用レジスタx0、x1、…x31の各々に対応し、readAccessVReg[0], readAccessVReg[1],…readAccessVReg[31]がベクトルレジスタv0、v1、…v31に対応する。
一方、コードT26は、汎用レジスタxn(n=0, 1, …31)とベクトルレジスタvn(n=0, 1, …31)の各々がデスティネーションレジスタとして使用済みかどうかを示す列挙型「writeAccess_t」のメンバ変数を宣言するコードである。そのメンバ変数としては、デスティネーションレジスタとして使用済みではないことを示す「FALSE」と、デスティネーションレジスタとして使用済みであることを示す「TRUE」とがある。
コードT27は、列挙型「writeAccess_t」のメンバ変数を格納するための配列を宣言するコードである。ここでは、汎用レジスタxn(n=0, 1, …31)用の配列として配列「writeAccessGReg」を宣言し、ベクトルレジスタvn(n=0, 1, …31)用の配列として配列「writeAccessVReg」を宣言する。
なお、配列「writeAccessGReg」、「writeAccessVReg」の各々の要素は、対応するレジスタがデスティネーションレジスタとして使用済かどうかを示す第１のフラグの一例である。
また、これらの配列「writeAccessGReg」、「writeAccessVReg」の各々の要素のインデックスは、レジスタのインデックスに等しいものとする。例えば、writeAccessGReg[0], writeAccessGReg[1],…writeAccessGReg[31]が汎用レジスタx0、x1、…x31の各々に対応し、writeAccessVReg[0], writeAccessVReg[1],…writeAccessVReg[31]がベクトルレジスタv0、v1、…v31に対応する。
このように、ここでは配列「dataSizeVReg」、「dataTypeGReg」、「dataTypeVReg」、「readAccessGReg」、「readAccessVReg」、「writeAccessVReg」、及び「writeAccessVReg」によってステータス情報１１０を実現する。これらの配列の要素は、例外検出部１０５が例外を検出しなかったときに、ステータス更新部１０７によって更新される。
例えば、オペランドにソースレジスタが指定された命令について例外がなかったときは、ステータス更新部１０７は、そのソースレジスタに対応した「readAccessGReg」又は「readAccessVReg」の要素に「TRUE」を格納する。
そして、オペランドにデスティネーションレジスタが指定された命令について例外がなかったときもステータス更新部１０７は各配列の要素を更新する。この場合は、ステータス更新部１０７は、デスティネーションレジスタに対応した配列「writeAccessGReg」又は「writeAccessVReg」の要素に「TRUE」を格納する。更に、ステータス更新部１０７は、そのデスティネーションレジスタに対応した配列「readAccessGReg」又は「readAccessVReg」の要素に「FALSE」を格納する。これにより、そのデスティネーションレジスタが、データが書き込まれてからまだソースレジスタとして使用されていない状態に設定されることになる。
また、ステータス更新部１０７は、レジスタにデータを書き込む命令がアセンブリ言語のソースプログラム１０９に存在するときに、そのレジスタに対応した配列「dataTypeGReg」又は「dataTypeVReg」を更新する。例えば、ソースプログラム１０９にコード「add x2, x0, x1」が記述されている場合を考える。add命令は、符号あり６４ビット整数の加算命令である。よって、この場合は、ステータス更新部１０７は、汎用レジスタx2に対応する「dataTypeGReg[2]」に「typeSigned」を格納する。このように、ステータス更新部１０７は、配列「dataTypeGReg」又は「dataTypeVReg」の要素に、「typeUnsigned」、「typeSigned」、及び「typeFloat」のちで命令が演算の対象とするデータタイプを格納する。
同様に、ステータス更新部１０７は、ベクトルレジスタにデータを書き込む命令がアセンブリ言語のソースプログラム１０９に存在するときに、そのベクトルレジスタに対応した配列「dataSizeVReg」を更新する。例えば、ソースプログラム１０９に「vadd v3.s, v0.s, v1.s」が記述されている場合を考える。この場合は、デスティネーションレジスタであるベクトルレジスタv3に書き込まれるデータのサイズとしてシングルワード「s」が指定されている。そこで、この場合は、ステータス更新部１０７は、ベクトルレジスタv3に対応する「dataSizeVReg[3]」に「sizeS」を格納する。このように、ステータス更新部１０７は、配列「dataSizeVReg」の要素に、「sizeB」、「sizeH」、「sizeS」、「sizeD」、及び「sizeX」のうちでデスティネーションレジスタに指定されたデータサイズを格納する。
次に、例外検出部１０５が例外を検出するときの検出ルールについて説明する。
図３４（ａ）は、オペランドに汎用レジスタxn(n=0,1,2…31)が指定された場合の検出ルールについて模式的に示す図である。
図３４（ａ）に示すように、オペランドに汎用レジスタが指定された場合に例外検出部１０５が検出対象とする例外には、第１実施形態の図１７で説明した「W例外」、「R例外」、「データタイプ例外」、及び「srcデータタイプ例外」がある。
このうち、W例外は、ある命令のソースレジスタがその命令の先行命令においてデスティネーションレジスタとして使用されていない場合に発生する例外であって、配列「writeAccessGReg」を利用して検出することができる。
例えば、ある命令のソースレジスタが汎用レジスタx0である場合を考える。その汎用レジスタx0に対応した「writeAccessGReg[0]」が「FALSE」の場合には、その汎用レジスタx0は過去にデスティネーションレジスタとして使用されていないことになる。よって、例外検出部１０５は、「writeAccessGReg[0]」が「FALSE」の場合にW例外を検出する。
また、R例外は、先行命令がデータを書き込んだレジスタを後続命令がデスティネーションレジスタとして使用する場合に、先行命令と後続命令の間の全ての命令がそのレジスタをソースレジスタとして使用しない場合の例外である。そのR例外は、配列「writeAccessGReg」と配列「readAccessGReg」とを利用して検出することができる。
例えば、ある命令のデスティネーションレジスタが汎用レジスタx0である場合を考える。その汎用レジスタx0が、過去に別の命令でデスティネーションレジスタとして使用済みの場合には「writeAccessGReg[0]」が「TRUE」となる。また、その汎用レジスタx0が、その後の命令でソースレジスタとして使用されていない場合には「readAccessGReg[0]」が「FALSE」となる。よって、例外検出部１０５は、「writeAccessGReg[0]」が「TRUE」であり、かつ「readAccessGReg[0]」が「FALSE」の場合にR例外を検出する。
また、データタイプ例外は、命令が演算の対象とするデータタイプとソースレジスタに書き込まれている実際のデータのデータタイプとが一致しない場合に発生する例外である。
データタイプ例外は配列「dataTypeGReg」を利用して検出することができる。例えば、取得部１０４が取得したアセンブリ言語のコードが「fadd x2, x0, x1」である場合を考える。この場合、例外検出部１０５は、アセンブリ言語のコードにおける「fadd」との記述から命令の種類がfaddであることを特定し、この命令が演算の対象とするデータのデータタイプが「typeFloat」であることを特定する。更に、例外検出部１０５は、上記のコードの第２オペランドの「x0」との記述に基づいて、この命令のソースレジスタが汎用レジスタx0であることを特定する。
一方、汎用レジスタx0に対応した配列「dataTypeGReg」の要素である「dataTypeGReg[0]」には「typeUnsigned」が格納されているとする。この場合は、「dataTypeGReg[0]」と「typeFloat」とが一致しない。例外検出部１０５は、このように「dataTypeGReg[0]」が「typeFloat」に一致しない場合にデータタイプエラーを検出する。
なお、この例では例外検出部１０５が第２オペランド「x0」についてのデータタイプ例外を検出したが、同様の方法で第３オペランド「x1」についてのデータタイプ例外も例外検出部１０５が検出することができる。
そして、srcデータタイプ例外は、命令の二つのソースレジスタの各々のデータタイプが一致しない場合に発生する例外である。
srcデータタイプ例外は配列「dataTypeGReg」を利用して検出することができる。
例えば、取得部１０４が取得したアセンブリ言語のコードが「multiply x2, x0, x1」である場合を考える。この場合、例外検出部１０５は、アセンブリ言語のコードにおけるにおける「multiply」との記述から命令の種類が「multiply」であることを特定する。そして、例外検出部１０５は、特定したmultiply命令が二つのソースレジスタのデータタイプが同一であることを前提とする命令であることに基づき、汎用レジスタx0、x1に格納されているデータのデータタイプを比較する。
ここで、汎用レジスタx0に格納されているデータタイプが符号無し整数であり、「dataTypeGReg[0]」が「typeUnsigned」であるとする。一方、汎用レジスタx1に格納されているデータタイプが浮動小数であり、「dataTypeGReg[1]」が「typeFloat」であるとする。この場合は、「dataTypeGReg[0]」と「dataTypeGReg[1]」とが一致しない。例外検出部１０５は、このように「dataTypeGReg[0]」と「dataTypeGReg[1]」とが一致しない場合にsrcデータタイプ例外を検出する。
一方、図３４（ｂ）は、オペランドにベクトルレジスタvn(n=0,1,2…31)が指定された場合の検出ルールについて模式的に示す図である。
ベクトルレジスタの場合も、図３４（ａ）の汎用レジスタの場合と同様の検出ルールで「W例外」、「R例外」、「データタイプ例外」、及び「srcデータタイプ例外」を検出できる。
更に、ベクトルレジスタの場合には「データサイズ例外」を検出するための検出ルールもある。
データサイズ例外は、先行命令がレジスタに書き込んだデータのデータサイズと、そのレジスタをソースレジスタとする後続命令において指定されたソースレジスタのデータサイズとが異なる場合に発生する例外である。そのデータサイズ例外は、配列「dataSizeVReg」を利用して検出することができる。
例えば、取得部１０４が取得したアセンブリ言語のコードが「vadd v2.s, v0.s, v1.s」である場合を考える。この場合、例外検出部１０５は、第２オペランドの「v0.s」との記述に基づいて、このvadd命令のソースレジスタに指定されたデータサイズが「sizeS」であることを特定する。更に、例外検出部１０５は、第２オペランドの「v0.s」との記述に基づいて、このvadd命令のソースレジスタがベクトルレジスタv0であることも特定する。
一方、ベクトルレジスタv0に対応した配列「dataSizeVReg」の要素である「dataSizeVReg [0]」には「sizeB」が格納されているとする。この場合は、「dataSizeVReg[0]」は「sizeS」に一致しない。例外検出部１０５は、このように「dataSizeVReg[0]」が「sizeS」に一致しない場合にデータサイズ例外を検出する。
なお、この例では例外検出部１０５が「vadd v2.s, v0.s, v1.s」の第２オペランド「v0.s」についてのデータサイズ例外を検出したが、同様の方法で第３オペランド「v1.s」についてのデータサイズ例外も検出することができる。
以上説明した情報処理装置１００によれば、ステータス情報１１０を利用して、例外検出部１０５が、図３４（ａ）、（ｂ）の検出ルールに従ってアセンブル時に例外を検出する。これにより、アセンブリ言語のソースプログラム１０９に記述ミスがあった場合に例外検出部１０５が例外を検出するようになり、その例外に基づいて開発者がソースプログラム１０９に記述ミスがあったことに気付くことができる。その結果、開発者がソースプログラム１０９を容易にデバッグすることができるようになり、プログラム開発の効率化を図ることができる。
更に、ステータス情報１１０には、「W例外」、「データタイプ例外」、「データサイズ例外」、及び「srcデータタイプ例外」を検出するための配列が定義されている。そのため、そのステータス情報１１０に基づいて、例外検出部１０５が、上記の各例外のうちのどの例外が発生したのかを特定できる。そして、これらのどの例外が検出されたかに応じ、開発者が、ソースプログラム１０９における具体的な記述ミスを特定することができる。
ところで、このように例外検出部１０５が例外を検出するとアセンブリ言語のソースプログラム１０９における記述ミスを発見できるが、場合によっては例外検出部１０５が例外を検出する機能を無効にした方が便利なこともある。
例えば、第１実施形態で説明したように、コンパイラの最適化が不十分であることに起因して無意味なアセンブリ言語のコードがソースプログラム１０９に含まれている場合がある。そのようなコードに対して例外検出部１０５が例外を検出すると、手作業に由来したミスを検出するという目的から外れた場合にも例外が検出されて煩わしい。
そこで、本実施形態では、以下のようにして例外検出部１０５の機能を抑制する。
図３５は、例外検出部１０５の機能を抑制するときのアセンブリ言語のソースプログラム１０９の模式図である。
このソースプログラム１０９においては、開発者が、例外を検出したくない命令列１０９ａの前に、アセンブリ言語のディレクティブである「.disable_check」を記述する。「.disable_check」は、例外検出部１０５が例外を検出する処理を無効にするディレクティブである。
そして、開発者が、その命令列１０９ａの後にディレクティブ「.enable_check」を記述する。「.enable_check」は、例外検出部１０５が例外を検出する処理を有効にするディレクティブである。
例外検出部１０５は、取得部１０４がディレクティブ「.disable_check」を取得した場合には、そのディレクティブの後続命令に対して例外を検出する処理を行わない。よって、命令列１０９ａに例外が発生するような記述ミスが含まれていても、機械語生成部１０８がこの命令列１０９ａをコンパイルして機械語を生成することになる。
また、命令列１０９ａのコンパイルが終わって取得部１０４がディレクティブ「.enable_check」を取得すると、例外検出部１０５は例外を検出する処理を再開する。よって、図３５の例では、命令列１０９ｂにおける例外が例外検出部１０５によって検出されることになる。
このようにディレクティブ「.disable_check」、「.enable_check」を利用することにより、例外検出部１０５が例外を検出する処理を無効にしたり、例外検出部１０５が例外を検出する処理を有効にしたりすることができる。
なお、このようにアセンブリ言語のディレクティブを使用にするのに代えて、開発者が情報処理装置１００にアセンブルの指示を与えるときのコマンドライン引数を利用して例外を検出する機能を抑制してもよい。
図３６は、コマンドライン引数の一例を示す模式図である。
図３６においては、アセンブリ言語のソースプログラム１０９から機械語の実行可能プログラム１１１（図３２参照）を生成することを情報処理装置１００に指示するコマンド「gas」の引数に「-no_check」を与えている。コマンドライン引数の「-no_check」は、情報処理装置１００がソースプログラム１０９をアセンブルするときに、例外検出部１０５が例外を検出する機能を無効にする引数である。これにより、アセンブル時に不要な例外が検出されるのを防止でき、プログラム開発の利便性を高めることができる。
次に、本実施形態に係るアセンブラプログラム１１２が実行する処理について説明する。
図３７は、本実施形態に係るアセンブラプログラム１１２が実行する処理のフローチャートである。
まず、初期化部１０３がステータス情報１１０を初期化する（ステップＳ４１）。例えば、初期化部１０３は、配列「dataSizeVReg」、「dataTypeGReg」、及び「dataTypeVReg」の全ての要素に「CLEAN」を格納する。また、初期化部１０３は、配列「readAccessGReg」、「readAccessVReg」、「writeAccessGReg」、及び「writeAccessVReg」の全ての要素に「FALSE」を格納する。
次に、取得部１０４が、記憶部１０２からアセンブリ言語のソースプログラム１０９を取得する（ステップＳ４２）。
次いで、例外検出部１０５が、例外を検出する機能が有効かどうかを判断する（ステップＳ４３）。一例として、例外検出部１０５は、取得部１０４がディレクティブ「.disable_check」を読み込んだ場合に、例外を検出する機能が有効ではないと判定する。また、例外検出部１０５は、コマンドライン引数に「-no_check」が含まれている場合にも、例外を検出する機能が有効ではない判定する。
一方、例外検出部１０５は、取得部１０４がディレクティブ「.enable_check」を読み込んだ場合や、コマンドライン引数に「-no_check」が含まれていない場合に、例外を検出する機能が有効である判定する。
ここで、例外を検出する機能が有効ではない（ステップＳ４３：否定）と判定された場合にはステップＳ４８に移る。
ステップＳ４８においては、機械語生成部１０８が、取得部１０４が取得したコードを機械語に変換する。そして、機械語生成部１０８は、その機械語を含む実行可能プログラム１１１を生成し、それを記憶部１０２に書き出す。
一方、例外を検出する機能が有効である（ステップＳ４３：肯定）と判定された場合にはステップＳ４４に移る。
ステップＳ４４においては、例外検出部１０５が例外検出処理を行う。その例外検出処理については後述する。
そして、例外検出部１０５が、例外を検出したかどうかを判定する（ステップＳ４５）。
ここで、例外を検出したと判定された場合（ステップＳ４５：肯定）にはステップＳ４６に移る。
ステップＳ４６においては、エラー出力部１０６がエラーを出力し、処理を終える。エラーの出力方法は特に限定されない。例えば、エラー出力部１０６は、エラーの原因である例外の種類を標準出力に出力する。
一方、例外を検出しなかったと判定された場合（ステップＳ４５：否定）にはステップＳ４７に移り、ステータス更新部１０７がステータス情報１１０を更新する。
次いで、前述のステップＳ４８に移り、機械語生成部１０８が機械語の実行可能プログラム１１１を生成し、それを記憶部１０２に書き出す。
この後は、アセンブリ言語のソースプログラム１０９に記述されているコードの行数だけステップＳ４３～Ｓ４８を繰り返して行い、処理を終える。
次に、ステップＳ４４の例外検出処理について説明する。
図３８は、ステップＳ４４の例外検出処理のフローチャートである。
まず、例外検出部１０５が、データタイプ例外があるかどうかをチェックする（ステップＳ５１）。例えば、例外検出部１０５は、取得部１０４が取得したアセンブリ言語のコードから命令の種類を特定することにより、この命令が演算の対象とするデータタイプを特定する。更に、例外検出部１０５は、アセンブリ言語のコードに基づいて、この命令のソースレジスタを特定する。
そして、例外検出部１０５は、配列「dataTypeGReg」、「dataTypeVReg」の各要素のうちでこのソースレジスタに対応した要素を特定する。そして、例外検出部１０５は、特定した要素が示すデータタイプと、命令が演算の対象とするデータタイプとが一致するかを判定し、一致しない場合にデータタイプ例外を検出する。
次に、例外検出部１０５が、データサイズ例外があるかどうかをチェックする（ステップＳ５２）。例えば、例外検出部１０５は、取得部１０４が取得したアセンブリ言語のコードに基づいて、そのコードに含まれる命令のソースレジスタを特定する。更に、例外検出部１０５は、配列「dataSizeVReg」の各要素のうちでこのソースレジスタに対応した要素が示すデータサイズと、命令のソースレジスタに指定されたデータサイズとが一致するかを判定する。そして、両者が一致しない場合に例外検出部１０５はデータサイズ例外を検出する。
次いで、例外検出部１０５が、W例外があるかどうかをチェックする（ステップＳ５３）。一例として、例外検出部１０５は、取得部１０４が取得したアセンブリ言語のコードに基づいて、そのコードに含まれる命令のソースレジスタを特定する。そして、例外検出部１０５は、配列「writeAccessGReg」、「writeAccessVReg」の各要素のうちで特定したソースレジスタに対応する要素が「FALSE」の場合にW例外を検出する。
続いて、例外検出部１０５が、R例外があるかどうかをチェックする（ステップＳ５４）。例えば、例外検出部１０５は、取得部１０４が取得したアセンブリ言語のコードに基づいて、そのコードに含まれる命令のデスティネーションレジスタを特定する。
特定したデスティネーションレジスタが汎用レジスタの場合には、例外検出部１０５は、そのデスティネーションレジスタに対応する配列「writeAccessGReg」と配列「readAccessGReg」のそれぞれの要素を特定する。更に、例外検出部１０５は、特定した配列「writeAccessGReg」の要素が「TRUE」であり、かつ特定した配列「readAccessGReg」の要素が「FALSE」の場合にR例外を検出する。
なお、デスティネーションレジスタがベクトルレジスタの場合にも、例外検出部１０５は、配列「writeAccessVReg」と配列「readAccessVReg」のそれぞれの要素を利用してR例外を検出する。
次に、例外検出部１０５が、srcデータタイプ例外があるかどうかをチェックする（ステップＳ５５）。
例えば、例外検出部１０５は、取得部１０４が取得したアセンブリ言語のコードから命令の種類を特定し、その命令が二つのソースレジスタのデータタイプが同一であることを前提とする命令かどうかを判断する。そして、データタイプが同一であることを前提とした命令であると判断した場合には、例外検出部１０５は、取得したコードに基づいて二つのソースレジスタを特定する。
特定した二つのソースレジスタが汎用レジスタである場合には、例外検出部１０５は、これらのソースレジスタの各々に対応する配列「dataTypeGReg」の要素が同一かどうかを判断する。そして、同一でないと判断した場合は、例外検出部１０５は、srcデータタイプ例外を検出する。なお、ソースがベクトルレジスタの場合にも、例外検出部１０５は、「dataSizeVReg」を利用してsrcデータタイプ例外を検出する。
以上により、例外検出処理を終える。
上記した本実施形態によれば、アセンブリ言語のソースプログラム１０９をアセンブルするときに、ステータス情報１１０（図３３）に基づいて例外検出部１０５が例外を検出する。そのため、アセンブルにより得られた実行可能プログラム１１１をプロセッサ９０（図３０参照）で実行する前に早期にソースプログラム１０９の記述ミスを検出でき、プログラム開発の効率化を図ることができる。
更に、実行可能プログラム１１１の実行前に記述ミスを検出できることで、記述ミスのある実行可能プログラムをプロセッサ９０で無駄に実行する時間が減り、プロセッサ９０やメモリ２８等のハードウェア資源の無駄な消費を改善できる。
しかも、ステップＳ４４の例外検出処理で使用するステータス情報１１１には、「R例外」、「W例外」、「データタイプ例外」、「データサイズ例外」、及び「srcデータタイプ例外」を検出するための種々の配列が含まれる。その配列の要素を図３４（ａ）、（ｂ）の検出ルールに適用することにより、例外検出部１０５が上記の種々の例外を検出できる。そのため、どの種類の例外が検出されたかに応じ、開発者が、アセンブリ言語のソースプログラム１０９における具体的な記述ミスを特定することができる。
（第４実施形態）
第１～第３実施形態で説明した「W例外」、「R例外」、「データタイプ例外」、「データサイズ例外」、及び「srcデータタイプ例外」の各々は、JIT(Just In Time)コンパイラ技術を使用したプログラムでも生じ得る。
JITコンパイラ技術は、実行時に決定されるパラメータ、処理内容、及びプロセッサの状況に応じて、好適な機械語の命令列を生成する技術である。JITコンパイラ技術を用いて生成した機械語の命令列は、AOT(Ahead Of Time)型のコンパイラが生成する汎用的に処理可能な機械語の命令列からなる実行可能プログラムよりも処理が高速である。
そこで、まずこのJITコンパイラ技術について、AOTコンパイラ技術と比較しながら説明する。
図３９は、AOTコンパイラ技術やJITコンパイラ技術により生成された実行可能プログラムを実行する情報処理装置のハードウェア構成図である。
この情報処理装置１１７は、HPC用途の計算機やPC(Personal Computer)等の計算機であって、図３０に示したのと同一の構造を有するプロセッサ９０とメモリ２８とを有する。
このうち、プロセッサ９０は、図３０に示した各種回路２１～２５と演算用レジスタファイル２７とを備えたハードウェアである。また、メモリ２８は、実行可能プログラムが展開されるDRAM等の揮発性メモリである。その実行可能プログラムは、以下のようにAOTコンパイラ技術を用いてソースコードをコンパイルすることにより生成することができる。また、JITコンパイラ技術を用いる場合には、実行可能プログラムの実行中に機械語の命令列が動的に生成される。
図４０（ａ）は、AOTコンパイラ技術でコンパイルすることを前提としたC++の疑似ソースコード１２０の一例を示す模式図である。
AOTコンパイラ技術では、開発者がC言語やC++の文法に即してソースコードを記述し、そのソースコードをGCC(GNU Compiler Collection)等のコンパイラが機械語の命令列にコンパイルする。
図４０（ａ）の例では、処理１２０ａにおいて配列「Tbl」の各要素をパラメータ「q」で除する。そして、処理１２０ｂにおいて、配列「in」の要素を配列「Tbl」の要素で除し、それを配列「out」に格納する。
図４０（ｂ）は、パラメータ「q」と配列「in」、「out」を宣言したC++の疑似ソースコード１２１の一例を示す模式図である。
パラメータ「q」は、前述の処理１２０ａにおける除数であり、以下では入力パラメータとも呼ぶ。また、配列「in」と配列「out」は、それぞれ処理１２０ｂにおける入力データと出力データである。これらの配列「in」、「out」に格納するデータは特に限定されない。ここでは１６個の画素データからなる画像を１００００００枚格納する二次元配列として配列「in」と配列「out」を宣言する。
図４０（ｃ）は、配列「Tbl」の初期値を宣言したC++の疑似ソースコード１２２の一例を示す模式図である。
配列「Tbl」は、画素データを量子化する量子化テーブルの値を格納する配列である。ここでは、各配列「in」、「out」に対応した１６個の要素を持つ配列として配列「Tbl」を宣言する。そして、配列「Tbl」の各要素の初期値は２のべき乗であると仮定する。
図４０（ａ）～図４０（ｃ）のソースコード１２０～１２２は全てC言語やC++の文法に即して開発者が記述し、コンパイラによってアセンブリプログラムに変換される。
図４１は、AOTコンパイラ技術で前述のソースコード１２０をコンパイルして得られたアセンブリプログラム１２４の疑似コードの模式図である。
そのアセンブリプログラム１２４には、プロセッサ９０の命令セットに含まれる複数の命令が各処理１２０ａ、１２０ｂに対応して生成されている。
例えば、処理１２０ａはmov命令からjmplt命令に至る６個の命令で実現され、処理１２０ｂはmov命令からjmplt命令に至る１０個の命令で実現される。なお、ここでは最初に汎用レジスタx2に入力パラメータ「q」が保存されているものとする。
ここで、処理１２０ｂにおける命令「div x2, x2, x1」について考える。この命令は、ソースコード１２０の処理１０ｂにおける「in[i]/Tbl[i]」に相当する命令である。除数の「Tbl[i]」は、ソースコード１２０の処理１２０ａにおいて入力パラメータ「q」で除されている。上記の命令「div x2, x2, x1」は入力パラメータ「q」の値の如何を問わずに正しい除算の結果を与える命令である。したがって、アセンブリプログラム１２４は、どのような入力パラメータ「q」に対しても正しい結果を与える汎用的なコードとなっている。
しかしながら、div命令のような除算を行う命令は、他の命令と比較して実行サイクル数が多い命令である。したがって、div命令は、実行開始してからその結果が得られるまでのスループットが大きく、処理性能の低下を招いてしまう命令である。プロセッサの種類にもよるが、div命令以外の数値演算命令の実行サイクル数は１～５であるのに対し、div命令の実行サイクル数は８０程度もあることがある。更に、深層学習や画像処理等ではforループのループ回数が膨大となるため、そのforループの内側にあるdiv命令によってスループットの低下が更に顕著となる。
このようなアセンブリプログラム１２４をアセンブラが機械語の命令列に翻訳することにより機械語からなる実行可能プログラムが生成されることになる。LLVMのように、コンパイラの種類によっては、プロセッサの種類によらず、仮想的な命令セットを持つプロセッサ向けのアセンブリプログラムを生成することがある。この場合、このアセンブリプログラムを個別のプロセッサ向けの機械語の命令列に変換することもあるが、div命令のような除算命令があるとスループットが低下する点は同じである。
図４２は、AOTコンパイラ技術で得られた実行可能プログラムの動作について示す模式図である。
図４２に示すように、実行可能プログラム１２５は、入力データである配列「in」の各要素と入力パラメータ「q」の入力を受け付ける。そして、前述のように入力パラメータ「q」や配列「in」の値の如何を問わずに、実行可能プログラム１２５は、同一のアセンブリプログラム１２４から得られた機械語の命令列により処理を行い、その処理の結果を配列「out」の各要素に格納する。
次に、スループットの低下を抑制し得るJITコンパイラ技術を前提としたプログラムについて説明する。
図４３は、JITコンパイラ技術を使用したC++の疑似ソースコード１２６の一例を示す模式図である。
このソースコード１２６は、その実行結果が図４０（ａ）のソースコード１２０の実行結果と同一になるように開発者によって記述されたコードであって、処理１２６ａと処理１２６ｂとを有する。このうち、処理１２６ａは、ソースコード１２０の処理１２０ａと同様に、配列「Tbl」の各要素をパラメータ「q」で除する処理である。また、処理１２６ｂは、配列「in」の要素を配列「Tbl」の要素で除してそれを配列「out」に格納する処理を行う機械語の命令列を生成する処理である。
その処理１２６ｂには、命令の名前であるニーモニックと同じ関数名を有する「mov(x0, i)」等の関数が開発者によって記述される。関数「mov(x0, i)」は、言わばアセンブリ言語の「mov x0, #i」に対応した関数であって、「mov x0, #i」が行う処理を表す機械語をメモリ２８に書き込む関数である。なお、アセンブリ言語では変数は記述することができず、「mov x0, #5」や「mov x0, #-128」等のようにアセンブリ言語では固定の値しか指定することができない。JITコンパイラ技術を用いた場合、即値に変数ｉが使用できる。このことはJITコンパイラ技術の利点の1つである。このように関数名が命令のニーモニックと同一であり、かつその命令が行う処理を表す機械語をメモリに書き込む関数のことを以下ではニーモニック関数と呼ぶ。
処理１２６ｂは、i=0～15に対してin[i]/Tbl[i]を実行する機械語の命令列をメモリ２８に書き込む処理である。この例では、開発者がswitch文を記述したことにより、除数である配列要素「Tbl[i]」の値に応じて異なるニーモニック関数を使って機械語の命令列が生成される。
例えば、「Tbl[i]」の値が「1」の場合には、「in[i]」に対する除数が「1」となるため、「in[i]」に対して何も行う必要がない。よって、この場合は、「case 1」において「in[i]」の値が格納されている汎用レジスタx1の値に対して演算する機械語の生成は行わず、そのままout[i]へ値を格納する機械語をメモリ２８に書き込むのみである。
一方、「Tbl[i]」の値が「2」の場合には、「case 2」においてshiftR命令の機械語の生成に対応した「shiftR(x1, x1, #1)」を実行する。このニーモニック関数は、汎用レジスタx1の内容を１ビットだけ右にシフトし、その結果をレジスタx1に書き込む処理を表す機械語をメモリ２８に書き込む関数である。よって、「shiftR(x1, x1, #1)」を実行することにより、汎用レジスタx1に格納されている「in[i]」を２で除したのと等価な処理を行う機械語をメモリ２８に書き込むことができる。
また、「Tbl[i]」の値が「4」の場合には、「case 4」において「shiftR(x1, x1, #2)」を実行する。これにより、汎用レジスタx1の内容が右に２ビットだけシフトし、汎用レジスタx1に格納されている「in[i]」を４で除したのと等価な処理を行う機械語をメモリ２８に書き込むことができる。
このように、除数の「Tbl[i]」が2のべき乗の値の場合には、shiftR命令に対応するニーモニック関数が実行される。
そして、「Tbl[i]」の値が「1」、「2」、「4」のような2のべき乗ではない場合には、「default」において「div(x1, x1, x2)」を実行する。このニーモニック関数は、div命令に対応した関数であって、汎用レジスタx1の内容を汎用レジスタx2の内容で除した値を汎用レジスタx1に書き込む機械語をメモリ２８に書き込む関数である。
このソースコード１２６によれば、「Tbl[i]」の値が「1」、「2」、「4」のような2のべき乗である場合には、div命令よりも実行サイクル数が少ないshiftR命令に等価な機械語や何もしない機械語がメモリ２８に書き込まれる。そして、「Tbl[i]」の値が「1」、「2」、「4」のような2のべき乗でない場合にのみdiv命令に等価な機械語がメモリに書き込まれる。
JITコンパイラ技術では、このように「Tbl[i]」等のパラメータの値に応じて実行サイクル数を低減するのに最適な機械語を書き込むことにより、AOTコンパイラ技術と比較してプログラムの実行速度を高速化することができる。
図４４は、ソースコード１２６をコンパイルして得られた実行可能プログラムの実行中に、処理１２６ｂがメモリ２８にどのような機械語の命令列を書き込んだかを示す模式図である。なお、その実行可能プログラムを実行する際、入力パラメータ「q」に「8」を与えている。また、図４４では、この機械語の命令列を逆アセンブルしたアセンブリプログラム１２７の疑似コードも併記している。
図４４に示すように、q=8の場合には、配列「Tbl」の各要素が先頭から順に「1」、「2」、「4」となる。よって、処理１２６ｂのforループ実行に際して、i=0(case 1)、i=1(case 2)、i=2(case 4)の各場合に対応したshiftR関数とstore関数の各々が生成する機械語１２８がメモリ２８内に配置されることになる。そして、その機械語１２８を逆アセンブルしたコードは、アセンブリプログラム１２７におけるコード１２７ａ、１２７ｂ、１２７ｃとなる。
図４５は、実行時に呼び出す関数を、JITコンパイラ技術で実行時に生成する実行可能プログラムの動作について示す模式図である。ここでは、JITコンパイラ技術を用いたソースコード１２６をコンパイルして得られた実行可能プログラム１３０の動作について説明する。
図４５に示すように、実行可能プログラム１３０は、まず入力パラメータ「q」の入力を受け付ける（ステップP10）。次いで、実行可能プログラム１３０は、その入力パラメータ「q」の値に応じて、処理が高速になる機械語１２８を生成する（ステップP11）。前述の図４４の例では、「Tbl[i]」の値に適した機械語１２８が生成される。
続いて、実行可能プログラム１３０は、入力データである配列「in」の各要素の入力を受け付けて（ステップP12）、処理の結果を配列「out」の各要素に格納する（ステップP13）。
このとき、機械語１２８の中にはスループットの遅いdiv命令が含まれていないため、アセンブリプログラム１２４に対応する実行可能プログラムよりも高速な処理を行うことができる。しかも、このように入力パラメータ「q」の値に応じて適切な機械語１２８を生成することにより、JITコンパイラ技術ではAOTコンパイラ技術よりもプログラムの実行速度を高速化できる。
ところで、このようなJITコンパイラ技術を使用する場合は、開発者は、図４３に示したようなソースコード１２６を自ら記述することになる。そのソースコード１２６においてニーモニック関数movやニーモニック関数load等を呼び出すコードはアセンブリ言語の文法に類似している。そのため、ソースコード１２６等のアプリケーションプログラム用のソースコードを記述するときに、図８～図１３に示した第１～第５例に類似の記述ミスが発生することがある。そのような記述ミスについて以下に説明する。
・第１例
図４６は、第１例に係る記述ミスについて説明するためのアプリケーションプログラム用のC++のソースコードの模式図である。
このソースコード１４０では、コードT40の文「vmov(v15.s, 3);」によってニーモニック関数vmovが呼び出されている。そのニーモニック関数vmovの第１引数の「v15.s」は、アセンブリ言語のv15.sに対応した書式である。このニーモニック関数vmovを実行すると、アセンブリ言語のコード「vmov v15.s, 3」と同じ処理を実行するための機械語の命令列をメモリ２８に書き込むコードが実行される。また、このコード「vmov v15.s, 3」は、データサイズがシングルワード「s」の４個の要素の各々に整数の即値「3」を格納したベクトルデータをベクトルレジスタv15に書き込むコードである。
一方、コードT41の文「float_multiply(vi.s, vi.s, v15.s);」は、ニーモニック関数float_multiplyを呼び出すための文である。このニーモニック関数float_multiplyを実行すると、アセンブリ言語のコード「float_multiply(vi.s, vi.s, v15.s);」と同じ処理を実行するための機械語の命令列をメモリ２８に書き込むコードが実行される。なお、このようにカウンタ変数「i」を用いたforループの内側に「vi.s」等を記述した場合、「vi」の「i」の部分にはカウンタ変数「i」の値「0」、「1」、「2」、…が代入されるものとする。また、このfloat_multiply命令は、第２オペランドと第３オペランドの各々に指定されているベクトルレジスタに格納されている浮動小数同士を乗算し、その結果を第１オペランドのベクトルレジスタに書き込む命令である。
このようにfloat_multiply命令が演算の対象とするデータタイプは浮動小数であるから、float_multiply命令のソースレジスタであるベクトルレジスタv15には浮動小数が書き込まれていなければならない。しかし、この例では、コードT40においてベクトルレジスタv15に整数が書き込まれてしまっているため、このコーディングは誤りである。
・第２例
図４７は、第２例に係る記述ミスについて説明するためのアプリケーションプログラム用のC++のソースコードの模式図である。
このソースコード１４１では、コードT42の文「vmov(v15.b, 3);」によってニーモニック関数vmovが呼び出されている。このニーモニック関数vmovを実行すると、アセンブリ言語のコード「vmov v15.b, 3」と同じ処理を実行するための機械語の命令列をメモリ２８に書き込むコードが実行される。また、このコード「vmov v15.b, 3」は、データサイズがバイト「b」の１６個の要素の各々に整数の即値「3」を格納したベクトルデータをベクトルレジスタv15に書き込むコードである。
一方、コードT43においては、ニーモニック関数multpilyを呼び出すための文「multiply(vi.s, vi.s, v15.s);」が実行される。このニーモニック関数multiplyを実行すると、アセンブリ言語のコード「multiply vi.s, vi.s, v15.s」と同じ処理を実行するための機械語の命令列をメモリ２８に書き込むコードが実行される。このコード「multiply vi.s, vi.s, v15.s」は、ベクトルレジスタvi、v15の各々に格納されているデータサイズがシングルワード「s」の要素同士を乗算し、その結果をベクトルレジスタviの対応する要素に書き込むコードである。これによれば、開発者は、コードT43においてデータサイズがシングルワード「s」のデータ同士の演算を意図していることになる。
しかし、ベクトルレジスタv15には、前述のコードT42によってデータサイズがバイト「b」の要素が書き込まれているため、コードT43を実行すると開発者の意図とは異なる結果が得られてしまう。
このように、先行命令のデスティネーションレジスタのデータサイズと、そのデスティネーションレジスタをソースレジスタとする後続命令の当該ソースレジスタのデータサイズとが異なる記述は誤りである。
・第３例
図４８は、第３例と第４例に係る記述ミスについて説明するためのアプリケーションプログラム用のC++のソースコードの模式図である。
このソースコード１４２では、コードT44において、「i」の値が0～7の各々に対して文「vload(vi.s, inAddr);」が実行される。この文は、vload命令に対応したニーモニック関数vloadを呼び出すための文である。このニーモニック関数vloadを実行すると、「vload vi.s, inAddr」という命令と同じ処理を実行するための機械語の命令列をメモリに書き込むコードが実行される。なお、命令「vload vi.s, inAddr」は、アドレスが「inAddr」のメモリのデータを、ベクトルレジスタviの４個の要素の各々に書き込む命令である。
一方、コードT45においては、「i」の値が0～9の各々に対して文「multiply(vi.s, vi.s, v15.s);」が実行される。但し、i=8やi=9のときのコードT45の第２引数であるベクトルレジスタv8、v9は、前述のコードT44でデータが書き込まれておらず、コードT45の以前にデスティネーションレジスタとして使用されていない。よって、ベクトルレジスタv8、v9にどのようなデータが書き込まれているかが不明であり、ベクトルレジスタv8、v9のデータは不定となる。
このような状態でコードT45を実行しても、デスティネーションレジスタのベクトルレジスタv8、v9に書き込まれるデータも不定となってしまう。よって、このようにデスティネーションレジスタとして使われたことがないレジスタをソースレジスタに指定するのは誤りである。
・第４例
第４例に係る記述ミスについて、図４８のソースコード１４２を引き続き参照しながら説明する。
そのソースコード１４２のコードT46においては、「multiply v0.s, v1.s, v15.s」という命令と等価な機械語を生成する処理を行う文「multiply(v0.s, v1.s, v15.s);」が実行される。この命令は、ベクトルレジスタv1、v15の各々の要素同士を乗算してその結果をベクトルレジスタv0に書き込む命令である。
ベクトルレジスタv0にはコードT45の結果が書き込まれているが、その結果を一度も使用することなく、コードT46においてベクトルレジスタv0の内容が上書きされてしまっている。これでは、ベクトルレジスタv0に演算結果を書き込んだコードT45の存在意義が不明となり、コードT45又はコードT46におけるレジスタの指定ミスが疑われる。
そのため、このようにデスティネーションレジスタとして使ったレジスタを、その後にソースレジスタとして使うことなく再びデスティネーションレジスタに指定するのは誤りである。
・第５例
図４９は、第５例に係る記述ミスについて説明するためのアプリケーションプログラム用のC++のソースコードの模式図である。
このソースコード１４３では、コードT47においてニーモニック関数vmovを呼び出すための文「vmov(v15.s, 7);」が実行される。このように第２引数に整数が指定された場合、ニーモニック関数vmovは、ベクトルレジスタv15の４個の要素の各々に整数の即値「7」を書き込む命令「vmov v15.s, 7」と等価な処理を行う機械語を生成する関数となる。
また、コードT48においては、第２引数に「3.14」が指定されたニーモニック関数vmovが実行される。この場合は、コードT48におけるニーモニック関数vmovは、ベクトルレジスタv14の４個の要素の各々に浮動小数で表される「3.14」を書き込む命令「vmov v14.s, 3.14」と等価な処理を行う機械語を生成する関数となる。
一方、コードT49においては、整数同士の乗算を行うニーモニック関数multiplyが呼び出されている。このニーモニック関数multiplyに対応したmultiply命令は、二つのソースオペランドの各々のデータタイプが同じであることを前提とする命令である。
しかし、この例では、ベクトルレジスタv15に書き込まれているデータのタイプが整数であるのに対し、ベクトルレジスタv14に書き込まれているデータのタイプは浮動小数となっており、両者は同じではない。
よって、このように二つのソースレジスタに書き込まれているデータのデータタイプが異なる場合もコーディングの誤りとなる。
図５０は、前述の第１例～第５例の記述ミスをまとめた図である。
図５０に示すように、第１～第３実施形態と同様に、本実施形態においても第１～第５例の各々に対応した例外を定義する。これらのうち、「データタイプ例外」と「データサイズ例外」は、それぞれ第１例と第２例の記述ミスに対応する。また、「W例外」と「R例外」は、それぞれ第３例と第４例の記述ミスに対応する。そして「srcデータタイプ例外」は第５例の記述ミスに対応する。
次に、これらの例外を検出できる情報処理プログラムについて説明する。
本実施形態においても、第１～第３実施形態と同様に、汎用レジスタxn(n=0, 1, …31)とベクトルレジスタvn(n=0, 1, …31)の各々のステータスを記憶したステータス情報を使用する。
図５１は、本実施形態に係るステータス情報を表すC++の疑似ソースコードを示す模式図である。
このステータス情報１４５におけるコードT60～T67の各々は、図３３におけるステータス情報１１０におけるコードT20～T27と同一であるため、ここではその概略を説明するのみとする。
図３３を参照して説明したように、コードT61は、ベクトルレジスタvn(n=0, 1, …31)のデータサイズを格納する配列「dataSizeVReg」を宣言するコードである。
また、コードT63は、汎用レジスタxn(n=0, 1, …31)とベクトルレジスタvn(n=0, 1, …31)の各々のデータタイプを格納する配列「dataTypeGReg」、「dataTypeVReg」を宣言するコードである。
そして、コードT65は、汎用レジスタxn(n=0, 1, …31)とベクトルレジスタvn(n=0, 1, …31)の各々がソースレジスタとして使用済みかどうかを示す配列「readAccessGReg」、「readAccessVReg」を宣言するコードである。
更に、コードT67は、汎用レジスタxn(n=0, 1, …31)とベクトルレジスタvn(n=0, 1, …31)の各々がデスティネーションレジスタとして使用済みかどうかを示す配列「writeAccessGReg」、「writeAccessVReg」を宣言するコードである。
図５２（ａ）、（ｂ）は、図５１のステータス情報を用いて例外を検出するときの検出ルールについて説明するための模式図である。
このうち、図５２（ａ）は、ニーモニック関数の引数に汎用レジスタxn(n=0,1,2…31)が指定された場合の検出ルールについて模式的に示す図である。また、図５２（ｂ）は、ニーモニック関数の引数にベクトルレジスタvn(n=0,1,2…31)が指定された場合の検出ルールについて模式的に示す図である。
図５２（ａ）、（ｂ）の検出ルールは、図３４（ａ）、（ｂ）におけるのと同一であるため、ここではその概略を説明するのみとする。
例えば、図５２（ａ）に示すように、W例外は、ソースレジスタに対応する配列「writeAccessGReg」の要素が「FALSE」であるときに発生する。
また、R例外は、デスティネーションレジスタに対応する配列「writeAccessGReg」の要素が「TRUE」であり、かつデスティネーションレジスタに対応する配列「readAccessGReg」の要素が「FALSE」の場合に検出される。
更に、データタイプ例外は、ソースレジスタに対応する配列「dataTypeGReg」の要素が、命令が演算の対象とするデータタイプと異なる場合に検出される。
そして、srcデータタイプ例外は、１番目と２番目の各々のソースレジスタに対応する配列「dataTypeGReg」の要素同士が異なる場合に検出される。
また、図５２（ｂ）に示すように、ニーモニック関数の引数にベクトルレジスタが指定された場合も、汎用レジスタの場合と同様に「W例外」、「R例外」、「データタイプ例外」、及び「srcデータタイプ例外」が検出される。
更に、ベクトルレジスタの場合には、これらの例外の他に「データサイズ例外」も検出される。その「データサイズ例外」は、ニーモニック関数の引数に指定されたソースレジスタに対応する配列「dataSizeVReg」の要素が、当該引数に指定されたデータサイズと異なる場合に検出される。
次に、本実施形態に係るニーモニック関数について説明する。
本実施形態に係るニーモニック関数は、開発者が記述するアプリケーション用のプログラムとは別の情報処理プログラムにおいて定義される。その定義では、以下のような種々の型が用いられる。
図５３（ａ）～（ｄ）と図５４（ａ）～（ｄ）は、ニーモニック関数で使用される種々の型を定義するC++の疑似ソースコードの模式図である。
このうち、図５３（ａ）は、Operand型を定義するソースコードの例である。
Operand型は、メンバ変数として「type」と「value」とを有するクラスである。このうち、「type」には、レジスタや即値等のオペランドの種類が格納される。そして、「value」には、即値やレジスタのインデックス等の数値が格納される。
図５３（ｂ）は、AddrReg型を定義するソースコードの例である。
AddrReg型は、アドレスレジスタを示すクラスである。そのクラスのメンバ変数は、アドレスのベース値を保持するレジスタのインデックスを格納する「regIndex」と、アドレスオフセット値である即値を格納する「imm_value」である。なお、「imm_value」の初期値は0とする。
図５３（ｃ）は、Imm型を定義するソースコードの例である。
Imm型は、符号付き整数即値を示すクラスである。そのクラスのメンバ変数は、符号付き整数即値を格納する「imm_value」である。
図５３（ｄ）は、UnsignedImm型を定義するソースコードの例である。
UnsignedImm型は、符号無し整数即値を示すクラスである。そのクラスのメンバ変数は、符号無し整数即値を格納する「imm_value」である。
また、図５４（ａ）～（ｄ）は、それぞれVRegB型、VRegH型、VRegS型、VRegD型を定義するソースコードの例である。これらの型は、ベクトルレジスタに格納されるベクトルデータの要素のデータサイズを示すクラスである。例えば、VRegB型とVRegH型は、それぞれバイトとハーフワードに対応する。そして、VRegS型とVRegD型は、それぞれシングルワードとダブルワードに対応する。なお、これらのクラスのメンバ変数は、いずれもデータサイズを示す符号無し整数の「regIndex」である。
次に、本実施形態に係るニーモニック関数の定義について説明する。
ニーモニック関数は、命令セットに含まれる全ての命令に対応して定義される。例えば、命令セットにmultiply命令、add命令、load命令、及びstore命令等があれば、これらに対応してニーモニック関数multiply、ニーモニック関数add、ニーモニック関数load、及びニーモニック関数storeが定義される。以下では、これらのニーモニック関数の一部について説明する。
図５５及び図５６は、ニーモニック関数multiplyを定義するC++のソースコードが記述されたソースファイル１５０の模式図である。
図５５及び図５６に示すように、このソースファイル１５０には開発者によってコードT70～T83が記述される。
このうち、コードT70は、ニーモニック関数multiplyが受け取る引数「dst」、「src0」、及び「src1」を宣言するコードである。これらの引数のうち、「dst」は、multiply命令の第１オペランドであるデスティネーションレジスタを示す。また、「src0」と「src1」は、それぞれmultiply命令の第２オペランドと第３オペランドのソースレジスタを示す。
一方、コードT71の文「nm = “multiply_VRegB”;」は、命令とそのオペランドのデータサイズとを識別する文字列「multiply_VRegB」を変数nmに代入する文である。ここでは、文字列「multiply_VRegB」における「multiply」により、ニーモニック関数multiplyがmultiply命令に対応することが一意に識別される。また、文字列「multiply_VRegB」における「VRegB」により、ソースレジスタとデスティネーションレジスタのデータサイズがバイト「b」であることが一意に識別される。
また、コードT72は、Operand型の変数「op0」、「op1」、及び「op2」を宣言して、その各々のメンバ変数に所定の値を代入するコードである。ここでは、変数「op0」、「op1」、及び「op2」は、それぞれ「dst」、「src0」、及び「src1」に対応するものとする。
この場合、変数「op0」は、デスティネーションレジスタに対応することになる。そのため、変数「op0」のメンバ変数「type」には「REGISTER」が代入され、メンバ変数「value」にはデスティネーションレジスタのインデックスを表す「dst.regIndex」が代入される。
同様に、変数「op1」は１番目のソースレジスタに対応するため、そのメンバ変数「type」には「REGISTER」が代入され、「value」には１番目のソースレジスタのインデックスを表す「src0.regIndex」が代入される。
更に、変数「op2」は２番目のソースレジスタに対応するため、そのメンバ変数「type」には「REGISTER」が代入され、「value」には２番目のソースレジスタのインデックスを表す「src1.regIndex」が代入される。
そして、コードT73は、配列「oplist」に上記の変数「op0」、「op1」、及び「op2」を代入する文である。
一方、コードT74～T78は、前述の図５２（ａ）、（ｂ）の検出ルールに従って例外を検出するコードである。例えば、コードT74とコードT75は、それぞれ「R例外」と「W例外」を検出するコードである。また、コードT76とコードT77は、それぞれ「データサイズ例外」と「データタイプ例外」を検出するコードである。そして、コードT78は「srcデータタイプ例外」を検出するコードである。
なお、これらのコードT74～T78においては、例外が検出された場合にエラーを出力する文も含まれる。例えば、コードT74においてR例外が検出された場合には、エラーとして“Invalid register use. Data on destination register is not used.”という文字列が標準出力に出力される。
そして、上記のコードT74～T78において例外が検出されなかった場合にはコードT79～T83が実行される。
このうち、コードT79は、MachineCodeEmitter関数を呼び出し、そのMachineCodeEmitter関数の返り値を関数writeでメモリ２８に書き込むコードである。MachineCodeEmitter関数は、変数「nm」と変数「oplist」とを引数として受け取り、変数「oplist」で表されるオペランドに対して変数「nm」で表される命令が行う処理を表す機械語を生成する関数である。
なお、MachineCodeEmitter関数は、プロセッサ９０のアセンブラプログラムと共に作成された動作が検証済の関数である。
そして、コードT80～T83は、ステータス情報１４５を更新するコードである。
このうち、コードT80は、配列「writeAccessVReg」の要素を更新するコードである。この例では、multiply命令を実行することによりデスティネーションレジスタが使用済みとなるため、そのデスティネーションレジスタに対応した配列「writeAccessVReg」の要素に「TRUE」が格納される。
また、コードT81は、配列「dataSizeVReg」の要素を更新するコードである。この例では、コードT70において、ニーモニック関数multiplyの第１引数の型が「VRegB」となっており、multiply命令のデスティネーションレジスタのデータサイズがバイト「b」であることが特定されている。よって、コードT81においては、バイト「b」を示す「sizeB」が、そのデスティネーションレジスタに対応した配列「dataSizeVReg」の要素に格納される。
そして、コードT82は、配列「dataTypeVReg」の要素を更新するコードである。multiply命令においては、二つのソースレジスタと同じデータタイプのデータがデスティネーションレジスタに書き込まれる。よって、この例では、デスティネーションレジスタに対応した配列「dataTypeVReg」の要素に、１番目のソースレジスタのデータタイプを格納している。
また、コードT83は、配列「readAccessVReg」の要素を更新するコードである。ニーモニック関数multiplyを実行すると、コードT70で指定された二つの引数「src0」、「src1」が示す二つのソースレジスタが使用済みとなる。そのため、コードT83においては、これら二つのソースレジスタに対応した配列「readAccessVReg」の各々の要素に、ソースレジスタとして使用済みであることを示す「TRUE」が格納される。
以上のように、この例では、コードT74～T78により「R例外」、「W例外」、「データサイズ例外」、「データタイプ例外」、及び「srcデータタイプ例外」を検出できる。
なお、前述のように、ニーモニック関数は、命令セットに含まれる全ての命令に対応して定義される。次に、ニーモニック関数multiply以外のニーモニック関数のソースコードの例について説明する。
図５７～図６９は、前述のソースファイル１５０に記述された種々のニーモニック関数を定義するC++の疑似ソースコードを模式的に示す図である。
例えば、図５７及び図５８は、ニーモニック関数float_multiplyを定義するC++のソースコードが記述されたソースファイル１５０の模式図である。また、図５９～図６９は、vload命令、vadd命令、vstore命令、cvtssBtoH命令、vmov命令、及びcvtFloatSigned命令の各々に対応したニーモニック関数を定義するソースコードが記述されたソースファイル１５０の模式図である。
なお、図６５のニーモニック関数cvtssBtoHはcvtssBtoH命令に対応したニーモニック関数である。そのcvtssBtoH命令は、ソースレジスタに格納されているMSB(Most Significant Bit)側の８個の符号付き８ビットデータを、符号付き１６ビットデータに変換してデスティネーションレジスタに格納する命令である。
そして、図６９のニーモニック関数cvtFloatSignedは、cvtFloatSigned命令に対応したニーモニック関数である。そのcvtFloatSigned命令は、ソースレジスタに格納されている３２ビットの浮動小数を、３２ビットの符号付き整数に変換してデスティネーションレジスタに格納する命令である。
また、図５７～図６９の各々において、図５５と図５６で説明したのと同種のコードにはこれらの図におけるのと同じ符号を付し、その説明は省略する。
命令によって発生する例外に相違はあるものの、図５７～図６９に示す種々のニーモニック関数においてもコードT74～T78により例外を検出することができる。
なお、ニーモニック関数の種類によっては、このように例外を検出する機能を無効にできると便利な場合がある。例えば、実行可能プログラムの実行に先立って汎用レジスタx0を0クリアするxor(x0,x0,x0)というニーモニック関数がある。この関数は、ソースレジスタにデータが書き込まれているかどうかによらず汎用レジスタx0を0クリアする関数であるため、W例外が検出されて実行されないと汎用レジスタx0を0クリアできなくなってしまう。
その場合には、以下のようにニーモニック関数が例外を検出する機能を抑制すればよい。
図７０（ａ）、（ｂ）は、例外を検出する機能を抑制する方法について模式的に示す図である。
この例では、図７０（ａ）のように例外を検出する機能を備えたニーモニック関数xorと、図７０（ｂ）のように当該機能を備えていないニーモニック関数xor_without_checkの各々を開発者がソースファイル１５０に記述する。
このうち、図７０（ａ）のニーモニック関数xorでは、前述のコードT74～T78によって例外のチェックが行われ、コードT80～T83によってステータス情報１４５の更新が行われる。一方、図７０（ｂ）のニーモニック関数xor_without_checkではコードT74～T78、T80～T83がなく、例外のチェックとステータス情報１４５の更新が行われない。
なお、ニーモニック関数xorとニーモニック関数xor_without_checkのいずれにおいても、xor命令の機械語をメモリ２８に書き込むコードT79がソースファイル１５０に記述される。
そして、例外を検出する機能を使用したい場合には、開発者が、図６０（ａ）のニーモニック関数xorを呼び出すコードをアプリケーションプログラム用のソースファイルに記述する。
一方、例外を検出する機能を使用したくない場合には、開発者が、図６０（ｂ）のニーモニック関数xor_without_checkを呼び出すコードをアプリケーションプログラムのソースファイルに記述すればよい。
なお、このように二種類のニーモニック関数を用意するのではなく、一つのニーモニック関数で例外を検出する機能を抑制できるようにしてもよい。
図７１は、このように例外を検出する機能を抑制することができるニーモニック関数のC++の疑似ソースコードの模式図である。
図７１に示すように、この例では、ニーモニック関数xorの引数に、例外を検出する機能を有効にするかどうかを指定する引数「no_check」を追加する。
そして、引数「no_check」の値が「0」の場合には、前述のコードT74～T78によって例外のチェックが行われ、コードT80～T83によってステータス情報１４５の更新が行われる。一方、引数「no_check」の値が「0」以外の場合には、例外のチェックとステータス情報の更新とが行われない。
これにより、アプリケーションプログラム用のソースファイルでニーモニック関数xorを呼び出すときに開発者が引数「no_check」の値を指定することにより、簡単に例外を検出する機能を有効にしたり無効にしたりできる。
また、次のようにグローバル変数で例外を検出する機能を抑制するようにしてもよい。
図７２（ａ）は、例外を検出する機能を抑制するためのグローバル変数「g_check_on」をニーモニック関数xorの内部に記述したときのソースファイル１５０の模式図である。
この例では、グローバル変数「g_check_on」の値が「1」かどうかを判定するif文を開発者がソースファイル１５０に記述する。そして、開発者は、そのif文の内部に、例外のチェックを行うコードT74～T78や、ステータス情報１４５の更新を行うコードT80～T83を記述する。
図７２（ｂ）は、このニーモニック関数xorを利用したアプリケーションプログラム用のソースファイル１５２のC++の疑似ソースコードを模式的に示す図である。
ここでは、開発者が、複数のニーモニック関数xorを呼び出すコード１５２ａをソースファイル１５２に記述した場合を想定する。そして、開発者が、これらのニーモニック関数xorが例外を検出する機能を無効にしたいと考えているものとする。この場合は、開発者は、コード１５２ａの前の位置にdisable_check関数を記述する。disable_check関数は、グローバル変数「g_check_on」の値を「0」にセットする関数である。
これにより、コード１５２ａのニーモニック関数xor(x0,x0,x0)とニーモニック関数xor(x1,x1,x1)の各々のコードT74～T78が実行されず、これらのニーモニック関数が例外を検出する機能を無効にすることができる。
また、このコード１５２ａの後のコード１５２ｂで例外を検出する機能を有効にしたい場合には、開発者は、コード１５２ａの後の位置にenable_check関数を記述すればよい。enable_check関数は、グローバル変数「g_check_on」の値を「1」にセットする関数である。
これにより、コード１５２ａのニーモニック関数xor(x0,x0,x0)とニーモニック関数xor(x1,x1,x1)の各々のコードT74～T78が実行され、これらのニーモニック関数が例外を検出する機能を有効にすることができる。
このようにdisable_check関数とenable_check関数とを利用することにより、ニーモニック関数が例外を検出する処理を無効にしたり、ニーモニック関数が例外を検出する処理を有効にしたりすることができる。なお、disable_check関数とenable_check関数の各々の定義は、例えば開発者がソースファイル１５０に記述しておけばよい。
次に、図５５～図６９のコードT79におけるMachineCodeEmitter関数について説明する。
図７３は、MachineCodeEmitter関数のC++の疑似ソースコードが記述されたソースファイル１５１の一例を示す模式図である。そのソースファイル１５１は、アセンブラプログラム自身のソースファイルの一部でもよい。
この例では、コードT90～T93によりMachineCodeEmitter関数の機能が実現される。このうち、コードT90は、変数「mnemonic」と変数「op0」、「op1」、「op2」の各々を３２ビットの符号無し整数として宣言する文である。
また、コードT91は、MachineCodeEmitter関数が引数として受け取った変数「nm」の内容に対応したオペコードを変数「mnemonic」に代入するコードである。例えば、変数「nm」で特定されるニーモニックが「mov」の場合には、mov命令のオペコード「0x01000000」が変数「mnemonic」に代入される。
そして、コードT92は、変数「nm」の内容に応じて変数「op0」、「op1」、「op2」の各々に対してビット操作を行うことにより、命令の仕様で定められたビット位置にこれらの変数を位置させるコードである。例えば、mov命令の場合には、３２ビットの内の１７～２４ビットに第１オペランドが位置し、８～１６ビットに第２オペランドが位置する。そこで、mov命令の場合には、文「op0=oplist[0]<<16;」を実行することにより、３２ビットの内の１７～２４ビットに変数「op0」のビット列を位置させる。一方、変数「op1」については、文「op1=oplist[1]<<8;」を実行することにより、３２ビットの８～１６ビット目に「op1」のビット列を位置させる。なお、mov命令は第３オペランドをとらないため、文「op2=0;」により変数「op2」を「0」にする。
更に、コードT93は、各変数「mnemonic」、「op0」、「op1」、「op2」の各々を上位ビットから順に連結したビット列を生成し、それを返り値として返す文である。そのビット列は、変数「oplist」で特定されるオペランドに対して変数「nm」で特定される命令が行う処理を表す機械語である。
このように、MachineCodeEmitter関数は、引数「nm」で表される命令が、引数「oplist」で表されるオペランドに対して行う処理を表す機械語を生成する関数である。
プロセッサ９０を開発する際には、そのプロセッサ９０で動作する機械語の実行可能プログラムを生成するためのツール群も開発される。そのツール群には、C言語やC++言語で記述されたソースファイルをアセンブリ言語に変換するためのコンパイラや、アセンブリ言語を機械語に変換するためのアセンブラプログラムが含まれる。そのようなツール群としては、例えばLLVMがある。MachineCodeEmitter関数は、LLVMのアセンブラプログラムに内蔵されている関数であり、アセンブラプログラムを開発した際にその動作が検証されて提供されている。そのため、本実施形態では、ニーモニック関数が正しい機械語を生成しているかという動作検証を行う必要がなく、開発者の負担減を実現できる。
開発者は、上記のようにニーモニック関数が定義されたソースファイル１５０を利用することにより、プロセッサで実行する様々なアプリケーションプログラムを開発することができる。そこで、そのアプリケーションプログラムの開発環境について以下に説明する。
図７４は、ニーモニック関数が定義されたソースファイル１５０を利用した開発環境について示す模式図である。
この例では、開発者が、例えばC++を用いてアプリケーションプログラム用のソースファイル１５２を作成する。そのソースファイル１５２は、JITコンパイラ技術の機能を使用することを前提としたファイルであって、C++のライブラリ関数に加えて、ソースファイル１５０にあるニーモニック関数を呼び出す記述を含む。
そして、開発者の指示の下で、コンパイラ、アセンブラプログラム、及びリンカのプログラム群１５３がビルドを行う。そのビルドの際、プログラム群１５３に含まれるコンパイラがソースファイル１５２をコンパイルする。
このとき、コンパイラは、各ソースファイル１５０、１５１、１５２を読み込んでアセンブリ言語の中間言語ファイルを出力する。これらのソースファイルのうち、ソースファイル１５１は、前述のMachineCodeEmitter関数が記述されたソースファイルである。そして、アセンブラプログラムがその中間言語ファイルを機械語の命令列に変換してオブジェクトファイルを生成する。
その後、リンカは、オブジェクトファイルと種々のライブラリとをリンクすることにより、プロセッサ９０で実行可能なバイナリ形式の実行可能プログラム１５４を生成する。
なお、機械語の生成ルールが秘匿されているようなプロセッサでは、アセンブラプログラムのソースファイルが公開されていないものの、実行ライブラリファイルが入手可能なこともある。その場合には、ソースファイル１５１に代えて機械語生成関数の機能を予め機械語の命令列に変換済みの実行ライブラリファイル１５１ａを入力として用い、これをリンクすることにより実行ライブラリファイル１５１ａを生成すればよい。
以上により、アプリケーションプログラム用のソースファイル１５２から実行可能プログラム１５４を生成することができる。
本実施形態では、図５５～図６９に示したように、各ニーモニック関数を定義するソースファイル１５０に、図５２（ａ）、（ｂ）の検出ルールに従って例外を検出するコードT74～T78が記述されている。そのため、図５２（ａ）、（ｂ）の検出ルールに当てはまるような記述ミスがアプリケーションプログラム用のソースファイル１５２にあると、実行可能プログラム１５４の実行時にエラーが出力される。これにより、ソースファイル１５２に記述ミスがあることに開発者が気付くことができ、開発者がソースファイル１５２のデバッグをするのが容易となる。
次に、この実行可能プログラム１５４を実行するときの情報処理装置１１７の動作について説明する。
図７５は、実行可能プログラム１５４を得るためのアプリケーションプログラム用のソースファイル１５２に記述されているC++の疑似ソースコードの模式図である。
図７５に示すように、この例では、mov命令、load命令、add命令、及びstore命令の各々に対応したニーモニック関数がソースファイル１５２に記述されている場合を想定する。
図７６は、このソースファイル１５２をコンパイルして得られた実行可能プログラム１５４を実行するときの情報処理装置１１７の動作について示すフローチャートである。
まず、情報処理装置１１７は、ステータス情報１４５（図５１参照）を初期化する（ステップＳ６１）。
例えば、情報処理装置１１７は、配列「dataSizeVReg」、「dataTypeGReg」、及び「dataTypeVReg」の全ての要素に「CLEAN」を格納する。更に、情報処理装置１１７は、配列「readAccessGReg」、「readAccessVReg」、「writeAccessGReg」、及び「writeAccessVReg」の全ての要素に「FALSE」を格納する。
次に、情報処理装置１１７は、実行可能プログラム１５４に記述されているニーモニック関数の実行処理を行う（ステップＳ６２）。この処理は、図７５の実行可能プログラム１５４に記述されている複数のニーモニック関数ごとに行われる。
例えば、図７５のコードT85に記述されているニーモニック関数load(v2.b, x0)の実行処理を行うと、そのニーモニック関数load(v2.b, x0)の内部でMachineCodeEmitter関数が呼び出される。そして、そのMachineCodeEmitter関数が、アセンブリ言語のコード「load v2.b, x0」に相当する機械語１２８（図４５参照）を生成し、それをメモリ２８に書き込む。
次に、情報処理装置１１７は、ステップＳ６２で生成した機械語１２８を呼び出し（ステップＳ６３）、それを実行する（ステップＳ６４）。
以上により、実行可能プログラム１５４を実行するときの情報処理装置１１７の処理を終える。
次に、上記したステップＳ６２のニーモニック関数の実行処理について説明する。
図７７は、ニーモニック関数の実行処理をするときの情報処理装置１１７の機能構成図である。
図７７に示すように、情報処理装置１１７は、制御部１７１と記憶部１７２とを備える。
このうち、記憶部１７２は、メモリ２８により実現される機能ブロックであり、前述のステータス情報１４５を記憶する。
一方、制御部１７１は、例外検出部１７５、エラー出力部１７６、ステータス更新部１７７、機械語生成部１７８、及び書き込み部１７９を有する。
このうち、例外検出部１７５は、図５５～図６９のコードT74～T78によって実現される処理部であって、ニーモニック関数を実行したときに発生する例外をステータス情報１４５に基づいて検出する。
例えば、図７５のコードT85に記述されているニーモニック関数vload(v2.b, x0)の実行処理を行う場合を考える。この場合は、図５９のコードT74において、ステータス情報１４５の一部である配列writeAccessVReg[dst.regIndex]と配列readAccessVReg[dst.regIndex]に基づいてR例外が検出される。なお、変数「dst」には、ニーモニック関数vload(v2.b, x0)の第１引数の「v2.b」が格納されている。
更に、この場合は、図５９のコードT75において、ステータス情報１４５の一部である配列writeAccessVReg[addr.regIndex]に基づいてW例外が検出される。なお、変数「addr」には、ニーモニック関数vload(v2.b, x0)の第２引数の「x0」が格納されている。
一方、エラー出力部１７６は、例外検出部１７５が例外を検出したときにエラーを出力する処理部である。本実施形態では、図５５～図６９のコードT74～T78の各々に記述されているthrow文によりエラー出力部１７６が実現される。図７５のコードT85に記述されているニーモニック関数vload(v2.b, x0)の実行処理を行う例では、図５９のコードT74におけるthrow文によってエラーが出力される。図５９に示すように、そのエラーの内容は、「“Invalid register use. Data on destination register is not used.”」という文字列である。また、図５９のコードT75を実行した場合には、「“Invalid register use. No data written on source register.”」という文字列がエラーとして出力される。
そして、ステータス更新部１７７は、例外検出部１７５が例外を検出しなかったときにステータス情報１４５の内容を更新する処理部である。そのステータス更新部１７７の機能は、図５５～図６９のコードT80～T83によって実現される。
更に、機械語生成部１７８は、図５５～図６９のコードT79におけるMachineCodeEmitter関数によって実現される処理部である。前述のように、MachineCodeEmitter関数は、ニーモニック関数に対応する命令がオペランドに対して行う処理を表す機械語１２８を生成する関数である。
そして、書き込み部１７９は、図５５～図６９のコードT79におけるwrite関数によって実現される処理部であって、機械語生成部１７８が生成した機械語の命令列をメモリ２８に書き込む処理部である。
次に、図７７に示した情報処理装置１１７の各部が実行する情報処理方法について説明する。
図７８は、本実施形態に係る情報処理方法のフローチャートである。
まず、例外検出部１７５が、例外を検出する機能が有効かどうかを判断する（ステップＳ７１）。例えば、例外検出部１７５は、図７１の引数「no_check」の値が「0」の場合には当該機能が有効であると判断し、引数「no_check」の値が「0」以外の場合には当該機能が有効ではないと判断する。
また、開発者が図７２（ｂ）の関数disable_check()をソースファイル１５０に記述している場合は、例外検出部１７５は、グローバル変数「g_check_on」の値に応じて例外を検出する機能が有効かどうかを判断する。例えば、例外検出部１７５は、グローバル変数「g_check_on」の値が「1」の場合には当該機能が有効であると判断し、グローバル変数「g_check_on」の値が「1」以外の場合には当該機能が有効ではないと判断する。
ここで、例外を検出する機能が有効ではない（ステップＳ７１：否定）と判定された場合にはステップＳ７６に移る。
ステップＳ７６においては、機械語生成部１７８が機械語１２８を生成する。例えば、図７５のコードT85に記述されているニーモニック関数vload(v2.b, x0)を実行する場合を考える。この場合は、機械語生成部１７８は、ニーモニック関数vload(v2.b, x0)に対応したアセンブリ言語の命令「vload v2.b, x0」がオペランドの「v2.b」、「x0」に対して行う処理の機械語１２８を生成する。
そして、書き込み部１７９が機械語１２８をメモリ２８に書き込む（ステップＳ７７）。
一方、例外を検出する機能が有効である（ステップＳ７１：肯定）と判定された場合にはステップＳ７２に移る。
ステップＳ７２においては、例外検出部１７５が例外検出処理を行う。その例外検出処理については後述する。
そして、例外検出部１７５が、例外を検出したかどうかを判定する（ステップＳ７３）。
ここで、例外を検出したと判定された場合（ステップＳ７３：肯定）にはステップＳ７４に移る。
ステップＳ７４においては、エラー出力部１７６がエラーを出力し、処理を終える。
一方、例外を検出しなかったと判定された場合（ステップＳ７３：否定）にはステップＳ７５に移り、ステータス更新部１７７がステータス情報１４５を更新する。
この後は、前述のステップＳ７６とステップＳ７７を実行し、処理を終える。
次に、ステップＳ７２の例外検出処理について説明する。
図７９は、ステップＳ７２の例外検出処理のフローチャートである。
この例外検出処理は、図５２（ａ）、（ｂ）の検出ルールに基づいて、以下のように例外検出部１７５が実行する。
まず、例外検出部１７５が、データタイプ例外があるかどうかをチェックする（ステップＳ８１）。このチェックは、図５５～図６９のコードT77を実行することにより行われる。コードT77に記述されているように、例外検出部１７５は、ニーモニック関数に対応した命令が演算の対象とするデータタイプと、ニーモニック関数の引数のソースレジスタに実際に書き込まれているデータタイプと異なるかを判断する。
例えば、図５８のコードT77では、１番目のソースレジスタに実際に書き込まれているデータタイプ「dataTypeVReg[src0.regIndex]」が、float_multiply命令が演算の対象とするデータタイプ「typeFloat」と異なるかが判断される。また、このコードT77では、２番目のソースレジスタに書き込まれているデータのデータタイプ「dataTypeVReg[src1.regIndex]」が、float_multiply命令が演算の対象とするデータタイプ「typeFloat」と異なるかも判断される。
そして、命令が演算の対象とするデータタイプとソースレジスタに実際に書き込まれているデータのデータタイプとが異なる場合に、例外検出部１７５は、データタイプ例外を検出する。
次に、例外検出部１７５が、データサイズ例外があるかどうかをチェックする（ステップＳ８２）。このチェックは、図５５～図６９のコードT76を実行することにより行われる。コードT76に記述されているように、例外検出部１７５は、ニーモニック関数の引数のソースレジスタに実際に書き込まれているデータのデータサイズと、当該引数に指定されたデータサイズとが異なるかを判断する。
例えば、図５７のコードT76では、１番目のソースレジスタに書き込まれているデータのデータサイズ「dataSizeVReg[src0.regIndex]」が、引数に指定されたデータサイズ「sizeS」と異なるかが判断される。また、このコードT76では、２番目のソースレジスタに書き込まれているデータのデータサイズ「dataSizeVReg[src1.regIndex]」が、引数に指定されたデータサイズ「sizeS」と異なるかも判断される。
そして、ソースレジスタに実際に書き込まれているデータのデータサイズと引数に指定されたデータサイズとが異なる場合に、例外検出部１７５は、データサイズ例外を検出する。
次いで、例外検出部１７５が、W例外があるかどうかをチェックする（ステップＳ８３）。このチェックは、図５５～図６９のコードT75を実行することにより行われる。コードT75に記述されるように、例外検出部１０５は、配列「writeAccessGReg」、「writeAccessVReg」の各要素のうち、ニーモニック関数の引数に指定されたソースレジスタに対応する要素が「FALSE」の場合にW例外を検出する。
例えば、図５７のコードT75では、１番目のソースレジスタに対応した「writeAccessVReg[src0.regIndex]」が「TRUE」でないかどうかが判断される。同様に、このコードT75では、２番目のソースレジスタに対応した「writeAccessVReg[src1.regIndex]」が「TRUE」でないかどうかも判断される。
そして、「writeAccessVReg[src0.regIndex]」が「TRUE」でない場合や、「writeAccessVReg[src1.regIndex]」が「TRUE」でない場合に、例外検出部１０５がW例外を検出する。
続いて、例外検出部１７５が、R例外があるかどうかをチェックする（ステップＳ８４）。このチェックは、図５５～図６９のコードT74を実行することにより行われる。コードT74に記述されるように、ニーモニック関数の引数に指定されたレジスタがベクトルレジスタの場合は、例外検出部１７５は、配列「writeAccessVReg」と配列「readAccessVReg」を使用してチェックを行う。例えば、例外検出部１７５は、これらの配列「writeAccessVReg」、「readAccessVReg」の各要素のうちで、ニーモニック関数の引数に指定されたデスティネーションレジスタに対応する要素を使用する。そして、例外検出部１７５は、その配列「writeAccessVReg」の要素が「TRUE」であり、かつ配列「readAccessVReg」の要素が「FALSE」の場合にR例外を検出する。
例えば、図５７のコードT74においては、「writeAccessVReg[dst.regIndex]」が「TRUE」であり、かつ「readAccessVReg[dst.regIndex]」が「TRUE」でない場合に、例外検出部１７５がR例外を検出する。
なお、デスティネーションレジスタが汎用レジスタの場合にも、例外検出部１７５は、配列「writeAccessGReg」と配列「readAccessGReg」のそれぞれの要素を利用してR例外を検出する。
次に、例外検出部１７５が、srcデータタイプ例外があるかどうかをチェックする（ステップＳ８５）。このチェックは、図５５～図６９のコードT78を実行することにより行われる。コードT78に記述されるように、ニーモニック関数の引数に指定されたレジスタがベクトルレジスタの場合は、例外検出部１７５は、配列「dataTypeVReg」を使用してチェックを行う。例えば、例外検出部１７５は、ニーモニック関数の引数に指定された二つのソースレジスタの各々に対応する配列「dataTypeVReg」の要素が同一かどうかを判断し、同一でない場合にsrcデータタイプ例外を検出する。
図５６のコードT78では、１番目のソースレジスタに対応した「dataTypeVReg[src0.regIndex]」と、２番目のソースレジスタに対応した「dataTypeVReg[src1.regIndex]」とが等しくない場合に、例外検出部１７５がsrcデータタイプ例外を検出する。
なお、ソースレジスタが汎用レジスタの場合にも、例外検出部１７５は、「dataTypeGReg」を利用してsrcデータタイプ例外を検出する。
以上により、例外検出処理を終える。
上記した本実施形態によれば、ニーモニック関数を定義するソースファイル１５０に、開発者が、図５２（ａ）、（ｂ）の検出ルールに従って例外を検出するコードT74～T78を記述する。そのため、アプリケーションプログラム用のソースファイル１５２に記述ミスがあった場合に、その記述ミスに起因した例外を例外検出部１７５が検出し、更にエラー出力部１７６がエラーを出力する。そのエラーに基づいて、開発者がソースファイル１５２を容易にデバッグすることができるようになり、プログラム開発の効率化を図ることができる。
更に、このように記述ミスに起因した例外を例外検出部１７５が検出することで、記述ミスのある実行可能プログラム１５４をプロセッサ９０で無駄に実行する時間が減る。その結果、プロセッサ９０やメモリ２８等のハードウェア資源の無駄な消費を改善できる。
しかも、上記のコードT74～T78は、ニーモニック関数の引数が示すレジスタのステータス情報１４５（図５１参照）に基づいて例外を検出するコードである。そのステータス情報１４５における各配列を使用することにより、例外検出部１７５が、「R例外」、「W例外」、「データタイプ例外」、「データサイズ例外」、及び「srcデータタイプ例外」を検出することができる。そして、これらのどの例外が検出されたかに応じ、開発者が、アプリケーションプログラム用のソースファイル１５２における具体的な記述ミスを特定することができる。
２０…プロセッサ、２１…命令デコード回路、２２…データフェッチ回路、２３…命令実行回路、２４…書き戻し回路、２５…例外処理回路、２６…ステータスレジスタファイル、２７…演算用レジスタファイル、２８…メモリ、２８ａ…命令メモリ、２８ｂ…データメモリ、３０…実行回路、３１…ステータス更新回路、３２ａ…第１の例外検出部、３２ｂ…第２の例外検出部、４０…選択回路、４１…例外検出回路、４２…例外信号生成回路、４３…データタイプ例外検出回路、４４…データサイズ例外検出回路、４５…W例外検出回路、４６…srcデータタイプ例外検出回路、４７…R例外検出回路、５０…例外ベクタテーブル、６０、１００…情報処理装置、６０ａ、１００ａ…記憶装置、６０ｂ、１００ｂ…メモリ、６０ｃ、１００ｃ…プロセッサ、６０ｄ、１００ｄ…通信インターフェース、６０ｅ、１００ｅ…表示装置、６０ｆ、１００ｆ…入力装置、６０ｇ、１００ｇ…バス、６０ｈ、１００ｈ…記録媒体、６１…シミュレーションプログラム、６３…制御部、６４…記憶部、６５…環境構築部、６６…シミュレーション実行部、７０…疑似プロセッサ、７１…命令デコード部、７２…データフェッチ部、７３…命令実行部、７４…書き戻し部、７５…例外処理部、７６…ステータスレジスタファイル部、７６ａ…第２の記憶領域、７７…演算用レジスタファイル部、７７ａ…第１の記憶領域、７８…メモリ部、７８ａ…命令メモリ部、７８ｂ…データメモリ部、７８ｃ…第３の記憶領域、８２…例外検出部、８２ａ…第１の例外検出部、８２ｂ…第２の例外検出部、８３…実行部、１０１…制御部、１０２…記憶部、１０３…初期化部、１０４…取得部、１０５…例外検出部、１０６…エラー出力部、１０７…ステータス更新部、１０８…機械語生成部、１１０、１４５…ステータス情報、１１２…アセンブラプログラム、１１７…情報処理装置、１５３…プログラム群、１７１…制御部、１７２…記憶部、１７５…例外検出部、１７６…エラー出力部、１７７…ステータス更新部、１７８…機械語生成部、１７９…書き込み部。

Claims (18)

  1. 第１のレジスタと、
    前記第１のレジスタに係るステータス情報を格納する第２のレジスタと、
    前記第２のレジスタに格納されている前記ステータス情報に基づいて、前記第１のレジスタがオペランドに指定された命令における例外を検出する検出回路と、
    を有し、
    前記ステータス情報は、前記命令の実行前に前記第１のレジスタが書き込み先のレジスタとして使用済みかどうかを示す第１のフラグと、前記命令の実行前に前記第１のレジスタが読み出し元のレジスタとして使用済みかどうかを示す第２のフラグとを有し、
    前記検出回路は、前記第１のレジスタが書き込み先のレジスタとして使用済みであることを前記第１のフラグが示しており、かつ前記第１のレジスタが読み出し元のレジスタとして使用済みではないことを前記第２のフラグが示している場合に前記例外を検出することを特徴するプロセッサ。
  2. 前記ステータス情報は、前記命令の実行前に前記第１のレジスタが書き込み先のレジスタとして使用済みかどうかを示す第１のフラグを有し、
    前記検出回路は、前記第１のレジスタが書き込み先のレジスタとして使用済みではないことを前記第１のフラグが示している場合に前記例外を検出することを特徴とする請求項１に記載のプロセッサ。
  3. 前記ステータス情報は、前記第１のレジスタに格納されているデータのデータタイプを示す型情報を有し、
    前記検出回路は、前記型情報が示す前記データタイプと、前記命令が演算の対象とするデータタイプとが一致しない場合に前記例外を検出することを特徴とする請求項１に記載のプロセッサ。
  4. 前記第１のレジスタは、ベクトルデータの複数の要素が格納されるベクトルレジスタであり、
    前記ステータス情報は、前記第１のレジスタに格納されている前記要素のデータサイズを示すサイズ情報を有し、
    前記検出回路は、前記サイズ情報が示すデータサイズと、前記オペランドにおいて指定された前記第１のレジスタのデータサイズとが一致しない場合に前記例外を検出することを特徴とする請求項１に記載のプロセッサ。
  5. 前記第１のレジスタを複数有すると共に、複数の前記第１のレジスタの各々に対応して前記第２のレジスタを複数有し、
    前記ステータス情報は、前記第１のレジスタに格納されているデータのデータタイプを示す型情報を有し、
    前記命令において複数の前記第１のレジスタが複数のソースレジスタの各々に指定された場合であって、複数の前記ソースレジスタの各々に格納されているデータのデータタイプ同士が同一であることを前記命令が前提としているときに、前記検出回路は、前記第１のレジスタの各々の前記型情報同士が一致しない場合に前記例外を検出することを特徴とする請求項１に記載のプロセッサ。
  6. 前記第２のレジスタに格納されている前記ステータス情報を前記第１のレジスタに保存する第１のストア命令と、前記第１のレジスタに保存されている前記ステータス情報を前記第２のレジスタに書き込む第１のロード命令とを実行する実行回路を更に有することを特徴とする請求項１に記載のプロセッサ。
  7. 前記第２のレジスタに格納されている前記ステータス情報をメモリに保存する第２のストア命令と、前記メモリに保存されている前記ステータス情報を前記第２のレジスタに書き込む第２のロード命令とを実行する実行回路を更に有することを特徴とする請求項１に記載のプロセッサ。
  8. 前記第１のレジスタを複数有すると共に、複数の前記第１のレジスタの各々に対応して前記第２のレジスタを複数有し、
    複数の前記第２のレジスタの各々に格納されている複数の前記ステータス情報を一括してメモリに保存する第３のストア命令と、前記メモリに保存されている複数の前記ステータス情報を一括して前記第２のレジスタの各々に書き込む第３のロード命令とを実行する実行回路を更に有することを特徴とする請求項１に記載のプロセッサ。
  9. 前記例外を検出する前記検出回路の機能を無効にする無効命令と、前記機能を有効にする有効命令とを実行する実行回路を更に有することを特徴とする請求項１に記載のプロセッサ。
  10. 前記無効命令と前記有効命令の各々は、例外の種類をオペランドとしてとり、
    前記実行回路は、前記無効命令を実行することにより前記種類の前記例外を検出する前記機能を無効にし、前記有効命令を実行することにより前記種類の前記例外を検出する前記機能を有効にすることを特徴とする請求項９に記載のプロセッサ。
  11. 前記第２のレジスタを複数有すると共に、
    前記無効命令と前記有効命令の各々は、複数の前記第２のレジスタのうちの一つをオペランドとしてとり、
    前記実行回路は、前記無効命令の前記オペランドに指定された前記第２のレジスタに格納されている前記ステータス情報を用いて前記例外を検出する前記機能を無効にし、前記有効命令の前記オペランドに指定された前記第２のレジスタに格納されている前記ステータス情報を用いて前記例外を検出する前記機能を有効にすることを特徴とする請求項９に記載のプロセッサ。
  12. 第１のレジスタを模擬する第１の記憶領域をメモリに確保する処理と、
    前記第１のレジスタに係るステータス情報格納する第２のレジスタを模擬する第２の記憶領域を前記メモリに確保する処理と、
    前記第２のレジスタに格納されている前記ステータス情報に基づいて、前記第１のレジスタがオペランドに指定された命令における例外を検出する処理と、
    をコンピュータに実行させ、
    前記ステータス情報は、前記命令の実行前に前記第１のレジスタが書き込み先のレジスタとして使用済みかどうかを示す第１のフラグと、前記命令の実行前に前記第１のレジスタが読み出し元のレジスタとして使用済みかどうかを示す第２のフラグとを有し、
    前記例外を検出する処理において、前記第１のレジスタが書き込み先のレジスタとして使用済みであることを前記第１のフラグが示しており、かつ前記第１のレジスタが読み出し元のレジスタとして使用済みでないことを前記第２のフラグが示している場合に前記例外を検出することを特徴とするシミュレーションプログラム。
  13. 前記ステータス情報は、前記命令の実行前に前記第１のレジスタが書き込み先のレジスタとして使用済みかどうかを示す第１のフラグを有し、
    前記例外を検出する処理において、前記第１のレジスタが書き込み先のレジスタとして使用済みでないことを前記第１のフラグが示している場合に前記例外を検出することを特徴とする請求項１２に記載のシミュレーションプログラム。
  14. 前記ステータス情報は、前記第１のレジスタに格納されているデータのデータタイプを示す型情報を有し、
    前記例外を検出する処理において、前記型情報が示すデータタイプと、前記命令が演算の対象とするデータタイプとが一致しない場合に前記例外を検出することを特徴とする請求項１２に記載のシミュレーションプログラム。
  15. 前記第１のレジスタは、ベクトルデータの複数の要素が格納されるベクトルレジスタであり、
    前記ステータス情報は、前記第１のレジスタに格納されている前記要素のデータサイズを示すサイズ情報を有し、
    前記例外を検出する処理において、前記サイズ情報が示すデータサイズと、前記オペランドにおいて指定された前記第１のレジスタのデータサイズとが一致しない場合に前記例外を検出することを特徴とする請求項１２に記載のシミュレーションプログラム。
  16. 前記第１の記憶領域が複数の前記第１のレジスタを模擬すると共に、複数の前記第１のレジスタの各々に対応した複数の前記第２のレジスタを前記第２の記憶領域が模擬し、
    前記ステータス情報は、前記第１のレジスタに格納されているデータのデータタイプを示す型情報を有し、
    前記命令において複数の前記第１のレジスタが複数のソースレジスタの各々に指定された場合であって、複数の前記ソースレジスタの各々に格納されているデータのデータタイプ同士が同一であることを前記命令が前提としているときに、前記例外を検出する処理において、前記第１のレジスタの各々の前記型情報同士が一致しない場合に例外を検出することを特徴とする請求項１２に記載のシミュレーションプログラム。
  17. オペランドにレジスタが指定された命令のアセンブリ言語のコードを取得する処理と、
    前記レジスタに係るステータス情報に基づいて、前記命令における例外を検出する処理と、
    前記例外を検出したときにエラーを出力する処理と、
    前記例外を検出しなかったときに前記コードの機械語を生成する処理と、
    をコンピュータに実行させ、
    前記ステータス情報は、前記命令の実行前に前記レジスタが書き込み先のレジスタとして使用済みかどうかを示す第１のフラグと、前記命令の実行前に前記レジスタが読み出し元のレジスタとして使用済みかどうかを示す第２のフラグとを有し、
    前記例外を検出する処理は、前記レジスタが書き込み先のレジスタとして使用済みであることを前記第１のフラグが示しており、かつ前記レジスタが読み出し元のレジスタとして使用済みではないことを前記第２のフラグが示している場合に前記例外を検出するためのアセンブラプログラム。
  18. 命令のオペランドに指定されたレジスタを表す引数を前記命令と対応付けられた関数が受け取ったときに、前記引数が表す前記レジスタに係るステータス情報に基づいて、前記命令における例外を検出する処理と、
    前記例外を検出したときにエラーを出力する処理と、
    前記例外を検出しなかったときに、前記オペランドに対して前記命令が行う処理を表す機械語を生成する処理と、
    前記機械語をメモリに書き込む処理と、
    を有することを特徴とする情報処理プログラム。
JP2021572135A 2020-01-20 2020-01-20 プロセッサ、シミュレータプログラム、アセンブラプログラム、及び情報処理プログラム Active JP7315872B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/001742 WO2021149113A1 (ja) 2020-01-20 2020-01-20 プロセッサ、シミュレータプログラム、アセンブラプログラム、及び情報処理プログラム

Publications (3)

Publication Number Publication Date
JPWO2021149113A1 JPWO2021149113A1 (ja) 2021-07-29
JPWO2021149113A5 JPWO2021149113A5 (ja) 2022-07-20
JP7315872B2 true JP7315872B2 (ja) 2023-07-27

Family

ID=76992115

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021572135A Active JP7315872B2 (ja) 2020-01-20 2020-01-20 プロセッサ、シミュレータプログラム、アセンブラプログラム、及び情報処理プログラム

Country Status (5)

Country Link
US (1) US20220300288A1 (ja)
EP (1) EP4095698A4 (ja)
JP (1) JP7315872B2 (ja)
CN (1) CN114830097A (ja)
WO (1) WO2021149113A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118519817A (zh) * 2024-07-19 2024-08-20 浙江大华技术股份有限公司 一种算力cpu的异常数据获取方法、装置和计算机设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000112757A (ja) 1998-10-02 2000-04-21 Nec Corp マイクロプロセッサ
US6185671B1 (en) 1998-03-31 2001-02-06 Intel Corporation Checking data type of operands specified by an instruction using attributes in a tagged array architecture
US20050172109A1 (en) 2001-06-01 2005-08-04 Microchip Technology Incorporated Register pointer trap
US20050246696A1 (en) 2004-04-29 2005-11-03 International Business Machines Corporation Method and apparatus for hardware awareness of data types
US20080028262A1 (en) 2006-07-27 2008-01-31 International Business Machines Corporation Method and Data Processing System for Finding Problems Caused by Access to Uninitialized Data Storage in Assembler Programs
JP6461828B2 (ja) 2014-02-10 2019-01-30 株式会社日清製粉グループ本社 磁性粒子の製造方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4021655A (en) * 1976-03-30 1977-05-03 International Business Machines Corporation Oversized data detection hardware for data processors which store data at variable length destinations
JPS63278147A (ja) * 1987-05-11 1988-11-15 Fujitsu Ltd レジスタ誤使用防止制御方式
JPS6461828A (en) * 1987-09-01 1989-03-08 Nec Corp Register reference holding mechanism
US5132972A (en) * 1989-11-29 1992-07-21 Honeywell Bull Inc. Assembly language programming potential error detection scheme sensing apparent inconsistency with a previous operation
JPH0452734A (ja) * 1990-06-14 1992-02-20 Koufu Nippon Denki Kk 汎用レジスタ例外検出回路
JP2793396B2 (ja) 1991-11-15 1998-09-03 株式会社東芝 電子計算機の演算ステータス保持装置
US6289445B2 (en) * 1998-07-21 2001-09-11 Lsi Logic Corporation Circuit and method for initiating exception routines using implicit exception checking
DE19933130A1 (de) * 1999-07-19 2001-01-25 Giesecke & Devrient Gmbh Operandenstapelspeicher und Verfahren zum Betreiben eines Operandenstapelspeichers
JP2002014809A (ja) * 2000-06-28 2002-01-18 Mitsubishi Electric Corp マイクロプロセッサ並びにアセンブラ、その方法およびそのプログラムを記録した記録媒体
JP2004118419A (ja) * 2002-09-25 2004-04-15 Seiko Epson Corp 半導体装置、マイクロコンピュータ、電子機器、半導体装置の制御方法
US10296416B2 (en) * 2016-07-02 2019-05-21 Intel Corporation Read from memory instructions, processors, methods, and systems, that do not take exception on defective data
KR102021447B1 (ko) * 2018-04-06 2019-09-16 서울대학교산학협력단 컴퓨팅 장치 및 그것의 동작 방법

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185671B1 (en) 1998-03-31 2001-02-06 Intel Corporation Checking data type of operands specified by an instruction using attributes in a tagged array architecture
JP2000112757A (ja) 1998-10-02 2000-04-21 Nec Corp マイクロプロセッサ
US20050172109A1 (en) 2001-06-01 2005-08-04 Microchip Technology Incorporated Register pointer trap
US20050246696A1 (en) 2004-04-29 2005-11-03 International Business Machines Corporation Method and apparatus for hardware awareness of data types
US20080028262A1 (en) 2006-07-27 2008-01-31 International Business Machines Corporation Method and Data Processing System for Finding Problems Caused by Access to Uninitialized Data Storage in Assembler Programs
JP6461828B2 (ja) 2014-02-10 2019-01-30 株式会社日清製粉グループ本社 磁性粒子の製造方法

Also Published As

Publication number Publication date
EP4095698A1 (en) 2022-11-30
EP4095698A4 (en) 2023-03-15
US20220300288A1 (en) 2022-09-22
CN114830097A (zh) 2022-07-29
WO2021149113A1 (ja) 2021-07-29
JPWO2021149113A1 (ja) 2021-07-29

Similar Documents

Publication Publication Date Title
Reshadi et al. Instruction set compiled simulation: A technique for fast and flexible instruction set simulation
KR101642556B1 (ko) 이진 번역을 수행하기 위한 방법 및 시스템
GB2480285A (en) Conditional compare instruction which sets a condition code when it is not executed
US20040006667A1 (en) Apparatus and method for implementing adjacent, non-unit stride memory access patterns utilizing SIMD instructions
JP2004510245A (ja) アレイ処理動作
CN111290952A (zh) 一种动态链接库函数的跟踪方法及装置
WO2021249054A1 (zh) 一种数据处理方法及装置、存储介质
TW201908757A (zh) 測試向量元素內部的位元值
JP4004915B2 (ja) データ処理装置
CN116860256A (zh) 一种面向risc-v基础c库的优化方法
CN114428642B (zh) 一种基于新型处理器架构的随机指令生成环境
JP7315872B2 (ja) プロセッサ、シミュレータプログラム、アセンブラプログラム、及び情報処理プログラム
CN107729118A (zh) 面向众核处理器的修改Java虚拟机的方法
US11886839B2 (en) Non-transitory computer-readable recording medium, function generation method, and information processing device
CN116594682A (zh) 基于simd库的自动测试方法及装置
Engelke et al. Using LLVM for optimized lightweight binary re-writing at runtime
Smith Programming with 64-bit ARM Assembly Language: Single Board Computer Development for Raspberry Pi and Mobile Devices
US20100100692A1 (en) Exploiting Register High-Words
WO2022174542A1 (zh) 一种数据处理的方法、装置、处理器和计算设备
JP4545777B2 (ja) データ処理装置
JP2013539882A (ja) データ要素の条件付き選択
Fink Translating x86 Binaries to LLVM Intermediate Representation
JP4498338B2 (ja) データ処理装置
JP2002182925A (ja) コンパイル方法及びコンピュータ読み取り可能な記録媒体
TW202403546A (zh) 用於可擴縮向量指令集架構的子向量支援指令

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220520

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220520

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230613

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230626

R150 Certificate of patent or registration of utility model

Ref document number: 7315872

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150