JP2902402B2 - データ処理装置 - Google Patents

データ処理装置

Info

Publication number
JP2902402B2
JP2902402B2 JP62247419A JP24741987A JP2902402B2 JP 2902402 B2 JP2902402 B2 JP 2902402B2 JP 62247419 A JP62247419 A JP 62247419A JP 24741987 A JP24741987 A JP 24741987A JP 2902402 B2 JP2902402 B2 JP 2902402B2
Authority
JP
Japan
Prior art keywords
instruction
bit
flag
exception
size
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.)
Expired - Fee Related
Application number
JP62247419A
Other languages
English (en)
Other versions
JPS6491236A (en
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.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
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 Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP62247419A priority Critical patent/JP2902402B2/ja
Publication of JPS6491236A publication Critical patent/JPS6491236A/ja
Priority to US08/260,031 priority patent/US5680568A/en
Application granted granted Critical
Publication of JP2902402B2 publication Critical patent/JP2902402B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/34Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes
    • G06F9/355Indexed addressing

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Executing Machine-Instructions (AREA)
  • Memory System (AREA)

Description

【発明の詳細な説明】 [産業上の利用分野] 本発明はデータ処理装置に関し、更に記述すれば、オ
ペランドに対して汎用アドレッシングを行なうデータ処
理に関するものであり、特に、インデックス・アドレッ
シング及びメモリ間接アドレッシングのために拡張フィ
ールドを持つデータ処理装置に関する。 [従来の技術] 電子計算機を用いてデータ処理を行なう場合、人間が
より解りやすい形式の高級言語と言われるC、Modula−
2、Pascal等を用いて、プログラムが作成されている
が、高級言語で書かれた原始プログラムは、通常コンパ
イラと呼ばれる翻訳プログラムにより機械命令による目
的プログラムへ変換された後、実行されている。 しかしながら、高級言語で表現されるデータの構造と
機械語のデータとの間には機能的に差があるために、高
級言語では容易に記述できるようなデータの読み書きが
複数個の機械語命令列へ変換され、逐次直列に処理され
るので、変換後の目的プログラムは必ずしも高い性能を
持って処理されていない。 例えば、第388図に示すようなデータ構造は高級言語
によるプログラムでは非常によく用いられる。図におい
てPはレコード1のアドレスを保持するポインタであ
り、レコード1およびレコード2にはそれぞれkey,val
およびnextと名付けられたフィールドが定義されてい
る。 valフィールドには、それぞれのレコードが保持する
べきデータが格納されており、keyフィールドには、val
フィールドのデータを識別するためのキーが格納されて
いる。また、nextフィールドは、次のレコードのアドレ
スを保持するポインタである。 今、valフィールドが1次元の整数の配列であると
き、レコード1のvalフィールドのi番目の要素の参照
は例えばC言語で、Pの値がレジスタ上にあっても、メ
モリ上のどの位置にあっても、それらを全く意識するこ
となく、 P−>val〔i〕 と表現される。 しかし、これをコンパイラ等で翻訳する際には、例え
ば、第389図のような場合、レジスタ1のkeyフィールド
のサイズが2であり、valフィールドの要素val[0],v
al[1],…のそれぞれのサイズが4であることを認識
し、ポインタPの値に2を加え、さらに4×iを加えて
目的のval[i]のフィールドのアドレスを得る。 従来のデータ処理装置、例えば米国のDEC社のVAX或は
ナショナルセミコンダクタ社のNS32032では、上述のア
ドレスの計算を行なうためのアドレッシング・モードを
備えている。 [発明が解決しようとする問題点] 例えば、iの値がすでにレジスタR1上にある場合、 (1)Pの値がすでにレジスタR0上にあるときには、第
390図に示すように、 レジスタR0の値に定数2を加え、その結果にレジスタ
R1の値と定数4をかけた値を加え、オペランドのアドレ
スとするような、アドレッシング・モードを備えてい
る。 しかしながら、 (2)Pの値が大域変数上にある場合、或は局所変数上
にあるときには、図中の破線が示すように、いったんP
の値をレジスタR0に格納する余分な命令を実行する必要
がある。 この場合、レジスタR0が何らかの必要なデータを保持
しているときには、レジスタR0の内容を一時的にメモリ
上に退避するような、さらに余分な命令を実行する必要
があり、最後にメモリ上に退避した値をレジスタR0に復
帰するような命令も実行する必要がある。 而して、従来の装置におけるオペランド拡張方法は以
下のとおりである。 DEC社のVAXのような従来の装置では、インデックスモ
ードにおいて、アドレス修飾拡張を行なうことが可能な
命令形式を備えている。 第391図に、VAXのインデックスモードの命令の形式を
示す。 VAXの命令形式に関する文献では、命令形式の記述をl
ittle−endianで行っているが、本明細書では、すべてb
ig−endianにより行なうことにする。 同図に示されるように、8ビットのオペレーションコ
ード指定フィールドOPに続いて、8ビットのインデック
ス指定フィールドが設けられている。インデックス指定
フィールドの最初の4ビットの値は16進数で4であり、
この値がインデックスモードであることを示す。また、
次の4ビットのRxフィールドは、インデックスレジスタ
の番号を示す。さらに、インデックス指定フィールドに
続いてベースアドレス指定フィールドが設けられている
が、このフィールドによりベースアドレスが指定され
る。ベースアドレス指定フィールドのModeフィールド
は、ベースアドレスを指定するためのアドレッシングモ
ードを指定し、Rbフィールドは、ベースアドレスポイン
タとなるレジスタを指定する。また、dispフィールド
は、Modeフィールドの値によって、可変長のフィールド
であり、ベースアドレスの指定時に加算されるべきディ
スプレイスメントの値を指定する。 このベースアドレス指定フィールドは、インデックス
モードに対するアドレス修飾拡張を行うフィールドであ
る。 例えば、Modeフィールドの値が、16進数の6の場合に
は、第391図の(b)の形式のようになり、これは、レ
ジスタ間接インデックスモードを表わし、ベースアドレ
スは、Rbフィールドで指定されたレジスタの内容とな
る。 また、16進数のAの場合には、第391図の(c)の形
式のようになり、バイト偏位インデックスモードを表
す。ベースアドレスは、Rbフィールドで指定されたアド
レスの内容にdispフィールドのディスプレイスメント値
を加えた値となる。 さらに、16進数のBの場合には、第391図の(d)の
形式のようになり、バイト偏位間接インデックスモード
を表す。この場合のベースアドレスは、Rbフィールドで
指定されたレジスタの内容にdispフィールドのディスプ
レイスメント値を加えた結果をアドレスとするメモリの
内容である。 このような命令の形式は、形式的には任意の段数のア
ドレス修飾拡張が可能である。例えば、第391図の
(e)のような形式により2段のインデックスモードが
表現できる。この場合、最初のインデックス指定フィー
ルドに対応するベースアドレス指定フィールドは、図中
のベースアドレス指定フィールド1で示され、そのベー
スアドレスは、2番目のインデックス指定フィールドに
よるインデックスモードにより指定される。 しかしながら、この命令形式では、任意段数のアドレ
ス修飾を効率よく行なうことができない。例えば、同図
の(e)の形式において、最終的なオペランドの実効ア
ドレスを計算する際には、先頭から最初のインデックス
指定フィールド、2番目のインデックス指定フィール
ド、の順にオペランドを調べ、次にベースアドレス指定
フィールド2を調べた後にはじめて、ベースアドレス指
定フィールド1がバイト偏位間接インデックスモードで
あることが認識でき、このアドレッシングモードでベー
スアドレス指定フィールド1に対応するベースアドレス
が計算される。そして、このベースアドレス及び最初の
インデックス指定フィールドにより、最終的なオペラン
ドの実効アドレスが得られる。 このように、従来のような命令形式は、アドレス修飾
拡張をインデックスモードに対するベースアドレスを拡
張形式で表現するというものであったため、アドレス計
算をオペランドの後ろから行なわなければならず、オペ
ランドをすべて調べるまでは、アドレス計算が行なえな
い。したがって、アドレス修飾拡張を多段に行なうとオ
ペランドの実効アドレス計算の効率が悪くなり、段数を
増すことができないという問題点があった。 本発明は斯かる問題点を解決するためになされたもの
であり、その目的とするところはプログラム制御方式の
システムにおけるプログラムの実行速度を向上させ得る
ような命令オペランドのアドレッシング・モードの形式
を提供することにある。 本発明の他の目的は、高級言語のデータ構造に対して
用いられる複雑なアドレス指定を可能にすることによ
り、コンパイラの構成を容易にする命令オペランドのア
ドレッシング・モードの形式を提供することにある。 [問題点を解決するための手段] 命令のオペランドに対するアドレッシングは、複雑な
アドレッシングであっても、基本的には加算と間接参照
の組合せに分解できる。本発明はこれを利用したもので
あり、加算と間接参照の操作をアドレッシングのプリミ
ティブとして与えておき、それを任意に組み合わせるこ
ととして、如何なる複雑なアドレッシング・モードをも
実現することができるようにしたものであり、本発明に
係る、新しい命令のフォーマットは、このような考え方
にたったアドレッシング・モードを表現するものであ
る。 本発明に係るデータ処理装置は、オペレーションの種
類を指定するオペレーションコード指定部分、少なくと
も1つのオペランドの実効アドレス及びアドレッシング
モードを示す実効アドレス指定フィールド、並びに該実
効アドレス指定フィールド又は先行するものの中で示さ
れる少なくとも1つのアドレッシングモードに対してア
ドレッシングの拡張修飾を行う複数の付加モード指定フ
ィールドを備え、各付加モード指定フィールド内に、後
行の付加モード指定フィールドの有無を示す情報を含む
命令を記憶する手段と、この命令をデコードする手段
と、デコードした命令を実行する手段とを備えることを
特徴とする。 本発明においては付加モード指定フィールドに次々と
付加モード指定フィールドを付加していくことができ、
その数に制限がない。またこのように付加モード指定フ
ィールドの追加数を特に監視する必要がなく、例えばカ
ウンタ等を必要としない。 また付加モード指定フィールドごとにアドレッシング
モードを変更することができ、複雑なアドレッシングモ
ードを随意に実現できる。 [実施例] 以下本発明をその更施例を示す図面に基いて詳述す
る。 第392図が、本発明により提案された新しい命令のフ
ォーマットの形式の一例を示す図である。同図に示され
るように、オペレーションコード指定フィールドOPに続
いて、オペランドの実効アドレスを示す実効アドレス指
定フィールドEaが設けられている。このEaフィールドに
続いてアドレス修飾を行なうための拡張フィールド1が
設けられている。拡張フィールドには、継続/終了ビッ
トが設けられており、その値が0の時はさらに後ろに拡
張フィールドがあることを意味し、1のときには拡張フ
ィールドが終わりであることを示す。 拡張フィールド1の継続/終了ビットは0であるとき
は図示のように拡張フィールド1の後に別の拡張フィー
ルド2が続く。同様にして、拡張フィールド2の後ろに
はいくつかの拡張フィールドが続き、最後に拡張フィー
ルドにおいては接続/終了ビットが1であるので、拡張
フィールドの列が終了する。 このフォーマットにおいて、実際のオペランドのアド
レス計算は、次のようにして行なう。 (1)まず、Eaフィールドにより指定される実効アドレ
スをアドレス計算の中間値とする。 (2)次の拡張フィールドを調べ、拡張フィールドに指
定されているアドレス修飾を中間値に対して行ない、結
果を新しい中間値とする。 (3)拡張フィールドの継続/終了ビットを調べ、値が
0である場合は、(2)に戻る。 値が1である場合は、中間値を最終的なオペランドの
アドレスとする。 このようなメカニズムを説明する図を第393図に示
す。 第394図は、本発明の拡張フィールドの実施例の基本
フォーマットを示す。 図に示されるように、拡張フィールドには、 ・拡張フィールドが継続するか、終了であるかを指定す
るEビット ・間接参照をするかしないかを指定するIビット ・インデックスの方法を指定するMビット ・Mビットとともにインデックスレジスタ等を指定する
Rxフィールド ・インデックスのスケールを指定するXXフィールド ・インデックスレジスタのサイズを指定するSビット ・ディスプレイスメントの指定方式を指定するDビット ・Dビットの値が0のときデイスプレイスメントの値を
指定し、1のとき、ディスプレイスメントのサイズを指
定するd4フィールド ・Dビットの値が1のときのみ存在し、ディスプレイス
メントの値を指定し、d4フィールドで指定されるフィー
ルド長を持つdispxフィールド ・メモリ参照において独立に何らかの動作を指定するP
ビット が設けられる。 以下本発明のデータ処理装置の全貌を詳細に説明する
が、上記フォーマットの詳細は第7章16節に記してあ
る。 なお、以下の説明は長大であるので目次を付すと共
に、詳細な記述を必要とする事項等については、付録の
形をとった部分に記述した。 目次 1.本発明装置の特徴 1−1.基本設計思想 1−2.OS向きアーキテクチャ 1−3.チューニングされた命令セット 1−4.コンパイラ向きの命令セット 2.本発明装置32と本発明装置64 3.本発明装置仕様のクラス分け 4.レジスタセット 5.データタイプ 5−1.ビット 5−2.ビットフィールド 5−3.整数 5−4.浮動小数 5−5.10進数 5−6.ストリング 5−7.キュー 6.命令フォーマット 6−1.2オペランド短縮形 6−1−1.レジスタ−メモリ間 (S−format,L−format) 6−1−2.レジスタ−レジスタ間 (R−format) 6−1−3.リテラル−メモリ間(Q−format) 6−1−4.イミディエート−メモリ間 (I−format) 6−2.1オペランド一般形(Gl−format) 6−3.2オペランド一般形 6−3−1.第一オペランドはメモリ読みだし(G−form
at) 6−3−2.第一オペランドは8ビットイミディエート
(E−format) 6−3−3.第一オペランドはアドレス計算 (GA−format) 6−3−4.その他の2オペランド命令 6−4.ショートブランチ 6−5.その他 7.アドレッシングモード 7−1.Pビット 7−2.フォーマット中で使われる記号 7−3.レジスタ直接 7−4.レジスタ間接 7−5.レジスタ相対間接 7−6.イミディエート 7−7.アブソリュート 7−8.PC相対間接 7−9.スタックポップ 7−10.スタックプッシュ 7−11.レジスタ相対付加モード 7−12.PC相対付加モード 7−13.絶対付加モード 7−14.FP相対間接 7−15.SP相対間接 7−16.付加モードのフォーマット 7−17.付加モード仕様のレベル 8.インプリメント関連事項 8−1.仮想記憶のサポート 8−2.プログラムによる命令の書き換え 9.EIT処理 10.PSWの構成 10−1.PSSの構成 10−2.PSHの構成 10−3.フラグの変化 11.命令セットの記述について 11−1.記述形式の概要 11−2.命令ビットパターンとアセンブラ表記 11−3.フィールド名 11−4.オペランドフィールド名 11−5.アドレッシングモードに関する制限 11−6.解説に関する注意 12.本発明装置の命令セット 12−1.データ転送命令 12−2.比較、テスト命令 12−3.算術演算命令 12−4.論理演算命令 12−5.シフト命令 12−6.ビット操作命令 12−7.固定長ビットフィールド操作命令 12−8.任意長ビットフィールド操作命令 12−9.10進演算命令 12−10.ストリング命令 12−11.キュー命令 12−12.ジャンプ命令 12−13.マルチプロセッサ用の命令 12−14.制御空間、物理空間操作命令 12−15.OS関連命令 12−16.MMU関連命令 付録1.本発明装置命令セットレファレンス 付録2.本発明装置のアセンブラ表記について 付録3.本発明装置メモリ管理方式概要 付録4.本発明装置のフラグ変化 付録5.異種サイズ間の演算について 付録6.高級言語向きサブルーチンコール 付録7.制御レジスタと制御空間 付録8.本発明装置のCTXB 付録9.本発明装置のEIT処理 付録10.本発明装置の命令セットパターン 付録11.高機能命令の詳細仕様と終了時のレジスタ値 付録12.オペランドが干渉した場合の動作 付録13.キャッシュやTLBの整合性確保について 1.本発明装置の特徴 1−1.基本設計思想 ・本発明装置はRISCではない。基本命令の高速実行を第
一目標とし、さらに高機能命令を追加した。 ・32ビット版の本発明装置32と64ビット版の本発明装置
64を同時に設計し、32ビット版と64ビット版のチップを
シリーズ化した。したがって、64ビットデータ、64ビッ
トアドレッシングへの拡張が始めから考慮されている。 ・OSと込みで開発し、リアルタイムOSであるITRON(Ind
ustorial−TRON)とワークステーション用のOSであるBT
RON(Business−TRON)を高速で実行することを目指し
た。本発明装置はTRON〈〈LlR〉〉仕様を満たし、特に
実記憶環境での高速処理に重点を置く。 ・将来のASIC LSIの核となるマイクロプロセッサとす
る。 1−2.OS向きアーキテクチャ ・ビットマップ操作サポート命令 BTRONで必要となるビットマップの移動、演算を行なう
命令 ・コンテキストスイッチ命令 ITRONにおいて高速のタスク切り替えを行なうための命
令 ・キュー操作命令 ITRONのレディキュー、ウエイトキューの操作を行なう
命令 ・2レベルのリング保護によるメモリ管理 (将来の拡張用にさらに2レベルのリングを用意してい
る。) 1−3.チューニングされた命令セット ・頻度の高い命令、アドレッシングモードが短い命令と
なるようにチューニング レジスタ間演算、リテラル演算の命令長を短縮 1−4.コンパイラ向きの命令セット ・直交化された命令セット ・データの保持、アドレスの保持、インデクス値の保持
といった各種の目的に使用できる16本の汎用レジスタ ・強力なアドレッシングモード 付加モードにより、任意段数のインデクス加算と間接参
照が可能。 ・異なるデータサイズ間での演算が可能 ソースオペランドとデスティネーションオペランドのサ
イズを別々に指定可能。 ・高級言語向きの高機能ジャンプ命令 2.本発明装置32と本発明装置64 本発明装置では、32ビット版の本発明装置32と64ビッ
ト版の本発明装置64をシリーズ化して扱っており、64ビ
ット版への拡張が始めから考慮されているのが大きな特
徴である。本発明装置64では、64ビットのリニアアドレ
スの空間が提供される。また、本発明装置64では、本発
明装置32で扱うデータタイプに加えて、64ビット整数を
扱うことができる。 本発明装置64での32ビット/64ビット切り替え方法は次
のようになっている。 ・オペランドのデータサイズについて 各命令、各オペランド毎に存在するサイズ指定ビット
により、命令単位、オペランド単位で32ビット/64ビッ
トを選択する。データサイズの場合は、32ビット、64ビ
ットのほかに8ビット、16ビットも利用できるので、4
つのサイズの選択を2ビットのフィールドで指定する。 本発明装置32では、64ビットデータを扱わず、64ビット
のデータサイズを指定した命令はエラーとする。 ・ポインタのサイズについて 通常は本発明装置32で32ビットポインタ、本発明装置
64で64ビットポインタを使用するが、本発明装置64で本
発明装置32用のオブジェクトコードを実行するため、本
発明装置64にはポインタサイズを32ビットにするモード
を設ける。このモードはPSW中で指定されるので、コン
テキスト(プロセスやタスク)単位で32ビット用のプロ
グラムと64ビット用のプログラムを混在させることは可
能である。 このほか、64ビットアドレッシングを行なうための拡
張用ビットとして、メモリアクセスを伴なうオペランド
毎に「Pビット」と呼ばれる予約ビットが設けられてい
る。 ポインタサイズの32ビット/64ビット切り替えを命令
単位とせず、モードにしたのは、次のような理由によ
る。 ポインタの場合、異種のサイズのものを混在させるこ
とは本質的に無理がある。というのは、ポインタという
のは場所を区別するものであるため、一つでも64ビット
のものがあれば、全体を64ビットのポインタにしないと
区別できないからである。したがって、32ビットポイン
タと64ビットポインタを命令毎に切り替え、混在できる
ようにしたとしても、大部分はコンテキスト単位で同じ
指定を繰り返すだけになり、ビット割り当てとしては効
率の悪いものになる。そのような状況では、モードの方
が適当である。 モードを使って32/64を切り替える場合、モードをい
つ設定するか、本発明装置32と本発明装置64の互換性が
大丈夫かといった疑問が生ずるかもしれない。しかし、
デフォルトが32ビットポインタとなるようにしておき、
64ビットアドレスを使用する時にモード変更するという
形態にすれば、本発明装置64でも本発明装置32用のプロ
グラムをそのまま走らせることができる。また、32ビッ
トポインタと64ビットポインタの切り替えをモードでは
なく命令単位にしたとしても、OSがスタックをどこの設
定するか、システムコールのパラメータが32ビット/64
ビットのどちらか、といったことを判断するために、OS
は各コンテキストが32ビットか64ビットかということを
認識しておく必要がある。その場合には、(スタックに
退避された)PSW中のモードを見て32ビット/64ビットを
判断できる方が便利なことがある。 3.本発明装置仕様のクラス分け 本発明装置では、64ビット版への拡張、シリーズ化、
多様な用途への適応、などといった要求に対応するた
め、インプリメントするかどうかオプションとなってい
る機能がある。このような「オプション機能」の位置付
けを明確にするため、本発明装置の仕様を次のようにク
ラス分けする。 〈〈L0〉〉仕様(Level 0) 本発明装置として必ず満たさなければならない仕様で
ある。 〈〈L0〉〉仕様の例は、ユーザプログラムから見たプロ
グラミングモデル(ISPの大部分、汎用レジスタ、PS
H)、機械語のビットパターンなどである。 仕様書中では、特に何も書いてない部分が〈〈L0〉〉
仕様となる。 〈〈L1〉〉仕様(Level 1) インプリメントしておくのが原則であるが、特に用途
の限定された軽い仕様のプロセッサを作りたい場合に
は、必ずしもインプリメントしなくてもよい仕様であ
る。 〈〈L1〉〉仕様になるのは、ストリング命令、付加モ
ード、キュー操作命令、ビットマップ命令といった高機
能命令などであるが具体的にどの命令を〈〈L1〉〉仕様
とするかは別に定める。 〈〈L1R〉〉仕様(Level 1 Real) 〈〈L1〉〉仕様から命令再実行関係の機能とMMU関係
の機能を削除した仕様であり、ITRONとμBTRONなどを実
記憶ベースで効率よく動かすための仕様である。 〈〈L1R〉〉の命令セットは〈〈L1〉〉とほぼ同じで
あり、コンパイラやユーザプログラムは共通に使用でき
るようにする。ただし、MMU関係(MOVPAなど)、OS関係
(JRNGなど)の一部の命令については、サポートしない
ものがある。 〈〈L2〉〉仕様(Level 2) 将来のハードウエア量の増加にしたがって導入される
予定の仕様である。 命令の対称性を高めるための仕様と、演算の高速化に
対応して新たに追加する命令の仕様とがある。 前者の例としてはBVSCH命令の‘/B'オプション、スト
リング命令での複雑な終了条件、無限段数の付加モード
などがあり、後者の例としてはINDEX命令などがある。 仕様書中では、〈〈L2〉〉仕様の部分を〈〈L2〉〉で
示す。 〈〈LX〉〉仕様(eXtension) 本発明装置64への拡張にしたがって導入される予定の
仕様である。L2仕様と同様の意味を持つが、本発明装置
64への対応ということで別のクラスとして扱う。 〈〈LX〉〉仕様の例は、64ビット演算命令などであ
る。 仕様書中では、〈〈LX〉〉仕様の部分を〈〈LX〉〉で
示す。 〈〈LU〉〉仕様(Undefined) 将来の拡張によって導入される予定の仕様であるが、
現段階ではまだ具体的な仕様まで提示されていないもの
である。 〈〈LV〉〉仕様(Variable) 各メーカーが全く自由に仕様を決めてよい部分であ
る。 チップのピン配置、パイプラインの段階や性能に関す
る仕様、各メーカーに割り当てられた命令のビットパタ
ーン、制御レジスタの使い方などが〈〈LV〉〉仕様の例
である。このうち、各メーカーに割り当てられた命令ビ
ットパターンについては、ビットパターンのレファレン
ス中でLVreservedにより示されている。 〈〈LA〉〉仕様(Alternative) 本発明装置としての標準仕様が提示されている(ある
いは、提示される予定がある)が、他にやむを得ない理
由があれば変更してもよいという仕様である。もちろ
ん、仕様を変更した部分に関しては互換性の失われる場
合がある。〈〈LA〉〉仕様は、TRONとしての互換性を保
証しない仕様である。 〈〈LA〉〉仕様の例は、メモリ管理方式、制御レジス
タと特権命令の一部などであり、主にOSの関係する部分
である。 本発明装置はMMUを内蔵せず、特に実記憶環境での高
速処理を目指す。従ってメモリ管理に関する〈〈LA〉〉
仕様の大部分は本発明装置でサポートされない。 4.レジスタセット ・本発明装置32では32ビット長の汎用レジスタが16本、
本発明装置64では64ビット長の汎用レジスタが16本存在
する。 ・スタックポインタ(Stack Pointer−SP)、フレーム
ポインタ(Frame Point er−FP)は汎用レジスタに含ま
れる。SPはR15、FPはR14となる。 ・プログラムカウンタ(Program Counter−PC)は汎用
レジスタに含まれない。 ・汎用レジスタは、データ保持、ベースアドレス保持、
あるいはインデクスレジスタとして、各種の目的に使用
できる。 ・プロセッサの状態を保持するレジスタ(Processor St
atus Word−PSW)を持つ。第1図は、本発明装置64の場
合〈〈LX〉〉のレジスタセットを示す。 ・SPはコンテキスト(リング番号、割り込み処理中)に
応じて切り替わる。 ・PSWは4バイトからなる。下位第一バイトがステータ
スの表示(Processor Status Byte−PSB)、下位第二バ
イトがユーザのモード設定(PSBと合わせてProcessor S
tatus Halfword−PSH)、上位の2バイトがシステムの
状態表示用、となる。 ・本発明装置はいわゆるbig−endianのチップであり、
レジスタ上のデータについては、8ビット、16ビットの
データをLSB側に詰めて配置する。したがって、データ
サイズとは無関係な絶対的なビット番号を定義すること
ができない。ビット番号を議論する場合には、必ずデー
タサイズと組にして扱う必要がある。これを「ビット位
置」と呼ぶ。 ・レジスタ上の8ビットデータに対しては、ビット位置
はMSB側から0,1,…7と付けられる。また、レジスタ上
の16ビットデータに対しては、ビット位置はMSB側から
0,1,…15と付けられ、レジスタ上の32ビットデータに対
しては、ビット位置はMSB側から0,1,…31と付けられ
る。したがって、8ビットデータのビット位置7のビッ
ト、16ビットデータのビット位置15のビット、32ビット
データのビット位置31のビットが物理的には同一のビッ
トとなる。 ・レジスタをデスティネーションオペランドとする命令
において、レジスタ側のデータサイズが8ビット、16ビ
ットであった場合には、上位バイトは影響を受けず、無
変化となる。これは、メモリ上で演算を行なった場合の
仕様と合わせたものである。上位ビットにまで影響を与
えたい場合は、異種サイズ間の演算を利用する。 [例] MOV #H′12345678,R0.W MOV #H′aa,R0.B R0=H′123456aaとなる。 ・レジスタ上に8ビット、16ビットのデータを置く場合
には、LSB側に詰められるので、例えば、 MOV.W #H′12345678,R0 MOV.B #H′aa,R0 MOV.W R0,R1 の結果はR1=H′123456aaとなる。一方、メモリに対し
て同じことを行なった場合 MOV.W #H′12345678,@R0 MOV.B #H′aa,@R0 MOV.W @R0,R1 には、8ビット、16ビットのデータのMSB側が揃うこと
になるので、R1=H′aa345678となる。レジスタ上とメ
モリ上で結果が異なるので、注意が必要である。 5.データタイプ 本発明装置では、いわゆるbig−endianを採用してい
る。すなわち、バイトアドレスの指定、ビット番号の指
定とも、小さい番号(アドレス)の方がMSB(Most Sign
ificant Bit/Byte)となっている。 big−endianでは、メモリ上のあるデータについて、
それを8ビットデータとして見る時と16(32)ビットデ
ータとして見る時のアドレスが異なってくるため、注意
が必要である。例えば、 address:N N+1 N+2 N+3 data: 0 0 0 H′12 といった場合に、32ビットデータとしてのアドレスNの
内容はH′00000012であるが、(H′は16進を表わ
す)、同じ内容のデータを8ビットデータとして扱うと
きは、アドレスN+3を参照しなければならない。 ただし、レジスタ上のデータに関しては、8ビットデ
ータ、16ビットデータがLSB側に詰めて配置されるた
め、レジスタ上に置かれたデータを、そのまま別のサイ
ズのデータとして扱うことができる。例えば、 MOV #0,R0.W MOV #H′12,R0.B MOV R0.W,R1.W の結果はR1=H′00000012となる。(命令の意味につい
ては本文参照) 一方、メモリに対して同じことを行なった場合 MOV #0,@R0.W MOV #H′12,@R0.B MOV @R0.W,R1.W には、8ビットデータH′12と32ビットデータのMSB側
が揃うことになるので、R1=H′12000000となる。 本発明装置でサポートしているデータタイプを以下に
説明する。 5−1.ビット 第2図のように太線内が対象ビットである。メモリ上
のビット操作の場合、offsetは任意レジスタ上のビット
操作の場合、offsetは一つのレジスタ内に限定 (offsetの上位ビットを無視する) ビットの指定は、base_addressの指定、base_addressの
サイズの指定、offsetの指定の組によって行なわれる。 メモリ上のビットを対象とした場合には、base_addre
ssで示されるメモリアドレスのMSBがoffset=0のビッ
トとなる。この時、base_addressのサイズの指定は、実
際に操作されるビットには影響しない。ビット操作命令
では、メモリに対してread−modify−writeを行なうア
クセスサイズを指定するためにbase_addressのサイズの
指定が利用されるが、アクセスサイズが異なっても実際
に操作されるビットは同じである。 一方、レジスタ上のビットを対象とした場合には、ba
se_addressのサイズとして指定したデータサイズでのMS
Bがoffset=0のビットとなる。base addressのサイズ
が異なれば、実際に操作されるビットも異なったものに
なるので、注意が必要である。 5−2.ビットフィールド ・符号付きビットフィールド 第3図に示すように太線内が対象ビットフィールドで
ある。 0<width≦32(〈〈LX〉〉0<width≦64) S:符号ビット base_addressのMSBから、対象ビットフィールドのMSB
(符号ビット)までのビットの隔たりがoffsetとなる。 BF:G命令によるメモリ上のビットフィールド操作の場
合、offsetは任意。 BF:E命令によるメモリ上のビットフィールド操作、およ
びレジスタ上のビットフィールド操作の場合、base_add
ressの1ワード(1ロングワード)をはみ出した部分の
ビットフィールドについて、動作を保証しない。 ・符号なしビットフィールド 第4図に示すように太線内が対象ビットフィールドで
ある。 0<width≦32(〈〈LX〉〉0<width≦64) base_addressのMSBから、対象ビットフィールドのMSB
までのビットの隔たりがoffsetとなる。 BF:G命令によるメモリ上のビットフィールド操作の場
合、offsetは任意。 BF:E命令によるメモリ上のビットフィールド操作、およ
びレジスタ上のビットフィールド操作の場合、base_add
ressの1ワード(1ロングワード)をはみ出した部分の
ビットフィールドについて、動作を保証しない。 ・任意長ビットフィールド offset、widthとも任意。ただしwidth>0。 5−3.整数 第5図に整数のデータタイプを示す。 5−4.浮動小数 浮動小数点の演算は、コプロセッサで扱う。 浮動小数点の形式はIEEE規格である。詳細は別に定め
る。 ・単精度32ビット浮動小数 〈〈コプロセッサ〉〉 ・倍精度64ビット浮動小数 〈〈コプロセッサ〉〉 ・80ビット浮動小数 〈〈コプロセッサ〉〉 5−5.10進数 多倍長の10進数の四則演算は、コプロセッサで扱う。
本発明装置のメインプロセッサでは、以下に示すような
固定長の符号なしPACKED形式10進数、および符号付きPA
CKED形式10進数を扱う。ただし、符号付きPACKED形式10
進数を扱う命令は、すべて〈〈L2〉〉である。第6図に
データタイプをしめす。 5−6.ストリング 第7図にストリングの場合のデータタイプを示す。 5−7.キュー 第8図にダブルリンクでつながれた線形リストのデー
タタイプを示す。 6.命令フォーマット 命令は16ビット単位で可変長となっており、奇数バイ
ト長の命令はない。 2オペランド命令には、大きくわけて、4バイト+拡
張部の構成をもち、すべてのアドレッシングモード(E
a)が利用できる一般形、および頻度の高い命令とアド
レッシングモード(Sh)のみを使用できる短縮形、の2
つのフォーマットがある。必要となる命令機能とコード
サイズに合わせて、より適した方を選択することができ
る。 本発明装置の命令フォーマットは、細かい点まで気を
つければかなり多くの種類に分かれる。しかし、理解を
容易にするため、ここでは本発明装置の命令フォーマッ
トを大まかに分類して説明を行なう。命令フォーマット
の詳細については、付録10を参照のこと。 フォーマット中に現われる記号の意味は次の通りであ
る。 − オペコードの入る部分 # リテラル、またはイミディエート値の入る部分 Ea 8ビットで指定する一般形のアドレッシングモード Sh 6ビットで指定する短縮形のアドレッシングモード Rn レジスタの指定を行なう部分 フォーマットの記述は、右側がLSB側で、かつ高いアド
レスになっている。(big−endian) フォーマットの記述例を第9図に示す。 アドレスNとアドレスN+1の2バイトを見ないと命
令フォーマットが判別できないようになっているが、こ
れは、命令が必ず16ビット(2バイト)単位でフェッ
チ、デコードされることを前提としたためである。 いずれのフォーマットの場合も、各オペランドのEaま
たはShの拡張部は、必ずそのEaまたはShの基本部を含む
ハーフワードの直後に置かれる。これは、命令により暗
黙に指定されるイミディエートデータや、命令の拡張部
に優先する。したがって、4バイト以上の命令では、Ea
の拡張部によって命令にオペコードが分断される場合が
ある。 また、付加モードによって、Eaの拡張部にさらに拡張
部が付く場合にも、次の命令オペコードよりもそちらの
方が優先される。 例えば、第一ハーフワードにEa1を含み、第二ハーフ
ワードにEa2を含み、第三ハーフワードまである6バイ
ト命令の場合を考える。Ea1に付加モードを使用したた
め、普通の拡張部のほかに付加モード拡張部もつくもの
とする。この時、実際の命令ビットパターンは 命令の第一ハーフワード (Ea1の基本部を含む) Ea1の拡張部 Ea1の付加モード拡張部 命令の第二ハーフワード (Ea2の基本部を含む) Ea1の拡張部 命令の第三ハーフワード の順となる。 なお、アライメントの関係で16ビットのフィールドの
うちの8ビットのみを使用するケースでは、使用する8
ビットは下位順(アドレスの大きい方)に詰めて置かれ
るものとする。これに該当するのは、オペランドサイズ
が8ビットで、EaR,ShRに#imm_dataのモードを指定し
た場合、I−formatでオペランドサイズが8ビットの場
合、BRA:G,Bcc:G,BSR:GでSS=00の場合、などである。 例えば、 MOV:I.B #H′12,@R0 の場合、第一バイトがMOV:I.Bのオペコード、第二バイ
トがオペコードの一部とShW(@R0)の指定、第三バイ
トは0、第四バイトがH′12となり、ビットパターンは
第10図のようになる。 この場合、16ビットのフィールドの上位側(アドレス
の小さい方)の8ビットには必ず0を入れておかなけれ
ばならない。上位8ビットが0でない場合は、これによ
って表現されるデータがインプリメント依存の不定値に
なるものとする。つまり、I−format,#imm_dataモー
ドの場合はそのオペランドがインプリメント依存の値に
あり、BRA:G.Bcc:G,BSR:G命令の場合は、ジャンプ先が
不定となる。いずれの場合もEIT(例外)とはしない。 6−1.2オペランド短縮形 6−1−1.レジスタ−メモリ間 (S−format,L−format) 第11図にその例を示す。 L−format,S−formatの命令には、サイズ指定のでき
るもの(MOV:L,MOV:S,CMP:L)とサイズ指定のできない
もの(ADD:L,SUB:L)がある。 サイズ指定のできる命令では、RR等によるサイズ指定
はメモリ側のみに適用され、レジスタ側のサイズは32ビ
ット固定となっている。レジスタ側とメモリ側のサイズ
が異なる場合には、ソース側のサイズが小さい場合に符
号拡張が、デスティネーション側のサイズが小さい場合
に上位バイトのカットとオーバーフローのチェックが行
なわれる。 一方、サイズ指定のできないADD:L,SUB:L命令では、
レジスタ側、メモリ側のオペランドサイズとも32ビット
固定である。 レジスタ側のサイズを32ビット固定としたのは、本発
明装置において、「レジスタ上のデータは、できる限り
32ビット符号付き整数として扱う」という原則を設けて
いるためである。この原則は、L−format,S−format命
令のほか、ビットフィールド命令や高機能命令でレジス
タ上にオペランドを置く場合にも適用される。 6−1−2.レジスタ−レジスタ間(R−format) 第12図にその例を示す。 6−1−3.リテラル−メモリ間(Q−format) 第13図にその例を示す。 6−1−4.イミディエート−メモリ間(I−format) 第14図にその例を示す。 I−formatのイミディエート値のサイズは、デスティ
ネーション側のオペランドのサイズと共通に8,16,32,64
ビットとなり、ゼロ拡張、符号拡張は行なわれない。 6−2.1オペランド一般形(Gl−format) 第15図にその例を示す。 6−3.2オペランド一般形 ここに含まれるのは、8ビットで指定する一般形アド
レッシングモードのオペランドが2つ存在する命令であ
る。オペランドの総数は3つ以上になる場合がある。 6−3−1.第一オペランドはメモリ読みだし(G−form
at) 第16図にその例を示す。 6−3−2.第一オペランドは8ビットイミディエート
(E−format) 第17図にその例を示す。 このフォーマットとイミディエート−メモリ間のフォ
ーマット(I−format)とは機能的には似たものである
が、考え方の点では大きく違っている。E−formatはあ
くまでも2オペランド一般形(G−format)の派生形で
あり、ソースオペランドのサイズが8ビット固定、ディ
スティネーションオペランドのサイズが8/16/32/64ビッ
トから選択となっている。つまり異種サイズ間の演算を
前提とし、destのサイズに合わせて8ビットのsrcがゼ
ロ拡張または符号拡張される。 一方、I−formatは、特にMOV,CMPで頻度の多いイミデ
ィエートのパターンを短縮形にしたものであり、ソース
とディスティネーションのサイズは等しい。 6−3−3.第一オペランドはアドレス計算(GA−forma
t) 第18図にその例を示す。 6−3−4.その他の2オペランド命令 第19図にその例を示す。 6−4.ショートブランチ 第20図にその例を示す。 6−5.その他 以上の外に第21図に示すようなものがある。 7.アドレッシングモード 本発明装置のアドレッシングモードには、レジスタを
含めて6ビットで指定する短縮形(Sh)と、8ビットで
指定する一般形(Ea)がある。 未定義のアドレッシングモードを指定した場合や、意
味的に考えて明らかにおかしなアドレッシングモードの
組み合わせを指定した場合には、未定義命令を実行した
場合と同じく予約命令例外(RIE)を発生し、例外処理
を起動する。 これに該当するのは、destinationがイミディエート
モードの場合、アドレス計算の命令でイミディエートモ
ードを使用した場合などである。 7−1.Pビット 本発明装置では、毎回のメモリアクセスに対応して1
ビットのオプション機能指定ビットを割り当てることが
できるようになっており、このビットをPビットと呼
ぶ。Pビットは、メモリアクセスに伴って何らかの別の
意味を加えたい場合に使用するビットである。 Pビットは、毎回のメモリアクセス毎に独立に指定す
る。したがって、レジスタ間接アドレッシング、アブソ
リュートアドレッシングなどの場合はオペランドに対応
して一つのPビットを指定するが、付加モードを使用し
た多段間接のアドレッシングモードでは、その段数分だ
けのPビットを指定することになる。 Pビットの用途としては、タグのチェック、論理空間
の切り替え、32ビットアドレッシングと64ビットアドレ
ッシングの切り替えなどがあるが、これらはすべて将来
の拡張用であり、現在の仕様ではPビットはreservedと
なっている。 命令フォーマットの説明では、Pビットの部分を‘P'
で表示してあるが、ここは必ず0にしておかなければな
らない。Pビットが0になっていなかった場合には、予
約命令例外(RIE)、が発生する。 Pビットに関する機能は〈〈LU〉〉仕様である。 7−2.フォーマット中で使われる記号 Rn レジスタ指定 P Pビット(0でなければならない) mem[EA]EAで示されるアドレスのメモリ内容 以下点線で囲まれた部分は、拡張部を示す。 7−3.レジスタ直接 アセンブラ表記: Rn オペランド: Rn フォーマット: 第22図に示す。 7−4.レジスタ間接 アセンブラ表記: @Rn オペランド: mem[Rn] フォーマット: 第23図に示す。 7−5.レジスタ相対間接 アセンブラ表記: @(disp,Rn) @(disp:16,Rn) @(disp:32,Rn) オペランド: mem[disp+Rn] フォーマット: 第24図に示す。 なおdispは符号付きとして扱う。 7−6.イミディエート アセンブラ表記: #imm_data オペランド: imm_data フォーマット: 第25図に示す。 なおimm_dataのサイズは、オペランドサイズとして命
令中で指定される。 7−7.アブソリュート アセンブラ表記: @abs @abs:16 @abs:32 @abs:64〈〈LX〉〉 オペランド: mem[abs] フォーマット: 第26図に示す。 なお32ビットアドレッシングの時は、abs:16で指定し
たアドレスは32ビットに符号拡張される。また、64ビッ
トアドレッシングの時は、abs:16,abs:32で指定したア
ドレスは64ビットに符号拡張される。 7−8.PC相対間接 アセンブラ表記: @(disp,PC) @(disp:16,PC) @(disp:32,PC) オペランド: mem[disp+PC] フォーマット: 第27図に示す。 PC相対間接モードにおいて参照されるPCの値は、その
オペランドを含む命令の先頭アドレスである。したがっ
て、例えば無限ループは JMP @(0,PC) という命令によって実現される。 付加モードにおいてPCの値が参照される場合にも、同
じように命令先頭のアドレスをPC相対の基準値として使
用する。 7−9.スタックポップ アセンブラ表記: @SP+ オペランド: mem[SP] SPをインクリメント フォーマット: 第28図に示す。 @SP+のモードでは、オペランドサイズだけSPをイン
クリメントする。例えば、本発明装置64で64ビットデー
タを扱う時には、SPが+8だけ更新される。B,Hのサイ
ズのオペランドに対する@SP+の指定も可能であり、そ
れぞれSP+1,+2だけ更新される。ただし、スタックの
アラインメントがくずれて速度低下の原因にになるた
め、使用上は注意した方がよい。 オペランドに対して@SP+のモードが意味を持たない
ものに対しては、予約命令例外(RIE)を発生する。具
体的に予約命令例外(RIE)となるのは、writeオペラン
ド、read−modify−writeオペランドに対する@SP+で
ある。 7−10.スタックプッシュ アセンブラ表記: @−SP オペランド: SPをデクリメント mem[SP] フォーマット: 第29図に示す。 @−SPのモードでは、オペランドサイズだけSPをデク
リメントする。例えば、本発明装置64で64ビットデータ
を扱う時には、SPが+8だけ更新される。B,Hのサイズ
のオペランドに対する@−SPの指定も可能であり、それ
ぞれSPが−1,−2だけ更新される。ただし、スタックの
アライメントがくずれて速度低下の原因になるため、使
用上は注意した方がよい。オペランドに対して@−SPの
モードが意味を持たないものに対しては、予約命令例外
(RIE)を発生する。具体的に予約命令例外(RIE)とな
るのは、readオペランド、read−modify−writeオペラ
ンドに対する@−SPである。 7−11.レジスタ相対付加モード オペランド: フォーマット: 第30図に示す。 付加モードについては、後の章でまとめて説明する。 7−12.PC相対付加モード オペランド: フォーマット: 第31図に示す。 7−13.絶対付加モード オペランド: フォーマット: 第32図に示す。 7−14.FP相対間接 アセンブラ表記: @(disp,FP) @(disp:4,FP) オペランド: mem[d4 * 4+FP] (disp=d4 * 4) フォーマット: 第33図に示す。 d4は符号付きとして扱い、オペランドのサイズとは関
係なく必ずd4を4倍して使用する。したがって、このモ
ードにより(FP−8 * 4)から(FP+7 * 4)までの4
の倍数のメモリアドレスが参照可能である。アセンブラ
で記述する場合には、ディスプレイースメントとして4
倍した値の方を書く。 このアドレッシングモードは〈〈L2〉〉である。本発
明装置ではFP相対間接モードは実装しないので、このア
ドレッシングモードが指定された場合は、予約命令例外
(RIE)となる。 このアドレッシングモードは短縮形で利用できないの
で、例えば、 MOV @(disp,FP),R1 といった場合に、 MOV:G.W.@(disp:4,FP),R1 MOV:L.W.@(disp:16,FP),R1 がともに4バイトとなり、コードの選択に曖昧さが生じ
るという問題点がある。このモードが〈〈L2〉〉となっ
ているのは、このような理由による。このモードは、本
発明装置64になって短縮形の割合が減った時に、有効に
利用することを狙ったものである。 @(d4:4,FP)、@(d4:4,SP)のモードでは、オペラ
ンドサイズにかかわらずd4を4倍して使用するため、8
ビット、16ビット、32ビットのローカル変数をスタック
フレーム上に混在した場合に@(d4:4,FP)、@(d4:4,
SP)のモードを利用しようとすると、本発明装置がbig
−endianである関係上、各変数のMSB側をワード境界に
合わせて配置する必要がある。これによって特に問題が
起きるわけではないが、注意が必要である。 @(d4:4,FP),@(d4:4,SP)モードを利用するため
のローカル変数配置の例を第34図に示す。 7−15.SP相対間接 アセンブラ表記: @(disp,SP) @(disp:4,SP) オペランド: mem[d4 * 4+SP] (disp=d4 * 4) フォーマット: 第35図に示す。 d4は符号付きとして扱い、オペランドのサイズとは関
係なく必ずd4を4倍して使用する。ただし、d4が負の値
であった場合の動作は規定されていない。したがって、
このモードにより(SP)から(SP+7 * 4)までの4の
倍数のメモリアドレスが参照可能である。アセンブラで
記述する場合には、ディスプレースメントとして4倍し
た値の方を書く。 このアドレッシングモードは〈〈L2〉〉である。本発
明装置ではFP相対間接モードは実装しないので、このア
ドレッシングモードが指定された場合は、予約命令例外
(RIE)となる。 このモードも、@(disp:4,FP)と同様に、本発明装
置64になって短縮形の割合が減った時に、有効に利用す
ることを狙ったものである。 7−16.付加モードのフォーマット 複雑なアドレッシングも、基本的には加算と間接参照
の組み合わせに分解することができる。したがって、加
算と間接参照のオペレーションをアドレッシングのプリ
ミティブとして与えておき、それを任意に組み合わせる
ことができれば、どんな複雑なアドレッシングモードを
も実現することができる。 付加モードはこのような考え方にたったアドレッシン
グモードである。複雑なアドレッシングモードは、モジ
ュール間のデータ参照やAI言語の処理系に特に有用であ
る。 ただし、本発明装置ではメモリ間接アドレッシングモ
ードが多用された場合処理速度が低下する場合があるの
で、メモリ間接アドレッシングモードを使用に際しては
十分な注意が必要である。 付加モードの指定は、16ビットを単位としており、こ
れを任意回繰り返す。1段の付加モードにより、定数
(displacement)の加算インデクスレジスタのスケーリ
ングと加算 スケーリングは×1、×2、×4、×8 メモリの間接参照を行なう。N段の付加モードにより、
N+1段までの間接参照ができる。 基本的な付加モードの処理: 基本フォーマット: 第36図に示す。 EI=00 間接参照なし、付加モード継続 EI=01 間接参照あり、付加モード継続EI=10 間接参照なし、付加モード終了 EI=11 間接参照あり、付加モード終了 M=0 〈Rx〉をインデクスとして使用 M=1 特殊なインデクス 〈Rx〉=0 インデクスを加算しない(Rx=0) 〈Rx〉=1 PCをインデクスRxとして使用(Rx=PC) 〈Rx〉=2〜 reserved D=0 付加モード中の4ビットのd4を4倍してdispと
し、これを加算する。d4は符号付きとして扱い、オペラ
ンドのサイズとは関係なく必ずd4を4倍して使用する。 D=1 付加モードの拡張部で指定されたdispx(16/32
/64ビット)をdispとし、これを加算する。拡張部のサ
イズはd4フィールドで指定する。 d4=0001 disp xは16ビット d4=0010 disp xは32ビット d4=0011 disp xは64ビット 〈〈LX〉〉 XX インデクスのスケール(scale=1/2/4/8) S インデクスレジスタのサイズ S=0 〈Rx〉は32ビットを符号拡張 S=1 〈Rx〉は64ビット 〈〈LX〉〉 P Pビット〈〈LU〉〉 ・Pビットは付加モードの各段に入る。 Pビットは「すべてのメモリ参照で独立に指定できる
ビット」となっている。 ・間接参照をする場合としない場合を選択できる。 間接参照しない段は、多段のベースレジスタ、インデ
クスレジスタの加算に用いる。(mem[R1+R2+R3]な
ど)これは、ユーザレベルでrelocation base register
などを導入したい時に使用することがある。 ・インデクスレジスタのサイズ64ビットアドレス使用時
でも32ビットデータがかなりの頻度で出てくると予想さ
れるため、付加モードの各段で32/64のサイズ切り替え
ができるようになっている。 ・レジスタ相対間接の@(disp:64,Rn)やメモリ間接の
アドレッシングモードも付加モードを使用して実現す
る。 ・PCに対して×2、×4、×8のスケーリングを行なっ
た場合には、その段の処理終了後の中間値(tmp)とし
て、インプリメントに依存した不定値が入る。この付加
モードによって得られる実効アドレスは予測できない値
となるが、例外は発生しない。マニュアル等では、PCに
対する×2、×4、×8のスケーリングの指定は行なわ
ないように、注意しておく必要がある。 フォーマットのバリエーション: 第37,38図に示す。 7−17.付加モード仕様のレベル 付加モードの利用方法としては、普通の間接参照、オ
ブジェクトコードのモジュール化のための外部変数のテ
ーブル参照、AI向け命令の実行などがあり、このうち、
AI向けの用途ではかなり多くの段数の間接参照を使うこ
とがあるが、普通の用途では、3〜4段までの間接参照
で十分なことが多い。 任意段数の付加モードが利用できれば、コンパイラの
中で段数による場合分けが不要になるので、コンパイラ
の負担が軽減されるというメリットがある。多段の間接
参照の頻度が非常に少ないとしても、コンパイラとして
は必ず正しいコードを発生できなければならないからで
ある。 しかし、インプリメントの方から考えると、任意の段
数を許して実行中の割り込みを受け付けるようにするの
はかなり重くなるため、全体のバランスとしてある程度
の段数制限をするのはやむを得ない。 そこで、本発明装置としては4段(付加モード基本フ
ォーマットの4つ分)までの付加モードが利用できるも
のを〈〈L1〉〉仕様とし、任意段数の付加モードのイン
プリメントは〈〈L2〉〉仕様としてクラス分けする。
〈〈L1〉〉仕様でも、5回のメモリ間接参照まで可能で
ある。5段(5ハーフワード)以上の付加モードに対し
ては、予約命令例外(RIE)が起動される。ただし、フ
ォーマット上は任意の段数が可能になっているので、将
来はそのままのフォーマットで段数を拡張することがで
きる。 本発明装置では任意段数の付加モードを許す。ただ
し、本発明装置では付加モードをもちいてメモリ間接ア
ドレッシングを多用した場合、処理速度が低下すること
があるので注意を要する。特に第2オペランドで多段の
付加モードが用いられた場合、付加モード処理中は割り
込みが受け付けられない場合があるので注意を要する。 また、本発明装置32でも浮動小数点を扱うことを考
え、‘×8'のスケーリングをインプリメントする。‘×
8'のスケーリングは〈〈LX〉〉仕様ではなく〈〈L1〉〉
仕様である。 8.インプリメント関連事項 8−1.仮想記憶のサポート (本発明装置では、仮想記憶のサポートは行わない。) 仮想記憶を実現するため、命令の実行途中で発生した
ページフォールトに対してうまく回復処理を行なう必要
がある。本発明装置では、原則として命令再実行方式を
採用する。 命令再実行方式でページフォールトが起こった場合に
は、それまでに変更したレジスタ類をプロセッサがすべ
てもとに戻してから、ページインの処理ルーチンを起動
する。したがって、処理再開後に命令の始めより再実行
しても矛盾は生じない。 命令再実行方式では、原則として実行途中の状態を保
持する必要がないので、実現機構は比較的簡単である。
また、本発明装置では、命令再実行のことを考慮して、
処理の途中で副作用を残す命令やアドレッシングモード
(オートインクリメントなど)を極力避けるようにして
いる。ただし、ページフォールトからの再実行では余分
なメモリアクセスが起こることがあり、OSで入出力装置
を操作する場合などには注意が必要である。 例えば、一般形の命令において、第一オペランドでI/
Oのリードを行ない、第二オペランドでページフォール
トを起こした場合、命令の再実行でもう一度I/Oのリー
ドを行なうため、I/Oの種類によっては矛盾を起こす。
したがって、リードによって副作用のあるI/Oをアクセ
スする場合は、その命令のもう一方のオペランドでペー
ジフォールトを起こさないように注意し、マニュアルに
も明記する必要がある。具体的には、もう一方のオペラ
ンドが必ずレジスタか常駐ページであればよい。 また、MOV命令などでソースオペランドとデスティネ
ーションオペランドが一部重なっていた場合、単なる再
実行では矛盾を生じることがあるので、この点に対する
注意も必要である。 例:2バイトのデータを1バイトずらす。デスティネーシ
ョンがページ境界にまたがる。 第39図で、MOV.H命令により[N−2:N−1]を[N−
1:N]に移す場合、デスティネーションの書き込みバス
サイクルは2回に分かれる。まず[N−2]のデータが
[N−1]に書かれ、次に[元のN−1]が[N]に書
かれるものとする。[N−1]への書き込みの際にpage
M−1がフォールトを起こすと、ページイン後[N−2:
N−1]を[N−1:N]を再試行しようとしても、N−
1の内容が既に書き変わっているので、矛盾を起こす。 さらに、LDMのような複数のデータ転送を行なう命令
でも、転送元と転送先が重なっていた場合に、命令の再
実行で矛盾が生じないようにする必要がある。例えば、 LDM @R6,(R6−R10) の場合、R6,R7をロードした後でR8を読んだ時にページ
フォールトが起きると、再実行した時に既にR6が書き替
わっており、本当に命令の最初から実行すると、矛盾を
生じる。これを避けるためには、以下のような対策をと
る必要がある。 ・命令の最初でページフォールトが起きないことを確認
する。 ・ページフォールト時に転送中のアドレスを示すテンポ
ラリ値をスタックにセーブする。(一種の命令継続実行
方式) ・R6の初期値を記憶しておき、ページフォールト発生時
にはこれをもとの値に戻す。 STMやその他の命令についても同様である。 なお、命令の再実行を矛盾なく行なうため、LDM,STM,
LDCTXでは付加モードを禁止している。また、ENTER,EXI
T,JRNGでは、メモリアクセスを伴うようなアドレッシン
グモードをすべて禁止している。 8−2.プログラムによる命令の書き換え ストアドプログラム方式の計算機は、一般に、これか
ら自分の実行する命令プログラム自体をプログラムによ
って書き変えることが可能である。しかし、命令のプリ
フェッチや命令キャッシュなどを持つ最近の高性能プロ
セッサでは、プログラムで命令を書き変えた場合の動作
を保証しようとすると、ハードウエアの負担が極めて大
きくなる。また、この機能は必要性が少なく、ソフトウ
エアの教育上も好ましくない。したがって、本発明装置
では、ソフトウエアによってこれから実行する命令コー
ドの書き換えを行なうことは原則として禁止し、そのよ
うな場合には動作を保証しないものとしている。ただ
し、OSからユーザまで含めたシステム全体の動作を見る
と、どこかでプログラムのロード〜実行といった流れを
含んでいるため、すべての場合にわたって「動作を保証
しない」とするわけにはいかない。また、特殊な用途で
は、ユーザプログラムで命令コードを生成し、それを実
行したいという場合もある。したがって、何らかの条件
が満たされた時には、ソフトウエアによって書き換えら
れた命令コードの実行動作を保証する必要がある。 そこで、本発明装置では、命令コードを書き換えたと
いうことをプロセッサに知らせる命令PIBを用意し、こ
の命令を実行することにより、以後、書き換えられた命
令コードの実行動作を保証することにしている。この命
令は、これから実行すべき命令コードが、以前(リセッ
ト時あるいは前回のPIB命令実行時)から変更されてい
る可能性があるということを、プロセッサに通知するた
めに使用する。インプリメント上は、この命令によって
パイプライン、命令キュー、命令キャッシュのパージを
行なうことになる。 9.EIT処理 本発明装置では、プログラムの実行の流れとは非同期
に行なわれる処理を総称して、EIT処理と呼んでいる。 EIT処理は、通常、例外処理や割り込み処理と呼ばれ
ているものである。EIT処理には、次のようなものが含
まれる。 ・内部割り込み(リング間コール、トラップ) システムコール発行などの際に、プログラマが意識し
て発生させる。 その時に実行中のコンテキストとは関連がある。 ・例外割り込み(例外) 一般の命令の実行中に、何らかのエラーが起った場合
に発生する。 その時に実行中のコンテキストとは関連がある。 ・外部割り込み(割り込み) 外部からのハードウエア的な信号により発生する。 その時に実行中のコンテキストとは全く関連がない。 EITとはException(例外割り込み)、Interrupt(外
部割り込み)、Trap(内部割り込み)の頭文字を合わせ
た名称である。EIT処理に関する詳細は付録9を参照の
こと。 10.PSWの構成 本発明装置のPSW(Processor Status Word)は32ビッ
トである。PSWの下位16ビット(PSH−Processor Status
Halfword)はユーザプログラム用であり、ユーザプロ
セスから自由に操作可能でる。PSWの上位16ビット(PSS
−Processor Status halfword for System)はシステム
用であり、ユーザプログラム(リング3)からは操作で
きない。PSHのうち、上位8ビットは各種モードの設定
を行なう部分であり、PSM(Processor Status byte for
Mode)と呼ぶ。また、PSHの下位8ビットは各種ステー
タスや演算結果の表示を行なう部分であり、PSB(Proce
ssor Status Byte)と呼ぶ。第40図に示す。 10−1.PSSの構成 第41に示す。 ・本発明装置では、〈〈LA〉〉仕様として4レベルのリ
ング保護によるメモリ管理を行なう(付録参照)。本発
明装置では2レベルのリング保護によるメモリ管理を行
なう。 RNGフィールドは、現在プロセッサがどのリングにい
るかという状態を示すものである。リング保護を行なわ
ない場合にも、例えばスーパバイザ、ユーザモードの切
り換え用にこのフィールドを使用する。 ・XAビットは、本発明装置32でreservedであり、1を書
き込もうとすると例外が発生する。 ・トレースなどデバッグ関係の情報については、その詳
細まで統一するのは難しいため、別の制御レジスタ(DC
R−Debug Control Register)に分離している。ただ
し、デバッグ中がどうかを示す情報のみDBとしてPSWに
入れる。 ・本発明装置の外部割り込みは、低い優先度の方が大き
な数字になる。外部割り込みの優先度は、0〜6の7レ
ベルであり、優先度0はマスク不能割り込み(NMI)で
ある。 ・キャッシュやMMUの制御情報は完全な統一が難しいた
め、PSWとは分離している。 ・AT(アドレス変換指定フィールド)をPSWに入れたこ
とによって、コンテキスト毎にアドレス変換やメモリ保
護の方法を変えたり、EIT処理ハンドラ実行中のみ一時
的にアドレス変換を止めたりすることが可能になってい
る。 なお、LDC,REIT,LDCTX,EIT起動などによって、PSW中
のAT(アドレス変換ビット)が00から01に変更された場
合には、TLBやキャッシュのパージが自動的に行なわ
れ、TLBや論理キャッシュの整合性が保証されるものと
する。また、ATが01から00に変更された場合にも、キャ
ッシュ(この場合は論理キャッシュ兼物理キャッシュ)
の整合性が保証されるものとする。 10−2.PSHの構成 第42図に示す。 ・PRNGフィールドで「一つ前のリング」とは、「一つ外
側のリング」あるいは、「そのリングにサービスを依頼
したリング」を表わすものである。したがって、EIT発
生時のPRNGの変化は、 リターン時(REIT命令)でのPRNGの変化は、 (RNG,PRNGを含む) となる。リターン時はRNGよりコピーするのではなく、
必ずスタックより復帰する必要がある。常にRNG≦PRNG
が成立する。PRNGは、ACS命令などでの参照を目的とし
たもので、実際のリング遷移はあくまでもRNGの情報を
使用する。 ・本発明装置以外のプロセッサでは、比較〜条件ジャン
プ、といった命令の流れをとる場合に、符号付きと符号
なしの区別を比較命令ではなく条件ジャンプ命令で行な
うのが普通である。例えば、符号なし整数の比較を CMP src1,src2 BLTS next Branch Lower Than(Singned) で、符号付き整数の比較を CMP src1,src2 BLTU next Branch Lower Than(Unsigned) で行なう。したがって、フラグの表現する情報として、
大小の区別のほかに、符号付きと符号なしの区別も必要
である。 しかし、本発明装置では、符号付きと符号なしの区別
がCMP命令、CMPU命令といったように命令別になってお
り、条件ジャンプ命令は符号付きも符号なしも共通であ
る。したがって、フラグ構成を簡単にすることができ
る。 ・通常のプロセッサで使用するCarry Flagは、符号なし
整数の大小関係を表わすという意味と、多倍長演算の桁
上がりを表わすという意味がある。しかし、後者に関し
ては本発明装置ではX_flagを使用するため、Carry Flag
は整数の大小関係を表わすという意味でのみ用いられ
る。したがって、TRON CHIPではこのフラグを大小関係
を表わすフラグであると定義し、名前をL_flag(Lower
Flag)としている。このフラグは、符号なし演算の場合
には従来のCarry Flagと同じ振る舞いをするが、符号付
き演算の場合には従来のCarry Flagとは異なり、オーバ
ーフローまで考慮した真の大小関係を表現する。 ・そのほか、ストリング命令やキューの命令の終了条件
を示すためのF_flag(General Flag)とPビットのエラ
ーを表現するためのP_flag(P−bit Frror Flag)を設
ける。P_flagは、現在の仕様では‘0'にreservedとなっ
ている。 ・通常のプロセッサでは、シフト命令ではみだしたビッ
トを入れるためにCarry Flagを用いているが、本発明装
置ではCarry Flagの代わりにL_flagを実装しているた
め、はみだしたビットはX_flagに入れることにする。 10−3.フラグの変化 加減算命令、比較命令、論理演算命令は2オペランド命
令であり、 の形をとる。destとsrcのサイズが異なる場合には、小
さいサイズの方が大きいサイズに合わせて符号拡張(AD
DU,SUBU,CMPUではゼロ拡張)された上で演算され、 演算結果がdestのサイズに変換されてからdestに格納
される。 CMP,CMPU,SUB,SUBUの場合、L_flagは、前の演算で第
一オペランドの方が値が小さかったことを示す。符号な
し演算CMPU,SUBUの場合には、L_flagは通常のプロセッ
サのCarry(Borrow)Flagと同じ意味になる。符号付き
演算の場合には、L_flagは単なるM_flagのコピーとは異
なり、オーバーフローまで含めた真の大小関係を表現す
る。ADD命令の場合には、L_flagは結果が負であること
を示す。これも、単なるM_flagのコピーとは異なり、オ
ーバーフローまで含めた真の正負を示す。ADDUの場合に
は、結果が必ず正になるため、L_flagは0となる。 V_flagは、演算の結果がdestで指定されたサイズでは
表現できなかったということを示す。つまり、演算結果
がdestのサイズの符号付き整数(ADDU,SUBUでは符号な
し整数)で表現できない時に、V_flagがセットされる。
CMP,CMPU命令では、V_flagは不変である。 X_flagは、多倍長の演算を行なう場合に、桁上がりの
状態を保持するために使用する。符号付き演算でも符号
なし演算の時と同じような変化をする。これは、通常の
プロセッサのCarry Flagとほぼ同じ意味であるが、X_fl
agを変化させる命令は加減算命令やシフト命令などに限
られている。 CMP命令とSUB命令、およびCMPU命令とSUBU命令のL_fl
agの変化は全く同じである。X_flagは、SUB,SUBU,SUBX
命令では変化するが、CMP,CMPU命令では変化しない。 MOV,MOVU,ADD,ADDU,ADDX,SUB,SUBU,SUBX命令の場合、
M_flagとZ_flagは、演算結果をdestのサイズに変換した
後の値を基準にして変化する。したがって、srcのサイ
ズよりもcestのサイズの方が小さい時は、演算結果が0
でなくてもZ_flagがセットされることがありうる。一
方、CMP,CMPU命令の場合のZ_flagは、演算結果そのもの
の値を基準にして変化し、destのサイズには関係しな
い。 ADDX,SUBX命令のフラグの変化は、多少変則的になっ
ている。これは、符号なし整数の拡張演算にも符号付き
整数の拡張演算にも対処するためである。この場合、条
件ジャンプ命令のニモニックとの対応がうまくとれなく
なるが、拡張演算自体が頻度も少なく、変則的な面を持
っているので、やむを得ない。 L_flag 符号付き演算としての大小関係(SUBX)、正負
(ADDX)を示す。 V_flag 符号付き演算としてのオーバーフローを示す。 X_flag ADDXの場合はdest+src+X_flagの演算におけ
るdestのサイズからの桁上がり、SUBXの場合は、dest−
src−X_flagの演算におけるdestのサイズからの桁下が
りを表わす。ただし、いずれの場合も、srcのサイズがd
estのサイズよりも小さい場合には、srcが符号拡張され
る。 SUBXにおいて、srcとdestのサイズが等しい場合に
は、結果的に、X_flagが符号なしデータとしての比較結
果を表わすことになる。 ADDX,SUBXで異種サイズ間の演算を行なう場合には、
サイズの短い方が符号拡張される。しかし、符号拡張後
の値を符号付きの数とみて演算するか、符号なしの数と
みて演算するかはフラグによって異なる。 MOV命令、MOVU命令および論理演算命令では、X_flag,
L_flagは変化しない。論理演算命令では、V_flagも変化
しない。 各命令に対応したフラグの変化は、命令セットの説明
の中に示されている。 ‘☆’は要注意個所である。 11.命令セットの記述について 11−1.記述形式の概要 【ニモニック】 その命令の名前(ニモニック)を示す。 【命令の機能】 その命令の機能の概要を示す。 【命令オプション】 その命令で使用できる命令オプションの種類を示す。 命令オプションは、命令の機能の細かい点を変更するた
めに用いるものであり、アセンブラ表記では‘/xxx'に
より記述する。 【命令ビットパターンとアセンブラ表記】 命令のビットパターン、そのアセンブラ表記、使用で
きるサイズの種類などを示す。本発明装置では、一つの
命令ニモニックに対して一般形や短縮形といった複数の
命令フォーマットが存在する場合があり、それぞれ使用
できるアドレッシングモードやサイズが異なっている。
この項では、命令フォーマット別にそういった内容を明
らかにする。 【フラグ変化】 命令実行後のステータスフラグ(PSB)の変化を示
す。 【解説】 その命令の機能を解説する。 なお、説明の中で現れるアセンブラニモニックの詳細に
ついては、巻末の付録を参照のこと。 11−2.命令ビットパターンとアセンブラ表記 命令ビットパターンとアセンブラ表記の部分は、フォ
ーマット別ニモニック、オペランド名、オペランドフィ
ールド名、命令ビットパターンから成る。 記述例: 第43図に示す。 AND:G‥フォーマット別ニモニック説明を行なう命令ビ
ットパターンのフォーマット別ニモニック(付録参照)
を示す。 src,dest‥オペランド命令 その命令の機能を説明するために使用する変数であ
る。この変数は、「命令の機能」「解説」で参照され
る。ここで記述されたオペランドの順番が、そのままア
センブラにおけるオペランドの順番になる。 EaR,EaM‥オペランドフィールド名 オペランドフィールド名は、ビットパターンとの対
応、使用できるオペランドサイズやアドレッシングモー
ド、メモリアクセス方法、その他の制約事項などの情報
をまとめて表わすものである。オペランドフィールド名
を表わす文字とその意味との間には一定の原則を設けて
おき、いろいろな意味を簡潔に表現できるようにしてい
る。 枠でかこまれた部分‥命令ビットパターン 命令ビットパターン中では、オペランドフィールドや
サイズ指定フィールドの位置、命令のオペコードなどを
示す‘*’で示されビットは、don/t careのビットであ
る。このビットの0/1は、命令デコードには影響しな
い。 ‘−',‘+',‘=',‘#’で示されるビットは、現在
のところ、命令機能やオペランドの区別には使用されて
いないビットである。ただし、ユーザプログラムでは
‘−',‘=’の部分には0を、‘+',‘#’の部分には
1を入れておかなければならない。‘−’のビットが0
でない場合や‘+’のビットが1でない場合は、予約命
令例外(RFE)となる。 ‘=’のビットが0でない場合や‘#’のビットが1
でない場合は、単に無視される。つまり、ハード的には
‘*',‘=',‘#’は同等の意味を持つ。しかし、将来
の拡張のために、ユーザ向けのマニュアルには‘=',
‘#’を‘0',‘1'としておくように明記しておかなけ
ればならない。 11−3.フィールド名 命令ビットパターン中には、オペランドフィールドの
ほかに、オプションフィールド、サイズ指定フィールド
がある。本発明装置で使用しているオプションフィール
ド名、サイズ指定フィールド名には、次のようなものが
ある。 ・サイズ指定フィールド名 RR readアクセスを行なうオペランドのサイズ指定 WW writeアクセスを行なうオペランドのサイズ指定 MM read−modify−writeアクセスを行なうオペラン
ドのサイズ指定 BB ビット操作命令でのメモリアクセスサイズ XX 上記以外の一般的なサイズ指定 特にレジスタサイズの指定を行なう場合 SS 上記以外の一般的なサイズ指定 ディスプレースメントのサイズ、CMPの第二オペラン
ド、暗黙でオペランドを指定するストリング命令、暗黙
でスタックを指定するMOVA:U命令などに使用 必ず同じ文字(大文字)を反復する。ただし、32ビット
と64ビットの指定しかできない場合には、このうちの一
文字のみを使う。 ・オプションフィールド名 命令オプションの指定を行なうオプションビットの名
前としては、主として小文字を使う。(Pビット関係を
除く) オプションフィールド名には、以下に示すようなものが
ある。いずれの場合にも、最初に記述した方(オプショ
ン値が0,00‥の方)がアセンブラでのデフォルトにな
る。 cccc Bcc,TRAP/ccでの条件指定 eeee ストリング命令、QSCH命令での終了条件指定 P,Q‥ Pビット指定(Q‥は、Pビットの必要なオペ
ランドが複数の場合) b /F=0,/B=1(BSCH,BVSCH,BVMAP,BVCPY,SCMP,
SMOV,QSCH) r /F=0,/R=1(SSCH) c /N=0,/S=1(CHK)‥CHK,change index valu
eの‘c' d /0=0,/1=1(BSCH,BVSCH)‥dataの‘d' m /NM=0,/MR=1(QSCH)‥maskの‘m' p /AS=0,/SS=1(PTLB,PSTLB,LDATE)‥PTLB,s
Peci fic spaceの‘p' ttt /PT=000,/ST=001,/AT=110,/reserved=010〜
101,111(PSTLB,LDATE,STATE) xx /LS=00,/CS=01 reserved=10,11(LDCTX,STCT
X) 以上の項目に当てはまらないフィールド名は、オペラン
ドフィールド名を示すものになる。できるだけ、同じ文
字が複数の意味を表わさないようにしている。 11−4.オペランドフィールド名 オペランドフィールド名を表わす文字には、以下のよ
うな意味を持たせている。オペランドフィールド名はこ
れらの文字の組み合わせによって構成されるため、フィ
ールド名だけで、使用できるアドレッシングモード、オ
ペランドサイズ、アクセス方法などの情報を得ることが
できる。 ・基本となるアドレッシングモード Ea 8ビットの一般形アドレッシングモードを使用 Sh 6ビットの短縮形アドレッシングモードを使用 # リテラル #i イミディエート #d ディスプレースメント Rg レジスタ Ll レジスタリスト(LDM用) Ls レジスタリスト(STM用) Ln レジスタリスト(ENTER用) Lx レジスタリスト(EXITD用) ・アクセス方法 一部の基本アドレッシングモードでは、以下のような
アクセス方法がデフォルトとして決まっている。この場
合には、特にアクセス方法を示す文字を付けない。 #,#i,#d 命令空間からのread Ls,Ln レジスタのread Ll,Lx レジスタへのwrite その他の基本アドレッシングモードについては、以下
に示す文字を使用してアクセス方法を示す。 R read W write M read−modify−write なお、フィールド名を短縮するため、RgRをRRに、RgW
をRWに、RgMをRMに省略することがある。(BF命令、CSI
命令) A アドレス計算のみを行なう。 f ビットオフセットとの組み合わせによって実際に
操作を行なうメモリアドレスが決まる。(R,Mのサフィ
ックス) 例:ビット操作命令 fq ビットオフセットが付くが、ビットオフセットはバ
イト境界を越えない。アクセスすべきアドレスは、オフ
セットを見なくても確定している。(R,Mのサフィック
ス) 例:短縮形のビット操作命令 bf ビットオフセットやビットフィールド幅との組み
合わせによって実際に操作を行なうメモリアドレスと範
囲が決まる。(R,Mのサフィックス) 例:固定長ビットフィールド操作命令 q キュー命令による複雑なアクセスを行なう。(他
のアクセス方法のサフィックス) 例:QINS,QDEL命令 i バスのインタロックによるアクセスを行なう。
(Mのサフィックス) % 制御空間、物理空間などの特殊空間のアクセスを
行なう。(R,W,Mのサフィックス) d 2つのデータ(double)に対する操作を行なう。
(Rのサフィックス)例:CHK命令 m 複数のデータ(multiple)に対する操作を行なう。
(R,Wのサフィックス) 例:LDM,STM命令 ・アドレッシングモードに対する制限基本アドレッシン
グモードとアクセス方法が決まると、自動的にアドレッ
シングモードに対する制限(EaWに対するイミディエー
トモードの禁止など)が決まる。ただし、それ以外に命
令特有の制限事項がある場合には、以下の文字も後ろに
付ける。 !I イミディエートモードの禁止 例:CMP命令の第二オペランド !M メモリ対象アドレッシングモードの禁止 例:ENTER:G命令のlocalオペランド !A 付加モードの禁止 例:LDCTX命令のctxaddrオペランド !S スタックポップ、スタックプッシュモードの禁止 例:QDEL命令のdestオペランド ・サイズ指定 サイズ指定は、原則として以下に示すフィールドによっ
て行なう。 アクセス方法がR RRフィールド アクセス方法がW WWフィールド アクセス方法がM MMフィールド アクセス方法がR!I,R!M,R2 SSフィールド アクセス方法が*f BBフィールドただし、これはメモリ操作のアクセスサイ
ズを意味する。 アクセス方法がA サイズは指定されない。 これより例外がある場合には、以下の文字を付け加え
ることにより区別する。原則として、数字と小文字が固
定サイズを表わし、大文字は可変サイズを表わす。例え
ば、‘w'は32ビット(ワード)固定のサイズを示すのに
対して、‘W'はWWフィールドによりサイズが指定される
ことを示す。 W オペランドサイズは必ず32ビット 例:MUL:R命令 h オペランドサイズは必ず16ビット 例:WAIT命令 b オペランドサイズは必ず8ビット 例:MOV:E命令のsrc S8 オペランド(ディスプレースメント)のサイズ
は、SSフィールドにより指定される。ただし、このオペ
ランド指定フィールドを使うには、SS=00(8bit指定)
の時に限られる。それ以外の場合には、拡張部によって
オペランドが指定され、このフィールドは無視される。
(0にしておくこと) 例:BF:I命令のsrc S オペランド(ディスプレースメント)のサイズ
は、SSフィールドにより指定される。 例:BRA:G命令 R オペランドサイズは、もう一方のオペランドのサ
イズと共通にRRフィールドにより指定される。 例:CMP:I命令 W オペランドサイズは、もう一方のオペランドのサ
イズと共通にWWフィールドにより指定される。 例:MOV:I命令 M オペランドサイズは、もう一方のオペランドのサ
イズと共通にMMフィールドにより指定される。 例::Iフォーマットの命令 L オペランドサイズとして8ビットまたは16ビット
を指定するためのビットパターンが割り当てられていな
いため、32ビットまたは64ビットのオペランドのみが指
定できる。サイズ指定は、RR,WW,MM,BBフィールドでは
なく、R,M,W,Bフィールドにより行なわれる。 P ポインタを扱うため、命令中ではサイズ指定を行
なわない。実際のサイズ指定は、Pビットまたはモード
(PSW中のXAビット)等によって行なわれる。 例:QINS,QDEL命令 X オペランドサイズは、XXフィールドにより指定さ
れる。 例:ACB,SCB命令のxreg Xw オペランドサイズは、Xフィールドにより他のオ
ペランドと共通に指定される。これは、BF命令のwidth
指定用である。 Xs オペランドサイズは、Xフィールドにより他のオ
ペランドと共通に指定される。これは、BF命令のsrc指
定用である。 Xd オペランドサイズは、Xフィールドにより他のオ
ペランドと共通に指定される。これは、BF命令のdest指
定用である。 C オペランドサイズは、RRフィールドにより他のオ
ペランドと共通に指定される。これは、CSI命令の比較
値指定用である。 3 3ビットのリテラル 4 4ビットのリテラル 例:TRAPA命令 6 6ビットのリテラル 8 8ビットのディスプレースメント 例:BRA:8名 16 16ビットのディスプレースメント 例:MOVA:R命令 なお、ストリング命令などの高機能命令において、命
令によって暗黙に指定されるオペランドのサイズを指定
する場合には、フィールド名としてSSを使用する。任意
長ビットフィールド命令では、Xも使用される。 ・その他 Z リテラルで、ビットパターンの0をオペランド値
の0(zero)に対応させる場合を示す。ビットパターン
とオペランド値との対応は、以下のようになる。(Nは
リテラルのビット数) 例:BTST:Qのoffset n リテラルで、ビットパターンの0をオペランド値
の2^Nに対応させる場合を示す。ビットパターンとオペ
ランド値との対応は、以下のようになる。(Nはリテラ
ルのビット数) 例:MOV:Qのsrc c リテラルで、ビットパターンが2の補数(comple
ment)を現わす場合を示す。ビットパターンとオペラン
ド値との対応は、以下のようになる。(Nはリテラルの
ビット数)例:SHA:C,SHL:Cで右シフトの場合のシフトカウント 1,2…一つの命令の中で、同じアクセス方法を持つオペ
ランドが複数存在した場合に、それらを区別するために
使用する。 なお、サイズに関する種々の制限事項のうち、命令機
能に大きな関係を持つものについては、オペランドフィ
ールド名やサイズ指定フィールド名ではなく、各命令の
説明のところでその制限を示す。これには、シフトカウ
ントで8ビット以外のサイズを指定した場合や、異種サ
イズ間の論理演算などが含まれる。 11−5.アドレッシングモードに関する制限 オペランドフィールド名のうち、次のものは、使用で
きるアドレッシングモードに制限が設けられている。 EaR,ShR @−SPは利用できない。 EaW,ShW #imm_data,@SP+は利用できない。 EaM,ShM #imm_data,@−SP,@SP+は利用できない。 EaA @SP+,@−SP,Rn,#imm_dataは利用できない。 このほか、各命令の説明のところでもアドレッシング
モードに関する制限が述べられている。 11−6.解説に関する注意 スタック操作の命令では、TOSによりスタックトップ
を示している。↑TOSはスタックからのポップ、↓TOSは
スタックへのプッシュである。 2オペランドの基本命令(MOV,MOVU,ADD,ADDU,ADDX,S
UB,SUBU,SUBX,AND,OR,XOR,CMP,CMPU)では、次のような
記法でそのオペレーションを説明している。 dest(src2)のサイズ(ビット数)をdで、src(src
1)のサイズ(ビット数)をsで表わし、src(src1),d
est(src2)をビット分解した値をD0,D1,…Dd−1,S0,S
1,…Ss−1で表わす。したがって、 dest(src2)=[D0.D1…Dd−2.Dd−1] src(src1)=[S0.S1…Ss−2.Ss−1] と書ける。 は2進数による表示を、‘.'は各桁の区切りを意味す
る。この時、演算結果によってdestに設定される値を dest.op.src=result=[R0.R1…Rd−2.Rd−1] で表わす。MOV,MOVU,CMP7,CMPU以外の命令では、result
がdestにセットされる。またs>dの場合は、一般に演
算結果の下位ビットのみをdestに設定することになる。
この時、演算結果の上位ビットをカットする前の値を result=[F0.F1…Fs−2.Fs−1] で表わす。Rのビット数はd、Fのビット数はsであ
る。 ビット列 を符号付きの2進数と解釈した場合には、そのビット列
の表現する値を で表わし、符号なしの2進数と解釈した場合には、その
ビット列の表現する値を で表わす。また、そのビット列を符号付きPACKED形式10
進数と解釈した場合には、そのビット列の表現する値を で表わし、符号なしPACKED形式10進数と解釈した場合に
は、そのビット列の表現する値を で表わす。さらに、‘~'は真偽反転を、‘^'は累乗を表
わす。 同じように、固定長ビットフィールド命令の説明で
は、 bitfield=[Bo.Bo+1…Bo+w−2.Bo+w−1] といった記法でビット単位の詳細なオペレーションを説
明している。 略記法として、 [Sn.Sn+1…Sm−2.Sm−1] を [Sn〜m−1] で表わし、 [S0.S1…Sd−2.Sd−1]=[S0〜s−1] を単に、 [S] で表わすことがある。[D],[R],[B],[F]
についても同様である。 12.「本発明装置」の命令セット 12−1.データ転送命令 【ニモニック】 MOV src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第44図に示す。 【フラグ変化】 第44図最下部に示す。 【解説】 ソースオペランドsrcをデスティネーションオペラン
ドdestに転送する。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースが符号拡張さ
れる。 デスティネーションの方がサイズが小さく、ソースの
値がデスティネーションのサイズの符号付き整数として
表現できない時は、V_flagがセットされる。 MOV:Zはいわゆるclear命令であるが、動作やフラグ変
化が同じであるため、MOVの短縮形の一つとして扱って
いる。 MOV,ADD,MOV,CMP命令は符号付きの演算を行なう命令で
あるが、MOV:Q,ADD:Q,SUB:Q,CMP:Qで利用できるリテラ
ルの範囲は1〜8(オペランドフィールド名#3n)とな
っており、正の範囲しか含んでいないので、注意が必要
である。MOV,MOVU命令ではsrcがイミディエート値であ
る場合に、そのイミディエート値と利用できるフォーマ
ットとの関係をまとめると、次のようになる。 [MOV] :Z src=0 :Q 1≦src≦8 :E −128≦src≦127 :I srcは任意 :G srcは任意 [MOVU] :E 0≦src≦255 :G srcは任意 ADD,SUB,CMP命令も同様である。 (d≦sの時) [R0.R1…Rd−s+1.Rd−s.Rd−s+1…Rd−2.Rd−
1](destに設定される) (d<sの時) (destに設定される) M_flag R0 Z_flag [R0〜d−1]=0 V_flag☆ S[S]<−2^(d−1).or.S[S]≧+2
^(d−1)つまり、d≧sであればクリアされ、d<
sであれば、 の時クリア、それ以外の場合にセットとなる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・WW=‘11'のとき ・EaR,ShRが@−SPのとき ・EaW,ShWが#imm_data,@SP+のとき 【ニモニック】 MOVU src,dest 【命令の機能】 データの移動とゼロ拡張 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第45図に示す。 【フラグ変化】 第46図に示す。 【解説】 ソースオペランドsrcをデスティネーションオペラン
ドdestに転送する。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースがゼロ拡張さ
れる。 デスティネーションの方がサイズが小さく、ソースの
値がデスティネーションのサイズの符号なし整数として
表現できない時は、V_flagがセットされる。 M_flag R0 Z_flag [R0〜d−1]=0 V_flag☆ U[S]≧+2^d つまり、d≧sであればクリアされ、d<sであれば、 S0=S1=……=Ss−d−1=0 の時クリア、それ以外の場合にセットとなる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・WW=‘11'のとき ・EaRが@−SPのとき ・EaWが#imm_data,@SP+のとき 【ニモニック】 PUSH src 【命令の機能】 push to stack スタックにプッシュ 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第47図に示す。 【フラグ変化】 第48図に示す。 【解説】 ソースオペランドsrcをスタックにプッシュする。 この命令は、MOV *,@−SPの短縮形と考えることも
できるが、フラグ変化をしないこと、およびPOPとの対
称性により、別命令となっている。 src/EaRLで指定されるアドレッシングモードでは、@
SP+のモードは使用できない。これは、POP命令のdest/
EaWLで@−SPのモードが使用できないのに合わせたもの
である。 PUSH SPなど、srcオペランドにSPを含む場合の命令動
作規定については、付録12を参照のこと。 【プログラム例外】 ・予約命令例外 ・R=‘1'のとき ・EaRLが@SP+,@−SPのとき 【ニモニック】 POP dest 【命令の機能】 pop from stack スタックからポップ 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第49図に示す。 【フラグ変化】 第50図に示す。 【解説】 スタックからポップした値をdestに転送する。 この命令は、MOV @SP+,*の短縮形と考えることも
できるが、srcにSPを含んだ場合の動作がMOV @SP+と
は異なること、およびフラグ変化をしないこと、によっ
て別命令となっている。 dest/EaWLで指定されるアドレッシングモードでは、
@−SPのモードを使用することは禁止されており、指定
した場合には予約命令例外RIEとなる。これは、POP @
−SPという命令を実行した場合に、SP更新がいつ行なわ
れるかという点について誤解を生じやすいためである。 POP SPなど、destオペランドにSPを含む場合の命令の
動作規定については、付録12を参照のこと。 【プログラム例外】 ・予約命令例外 ・W=‘1'のとき ・EaWLが#imm_data,@SP+,@−SPのとき 【ニモニック】 LDM src,reglist 【命令の機能】 load multiple registers 複数レジスタのロード 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第51図に示す。 【フラグ変化】 第52図に示す。 【解説】 複数のレジスタをメモリからロードする。ロードする
レジスタはビットマップreglist/LIRL(レジスタリス
ト)で指定する。LIRLは、EaRmLの拡張部よりも後に置
かれる。 ロードするレジスタリスト(reglist)のビットマッ
プ指定は、第53図に示すように行なう。 EaRmLで@SP+のアドレッングモードを指定した場合
は、小さい番号のレジスタから順にポップされ、SPはロ
ードしたレジスタ数の4倍(または8倍)だけ増加す
る。それ以外のアドレッシングモードを指定した場合
は、得られた実効アドレスがレジスタにロードすべきメ
モリデータの先頭を指す。いずれの場合にも、メモリ中
では小さい番号のレジスタの方が低いアドレスに置かれ
る。 ロードするレジスタのビットマップのフォーマット
は、BSCH/F,BVSCH/F命令で使用する回路(次に出現する
‘0'または‘1'のビットをMSB方向にサーチする回路)
と同じ回路によって、次に転送するレジスタを見付けら
れるように決めたものである。したがって、LDM @SP+
の場合は小さな番号のレジスタから転送するためにレジ
スタ番号の小さな方がMSB側となっている。それ以外の
アドレッシングモードの場合にも、レジスタ退避ブロッ
クの先頭アドレスを実効アドレスとしているため、やは
りレジスタ番号の小さい方から転送するのがよく、LDM
@SP+と同じフォーマットになる。 なお、これらのフォーマットはレジスタの転送順序ま
で考えて決めたものであり、ハードウエア資源が少ない
場合には、ここで説明したような転送順序にするのが最
適と考えられる。しかし、実際の転送の順序は「本発明
装置」で規定されたものではなく、インプリメント側の
自由である。 EaRmLのアドレッシングモードでは、@−SP、レジス
タ直接モードRn,イミディエートモード#imm_data、付
加モードの指定はイリーガルとする。付加モードを禁止
するのは、LDMやSTMによって退避、復帰したレジスタや
レジスタ退避エリアと、付加モードで使用するレジスタ
やメモリの間にオーバーラップがあった場合に、命令の
再実行が難しくなるためである。 レジスタリストがオール0の時は、何もせずに命令を
終了する。(特にエラーとはしない) LDM @SP+でレジスタリストにSPが含まれる場合の動
作規定については、付録12を参照のこと。 【プログラム例外】 ・予約命令例外 ・R=‘1'のとき ・EaRmLがRn,#imm_data,@−SP,付加モードのとき 【ニモニック】 STM reglist,dest 【命令の機能】 store multiple registers 複数レジスタのストア 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第54図に示す。 【フラグ変化】 第55図に示す。 【解説】 複数のレジスタをメモリにセーブする。セーブするレ
ジスタはビットマップreglist/LsWL(レジスタリスト)
で指定する。LsWLは、EaWmLの拡張部よりも後に置かれ
る。 ストアするレジスタリスト(reglist)のビットマッ
プ指定は、EaWmLが@−SPモードの時、第56図に示すよ
うに、またその他のモードの時、第57図に示すように行
う。 EaWmLに@−SPのアドレッシングモードを指定した場
合は、大きい番号のレジスタから順にプッシュされ、SP
はセーブしたレジスタ数の4倍(または8倍)だけ減少
する。それ以外のアドレッシングモードを指定した場合
は、得られた実効アドレスがレジスタをセーブすべきメ
モリ領域の先頭を指す。いずれの場合にも、メモリ中で
は小さい番号のレジスタの方が低いアドレスに置かれ
る。 このフォーマットは、BSCH/F,BVSCH/F命令で使用する
回路(次に出現する‘0'または‘1'のビットをMSB方向
にサーチする回路)と同じ回路によって、次に転送する
レジスタを見付けられるように決めたものである。した
がって、STM @−SPの時は大きな番号のレジスタから転
送するためにレジスタ番号の大きな方がMSB側となる。
それ以外のアドレッシングモードの場合には、レジスタ
退避ブロックの先頭アドレスを実効アドレスとしている
ため、レジスタ番号の小さな方から転送するのがよく、
レジスタ番号の小さな方がMSB側となっている。 なお、これらのフォーマットはレジスタの転送順序ま
で考えて決めたものであり、ハードウエア資源が少ない
場合には、ここで説明したような転送順序にするのが最
適と考えられる。しかし、実際の転送の順序は「本発明
装置」で規定されたものではなく、インプリメント側の
自由である。 EaRmLのアドレッシングモードでは、@SP+、レジス
タ直接モードRn、イミディエートモード#imm_data、付
加モードの指定はイリーガルとする。付加モードを禁止
するのは、LDMやSTMによって退避、復帰したレジスタや
レジスタ退避エリアと、付加モードで使用するレジスタ
やメモリの間にオーバーラップがあった場合に、命令の
再実行が難しくなるためである。 LDM,STM命令では、転送しないレジスタに対するメモ
リ領域は割り当てない。例えば、 STM.W(R1,R3,R9),@−SP の場合は次のような動作を行なう。(ただし、命令実行
前のSP値をinitSPとする。) レジスタリストがオール0の時は、何もせずに命令を
終了する。(特にエラーとはしない) STM @−SPでレジスタリストにSPが含まれる場合の動
作規定については、付録12を参照のこと。 【プログラム例外】 ・予約命令例外 ・W=‘1'のとき ・EaWmLがRn,#imm_data,@SP+,付加モードのとき 【ニモニック】 MOVA srcaddr,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第58図に示す。 【フラグ変化】 第59図に示す。 【解説】 ソースオペランドの実効アドレスをデスティネーショ
ンオペランドに転送する。 この命令のオペレーションそのものは、MOV命令など
で代用可能であるが、高級言語での左辺値のアドレス計
算やポインタ演算にすなおに使用できること、アドレス
計算用の回路を使用するため、より高速な演算が期待で
きること、により別命令となっている。 短縮形の MOVA:R @(disp:16,Rs),Rd は、実質的には3オペランド加算命令 Rs+disp:16,Rs−>Rd となるが、フラグ変化をおこさないためMOVA命令に分類
されている。 srcaddrにPC相対間接モードを指定し、PC相対のディ
スプレースメントを0とした場合には、現在のPC値、つ
まりMOVA命令の先頭アドレスをdestに格納することにな
る。また、PC相対のディスプレースメントとしてMOVA命
令の命令長を指定した場合には、MOVA命令の次の命令の
アドレスをdestに格納することになる。これらの機能
は、ユーザプログラムのレベルでコルーチン処理を行な
う時に有効である。 アセンブラでは、〈オペレーション〉またはdest側で
サイズ指定を行なう。srcaddr側はアドレス計算のみな
ので、サイズの指定はしない。 EaAで指定されるアドレッシングモードでは、イミデ
ィエート、@SP+,@−SPのモードは使用できない。 【プログラム例外】 ・予約命令例外 ・+=‘0'のとき ・W=‘1'のとき ・EaAがRn,#imm_data,@SP+,@−SPのとき ・EaWが#imm_data,@SP+のとき 【ニモニック】 PUSHA srcaddr 【命令の機能】 push address to stack 実効アドレスをスタックにプッシュ 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第60図に示す。 【フラグ変化】 第61図に示す。 【解説】 ソースオペランドsrcaddrの実効アドレスをスタック
にプッシュする。 この命令は、MOVA*,@−SPの短縮形と考えることも
できるが、実行速度の向上や、MOV命令〜PUSH命令の区
別との対応をとるために、別命令となっている。 srcにSPを含んだ場合の動作規定については、付録12
を参照のこと。 【プログラム例外】 ・予約命令例外 ・S=‘1'のとき ・EaAがRn,#imm_data,@SP+,@−SPのとき 12−2.比較、テスト命令 【ニモニック】 CMP src1,src2 【命令の機能】 src2−src1,flags affected 比較、符号拡張と比較 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第62図に示す。 【フラグ変化】 第63図に示す。 【解説】 src1オペランドをsrc2オペランドと比較し、その結果
によりPSB(L_flag,Z_flag)をセットする。 src1オペランドのサイズとsrc2オペランドのサイズが
異なる時は、サイズの小さい方のオペランドが符号拡張
された上で比較される。 なお、EaR!l,ShR!lのモードではイミディエートを禁
止しているが、@SP+は可能である。 CMP @SP+,@SP+の場合、スタックポインタはオペ
ランドサイズの2倍だけ変化し、他の命令と比較すると
変則的であるが、この命令はスタックマシンをシミュレ
ートする場合に使用することがある。 CMP:Zはいわゆるtest命令であるが、動作やフラグ変化
が同じであるため、CMPの短縮形の一つとして扱ってい
る。 以下では、 src1=[S0.S1……Ss−2.Ss−1] src2=[D0.D1……Dd−2.Dd−1] によってオペレーションを説明する。 L_flag☆ S[D]<S[S] SUB命令と同じ Z_flag [R0〜d−1]=0 (d≧sの時) ☆ [F0〜s−1]=0 (d<sの時) 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・SS=‘11'のとき ・EaR,ShRが@−SPのとき ・EaR!l,ShR!lが#imm_data,@−SPのとき 【ニモニック】 CMPU src1,src2 【命令の機能】 src2−src1,flags affected ゼロ拡張と比較 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第64図に示す。 【フラグ変化】 第65図に示す。 【解説】 src1オペランドをsrc2オペランドと比較し、その結果
によりPSB(L_flag,Z_flag)をセットする。 src1オペランドのサイズとsrc2オペランドのサイズが
異なる時は、サイズの小さい方のオペランドがゼロ拡張
された上で比較される。 EaR!lのモードではイミディエートを禁止している
が、@SP+は可能である。 以下では、 src1=[S0.S1.……Ss−2.Ss−1] src2=[D0.D1.……Dd−2.Dd−1] によってオペレーションを説明する。 L_flag☆ U[D]<U[S] SUBU命令と同じ Z_flag [R0〜d−1]=0 (d≧sの時) ☆ [F0〜s−1]=0 (d<sの時) 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・SS=‘11'のとき ・EaRが@−SPのとき ・EaR!lが#imm_data,@−SPのとき 【ニモニック】 CHK bound,index,xreg 【命令の機能】 check upper and lower bounds 配列の範囲のチェック 【命令オプション】 /S 下限値を引く /N 下限値を引かない(デフォルト) 【命令ビットパターンとアセンブラ表記】 第66図に示す。 【フラグ変化】 第67図に示す。 【解説】 配列のインデクスの範囲のチェックとレジスタへのロ
ードを行なう。 boundの指すアドレスには上限値と下限値が組みにな
って置かれており、その上限値、下限値とindexにより
フェッチされた比較値オペランドが比較される。bound
の実効アドレスに置かれているのが上限値であり、(bo
undの実効アドレス+オペランドサイズ)のアドレスに
置かれているのが下限値である。比較は符号付き整数と
して行なわれる。比較値が上限値と下限値の間に入って
いない場合には、V_flagがセットされるので、続けてTR
AP命令を実行することにより、例外処理を起動すること
ができる。 /Sを指定した場合、比較値から下限値を引いたものが
レジスタxregにロードされる。/Sを指定しない場合、比
較値はそのままレジスタxregにロードされる。比較値を
レジスタにロードするのは、次にそれを配列のインデク
スのアドレス計算に使うことが多いためである。 オペレーション: ただし、‘address_of_'は、 の逆演算子であり、boundとmem[address_of_bound]が
同じ意味になる。 下限の方は、値が一致した場合に範囲内と見なされる
が、上限の方は、値が一致した場合には範囲外と見なさ
れる。例えばboundのメモリが(0,100)となっている
と、CHKで範囲内となるのはindexが0〜99の場合であ
る。 L_flag,Z_flagは、下限値とindexとの比較結果にしたが
ってCMPと同様にセットされるが、L_flag=1となるの
は、 index<下限値 の場合である。つまり、第68図のようになる 上限値<下限値の場合には、下限値との比較により1
になることもある。 この場合、index−下限値の演算結果によってフラグが
セットされることになる。次の3つの命令は、すべて第
二オペランドが第一オペランド(CHKでは第一オペラン
ドboundの下限値)よりも小さい時にL_flagがセットさ
れるという仕様である。 CMP src1,src2 SUB src,dest CHK bound,index,xreg CHK命令では、上限値≧下限値のチェックは特に行な
わない。上限値と下限値の大小にかかわらず、「オペレ
ーション」に書かれたものと等価の動作を行なうものと
する。 EaRdRで指定されるアドレッシングモードでは、レジ
スタ直接Rn,@−SP,@SP+,#imm_dataのモードは使用
できない。どうしてもレジスタ上の値と比較したい場合
には、CHKではなくCMPを2回行なえばよい。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・EaRが@−SPのとき ・EaRdRがRn,#imm_data,@SP+,@−SPのとき 12−3.算術演算命令 【ニモニック】 ADD src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第69図に示す。 【フラグ変化】 第70図に示す。 【解説】 ソースオペランドをデスティネーションオペランドに
加算する。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースが符号拡張さ
れた上で加算される。 デスティネーションのサイズが小さく、演算結果がデ
スティネーションのサイズの符号付き整数として表現で
きない時は、V_flagがセットされる。 なお、L_formatのADD:L @SP+,SPについては、ADD:G
@SP+,SPと同じく の動作を行なうのが望ましい。しかし、インプリメント
上、L_formatではこのような動作を行なうのが難しい場
合があるので、ADD:L@SP+,SPの動作についてはインプ
リメント依存とする。これは、SUB:L,CMP:L,INDEXも同
様である。 詳しくは付録12を参照のこと。 L_flag☆ S[D]+S[S]<0 結果が負になることを表わす。(M_flagも結果の正負を
表わすが、M_flagが正しい正負を表示するのはオーバー
フローのない時に限られる。) M_flag R0 Z_flag [R0〜d−1]=0 V_flag S[D]+S[S]<−2^(d−1).or.S
[D]+S[S]≧+2^(d−1) X_flag☆ いずれの場合も、destのサイズからの桁上げ
がX_flagにセットされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaR,ShRwが@−SPのとき ・EaM,ShMが#imm_data,@SP+,@−SPのとき 【ニモニック】 ADDU src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第71図に示す。 【フラグ変化】 第72図に示す。 【解説】 ソースオペランドをデスティネーションオペランドに
加算する。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースがゼロ拡張さ
れた上で加算される。 デスティネーションのサイズが小さく、演算結果がデ
スティネーションのサイズの符号なし整数として表現で
きない時は、V_flagがセットされる。 ADDUのL_flagは、結果が正になるという意味で、必ず
0にリセットされるものとする。 F0.F1.……Fs−d−1 s−dビットがカットされる。 L_flag 0 M_flag R0 Z_flag [R0〜d−1]=0 V_flag U[D]+U[S]≧+2^d X_flag☆ いずれの場合も、destのサイズからの桁上げ
がX_flagにセットされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 ADDX src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第73図に示す。 【フラグ変化】 第74図に示す。 【解説】 ソースオペランドとキャリーをデスティネーションオ
ペランドに加算する。 ソースオペランドのサイズがデスティネーションオペラ
ンドのサイズよりも小さい時は、ソースが符号拡張され
た上で加算される。 Z_flagでは、フラグ値を累積できるようになっている。
また、ADDXとADDのフラグ変化は、符号拡張/ゼロ拡張
を含めてほとんど同じである。ADDとADDXでフラグ変化
の異なるのは、Z_flagのみである。 なお、ADDX,SUBXの累種サイズ間演算については、例
えば8バイトの数dest2〜dest1に4バイトの数srcを加
える場合、 ADD @src.W,@dest1.W ADDX #0,@dest2.W のADDX:E #0といった形で利用することがある。 F0.F1……Fs−d−1 s−dビットがカットされる。 L_flag☆ S[D]+S[S]+X_flag<0 符号付きの数と見て演算を行ない、結果が負になること
を表わす。 d≠sの場合には、オペランドが符号拡張されてから比
較される。 (M_flagも結果の正負を表わすが、M_flagが正しい正負
を表示するのはオーバーフローのない時に限られる。) M_flag R0 Z_flag [R0〜d−1]=0.and.previous Z_flag V_flag S[D]+S[S]+X_flag<−2^(d−
1).or. S[D]+S[S]+X_flag≧+2^(d−1) 符号付きの数と見て演算を行ない、結果がオーバーフロ
ーすることを表わす。d≠sの場合にはオペランドが符
号拡張される。 X_flag☆ いずれの場合も、destのサイズからの桁上げ
がX_flagにセットされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 SUB src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第75図に示す。 【フラグ変化】 第76図に示す。 【解説】 ソースオペランドをデスティネーションオペランドか
ら減ずる。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースが符号拡張さ
れた上で減算される。 デスティネーションのサイズが小さく、演算結果がデ
スティネーションのサイズの符号付き整数として表現で
きない時は、V_flagがセットされる。 F0.F1……Fs−d−1 s−dビットがカットされる。 L_flag☆ S[D]−S[S]<0 結果が負になることを表わす。 (M_flagも結果の正負を表わすが、M_flagが正しい正負
を表示するのはオーバーフローのない時に限られる。) M_flag R0 Z_flag [R0〜d−1]=0 V_flag S[D]−S[S]<−2^(d−1).or. S[D]−S[S]<+2^(d−1) X_flag☆ いずれの場合も、destのサイズからの桁下げ
がX_flagにセットされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaR,ShRwが@−SPのとき ・EaM,ShMが#imm_data,@SP+,@−SPのとき 【ニモニック】 SUBU src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第77図に示す。 【フラグ変化】 第78図に示す。 【解説】 ソースオペランドをデスティネーションオペランドか
ら減ずる。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースがゼロ拡張さ
れた上で減算される。 デスティネーションのサイズが小さく、演算結果がデ
スティネーションのサイズの符号なし整数として表現で
きない時は、V_flagがセットされる。 F0.F1……Fs−d−1 s−dビットがカットされる。 L_flag☆ U[D]−U[S]<0 結果が負になることを表わす。 (M_flagも結果の正負を表わすが、M_flagが正しい正負
を表示するのはオーバーフローのない時に限られる。) M_flag R0 Z_flag [R0〜d−1]=0 V_flag U[D]−U[S]<0 SUBU命令のL_flagと同じ X_flag☆ いずれの場合も、destのサイズからの桁下げ
がX_flagにセットされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 SUBX src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第79図に示す。 【フラグ変化】 第80図に示す。 【解説】 ソースオペランドとキャリーをデスティネーションオ
ペランドから減ずる。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースが符号拡張さ
れた上で減算される。 Z_flagではフラグ値を累積できるようになっている。
また、SUBXとSUBのフラグ変化は、符号拡張/ゼロ拡張
を含めてほとんど同じである。SUBとSUBXでフラグ変化
の異なるのは、Z_flagのみである。 L_flag☆ S[D]−S[S]−X_flag<0 符号付きの数と見て演算を行ない、結果が負になるこ
とを表わす。 d≠sの場合にはオペランドが符号拡張されてから比較
される。 (M_flagも結果の正負を表わすが、M_flagが正しい正負
を表示するのはオーバーフローのない時に限られる。) M_flag R0 Z_flag [R0〜d−1]=0.and.previous Z_flag V_flag S[D]−S[S]−X_flag<−2^(d−
1).or. S[D]−S[S]−X_flag≧+2^(d−1) 符号付きの数と見て演算を行ない、結果がオーバーフ
ローすることを表わす。d≠sの場合にはオペランドが
符号拡張される。 X_flag☆ いずれの場合も、destのサイズからの桁下げ
がX_flagにセットされる。【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 MUL src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第81図に示す。 【フラグ変化】 第82図に示す。 【解説】 ソースオペランドをデスティネーションオペランドに
乗ずる。乗算は符号付きで行われ、オペランドも符号付
き整数とみなされる。 この命令は、被乗数のサイズと結果のサイズが等しい
ため、高級言語向きである。 デスティネーションのサイズが小さく、演算結果がデス
ティネーションのサイズの符号付き整数として表現でき
ない時は、V_flagがセットされる。オーバーフローが生
じた場合にも、destにセットされるデータ(正しい結果
の下位ビット)が基準となってM_flag,Z_flagがセット
される。例えば、R0=H′10000で MUL.W #H′10000,R0 を実行した場合、積がH′100000000となるため、R0=
0(下位ビット),V_flag=1,Z_flagとなる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 MULU src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第83図に示す。 【フラグ変化】 第84図に示す。 【解説】 ソースオペランドをデスティネーションオペランドに
乗ずる。乗算は符号なしで行われ、オペランドも符号な
し整数とみなされる。 デスティネーションのサイズが小さく、演算結果がデ
スティネーションのサイズの符号なし整数として表現で
きない時は、V_flagがセットされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 MULX src,dest,tmp 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第85図に示す。 【フラグ変化】 第86図に示す。 【解説】 ソースオペランドをデスティネーションオペランドに
乗ずる。この命令は、積が倍長で得られるため、srcとd
estのほかに、積の上位ビットを入れるためのテンポラ
リレジスタtmpを指定する。サイズは32ビットに固定(3
2/64から選択)とする。乗算は符号なしで行われ、積の
サイズは被乗数のサイズの2倍になる。 [MULXのオペレーション] MULXでは、得るべき結果がdest,tmpの二つあるので、
両者が重なった場合(destでtmpと同じレジスタを指定
した場合)の処置が問題となる。一般に、tmp(MULXの
上位桁)の方は次の桁への桁上がりとして用いられるこ
とが多いので、最終桁の計算などでは使用しないことも
ある。したがって、両者が重なった場合には、destに設
定すべき値(MULXの下位桁)の方が残るものとする。
(付録12参照) MULXのM_flag,Z_flagのフラグ変化は、destを基準と
する。tmpに設定される値は、これらのフラグには影響
しない。このような仕様になったのは、次のような理由
による。 ・ADDX,SUBXなどのフラグ変化の仕様に合わせたため。
(ADDX,SUBXでは、X_flagがセットされていても、dest
が0であればZ_flagがセットされる。) ・多倍長演算を考えた場合には、tmp&destのみでフラ
グを変化させてもあまり意味がない。フラグ本来の意味
で変化させるためには、全体の値を通して判定すること
が必要であり、個々の命令だけでは対処できない。tmp
&destでフラグ変化を行なったとしても、結局中途半端
である。 例: [実行前][実行後] なお、MULX,DIVXでは、ADDX,SUBXとは異なり、Z_flagは
累積した変化をするわけでない。 F_flagによってtmp=0のテストが可能である。 !=0の場合は、動作を保証しない。 実際「本発明装置」では!=0の場合、srcサイズ
を、!R(8ビットまたは16ビット)としてオペランドの
フェッチを行ない、それを32ビットに符号拡張して命令
が実行される。 ただし、dest,tmpは!Rによらず常に32ビットとして扱
われる。 【プログラム例外】 ・予約命令例外 ・!R=‘11'のとき 注)!=0のときは予約命令例外としては検出しない。 ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 DIV src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第87図に示す。 【フラグ変化】 第88図に示す。 【解説】 ソースオペランドでデスティネーションオペランドを割
る。除算は符号付きで行われ、オペランドも符号付き整
数とみなされる。 この命令は、被除数のサイズと結果のサイズが等しい
ため、高級言語向きである。 商は0方向に丸められ、余りの符号は被除数と同じに
なる。 例: 10/3 → 商=3, 剰余=1 (−10)/3 →商=(−3), 剰余=(−1) 10/(−3) →商=(−3), 剰余=1 src=0の場合には、ゼロ除算例外(ZDE)となる。ゼロ
除算の場合、V_flagがセットされて例外処理が起動され
るが、destの値は変化しない。このとき、destのライト
アクセスを行なうかどうか、すなわち、同じ値を書き込
むか、何も書き込まないかは規定しないものとする。ま
た、V_flag以外のフラグも変化しない。これは、destに
合わせたため、および、例外処理プログラムで例外発生
要因を解析するためには、できるだけ以前の状態(フラ
グを含めて)が保存されている方が望ましいためであ
る。 DIVで0除算以外の場合にオーバーフローが発生する
のは(最小負数)÷(−1)の場合のみである。DIVはD
IVXとは異なり、コンパイラの生成する普通の演算命令
であるため、できるだけ他の演算命令と同じ仕様にする
方が望ましい。そこで、この場合のフラグの変化は、そ
れぞれのフラグの意味を生かして、 V_flag=1,L_flag=0,M_flag=1,Z_flag=0 {最小負数÷(−1)の時} とする。オーバーフローするのは(最小負数÷(−
1))に限るので、正しい結果の下位ビットがdestにセ
ットされると考えても、結局destは変化しない。正しい
結果の下位ビットになったと考えても結局同じ値であ
る。 例:【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき ・ゼロ除算例外 ・src=0のとき 【ニモニック】 DIVU src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第89図に示す。 【フラグ変化】 第90図に示す。 【解説】 ソースオペランドでデスティネーションオペランドを
割る。除算は符号なしで行われ、オペランドも符号なし
整数とみなされる。 src=0の場合には、ゼロ除算例外(ZDE)となる。ゼ
ロ除算の場合、V_flagがセットされて例外処理が起動さ
れるが、destは変化しない。このとき、destのライトア
クセスを行なうかどうか、すなわち、同じ値を書き込む
か、何も書き込まないかは規定しないものとする。ま
た、V_flag以外のフラグも変化しない。これは、destに
合わせたため、および、例外処理プログラムで例外発生
要因を解析するためには、できるだけ以前の状態(フラ
グを含めて)が保存されている方が望ましいためであ
る。 DIVU命令では、0除算以外の場合に、オーバーフロー
が発生してV_flagがセットされることはない。したがっ
て、0除算以外の場合は必ずV_flagがクリアされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき ・ゼロ除算例外 ・src=0のとき 【ニモニック】 DIVX src,dest,tmp 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第91図に示す。 【フラグ変化】 第92図に示す。 【解説】 ソースオペランドでデスティネーションオペランドを
割る。この命令は、多倍長除算のプリミティブとなるた
め、srcとdestのほかに、拡張演算のためのテンポラリ
値(剰余)を置くレジスタを指定する。サイズは32ビッ
トに固定(32/64から選択)とする。除算は符号なしで
行われ、被除数のサイズは除数のサイズの2倍になる。 [DIVXのオペレーション] DIVXでは、得るべき結果がdest,tmpの二つあるので、
両者が重なった場合(destでtmpと同じレジスタを指定
した場合)の処置が問題となる。一般に、tmp(DIVXの
剰余)の方は次の桁への桁下がりとして用いられること
が多いので、最終桁の計算などでは使用しないこともあ
る。したがって、両者が重なった場合には、destに設定
すべき値(DIVXの商)の方が残るものとする。 なお、DIVXは被除数が多倍長の場合に使用できる命令
であるが、除数が多倍長になった場合には、DIVXが使用
できず、プログラムによってシフトや減算を繰り返しな
がら割り算を進めなければならない。この際、多倍長の
シフト演算が必要になる。多倍長のシフトを実現するた
め、X_flagを通したローテイト命令(SHXR,SHXL)が用
意されている。 DIVXのM_flag,Z_flagのフラグ変化は、dest(商)を
基準とする。tmpに設定される値(剰余)は、これらの
フラグには影響しない。ただし、F_flagによってtmp=
0のテストが可能である。 MULX,DIVXではADDX,SUBXとは異なり、Z_flagは累積した
変化をするわけではない。 DIVXで結果がオーバーフローした場合、MOV,ADD,SUB,
MULでのオーバーフローと仕様を合わせるという意味で
は、正しい結果の下位ビットがdestに設定されるのが望
ましい。しかし、ADD,SUBのように、オーバーフローの
時も自然に正しい結果の下位ビットが得られるものと違
って、除算の場合には上位ビットから計算を行なうた
め、アルゴリズムの関係で正しい結果の下位ビットを得
るのが難しい。したがって、DIVXのオーバーフローの場
合には、destを変化させないという仕様にする。 DIVXで商がdestに入らず、オーバーフローが発生した
場合には、V_flag以外のフラグは変化しない。これは、
DIVXでオーバーフローが発生した場合に、destが変化し
ないことに合わせたものである。 src=0の場合には、ゼロ除算例外(ZDE)となる。ゼ
ロ除算の場合dest,tmpは変化しない。このとき、destの
ライトアクセスを行なうかどうか、すなわち、同じ値を
書き込むか、何も書き込まないかは規定しないものとす
る。また、V_flag以外のフラグも変化しない。これは、
destに合わせたため、および、例外処理プログラムで例
外発生要因を解析するためには、できるだけ以前の状態
(フラグを含めて)が保存されている方が望ましいため
である。 !=0の場合は、動作を保証しない。 実際「本発明装置」では!=0の場合、srcサイズを、!
R(8ビットまたは16ビット)としてオペランドのフェ
ッチを行ない、それを32ビットに符号拡張して命令が実
行される。 ただし、dest,tmpは!Rによらず常に32ビットとして扱
われる。 【プログラム例外】 ・予約命令例外 ・!R=‘11'のとき 注)!=0のときは予約命令例外としては検出しない。 ・EaRが@−SPのとき ・EaMRが#imm_data,@SP+,@−SPのとき ・ゼロ除算例外 ・src=0のとき 【ニモニック】 REM src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第93図に示す。 【フラグ変化】 第94図に示す。 【解説】 ソースオペランドでデスティネーションオペランドを
割り、その剰余を求める。除算は符号付きで行われ、オ
ペランドも符号付き整数とみなされる。 この命令は、被除数のサイズと剰余のサイズが等しい
ため、高級言語向きである。 商は0方向に丸められ、余りの符号は被除数と同じにな
る。 例: 10/3 → 商=3, 剰余=1 (−10)/3 →商=(−3), 剰余=(−1) 10/(−3) →商=(−3), 剰余=1 src=0の場合には、ゼロ除算例外(ZDE)となる。た
だし、REMで0除算を行なった場合には、オーバーフロ
ーをクリアして例外処理を起動するようにする。REM命
令では、DIV命令とは異なり、0除算をしてもdest(剰
余)がオーバーフローするわけではないので、V_flagは
クリアしておく方が合理的である。また、V_flagをクリ
アしておくと、例外処理の中でDIVによるエラーかREMに
よるエラーかが判定しやすい。 0除算の場合、destは無変化である。destに対してメ
モリアクセスを行なうか(readまたは同じ値でread−mo
dify−write)、アクセスを行なわないか、について
は、インプリメント方法を縛ることになるので、規定し
ない。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき ・ゼロ除算例外 ・src=0のとき 【ニモニック】 REMU src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第95図に示す。 【フラグ変化】 第96図に示す。 【解説】 ソースオペランドでデスティネーションオペランドを
割り、その剰余を求める。除算は符号なしで行われ、オ
ペランドも符号なし整数とみなされる。srcとdestのサ
イズの違う場合にはゼロ拡張が行なわれる。 この命令は、被除数のサイズと剰余のサイズが等しい
ため、高級言語向きである。 src=0の場合には、ゼロ除算例外(ZDE)となる。0
除算の場合の処置はREMと同様である。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき ・ゼロ除算例外 ・src=0のとき 【ニモニック】 NEG dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第97図に示す。 【フラグ変化】 第98図に示す。 【解説】 オペランドの符号を反転する。 L_flag 命令実行後のdestの値が負のとき、すなわち
destの初期値が正のときセットされる。 M_flag 命令実行後のdestのMSBが1のとき、すなわ
ちdestの初期値が正または最小負数のときセットされ
る。 Z_flag 命令実行後のdestの値が0のとき、すなわち
destの初期値が0のときセットされる。 V_flag destの初期値が最小負数(MSBのみ1で他の
ビットはall 0)のみセットされる。 【プログラム例外】 ・予約命令例外 ・MM=‘11'のとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 INDEX indexsize,subscript,xreg 【命令の機能】 calculate address of array 多次元配列のアドレス計算 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第99図に示す。 【フラグ変化】 第100図に示す。 【解説】 多次元配列を一次元配列に展開するためのアドレス計
算として、スケールの乗算とインデクスの加算を行な
う。 subscriptのサイズがxregのサイズよりも小さい時
は、subscriptが符号拡張される。xreg,indexsize,subs
criptは符号付きの整数と考え、乗算および加算は符号
付きで行なう。乗算または加算でオーバーフローを検出
した場合には、V_flagをセットする。 indexsizeは固定値(immediate)を済むことが多いが、
メモリ上に配列のディスクリプタを作ることを考え、汎
用アドレッシングとしている。 INDEX命令がCHK命令の後で実行されるならば、subscr
iptはレジスタのみの指定でよい。しかし、高級言語の
仕様によっては範囲をチェックしない(CHK命令を実行
しない)こともあるので、メモリ上の変数をsubscript
として使用できるように、subscriptも汎用アドレッシ
ングとしている。 [INDEXのオペレーション] xreg*indexsize+subscript==>xreg INDEX命令では、オペランドxreg,indexsize,subscrip
tは、すべてポインタではなく符号付きの数として扱わ
れる。負であってもそのまま演算し、EITなどの特別な
動作はしない。また、フラグ変化(V_flag,L_flag,M_fl
ag,Z_flag)も一般の算術演算命令に準じたものになっ
ている。これに関して若干補足しておく。 INDEXで扱うオペランドは、ポインタというよりも配
列のインデクスであり、INDEXでは配列のインデクスを
一次元に展開するという処理を行なう。インデクスがポ
インタになるのは、付加モードのスケーリングで(×
4)などを行なった後である。したがって、INDEXで扱
うデータを符号付きと考えても特に不自然はないし、イ
ンデクスが負になると困るような言語では、それをチェ
ックすることもできる。 !=0のときは、動作を保証しない。 実際「本発明装置」では!=0の場合、indexsizeサ
イズを!R(8ビットまたは16ビット)としてオペランド
のフェッチを行ない、それを32ビットに符号拡張して命
令が実行される。ただし、xregは!Rによらず常に32ビッ
トとして扱われる。 【プログラム例外】 ・予約命令例外 ・!R=‘11'のとき ・SS=‘11'のとき 注)!=‘0'のときは予約命令例外としては検出しな
い。 ・EaR,EaR2が@−SPのとき 12−4.論理演算命令 【ニモニック】 AND src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第101図に示す。 【フラグ変化】 第102図に示す。 【解説】 ソースオペランドとデスティネーションオペランドと
の論理積をとる。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズと異なる異種サイズ間の演算(AND:GのR
R≠MM、AND:EのMM≠00)になった場合、命令はそのまま
実行され、予約命令例外とはならないが、destに設定さ
れる結果は保証できない(インプリメント依存になる)
ものとする。「本発明装置」の仕様としては、異種サイ
ズ間の論理演算を規定していないので、この機能をソフ
トウエアで利用してはいけない。異種サイズ間の論理演
算はあまり意味のない命令であるが、これを予約命令例
外としないのは、インプリメントの負担が大きく、実行
速度に影響が出るためである。 M_flag R0 Z_flag [R0〜d−1]=0 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 OR src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第103図に示す。 【フラグ変化】 第104図に示す。 【解説】 ソースオペランドとデスティネーションオペランドと
の論理和をとる。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズと異なる異種サイズ間の演算(OR:GのRR
≠MM、OR:EのMM≠00)になった場合、命令はそのまま実
行され、予約命令例外とはならないが、destに設定され
る結果は保証できない(インプリメント依存になる)も
のとする。 M_flag R0 Z_flag [R0〜d−1]=0 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 XOR src,dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第105図に示す。 【フラグ変化】 第106図に示す。 【解説】 ソースオペランドとデスティネーションオペランドと
の排他的論理和をとる。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズと異なる異種サイズ間の演算(XOR:GのR
R≠MM、XOR:EのMM≠00)になった場合、命令はそのまま
実行され、予約命令例外とはならないが、destに設定さ
れる結果は保証できない(インプリメント依存になる)
ものとする。 M_flag R0 Z_flag [R0〜d−1]=0 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 NOT dest 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第107図に示す。 【フラグ変化】 第108図に示す。 【解説】 オペランドの各ビットの1と0を反転する。 M_flag 命令実行後のdestのMSBが1のとき、すなわ
ちdestの初期値のMSBが0のときセットされる。 Z_flag 命令実行後のdestの値が0のとき、すなわち
destの初期値が0のときセットされる。 【プログラム例外】 ・予約命令例外 ・MM=‘11'のとき ・EaMが#imm_data,@SP+,@−SPのとき 12−5.シフト命令 【ニモニック】 SHA count,dest 【命令の機能】 shift arithmetic 算術シフト 【命令オプシヨン】 なし 【命令ビットパターンとアセンブラ表記】 第109図に示す。 【フラグ変化】 第110図に示す。 【解説】 デスティネーションオペランドdestをソースオペラン
ドcountで指定されたビット数だけ算術シフトする。一
般形の命令では、countの符号によってシフト方向を指
定する。countが正の時左シフト、負の時右シフトとな
る。 算術シフトであるため、右シフトの場合にはデスティ
ネーションのMSB(符号ビット)が変化せず、同じ値が
右側のビットにコピーされていく。左シフトの場合に
は、LSBに0が入り、0が左側のビットにコピーされて
いく。 正負によるシフト方向の指定は、浮動小数点演算のエ
ミュレーションなどに有効な場合がある。 左シフトの場合はSHAの短縮形がないが、フラグ変化
がSHAと異なってもよければ、SHLの短縮形SHL:Qで代用
できる。 [左シフト(count>0)の場合] 第111図に示す。 [右シフト(count<0)の場合] 第112図に示す。 なお、count=0の場合は、X_flag=0となる。 SHA命令では、countのサイズとして8ビットのみが有
効である。RR≠00の場合動作を保証しない。RR≠00の機
能が利用できないのは、主としてインプリメント上の制
約によるものである。 RR≠00の場合には、「本発明装置」では、サイズRRで
countオペランドのフェッチを行ない、countの下位8ビ
ットのみを有効としてそのまま命令を実行する。 SHAは算術演算なのでL_flagをセットするが、これはd
estのはじめの値の符号(MSB)を反映する。これは、L_
flagが、オーバーフローやアンダーフローが発生した場
合にも、常に正しい計算結果の符号を反映するという性
質を持っているためである。シフト命令の場合、オーバ
ーフローが起こらなければ、destの符号は変化しない。
右シフトの場合、または左シフトでオーバーフローがな
かった場合にはL_flag=M_flagとなるが、左シフトでオ
ーバーフローが発生した場合には、L_flagとM_flagが異
なる変化をすることがある。 「本発明装置」はbig−endianのチップであるため、c
ountをビット位置の増減の意味で考えるか、2の累乗の
意味で考えるかによって、シフト方向が逆になってしま
う。すなわち、前者の考え方ではcount>0の時右シフ
トとすべきであるのに対して、後者の考え方では、litt
le−endianの場合と同じように、count>0の時左シフ
トとなる。しかし、シフト命令はビット操作関係の命令
よりも算術演算関係の命令に近いものであるから、coun
tをビット位置の増減の意味で考えるよりは、2の累乗
の意味で考える方が自然である。したがって、「本発明
装置」ではcount>0の時左シフトという仕様になって
いる。 SHL,SHAでは、countの絶対値が(destのサイズ+1)
を越えた場合にも、指定された数だけそのままシフトを
続ける。結果的に、countの絶対値が(destのサイズ+
1)の場合と同じ動作になる。例えば、次のような動作
をする。 SHA #33,dset.W ;dest =X_flag=0 SHL #33,dest.W ;dest =X_flag=0 SHA #33,dset.W ;dest =X_flag=旧destのMSB SHL #33,dest.W ;dest =X_flag=0 なお、X_flagを除けば、countの絶対値が(destのサ
イズ)に等しい場合も同じ結果になる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaM,ShMが#imm_data,@SP+,@−SPのとき 【ニモニック】 SHL count,dest 【命令の機能】 shift logical 論理シフト 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第113図に示す。 【フラグ変化】 第114図に示す。 【解説】 デスティネーションオペランドをソースオペランドco
untで指定されたビット数だけ論理シフトする。一般形
の時、シフト方向はcountの符号で指定する。countが正
の時左シフト、負の時右シフトとなる。 右シフトの場合には、MSBに0が入り、0が右側のビ
ットにコピーされていく。また、左シフトの場合には、
LSBに0が入り、0が左側のビットにコピーされてい
く。 [左シフト(count>0)の場合] 第115図に示す。 [右シフト(count<0)の場合] 第116図に示す。 なお、count=0の場合は、X_flag=0となる。 SHL命令では、countのサイズとして8ビットのみが有
効である。RR≠00の場合、動作を保証しない。RR≠00の
機能が利用できないのは、主としてインプリメント上の
制約によるものである。RR≠00の場合には、「本発明装
置」ではサイズRRでcountオペランドのフェッチを行な
い、countの下位8ビットのみを有効としてそのまま命
令を実行する。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaM,ShMが#imm_data,@SP+,@−SPのとき 【ニモニック】 ROT count,dest 【命令の機能】 rotate 回転 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第117図に示す。 【フラグ変化】 第118図に示す。 【解説】 デスティネーションオペランドをソースオペランドco
untで指定されたビット数だけ回転する。すなわち、LSB
(MSB)から溢れたビットをMSB(LSB)に詰めながらシ
フトを行なう。 回転方向はcountの符号で指定する。countが正の時左
回転、負の時右回転となる。 回転の際、フラグは通さない。 [左回転(count>0)の場合] 第119図に示す。 [右回転(count<0)の場合] 第120図に示す。 なお、count=0の場合は、X_flag=0となる。 ROT命令では、countのサイズとして8ビットのみが有
効である。RR≠00の場合、動作を保証しない。RR≠00の
機能が利用できないのは、主としてインプリメント上の
制約によるものである。RR≠00の場合には、「本発明装
置」ではサイズRRでcountオペランドのフェッチを行な
い、countの下位8ビットのみを有効としてそのまま命
令を実行する。 ROTでcountの絶対値が(destのサイズ)を越えた場合
にも、指定された数だけそのままローテイトを続ける。
結果的に、countを(destのサイズ)で割った剰余をcou
ntとした場合と同じ動作になる。ただし、countが(des
tのサイズ)の整数倍(≠0)の場合には、MSBまたはLS
Bに応じてX_flagのセットされる点が、count=0の場合
とは異なる。例えば、データサイズと同じビット数だけ
回転した場合、データの値そのものは変化せず、destは
count=0の時と同じ値になる。しかし、フラグにはも
とのデータのLSBがコピーされるため、フラグ変化はcou
nt=0の時とは異なったものになる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき 【ニモニック】 SHXL dest 【命令の機能】 shift left with extend 拡張左シフト 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第121図に示す。 【フラグ変化】 第122図に示す。 【解説】 destを1ビット左にシフトし、元のX flagの内容をLS
Bに詰める。MSBからあふれたビットはX flagに入る。こ
の命令は、複数ワードの1ビットシフトを行なうための
プリミティブとして専用化したものであり、シフト対象
のサイズを32ビットに固定している点、1ビットのシフ
トしかできない点、などにおいてSHA,SHL,ROTとはかな
り仕様が異なる。 DIVXは被除数が多倍長の場合に使用できる命令である
が、除数が多倍長になった場合には、DIVXが使用でき
ず、プログラムによってシフトや減算を繰り返しながら
割り算を進めなければならない。その際、多倍長のシフ
ト演算が必要になる。この命令は、このような場合に使
用することを目的とした命令である。第123図にこれを
示す。 【プログラム例外】 ・予約命令例外 ・+=‘0'のとき ・−=‘1'のとき ・X=‘1'のとき ・EaMXが#imm_data,@SP+,@−SPのとき 【ニモニック】 SHXR dest 【命令の機能】 shift righ with extend 拡張右シフト 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第124図に示す。 【フラグ変化】 第125図に示す。 【解説】 destを1ビット右にシフトし、元のX flagの内容をMS
Bに詰める。LSBからあふれたビットはX flagに入る。こ
の命令は、複数ワードの1ビットシフトを行なうための
プリミティブとして専用化したものであり、シフト対象
のサイズを32ビットに固定している点、1ビットのシフ
トしかできない点、などにおいてSHA,SHL,ROTとはかな
り仕様が異なる。 DIVXは被除数が多倍長の場合に使用できる命令である
が、除数が多倍長になった場合には、DIVXが使用でき
ず、プログラムによってシフトや減算を繰り返しながら
割り算を進めなければならない。その際、多倍長のシフ
ト演算が必要になる。この命令は、このような場合に使
用することを目的とした命令である。第126図にこれを
示す。 【プログラム例外】 ・予約命令例外 ・+=‘0'のとき ・−=‘1'のとき ・X=‘1'のとき ・EaMXが#imm_data,@SP+,@−SPのとき 【ニモニック】 RVBY src,dest 【命令の機能】 reverse byte order バイト順の逆転 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第127図に示す。 【フラグ変化】 第128図に示す。 【解説】 srcのバイト順を逆転したものをdestに転送する。 srcよりもdestのサイズの方が大きい場合には、srcを
destのサイズにまでゼロ拡張した後、destのサイズでバ
イト順を逆転する。 srcよりもdestのサイズの方が小さい場合には、srcの
上位バイトをカットしてdestのサイズとした後、destの
サイズでバイト順を逆転する。(srcのアドレスをずら
した上でsrcとdestを同じサイズとしても、結果は同じ
になる) 例: この命令は、endianの変換に対するオーバーヘッドを
削減することを目的とした命令である。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・WW=‘11'のとき ・EaRが@−SPのとき ・EaWが#imm_data,@SP+のとき 【ニモニック】 RVBI src,dest 但し<<L2>> 【命令の機能】 reverse bit order ビット順の逆転 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第129図に示す。 【フラグ変化】 第130図に示す。 【解説】 srcのビット順を逆転したものをdestに転送する。 srcよりもdestのサイズの方が大きい場合には、srcを
destのサイズにまでゼロ拡張した後、destのサイズでビ
ット順を逆転する。 srcよりもdestのサイズの方が小さい場合には、srcの
上位バイトをカットしてdestのサイズとした後、destの
サイズでビット順を逆転する。(srcのアドレスをずら
した上でsrcとdestを同じサイズとしても、結果は同じ
になる) この命令は、endianの変換に対するオーバーヘッドを
削減することを目的とした命令である。ビットマップの
処理を考えると、ビットを逆順にするビットリバース命
令RVBIもあった方がよいが、バイトリバース命令RVBYよ
りも頻度が少ないこと、追加のハードウエアが必要とな
る可能性が強いこと、により、RVBI命令は<<L2>>と
する。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・WW=‘11'のとき ・EaRが@−SPのとき ・EaWが#imm_data,@SP+のとき 12−6.ビット操作命令 「本発明装置」のビット操作命令では、次の図のよう
に base(base address) offset(bit address) の2つのパラメータにより操作対象となるビットを指定
する。レジスタ上のビットを操作する場合には、このほ
かにbaseのサイズも対象ビットの指定に影響する。 [メモリ上のビット操作をする場合] 第131図に示す。 「本発明装置」の一般形のビット操作命令では、offs
etの値に制限がなく、offsetがバイト境界を越えてもよ
いようになっている。offsetは、符号付き整数として扱
われる。 ビット操作命令では、BBフィールドによりメモリアク
セスの範囲を指定できるようになっている。これは、BT
STでreadを行なうメモリアドレスの範囲、およびBSET,B
CLR,BNOTでread−modify−writeを行なうメモリアドレ
スの範囲を意味するものである。アクセスされるメモリ
アドレスの範囲は、入出力やマルチプロセッサを使用し
た場合に問題となることがある。 しかし、実際には、バイト単位のアクセス(‘.B')
のみが使用できればほとんどの場合に十分であるため、
ハーフワード、ワード単位のアクセスは<<L2>>とす
る(ただしレジスタに対するビット操作命令を除く)。
また、ハーフワード、ワード単位のアクセスが意味を持
つのは、アライメントのとれたハーフワードやワードを
アクセスする場合に限られているので、ハーフワード、
ワード単位のアクセスの機能を利用するめには、baseと
して必ずアライメントのとれたアドレスを指定しなけれ
ばならないという制限を設ける。これは、アクセス範囲
の指定に関するインプリメントを容易にするためであ
る。したがって、アライメントのとれたハーフワードの
単位で、対象ビットを含むメモリアクセスを行ないたい
場合には、baseとして2の倍数を指定する必要がある。
また、アライメントのとれたワードの単位で、対象ビッ
トを含むメモリアクセスを行ないたい場合には、baseと
して4の倍数を指定する必要がある。offsetの値につい
ては制限はない。baseとしてアライメントのとれていな
いアドレスを指定した場合のアクセス範囲は、インプリ
メントに依存するものとする。 「本発明装置」では、<<L2>>となっているメモリ
に対するハーフワード、ワード単位のアクセスのインプ
リメントを行なう。またbaseとしてアライメントのとれ
ていないアドレスを指定した場合にも、アクセス範囲は
アライメントのとれたハーフワード、ワード単位でアク
セスを行なう。 [例] BSET.B #H′84,@H′100 offset %8=4;base+offset/8=H′110なので、
H′110のbit4をセットする。 H′110の1バイトについてread−modify−writeが行
なわれる。 BSET.B #H′7c,@H′101 offset %8=4;base+offset/8=H′110なのでアク
セスサイズがバイトなので、BSET.B #H′84,@H′10
0と全く同じ動作をする。 BSET.B #H′84,@H′100 offset %8=4;base+offset/8=H′110なので、
H′110のbit4をセットする。 baseが4の倍数になっているので、H′100〜H′103
のアライメントのとれた32ビットについてread−modify
−writeを行ない、対象ビットをセットする。 BSET.W #H′7c,@H′101 offset %8=4;base+offset/8=H′110なので、お
なじようにH′110のbit4をセットする。 しかし、baseが4の倍数ではないので、read−modify
−writeを行なうアクセス範囲についてはインプリメン
ト依存である。 なお、BBで示されるサイズは、「どの範囲に対してre
ad−modify−writeを行なうか?」ということであり、
オフセットの範囲(例えば、‘.B'であればオフセット
が8より小さくなる、など)を規定するものではない。 レジスタに対するビット操作命令では、アクセスのサ
イズ(baseのサイズ)によってoffset=0(MSB)のビ
ット位置が変わるため、baseのサイズは重要な意味を持
つ。baseがレジスタ直接Rnの場合は、baseのサイズ‘.
H',‘.W'も<<L1>>である。 レジスタRnをbaseとしたビット操作命令の場合、offs
etは‘.B'の時下位3ビット、‘.H'の時下位4ビット、
‘.W'の時下位5ビット、‘.L'の時下位6ビットのみが
有効であり、上位ビットは無視される。上位ビットが0
でなくても、エラー、EITとはしない。アーキテクチャ
面から見ると、上位ビットを無視するよりも、BF命令の
widthなどと同じように、きちんとoffsetの範囲をチェ
ックする方が望ましいが、チェックを行なうことにより
命令の実行時間が増大するため、offsetはアクセスサイ
ズのビット数でmoduloをとって使用することにしてい
る。 レジスタ上に8ビットデータ、16ビットデータ、32ビ
ットデータを置いて場合では、それぞれのデータで同じ
ビット位置を持つビットであっても、実際には異なった
ビットに対応することになるので、注意が必要である。
仕様が複雑化するのを避けるため、アセンブラのデフォ
ルトはメモリ対象、レジスタ対象とも.Bとする。また、
短縮形も.Bの仕様である。したがって、短縮形でアクセ
スできるレジスタ上の範囲は、2^0〜2^7のビットである
(第132図参照)。 [例] BSET:Q#1,r0では、BSETの場合にデフォルト
が.Bなので、r0.Bのビット1がセットされる。 このビットは、r0.Wのビット1とは異なったものであ
り、r0.Wのビット25に対応する。 例えば、2^17のビットをアクセスするつもりで BTST #14,R0 と書くと、実際は BTST.B#14,R0 と解釈され、offsetは上位ビットを無視するので、結局
2^1のビットが対象となる。正しくは、 BTST.W#14,R0 と書かなければならない。このような場合には、アセン
ブラで警告を出すのが望ましいであろう。 【ニモニック】 BTST offset,base 【命令の機能】 ~bit−>Z_flag ビットのテスト 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第133図に示す。 【フラグ変化】 第134図に示す。 【解説】 指定されたビットの値を反転したものをZ_flagにコピ
ーする。 EaRf,ShRfqで指定されるアドレッシングモードでは、
イミディエートモード#imm_data、@−SP、@SP+は使
用できない。また、Rnのモードを使用した場合、offset
の上位ビットの値は無視される。 アセンブラ表記では、メモリアクセスのサイズをbase
のサイズとして指定する。BTST:Qでは、メモリアクセス
のサイズは8ビットに固定されており、サイズは‘.B'
のみを書くことができる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・BB=‘11'のとき ・EaRが@−SPのとき ・EaRf,ShRfqが#imm_data,@SP+,@−SPのとき 【ニモニック】 BSET offset,base 【命令の機能】 ~bit−>Z_flag,1−>bit ビットのセット 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第135図に示す。 【フラグ変化】 第136図に示す。 【解説】 指定されたビットの値を反転したものをZ_flagにコピ
ーし、その後そのビットを1にセットする。 EaMf,ShMfqで指定されるアドレッシングモードでは、
イミディエートモード#imm_data、@−SP,@SP+は使
用できない。また、Rnのモードを使用した場合、offset
の上位ビットの値は無視される。 アセンブラ表記では、メモリアクセスのサイズをbase
のサイズとして指定する。BSET:Qでは、メモリアクセス
のサイズは8ビットに固定されており、サイズは‘.B'
のみを書くことができる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・BB=‘11'のとき ・EaRが@−SPのとき ・EaMf,ShMfqが#imm_data,@SP+,@−SPのとき 【ニモニック】 BCLR offset,base 【命令の機能】 ~bit−>Z_flag,0−>bit ビットのクリア 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第137図に示す。 【フラグ変化】 第138図に示す。 【解説】 指定されたビットの値を反転したものをZ_flagにコピ
ーし、その後そのビットを0にクリアする。 EaMf,ShMfqで指定されるアドレッシングモードでは、
イミディエートモード#imm_data、@−SP、@SP+は使
用できない。また、Rnのモードを使用した場合、offset
の上位ビットの値は無視される。 アセンブラ表記では、メモリアクセスのサイズをbase
のサイズとして指定する。BCLR:Qでは、メモリアクセス
のサイズは8ビットに固定されており、サイズは‘.B'
のみを書くことができる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・BB=‘11'のとき ・EaRが@−SPのとき ・EaMf,ShMfqが#imm_data,@SP+,@−SPのとき 【ニモニック】 BNOT offset,base 【命令の機能】 ~bit−>Z_flag,~bit−>bit ビットの反転 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第139図に示す。 【フラグ変化】 第140図に示す。 【解説】 指定されたビットの値を反転したものをZ_flagにコピ
ーし、その後そのビットも反転する。 EaMfで指定されるアドレッシングモードでは、イミデ
ィエートモード#imm_data、@−SP,@SP+は使用でき
ない。また、Rnのモードを使用した場合、offsetの上位
ビットの値は無視される。 アセンブラ表記では、メモリアクセスのサイズをbase
のサイズとして指定する。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・BB=‘11'のとき ・EaRが@−SPのとき ・EaMfが#imm_data,@SP+,@−SPのとき 【ニモニック】 BSCH date,offset 【命令の機能】 find first‘0'or‘1'in the bitfield(within a wo
rd) 0または1のサーチ(1ワード内) 【命令オプション】 /0 ‘0'をサーチ(デフォルト) /1 ‘1'をサーチ /F ビット番号の増加方向にサーチ(デフォルト) /B ビット番号の減少方向にサーチ<<L2>>(M32
でサポートする) 【命令ビットパターンとアセンブラ表記】 第141図に示す。 【フラグ変化】 第142図に示す。 【解説】 ワード中にある‘0'または‘1'のビットをサーチす
る。 サーチを開始するビット番号(bit offset)をoffset
オペランドにセットしてこの命令を実行すると、命令実
行後、サーチ結果のビット番号がoffsetオペランドにセ
ットされている。offsetはread−modify−writeとなっ
ている。offsetをread−modify−writeの形にしたの
は、ビットの検索を繰り返して行なうことを想定したた
めである。 サーチの行なわれるビット位置の範囲は、dataオペラ
ンドの0〜(dataのサイズ)に限られており、ワード境
界を越えることはできない。 offsetとしてはすべてのサイズが使用可能であるが、
offsetの初期値の上位ビットはサーチの際には無視され
る。これは、上位ビットに、ワード境界を越えた分のビ
ットオフセットや実効アドレスなどといった、別の情報
が入っていることが多いと考えられるためである。ま
た、BSCHの仕様を軽くして高速化するためである。な
お、/Fの時dataのサイズを表わす数、/Bの時(−1)と
なる。「上位ビット」とは、log2(dataのビット数)よ
りも上位のビットを示す。dataが32ビットであれば、2^
5〜2^31のビットが上位ビットである。 サーチはビット番号の大きな方向へ向かって、つま
り、big−endianの「本発明装置」ではLSBの方向へ向か
って行なわれるのが標準の仕様<<L0>>であり、/Fオ
プションにより実現される。逆方向のサーチ/Bオプショ
ンは<<L2>>仕様となっている。これは、正方向のサ
ーチと逆方向のサーチで全く別のハードウエアが必要な
ためである。また、サーチされるdataのサイズのうち、
8ビットと16ビット(RR=00,01)の指定は<<L2>>
となっている。「本発明装置」では、<<L2>>となっ
ている/Bオプション,8ビットと16ビットのデータサイズ
(RR=00,01)もサポートする。 BSCHはビット操作命令と同じ分類にしているが、かな
り異なった性質をもっている。BSCH命令でも、他のビッ
ト操作命令と同じようにオフセットを自由に設定できる
方が使いやすいという考え方があるが、その目的でBVSC
H命令が別に設けられているため、BSCHとしてはできる
だけ軽い仕様に絞り、オフセットの範囲を制限してい
る。オフセットの有効範囲は、他のビット操作命令でレ
ジスタ直接モードRnを指定した場合と同じ範囲である。
また、一般のビット操作命令ではoffsetがread−only、
baseがread−modify−writeとなっているのに対して、B
SCHではそれとは逆にoffsetがread−modify−write、da
ta(base address)がread−onlyとなっており、注意が
必要である。 BSCH/Fで、指定したビットが見付からなかった場合に
は、サーチを行なった最後のビット(ワード境界)の次
のビットのオフセットがセットされ、V_flag=1とな
る。サーチ失敗時にも、EITは起動しない。結果的に、
サーチを行なったビット数の分だけオフセットが加算さ
れる。 [例] BSCH/Bで、指定したビットが見付からなかった場合に
は、offsetに(−1)がセットされる。この場合もV_fl
agがセットされるが、EITは起動されない。 BSCH命令では、offsetの初期値の上位ビットは無視さ
れるが、命令終了後にセットされるoffset値(サーチ結
果)については、上位ビットまで意味を持つ値になって
いる。つまり、offsetの上位ビットに、ワード境界を越
えた分のビットオフセットや実効アドレスなどといった
別の情報が入っていても、BSCH命令実行後は、offsetの
上位ビットも書き換えられてしまうわけである。サーチ
成功の時はoffsetが0〜31の値をとる(dataが32ビット
の場合)ので、/F,/Bとも上位ビットは常に0となる。
また、/Fでサーチ失敗の場合はoffset=32となるため、
上位ビットが00……001に、下位ビットが00000になる。
/Bでサーチ失敗の場合はoffset=(−1)となるため、
上位ビットが11……111に、下位ビットが11111になる。 [例]【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaWが#imm_data,@SP+,@−SPのとき 12−7.固定長ビットフィールド操作命令 「本発明装置」の一つのデータタイプであるビットフ
ィールドは、ビットフィールド中のMSBの位置、および
ビットフィールドの長さ(width)により指定される。
ビットフィールドのMSBの位置は、baseとoffsetとの組
で示される。baseで示されるメモリのMSB(第0bit)がo
ffset=0になる。offsetの意味は、ビット操作命令の
時と同じである。ビットフィールドとbase、offset、wi
dthとの関係を下の図に示す。 [メモリ上のビットフィールド操作をする場合] 第143図に示すように太線内が対象ビットフィールド
である。 固定長ビットフィールドの操作命令(BFEXT,BFEXTU,BFC
MP,BFCMPU,BFINS,BFINSU)は、AI向き応用のタグ処理
(タグの比較やタグの切り出し)などに特に有効であ
る。 固定長ビットフィールド命令には、次の2つのフォーマ
ットがある。 ・offsetを8ビットの一般形アドレッシングモードで指
定し、widthをレジスタで指定する形式。これを‘:G'フ
ォーマットと呼ぶ。‘:G'フォーマットでは、baseにoff
set/8の値を加えることにより、実際にアクセスするメ
モリのアドレスが決まる。26bit以上のビットフィール
ドで5バイトにまたがるビットフィールドを扱うことも
できる。 ・offsetを8ビットのイミディエート値で指定し、widt
hをリテラルで指定する形式。これを‘:E'フォーマット
と呼ぶ。‘:E'フォーマットでは、ワード境界を越えな
いビットフィールドのみを対象として速度を上げるため
に、baseの1ワードからはみ出した部分のビットフィー
ルドについて、動作を保証しないものとしている。widt
h+offset≧sizeであってもEITは起動しないが、読みだ
し時、書き込み時とも値が不定となる。baseの1ワード
のみのアクセスでも命令仕様を実現することができるの
で、offsetとは無関係に、baseのみを見て操作対象とな
るビットフィールドのメモリアドレスを決めることが可
能である。したがって、インプリメント次第で命令実行
を高速化することもできる。 BF:EとBF:Gのbaseで許されるアドレッシングモード
は、全く同じである。 BFINS,BFINSU,BFCMP,BFCMPUでは、:G,:Eフォーマット
のそれぞれに対して、さらに次の二つの形式がある。 ・srcオペランドをレジスタで指定する:Rフォーマット ・srcオペランドをイミディエートで指定する:Iフォー
マット widthの値は、1〜32(<<LX>>では1〜64)に制
限されており、命令実行前に0<width≦32(64)のチ
ェックが行なわれる。width=0の場合もエラーであ
る。違反した場合には、不正オペランド例外(10E)と
なる。すべての命令について、offset,widthとも符号付
きの数として扱われる。ただし、widthはもともと1〜3
2(64)の値しか許されていないため、符号付きと考え
るか符号なしと考えるかは実際の動作には影響せず、仕
様書記述上の問題となっている。また、:Eフォーマット
の命令のoffsetも符号付きとして扱われ、この場合はof
fsetとして−128〜+127の数を表わすことになる。(た
だし、後で述べるように、:Eフォーマットではbaseのア
ドレスの1ワードbase〜base+3からハミ出すビットフ
ィールドについて、ハミ出した部分に関する動作を保証
していない。) BF命令のビットフィールドでない方のオペランドは、
普通の整数として扱われる。したがって、例えばBFEXT
の場合は、抽出されたビットフィールドがレジスタのLS
B側に詰めてセットされ、MSB方向に符号拡張される。ビ
ット位置=0(MSB)に合わせてビットフィールドをセ
ットするのではない。 baseとしてレジスタを対象とした場合には、ビットフ
ィールドは一つのレジスタの範囲内に限られる。レジス
タ対象の固定長ビットフィールド命令も「本発明装置」
でサポートする。ただしこれは<<L2>>となってい
る。これは、レジスタを対象としたビットフィールド操
作の場合、現段階では、BF:E命令よりもシフト命令とAN
D命令を組み合せて実行する方が速くなる可能性がある
ためである。レジスタ対象のビットフィールド命令(<
<L2>>)については、:Gでも次に述べる:Eと同じよう
に、1ワード(レジスタ)からハミ出すビットフィール
ドについて、ハミ出した部分に関する動作を保証しない
ものとする。BFEXT,BFEXTUでは不定値が得られ、BFINS,
BFINSUでは無視される。offset+width≧sizeの場合もE
ITは起動しない。 :Eフォーマットでは、対象となるビットフィールドの
うちで、sizeを越えたビットオフセットを持つ部分につ
いてのみ動作を保証していない。同様に、負のビットオ
フセットを持つ部分についても動作を保証していない。
いずれの場合も、指定されたビットフィールドのうち
で、baseのアドレスで示される1ワードに含まれる部分
については、正しく実行される。 [例] width,src,destのレジスタのサイズ指定は、Xフィー
ルドによって共通に行なわれる。サイズ指定フィールド
Xは、32ビット演算と64ビット演算(<<LX>>)の切
り換えを行なうものであるが、具体的には次の3つの意
味を持つ。 src(dest)レジスタのサイズ指定(:Rフォーマッ
ト) widthレジスタのサイズ指定(:Gフォーマット) widthの範囲の指定 X=0の時0<width≦32 X=1の時0<width≦64 :E:Iフォーマットの場合は意味を持たないが、
の区別を行なうためにやはりXフィールドを使用する。
すなわち、Xフィールドは、32ビットと64ビットの互換
性を高めるためのビットであると言える。 :Iフォーマットの命令でSS≠00の時には、#iS8のフ
ィールドは使用しない。この時、もし#iS8のフィール
ドが0になっていなくても、単に無視される。ただし、
マニュアル上は、#iS8のフィールドには0を入れるよ
うにしておく。 ビットフィールド命令のフォーマットと、それに対し
て使用できるサイズを列挙すると、第144図のようにな
る。 ビットフィールド命令についても、ビット操作命令と
同じようにアクセスを行なうメモリの範囲が問題となる
が、インプリメントへの依存性が強いので、強い規定は
設けない。[これについては詳細仕様調整中] 【ニモニック】 BFEXT offset,width,base,dest 【命令の機能】 extract bit field(signed) ビットフィールドの抽出(符号付き) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第145図に示す。 【フラグ変化】 第146図に示す。 【解説】 ビットフィールドの抽出を行ない結果をデスティネー
ションに転送する。 ビットフィールドのwidthよりもデスティネーション
のサイズの方が大きい時は、データが符号拡張される。
また、BFEXT:Gのoffsetも符号拡張される。 EaRbfのアドレッシングモードでは、@−SP,@SP+,
#imm_dataのモードは使用できない。baseのレジスタ直
接モードRnは<<L2>>であるが「本発明装置」ではサ
ポートする。 [オペレーション] destの初期値を[D0.D1....Dd−2.Dd−1] d=32,64 destに設定される値を[R0.R1....Rd−2.Rd−1] d=32,64 offset=o,width=w とする。offset,widthは符号付きとして扱われる。(wi
dth≦0,width>dの時はエラー) この時、抽出される部分のビットフィールドとフラグの
変化は、次のようになる。 「本発明装置」32であれば常にクリアされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・+=‘0'のとき ・X=‘1'のとき ・EaRが@−SPのとき ・EaRbfが#imm_data,@SP+,@−SPのとき ・不正オペランド例外 ・width≦0,width>32のとき 【ニモニック】 BFEXTU offset,width,base,dest 【命令の機能】 extract bit field(unsigned) ビットフィールドの抽出(符号なし) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第147図に示す。 【フラグ変化】 第148図に示す。 【解説】 ビットフィールドの抽出を行ない結果をデスティネー
ションに転送する。 ビットフィールドのwidthよりもデスティネーション
のサイズの方が大きい時は、データがゼロ拡張される。
ただし、BFEXTU:Gのoffsetは符号拡張される。 EaRbfのアドレッシングモードでは、@−SP,@SP+,
#imm_dataのモードは使用できない。baseのレジスタ直
接モードRnは<<L2>>であるが「本発明装置」ではサ
ポートする。 [オペレーション] destの初期値を[D0.D1....Dd−2.Dd−1] d=32,64 destに設定される値を[R0.R1....Rd−2.Rd−1] d=32,64 offset=o,width=w とする。offset,widthは符号付きとして扱われる。(wi
dth≦0,width>dの時はエラー) この時、抽出される部分のビットフィールドとフラグの
変化は、次のようになる。 「本発明装置」32であれば常にクリアされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・+=‘0'のとき ・X=‘1'のとき ・EaRが@−SPのとき ・EaRbfが#imm_data,@SP+,@−SPのとき ・不正オペランド例外 ・width≦0,width>32のとき 【ニモニック】 BFINS src,offset,width,base 【命令の機能】 insert bit field ビットフィールドの挿入(符号付き) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第149図に示す。 【フラグ変化】 第150図に示す。 【解説】 ソースの値をビットフィールドに挿入する。 ソースのサイズよりもビットフィールドのwidthの方
が大きい時は、データが符号拡張される。また、BFINS:
Gのoffsetも符号拡張される。 EaRbfのアドレッシングモードでは、@−SP,@SP+,
#imm_dataのモードは使用できない。baseのレジスタ直
接モードRnは<<L2>>であるが「本発明装置」ではサ
ポートする。 [オペレーション] srcの初期値を[S0.S1....Ss−2.Ss−1] s=8,16,32,64(:I) s=32,64(:R) offset=o,width=w とする。offset,widthは符号付きとして扱われる。(wi
dth≦0,width>dの時はエラー) この時、挿入される部分のビットフィールドとフラグの
変化は、次のようになる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・+=‘0'のとき ・X=‘1'のとき ・SS=‘11'のとき ・EaRが@−SPのとき ・EaMbfが#imm_data,@SP+,@−SPのとき ・不正オペランド例外 ・width≦0,width>32のとき 【ニモニック】 BFINSU src,offset,width,base 【命令の機能】 insert bit field ビットフィールドの挿入(符号なし) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第151図に示す。 【フラグ変化】 第152図に示す。 【解説】 ソースの値をビットフィールドに挿入する。 ソースのサイズよりもビットフィールドのwidthの方
が大きい時は、データがゼロ拡張される。一方、BFINS
U:Gのoffsetは符号拡張される。 EaRbfのアドレッシングモードでは、@−SP,@SP+,
#imm_dataのモードは使用できない。baseのレジスタ直
接モードRnは<<L2>>であるが「本発明装置」ではサ
ポートする。 [オペレーション] srcの初期値を[S0.S1....Ss−2.Ss−1] s=8,16,32,64(:I) s=32,64(:R) offset=o,width=w とする。offset,widthとも符号付きとして扱われる。
(width≦0,width>dの時はエラー) この時、挿入される部分のビットフィールドとフラグの
変化は、次のようになる。 srcの[S0.S1....Ss−w−1]がカットされる。 M_flag 対象ビットフィールドのMSB(Bo)の変化を
基準とする。または(w>sの時)0 (w=sの時)S0 (w<sの時)Ss−w Z_flag 対象ビットフィールドの[Bo〜o+w−1]
の変化を基準とする。または(w≧sの時)[S0〜s−
1]=src=0 (w<sの時)[Ss−w〜s−1]=0 V_flag☆ U[S0〜s−1]=src≧+2^w または(w≧sの時)0 (w<sの時)S0=S1=...Ss−w−1=0の時クリ
ア、それ以外の場合にセットとなる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・+=‘0'のとき ・X=‘1'のとき ・SS=‘11'のとき ・EaRが@−SPのとき ・EaMbfが#imm_data,@SP+,@−SPのとき ・不正オペランド例外 ・width≦0,width>32のとき 【ニモニック】 BFCMP src,offset,width,base 【命令の機能】 compare bit field(signed) ビットフィールドの比較(符号付き) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第153図に示す。 【フラグ変化】 第154図に示す。 【解説】 ソースsrcの値をビットフィールドの値を比較する。 ソースのサイズとビットフィールドのwidthの値が異
なっている場合は、サイズの小さい方のデータが符号拡
張されてから比較される。また、BFCMP:Gのoffsetも符
号拡張される。 EaRbfのアドレッシングモードでは、@−SP,@SP+,
#imm_dataのモードは使用できない。baseのレジスタ直
接モードRnは<<L2>>であるが「本発明装置」ではサ
ポートする。 [オペレーション] srcの初期値を[S0.S1....Ss−2.Ss−1] s=8,16,32,64(:I) s=32,64(:R) offset=o,width=w とする。offset,widthとも符号付きとして扱われる。
(width≦0,width>dの時はエラー) この時、比較される部分のビットフィールドとフラグの
変化は、次のようになる。 srcを符号拡張してこの部分と比較する L_flag S[Bo〜o+w−1]−S[S0〜s−1]<
0 比較結果によってセットされる。 Z_flag S[Bo〜o+w−1]−S[S0〜s−1]=
0 比較結果によってセットされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・+=‘0'のとき ・X=‘1'のとき ・SS=‘11'のとき ・EaRが@−SPのとき ・EaRbfが#imm_data,@SP+,@−SPのとき ・不正オペランド例外 ・width≦0,width>32のとき 【ニモニック】 BFCMPU src,offset,width,base 【命令の機能】 compare bit field(unsigned) ビットフィールドの比較(符号なし) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第155図に示す。 【フラグ変化】 第156図に示す。 【解説】 ソースsrcの値をビットフィールドの値を比較する。 ソースのサイズとビットフィールドのwidthの値が異
なっている場合は、サイズの小さい方のデータがゼロ拡
張されてから比較される。一方、BFCMPU:Gのoffsetは符
号拡張される。 EaRbfのアドレッシングモードでは、@−SP,@SP+,
#imm_dataのモードは使用できない。baseのレジスタ直
接モードRnは<<L2>>であるが「本発明装置」ではサ
ポートする。 [オペレーション] srcの初期値を[S0.S1....Ss−2.Ss−1] s=8,16,32,64(:I) s=32,64(:R) offset=o,width=w とする。offset,widthとも符号付きとして扱われる。
(width≦0,width>dの時はエラー) この時、比較される部分のビットフィールドとフラグの
変化は、次のようになる。 srcをゼロ拡張してこの部分と比較する L_flag U[Bo〜o+w−1]−U[S0〜s−1]<
0 比較結果によってセットされる。 Z_flag U[Bo〜o+w−1]−U[S0〜s−1]=
0 比較結果によってセットされる。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・+=‘0'のとき ・−=‘1'のとき ・SS=‘11'のとき ・EaRが@−SPのとき ・EaRbfが#imm_data,@SP+,@−SPのとき ・不正オペランド例外 ・width≦0,width>32のとき 12−8.任意長ビットフィールド操作命令 任意長のビットフィールド操作命令には、次のような
ものがある。 一般的な演算と転送 BVMA P 転送 BVCP Y 繰り返しパターンの演算と転送 BVPA T 0または1のサーチ BVSC H BVMAP,BVPAT,BVCPYは、ビットマップディスプレイ上の
ウインドウ操作(bitblt)を主な目的とした命令であ
る。 説明のため、ビットマップディスプレイの属性につい
て用語を定義する。 (color scale,color offsetとbit−dot極性) ・color scale: 1dotを連続の何bitで表すか。 例: <color scale=1> 1bitが1dot。1バイトで連続した8dot。 白黒のビットマップディスプレイ。または、colorを構
成する各ビットをバンクにしたビットマップディスプレ
イ。 <color scale=4> 隣合った4bitで1dot。1バイトで連続した2dot。 16色カラーのビットマップディスプレイ。 ・bit−dot極性 これは、ビットマップディスプレイとプロセッサとの
組み合わせに対して生ずる概念である。小さいアドレス
の方が左側に表示されるような一般的はビットマップデ
ィスプレイにおいて、小さいビット番号に対応するドッ
トも左側に表示される場合、このようなビットマップデ
ィスプレイを正のbit−dot極性を持つという。また、逆
のものを負のbit−dot極性を持つという。つま、big−e
ndianのプロセッサでは、MSBビットが左側に表示される
場合に正のbit−dot極性を持つことになる。 ・color offset 1dotを構成する複数のビットのうち、第何ビットを操
作するか、ということ。 0≦color offset<color scale という関係が成り立つ。 これは、ビットマップディスプレイハードウエアの属
性ではなく、ビットマップディスプレイ操作上のパラメ
ータである。 base addressに対応するドットから、横方向にX(do
t offset)だけ変位したドットを操作する場合、そのメ
モリ上のbit offsetは次のように計算される。 (dot offsetは画面上の点の概念、bit offsetはメモリ
上のbitの概念である。) 正のbit−dot極性の時 bit offset=X*color scale+color offset 負のbit−dot極性の時 bit offset=(X*color scale+color offset).xor.
7 ところで、実際の「本発明装置」のBVMAP,BVCPY,BVPAT
命令では、インプリメントのことを考えて制約を設け、
次のような場合にのみ使用できるようになっている。 ・bit−dot極性が正 ・color scaleが1 このため、ビットマップディスプレイのハードウエアを
ある程度規定することはやむを得ない。具体的な制限は
次のようになる。 ・bit−dot極性が正なので、「本発明装置」をbig−end
ianとした場合には、アドレスの小さい方、ビット番号
の小さい方(MSB)が画面の左側に表示されなければな
らない。 ・color scale=1のみなので、color scale≠1のビッ
トマップディスプレイに対しては次のような制約があ
る。 color scale≠1のビットマップディスプレイでは、c
olor offset毎に演算の種類を変えることができなくな
る。 BVMAP命令でcolor scaleの変更をすることはできない
ので、ビットマップディスプレイのcolor scaleが1で
ない時には、内部表現も同じcolor scaleにしないと、B
VMAP命令は、使えない。その場合、画面イメージの内部
表現がハードウエアに依存することになるので、他のハ
ードウエアとの間でデータの転送を行なう時は、データ
形式の変換が必要になる。 任意長ビットフィールド操作命令はオペランドが多
く、実行時間も長い。したがって、実行中での割り込み
受け付けや、割り込み処理後の再実行のメカニズムが必
要である。「本発明装置」では、オペランドの指定と演
算の進行状況の表現のために固定番号のレジスタを使用
している。そのため、任意長ビットフィールド命令実行
中に割り込みが入っても、割り込み処理ハンドラ中でそ
のレジスタの退避と復帰が正しく行なわれていれば、割
り込み処理後に、そのビットフィールド命令を途中から
再開できる。実行中断後に状態の退避やコンテキストス
イッチを行なったり、コンテキストスイッチ後に別のプ
ロセスで同じビットマップ命令を実行し、再び前のコン
テキストに戻って前のビットマップ命令を再開したとし
ても、問題なく動かなければならない。 また、BTRONの仕様では、VRAMではない普通のメイン
メモリに対しても、文字や図形の描画が行なわれること
がある。したがって、任意長ビットフィールド命令でも
ページフォールドの起こる可能性があり、ストリング命
令と同様に、ページフォールトによる実行中断にも対処
できなければならない。 BVMAP,BVCPY命令では、インサートエディタなどで真
横に図形を移動することを考え、ビットマップのソース
とデスティネーションのオーバーラップにも対応できる
ようになっている。具体的には、ストリング命令と同じ
ように、演算を行なう方向を命令中のオプション/F,/B
として指定する。ソフトウエアにより適当な方向を判定
し、デスティネーションがソースを破壊しないように演
算を進める。ただし、インプリメントの負担を考え、逆
方向の処理を指定するオプション/Bは<<L2>>となっ
ている。 「本発明装置」ではBTRONの動作を高速化するための
逆方向処理のサポートする。 srcとdestがオーバーラップしていた場合、srcのbase
〜offsetよりもdestのbase〜offsetの方が小さければ、
offsetの小さい方から処理することによってdestがsrc
を破壊することなく処理を進めることができる。この目
的で/Fオプションを使用する。画面とビットマップとの
対応は、通常オフセット(アドレス)の小さい方が左側
になる。したがって、srcよりもdestのbase〜offsetの
方が小さくなるのは、文字の削除などによってビットマ
ップデータを左に動かそうとした時である。 また、srcのbase〜offsetよりもdestのbase〜offset
の方が大きければ、offsetの大きい方から処理すること
によってdestがsrcを破壊することなく処理を進めるこ
とができる。この目的で/Bオプションを使用する。src
よりもdestのbase〜offsetの方が大きくなるのは、文字
の挿入などによってビットマップデータを右に動かそう
とした時である。 srcとdestがオーバーラップする可能性がある場合に
は、ソフトウエアの判断により正しいオプションを使用
し、destがsrcを破壊しないように演算を進める必要が
ある。ただし、/Bオプションは<<L2>>となっている
ので、/Bが使用できない場合には、srcを一旦他の場所
にコピーしてからdestとの演算を行なわなければならな
い。 オーバーラップがない場合には、どちらのオプション
を使っても結果は変わらない。 ここで、問題は、destのbase〜offsetの方が小さいの
に/Bオプションを使用した場合や、destのbase〜offset
の方が大きいのに/Fオプションを使用した場合にどのよ
うな動作を行なうかということである。基本的には、既
に演算の終った部分のdestが、srcのまだ参照されてい
ない部分を破壊する形になるため、正しい結果が得られ
ない。しかも、この時は、アルゴリズム上、命令が途中
で中断して再実行を行なった場合に、結果が変わってく
ることがある、もともと正しい結果を保証していないの
であるから、実行中断によって結果が変わったとしても
構わないはずであるが、実行中断のなかった場合は正し
い結果が得られることもあるので、再現不可能なバグが
入りやすい状況になる。しかし、このエラーチェックを
きちんと行なうとオーバヘッドが増え、実行時間の低下
をもたらすので、エラーチェックは行なわない。ユーザ
の側で注意が必要である。 任意長ビットフィールド命令では、レジスタ上のビッ
トオフセットoffset、ビット幅width、パターンデータp
atternのサイズとして、32ビットまたは64ビット<<LX
>>のみが使用できる。8,16ビットの指定は行なわな
い。32ビットと64ビットのレジスタサイズの選択は、X
フィールドによって共通に行なわれる。 BVMAP,BVCPY,BVPAT命令のdest側のメモリアクセス方
法については、writeまたはread−modify−writeという
ことで特に規定しない。 BV命令でwidth≦0の場合には、何もせずに命令を終
了し、EITとはしない。この時、BVSCH命令では、長さに
よる終了を示すV_flag(サーチ失敗と同じ)がセットさ
れる。これは、BV命令やストリング命令の様な高機能命
令の場合には、その外側でさらに高機能のサブルーチン
を作ることが多く、チェックが必要であればそのサブル
ーチンで行なえばよいと考えているためである。例え
ば、BVMAPであれば、それをライン数だけ繰り返してBit
Blt関数を作ることが多く、その時はwidthがすべて共通
になるので、毎回widthをチェックする必要はない。一
方、BF命令のように、コンパイラが直接生成する可能性
のあるコードでは、できるだけチェックを厳重にする必
要がある。したがって、BF命令のwidthは例外で検出す
るようにしている。 任意長ビットフィールド命令ではoffset+widthがオ
ーバーフローする場合には、割り込みによる命令実行中
断時、および命令終了時のレジスタ上のoffset値がおか
しな値になり、正常な命令の実行ができなくなる。この
場合は、動作を保証しないものとする。アーキテクチャ
上は、命令実行開始時にこれを検出して不正オペランド
例外(IOE)とするのが望ましいが、チェックのために
実行時間が伸びるので、チェックせずに実行するものと
する。(なお、ストリング命令の場合は、offsetに相当
するのが整数ではなくポインタアドレスとなっているた
め、オーバーフローとしては扱わず、単にアドレスがラ
ップアラウンドするだけである。) 【ニモニック】 BVSCH 【命令の機能】 find first‘0'or‘1'in the bitfield(variable le
ngth) 0または1のサーチ(任意長ビットフィールド) 【命令オプション】 /0 ‘0'をサーチ(デフォルト) /1 ‘1'をサーチ /F ビット番号の増加方向にサーチ(デフォルト) /B ビット番号の減少方向にサーチ<<L2>>(「本
発明装置」ではサポートする) 【命令ビットパターンとアセンブラ表記】 第157図に示す。 【フラグ変化】 第158図に示す。 【解説】 任意長のビットフィールドの中にある‘0'または‘1'
のビットをサーチする。 サーチを開始するビット番号(bit offset)をoffset
オペランド(R1)にセットしてこの命令を実行すると、
命令実行後、サーチ結果のビット番号がoffsetオペラン
ド(R1)にセットされている。つまり、offsetはread−
modify−writeとなっている。これは、ビットの検索を
繰り返して行なうことを想定したためである。offsetは
符号付き整数として扱われ、その値は任意である。 BVSCHを実行した結果、サーチ失敗だった場合には、V
_flagをセットし、offsetは次にサーチすべきビットを
指示。EITは起動しない。BVSCH命令のオフセットやV_fl
agの変化方法は、BSCH命令に準じたものである。 /Bによる逆方向のサーチは<<L2>>仕様となってい
るが「本発明装置」ではサポートする。 この命令は、ディスクやメモリの空きブロック検索な
どに使用することを目的としたものである。 なお、任意長ビットフィールド命令やストリング命令
などの高機能命令の詳細仕様や、命令終了後のレジスタ
値については、付録11を参照のこと。 【プログラム例外】 ・予約命令例外 ・+=‘0'のとき ・X=‘1'のとき ・P=‘1'のとき 【ニモニック】 BVMAP 【命令の機能】 bit operation(one line BitBlt) ビットマップ演算 【命令オプション】 /F offsetの小さい方から処理する(デフォルト) /B offsetの大きい方から処理する <<L2>>(「本発明装置」ではサポートする) 【命令ビットパターンとアセンブラ表記】 第159図に示す。 【フラグ変化】 第160図に示す。 【解説】 スクリーン上のビットマップ操作を行なうために、任
意長のビットフィールドsrc,destに対する各種の論理演
算をする命令である。演算の種類はR5の下位4ビットで
指定され、次の16種類が用意されている。 このうちD(Dest)の演算モードは、対称性のために
設けられている。ニモニックと実際のビットパターンと
の対応については、付録を参照のこと。 演算を指定するレジスタR5の上位ビットが0でない場
合にも、特にチェックは行なわないものとする。ただ
し、チェックが行なわれていなくても、上位ビットには
必ず‘0'を入れてもらうように、マニュアル等で指導す
る必要がある。不正オペランド例外(IOE)としないの
は、インプリメントの負担が大きく、実行速度に影響が
出るためである。 /F,/Bオプションは、offsetの小さい方から処理する
か、offsetの大きい方から処理するかを指定する。これ
は、ビットマップのsrcとdestがオーバーラップしてい
た場合に、処理の方向を明確にしておかないと、destが
srcを破壊して正しい結果が得られないからである。 srcとdestがオーバーラップしていた場合、srcのbase
〜offsetよりもdestのbase〜offsetの方が小さければ、
offsetの小さい方から処理することによってdestがsrc
を破壊することなく処理を進めることができる。この目
的で/Fオプションを使用する。画面とビットマップとの
対応は、通常オフセット(アドレス)の小さい方が左側
になる。したがって、srcよりもdestのbase〜offsetの
方が小さくなるのは、文字の削除などによってビットマ
ップデータを左に動かそうとした時である。 また、srcのbase〜offsetよりもdestのbase〜offset
の方が大きければ、offsetの大きい方から処理すること
によってdestがsrcを破壊することなく処理を進めるこ
とができる。この目的で/Bオプションを使用する。src
よりもdestのbase〜offsetの方が大きくなるのは、文字
の挿入などによってビットマップデータを右に動かそう
とした時である。 なお、destのbase〜offsetの方が小さいのに/Bオプシ
ョンを使用した場合や、destのbase〜offsetの方が大き
いのに/Fオプションを使用した場合には、結果(dest)
を保証しないものとする。特に、このような場合には、
命令実行中に割り込みやページフォールドなどが発生し
て命令再実行が起こると、結果が変わってくることもあ
る。 srcとdestがオーバーラップする可能性がある場合に
は、ソフトウエアの判断により正しいオプションを使用
し、destがsrcを破壊しないように演算を進める必要が
ある。ただし、/Bオプションは<<L2>>となっている
ので、/Bが使用できない場合には、srcを一旦他の場所
にコピーしてからdestとの演算を行なわなければならな
い。「本発明装置」では/Bオプションはサポートする。 オーバーラップがない場合には、どちらのオプション
を使っても結果は変わらない。 ←base〜offsetが小 base〜offsetが大→ [オーバーラップなし] 第161図に示す。 [オーバーラップあり−destのbase〜offsetが小] 第162図に示す。 [オーバーラップあり−destのbase〜offsetが大] 第163図に示す。 【プログラム例外】 ・予約命令例外 ・Q=‘1'のとき ・X=‘1'のとき ・P=‘1'のとき 【ニモニック】 BVCPY 【命令の機能】 bit transfer ビットマップ転送 【命令オプション】 /F offsetの小さい方から処理する(デフォルト) /B offsetの大きい方から処理する <<L2>>(「本発明装置」ではサポートする) 【命令ヒットパターンとアセンブラ表記】 第164図に示す。 【フラグ変化】 第165図に示す。 【解説】 スクリーン上のビットマップ操作を行なうために、任
意長のビットフィールドsrc,destの間の転送をする命令
である。この命令は、BVMAP命令から演算の機能をはず
して転送のみに限定し、高速化を目指したものである。 /F,/Bオプションの意味はBVMAPと同じである。ビット
マップのsrcとdestがオーバーラップしていなければ、
どちらのオプションを使っても結果は変わらないが、sr
cとdestがオーバーラップした場合には、ソフトウエア
の判断により正しいオプションを使用し、destがsrcを
破壊しないように演算を進める必要がある。/Bオプショ
ンの場合、R1,R4に入れるオフセット値としては、転送
の対象となるビットフィールドの最大+1のオフセット
値を指定する。これは、SMOV/B,SCMP/Bの仕様との対応
を考えたものである。/Bオプションは<<L2>>である
が「本発明装置」ではサポートする。 【プログラム例外】 ・予約命令例外 ・Q=‘1'のとき ・X=‘1'のとき ・P=‘1'のとき 【ニモニック】 BVPAT 【命令の機能】 cyclic bit operation パターンとビットマップの演算 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第166図に示す。 【フラグ変化】 第167図に示す。 【解説】 スクリーン上のビットマップをあるパターンで埋めた
り、スクリーン上のビットマップとあるパターンの演算
を行ないたい場合に使用する命令である。patternを繰
り返し発生しながら、ビットフィールドとの論理演算を
行なう。 演算指定(R5)の上位ビットが0でない場合は単に無
視され、特にチェックは行なわないものとする。 ただし、チェックが行なわれていなくても、将来の拡
張のため、上位ビットには必ず‘0'を入れてもらうよう
に、マニュアル等で指導する必要がある。不正オペラン
ド例外(IOE)としないのは、インプリメントの負担が
大きく、実行速度に影響が出るためである。 この命令では、BVMAP,BVCPYとは異なり、書き込みの
際にシフトを行なわない。offsetの指定は、単にパター
ンをクリッピングするだけである。(これに対して、BV
MAP命令では、srcとdestのoffsetがずれていた場合には
シフトが行なわれる) 【プログラム例外】 ・予約命令例外 ・+=‘0'のとき ・X=‘1'のとき ・P=‘1'のとき 12−9.10進演算命令 10進演算に関しては、符号ないしPACKED形式(BCD)
の10進数の1ワードの加減算とPACK/UNPACK処理をメイ
ンプロセッサの<<L1>>仕様としてサポートし、符号
付きPACKED形式10進数の1ワードの加減算を<<L2>>
仕様としてサポートする。また、多桁の10進数の加減乗
除はコプロセッサで行なう。 このうち、本章では符号なしPACKED形式10進数の加減
算とPACK/UNPACK処理について説明を行なう。符号付きP
ACKED形式10進数をサポートする<<L2>>の命令につ
いては、後の章で説明を行なう。10進演算のアドレッシ
ングモードは一般命令と同じになっている。 本発明装置では本節で述べる10進演算命令4種類はサ
ポートしない。 【ニモニック】 ADDDX src,dest(本発明装置ではサポートしない) 【命令の機能】【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第168図に示す。 【フラグ変化】 第169図に示す。 【解説】 パックされたBCDの加算を行なう。 8ビット(2桁)、16ビット(4桁)、32ビット(8
桁)、64ビット(16桁)のBCDデータを扱うことができ
る。ただし、64ビットは<<LX>>仕様である。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースがゼロ拡張さ
れた上で加算される。 BCDの数は符号拡張が無意味なので、基本的には符号
なしの数と考え、ADDDXのフラグ変化はADDUに準じるも
のとする。結果がdestに入らない時にV_flagがセットさ
れること、d<sの時はdestのサイズからの桁上げがX_
flagにセットされること、などもADDUと同様である。た
だし、ADDUとは異なり、Z_flagはADDX,SUBXのように累
積で変化する。 src,destの各桁が0〜9以外の数を含んでいた場合、
つまりADDDX,SUBDXのオペランドがBCDでなかった場合に
は、EITとはならないが、destやフラグに設定される結
果は保証できない(インプリメント依存になる)ものと
する。不正オペランド例外(IOE)としないのは、イン
プリメントの負担が大きく、実行速度に影響が出るため
である。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき ・<<L1>>機能例外 ・ADDDXの正しいビットパターンがデコードされたと
き 【ニモニック】 SUBDX src,dest(本発明装置ではサポートしない) 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第170図に示す。 【フラグ変化】 第171図に示す。 【解説】 パックされたBCDの減算を行なう。 8ビット(2桁)、16ビット(4桁)、32ビット(8
桁)、64ビット(16桁)のBCDデータを扱うことができ
る。ただし、64ビットは<<LX>>仕様である。 ソースオペランドのサイズがデスティネーションオペ
ランドのサイズよりも小さい時は、ソースがゼロ拡張さ
れた上で加算される。 BCDの数は符号拡張が無意味なので、基本的には符号
なしの数と考え、SUBDXのフラグ変化はSUBUに準じるも
のとする。結果が負になった時にV_flagがセットされる
こと、d<sの時はdestのサイズからの桁下げがX_flag
にセットされること、などもSUBUと同様である。ただ
し、SUBUとは異なり、Z_flagはADDX,SUBXのように累積
で変化する。 SUBDXで結果が負になった場合には、destは絶対値表
現ではなく補数表現(10の補数)となる。したがって、
destは上位桁からの繰り下がりがあった場合と同じ値に
なる。 例:16ビットでSUBDXを実行する場合 dest src 0123−0456=(−0333) destは(−333)=9667となる。 src,destの各桁が0〜9以外の数を含んでいた場合、
つまりADDDX,SUBDXのオペランドがBCDでなかった場合に
は、EITとはならないが、destやフラグに設定される結
果は保証できない(インプリメント依存になる)ものと
する。不正オペランド例外(IOE)としないのは、イン
プリメントの負担が大きく、実行速度に影響が出るため
である。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・MM=‘11'のとき ・EaRが@−SPのとき ・EaMが#imm_data,@SP+,@−SPのとき ・<<L1>>機能例外 ・SUBDXの正しいビットパターンがデコードされたと
き 【ニモニック】 PACKss src,dest(本発明装置ではサポートしない) 【命令の機能】 pack string into BCD BCDへのパック 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第172図に示す。 【フラグ変化】 第173図に示す。 【解説】 scrをBCD(Binary Coded Decimal)にパックしてdest
に転送する。実際には、ssにB,H,W,Lのいずれかの文字
が入り、次のようなニモニックとオペレーションにな
る。 なお、PACKss,UNPKssにおいて、サイズの違いによっ
てニモニックまで変えているのは、サイズの違いによっ
て命令自体の意味もかなり変わると考えられるためであ
る。つまり、一般の命令では、サイズの違いによってゼ
ロ拡張や符号拡張を行なうだけであったが、PACKss,UNP
Kssでは命令のオペレーション自体がかなり異なってい
る。 PACK,UNPKで、上記の説明に含まれない不合理なサイ
ズの組み合わせを指定した場合には、動作を保証しない
(インプリメントに依存した値がdestに設定される)も
のとする。アーキテクチャ上は予約命令例外(RIE)と
するのが望ましいが、2つのオペランドのサイズの組み
合わせによって予約命令例外(RIE)を検出するのはイ
ンプリメントの負担が大きいため、予約命令例外(RI
E)とはしない。これは、異種サイズ間の論理演算の場
合も同様である。 srcのうち、destに影響を与えないフィールド(PACKH
Bの2^7〜2^4のビットなど)については、0かどうかの
チェックは行なわず、0でなくても無視する。文字コー
ドをそのままパックするケースを考えると、0でないこ
との方が多い。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・W=‘11'のとき ・EaRが@−SPのとき ・EaWが#imm_data,@SP+のとき ・<<L1>>機能例外 ・PACKssの正しいビットパターンがデコードされたと
き 【ニモニック】 UNPKss src,dest,adj(本発明装置ではサポートしな
い) 【命令の機能】 unpack BCD BCDからのアンパック 【命令オプション】 なし 第174図に示す。 【フラグ変化】 第175図に示す。 【解説】 BCD(Binary Coded Decimal)のsrcのアンパックを行
ない、アンパックした値に補正値adjを加えてdestに転
送する。補正値adjを加えるのは、UNPK命令によって直
接文字コードまで生成するためである。adjの加算は、B
CDではなくバイナリの加算である。adjのサイズはdest
のサイズと共通にWWフィールドによって指定される。 実際には、ssにB,H,W,Lのいずれかの文字が入り、次
のようなニモニックとオペレーションになる。第176図
に示す。 PACK,UNPKで、上記の説明に含まれない不合理なサイ
ズの組み合わせを指定した場合には、動作を保証しない
(インプリメントに依存した値がdestに設定される)も
のとする。アーキテクチャ上は予約命令例外(RIE)と
するのが望ましいが、2つのオペランドのサイズの組み
合わせによって予約命令例外(RIE)を検出するのはイ
ンプリメントの負担が大きいため、予約命令例外(RI
E)とはしない。 adjの加算によるオーバーフローは無視する。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・W=‘11'のとき ・EaRが@−SPのとき ・EaWが#imm_data,@SP+のとき ・<<L1>>機能例外 ・UNPKssの正しいビットパターンがデコードされたと
き 12−10.ストリング命令 「ストリング」とは、8ビット、16ビット、32ビッ
ト、または64ビットのデータを任意の長さだけ連続して
並べたデータタイプである。(SSCH命令に限り、連続で
はなく、一定間隔で飛び飛びのアドレスにあるデータの
集合もサポートしている。) 個々のデータの意味は特に決まっておらず、実際の文
字コードになる場合、整数になる場合、浮動小数になる
場合などがある。これは、ユーザ側で解釈する。 ストリングの範囲を示す方法には、 ・ストリングの長さ(データ数)を指定する方法 ・ストリング終了を示す文字(ターミネータ)を指定
する方法 の2通りがあり、使用目的や言語によって適した方を選
択する必要がある。本発明装置のストリング命令ではス
トリングのデータ数がパラメータとなっているが、さら
にオプションの終了条件という形でターミネータを与え
ることができ、両方の指定方法をサポートしている。 本発明装置のストリング命令の特徴の一つとして、ポ
インタの増減量を自由に設定できるということがあげら
れる。そのため、ストリングサーチ命令(SSCH命令)を
使ってテーブル検索や多次元配列のスキャンなども行な
うことができる。 また、本発明装置ではストリング命令SMOV,SCMP,SSCH
の終了条件として大小比較や二値比較を含む豊富な条件
が指定でき、これも大きな特徴となっている。ストリン
グ命令のうち、ストリングサーチ用のSSCH命令は、検索
条件が終了条件として指定されるため、終了条件にのみ
意味がある命令となっている。本発明装置のストリング
命令で指定できる条件(eeee)については、付録を参照
のこと。本発明装置では<<L2>>仕様となっている、
終了条件OUTU−ZEはサポートしない。 ストリング命令の用途としては、文字どおり8/16ビッ
トの文字列を処理するもののほか、特定のビットパター
ンのサーチ、メモリのブロック転送、構造体の代入、メ
モリ領域のクリアなどの応用がある。 ストリング命令は任意長ビットフィールド命令と同じ
く不定長のデータを扱うため、実行中の割り込み受付、
実行再開の機能が不可欠である。一方、ストリング命令
自体がコンパイラの生成するコードとなることはほとん
どなく、アセンブラで書かれたサブルーチンとして提供
されることが多い。そのため、対称性やアドレッシング
モードについての制限はあまり問題にならない。したが
って、本発明装置のストリング命令では、オペランドや
実行途中の状態保持のために固定番号のレジスタ(R0〜
R4)を使うようになっている。主なレジスタの使い方は
次のようになる。 R0:ソース側ストリングの先頭アドレス R1:デスティネーション側ストリングの先頭アドレス R2:ストリングの長さ、データ数 R3:終了条件の比較値(1) R4:終了条件の比較値(2) このうち、ストリングの長さを表わすR2はエレメント
数であって、バイト数ではない。R2は符号なしの数とし
て扱われ、R2=0の場合はエレメント数による命令終了
は行なわないという意味に解釈される。つまり、エレメ
ント数による終了を避けたい場合には、R2=0として命
令を実行すれば良いことになる。インプリメント上は、
ストリング命令の実行パターンは次のようになるのが一
般的である。 ただし、R2=0とした場合に、エレメント数をH′10
0000000と考えるか、無限大(エレメント数のチェック
を行なわない)と考えるかはインプリメントに依存す
る。つまり、H′100000000回のエレメント操作を行な
っても命令を終了しなかった場合に、その後の動作はイ
ンプリメント依存になるものとする。 ただし、エレメント数以外の要因により命令を終了し
た場合(R2=0の場合は普通こうなる)には、命令終了
後のR2の値(付録11参照)が正しくセットされていなけ
ればならない。実際には、SSCH/RでR5=0を指定したよ
うな特殊な場合を除いて、H′100000000回のエレメン
ト操作を行なう間にアドレス変換例外(ATRE)やバスア
クセス例外(BAE)を起こし、命令中断となるのが普通
である。 ストリング命令はいろいろ要因で終了するため、それ
らを区別するためにフラグを用いる。それぞれのフラグ
の意味は、次のようになっている。 V_flag エレメント数(ストリング長)による終了 F_flag 終了条件(eeee)による終了 この時、複数の終了条件を区別するためにM_flagを使用
する。 M_flagの変化については付録参照。 これ以外に終了要因のないSCMP,SSCHでは、V_flagとF_f
lagの変化が相補的となる。SCMPの場合には、これ以外
に比較データの不一致によって命令を終了する場合があ
る。 【ニモニック】 SMOV 【命令の機能】 copy string ストリングのコピー 【命令オプション】 /F アドレス増加の方向に処理する /B アドレス減少の方向に処理する /終了条件各種(eeee) (本発明装置では<<2L>
>となっているOUTU−ZEはサポートしない。) 【命令ビットパターンとアセンブラ表記】 第1177図に示す。 【フラグ変化】 第178図に示す。 【解説】 ストリングの転送を行なう。 減少方向の操作をするストリング命令SMOV/Bでは、最
初にR0,R1で指定するアドレスが、操作対象となるスト
リングの占めるアドレスの最大アドレス+1を指し、R
0,R1をプリデクリメントしながら操作を進める。 SMOVでsrcとdestがオーバーラップしていた時に/F,/B
のうち正しくない方のオプションを指定した場合の動作
は、BVCPY,BVMAPと同じように保証しないものとする。
つまり、インプリメントや命令実行中断の有無によって
異なる場合がある。 これは、高機能命令の特徴を生かしてパイプライン的
なメモリアクセスをした場合に、メモリアクセスの順番
が変わることがあり、必ずしも前エレメントの書き込み
が終わってから次エレメントの読み出しを行なうとは限
らないからである。 なお、逆方向の処理オプション/Bは、この命令SMOV/B
に限り<<2L>>ではなく、<<L1>>となっている。 任意長ビットフィールド命令やストリング命令などの
高機能命令の詳細仕様や、命令終了後のレジスタ値につ
いては、付録11を参照のこと。 【プログラム例外】 ・予約命令例外 ・SS=‘11'のとき ・P=‘1'のとき ・Q=‘1'のとき ・eeee=‘0111'〜‘1111'のとき 【ニモニック】 SCMP 【命令の機能】 compare string ストリングの比較 【命令オプション】 /F アドレス増加の方向に処理する /B アドレス減少の方向に処理する <<2L>>(本発明装置ではサポートする) /終了条件各種(eeee) (本発明装置では<<2L>
>となっているOUTU−ZEはサポートしない。) 【命令ビットパターンとアセンブラ表記】 第179図に示す。 【フラグ変化】 第180図に示す。 【解説】 ストリングsrc1,src2,の比較を行なう。 2つのストリングが一致している間は比較を続け、一
致しない文字が見付かれば比較を終了する。SCMP命令で
は、CMP命令と同様に、src2−src1の結果をもとにして
フラグの設定を行なう。例えばL_flagは、src1に対して
src2の方がより小さいということを示す。src1−src2の
結果をもとにしてフラグの設定を行なうのではない。 終了条件を持つSCMP命令の応用としては、テキストを
一行単位で比較する(R3に改行の文字コードをセットし
てSCMP/EQを実行)、数字が続く間だけ比較する。全角
文字が続く間だけ比較する、といったものがある。 SCMPでは、命令を終了させる要因が次の3つ存在し、
フラグ変化によってそれらを見分けることができる。 1.エレメント(データ)数(R2)による終了 V_flag=1 2.終了条件による終了 F_flag=1,終了要因によってM_flagが変化 3.比較中のデータの不一致による終了 Z_flag=0,比較結果によってL_flag,X_flagが変化 L_flagは、最後のデータを符号付きと見て比較した時の
比較結果X_flagは、最後のデータを符号なしと見て比較
した時の比較結果 1〜3の要因のうち、2と3のチェックを同時に行な
うことは可能であるが、1の要因のチェックは、2,3と
は別のフェーズで行なわれる。したがって、2と3が同
時に成立することはあるが、1と2や1と3が同時に成
立することはない。1,2,3の少なくても一つの終了要因
が成立した場合にSCMP命令が終了する。 比較するデータが一致している間は、その値(src1=
src2)が終了条件のテスト対象となるが、データに不一
致があった場合には、R0により示されるsrc1の方を終了
条件のテスト対象とする。ただし、不一致によりSCMP命
令が終了した場合には、終了条件が成立したかどうかと
いう情報は必要ないことが多いため、これは単なる約束
に過ぎない。 また、終了条件が満たされないと意味を持たないM_fl
agについては、別の終了要因により終了した場合に、意
味が不明確となる。そのような場合のフラグ変化は、0
になるものと決めておく。 Z_flag,L_flag、X_flagについては、一致、不一致に
かかわらず必ず最後のデータの比較結果を反映する。し
たがって、3.以外の要因で終了した場合(データが一致
している場合)には、自動的にZ_flag=1,L_flag=0,X_
flag=0となる。なお、SCMPでは符号なしデータ、符号
付きデータの両方を扱うため、L_flagにエレメントを符
号付きデータと考えた時の比較結果が入り、X_flagにエ
レメントを符号なしデータと考えた時の比較結果が入る
ようになっている。BTRONの文字コードは符号なしで扱
う必要があるし、一般の整数を扱うのであれば、符号付
きのデータを扱う必要もある。 SCMPのフラグ変化をまとめると第181図のようにな
る。 ○は終了要因が満たされたことを示し、×は終了要因
が満たされないことを示す。 +……フラグ本来の意味ではなく、約束としてこうな
っていることを示すものである *A……src1=src2が終了条件のどれに該当するか、
による *B……src1が終了条件のどれに該当するか、による *C……src1<src2かsrc2<src1か、による /Bオプションは<<L2>>であるが本発明装置ではサ
ポートする。 【プログラム例外】 ・予約命令例外 ・SS=‘11'のとき ・P=‘1'のとき ・Q=‘1'のとき ・eeee=‘0111'〜‘1111'のとき 【ニモニック】 SSCH 【命令の機能】 find a character in a string ストリングのサーチ 【命令オプション】 /F アドレス増加の方向に処理する (ポインタ値をエレメントサイズずつ増加させる) /R ポインタの増加値はR5で指定される /終了条件各種(eeee) (本発明装置では<<2L>
>となっているOUTU−ZEはサポートしない。) 【命令ビットパターンとアセンブラ表記】 第182図に示す。 【フラグ変化】 第183図に示す。 【解説】 ストリングをサーチし、条件に合うエレメントを見つ
け出す。 ‘/R'オプションの場合には、R5の正負にかかわら
ず、常にエレメントの比較後にR0が更新(ポストインク
リメントまたはポストデクリメント)される。 SSCH/RのR5のサイズはR0のポインタサイズと等しくな
る。つまり、本発明装置32では32ビット固定であり、本
発明装置64ではPビットまたはモードによって指定され
る。SS(R3,R4,エレメントサイズ)とは独立である。 【プログラム例外】 ・予約命令例外 ・SS=‘11'のとき ・P=‘1'のとき ・eeee=‘0111'〜‘1111'のとき 【ニモニック】 SSTR 【命令の機能】 store characters 同一データを繰り返し書き込み(ストリングのフィ
ル) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第184図に示す 【フラグ変化】 第185図に示す。 【解説】 先頭アドレス(R1)と長さ(R2)により指定されたメ
モリ領域に、R3の値を繰り返し書き込む。 SSTR命令では終了条件が意味を持たないため、終了条
件の指定は行なわない。 なお、ストリング命令でR2=0の場合はエレメント数
による終了を行なわないが、SSTR命令の場合はエレメン
ト数による終了が唯一の終了要因であり、R2=0を指定
すると無限ループを形成することになる。これについて
は、ハードウエアでは特に対処せず、プログラム側で注
意してもらうことにする。ただ、実行中の割り込み受付
や再実行は可能なので、この命令によって間違って無限
ループに入ったとしても、タスクやプロセスのスケジュ
ーリング等には影響しない。通常は複数の命令によって
構成される無限ループが、たまたま一命令にまとめられ
ただけと考える。R2=0を不正オペランド例外IOEとし
ないのは、他のストリング命令との仕様の統一や、イン
プリメントの負担、高速化を考えたためである。 このほか、SSCHやQSCH命令でも、パラメータや終了条
件の指定によっては一つの命令で無限ループを形成する
場合がある。 【プログラム例外】 ・予約命令例外 ・SS=‘11'のとき ・P=‘1'のとき 12−11.キュー命令 本発明装置ではキューを操作するための命令として、
QINS(エントリの挿入)、QDEL(エントリの削除)、QS
CH(エントリのサーチ)の3つの命令が用意されてい
る。本発明装置でサポートしているキューは、各キュー
エントリの先頭から1番目と2番目のデータが絶対アド
レスのリンクポインタとなった、ダブルリンクのキュー
である。キューエントリの先頭にあるデータが次のキュ
ーエントリへのポインタとなり、キューエントリの2番
目にあるデータが前のキューエントリへのポインタとな
っている。 キュー命令の仕様は、キューヘッダをキュー命令のオ
ペランドとして直接指定できるように、以下のような方
針で決められている。 1.QDELでは、指定したエントリではなく直後のエントリ
が削除される。 QUEUE HEADをオペランドとして指定した場合には、先
頭のエントリが削除されることになる。QSCH/Bで見付け
たエントリを削除する場合や、キューの最後のエントリ
を削除する場合には間接参照が必要になるが、QSCH/Fで
見付けたエントリを削除する場合やキューの先頭のエン
トリを削除する場合に比較すれば、頻度は少ないと考え
られる。 2.QINSでは、指定したエントリの直前に新しいエントリ
が挿入される。 QUEUE HEADをオペランドとして指定した場合には、キ
ューの最後にエントリが挿入されることになる。 これについては2つの考え方がある。QDEL命令との対
称性を考えると、QINSでは指定したエントリ(あるいは
QUEUE HEAD)の直後にエントリを挿入する方が望まし
い。これは、QINSで挿入したエントリをQDELで削除する
ために、同じオペランドを指定できるからである。ま
た、キューをスタック(LIFO)的な使い方にする場合に
も、このような仕様の方が良い。 一方、キューをFIFOで使う場合には、QINSでキューの
最後にエントリを挿入し、QDELではキューの先頭のエン
トリを削除することが多い。こちらの方がキュー本来の
使い方であるし、ITRONでもそのような例がある。 したがって、後者の仕様にする。 3.QSCHでは、現在のエントリではなく直後のエントリか
らサーチを始める。 QUEUE HEADをオペランドとして指定した場合には、キ
ューの先頭からサーチを始めることになる。また、サー
チが成功した場合に次のサーチを行なうには、そのまま
もう一度QSCHを実行すればよい。 この考え方は、他の高機能命令(ストリング、任意長
ビットフィールド操作)とは異なったものである。すな
わち、ストリング命令では現在ポインタの指しているデ
ータ自体からサーチが始まり、連続サーチを行なう場合
には別命令でポインタを更新しておく必要がある。これ
はキュー命令とは異なった動きである。 しかし、キューの場合にはヘッダが別になっていると
いう事情があり、扱いが異なっているため、別の仕様に
しても構わないと判断した。 4.空のキューをフラグで判定する。 QINSで空のキューにデータを挿入した場合、QDELでエ
ントリの削除の結果キューが空になった場合には、Z_fl
agをセットする。また、QDELで空のキューからエントリ
を削除しようとした場合は、エラーなのでポインタの付
け変えは行なわないが、この時V_flagをセットする。 【ニモニック】 QINS entry.queue 【命令の機能】 insert a new entry into a queue ダブルリンクのキューへ挿入 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第186図に示す。 【フラグ変化】 第187図に示す。 【解説】 entryで指定される新しいキューのエントリが、queue
で示されるキューエントリの直前に挿入される。 queueで指定されるキューエントリがキューヘッダで
あった場合には、この命令によって、キューの最後に新
しいエントリが挿入されることになる。 命令実行前にキューが空であったかどうかによって、
Z_flagがセットされる。 [32ビットで処理を行なう場合のQINS命令のオペレーシ
ョン] 第188図に示す。 [実行前] 第189図に示す。 [実行後] 第190図に示す。 EaMqP,EaMaP2で指定されるアドレッシングモードで
は、レジスタ直接Rn、@−SP,@SP+.#imm_dataのモ
ードは使用できない。 なお、QINSでは、命令の実行のために直接必要ではな
い部分のデータ構造のチェック(queueの前後のキュー
エントリのリンク関係など)は特に行なわない。オペレ
ーションに書かれている通りの動作を行なう。 【プロラウム例外】 ・予約命令例外 ・+=‘0'のとき ・−=‘1'のとき ・EaMqPがRn,#imm_data,@SP+,@−SPのとき ・EaMqP2がRn,#imm_data,@SP+,@−SPのとき 【ニモニック】 QDEL queue,dest 【命令の機能】 remove a entry from a queue ダブルリンクのキューエントリを削除 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第191図に示す。 【フラグ変化】 第192図に示す。 【解説】 queueで指定された新しいキューエントリの次のエン
トリを削除し、削除されたエントリのアドレスをdestに
セットする。削除されたエントリのアドレスをdestにセ
ットするのは、それ以後削除したエントリを操作するこ
とが多いためである。 queueとしてキューヘッダを指定した場合には、キュ
ーの先頭のエントリが削除されることになる。 queueで指定されたキューが空のキューであった場合
は、命令の実行ができない。この時、EITは起動せず、V
_flag,Z_flagのセットだけを行なって命令を終了する。
destは無変化となる。 dest/EaW!Sでは、@−SPのモードを禁止している。こ
れは、キューが空でV_flagがセットされ、destの転送が
できない場合に、destに@−SPが指定されていると命令
動作がまぎらわしくなるためである。 [32ビットで処理を行なう場合のQDEL命令のオペレーシ
ョン] 第193図に示す。 [実行前] 第194図に示す。 [実行後] 第195図に示す。 EaRqPで指定されるアドレッシングモードでは、レジ
スタ直接、@−SP,@SP+.#imm_dataのモードは使用
できない。 なお、QDELでは、空のキューの判定以外のチェック、
命令の実行のために直接必要ではない部分のデータ構造
のチェック(queueの前後のキューエントリのリンク関
係など)は特に行なわない。オペレーションに書かれて
いる通りの動作を行なう。 【プロラウム例外】 ・予約命令例外 ・+=‘0'のとき ・W=‘1'のとき ・EaMqPがRn,#imm_data,@SP+,@−SPのとき ・EaW!Sが#imm_data,@SP+,@−SPのとき 【ニモニック】 QSCH 【命令の機能】 search queue entries キューのサーチ 【命令オプション】 /NM R6のマスクなし /NM R6のマスクあり<<L2>> (本発明装置ではサポートしない) /F キューの順方向にサーチ /B キューの逆方向にサーチ<<2L>> (本発明装置ではサポートしない) /終了条件各種(eeee) (本発明装置では<<2L>
>となっているOUTU−ZEはサポートしない) 【命令ビットパターンとアセンブラ表記】 第196図に示す。 セットの必要なのは、R0,R2,R3(オプション),R4
(オプション),R5,R6(オプション)であり、結果が入
るのは、R0,R1である。続けて次のサーチを行なうこと
ができる。 【フラグ変化】 第197図に示す。 【解説】 キューのエントリをサーチし、条件に合ったものを見
付ける。逆方向のサーチ機能/B、およびマスクの機能/M
Rは<<2L>>となっている。本発明装置では逆方向の
サーチ機能/Bをサポートする。マスクの機能/MRはサポ
ートしない。 この命令ではキューの長さに依存した処理量となるの
で、ストリング命令と同じように実行中の中断に対する
考慮が必要である。したがって、オペランドと途中の実
行状態は固定番号のレジスタに置く。 サーチ条件としては、マスク(特定ビットの抽出)と
比較が用意されている。マスクはフラグのサーチに用
い、比較は優先度の処理などに用いる。比較条件の指定
は、ストリング命令の終了条件の指定と同じである。 キューの終りを判定するために、キューのエントリア
ドレスとキューの終了アドレスR2との比較を行ない、一
致した場合には命令を終了する。R2と比較によって命令
を終了した場合、すなわち、それまでにサーチ条件を満
たすものがなく、サーチ失敗であった場合には、V_flag
をセットして命令を終了する。EITは起動しない。 QSCH命令の条件指定によっては、一つの命令の中で無
限ループに入ることがある。これについては、ハードウ
エアでは特に対処せず、プログラム側で注意してもらう
ことにする。ただ、実行中の割り込み受付や再実行は可
能なので、ユーザプログラムの中で間違って無限ループ
に入ったとしても、タスクやプロセスのスケジューリン
グ等には影響しない。通常は複数の命令によって構成さ
れる無限ループが、たまたま一命令にまとめられただけ
と考える。 サーチが終了した時に、R0は指定した条件に合うエン
トリを、R1はその直前のエントリを指している。R1は、
シングルリンクのキューの時にエントリを削除するため
に使用することができる。また、QDELでは指定したエン
トリの次のエントリが削除されるので、QSCH/Fで見付け
たエントリ自体を削除する場合には、QSCH実行後、@R0
ではなく@R1をパラメータとしてQDELを実行すればよ
い。 一般に、R0,R2にQUEUE HEADのアドレスをセットしてQ
SCH命令を実行することにより、キューが空の場合を含
めてキュー全体のサーチを行なうことができる。 QSCHは、シングルリンクキューとダブルインクキュー
で共用することを狙った命令である。 [QSCHのオペレーション] 第198図に示す。 このうち、check_interruptは、外部から割り込みが
かかっているかどうかを調べ、割り込みがかかっていれ
ば、QSCHの実行を中断して割り込み処理を始めるという
ものである。割り込み処理終了後にQSCH命令の残りの部
分を実行する。 [実行前] 第199図に示す。 [実行後] 第200図に示す。 【プログラム例外】 ・予約命令例外 ・SS=‘11'のとき ・eeee=‘0111'〜‘1111'のとき ・m=‘1'のとき 12−12.ジャンプ命令 【ニモニック】 BRA newpc 【命令の機能】 branch always ジャンプ(PC相対) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第201図に示す。 【フラグ変化】 第202図に示す。 【解説】 BRA命令は、PC相対のみのアドレッシングをサポート
するジャンプ命令である。ディスプレースメントのサイ
ズとして、BRA:Dでは8ビットが、BRA:Gでは8ビット、
16ビット、32ビット、64ビットが利用できる。本発明装
置の命令は必ず偶数アドレスから始まるので、短縮形の
BRA:D命令では、#d8を2倍して使用する。すなわち、となる。BRA:GでSS=00を指定した場合には、#dSを2
倍せずにそのまま使用する。 BRA:Gでnewpcが16ビットの場合、JMP@(#dS:16,P
C)と命令機能、コードサイズともに同じであるが、実
行サイクル数を短くできる可能性があるため、別命令と
なっている。 BRA:Gで、newpcが奇数であった場合には、ジャンプ先
が奇数アドレスになるため、奇数アドレスジャンプ例外
(OAJE)となる。これは、Bcc:G,CSR:G,JMP,JSR命令も
同様である。BRA:D,Bcc:D,BSR:Dでは、オペランドを2
倍して使用するため、OAJEは発生しない。 BRA:G,Bcc:G,BSR:GでSS=00の場合、オペランドサイ
ズは8ビットであるが、#dSフィールド16ビットとな
る。この時、#dSフィールドは下位8ビットのみを使用
し、上位8ビットには必ず0を入れておかなければなら
ない。上位8ビットが0でない場合は、これによって表
現されるデータがインプリメント依存の不定値になるも
のとする。つまり、BRA:G命令の場合は、ジャンプ先が
不定となる。EITにはしない。 本発明装置ではこの命令に対し、動的ブランチ予測処
理をする。 【プログラム例外】 ・予約命令例外 ・SS=‘11'のとき ・P=‘1'のとき ・奇数アドレスジャンプ例外 ・奇数アドレスにジャンプしたとき 【ニモニック】 Bcc newpc 【命令の機能】 branch conditionally 条件ジャンプ(PC相対) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第203図に示す。 【フラグ変化】 第204図に示す。 【解説】 Bcc命令は、PC相対のみのアドレッシングをサポート
する条件ジャンプ命令である。ディスプレースメントの
サイズとして、Bcc:Dでは8ビットが、Bcc:Gでは8ビッ
ト、16ビット、32ビット、64ビットが利用できる。本発
明装置の命令は必ず偶数アドレスから始まるので、Bcc:
D命令では、#d8を2倍して使用する。すなわち、 となる。Bcc:GでSS=00を指定した場合には、#dSを2
倍せずにそのまま使用する。 Bccの条件指定部分(‘cc'部分)の詳細とニモニッ
ク、ccccのビットパターンについては、付録を参照のこ
と。Bccで未定義の条件を指定した場合には、予約命令
例外(RIE)となる。 Bcc:Gで条件不一致のためジャンプしなかった時は、
本発明装置では奇数アドレスジャンプ例外(OAJE)を発
生する場合と、発生しない場合がある。 本発明装置ではこの命令に対し、動的ブランチ予測処
理をする。 【プログラム例外】 ・予約命令例外 ・SS=‘11'のとき ・P=‘1'のとき ・cccc=‘1110'〜‘1111'のとき ・奇数アドレスジャンプ例外 ・奇数アドレスにジャンプしたとき 【ニモニック】 BSR newpc 【命令の機能】 jump to subroutine サブルーチンジャンプ(PC相対) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第205図に示す。 【フラグ変化】 第206図に示す。 【解説】 BSR命令は、PC相対のみのアドレッシングをサポート
するサブルーチンジャンプ命令である。PCの値がスタッ
クに退避される。 ディスプレースメントのサイズとして、BSR:Dでは8
ビットが、BSR:Gでは8ビット、16ビット、32ビット、6
4ビットが利用できる。本発明装置の命令は必ず偶数ア
ドレスから始まるので、BSR:D命令では、#d8を2倍し
て使用する。すなわち、 となる。BSR:GでSS=00を指定した場合には、#d8を2
倍せずにそのまま使用する。 BSR,JSR命令でスタックに退避されるPC値としては、
その次の命令の先頭アドレスを使用する。これに対し
て、実効アドレスの計算のためにPCを参照する場合(BS
Rなどで暗黙にPCを参照する場合を含む)には、その命
令(次の命令ではない)の先頭アドレスをPC値として使
用するので、注意が必要である。 BSR,JSRでは旧のPCがスタックにセーブされるが、SP
のアライメントに関しては特にチェックしない。SPが4
の倍数でない場合にも、そのまま実行される。 本発明装置ではこの命令に対し、動的ブランチ予測処
理をする。 【プログラム例外】 ・予約命令例外 ・SS=‘11'のとき ・P=‘1'のとき ・Q=‘1'のとき ・奇数アドレスジャンプ例外 ・奇数アドレスにジャンプしたとき 【ニモニック】 JMP newpc 【命令の機能】 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第207図に示す。 【フラグ変化】 第208図に示す。 【解説】 newpcの実効アドレスにジャンプする。一般のアドレ
ッシングモードが使用可能なジャンプ命令である。 case文の実行などにおいては、ジャンプテーブルを参
照してジャンプ先アドレスを決める場合がある。これは
JMP命令と付加モードによるインデックスアドレッシン
グとを組み合せることにより実現する。 【プログラム例外】 ・予約命令例外 ・EaAがRn,#imm_data,@SP+,@−SPのとき ・奇数アドレスジャンプ例外 ・奇数アドレスにジャンプしたとき 【ニモニック】 JSR newpc 【命令の機能】 jump to subroutine サブルーチンジャンプ 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第209図に示す。 【フラグ変化】 第210図に示す。 【解説】 newpcの実効アドレスにサブルーチンジャンプする。P
Cの値がスタックに退避される。 BSR,JSR命令でスタックに退避されるPC値としては、
その次の命令の先頭アドレスを使用する。これに対し
て、実効アドレスの計算のためにPCを参照する場合(BS
Rなどで暗黙にPCを参照する場合を含む)には、その命
令(次の命令ではない)の先頭アドレスをPC値として使
用するので、注意が必要である。 【プログラム例外】 ・予約命令例外 ・P=‘1'のとき ・EaAがRn,#imm_data,@SP+,@−SPのとき ・奇数アドレスジャンプ例外 ・奇数アドレスにジャンプしたとき 【ニモニック】 ACB step,xreg,limit,newpc 【命令の機能】 add,compare and branch インデクス値を増加するループ命令 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第211図に示す。 【フラグ変化】 第212図に示す。 【解説】 加算、比較、条件ジャンプを一命令にした複合命令で
あり、ループのプリミティブとして利用する。 step、xreg、limitは符号付き整数として演算、比較
される。stepは必ず正しの値でない条件ジャンプの意味
がないが(xregが終了値と反対の方向に変化することに
なる)、stepの正負のチェックは行なわず、オペレーシ
ョンに書かれている通りの動作をそのまま行なう。 ACB命令では、ループ命令として高速実行ができるよ
うに、step加算時のオーバーフローのチェックは行なわ
ない。stepを加算した結果オーバーフローが起こり、符
号が反転した場合には、符号反転した正しくない値がそ
のままlimitと比較される。ただし、比較のためのlimit
−xregの減算がオーバーフローしたとしても、xreg<li
mitの比較は正確に行なわれる。 ACB,SCBではPC相対でジャンプを行なう。SS=00でデ
ィスプレースメントが8ビットになる場合も、SS≠00の
場合と同様に、#d8は2倍せずにそのまま使用する。SS
≠00の場合は、#d8のフィールドは使用せず(0にす
る)、SSで使用されたサイズ(16,32,64ビット)のデー
タが#dS8の直後に続く。例えば、 ACB:Q #1,R0,#4,label でlabelとACB:Q命令のアドレスの差がH′1234であった
場合は、第213図に示すビットパターンになる。これ
は、固定長ビットフィールド命令の:Iフォーマットでも
同じである。 [ACBのオペレーション] newpcが奇数であった場合には、ジャンプ先が奇数ア
ドレスになるため、奇数アドレスジャンプ例外(OAJE)
となる。本発明装置では、終了条件満足のためジャンプ
しなかった時も、奇数アドレスジャンプ例外(OAJE)を
発生する。[詳細仕様調整中] ACB,SCB命令でSS≠00の時には、#dS8のフィールドは
使用しない。この時、もし#dS8のフィールドが0にな
っていなくても、単に無視される。ただし、マニュアル
上は、#dS8のフィールドには常に0を入れるようにし
ておく。 本発明装置ではこの命令に対して、動的ブランチ予測
処理をする。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・XX=‘11'のとき ・SS=‘11'のとき ・P=‘1'のとき ・EaRが@−SPのとき ・EaRXが@−SPのとき ・奇数アドレスジャンプ例外 ・奇数アドレスにジャンプしたとき 【ニモニック】 SCB step,xreg,limit,newpc 【命令の機能】 subtract,compare and branch インデクス値を減少するループ命令 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第214図に示す。 【フラグ変化】 第215図に示す。 【解説】 減算、比較、条件ジャンプを一命令にした複合命令で
あり、ループのプリミティブとして利用する。 step、xreg、limitなどは符号付き整数として比較さ
れる。stepは必ず正の値でないと条件ジャンプの意味が
ないが、(xregが終了値と反対の方向に変化することに
なる)。stepの正負のチェックは行なわず、オペレーシ
ョンに書かれている通りの動作をそのまま行なう。 SCB命令では、ループ命令として高速実行ができるよ
うに、step減算時のオーバーフローのチェックは行なわ
ない。stepを減算した結果オーバーフローが起こり、符
号が反転した場合には、符号反転した正しくない値がそ
のままlimitと比較される。ただし、比較のためのlimit
−xregの減算がオーバーフローしたとしても、xreg<li
mitの比較は正確に行なわれる。 ACB,SCBではPC相対でジャンプを行なう。SS=00でデ
ィスプレースメントが8ビットになる場合も、SS≠00の
場合と同様に、#d8は2倍せずにそのまま使用する。SS
≠00の場合は、#d8のフィールドは使用せず(0にす
る)、SSで指定されたサイズ(16,32,64ビット)のデー
タが#dS8の直後に続く。 [SCBのオペレーション] newpcが奇数であった場合には、ジャンプ先が奇数ア
ドレスになるため、奇数アドレスジャンプ例外(OAJE)
となる。本発明装置では、終了条件満足のためジャンプ
しなかった時も、奇数アドレスジャンプ例外(OAJE)を
発生する。[詳細仕様調整中] ACB,SCB命令でSS≠00の時には、#dS8のフィールドは
使用しない。この時、もし#dS8のフィールドが0にな
っていなくても、単に無視される。ただし、マニュアル
上は、#dS8のフィールドには常に0を入れるようにし
ておく。 本発明装置ではこの命令に対して、動的ブランチ予測
処理をする。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・XX=‘11'のとき ・SS=‘11'のとき ・P=‘1'のとき ・EaRが@−SPのとき ・EaRXが@−SPのとき ・奇数アドレスジャンプ例外 ・奇数アドレスにジャンプしたとき 【ニモニック】 ENTER local,reglist 【命令の機能】 cteate new stack frame スタックフレームの形成、高級言語用サブルーチンチ
ャンプ 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第216図に示す。 【フラグ変化】 第217図に示す。 【解説】 高級言語用のスタックフレームを形成する。 ENTERのlocalは符号付きとして扱われ、localのサイ
ズが小さい場合には、localの値が符号拡張される。loc
alが負の場合は意味がないスタックフレームが形成され
るが、特にチェックは行なわず、オペレーションに書か
れている通りの動作を行なう。この点は、ACB,SCBのste
pと同じである。 オペレーション: FP−>↓TOS SP−>FP SP−local−>SP registers(mask)−>↓TOS 高級言語用のスタックフレームの詳細は、付録を参照
のこと。 退避するレジスタのビットマップ指定LnXLは、第218
図のように行なう。 LnXLは、EaRの拡張部よりも後に置かれる。 ENTERのreglistでbit0,bit1(SP,FP)を指定した場合
には、単にその指定が無視されるものとする。bit0,bit
1が“1"であっても、SP,FPは転送されない。これを不正
オペランド例外(IOE)としないのは、インプリメント
の負担が大きく、実効速度に影響が出るためである。た
だし、チェックが行なわれていなくても、FP,SPのビッ
トには必ず‘0'を入れてもらうように、マニュアル等で
指導する必要がある。 FP,SPのアライメントに関しては特にチェックしな
い。FP,SPが4の倍数でない場合にも、オペレーション
に書かれた通りの実行が行なわれる。 ENTER:Gのlocalオペランドがメモリ上にあり、それが
ENTER命令の実行に伴って形成されるスタックフレーム
領域と重なっていた場合には、命令再実行が極めて難し
くなる。そこで、ENTER:G,JRNG:G、および対称性からEX
ITD:G命令では、メモリアクセスを伴うアドレッシング
モード、つまりレジスタ直接Rnとイミディエート以外の
アドレッシングモードは、すべて禁止している。この命
令のオペランドとして動的な値を設定したい場合には、
テンポラリレジスタを一つ用意し、レジスタ直接Rnのモ
ードを利用するということになる。 localとしてFP,SPを指定した場合の動作は、インプリ
メント依存である。 【プログラム例外】 ・予約命令例外 ・X=‘1'のとき ・+=‘0'のとき ・−=‘1'のとき ・P=‘1'のとき SS=‘11'のとき ・EaR!Mが#imm_data,Rn以外のとき 【ニモニック】 EXITD reglist,adjsp 【命令の機能】 exit and deallocate parameters 高級言語用サブルーチンリターンとパラメータ解放 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第219図に示す。 【フラグ変化】 第220図に示す。 【解説】 高級言語用のスタックフレーム解放とレジスタの復帰
を行ない、サブルーチンから戻る。その後adjspをSPに
加え、スタック上に残っていたサブルーチンのパラメー
タを捨てる。 EXITDのadjspは符号付きとして扱われ、adjspのサイ
ズが小さい場合には、adjspの値が符号拡張される。adj
spが負の場合は意味のない動作をするが、特にチェック
は行なわず、オペレーションに書かれている通りに実行
を行なう。この点は、ACB,SCBのstepと同じである。 オペレーション: 高級言語用のスタックフレームの詳細は、付録を参照
のこと。 復帰するレジスタのビットマップ指定LxXLは、第221
図のように行なう。 LxXLは、EaRの拡張部よりも後に置かれる。 EXITDのreglistでbit14,bit15(SP,FP)を指定した場
合には、単にその指定が無視されるものとする。bit14,
bit15が“1"であっても、SP,FPは転送されない。これを
不正オペランド例外(IOE)としないのは、インプリメ
ントの負担が大きく、実効速度に影響が出るためであ
る。ただし、チェックが行なわれていなくても、FP,SP
のビットには必ず‘0'を入れてもらうように、マニュア
ル等で指導する必要がある。 FP,SPのアライメントに関しては特にチェックしな
い。FP,SPが4の倍数でない場合にも、オペレーション
に書かれた通りの実行が行なわれる。 EXITDで、スタックから復帰されたリターンアドレス
が奇数であった場合には、ジャンプ先が奇数アドレスに
なるため、奇数アドレスジャンプ例外(OAJE)となる。 EXITDのオペランドadjsp/Ear!Mでは、メモリアクセス
を伴うアドレッシングモード、つまりレジスタ直接Rnと
イミディエート以外のアドレッシングモードは、すべて
禁止している。この命令のオペランドとして動的な値を
設定したい場合には、テンポラリレジスタを一つ用意
し、レジスタ直接Rnのモードを利用するということにな
る。 adjspにレジスタ直接Rnのモードを利用し、reglistに
同じレジスタRnが含まれていた場合には、adjspとし
て、レジスタ復帰前の値を使用する。つまり、スタック
中に退避されていたEXITD命令実行後のレジスタ値では
なく、EXITD命令実行前のレジスタ値がadjspとなる。 adjspとしてFP,SPを指定した場合の動作は、インプリ
メント依存である。 【プログラム例外】 ・予約命令例外 ・X=‘1'のとき ・+=‘0'のとき ・−=‘1'のとき ・P=‘1'のとき SS=‘11'のとき ・EaR!Mが#imm_data,Rn以外のとき 【ニモニック】 RTS 【命令の機能】 reture from subroutine サブルーチンからのリターン 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第222図に示す。 【フラグ変化】 第223図に示す。 【解説】 サブルーチンからのリターンを行なう。 オペレーション: ↑TOS−>PC RTSで、スタックから復帰されたリターンアドレスが
奇数であった場合には、ジャンプ先が奇数アドレスにな
るため、奇数アドレスジャンプ例外(OAJE)となる。 【プログラム例外】 ・予約命令例外 ・P=‘1'のとき ・奇数アドレスジャンプ例外 ・リターンアドレスが奇数であったとき 【ニモニック】 NOP 【命令の機能】 no operation ノーオペレーション 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第224図に示す。 【フラグ変化】 第225図に示す。 【解説】 何もしない。 【プログラム例外】 ・予約命令例外 ・−=‘1'のとき 【ニモニック】 PIB 【命令の機能】 purge instruction buffer 命令キャッシュやパイプラインの整合性をとる 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第226図に示す。 【フラグ変化】 第227図に示す。 【解説】 命令パイプライン、命令キュー、命令キャッシュな
ど、命令実行の高速化のためのバッファ類をすべてパー
ジし、メモリ上に置かれた命令列とプロセッサの内部状
態との整合性を保証する。この命令は、これから実行す
べき命令コードが、以前(リセット時あるいは前回のPI
B命令実行時)から変更されている可能性があるという
ことを、プロセッサに通知するために使用する。 本発明装置では、パイプラインや命令キュー、命令キ
ャッシュの制御を簡単化するため、プログラムにより命
令コードを書き換えることは許されていない。 つまり、自分自信で書き換えを行なった命令コードを
そのまま実行しようとしても、動作が保証されない。と
ころが、OSの行なう処理をマクロ的に見ると、プログラ
ムをロードしてからそれを実行するという流れがある。
つまり、広い範囲で見るとOSのプログラムにより命令コ
ードを書き変えていることになる。また、特殊な用途で
は、プログラムによって生成した命令列を実行すること
もある。 この命令の目的は、そのような場合でも正しい命令の
実行ができるようにすることである。すなわち、書き換
えのあった命令コードに入る前にこの命令を実行してお
けば、新しい命令コードが正しく実行されることが保証
される。インプリメント上は、この命令によってパイプ
ライン、命令キュー、命令キャッシュのパージを行なう
ことになる。 ただし、パイプラインやキャッシュのメカニズムがメ
モリの書き換えに対するバスモニタリング機構を持って
おり、メモリとの整合性がハードウエアで常に保証され
ていれば、必ずしもPIB命令でパージを行なう必要はな
い。この場合、PIB命令はNOP命令として実行される。い
ずれにしても、この命令を実行した後に、パイプライン
や命令キャッシュとメモリとの整合性が保証されていれ
ば良いのである。 MMUを用いて多重論理空間を実現している場合には、P
IB命令を実行した論理空間に対してのみ書き変えた命令
コードの実行が保証される。例えば、 context_Aの命令コードを書き換え STCTX LDCTX context_B context_Bの命令コードを書き換え PIB といった命令列を実行した場合、context_Bでは変更さ
れた命令コードを実行しても動作が保証されるが、次に
LDCTX context_Aを実行した後でも、context_Aの変更さ
れた命令コードの実行に対しては動作が保証されない。
context_Aの命令実行を保証するためには、context_Aの
コンテキストにおいて、もう一度PIB命令を実行する必
要がある。これは、命令キャッシュにはLSIDが導入され
た場合に、PIB命令では、LSIDの一致する命令キャッシ
ュエントリをパージするだけで済ませたいからである。 PIB命令以外の命令では、いかなるジャンプ命令やOS
関連命令(LDCTX,REIT,RRNG,TRAP,EIT起動など)を実行
した後でも、命令コード書き換え部分のプログラムの動
作は保証されない。これは、命令キャッシュのパージを
できるだけ減らすためである。したがって、OSがロード
したプログラムを最初に実行する時には、新しいコンテ
キストに入ってから(例えばLDCTX〜REITの間で)、必
ずPIBを実行する必要がある。 この命令のニモニックPIB(Purge Instruction Buffe
r)の‘Buffer'は、キャッシュやパイプラインなどを総
括的に含めた意味で用いることばであり、PTLBの‘B'の
Bufferに同じ用例がある。PIBというニモニックも、PTL
Bとの連想から作られたものである。 この命令は特権命令ではない。ユーザプログラムから
も使用できる。 [命令コードの整合性について] PIB命令の動作を正確に説明するため、「命令コード
の整合性」という状態を以下のように定義する。 「命令コードの整合性」とは、各論理空間の各論理ア
ドレスについて、別々に定義される状態である。例え
ば、論理空間AではH′00000000〜H′000fffffについ
て「命令コードの整合性」が保証され、論理空間Bでは
H′00010000〜H′0003ffffについて「命令コードの整
合性」が保証されている、といった使い方をする。「命
令コードの整合性」が保証されている領域の命令を実行
した場合にのみ、正しい命令動作をする(executeのア
クセス権チェックを含む)ことが保証される。一般に
は、「命令コードの整合性」の保証されている領域が命
令コード領域であり、データ領域では「命令コードの整
合性」が保証されていない。 ・「命令コードの整合性」が保証されるようになるの
は、次の場合である。 −リセット時 物理空間(=論理空間)の全領域で「命令コードの整
合性」が得られる。 −PIB命令実行時 PIB命令を実行した論理空間の全領域で「命令コード
の整合性」が得られる。AT=00の場合は、リセット時と
同様、物理空間(=論理空間)の全領域で「命令コード
の整合性」が得られる。 ・「命令コードの整合性」が失われるようになるのは、
次の場合である。 −メモリ書き換え時 メモリ内容を書き変えた場合、書き変えた領域の「命
令コードの整合性」は失われる。これは、論理アドレス
によるメモリアクセスの場合も、物理アドレスによるメ
モリアクセスの場合(AT=00やLDP命令など)も同様で
ある。 −ATE更新時 ATEを更新した場合、そのATEによりアドレス変換され
る領域の「命令コードの整合性」は失われる。したがっ
て、例えば、LDATEでATE中の保護ビットを変更した場合
にも、その後PIB命令を実行しなければ保護情報のチェ
ックが正しく行なわれないことになる。(これは、命令
キャッシュと保護情報のチェックに関するインプリメン
トを軽くするために有効であろう) 以上の点に該当しない一般の命令実行ではBRA,JMP,JR
NG,RRNG,TRAP,REIT,LDCTX,EIT起動などを含めて、「命
令コード整合性の状態」は変化しない。 12−13.マルチプロセッサ用の命令 【ニモニック】 BSETI offset,base 【命令の機能】 ~bit−>Z_flag,1−>bit(interlocked) ビットのセット(バスをロック) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第228図に示す。 【フラグ変化】 第229図に示す。 【解説】 指定されたビットの値を反転したものをZ_flagにコピ
ーし、その後そのビットを1にセットする。この2つの
操作はバスをロックして行なわれ、不可分の操作にな
る。したがって、マルチプロセッサ間の同期をとるため
にこの命令が使用できる。 ShMfqi,EaMfiで指定されるアドレッシングモードで
は、レジスタ直接モードRn,@−SP,@SP+,#imm_data
のモードは使用できない。 アセンブラ表記では、メモリアクセスのサイズをbase
のサイズとして指定する。BSETI:Qでは、メモリアクセ
スのサイズは8ビットに固定されており、サイズは‘B'
のみを書くことができる。また、BSETI:G,BSETI:Eでの
アクセスサイズ(baseのサイズ).H,.Wの指定は、BSET,
BCLRと同じく<<L2>>とする。 <<2L>>仕様でアクセスサイズ.H,.Wを指定したの
に、baseがアライメントのとれていないアドレスであっ
た場合には、メモリアクセスの範囲がインプリメント依
存となる。これは、ビット操作命令と同様である。この
時、インプリメントによって、アライメントのとれてい
ないワードやハーフワードのアクセスが行なわれる場合
には、バスをロックしたまま複数のバスサイクルを実行
する。これはCSI命令と同様である。 本発明装置では<<L2>>となっているハーフワー
ド、ワード単位のアクセスのインプリメントを行なう。
またbaseとしてアライメントのとれていないアドレスを
指定した場合にも、アライメンのとれたハーフワード、
ワード単位でアクセスを行なう。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・BB=‘11'のとき ・EaRが@−SPのとき ・EaMfi,ShMfqiがRn,#imm_data,@SP+,@−SPのと
き 【ニモニック】 BCLRI offset,base 【命令の機能】 ~bit−>Z_flag,1−>bit(interlocked) ビットのクリア(バスをロック) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第230図に示す。 【フラグ変化】 第231図に示す。 【解説】 指定されたビットの値を反転したものをZ_flagにコピ
ーし、その後そのビットを0にセットする。この2つの
操作はバスをロックして行なわれ、不可分の操作にな
る。したがって、マルチプロセッサ間の同期をとるため
にこの命令が使用できる。 EaMfiで指定されるアドレッシングモードでは、レジ
スタ直接モードRn,@−SP,@SP+,#imm_dataのモード
は使用できない。 アセンブラ表記では、メモリアクセスのサイズをbase
のサイズとして指定する。BCLRI:G,BCLRI:Eでのアクセ
スサイズ(baseのサイズ).H,.Wの指定は、BSET,BCLRと
同じく<<L2>>とする。 <<2L>>仕様でアクセスサイズ.H,.Wを指定したの
に、baseがアライメントのとれていないアドレスであっ
た場合には、メモリアクセスの範囲がインプリメント依
存となる。これは、ビット操作命令と同様である。この
時、インプリメントによって、アライメントのとれてい
ないワードやハーフワードのアクセスが行なわれる場合
には、バスをロックしたまま複数のバスサイクルを実行
する。これはCSI命令と同様である。 本発明装置では<<L2>>となっているハーフワー
ド、ワード単位のアクセスのインプリメントを行なう。
またbaseとしてアライメントのとれていないアドレスを
指定した場合にも、アライメンのとれたハーフワード、
ワード単位でアクセスを行なう。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・BB=‘11'のとき ・EaRが@−SPのとき ・EaMfiがRn,#imm_data,@SP+,@−SPのとき 【ニモニック】 CSI comp,update,dest 【命令の機能】 compare and store(interlocked) 比較とストア(バスをロック) 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第232図に示す。 【フラグ変化】 第233図に示す。 【解説】 destの値が以前の値(compにより指定)と同じであれ
ば、内容を更新する命令である。 この命令は、簡単な構造のデータをマルチプロセッサ
から更新していく場合に利用できる。CSI命令を実行し
た結果、destの値が以前の値と異なっていることがわか
った場合、それは他のプロセッサがデータ内容を書き替
えたことを意味している。したがって、CSI命令によっ
てdestの値の食い違いを発見したプロセッサは、新しい
destの値をもとにして、そのデータ内容の更新をやり直
さなければならない。このような方法をとることによ
り、マルチプロセッサの下でデータの一貫性を保つこと
ができる。 [CSIのオペレーション] /*以下の動作はバスをロックして行なわれる*/ ビットパラーン上の制約から、CSIでは、比較が成功
しなくてもupdateの読みだしが行なわれる。また、CSI
命令でのdestのアクセス権は、常にread,writeとも必要
であるものとする。すなわちCSI命令で比較が失敗し、d
estに対して書き込みが起らない場合でも、destに対し
てwriteアクセス権がないとアドレス変換例外(ATRE)
になる。 RMC,EaMiRのサイズはRRで指定される。EaMiRで指定さ
れるアドレッシングモードでは、@−SP,@SP+,Rn,#i
mm_dataのモードは仕用できない。 CSI命令で、サイズ.H,.Wを指定し、アライメントの取
れていないアドレスをオペランドとした場合には、バス
をロックしたまま複数のバスサイクルを実行する。この
場合、read,writeのそれぞれが2回ずつのメモリアクセ
スに分かれるので、命令全体では、バスをロックしなが
らread,read,write,writeの4回のメモリアクセスを行
なうことになる。 なお、CSI以外の一般命令で、アライメントの取れて
いないアドレスに対してメモリアクセスを行なった場合
には、バスはロックされない。したがって、例えば、 var1 EQU H′00000006 ;アライメントの取れていないアドレス とした場合に、プロセッサAから MOV.W #H′12345678,@var1 を実行し、プロセッサBから MOV.W #H′87654321,@var1 を実行すると、メモリ書き込みのタイミングによって
は、 H′00000006〜7=H′8765 H′00000008〜9=H′5678 となって、プロセッサAのMOV命令が先に実行された場
合ともプロセッサBのMOV命令が先に実行された場合と
も異なる結果になる可能性がある。 マルチプロセッサ間の共有変数に対しては、通常デー
タの書き込みだけではなくデータ更新(read−modify−
write)を行なうのが普通なので、必然的にCSI命令を使
うことになり、以上のような問題は発生しない。しか
し、マルチプロセッサからSCI以外の命令でアライメン
トのとれていない変数をアクセスする場合には、以上の
ような問題が生じることがあるので、注意しておく必要
がある。 【プログラム例外】 ・予約命令例外 ・RR=‘11'のとき ・EaRが@−SPのとき ・EaMiRがRn,#imm_data,@SP+,@−SPのとき 12−14.制御空間、物理空間操作命令 本発明装置では、メインプロセッサの制御レジスタ群
が、コプロセッサの制御レジスタ群やチップバス上の高
速メモリなどとともに一つのアドレス空間を作ることが
できるようになっており、これを制御空間と呼ぶ。制御
空間の考え方は、現在別チップとなっているコプロセッ
サやコンテキスト退避用の高速メモリが、将来メインプ
ロセッサに内蔵された場合に、特に有効になる考え方で
ある。制御レジスタ操作命令は、制御空間に対してアク
セスを行なうための命令である。 なお、LDC,STCなどの汎用的な制御空間操作命令は特
権命令なっているため、ユーザが制御空間の一部である
PSB,PSMを操作するためには、LDPSB,STPSB,LDPSM,STPSM
命令を使用する。 本発明装置はアドレス変換機構を持たない。よって、
論理空間アドレスと物理空間アドレスがつねに等しいた
め物理空間操作命令の機能は論理空間を操作する他の命
令に吸収されてしまう。しかし、アドレス変換機構を持
ち、論理空間と物理空間を区別して扱う本発明装置との
ソフトウエア互換性を重視し、本発明装置では物理空間
操作命令をサポートする。 【ニモニック】 LDC src,dest 【命令の機能】 load control space or register 制御空間へのロード 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第234図に示す。 【フラグ変化】 第235図に示す。 【解説】 srcの値を制御空間のdestに転送する。srcのサイズが
destより小さいときは、符号拡張される。 dest/EaW%では、レジスタ直接モードRnの指定、@−
SPの指定はできない。 この命令は特権命令である。ring0以外から実行され
た場合には、特権命令違反例外(RIVE)となる。 本発明装置では制御空間に対する.B,.Hのアクセス機
能はサポートしない。制御空間としてはCPU内の制御レ
ジスタのみをインプリメントする。 また、UATB,SATBを実装していないためLDCによりUAT
B,SATBを変更することはできない。 LDATE,STATE,LDP,STP,LDC,STC,MOVPA命令の中の特殊
空間を参照するオペランドにおいて、付加モードにより
メモリの間接参照が起こった場合には、特殊空間の方で
はなく論理空間(LS)の方を参照する。また、スタック
ポインタSPの参照があった場合には、PRNGではなく現在
リングRNGのスタックが参照される。特殊空間のアドレ
スという意味を持つのは、最終的に得られた実効アドレ
スのみである。 制御空間に対する.B,.Hのアクセス機能が全くないプ
ロセッサにおいて、制御空間のオペランドのサイズとし
て.B,.Hを指定した場合には、予約命令例外(RIE)とな
る。 未実装の制御レジスタ、または制御レジスタのないア
ドレスをLDCで指定した場合には、予約機能例外(RFE)
となる。<<LV>>の領域についても同様である。 制御空間で利用できるアドレスに何らかの制限のある
プロセッサの場合、それに違反した場合には予約機能例
外(RFE)とする。例えば、制御レジスタのアドレスを
4の倍数に限るといった制限はこれに含まれる。コンテ
キスト退避用の高速メモリを内蔵したプロセッサであれ
ば、制御レジスタ部分のアドレスのみが4の倍数に制限
され、高速メモリ部分のアドレスは自由になるというケ
ースが考えられるが、この場合にも、違反すると予約機
能例外(RFE)になる。また、一部のアドレスについて
のみ.B,.Hの指定が可能なプロセッサにおいて、.B,.Hの
アクセスができないアドレスを指定した場合にも、予約
命令例外(RIE)ではなく予約機能例外(RFE)となる。
これは、命令ビットパターン(サイズ指定を含む)ので
エラーと判定できるものを予約命令例外(RIE)とし、
アドレスやオペランド値によってエラーかどうかの状態
が変化するものは予約機能例外(RFE)とする、という
考え方に基づいたものである。 制御空間のアドレスがチップ外(コプロセッサのアド
レスなど)になり、インプリメントの制約によってその
領域がアクセスできなくなっている場合にも、予約機能
例外(RFE)が発生する。LDC,STCでは、制御空間のアド
レスがコプロセッサのアドレスになった場合でも、プロ
セッサ命令例外(CIE)は発生しない。コプロセッサ命
令例外(CIE)が発生するのは、コプロセッサ用の命令
を実行した場合に限られる。 LDCで、制御レジスタの’−','+’で表現されるrese
rvedのビットに異なる値を書き込もうとした場合や、あ
るフィールドに対してreservedの値を書き込もうとした
場合には、予約機能例外(RFE)になる。PSWのSMRNGの
フィールドに'001'などのreservedの値を書き込んだ場
合も、これに含まれる。一方、’=','#’で表現され
ているreservedのビットに異なる値を書き込んだ場合に
は、単に無視される。ただし、ユーザ向けのマニュアル
では、’=’に対して必ず'0'を書き込んでもらうよう
に注意しなければならない。また、’*’で表現されて
いるビットには、何を書き込んでも単に無視される。こ
のビットは、’=','#’とは異なり、今後仕様を拡張
した場合でも、仕用されないことが保証されたビットで
ある。したがって、LDCを実行する前に、このビットを'
0'にマスクしておく必要はない。 LDCでCTXBBを変更した場合には、メモリ上のCTXBBの
内容と実際のチップ内のコンテキストとの整合性がとれ
なくなるが、これはプログラマの責任で処理する。ハー
ドウエア的には、単にCTXBBの変更のみを行なう。CTXBB
の変更とコンテキストのロードを両方行なう場合は、LD
CTXを使用すればよい。 LDC命令によってUTAB,STABが変更される時は、それに
伴ってTLBや論理キャッシュのパージ(PSTLB/ATに相当
する処理)が自動的に行なわれる。LSIDを実装したプロ
セッサの場合は、LSID制御レジスタにより指定される論
理空間がパージの対象となる。この場合、LDC命令に
は、PSTLB命令のような/SS,/ASのオプションは設けられ
ていないが、これは次のような理由によっている。 PTLB,PSTLB命令によるTLBのパージの場合は、LDC*,U
ATBの場合とは異なり、他の論理空間のキャッシュやTLB
もパージできるように、LSIDの機能に相当するパラメー
タを、別のレジスタ(R1)によって指定している。この
場合、LSIDの制御レジスタは使用しない。したがって、
そのパラメータを使用するかどうかを区別するために、
/SS,/ASのオプションを切り換える必要がある。ところ
が、LDC*,UATBの場合は、データの矛盾をなくするため
に、現在使用中の空間に対してキャッシュやTLBのパー
ジを行なうのであるから、LSIDの制御レジスタは本来の
意味で働く。つまり、一般のメモリアクセスと同様に、
LSID制御レジスタによって指定された論理空間がパージ
の対象となる。LSID未実装のプロセッサでは、全論理空
間(一つだけであるが)がパージの対象となる。 【プログラム例外】 ・予約命令例外 ・RR='11'のとき ・WW='10'以外のとき ・EaRが@−SPのとき ・EaW%がRn,#imm_data,@SP+,@−SPのとき ・特権命令違反例外 ・ring0以外から実行されたとき ・予約機能例外 ・未実装の制御レジスタをアクセスしたとき ・制御レジスタの特定フィールドに対してreservedの値
を書き込もうとしたとき(=,#,*は除く) ・EaW%のアドレスのワードアラインメントがとれてい
ないとき 【ニモニック】 STC src,dest 【命令の機能】 store control space or register 制御空間からのストア 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第236図に示す。 【フラグ変化】 第237図に示す。 【解説】 制御空間にあるsrcの値をdestに転送する。STCでは、
srcとdestのサイズが共通に指定されるため、異種サイ
ズ間の転送は行なわれない。 この命令は特権命令である。ring0以外から実行され
た場合には、特権命令違反例外(PIVE)となる。 src/EaR%では、レジスタ直接モードRnの指定、イミ
ディエート#imm_dataの指定、@SP+の指定はできな
い。 本発明装置では、制御空間に対する.B,.Hのアクセス
機能はサポートしない。制御空間についてはCPU内の制
御レジスタのみをインプリメントする。 LDATE,STATE,LDP,STP,LDC,STC,MOVPA命令の中の特殊
空間を参照するオペランドにおいて、付加モードにより
メモリの間接参照が起こった場合には、特殊空間の方で
はなく論理空間(LS)の方を参照する。また、スタック
ポインタSPの参照があった場合には、PRNGではなく現在
リングRNGのスタックが参照される。特殊空間のアドレ
スという意味を持つのは、最終的に得られた実効アドレ
スのみである。 制御空間に対する.B,.Hのアクセス機能が全くないプ
ロセッサにおいて、制御空間のオペランドのサイズとし
て.B,.Hを指定した場合には、予約命令例外(RIE)とな
る。 未実装の制御レジスタ、または制御レジスタのないア
ドレスをSTCで指定した場合には、予約機能例外(RFE)
となる。<<LV>>の領域についても同様である。 制御空間で利用できるアドレスに何らかの制限のあるプ
ロセッサの場合、それに違反した場合には予約機能例外
(RFE)とする。例えば、制御レジスタのアドレスを4
の倍数に限るといった制限はこれに含まれる。コンテキ
スト退避用の高速メモリを内蔵したプロセッサであれ
ば、制御レジスタ部分のアドレスのみが4の倍数に制限
され、高速メモリ部分のアドレスは自由になるというケ
ースが考えられるが、この場合にも、違反すると予約機
能例外(RFE)になる。また、一部のアドレスについて
のみ.B,.Hの指定が可能なプロセッサにおいて、.B,.Hの
アクセスができないアドレスを指定した場合にも、予約
命令例外(RIE)ではなく予約機能例外(RFE)となる。
これは、命令ビットパターン(サイズ指定を含む)のみ
でエラーと判定できるものを予約命令例外(RIE)と
し、アドレスやオペランド値によってエラーかどうかの
状態が変化するものは予約機能例外(RFE)とする、と
いう考え方に基づいたものである。 制御空間のアドレスがチップ外(コプロセッサのアド
レスなど)になり、インプリメントの制約によってその
領域がアクセスできなくなっている場合にも、予約機能
例外(RFE)が発生する。LDC,STCでは、制御空間のアド
レスがコプロセッサのアドレスになった場合でも、コプ
ロセッサ命令例外(CIE)は発生しない。コプロセッサ
命令例外(CIE)が発生するのは、コプロセッサ用の命
令を実行した場合に限られる。 STCで、制御レジスタの’−’で表現されているビッ
トを読みだした場合には'0'が、’+’のビットを読み
だした場合には'1'が読み出される。また、’=','
#','*’のビットを読み出そうとした場合に得られる
値は、不定である。インプリメントによって、'0'固定
の場合、'1'固定の場合、以前に書き込んだ値がそのま
ま読み出される場合がある。将来の拡張のため、’
=','#','*’のビットの値を利用したプログラミング
は行なわないように、ユーザ向けのマニュアルに明記し
なければならない。 【プログラム例外】 ・予約命令例外 ・WW='10'以外のとき ・EaR%がRn,#imm_data,@SP+,@−SPのとき ・EaWが#imm_data,@SP+のとき ・特権命令違反例外 ・ring0以外から実行されたとき ・予約機能例外 ・未実装の制御レジスタをアクセスしたとき ・EaR%のアドレスのワードアラインメントがとれてい
ないとき 【ニモニック】 LDPSB src 【命令の機能】 load PSB PSBへのロード 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第238図に示す。 【フラグ変化】 第239図に示す。 【解説】 srcをPSBに転送する。 ユーザのコルーチンなどで、PSB,PSMの個々のビット
の意味とは関係なく退避や復帰を行なう場合を除けば、
PSM,PSBでは、一部のフィールドのみの書き換えをした
いということが多い。そのため、LDPSB,LDPSM命令のsrc
オペランドは16ビット(EaRh)となっており、上位バイ
トがマスク(変更されるビットを0とする)、下位バイ
トが変更データを表わすという仕様になっている。つま
り、srcを src=[S0.S1……S7.S8.S9……S15] とすると、 [LDPSBのオペレーション] ([S0.S1……S7].and.PSB).or.(-[S0.S1・・・S
7] ただし’-’はビット否定 となる。例えば、2^4の位置にあるX_flagをセットする
命令は、 LSPSB #H'ef10 となる。 上位バイトで、変更されるビットの方を0、変更され
ない方を1としたのは、変更される方をデフォルトと考
える方が自然だと判断したからである。8ビット全部を
変更する場合には、上位バイトをすべて0にして単なる
バイトデータを書けばよい。8ビット全部の変更は、最
初に述べたように、ユーザ側でPSB,PSMの退避や復帰を
する場合に必要である。 LDPSB,LDPSMで、PSB,PSMの未使用フィールドの値を"
1"にしようとした場合には、予約機能例外(RFE)が発
生する。 【プログラム例外】 ・予約命令例外 ・EaRhが@−SPのとき 【ニモニック】 LDPSM src 【命令の機能】 load PSM PSMへのロード 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第240図に示す。 【フラグ変化】 第241図に示す。 【解説】 srcをPSMに転送する。 ユーザのコルーチンなどで、PSB,PSMの個々のビット
の意味とは関係なく退避や復帰を行なう場合を除けば、
PSM,PSBでは、一部のフィールドのみの書き換えをした
いということが多い。そのため、LDPSB,LDPSM命令のsrc
オペランドは16ビット(EaRh)となっており、上位バイ
トがマスク(変更されるビットを0とする)、下位バイ
トが変更データを表わすという仕様になっている。つま
り、srcを src=[S0.S1……S7.S8.S9……S15] とすると、 [LDPSMのオペレーション] ただし’-’はビット否定 となる。 LDPSB,LDPSMで、PSB,PSMの未使用フィールドの値を"1"
にしようとした場合には、予約機能例外(RFE)が発生
する。 【プログラム例外】 ・予約命令例外 ・EaRhが@−SPのとき 【ニモニック】 STPSB dest 【命令の機能】 store PSB PSBからのストア 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第242図に示す。 【フラグ変化】 第243図に示す。 【解説】 PSBをdestに転送する。上位8ビットは必ず0とな
る。 destが8ビットではなく16ビットとなっており、上位
8ビットが常に0を返すようになっているのは、LDPSM,
LDPSBでそのままPSM,PSBの復帰ができるように配慮した
ためである。 【プログラム例外】 ・予約命令例外 ・EaWhが#imm_data,@SP+のとき 【ニモニック】 STPSM dest 【命令の機能】 store PSM PSMからのストア 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第244図に示す。 【フラグ変化】 第245図に示す。 【解説】 PSMをdestに転送する。上位8ビットは必ず0とな
る。 destが8ビットではなく16ビットとなっており、上位
8ビットが常に0を返すようになっているのは、LDPSM,
LDPSBでそのままPSM,PSBの復帰ができるように配慮した
ためである。 【プログラム例外】 ・予約命令例外 ・EaWhが#imm_data,@SP+のとき 【ニモニック】 LDP src,dest 【命令の機能】 load physical space 物理空間へのロード 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第246図に示す。 【フラグ変化】 第247図に示す。 【解説】 srcの値を物理空間のdestに転送する。srcのサイズがde
stより小さいときは、符号拡張される。 本発明装置はアドレス変換機構を持たないので論理空
間アドレスと物理空間アドレスがつねに等しく、この命
令の機能はMOV命令に吸収されてしまう。しかし、アド
レス変換機構をもち論理空間と物理空間を区別して扱う
本発明装置とのソフトウエア互換性を取るためこの命令
をサポートする。 この命令は特権命令である。 dest/EaW%では、レジスタ直接モードRnの指定、@−SP
の指定はできない。 LDATE,STATE,LDP,STP,LDC,STC,MOVPA命令の中の特殊
空間を参照するオペランドにおいて、付加モードにより
メモリの間接参照が起こった場合には、特殊空間の方で
はなく論理空間(LS)の方を参照する。また、スタック
ポインタSPの参照があった場合には、PRNGではなく現在
リングRNGのスタックが参照される。特殊空間のアドレ
スという意味を持つのは、最終的に得られた実効アドレ
スのみである。 【プログラム例外】 ・予約命令例外 ・RR='11'のとき ・WW='11'のとき ・EaRが@−SPのとき ・EaW%がRn,#imm_data,@SP+,@−SPのとき ・特権命令違反例外 ・ring0以外から実行されたとき 【ニモニック】 STP src,dest 【命令の機能】 store physical space 物理空間からのストア 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第248図に示す。 【フラグ変化】 第249図に示す。 【解説】 物理空間にあるsrcの値をdestに転送する。 STPでは、srcとdestのサイズが共通に指定されるた
め、異種サイズ間の転送は行なわれない。 本発明装置はアドレス変換機構を持たないので論理空
間アドレスと物理空間アドレスがつねに等しく、この命
令の機能はMOV命令に吸収されてしまう。しかし、アド
レス変換機構を持ち論理空間と物理空間を区別して扱う
本発明装置とのソフトウエア互 換性を取るためこの命
令をサポートする。 この命令は特権命令である。 src/EaR%では、レジスタ直接モードRnの指定、イミデ
ィエート #imm_dataの指定、@SP+の指定はできな
い。 LDATE,STATE,LDP,STP,LDC,STC,MOVPA命令の中の特殊
空間を参照するオペランドにおいて、付加モードにより
メモリの間接参照が起こった場合には、特殊空間の方で
はなく論理空間(LS)の方を参照する。また、スタック
ポインタSPの参照があった場合には、PRNGではなく現在
リングRNGのスタックが参照される。特殊空間のアドレ
スという意味を持つのは、最終的に得られた実効アドレ
スのみである。 【プログラム例外】 ・予約命令例外 ・WW='11'のとき ・EaR%がRn,#imm_data,@SP+,@−SPのとき ・EaWが#imm_data,@SP+のとき ・特権命令違反例外 ・ring0以外から実行されたとき 12−15.OS関連命令 【ニモニック】 JRNG vector(「本発明装置」ではサポートしな
い) 【命令の機能】 jump to new ring リング間コール 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第250図に示す。 【フラグ変化】 第251図に示す。 【解説】 リング間の遷移とジャンプ(リング間コール)を行な
う。この命令は、現在のリングよりも内側のリングレベ
ルにあるプログラムの呼び出し(システムコールの呼び
出しを含む)を行なうために使用される。 外側のリングから内側のリングを保護するため、JRNG
でのジャンプ先は特定のアドレスに制限されている。こ
のアドレスを入れたテーブルをリング間遷移テーブルJR
NGVT(JRNG Vector table)と呼ぶ。JRNG命令では、vec
torオペランドがJRNGVTに対するインデクスとなる。JRN
GVTの一つのエントリを、JRNGVTEと呼ぶ。 JRNGVTは、vectorに対するエントリを65535個持つテ
ーブルであり、そのベースの論理アドレスがJRNGVBによ
って示される。vectorのサイズは16ビットとなってい
る。JRNGVBは制御レジスタの一つであり、次のような構
成になっている。 ・JRNGVB JRNGVBは、第252図に示すようにJRNG命令のベクトル
テーブルの先頭の論理アドレスを示す。テーブルのベー
スアドレスは、アラインメントのため、下位の3ビット
が0に固定される。 EがOの時はJRNGが実行禁止であり、JRNGを実行する
とリング遷移違反例外(RTVE)となる。この時、JRNGVB
は意味を持たないので、OSはこのフィールドを自由に使
用して良い。 ’=’のビットには'0'を入れておかなければならな
い。ただし、このビットが0でなくても単に無視され
る。 JRNGVTEは8バイトであり、第253図のような構成にな
っている。これは、内側のリングへ入るためのゲートと
いう意味合いをもったものである。 ・ARの機能は、そのvectorで示されるエントリのリング
間コールが、最低でどのリングから発行可能であるかを
示すものである。ARで示されるリングよりも現在のリン
グの方が外側の場合には、リング間コール(システムコ
ール)が許可されていないものと見なされ、リング遷移
違反例外(RTVE)となる。ARは、その意味から考えて、
PSWのPRNGの位置に相当するフィールドを使う。これ
は、JRNGVT,EITVTの各エントリが、基本的にはPSW+PC
のサブセットの形になっているという考え方に基づいた
ものである。 ・VXの機能は、OSとユーザプログラムとの間で32/64ビ
ットのモードが異なっている場合に有効である。 ・JRNGVTEの未使用フィールド(’=’で示される)、
および'VX'ビットには、'0'を入れておかなければなら
ない。ただし、実際には、これらのビットが'1'であっ
たとしても、単に無視されるだけである。これを予約機
能例外(RFE)としないのは、インプリメントの負担を
考えたためである。[詳細仕様調整中] ・また、JRNGVTEのVPCのフィールドは偶数でなければな
らない。つまり、VPCのフィールドのLSBは'0'でなけれ
ばならない。違反した場合には、JRNG実行時に奇数アド
レスジャンプ例外(OAJE)が発生する。[詳細仕様調整
中] JRNGVBはMSB=0の時UATB、MSB=1の時SATBを使って
アドレス変換される。JRNGVBのアドレスを論理アドレス
としたのは、次のような利点があるためである。 テーブルをコンテキスト毎に持つことが可能 テーブルの仮想化が可能である。すなわち、テーブル
自体をページ不在にすることができる。 EITであるTRAPAとの性格の違いが、よりはっきりす
る。 JRNGVBを論理アドレスと考えることにより、テーブル
の仮想化が可能となる。「本発明装置」では、ベクトル
が16ビット(65536エントリ、512KBテーブルサイズ)で
非常に多くなっており、しかもベクトルの上限を指定す
るレジスタが設けられていない。しかし、JRNGVBが論理
アドレスとなっているため、MMU機能との組合わせが可
能であり、必ずしもテーブル分の物理メモリを負担する
必要はなくなっている。JRNGVT部分のSTE,PTEを未使用
領域にしておけば、16ビット=65536エントリ分のテー
ブルをすべて物理メモリで用意する必要はない。 JRNGVTEの読みだしは、論理アドレスを用いた一般の
メモリアクセスと同様に行なわれる。したがって、JRNG
VTEは、JRNGを実行したプログラムのリングのアクセス
権で読み出される。JRNGを実行したリングから、指定し
たベクトルのJRNGVTEをreadする権利がない時は、アド
レス変換例外(ATRE)のリング保護違反エラーになる。
また、指定したベクトルのJRNGVTEが未使用領域となっ
ていた場合には、アドレス変換例外(ATRE)の未使用領
域参照エラーとなる。使用する側から見ると、これらの
エラーはリング遷移違反例外(RTVE)と同じように扱わ
れる方が望ましいのであるが、主としてインプリメント
の都合により、上記のような仕様になっている。JRNGVT
Eの読み出しの際には、このほかページ不在例外(PO
E)、バスアクセス例外(BAE)などの発生する可能性が
ある。 JRNG機能の導入により、JRNGVTのための論理空間を必
ず512KB消費することになる。また、不当なリング間コ
ールを防ぐためには、ユーザプログラムを実行する前
に、OSがJRNGVTの領域のSTE,PTEのセットを行なってお
く必要がある。そこで、リング間コール機能を使用しな
い場合に、こういった処理が全く不用になるように、リ
ング間コール機能全体をディスエーブルにすることがで
きるようになっている。この指定には、JRNGVBのLSBの
Eビットを使う。JRNGVBのEビットが0の場合は、リン
グ間コール機能は使用できなくなり、JRNGを実行した場
合には無条件にリング遷移違反例外(RTVE)となる。 結局、JRNGが成功するには次の条件を満たさなければ
ならない。 −−−JRNGVBのE=1。 E=0であれば、JRNGVTが用意されていないことを意
味するのでリング遷移違反例外(RTVE)となる。 −−−指定したベクトルに対するJRNGVTEが、JRNG実
行前のリングからread可能。 ページ不在例外が発生した場合は、ページインの後再
実行することになる。 アドレス変換例外(ATRE)の未使用領域参照エラーが
発生した場合は、そこまでテーブルが用意されていない
ことを意味するので、そのユーザプログラムにエラーを
返すのが普通である。 readのアクセス権がない場合は、保護の観点からJRNG
の実行を禁止していることを意味するので、やはりその
ユーザプログラムにエラーを返すのが普通である。これ
はVAフィールドと同等の意味になるが、512ベクトル毎
の指定となる。 −−−現在リング≧VRが成立。 外側のリングには行けない。違反した場合はリング遷
移違反例外(RTVE)となる。 −−−現在リング≦ARが成立。 受け付け可能リングのチェック。違反した場合はリン
グ遷移違反例外(RTVE)となる。なお、ARはJRNGVTEのA
Rフィールドである。 [JRNGのオペレーション] JRNG命令により形成されるスタックフレームは、第25
4図のようになる。 ここで、旧リングのSPを新リングのスタックに積んだ
のは、新リングから旧リングのスタックポインタSPやス
タックをアクセスするためである。リング毎のスタック
は制御レジスタとしてアクセス可能であるが、アクセス
のためには特権命令(STC)を利用しなければならな
い。したがって、例えばring1からring3のスタックに積
まれたパラメータを見たいという場合には、この機能が
必要である。 JRNGでは、PSSの一部とPSMのPRNGのみが更新され、PS
Bは更新されない。また、リング間コールの機能では、E
ITとは異なり、スタックフォーマットは一種類しかない
ので、FORMAT(EITINF)はスタックに積まれない。 JRNG:Eの場合は、vectorがゼロ拡張される。 AT=00(アドレス変換なし)の場合は、JRNGVBは物理
アドレスを表わす。 JRNG実行時に、リング遷移違反例外(RTVE)などの命
令再実行型のEITが発生した場合、JRNG固有の機能であ
るリング間コール用のスタックフレームの形成は行なわ
れず、EIT処理用のスタックフレームのみが形成され
る。例えば、SMRNG=000の状態でJRNGを実行し、RNG=0
0にジャンプしようとしたが、何らかのエラーによりEIT
が発生した場合は、第255図のようなスタックフレーム
になる。第256図ではない。 (A)のような仕様になっているのは、EIT発生後の
命令再実行のことを考えているからである。つまり、EI
T処理ハンドラに入る前に、プロセッサの状態をできる
だけ命令実行前の状態に戻そうとしているからである。 EITで使用するスタックとJRNGで使用するスタックが異
なっていた場合は、EIT発生時にEITで使用するスタック
のみが変化し、JRNGで使用するスタックのSPは変化しな
い。 JRNGでは、現在リングと同じリングにジャンプするこ
とも可能である。この場合、JRNGでスタックの切り換え
は起こらない。SPとしてスタックにプッシュされる値
は、命令実行前のSPの値になる。これは、JRNG命令の最
初でPUSHSPを実行したのと同じ動作である。この様子を
第257図に示す。 JRNGで現在リングと同じリングにジャンプする場合
に、JRNG:Gのvectorオペランドがメモリ上にあり、それ
がJRNG命令の実行に伴って形成されるスタックフレーム
領域と重なっていると、命令再実行がきわめて難しくな
る。そこで、JRNG:G命令では、メモリアクセスを伴うア
ドレッシングモード、つまりレジスタ直接Rnとイミディ
エート以外のアドレッシングモードは、すべて禁止して
いる。この命令のオペランドとして動的な値を設定した
い場合には、テンポラリレジスタを一つ用意し、レジス
タ直接Rnのモードを利用する必要がある。 リング間コールの機能はEITには含めない。 TRAPAとJRNGは、どちらもOSのシステムコールの呼出し
を行なうことを目的にした命令である。一般には、BTRO
Nのようにシステムコールの数が多く、複数のリングを
利用するOSではJRNGを利用し、ITRONのようにシステム
コールの数があまり多くなく、2リングで十分なOSでは
TRAPAを利用することになる。 TRAPAでは、ring1,ring2に行くことはできないので、
BTRONで外核をring1に置く場合には、当然JRNGを使う必
要がある。 なお、OSをユーザが拡張するような場合には、外向き
のリング間コールが必要になることがあり、BTRONでも
そういった例がある。しかし、頻度としては多くないこ
と、リング保護の趣旨とは矛盾していること、完全な保
護を行なうためにはリターンスタックを別に設ける必要
があり、インプリメントの負担が大きくなること、など
の理由により、命令セットのレベルでは外向きの リング間コールをサポートしない。 【プログラム例外】 ・予約命令例外 ・P='1'のとき ・EaRh!MがRn,#imm_data以外のとき ・<<L1>>機能例外 ・JRNGの正しいビットパターンがデコードされたとき 【ニモニック】 RRNG(「本発明装置」ではサポートしない) 【命令の機能】 return from previous ring リング間リターン 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第258図に示す。 【フラグ変化】 第259図に示す。 【解説】 リング間コールに対するリターンを行なう。 [RRNGのオペレーション] このほか、RRNG命令実行時にはDCEのEITが起動される
場合があり、そのチェックを行なう必要がある。詳しく
は付録9を参照。 ここで、PRNGの旧のスタックポインタをRNGのスタッ
クからポップして、再びPRNGのスタックポインタとして
設定しているのは、PRNGのスタックに積まれたシステム
コールのパラメータのポップなどにより、OS側からユー
ザのスタックポインタを更新することを想定したためで
ある。 RRMGで内側のリングに入ろうとした場合には、リング
遷移違反例外(RTVE)となる。また、スタックからポッ
プされたPCが奇数であった場合には、奇数アドレスジャ
ンプ例外(OAJE)となる。 現在のPSWのSMが0で、RRNG命令によりポップされる
スタック中のRNG(上記オペレーション中のtempl<RNG
>)が0でない場合は、RRNG命令の実行によって、PSW
中のSMとRNGの組み合せがreservedのパターンとなる。
この場合には、予約機能例外(RFE)となる。 RRNG命令で、命令再実行型の例外であるRTVE,RFEが発
生した場合には、RRNG命令実行後に無くなる予定であっ
たリング間コールのスタックフレームが、そのまま残
る。したがって、EITとリング間コールで同じスタック
を使っていた場合には、そのスタックフレームに追加さ
れる形でEITのスタックフレームが形成される。また、E
ITとリング間コールで異なるスタックを使っていた場合
には、リング間コールで使用していたスタックの内容や
スタックポインタは変化しない。この点は、RRNGでDCE
を起動する場合とは異なっている。DCEの場合には、前
のリング間コールのスタックフレームをクリアしてか
ら、DCEの新しいスタックフレームを構成する。 <<RFE発生時のスタックの例−EITで同じスタックを利
用する場合>> 第260図に示す これに対して、OAJEは命令完了型のEITとなる予定であ
る。[詳細仕様調整中] その場合は、DCEと同じように、リング間コールのス
タックフレームをクリアしてからEITのスタックフレー
ムを生成するということになる。RRNG命令でOAJEが発生
する場合のスタックの動きは、次のようになる。 <<OAJE発生時のスタックの例−EITで同じスタックを
利用する場合>> (RRNG実行前) 第261図に示す (RRNG実行後、OAJE起動後) 第262図に示す RRNG命令でスタック中からポップされたPSW(上記のt
empl)のうち、PSH,RNG,XA以外のフィールドは、無視さ
れる。ただし、プログラミング上は、JRNG命令からRRNG
命令までの間で、スタック中に退避されたPSWのPSH,RN
G,XA以外のフィールドを書き換えてはいけない。 RRNG命令(32ビット)で同じリングに戻る場合、SPの
最終値は (ただし、+8はPC,PSWの分) となる。これは、PC,PSWの処理の後POP SPを実行したの
と同じ動作である。 JRNGVBのEビットは、RRNG命令の動作には関係しな
い。Eビットが0の場合にも、RRNG命令の実行は行なわ
れる。 【プログラム例外】 ・予約命令例外 ・P='1'のとき ・<<L1>>機能例外 ・RRNGの正しいビットパターンがデコードされたとき 【ニモニック】 TRAPA vector 【命令の機能】 TRAP always ソフトウエア割り込み、トラップ 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第263図に示す 【フラグ変化】 第264図に示す 【解説】 内部割り込み(トラップ)を発生する。 この命令は、ユーザプロセスからOSを呼ぶ場合などに利
用する。TRAPA命令ではEITが起動されるので、必ずリン
グ0に入ることになる。 TRAP,TRAPAでは、その他のEIT処理と同じく、PSSの一
部およびPSMのPRNGのみが更新される。PSMのPRNG以外の
フィールド(PSBを含む)は更新されない。 【プログラム例外】 ・予約命令例外 ・P='1'のとき ・無条件トラップ命令 【ニモニック】 TRAP 【命令の機能】 TRAP conditionally 条件によるソフトウエア割り込み、トラップ 【命令オプション】 /条件指定各種(cccc) 【命令ビットパターンとアセンブラ表記】 第265図に示す 【フラグ変化】 第266図に示す 【解説】 指定された条件が満たされていた場合に内部割り込み
(トラップ)を発生する。 TRAP命令ではEITが起動されるので、必ずリング0に入
ることになる。条件の指定方法は、Bcc命令と同じであ
る。 TRAP,TRAPAでは、その他のEIT処理と同じく、PSSの一
部およびPSMのPRNGのみが更新される。 PSMのPRNG以外のフィールド(PSBを含む)は更新され
ない。 TRAPで未定義の条件を指定した場合には、予約命令例
外(RIE)となる。 【プログラム例外】 ・予約命令例外 ・P='1'のとき ・cccc='1110,1111'のとき ・条件トラップ命令 【ニモニック】 REIT 【命令の機能】 return from EIT EIT処理(割り込み、例外処理)からのリターン 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第267図に示す 【フラグ変化】 第268図に示す 【解説】 「本発明装置」では、例外、外部割り込み、内部割り
込みを総称してEIT(Exception,Interrupt,Trap)と呼
ぶ。REIT命令は、EITからのリターン、すなわち、OSか
らのリターンや割り込み処理からのリターンを行なうた
めに使用する命令である。 この命令は特権命令である。 [REITのオペレーション] このほか、EITのタイプによっては、スタックに付加
情報が積まれている場合がある。それをポップしてEIT
発生前の状態に戻す。追加情報の有無は、FORMAT/VECTO
R(EITINF)で判定する。また、REIT命令実行時には、D
I,DCEのEITが起動される場合があり、そのチェックを行
なう必要がある。 詳しくは付録9を参照。 FORMAT/VECTORとして、サポートされないスタックフ
ォーマットが指定されていた場合には、予約スタックフ
ォーマット例外(RSFE)となる。この場合、フォーマッ
トが不当であったスタックフレームは、追加情報の有無
が判定できないためにそのまま残し、そのスタックフレ
ームに追加される形でRSFEのスタックフレームが形成さ
れる。この点は、REITでDI,DCEを起動する場合とは異な
っている。DI,DCEの場合には、前のEITのスタックフレ
ームをクリアしてから、DI,DCEの新しいスタックフレー
ムを構成する。 <<RSFEの処理−RSFEで同じスタックを利用する場合>
> 第269図に示す REIT命令で、スタックからポップされたPCが奇数であ
った場合には、奇数アドレスジャンプ例外(OAJE)とな
る。また、スタックからポップされたPSWによって、PSW
内のreserved(’−’)のビット(XAビットを含む)
を'1'に書き換えようとした場合や、SMRNGとしてreserv
edの値を書き込もうとした場合には、予約機能例外(RF
E)となる。 SMビットの変化については特にチェックしない。EIT
から戻るためにREIT命令を使う限り、REIT命令の実行に
よってSMが1から0に変わることはないはずである。し
かし、これは運用上の問題として対応することにし、RE
IT命令ではSMが1から0になったかどうかのチェックは
行なわない。 【プログラム例外】 ・予約命令例外 ・P='1'のとき ・特権命令違反例外 ・ring0以外から実行されたとき ・予約スタックフォーマット例外 ・EITから復帰する際に、サポートされていないスタッ
クフォーマットが指定されたとき ・奇数アドレスジャンプ例外 ・スタックからポップされたPCが奇数であったとき ・予約機能例外 ・スタツクからポップされたPSWによって、PSW内にrese
rvedの値を書き込もうとしたとき 【ニモニック】 WAIT imask 【命令の機能】 set IMASK and wait 停止、割り込み待ち 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第270図に示す 【フラグ変化】 第271図に示す 【解説】 PSWのIMASKフィールドをセットし、プログラムの実行
を停止する。外部割り込みまたはリセットにより実行を
再開する。 この命令は特権命令である。 imaskは、符号なしの数として解釈される。 imask≧16の場合には、予約機能例外(RFE)を発生す
る。 外部割り込みの場合には、割り込みが起るまで確定でき
ない情報(SPI/SPOのスタックが選択、ベクトル番号)
がある。したがって、WAIT命令では、外部割り込みが発
生してから情報をスタックに退避する。 [WAITのオペレーション]【プログラム例外】 ・予約命令例外 ・−='1'のとき ・特権命令違反例外 ・ring0から実行されたとき 【ニモニック】 LDCTX ctxaddr 【命令の機能】 load context from CTXB コンテキストのロード 【命令オプション】 /LS 論理空間からCTXBをロード /CS 制御空間からCTXBをロード <<L2>> 【命令ビットパターンとアセンブラ表記】 第272図に示す 【フラグ変化】 第273図に示す 【解説】 ctxaddrで示される実効アドレスをCTXBBレジスタにロ
ードし、タスクやプロセスのコンテキストブロック(CT
XB)の内容をプロセッサのレジスタにロードする。ロー
ドの行なわれるレジスタは、MMUの有無やCTXBFMの内容
によって変化するが、SP0〜SP3,UATB,CSWなどが含まれ
る。LDCTXで転送されるレジスタの詳細については、付
録8を参照のこと。 /LSオプションを指定した場合には、ctxaddrは論理空
間のアドレスを意味する。この場合には、論理空間上に
CTXBが置かれていることになる。また、/CSオプション
を指定した場合には、ctxaddrは制御空間のアドレスを
意味する。このオプションは、将来コンテキスト退避用
の高速メモリをチップに内蔵した場合に使用することを
想定したものであり、現在は<<L2>>となっている。
これらのオプションは、チップやチップバスのインプリ
メントに合わせて最も高速なコンテキストスイッチを行
なうため、CTXBを置く空間に自由度を持たせるという目
的で設けられたものである。 「本発明装置」では/CSオプションはサポートしな
い。 「本発明装置」標準のMMUを内蔵したプロセッサで
は、LDCTX命令でUATBの変更が行なわれる。この場合、L
SIDを実装しないプロセッサであれば、UATBの変更に伴
ってTLBやキャッシュのパージ(PSTLB/ATに相当する処
理)が自動的に行なわれる。LDCTX命令では論理空間の
切り換えが行なわれるため、LDCTX/LSが意味のある動作
を行なうには、ctxaddrはSRを指している必要がある。L
DCTX/LSでctxaddrがURを指していた場合の動作は保証さ
れない。 「本発明装置」のLDCTX,STCTX命令では、汎用レジス
タR0〜R14の転送を行なっていない。これは、次のよう
な理由による。 −汎用レジスタについては、LDM,STM命令で転送するこ
とが可能であり、LDM,STMならばレジスタの指定も可能
である。実際のコンテキストスイッチの処理では、入れ
換えを行なうレジスタ以外にワーキング用のレジスタが
必要になることが多いので、一部のレジスタは転送しな
い方がよい場合はある。したがって、LDM,STMのよう
な、より汎用的な命令を使用する方が適当である。 −現在は、まだコンテキスト退避用のメモリをチップに
内蔵することが技術的に難しく、コンテキストの退避に
は外部メモリを利用せざるを得ない。その場合、LDCTX
で汎用レジスタの転送まで行なっても、汎用レジスタの
転送を別命令(LDM)としても、ほとんど速度差は生じ
ない。 −将来CTXBをすべてチップに内蔵して高速化しようとい
う場合には、LDC TXのreservedのオプションやCTXBFMの
機能を利用して仕様を拡張すれば良い。 また、LDCTX,STCTX命令では、PC,PSWの転送も行なっ
ていない。これは、次のような理由による。 −一般に、コンテキストスイッチによって切り換える必
要があるのは、OSのPCやPSWではなく、ユーザプログラ
ムのPCやPSWである。ところが、ユーザプログラムのPC
やPSWは、普通はOS呼び出し時にスタック中に退避され
ている。そこで、PC,PSWの退避にSPOのスタックを使用
するようにしておけば、コンテキストスイッチでSPOを
切り換えることにより、PC,PSWも間接的に切り替わる。
これを積極的に利用し、CTXBの構造として、SPOから間
接参照される部分(スタック)にPC,PSWが置かれるよう
なものを考えれば、コンテキストスイッチ命令で、PC,P
SWの操作(スタック〜CTXB間のコピー)をする必要がな
くなる。 −SPIを使用した外部割り込みの処理ハンドラの最後で
直接コンテキストスイッチを行なう場合には、どうして
もSPIのスタック〜CTXB間でPC,PSWの転送が必要にな
る。しかし、この場合、外部割り込みの中ではコンテキ
ストスイッチを遅延し、外部割り込みから抜ける時にDC
EやDIを使ってコンテキストスイッチを行なうようにす
れば、DCEやDIでSPOを指定することにより、上記のデー
タ構造が自然に実現できる。 この命令は特権命令である。 LDCTXによってセットされるPSWのreservedのビッ
ト(’−’で表示される)に対して、CTXBから'1'をロ
ードしようとした場合には、予約機能例外(RFE)が発
生する。また、UATBなどの制御レジスタのreservedのビ
ット(’=’で表示される)に対して、CTXBから'1'を
ロードしようとした場合には、単に無視される。これ
は、LDCによって制御レジスタをセットしようとした場
合と同様である。 <<L1>>仕様のチップでは、AT=00(アドレス変換な
し)の場合にもUATBの転送が行なわれる。これは、OS内
のみで一時的にアドレス変換を中止するというケースが
考えられるためである。ただし、AT=00の場合は、/LS
を指定してもctxaddrは物理アドレスとして扱われる。 LDCTXでUATBを転送しないことを指定するには、CTXBFM
を利用する。 LDCTXの現在の仕様では、汎用レジスタの転送を行な
っていない。しかし、将来仕様が拡張されたり、コンテ
キスト退避用のメモリをチップに内蔵したりした場合に
は、LDCTX命令で複数の汎用レジスタのロードまで行な
う予定がある。その場合、ctxaddt/EaA!Aで付加モード
を許していると、LDMと同様に、命令が途中で中断した
場合の命令再実行が難しくなる。したがって、LDCTXのc
txaddr/EaA!Aでは付加モードを禁止している。どうして
も付加モードの機能を利用したい場合には、MOVAを使っ
とすることにより、同等の機能が実現できる。 【プログラム例外】 ・予約命令例外 ・XX='01'〜'11'のとき ・EaAがRn,#imm_data,@SP+,@−SP,付加モードのと
き ・特権命令違反例外 ・ring0以外から実行されたとき ・予約機能例外 ・PSWにreservedの値を書き込んだとき 【ニモニック】 STCTX 【命令の機能】 store context to CTXB コンテキストのストア 【命令オプション】 /LS 論理空間にCTXBをストア /CS 制御空間にCTXBをストア <<L2>> (検討中) 【命令ビットパターンとアセンブラ表記】 第274図に示す 【フラグ変化】 第275図に示す 【解説】 プロセッサ中の現在のコンテキストの内容を、CTXBB
レジスタで示される領域(CTXB)に退避する。退避の行
なわれるレジスタは、MMUの有無やCTXBFMの内容によっ
て変化するが、SP0〜SP3,UATB,CSWなどが含まれる。STC
TXで転送されるレジスタの詳細については、付録8を参
照のこと。 STCTXでは、LDCTXと同様に、汎用レジスタやPC,PSWの
転送は行なわれない。 CTXBBの指す空間は/LS,/CSのオプションで指定する。
ただし、/CSオプションは、将来コンテキスト退避用の
メモリをチップに内蔵した場合にはじめて意味を持つも
のであり、<<L2>>となっている。 「本発明装置」では、/CSオプションはサポートしな
い。 「本発明装置」標準のMMUを内蔵したプロセッサでは、S
TCTX命令でUATB退避が行なわれる。この場合、STCTX/LS
が意味のある動作を行なうには、CTXBBがSRを指してい
る必要があるが、CTXBBがSRを指すかURを指すかのチェ
ックは特に行なわない。 この命令は特権命令である。 STCTXでCTXBに退避される制御レジスタのreservedの
ビットのうち、’−','+’のビットについては、'0','
1'がCTXBにセットされる、また、’=','#','*’のビ
ットについては、CTXBにセットされる値は不定であり、
インプリメント依存である。これらは、STC命令と同様
である。 <<L1>>仕様のチップでは、AT=00(アドレス変換
なし)の場合にもUATBの転送が行なわれる。これは、OS
内のみで一時的にアドレス変換を中止するというケース
が考えられるためである。ただし、AT=00の場合は、/L
Sを指定してもCTXBBは物理アドレスとして扱われる。 STCTXでUATBを転送しないことを指定するには、CTXBF
Mを利用する。 【プログラム例外】 ・予約命令例外 ・XX='00'以外のとき ・P='1'のとき ・特権命令違反例外 ・リング0以外から実行されたとき 12−16.MMU関連命令 【ニモニック】 ACS chkaddr 【命令の機能】 test access rights アクセス権のチェック 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第276図に示す 【フラグ変化】 第277図に示す 【解説】 chkaddrで指定したアドレスを含むページのATEを調
べ、chkaddrがPRNGからアクセス可能かどうかをチェッ
クする。チェックした結果に応じてフラグをセットす
る。 この命令は特権命令ではなく、ユーザが使用すること
も可能である。例えばring3からPRNG=ring3のアクセス
権をチェックすることもできる。したがって、ページア
ウトなどのOSの管理すべき情報はできるだけ見せないよ
うになっている。ACSの実行のために必要なSection tab
leやPage tableがページアウトされていた場合には、通
常の命令と同じように、ページ不在例外(POE)として
命令を再実行する。このほか、ACS命令でATEを参照中に
は、アドレス変換例外(ATRE)、バスアクセス例外(BA
E)の発生する可能性がある。 ACS命令でテストするオペランドのサイズは、バイト
と考える。つまり、EaAで示されるアドレスの1バイト
が、PRNGからアクセス可能かどうかを示す。複数バイト
にまたがる領域のチェックを行なう場合は、ソフトウエ
アで対処する。 ACSでは、直前のリングからの処理要求に対するアク
セス権のチェックを行なう場合に、PRNGがそのまま利用
できる。しかし、例えばring3からring2に処理を依頼
し、ring2からさらにring1を呼びたいという場合に、ri
ng1でring3からのアクセス権をチェックしたい場合があ
る。この時、PRNGはring2となっているので、そのままA
CS命令を使うことはできず、PRNGをring3に書き変えて
からACSを実行する必要がある。 このような要求に答えるために、PRNGはユーザからも
操作可能なPSMに置いている。PRNGは、ACS命令に対する
パラメータという意味を持ったフィールドである。ただ
し、このままではring3からring0の保護情報まで見える
ことになる。そこで、PRNG<RNGの時は無条件に L_flag=M_flag=Z_flag=0 とすることによって、保護情報が見えるのを防ぐ。 ACSにおいて、chkaddrが未使用領域(ページ範囲外)
であった場合には、R不可、W不可、E不可と同じよう
に、M_flag=0,Z_flag=0,L_flag=0アクセス権なしと
して命令を正常終了するものとする。EITとはならな
い。 また、AT=00(アドレス変換なし)の場合は、リング
保護のチェックが行なわれないので、すべてのアドレス
に対してアクセス権をもっていると考える。実際には、
バスアクセス例外(BAE)が発生するためにアクセスで
きない領域もあるわけだが、そのチェックは行なわな
い。これは、システムバスに起因するアクセスエラーと
メモリ保護に起因するアクセスエラーはレベルの違った
ものであり、ACSでは後者のみのチェックを行なうと考
えるためである。したがって、AT=00の場合、chkaddr
が得られた後はいずれの例外も発生せず、L_flag=M_fl
ag=Z_flag=1(アクセス権あり)として命令を終了す
るものとする。 ACS命令は、命令エミュレーションのプログラムで、
リング保護レベルのチェックまできちんとエミュレート
したい場合に利用できる命令である。エミュレーション
のプログラムは通常ring0に置かれるので、エミュレー
トされる命令とは異なったリングで実行されるのが普通
である。つまり、リング保護のレベルに関しては、エミ
ュレートされるプログラムとエミュレーションプログラ
ムは異なった環境になっている。そこで、エミュレート
される命令のオペランドをアクセスする前に、ACS命令
によって、そのオペランドがエミュレートされる命令と
同じリング(PRNG)からアクセスできるかどうかをチェ
ックしてやれば、リング保護に関するエミュレーション
まできちんと行なうことが可能になる。 ACSのchkaddrの実効アドレス計算において、スタック
ポインタSPの参照があった場合には、PRNGではなく現在
リングRNGのスタックが参照される。 【プログラム例外】 ・予約命令例外 ・EaAがRn,#imm_data,@SP+,@−SPのとき 【ニモニック】 MOVPA srcaddr,dest(「本発明装置」ではサポ
ートしない) 【命令の機能】 move physical address 物理アドレスの転送 【命令オプション】 なし 【命令ビットパターンとアセンブラ表記】 第278図に示す 【フラグ変化】 第279図に示す 【解説】 srcaddrで指定したオペランドの実効アドレス(論理
アドレス)を計算し、それを物理アドレスに変換してか
らdestに転送する。srcaddrで得られた実効アドレスの
アドレス変換の方法は通常の命令とは異なり、UATBレジ
スタではなくR1レジスタをアドレス変換テーブルのベー
スアドレスとして使用する。これは、OS等から、現在プ
ログラムが走っている論理空間以外の空間に対する操作
も行なえるようにするためである。 この命令で、高機能命令と同じように固定番号のレジス
タを空間指定に使用したのは、高級言語で直接使用する
ことのない命令なので命令の対称性があまり必要ないこ
と、ビット割り当てからの制約があること、による。 MOVPA命令において、srcaddrを得てから、それを物理
アドレスに変換するまでの過程でページ不在例外、アド
レス変換例外などが発生した場合、そのエラーはフラグ
に反映し、EITは起動しない。これはsrcaddrのアドレス
変換に使用するSection TableやPage Tableがページア
ウトされていた場合、また最終段のページ(ページテー
ブルではない)がページアウトの場合、さらに交換テー
ブルのエントリ(ATE)のフォーマットにエラー(予約A
TEエラー)があった場合などが含まれる。この時、dest
は変化せず、V_flagがセットされて命令を終了する。ま
た、ページフォールトがあったかどうかはF_flagで示さ
れる。エラーやページフォールトがなく、命令を正常に
終了した場合には、V_flagはクリアされる。この命令
は、基本的にはアドレス演算と考えるので、その他のフ
ラグは無変化である。 MOVPA命令のフラグ変化をまとめると、第280図のよう
になる。 なお、STATEでV_flag=0,F_flag=1に相当する場合
(次の段のページアウト)は、MOVPAではV_flag=1,F_f
lag=1のページアウトの場合に吸収されているので、S
TATEとMOVPAとではフラグ変化のパターンが異なってい
る。 srcaddr,destなどの実効アドレスを得るまでの過程で
ページフォールトが生じた場合には、通常の命令と同じ
ようにページ不在例外(POE)が起動される。 この命令は特権命令である。 dest/EaW!Sでは、@−SPのモードを禁止している。こ
れは、エラーやページアウトの発生によってV_flagがセ
ットされ、destの転送ができない場合に、destに@−SP
が指定されていると命令動作がまぎらわしくなるためで
ある。 LDATE,STATE,LDP,STP,LDC,STC,MOVPA命令の中の特殊
空間を参照するオペランドにおいて、付加モードにより
メモリの間接参照が起こった場合には、特殊空間の方で
はなく論理空間(LS)の方を参照する。また、スタック
ポインタSPの参照があった場合には、PRNGではなく現在
リングRNGのスタックが参照される。特殊空間のアドレ
スという意味を持つのは、最終的に得られた実効アドレ
スのみである。 MOVPA,LDATE,STATE命令で、対象アドレスのMSBが1の
場合(SRを示す場合)は、R1ではなくSATBを使ってアド
レス変換を行なう。まとめると、第281図のようにな
る。 MOVPA,LDATE,STATEでは、アドレス変換のベースレジ
スタを、UATBの代わりにR1によって指定している。この
時、UATBのreservedの部分に対応するR1のビット(’
=’で表現された2^4,2^5のビット)が'1'でなくても、
特にチェックは行なわず、単に無視される。これは、イ
ンプリメントの負担を考慮したためである。チェックが
行なわれていなくても、R1の2^4,2^5のビットには必ず'
0'を入れてもらうように、マニュアル等で指導する必要
がある。 srcaddrの実効アドレスを得てから、R1を使ってアド
レス変換を行ない、その物理アドレスを得るまでの動作
は、ATビットには影響されない。つまり、AT=00であっ
ても、AT=01の時と同じようにsrcaddrのアドレス変換
が行なわれて物理アドレスが得られる。これは、アドレ
ス変換の前準備としてこの命令を使用することを想定し
たためである。もちろん、srcaddr,destの実効アドレス
計算(間接参照など)やdestへの書き込みは、AT=00の
時物理アドレス対象で行なわれる。 【プログラム例外】 ・予約命令例外 ・+='0'のとき ・W='1'のとき ・EaAがRn,#imm_data,@SP+,@−SPのとき ・EaW!Sが#imm_data,@SP+,@−SPのとき <<L1>>機能例外 ・MOVPAの正しいビットパターンがデコードされたとき 【ニモニック】 LDATE src,destaddr (「本発明装置」ではサポートしない) 【命令の機能】 load address translation table entry ATEのロード 【命令オプション】 /AS すべての論理空間のTLBをパージする /SS R0で指定されたLSIDを持つ論理空間のTLBをパージ
する <<L2>> /PT PTE操作 /ST STE操作 【命令ビットパターンとアセンブラ表記】 第282図に示す 【フラグ変化】 第283図に示す 【解説】 destaddrで指定したオペランドの実効アドレス(論理
アドレス)を計算し、それを物理アドレスに変換する際
に使用するアドレス変換テーブルのエントリ(ATE)に
対して、srcで得られるデータの転送を行なう。destadd
rに対するアドレス変換の方法は通常の命令とは異な
り、UATBレジスタではなくR1レジスタをアドレス変換テ
ーブルのベースアドレス(物理アドレス)として使用す
る。これは、OS等から、現在プログラムが走っている論
理空間以外の空間に対する操作も行なえるようにするた
めである。destaddrのMSBが1の場合(SRを示す場合)
は、R1ではなくSATBを使ってアドレス変換を行なう。 /PTオプションの場合、/STオプションの場合とも、R1
はSection Tableのベースアドレスを指す。 結果的に、/PTの場合には2段の間接参照が、/STの場
合には1段の間接参照が行なわれる。 ATEへのセットが正常に行なわれた場合には、ATE値の
変更によって影響を受けるTLBと論理キュッシュのパー
ジが自動的に行なわれる。 LSIDとは、複数のコンテキスト(プロセスやタスク)
のTLBの混在を許す場合に、それを区別する番号であ
る。複数の論理空間の区別が可能なTLBの場合には、/SS
オプションを指定することによって、TLB中のLSIDとR0
で示されるLSIDが一致したTLBのみをパージすることが
できる。なお、現在使用中の論理空間に対するLSIDは、
LSID制御レジスタに置かれているが、この命令の実行と
は直接関係しない。メモリ管理やTLBの構成はインプリ
メント依存性の強いところなので、この命令を実装する
場合にも、必ずしも/SSオプションをインプリメントす
る必要はない。また、LSIDの機能も必須のものではな
い。/SSのオプションが用意されているのは、LSIDのあ
るプロセッサとLSIDのないプロセッサの互換性を取るた
めである。PSTLBの項を参照のこと。 この命令で、高機能命令と同じように固定番号のレジ
スタを空間指定に使用したのは、高級言語で直接使用す
ることのない命令なので命令の対称性があまり必要ない
こと、ビット割り当てからの制約があること、による。 この命令では、ATE自体のエラーやページアウトな
ど、いろいろな場合を見分けるため、F_flag,V_flagを
使用する。それぞれの場合における動作は、次のように
なる。 1.destaddrのアドレス変換に使用するSection TableやP
age Tableのうち、操作する段より上位段のATEにフォー
マットエラー(予約ATEエラー)があった場合 この場合は、操作対象となるATEまで到達できないの
で、ATEへのセットは行なわれない。V_flag=1,F_flag
=0となって命令を終了する。 2.destaddrのアドレス変換に使用するSection TableやP
age Tableのうち、操作する段のATEを含むテーブル、あ
るいはそれより上位段のテーブルがページアウトされて
いた場合 この場合も、操作対象となるATEまで到達できないの
で、ATEへのセットは行なわれない。V_flag=1,F_flag
=1となって命令を終了する。なお、途中段のATEで、
予約ATEエラーと次段のページアウトが同時に起こった
場合には、予約ATEエラーの方を優先し、V_flag=1,F_f
lag=0とする。 3.それ以外の場合 この場合には、srcのデータがATEにセットされ、V_flag
は0となる。LDATEによってATEにセットしたデータのPI
ビットが0の場合には、それより下位の段のページアウ
トを示すため、F_flag=1となる。また、セットしたデ
ータがATEとして予約ATEエラーを起こすものであった場
合には、やはりF_flag=1となる。この二つのケース
は、セットしたATEを使ってアドレス変換を行なおうと
すると例外が発生するという点で共通している。 セットしたATEにエラーがなく、PIビットが1の場合
には、F_flag=0となる。 LDATE命令のフラグ変化をまとめると第284図のように
なる。 この命令は、基本的にはアドレス演算と考えるので、
M_flag,Z_flagなどは変化しない。また、src,destaddr
などの実効アドレスを得るまでの過程でページフォール
トが生じた場合には、通常の命令と同じようにページ不
在例外(POE)が起動される。 この命令は特権命令である。 LDATE/STではPSTLB/STに相当する処理が、 LDATE/PTではPSTLB/PTに相当する処理が自動的に行なわ
れる。 LDATE,STATE,LDP,STP,LDC,STC,MOVPA命令の中の特殊
空間を参照するオペランドにおいて、付加モードにより
メモリの間接参照が起こった場合には、特殊空間の方で
はなく論理空間(LS)の方を参照する。また、スタック
ポインタSPの参照があった場合には、PRNGではなく現在
リングRNGのスタックが参照される。特殊空間のアドレ
スという意味を持つのは、最終的に得られた実効アドレ
スのみである。 MOVPA,LDATE,STATEでは、アドレス変換のベースレジ
スタを、UATBの代わりにR1によって指定している。この
時、UATBのreservedの部分に対応するR1のビット(’
=’で表現された2^4,2^5のビット)が'1'でなくても、
特にチェックは行なわず、単に無視される。これは、イ
ンプリメントの負担を考慮したためである。チェックが
行なわれていなくても、R1の2^4,2^5のビットには必ず'
0'を入れてもらうように、マニュアル等で指導する必要
がある。 AT=00でLDATEを実行した場合、srcのフェッチとdest
addrの実効アドレス計算は、他の命令と同様にアドレス
変換なしで行なわれる。しかし、LDATEの命令動作その
ものは、ATの値に関係しない。すなわち、AT=00であっ
ても、得られたdestaddrの実行アドレスは論理アドレス
であると解釈され、それを物理アドレスに変換する際に
使用するATEに対して、srcの転送を行なう。これは、ア
ドレス変換の前準備としてこの命令を使用することを想
定したためである。 AT=00の場合のLDATE,STATE,MOVPAの仕様は、AT=01
の場合の仕様との整合性のほか、OSが最初にMMUの動作
環境を設定するために利用できるように、また、ユーザ
プログラムがAT=01、OSがAT=00で動く場合に矛盾なく
利用できるように、という意図で決められたものであ
る。 【プログラム例外】 ・予約命令例外 ・!R='11'のとき(!='0'のときは検出しない) ・P='1'のとき ・ttt='010'〜'111'のとき ・EaRが@−SPのとき ・EaAがRn,#imm_data,@SP+,@−SPのとき ・<<L1>>機能例外 ・LDATEの正しいビットパターンがデコードされたとき 【ニモニック】 STATE srcaddr,dest (「本発明装置」ではサポートしない) 【命令の機能】 store address translation table entry ATEのストア 【命令オプション】 /PT PTE操作 /ST STE操作 【命令ビットパターンとアセンブラ表記】 第285図に示す 【フラグ変化】 第286図に示す 【解説】 srcaddrで指定したオペランドの実効アドレス(論理
アドレス)を計算し、それを物理アドレスに変換する際
に使用するアドレス変換テーブルのエントリ(ATE)を
読みだし、destに設定する。srcaddrに対する実効アド
レスのアドレス変換の方法は通常の命令とは異なり、UA
TBレジスタではなくR1レジスタをアドレス変換テーブル
のベースアドレス(物理アドレス)として使用する。こ
れは、OS等から、現在プログラムが走っている論理空間
以外の空間に対する操作も行なえるようにするためであ
る。なお、srcaddrのMSBが1の場合(SRを示す場合)
は、R1ではなくSATBを使ってアドレス変換を行なう。 /PTオプションの場合、/STオプションの場合とも、R1は
Section Tableのベースアドレスを指す。結果的に、/PT
の場合には2段の間接参照が、/STの場合には1段の間
接参照が行なわれる。 この命令で、高機能命令と同じように固定番号のレジ
スタを空間指定に使用したのは、高級言語で直接使用す
ることのない命令なので命令の対称性があまり必要ない
こと、ビット割り当てからの制約があること、による。 この命令では、ATEの予約エラーやページ不在エラー
など、いろいろな場合を見分けるため、F_flag,V_flag
を使用する。それぞれの場合における動作は、次のよう
になる。 1.srcaddrのアドレス変換に使用するSection TableやPa
ge Tableのうち、操作する段より上位段のATEに予約ATE
エラーがあった場合 この場合は、操作対象となるATEまで到達できないの
で、ATEの読みだしは行なわれない。V_flag=1,F_flag
=0となって命令を終了する。 2.srcaddrのアドレス変換に使用するSection TableやPa
ge Tableのうち、操作する段のATEを含むテーブルある
いはそれより上位段のテーブルがページアウトされてい
た場合 この場合も、操作対象となるATEまで到達できないの
で、ATEの読みだしは行なわれない。V_flag=1,F_flag
=1となって命令を終了する。なお、途中段のATEで、
予約ATEエラーと次段のページアウトが同時に起こった
場合には、予約ATEエラーの方を優先し、V_flag=1,F_f
lag=0とする。 3.それ以外の場合 この場合には、ATEが読み出されてdestにセットされ、V
_flagは0となる。STATEによって読み出されたATEのP1
ビットが0の場合には、それより下位の段のページアウ
トを示すため、F_flag=1となる。また、読み出された
ATEが予約ATEエラーを起こすものであった場合には、や
はりF_flag=1となる。この二つのケースは、読み出さ
れたATEを使ってアドレス変換を行なおうとすると例外
が発生するという点で共通している。 読み出されたATEに予約ATEエラーがなく、P1ビットが
1の場合には、F_flag=0となる。 STATE命令のフラグ変化をまとめると、第287図のよう
になる。 なお、フラグ変化の意味を考えると、STATEのF_flag.
or.V_flagに相当するものがMOVPAのV_flagとなってお
り、STATEとMOVPAとではフラグ変化のパターンが異なっ
ている。 この命令は、基本的にはアドレス演算と考えるので、
M_flag,Z_flagなどは変化しない。また、srcaddr,dest
などの実効アドレスを得るまでの過程でページフォール
トが生じた場合には、通常の命令と同じようにページ不
在例外(POE)が起動される。 この命令は特権命令である。 dest/EaW!Sでは、@−SPのモードを禁止している。こ
れは、途中段の予約ATEエラーやページアウトの発生に
よってV_flagがセットされ、destの転送ができない場合
にdestに@−SPが指定されていると命令動作がまぎらわ
しくなるためである。 LDATE,STATE,LDP,STP,LDC,STC,MOVPAM命令の中の特殊
空間を参照するオペランドにおいて、付加モードにより
メモリの間接参照が起こった場合には、特殊空間の方で
はなく論理空間(LS)の方を参照する。また、スタック
ポインタSPの参照があった場合には、PRNGではなく現在
リングRNGのスタックが参照される。特殊空間のアドレ
スという意味を持つのは、最終的に得られた実効アドレ
スのみである。 AT=00でSTATEを実行した場合、srcaddrとdestの実効
アドレス計算は、他の命令と同様にアドレス変換なしで
行なわれる。しかし、STATEの命令動作そのものは、AT
の値に関係しない。すなわち、AT=00であっても、得ら
れたsrcaddrの実効アドレスは論理アドレスであると解
釈され、それを物理アドレスに変換する際に使用するAT
Eをdestに転送する。これは、アドレス変換の前準備と
してこの命令を使用することを想定したためである。 MOVPA,LDATE,STATEでは、アドレス変換のベースレジ
スタを、UATBの代わりにR1によって指定している。この
時、UATBのreservedの部分に対応するR1のビット(’
=’で表現された2^4,2^5のビット)が'1'でなくても、
特にチェックは行なわず、単に無視される。これは、イ
ンプリメントの負担を考慮したためである。チェックが
行なわれていなくても、R1の2^4,2^5のビットには必ず'
0'を入れてもらうように、マニュアル等で指導する必要
がある。 【プログラム例外】 ・予約命令例外 ・+='0'のとき ・W='1'のとき ・EaAがRn,#imm_data,@SP+,@−SPのとき ・EaW!Sが#imm_data,@SP+,@−SPのとき ・<<L1>>機能例外 ・STATEの正しいビットパターンがデコードされたとき 【ニモニック】 PTLB (「本発明装置」ではサポートしない。つま
り《L2》である。) 【命令の機能】 purge TLB TLBのパージ 【命令オプション】 /AS すべての論理空間のTLBをパージする /SS R0で指定されたLSIDを持つ論理空間のTLBをパージ
する 【命令ビットパターンとアセンブラ表記】 第288図に示す 【フラグ変化】 第289図に示す 【解説】 TLBのパージを行なう。 TLBのロックやイネーブルなどの細かい操作を行なう
には、制御レジスタを用いる。しかし、TLBに対するパ
ージ操作しか行なわない場合には、そのためだけに制御
レジスタを追加するのはインプリメントの負担が大きい
ため、TLBのパージ命令を別に用意している。 LSIDとは、複数のコンテキスト(プロセスやタスク)
のTLBの混在を許す場合に、それを区別する番号であ
る。/SSオプションの際には、R0により示されたLSIDを
持つ論理空間のTLBのみがパージされる。なお、現在使
用中の論理空間に対するLSIDは、LSID制御レジスタに置
かれているが、この命令の実行とは直接関係しない。 PTLB命令では、特定の論理アドレスのTLBのみをパー
ジする機能はなく、指定した論理空間のすべてのTLBが
パージされる。特定の論理アドレスのTLBをパージする
場合は、PSTLB命令を使う。ただし、/SSオプションが指
定された場合には、指定した論理空間のURのTLBのみが
パージされ、SRのパージは一切行なわれない。SR部分の
パージを行なう場合には、必ず/ASを使用する必要があ
る。 この命令は特権命令である。 メモリ管理やTLBの構成はインプリメント依存性の強
いところなので、この命令は<<L2>>となっている。
また、この命令を実装する場合にも、必ずしもすべての
オプションをインプリメントする必要はない。LSIDの機
能も必須のものではない。 PTLBでは、AT=00の場合にも、AT=01の時と同様にパ
ージが実行される。これは、アドレス変換の前準備とし
てPTLB命令を使用することを想定したためである。 【プログラム例外】 ・予約命令例外 【ニモニック】 PSTLB prgaddr(「本発明装置」ではサポートしな
い。つまり《L2》である。) 【命令の機能】 purge specific TLB 特定のアドレスのTLBのパージ 【命令オプション】 /AS すべての論理空間のTLBをパージする /SS R0で指定されたLSIDを持つ論理空間のTLBをパージ
する /PT 論理アドレス全体(2^31〜2^12ビット)がprgaddr
と一致するエントリをパージする つまり、PTEの変更時に影響を受ける部分をパージする /ST 論理アドレスの2^31〜2^22ビットがprgaddrと一致
するエントリをパージする つまり、STEの変更時に影響を受ける部分をパージする /AT 論理アドレスの2^31ビットがpragaddrと一致する
エントリをパージする つまり、UATB,SATBの変更時に影響を受ける部分をパー
ジする。 【命令ビットパターンとアセンブラ表記】 第290図に示す 【フラグ変化】 第291図に示す 【解説】 特定の論理アドレスのTLBをパージする。 /PTオプションを指定した場合には、対象となる論理空
間のTLBのうち、STE〜PTEのインデクスに相当する論理
アドレス(すなわち論理アドレス全体)がprgaddrと一
致するものをパージする。また、/STオプションを指定
した場合には、対象となる論理空間のTLBのうち、STEの
インデクスに相当する論理アドレスがprgaddrと一致す
るものをパージする。/ATオプションを指定した場合に
は、対象となる論理空間のキャッシュのうち、論理アド
レスのMSBがprgaddrと一致するエントリをすべてパージ
する。 LSIDとは、複数のコンテキスト(プロセスやタスク)
のTLBの混在を許す場合に、それを区別する番号であ
る。/SSオプションの際には、R0により示されたLSIDを
持つ論理空間のURのTLBのみがパージされる。なお、現
在使用中の論理空間に対するLSIDは、LSID制御レジスタ
に置かれているが、この命令の実行とは直接関係しな
い。 この命令は特権命令である。 メモリ管理やTLBの構成はインプリメント依存性の強
いところなので、この命令は<<L2>>となっている。
また、この命令を実装する場合にも、必ずしもすべての
オプションをインプリメントする必要はない。LSIDの機
能も必須のものではない。 /AS,/SSオプションは、LSIDの有無に対する互換性を
保つために設けてあるオプションである。意味的には、
PSTLBの場合に常に/SSのみが指定できればよいが、PSTL
Bの場合に常に/SS指定とすると、LSIDの有無によって互
換性が失われる恐れがある。例えば、最初にLSIDの機能
のないプロセッサができると、その上で動くプログラム
は、R0にLSIDのセットを行なわずにPSTLB命令を実行す
るものになるだろう。同じプログラムを将来LSIDの機能
の有るプロセッサで実行した場合、その時にR0に残って
いたゴミによって、全くでたらめのLSIDに対してPSTLB
が実行されることになる。これを防ぐためには、オプシ
ョンを使って、R0をセットしていない場合には/AS指
定、将来R0をセットした場合は/SS指定とすればよいわ
けで、PSTLBにおける/AS指定はこのような意味を持って
いる。 したがって、PSTLBでは、 /AS/PT /AS/ST /SS/PT /SS/ST はすべて有効であり、 /SSはR0によって指定される論理空間のURのTLBをパージ /ASはすべての論理空間に対するTLBのパージ、あるいは
LSIDの機能のないプロセッサでのTLBのパージ(/PT,/ST
オプションも有効、R0は使用しない) となる。 /ASオプションを使えば、LSIDのあるプロセッサでもL
SIDのないプロセッサでも共通のプロセッサを書ける
が、LSIDの機能は生かせないことになる。一方、/SSオ
プションを使えば、LSIDの機能は生かせるが、LSIDのな
いプロセッサでは未実装オプションということでエラー
(予約命令例外など)になる。 PTLB,PSTLB命令で/SSオプションが指定された場合に
は、指定した論理空間のURのTLBのみがパージされ、SR
のパージは一切行なわれない。SR部分のパージを行なう
場合には、必ず/ASを使用する必要がある。PTLB,PSTLB
で/SSのオプションを指定した場合の動作をまとめる
と、以下のようになる。 PTLB/SS R0で指定された論理空間のURをパージ PSTLB/SS/AT@uraddr ;uraddrはURR0で指定された
論理空間のURをパージ PSTLB/SS/AT@sraddr ;sraddrはSR/SSでSRを指定
したので、何もしない SR全体をパージする場合はPSTLB/AS/AT@sraddrを利用 PSTLB/SS/PT@uraddr ;uraddrはURR0で指定された
論理空間のURの一部をパージ PSTLB/SS/PT@sraddr ;sraddrはSR/SSでSRを指定
したので、何もしない SRの一部をパージする場合はPSTLB/AS/PT@sraddrを
利用 PSTLBで/STオプションの実装が難しい場合には、互換性
のため機能を縮退してそのまま実行することにし、EIT
とはしない。具体的には、/STの代わりに/AT相当の動作
を行なうことになる。 AT=00でPSTLBを実行した場合、prgaddrの実効アドレ
ス計算は、他の命令と同様にアドレス変換なしで行なわ
れる。しかし、PSTLBの命令動作そのものは、ATの値に
関係しない。すなわち、AT=00であっても、得られたpr
gaddrの実効アドレスは論理アドレスであると解釈さ
れ、AT=01の時と同様にパージが実行される。これは、
アドレス変換の前準備としてPSTLB命令を使用すること
を想定したためである。 【プログラム例外】 ・予約命令例外 付録1.本発明装置命令セットレファレンス *:本発明装置ではサポートしない命令 (データ転送命令) MOV src,dest データの移動と符号拡張 MOVU src,dest データの移動とゼロ拡張 PUSH src スタックにプッシュ POP dest スタックからポップ STM reglist,dest 複数レジスタのストア LDM src,reglist 複数レジスタのロード MOVA srcaddr,dest 実効アドレスを得る PUSHA srcaddr 実効アドレスをスタックにプッシュ (比較・テスト命令) CMP src1,src2 比較、符号拡張と比較 CMPU src1,src2 ゼロ拡張と比較 CHK bound,index,xreg 配列の範囲のチェック (算術演算命令) ADD src,dest 加算、符号拡張と加算 ADDU src,dest ゼロ拡張と加算 ADDX src,dest キャリーを含めた加算 SUB src,dets 減算、符号拡張と減算 SUBU src,dest ゼロ拡張と減算 SUBX src,dest キャリーを含めた減算 MUL src,dest 乗算 MULU src,dest 符号なし乗算 MULX src,dest,tmp 拡張乗算、サイズが大きくなる DIV src,dest 除算 DIVU src,dest 符号なし除算 DIVX src,dest,tmp 拡張除算、サイズが小さくなる、剰余を出す REM src,dest 剰余 REMU src,dest 符号なし除算による剰余 NEG dest 補数演算 <<L2>> INDEX indesize,subscript,xreg 多次元配列のアドレス計算 (論理演算命令) AND src,dest 論理積 OR src,dest 論理和 XOR src,dest 排他的論理和 NOT dest 全ビット反転 (シフト命令) SHL count,dest 論理シフト SHA count,dest 算術シフト ROT count,dest 回転 SHXL dest 拡張左シフト SHXR dest 拡張右シフト RVBY src,dest バイト順の逆転 <<L2>> RVBI src,dest ビット順の逆転 (本発明装置ではサポート) (ビット操作命令) BTST offset,base ビットのテスト BSET offset,base ビットのセット BCLR offset,base ビットのクリア BNOT offset,base ビットの反転 BSCH data,offset 0または1のサーチ (1ワード内) (固定長ビットフィールド命令) BFEXT offset,width,base,dest ビットフィールドの抽出 (符号付き) BFEXTU offset,width,base,dest ビットフィールドの抽出 (符号なし) BFINS src,offset,width,base ビットフィールドの挿入 (符号付き) BFINSU src,offset,width,base ビットフィールドの挿入 (符号なし) BFCMP src,offset,width,base ビットフィールドの比較 (符号付き) BFCMPU src,offset,width,base ビットフィールドの比較 (符号なし) (任意長ビットフィールド命令) BVSCH 0または1のサーチ (任意長ビットフィールド) BVMAP ビットマップ演算 BVCPY ビットマップ転送 BVPAT パターンとビットマップの演算 (10進演算命令) *ADDDX src,dest BCDの加算 *SUBDX src,dest BCDの減算 *PACKss src,dest BCDへのパック *UNPKss src,dest,adj BCDからのアンパック (ストリング命令) SMOV ストリングのコピー SCMP ストリングの比較 SSCH ストリングのサーチ SSTR 同一データを繰り返し書き込み (ストリングのフィル) (キュー操作命令) QINS entry,queue ダブルリンクのキューへ挿入 QDEL queue,dest ダブルリンクのキューエントリを削除 QSCH キューのサーチ (ジャンプ命令) BRA newpc ジャンプ(PC相対) Bcc newpc 条件ジャンプ (PC相対) BSR newpc サブルーチンジャンプ(PC相対) JMP newpc ジャンプ JSR newpc サブルーチンジャンプ ACB step,xreg,limit,newpc インデクス値を増加する ループ命令 SCB step,xreg,limit,newpc インデクス値を減少する ループ命令 ENTER local,reglist スタックフレームの形成、高級言語用サブルーチンジャ
ンプ EXITD reglist,adjsp 高級言語用サブルーチン リターンとパラメータ解放 RTS サブルーチンからのリターン NOP ノーオペレーション PIB 命令キャッシュやパイプラインの
整合性をとる (マルチプロセッサ命令) BSETI offset,base ビットのセット (バスをロック) BCLRI offset,base ビットのクリア (バスをロック) CSI comp,update,dest 比較とストア(バスをロック) (制御空間、物理空間操作命令) LDC src,dest 制御空間へのロード STC src,dest 制御空間からのストア LDPSB src PSBへのロード LDPSM src PSMへのロード STPSB dest PSBからのストア STPSM dest PSMからのストア LDP src,dest 物理空間へのロード STP src,dest 物理空間からのストア (OS関連命令) *JRNG vector リング間コール *RRNG リング間リターン TRAPA vector ソフトウエア割り込み、トラップ TRAP 条件によるソフトウエア割り込み、ト
ラップ REIT EIT処理(割り込み、例外処理)から
のリターン WAIT imask 停止、割り込み待ち LDCTX pcbaddr プロセスコンテキストのロード STCTX プロセスコンテキストのロード (MMU関連命令) ACS chkaddr アクセス権のチェック *MOVPA srcaddr,dest 物理アドレスの転送 *LDATE src,destaddr ATEのロード *STATE srcaddr,dest ATEのストア <<L2>>*PTLB TLBのパージ <<L2>>*PSTLB prgaddr 特定のアドレスのTLBのパージ (符号付き10進演算命令) <<L2>>*DCADD src,dest 符号付きBCDの加算 <<L2>>*DCADDU src,dest 符号なしBCDの加算 <<L2>>*DCSUB src,dest 符号付きBCDの減算 <<L2>>*DCSUBU src,dest 符号なしBCDの減算 <<L2>>*DCX src,dest キャリーを含めたBCDの加減算 <<L2>>*DCADJ src,dest 符号付きBCDの補数 <<L2>>*DCADJU src,dest 符号なしBCDの補数 <<L2>>*DCADJX src,dest キャリーを含めたBCDの補数 <<L2>>*DCCMP src1,src2 符号付きBCDの比較 <<L2>>*DCCMPU src1,src2 符号なしBCDの比較 <<L2>>*DCCMPX src1,src2 キャリーを含めたBCDの比較 付録2.本発明装置のアセンブラ表記について A2−1.概要 この資料は、命令ニモニック、アドレッシングモード
のニモニック、などに関する本発明装置での規定を示し
たものである。ドキュメントの記述の意味を明確にし、
本発明装置に対する理解を深めてもらうことを目的とし
ている。 A2−1−1.このドキュメントにおける記述方法 A2−1−2.ニモニック決定の方針 総称ニモニックとフォーマット別ニモニックを設け
る。 総称ニモニックは各命令に対応したニモニックであ
り、短縮形、一般形などフォーマットが複数存在する命
令でも、総称ニモニックは一つである。これに対して、
フォーマット別ニモニックは、短縮形や一般形などの区
別をしたい場合のニモニックである。命令フォーマット
を表わす文字を決めておき、総称ニモニックから規則的
にフォーマット別ニモニックを作る。ユーザがアセンブ
ラのソースプログラムを書いた場合には、通常総称ニモ
ニックを使う。総称ニモニックに対する最適なフォーマ
ットの選択は、原則としてアセンブラが行なう。 データタイプ指定子に関して統一的な規則を設ける。 データタイプ関係で記述を必要とするものは、演算の
ためのデータタイプ指定、命令全体でのオペランドサイ
ズ指定、およびオペランド毎のサイズ指定である。これ
らに関して統一的な規則を設ける。 ニモニックは、原則としてIEEE Microprocessor Asse
mbly Language Stan dard(P694)を標準とする。ただ
し、これには一般的な感覚になじまないと思われるとこ
ろ、本発明装置のアーキテクチャに合わないところなど
があるので、あくまでも個々の名称を決める際の参考と
するだけである。考え方や規則まで完全にIEEEに合わせ
るわけではない。 特殊記号の利用はできるだけ避ける。 ここで定義するアセンブラでは、できるだけ特殊記号
を使用しないという方針にしている。それは、オペラン
ドに数式が来たり、アセンブラを拡張した場合に、その
中で使用する記号と競合させないためである。また、文
字セットの少ない大型機でも開発を行なうためには、あ
まり多くの記号を使用するのは望ましくない。特殊記号
の利用をできるだけ避けたため、アセンブラの中では括
弧を一種類しか使用しておらず、また';','&’などが
未使用の特殊記号となっている。 A2−1−3.アセンブラ命令 本発明装置用アセンブラ言語における一つの命令は、
一つのオペレーションニモニックと複数個(0個,1個を
含む)、のオペランドニモニックにより記述される。オ
ペコードニモニックとオペランドニモニックの間は一個
以上の空白文字(スペースまたはタブ)により区切ら
れ、オペランドニモニックどおしの間はコンマ','によ
り区切られる。A2−1−4.オペランドの順序 オペランドの順序は命令毎に定まっているが、原則は次
のようになる。 移動命令(MOV) 第一オペランドがソース、第二オペランドがデスティ
ネーションになる。 すなわち、 これはIEEE標準と同じである。 2項演算の2オペランド命令(SUBなど) 第一オペランドが2番目のソース、 第二オペランドが1番目のソースと デスティネーションになる。 すなわち、 これはIEEE標準とは異なるが、多くのプロセッサで用
いられている方法であり、なじみやすい。 A2−2.オペレーションのニモニック A2−2−1.ニモニック生成規則 IEEEでは、演算操作を示す動詞をニモニックの先頭に
もってくるという考え方であるが、本発明装置ではさら
にその前にデータタイプ指定子を置く。演算操作そのも
のに対するニモニックは、ほぼIEEEに合わせる。 本発明装置での命令のニモニックは、次のような規則
で生成する。 例: MOV SMOV/NE.W MOV.W MOV:L MOV:Q.W 〈データタイプ〉 命令の先頭で指定するのは、演算方
法に大きな影響を与えるデータタイプ、すなわち、〈演
算操作〉に対して直交関係にないデータタイプである。
このデータタイプには、ストリング、キュー、ビットフ
ィールドなどが含まれる。データサイズ(整数の8,16,3
2,64ビット、浮動小数の32,64ビットなど)の指定は、
ここではなく〈サイズ〉で行なう。また、符号付き、符
号なしの指定、およびアドレス演算の指定は、ここでは
なく〈バリエーション〉で行なう。 〈演算操作〉 演算そのものの指定を行なう。できる限
りIEEEに合わせる。条件ジャンプ命令の条件の指定は本
来オプションとするべきであるが、慣例にしたがって基
本部分の〈演算操作〉に含める。 〈バリエーション〉 演算に対する細かい操作や属性の
指定を行なう。 〈オプション〉 命令フォーマット中の数ビットで表現
される命令オプションを示す。オプションになるのは、
ストリング命令の終了条件、キューのサーチ条件などで
ある。 〈フォーマット〉 短縮形、一般形などのフォーマット
を指定する。通常は書かなくてもよく、書かない場合は
総称ニモニックになる。アセンブラのソースで〈フォー
マット〉を書かずに総称ニモニックを使った場合には、
アセンブラで自動的に最適なフォーマットを選ぶ。〈フ
ォーマット〉を書いた場合にはフォーマット別ニモニッ
クの記述になる。アセンブラのソースでユーザが〈フォ
ーマット〉を書いた場合には、強制的にそのフォーマッ
トを使うことを示す。 〈フォーマット〉によるフォーマット別ニモニックは、
仕様書やマニュアルの記述において、あるいは逆アセン
ブラなどにおいて、あえて命令フォーマットの区別をし
たい場合に用いる。 〈サイズ〉 オペランドのサイズを指定する。〈サイ
ズ〉を使用する命令は、主として整数を扱う命令と浮動
小数を扱う命令である。〈サイズ〉は〈データタイプ〉
とは異なり、〈演算操作〉に対して直交関係があるのが
特徴である。 A2−2−2.データタイプ 〈データタイプ〉を表わす文字として、次のようなもの
がある。 なし 整数演算、アドレス演算、雑命令など F 浮動小数 S ストリング Q ダブルリンクによるキュー B 1ビットのビット操作 BF 固定長ビットフィールドの操作 BV 任意長ビットフィールドの操作 A2−2−3.演算操作 原則としてIEEEのニモニックに従う。使用するものは次
の通りである。 ADD,SUB,MUL,DIV,CMP,NEG,AND,OR,XOR,NOT,LD,ST,MOV,P
USH,POP,WAIT,NOP 注意 ・MOV,LD,STの使い分け MOV レジスタ間、メモリ間の転送 LD メモリからレジスタへの転送 ST レジスタからメモリへの転送 LD,STは、方向性を意識する必要のある命令に使用す
る。 ・シフト関係のオペレーションは、左右の指定方法が異
なるためにIEEEのニモニックをそのまま使うわけではな
いが、IEEEの原則を生かしてSHA,SHL,ROTとする。 ・ブランチ(条件分岐)命令に関しては、IEEEに従う
と'BV'などが別の意味とぶつかること、符号付き整数の
比較と符号なし整数の比較の区別をわかりやすくしたい
こと、などを考慮したため、条件指定の部分がIEEEには
従っていない。 ・JMP,JSR,RTSは、ブランチ命令とのバランスからIEEE
には従っていない。 ・〈バリエーション〉の'X'により拡張演算を表わすこ
とに統一したため、ADDX,SUBX,MULX,DIVXについてもIEE
Eには従っていない。 A2−2−4.バリエーション 〈バリエーション〉は、演算に対する属性などを指定
するものである。次のような文字を使用する。 X 拡張演算 例:ADDX,MULXなど U 符号なしデータの演算 例:MOVU,ADDU,MULUなど C 制御空間(制御レジスタ)に対する演算 例:LDC,STC P 物理空間に対する演算 例:LDP,STP I バスをロックして行なう処理 例:BSETI,BCLRI,CSI M 複数データの処理 例:LDM,STM A アドレス計算 例:MOVA,PUSHA,MOVPA D 10進演算(符号なし、データチェックなし) 例:ADDDX,SUBOX またはスタック上のパラメータを捨てる処理 例:EXITD A2−2−5.フォーマット 〈フォーマット〉は、命令フォーマットの詳細を区別
したい場合に用いる。次のような文字を使用する。 Q リテラル短縮形 ビットフィールド命令のスタティック形 ループ命令のリテラル短縮形 例:MOV:Q.W #3,@abs BTST:Q.B #4,@abs ACB:Q #1,R1,#5,loop1 R レジスタ−レジスタ間演算の短縮形 ループ命令のレジスタ短縮形 例:AND:R.W R1,R2 MOVA:R.W @(disp:16,R2),R3 ACB:R #1,R1,R2,loop2 L メモリ−レジスタ間演算の短縮形 例:ADD:L.W @abs,R2 MOV:L.W @(disp,R2),R3 S レジスタ−メモリ間演算の短縮形(MOVの
み) 例:MOV:S.W R2,@abs I イミディエート短縮形 例:ADD:I.W #100000,@abs2 G 2オペランド命令の一般形 ループ命令の一般形 例:ADD:G.W @abs1,@abs2 ACB:G @abs1,R1,@a bs2,loop3 E 2オペランド命令の一般形 の8ビットイミディエート 例:ADD:E.W #100.B,@abs2 8 newpcが8ビット 例:ACB:G @abs1,R1,@abs2, loop3:8 16 newpcが16ビット 例:BEQ:G error:16 32 newpcが32ビット 例:BNE:G next:32 64 newpcが64ビット 例:BRA:G loop:64 なお、ここで示した':Q',':G'...といったフォーマッ
ト指定は、一つの命令(総称ニモニック)の中でフォー
マットの区別を行ない、フォーマット別ニモニックを作
ることが目的のものである。つまり、アセンブラ表記上
のフォーマット指定である。一方、命令フォーマット説
明で用いたG−format,E−format..といったフォーマッ
トの方は、命令全体の中でのフォーマットの説明を行な
うことが目的のものである。したがって、例えば同じ':
G'であっても'MOVA:G'であればMOVA命令の一般形なので
GA−formatであり、'MOV:G'であればMOV命令の一般形な
のでG−formatということになる。 A2−2−6.サイズ IEEEでは64ビット整数まで考慮されていないので、扱
うデータサイズはどうしてもIEEEと異なったものにな
る。 整数の場合 4通りのサイズが対照的にサポートされている点、 オペランド側でもデータタイプが指定できる点、が特徴
である。 オペレーション側にもオペランド側にも同じものを書
くので、'.'により区切っている。 〈サイズ〉として、次のような文字を使用する。 B Byte 8ビット長の整数 H Halfword 16ビット長の整数 W Word 32ビット長の整数 L Longword 64ビット長の整数 'L'は本発明装置32では使用できない。 浮動小数点の場合 別に定める。 A2−3.オペランドのニモニック オペランドには、汎用のアドレッシングモードまたはそ
のサブセットが利用できるもの(一般オペランドと呼
ぶ)と、命令に応じた特殊な指定をするもの(特殊オペ
ランドと呼ぶ)とがある。特殊オペランドについては、
命令毎にフォーマットを定める。特殊オペランドをとる
命令は、 BRA,Bcc,BSR,ACB,SCB (newpcオペランド) LDM,STM (reglistオペランド) などである。 一般オペランドに関しては、本発明装置において、オ
ペランド毎にデータサイズを指定できる点が特色であ
り、アセンブラにおける一般オペランドの記述方法にも
そのような能力を持たせている。また、オペランドに対
しても総称ニモニックとフォーマット別ニモニックを設
けている。 一般オペランドのニモニックは、実際のオペランドの
値(実効アドレス)と付加モードフォーマットの区別、
およびサイズから成る。 A2−3−1.アドレッシングモード表記の原則 従来のプロセッサでは、アドレッシングモードの数が
あまり多くなかったため、それぞれのモードを個別に考
え、別々の記号を割り当てておけばよかった。また、表
記法と実際のアドレッシングのオペレーションがうまく
対応していない場合も見られた。例えば、あるプロセッ
サではレジスタ相対間接のアドレッシングモードをdisp
(Rn)で表現する場合があるがこれはオペレーションと
してはmem[disp+Rn]であり、dispの部分とRnの部分
の扱いが対称的ではない。これだけで使っている場合に
は問題は生じないが、これを組み合わせて複雑なモード
を作っていった場合には矛盾の起きることがある。 本発明装置では付加モードといった機能があるため、
統一的、規則的なアドレッシングの表記を行なわないと
混乱を招く。そこで、本発明装置では実際のオペレーシ
ョンとその表記との関係について原則を設け、それに基
づいて、付加モードまで一貫したアドレッシングモード
の表記を行なうこととした。 アドレッシングは、基本的には加算と間接参照の繰り
返しである。したがって、この二つのオペレーションに
対する表記法が決まればよい。 本発明装置の表記原則をまとめると次のようになる。 [本発明装置アドレッシングモードの表記原則] @Aまたは@(A) アドレスAのメモリ内容を
参照 mem[A] @(A,B,C,...) A,B,C,.を加算して、加算結果のアド
レスのメモリ内容を参照 mem[A+B+ C+...] 本発明装置における’( )’は、間接参照などの特別
な意味は持たない。一般の数式と同じように、結合の順
序を示すに過ぎない。したがって、@Aと@(A)は全
く同じ意味ということになる。以下で説明するシンタッ
クスにおいて が入る場合であっても、 内に一つの項しかなければ、 を省略しても構わない。 従来のプロセッサでは によって間接参照を意味する場合があり、これがある程
度慣用的な表記法となっている。しかし、このような表
記法では以下のような点で誤解を生みやすい。 例: 慣用的表記法 オペランド値 Rn Rn (Rn) mem[Rn] abs mem[abs]またはabs (abs) mem[mem[[abs]]またはmem
[abs] うまく対応がとれない場合が生ずる。 本発明装置において、間接参照を必ず’@’によって
表現しているのは、こういった理由による。 イミディエート、スタック操作のアドレッシングモー
ド、インデクスのスケーリングなどの処理はこの原則に
入らないので、原則を参照にしながらそれぞれ別に表記
法を定める。 A2−3−2.付加モードの指定 'A'の指定は、付加モードのフォーマットを使うとい
うことを特に強調したい場合に付け加える。また、'N'
の指定は、付加モードを使用しないということを特に強
調したい場合に付け加える。これらの指定は、フォーマ
ット別ニモニックに相当するものである。':N',':A'と
も書かれていない場合は、そのアドレッシングが付加モ
ード以外の短いモードで実現できるかどうかをアセンブ
ラが判断し、実現できればそのモードを使う。付加モー
ドでないと実現できなければ、付加モードを使う。 例: @(disp,PC):A 常にPC相対付加モードを使用 dispが32ビット以下であっても付加モードを使用 @(disp,PC):N 常にPC相対間接のモードを使用 dispが64ビットであるとエラー @(disp,PC) dispが32ビットであればPC相対間
接のモードを使用 dispが64ビットであればPC相対付加モードを使用 A2−3−3.サイズ 〈サイズ〉は、オペランドの演算サイズを示すものであ
り、オペレーションのニモニックに示されたサイズと組
みになって実際のサイズ指定を行なう。サイズ指定の文
字は、オペレーションに使われるものと同じである。 オペランド中の〈サイズ〉と、オペレーション中の〈サ
イズ〉の関係は、原則として次のようになる。 ・オペレーション中に〈サイズ〉の指定があった場合に
は、その〈サイズ〉が全部のオペランドのデフォルトの
サイズとして有効になる。ただし、サイズの指定ができ
ないオペランド、イミディエートのオペランド、特殊な
意味を持つオペランドの場合はこの限りではない。 ・オペランド中に〈サイズ〉の指定があった場合には、
それがそのオペランドのサイズになる。オペレーション
中で異なるサイズが指定されていても、オペランドで指
定された〈サイズ〉の方が優先される。 ・オペランド中で〈サイズ〉の指定を行ない、それが利
用できないサイズであった場合はエラーとなる。 例: MOV.W @src,@dest src,destともW(WORD)型 MOV.W @src,@dest srcはB(BYTE)型、destともW(WORD)型 MOV @src.B,@dest.W srcはB(BYTE)型、destはW(WORD)型 A2−3−4.オペランド値 以下の項では、一般オペランドに関してアドレッシン
グモード別にそのアセンブラ表記を示す。 〈イミディエート値〉、〈絶対アドレス〉などの内容
としては、数値、変数名、数式などが書けるが、そのシ
ンタックスは別に定める。〈フォーマット〉は、アドレ
ッシングモードのフォーマット選択を明示したい場合に
書く。主としてアドレッシングモードの拡張部のサイズ
を指定するために使用する。通常は書かなくてもよく、
書かない場合はアセンブラで自動的に最適なフォーマッ
ト(サイズ)を選ぶ。〈フォーマット〉によるフォーマ
ット別ニモニックは、仕様書やマニュアルの記述におい
て、あるいは逆アセンブラなどにおいて、あえてアドレ
ッシング部のフォーマットの区別をしたい場合に用い
る。 〈フォーマット〉により指定されるのは、あくまでも命
令フォーマット自体のサイズである。一方、〈サイズ〉
により指定されるのは、演算されるオペランドのサイズ
である。イミディエートモードの場合を除けば、両者は
全く異なるものである。 例: MOV RO.W,@addr:16,W この命令では、ROの内容を'addr'で示されるメモリに転
送する。 絶対アドレッシングが用いられている。 ':16'は'addr'を16ビットで表現することを示す。した
がって、'addr'の範囲は$ffff8000〜$00007fffとな
る。 一方、'.W'は演算をWORD(32ビット)で行なうことを示
す。つまり、この命令により4バイトのデータが転送さ
れる。 〈レジスタ番号〉に入るのは、汎用レジスタのニモニ
ックである。FPとR14は全く同義、SPとR15は全く同義である。 A2−3−4−1.レジスタ直接 オペランド=Rn A2−3−4−2.レジスタ間接 オペランド=mem[Rn] A2−3−4−3.レジスタ相対間接 オペランド=mem[disp16+Rn] mem[disp32+Rn] A2−3−4−4.リテラルとイミディエート オペランド=imm_data リテラルの命令フォーマットを使用するということを
明示したい場合は、オペレーションのニモニック中で示
す。 イミディエートの場合には、拡張部のサイズがオペラ
ンドのサイズとして決まるため、〈フォーマット〉と
〈サイズ〉が同じ意味になる。アセンブラとしては、
〈フォーマット〉としても〈サイズ〉としてもその大き
さを指定することができる。 なお、イミディエートのオペランドでオペランド側に
サイズ指定がなく、しかも命令機能の上でサイズの自由
度がある場合には、自動的に最小のサイズが選択される
ものとする。 例: ADD:Q.W #1,R0 リテラルのフォーマットを使用(2バイト) ADD:I.W #1,R0 イミディエート形のフォーマットを使用(6バイト) ソースオペランド'1'は32ビットで表現 ADD:L.W #1,R0 短縮形のフォーマットを使用(6バイト) ソースオペランドとして32ビット イミディエートを指
定 ADD:G.W #1.B,R0 一般形のフォーマットを使用(6バイト) ソースオペランドとして8ビット イミディエートを指
定 16ビットフィールドの下位8ビットを用いて'1'を表
現。'1'は32ビットに符号拡張される。 ADD:E.W #1,R0 一般形8ビットイミディエートのフォーマットを使用
(4バイト)'1'は32ビットに符号拡張される。 ADD:G.W #1,R0 #1にはサイズの指定がなく、しかも:Gフォーマットな
のでサイズの自由度が残されている。したがって、自動
的に最小のサイズが選択され、 ADD:G #1.B,R0.W(6バイト命令) と等価になる。 ADD:G #1.W,R0.W(8バイト命令) になるのではない。 ADD:G.W #1:16,R0 これは、〈サイズ〉ではなく〈フォーマット〉によって
命令を選択した例であり、 ADD:G.W #1.H,R0 と等価になる。 総称ニモニックで単に ADD.W #1,R0 と書くと、最もコードの短い ADD.Q.W #1,R0 が選択される。 また、命令によっては、サイズが一つに固定されてい
るわけではないが、実質的にほとんど一つのサイズでの
み使用されるものがある。そのようなものについては、
特にオペランド側に〈サイズ〉がついていない限り、命
令によって定められるデフォルトサイズを適用する。こ
れは、〈オペレーション〉のニモニックが全体のオペラ
ンドにかかるという原則に対しては、例外となる。 [例] ビット操作命令のアクセスサイズ(BB指定)は、8bi
t(.B)がデフォルト.H,.Wは<<L2>>,.Lは<<LX>
> 固定長ビットフィールド操作命令のレジスタサイズ(X
指定)は、32bit(.W)がデフォルト、 .H,.Bは使用不可、.Lは<<LX>> BTST.W R0,@addr=BTST R0.W,@addr.B A2−3−4−5.アブソリュート オペランド=mem[abs16] mem[abs32] mem[abs64] A2−3−4−6.PC相対間接 オペランド=mem[disp16+PC] mem[disp32+PC] A2−3−4−7.スタックポップ オペランド=mem[SP++] A2−3−4−8.スタックプッシュ オペランド=mem[−−SP] A2−3−4−9.FP相対間接 オペランド=mem[disp4+FP] このアドレッシングモードでは、ビットパターン中に
指定されたdisp値を4倍して実際のディスプレースメン
トとするが、アセンブラでの表記に使う値は、4倍した
後のものである。 〈フォーマット〉を指定しない場合には、アセンブラ
での表記がレジスタ相対間接のモードと同じになるた
め、アセンブラによって最適なモードが選択される。つ
まり、@(disp,Rn)と書かれたオペランドでは、RnがR
14またはFPであり、かつdispが−32〜31の4の倍数の時
にはFP相対間接のモードが選択され、それ以外の場合に
はレジスタ相対間接のモードが選択されるわけである。 A2−3−4−10.SP相対間接 オペランド=mem[disp4+SP] このアドレッシングモードでは、ビットパターン中に
指定されたdisp値を4倍して実際のディスプレースメン
トとするが、アセンブラでの表記に使う値は、4倍した
後のものである。 A2−3−5.付加モード 付加モードについても、機能面の要求を示す総称ニモ
ニックと、フォーマットやビットパターンを記号化した
フォーマット別ニモニックを設ける。 [総称ニモニックに関して] ・@または により間接参照を表わし、 によりアドレスの加算を表わすという原則はそのままで
ある。 を原則とする。こうすると、実効アドレス計算の流れが
左から右への単純な形になり、先の段の付加モードに必
要な情報が先の方に、後の段の付加モードに必要な情報
が後ろの方に集まる。すなわち、総称ニモニックの表記
の順序が、付加モードの機械語ビットパターンの順序と
同じになる。したがって、フォーマット別ニモニックや
実際の機械語の付加モードとの対応がよく、アセンブラ
も簡単になり、理解しやすくなる。 [フォーマット別ニモニックに関して] ・フォーマット指定用として、つぎの3つの文字を導入
することにより、機械語のビットパターンと1対1に対
応した表記ができるようにする。 :B その部分の処理をベースモードにより実現するこ
とを表わす :A その部分まで処理を一段の付加モードにより実現
することを表わす :N その部分の処理は次の段の付加モード(':A'の指
定のある部分)でまとめて実現することを表わす なお、「その部分の処理」とは、フォーマット指定文
字がディスプレースメントやレジスタに付いている場合
にはその値の加算処理を、フォーマット指定文字が閉じ
括弧’)’についている場合は間接参照の処理を意味す
る。また、':A'で「その部分までの処理」とあるのは、
その':A'の部分の処理と、それより左側で':N'の付いた
部分(前の':A'または':B'との間で':N'の付いた部分)
の処理を合わせて行なうことを示す。 ・フォーマットをすべて指定した場合には、':A'の個数
が付加モードの段数になる。また、通常は一回の':A'が
一段の間接参照に対応する。ただし、複数のインデクス
レジスタを加算する場合(間接参照がなくても':A'が必
要)、最後の段で二重間接を行なう場合(二段の間接参
照でも一回の':A'でよい)は例外である。 ・フォーマットの表記のない場合には、総称ニモニック
として表記した処理を実現できるような付加モードが自
動的に選択される。また、実際の付加モードでは実現で
きないフォーマットをフォーマット別ニモニックで指定
した場合は、エラーとなる。さらに、フォーマット指定
ニモニックからフォーマット指定文字を取り去ると、そ
のまま総称ニモニックになる。このような点は、フォー
マット別ニモニックの一般的な原則と同じである。 [フォーマット一般に関して] ・複数のアドレス加算がない場合、 の括弧は書かなくてもよい。よって、例えば付加モード
で実現される3重間接参照の@(@(@(R1)))は@
@@R1と書いてもよい。これは、付加モード以外のアド
レッシングにも適用される原則であり、一種のシンタッ
クスシュガーと言える。 ・インデクスのスケール値は、IEEEでは':B',':W'など
サイズ指定文字を使用しているが、将来スケール値にも
っと大きな値を入れることも考えられるので、ここは従
来通りスケール値の数字を直接書くようにする。また、
スケーリングを指定する文字もIEEEの':'ではなく、’
*’を使用する。これは、':'をフォーマット指定の目
的で別に使用しているためである。 例: @(offset,PC) mem[offset+PC] 総称ニモニック。offsetが32ビットに入ればPC相対間接
モードで実現し、32ビットに入らなければ付加モードで
実現する。 @(offset,PC):N mem[offset+PC] 必ずPC相対間接モードで実現し、付加モードにはしな
い。 本発明装置64で、offsetが32ビットに入らない時はエラ
ーとなる。 @(offset[:N],PC[:N]):A mem[offset+PC] 必ず付加モードで実現する。ベースモードの指定に相当
する部分がないので、 絶対付加モード +付加モード El=10,disp= offset,index=PC,scale=1 になる。 @(PC[:B],offset[:N])[:A] mem[offset+PC] 必ず PC相対付加モード +付加モード El=10,disp= offset,index=0,scale=* で実現する。 @(@(@(R3[:B],base1[:N],R4*4[:N])[:
A],base2[:N],R5[*1][:N])[:N])[:A] mem[mem[mem[R3+base1+R4*4]+ base2+R5]] R3 相対付加モード +付加モード El=01,disp=base1 ,index=R4,scale=4 +付加モード El=11,disp=base2 ,index=R5,scale=1 @(R3[:B],base1[:N],R4*4[:A],R5*2[:
N])[:A] mem[R3+base1+R4*4+R5*2] R3 相対付加モード +付加モード El=00,disp=base1 ,index=R4,scale=4 +付加モード El=10,disp=base2 ,index=R5,scale=2 @(R3[:B],base1:A,R4*4:A):A mem[R3+base1+R4*4] R3 相対付加モード +付加モード El=00,disp=base1 ,index=0,scale=* +付加モード El=00,disp=0,in dex=R4,scale=4 +付加モード El=10,disp=0,in dex=0,scale=* これは一段の付加モードで実現可能であるにもかかわ
らず、フォーマットを指定してわざわざ三段の付加モー
ドにしている例である。 付加モードのシンタックスを以下にまとめておく。た
だし、括弧を省略する略記法、および各部分を区切るコ
ンマ についてのシンタックスは、ここには含めていない。 これは途中にある一段の付加モードを表わす。 ’*’は、アスタリスク’*’を文字として使うこと
を示す。「繰り返し」を表わすメタ的な意味はもたな
い。 〈インデクス〉の〈サイズ〉は、インデクスレジスタ
の有効なデータサイズである。本発明装置64で'.W'を指
定した場合には、レジスタの下位32ビットが64ビットに
符号拡張される。〈インデクス〉の〈スケール〉を省略
した場合には、1が仮定される。 A2−3−6.特殊オペランド 一般のアドレッシングモード以外の方法で指定される
オペランド(特殊オペランド)に関しては、次のような
シンタックスとする。なお、各部分を区切るコンマ','
についてのシンタックスは、ここには含めていない。 reglist(LDM,STM,ENTER,EXITD命令) 〈レジスタ番号〉または〈レジスタ番号〉−〈レジス
タ番号〉を で区切って並べ、 でくくったもの newpc(BRA,Bcc,BSR,ACB,SCB命令) アドレッシング方法は、PC相対モードのみである。 オペランドとしては、単にジャンプ先のラベルのみを
書く。 この場合は、アセンブラによって、その命令の先頭アド
レスとジャンプ先のアドレスとの差がnewpcのビットパ
ターンとして設定され、命令実行時にそのラベルの場所
へジャンプできるようになる。 BRA,Bcc,BSR,ACB,SCB命令は、出現頻度が高い、特殊
なアドレッシング(PC相対のみ)である、慣用的に行き
先のラベルをそのまま書ける方がよい、といった理由か
ら、〈行き先ラベル〉を書くだけで自動的に〈行き先ラ
ベル〉のアドレスと、これらの命令の置かれたアドレス
との差がディスプレースメントに設定されるようになっ
ている。すべてのオペランド表記のうちで、レジスタ以
外のシンボル名が先頭に’#’も’@’もなく現われる
のは、この〈行き先ラベル〉に限られる。 したがって、例えば BRA label は JMP @(label−$,PC) と同じ意味を表わすことになる。なお、’$’は、この
記号を含む命令(この場合はJMP命令)の先頭アドレス
を表わす。 adj(UNPKss命令) 頭に’#’を付ける。 vector(TRAPA命令) 頭に’#’を付ける。 その他 ・ビットフィールド命令などのリテラル指定は、短縮形
のリテラル指定と同じように #〈リテラル値〉 で表わす。 ・CHK,INDEX,ACB,SCBビットフィールド命令などのレジ
スタ指定は、一般のアドレッシングにおけるレジスタ直
接モードと同じように、 〈レジスタ番号〉 で表わす。 A2−4.フォーマット別ニモニックと総称ニモニック 「総称ニモニック」と「フォーマット別ニモニック」
は、本発明装置アセンブラの特徴の一つである。従来の
プロセッサでも一部の命令について似たような考え方は
見られたが(68020のMOVとMOVQなど)、本発明装置では
両方のニモニックを完全に体系化し、オペレーションだ
けではなくオペランドの記述にも同じ考え方を取り入れ
た点に特色がある。 フォーマット別ニモニックと総称ニモニックの間に
は、次のような関係がある。 ・インプリメントやフォーマットから来るいろいろな制
約をユーザに押し付けないのが総称ニモニックであり、
総称ニモニックを書く限りアセンブラが最適なコードを
選ぶ。同じ機能を持ち、同じようにフラグのセットされ
る命令は、できる限り一つの総称ニモニックに統合す
る。 ・フォーマット別ニモニックは、機械語のビットパター
ンと1対1に対応するものである。 フォーマット別ニモニックが変わっても、それはオブ
ジェクトサイズや実行サイクル数にのみ影響し、ユーザ
から見た命令機能はフラグ変化まで含めて全く同じであ
る。この点でフォーマット指定子とサイズ指定子は根本
的に異なる。サイズ指定子の場合は、演算サイズが変わ
るとユーザから見た命令機能も変化する。条件ジャンプ
命令ではBRA label:32のようなフォーマット指定子を使
っているのに、加算命令の場合は、ADD src.B,dest.Wの
ようなサイズ指定子を使っているのは、このためであ
る。 ・通常ユーザが使うのは、「総称」の方である。「フォ
ーマット別」は、仕様書でのフォーマットの説明、逆ア
センブラなどの特殊な用途でしか使わない。したがっ
て、場合によっては多少冗長な感じになることもある
が、使用目的を考えると特に問題はない。ユーザが主に
使用するのは、あくまでも総称ニモニックである。ま
た、「総称」と「フォーマット別」は両極端の表記法に
過ぎず、一部のみフォーマットを指定する中間的な記法
も存在する。例えば、@(offset,PC)を付加モードで
書きたいが、付加モードの各段のフォーマットはどうで
もよいという場合には、 @(offset,PC):A と記述する。「フォーマット別」と言っても、どうして
もフォーマット指定の必要な部分のみ指定を行なえばよ
く、実際にはそれほど長い記述にはならないのが普通で
ある。 ・「フォーマット別」から「総称」への変換は、':X'を
取ることにより機械的にできるようになっている。ま
た、逆の変換も、フォーマットが許される範囲で適当
に':X'を付ければ済むようになっている。オペランドの
順序は変化しない。 フォーマット別ニモニックとして、記号を変えたり、
順序を変えたりする方法も考えられるが、そうすると総
称ニモニックとの関係がスムーズではなくなるため、そ
のような方法はとっていない。(いろいろな場合分けが
必要になり、かえってわかりにくくなる。拡張性もよく
ない。) また、前述の@(offset,PC):Aのように、一部のフ
ォーマットのみ指定したい場合には、「フォーマット
別」か「総称」かの区別が統一的に行なえる方が望まし
い。 ・結局、ユーザからの要求を受けるインタフェースが総
称ニモニックであり、機械語からくる制約を受けるイン
タフェースがフォーマット別ニモニックである。両者の
調整をとるのが、':X'のフォーマット指定文字およびア
センブラである。 ・フォーマット別ニモニックと総称ニモニックを併用す
ることの欠点は、アセンブラが複雑化することである。
しかし、ユーザがフォーマットのことまで心配するより
は、アセンブラで処理できることはアセンブラで処理す
る方がよいと考えており、そのためにアセンブラが多少
複雑になるのはやむを得ない。 ・機械やフラグ変化の異なる命令は、たとえ命令のビッ
トパターンが似ていたとしても別の総称ニモニックにな
る。 以上のような理由から「フォーマット別」の方は、多
少記述が長くなっても、「フォーマット別ニモニックで
あること」や「どのフォーマットを使うかということ」
がはっきりわかるようにした方がよいと考えている。フ
ォーマットを表わす部分をすべて':X'に統一しているの
は、このためである。 なお、シンタックス中で とある部分は省略可能であるが、省略するかどうかが全
体で統一されている必要はない。例えば、ある を省略し、別の を残してもよい。 A2−5.言語としてのアセンブラ これまでに述べたアセンブラ表記は、機械語のビット
パターンに命令としてのニモニックを与えるための表記
法であり、アセンブリ言語の核となる部分である。本発
明装置では、ここまでを《L0》仕様とする。 しかし、アセンブラを一つの言語として見た場合に
は、ニモニック以外にも次のような項目を規定する必要
がある。これらの項目については、本発明装置のアーキ
テクチャと矛盾を起こさない範囲で、できるだけIEEEに
合わせるように標準化する。 ・大文字と小文字の使用をどうするか ・シンボルの文字数は何文字までにするか ・シンボルに式が書けるかどうか、シンタックスはどう
なるか ・ラベルの形式はどうするか(ラベルの後に′:′をつ
けるかどうか) ・2進数、8進数、10進数、16進数の表記法はどうする
か ・コメントの表記法はどうするか ・ストリングの記述形式 ・特殊キャラクタ(改行文字′¥n′など)の表現形式 ・細かいシンタックスや使用できる文字 ・アセンブラ疑似命令 ・マクロ このうち、2進数、8進数、10進数、16進数の表記法
については、IEEEでは以下のような形式になっている。 B′〜 2進数 例:B′00010010=H′12 Q′〜 8進数 例:Q′22=H′12 D′〜 10進数 例:D′18=H′12 H′〜 16進数 本仕様書でも、16進数を表わすために"H"〜”を、2
進数を表わすために"B"〜”を使用している。 A2−5−1.大文字と小文字について IEEEでは特に決まっていない。本発明装置では、ニモ
ニックや予約名に対しては、大文字と小文字を同等に扱
う。すなわち、この資料で大文字になっている部分に対
して、小文字を使用しても構わない。ただしユーザが定
義した一般の変数においては、大文字と小文字を区別す
る方を標準とする。 A2−5−2.シンボル値 〈ディスプレースメント〉、〈リテラル値〉、〈イミ
ディエート値〉、〈絶対アドレス〉などの項目(総称し
て〈シンボル値〉と呼ぶ)には、定数、ラベルを含む四
則演算式が書けるものとする。式の中では、優先順位を
変えるために を使用することができる。ただし、未確定の値(外部名
や後で定義されるラベルなど)を含む式に関しては、正
しいリロケーションができるように、演算式の形を制限
しても構わない。 さらに、式の中では現在注目している命令のアドレス
を示す値として、′$′を使用することができる。 PC相対間接モードの表記は @(disp,PC) であり,dispの値が直接ディスプレースメントに設定さ
れる。しかし、PC相対でリロケータブルなプログラムを
書く場合には、オペランドのアドレスそのものをdispと
して設定するのではなく、オペランドのアドレスとこの
命令のあるアドレスとの差をdisp値として設定する必要
がある。この目的で′$′を使用することができる。す
なわち、(オペランド−$)をdisp値として設定すれば
よい。 ′$′を使ったプログラム例 アドレスH′0100のMOV.B命令の第二オペランド@(l
oc−$:16,PC)では、実際のdispのビットパターンに設
定される値がH′0180−H′0100=H′0080となる。こ
の命令により、アドレスH′0180のlocに1がセットさ
れる。一方、H′0104のMOV.B命令では、アドレスH′0
104+8=H′010Cに2がセットされる。 付加モードと′$′を使ったオペランドの表記 @(@([0:B,]label1−$[:N],PC[:N])[:A],
label2−$[:N],PC[:N])[:A] これは mem[mem[disp1+PC]+disp2+PC]を表わす。 ただし、 disp1はlabel1の指すアドレスと現在アドレスとの差 disp2はlabel2の指すアドレスと現在アドレスとの差 であり付加モードの拡張部は 絶対付加モード +付加モード El=01,disp=disp1,index=PC,scale=
1 +付加モード El=10,disp=disp2,index=PC,scale=
1 という構成になる。 このモードは、リロケータブルなデーブル(case文用
のジャンプテーブルなど)をプログラム領域に置く場合
に使用できる。 一段目のPC相対間接 mem[disp1+PC] は、case文用のテーブル参照をリロケータブルにするた
めに用いられる。また、二段目のPC相対間接 は、ジャンプ先アドレスの決定をリロケータブルに行な
うために用いられる。 付録3.本発明装置メモリ管理方式概要 本発明装置を組み込み用などの用途に用いることを考
えると、命令セットは本発明装置になっているが、メモ
リ管理のハードウエア(MMU)は持たないといったバー
ジョンのチップも考えられる。 したがって、本発明装置のメモリ管理気機構は、必ず
サポートの必要な《L0》仕様でなく、標準的な仕様の提
示のみを行なう《LA》仕様となっている。以下では、
《LA》仕様としての本発明装置標準メモリ管理方式を説
明する。 A3−1.メモリ管理方式の選択と《LIR》仕様 本発明装置では、ハードウエアによるアドレス変換と
メモリ管理方式(以下MMUと呼ぶ)の標準仕様が、《L
A》仕様として用意されている。しかし、本発明装置にI
TRONやμBTRONを実装するような場合には、MMUが不要と
なることが多い。また、MMUを使用する用途であって
も、ページテーブルなどMMU関係の実行環境の設定が終
わるまでは、アドレス変換なしで命令を実行する必要が
ある。 そこで、本発明装置では、MMU機構を使用しているか
どうか、アドレス変換を行なっているかどうか、を示す
フィールドをPSW内に設け、このフィールドを書き換え
ることにより、アドレス変換やメモリ保護の有無を指定
できるようにしている。このフィールドをAT(Address
Translation)フィールドと呼ぶ。ATはPSSのbit6〜bit7
に配置されている。ATをPSW内に設けたことにより、LDC
TX等によるコンテキストスイッチや、EIT処理の起動、R
EIT命令によるタクサ処理ハンドラからのリターンの際
にも、アドレス変換の有無を切り換えることが可能であ
る。 ATフィールドの意味を以下に示す。 このうち、《LA》仕様の標準メモリ管理を実装した本
発明装置ではAT=00,01が利用可能、《L1R》本発明装置
ではAT=00,10が利用可能となる。 《L1R》仕様のAT=10の場合、MMUがないのでページ毎
のメモリ保護は行なえないが、《LA》の4リングを縮退
してリング0、リング3のみを有効とし、アドレスによ
って簡単なメモリ保護を行なう。アドレスのMSB=1の
領域(《LA》でいうSR)はリング0からアクセス可能、
リング3からアクセス禁止の領域であり、通常はここに
OSを置く。一方、アドレスのMSB=0の領域(《LA》で
いうUR)はリング0からもリング3からもアクセス可能
な領域であり、通常はここにユーザプログラムを置く。
MMUがないのでユーザプログラム間のメモリ保護はでき
ないが、ユーザプログラムからOSを保護することは可能
である。 AT=00(アドレス変換なし)の場合は、メモリアクセ
スに対するリング保護のチエックは行なわれない。 したがって、ページ不在例外(POE)、アドレス変換
例外(ATRE)は発生しない。 ただし、AT=00の場合も特権命令のチエックは行なわ
れる。 AT=00の時の動作については、《L1》と《L1R》で全
く同じになることが望ましい。しかし、LDATEなどの命
令では、《L1》ならばMMU環境の設定という意味で実用
的な命令であるのに対して、《L1R》では全く意味を持
たない。また、PTLBなどの命令も《L1》のAT=00ならば
一応意味を持っているが、《L1R》ではTLBそのものがな
いので全く意味を持たない。したがって、《L1R》仕様
ではこういったMMU関係の命令を実行しないことにす
る。《L1R》でこういった命令を実行しようとした場合
は、ATの値にかかわらず予約命令例外(RIE)となる。 A3−2.本発明装置のメモリ管理方式 本発明装置は《L1R》仕様のチップである。 本発明装置のATフィールドの意味を第292図に示す。 A3−3.本発明装置のI/O空間アクセスに関して IOMASK,IOADDRで示されるI/O空間に対する命令フェッ
チ及びメモリ間接アドレッシング・モードによるオぺラ
ンドフェッチはアドレス変換例外となる。 I/O空間に対するアクセスで、メモリ間接アドレッシ
ングの場合はアクセス動作は一切行なわれない。しか
し、命令フェッチの場合にはアクセス動作が行なわれ
る。そのため、外部のI/Oデバイスはバスアクセスタイ
プ(BAT)信号をみて命令フェッチであれば応答しない
ようにする必要がある。I/O空間は通常リング0の領域
におかれるためリング3からのアクセスはリング保護違
反が検出されることになると考える。リング保護違反の
場合は高速に検出可能なためメモリアクセスは行なわれ
ない。 また、I/O空間とI/Oでない空間をまたぐようなアクセ
スが行われた場合、アドレス変換例外を起こすが、その
場合の再実行動作を保証できない。 A3−4.メモリ管理の目的と概要 本発明装置では、以下のような目的を達成するため
に、ハードウエアによるメモリ管理機構(MMU)を導入
している。 ・命令再実行と仮想記憶方式のサポートにより、実装さ
れている物理メモリの量を越える大きさの論理空間を提
供する。 ・多重論理空間の機能の導入により、コンテキスト(タ
スクやプロセス)間の独立性を維持し、プログラムを作
りやすくする。 ・リング保護の機能の導入により、OSや共有データとユ
ーザプログラムやユーザデータとの間でメモリ保護を行
なう。 本発明装置では、以上のような機能を提供するため
に、毎回のメモリアクセスでページング方式によるアド
レス変換を行なう。アドレス変換前のアドレス(論理ア
ドレス)の作る空間を、Logical Spaceの意味でLSと予
備、アドレス変換後のアドレス(物理アドレス)の作る
空間を、Physical Spaceの意味でPSと呼ぶ。 ページングの場合には、メモリアクセスを高速化する
ために、TLB(Translation Lookaside Buffer)と呼ば
れるアドレス変換対の記憶バッファを導入することが一
般的である。しかし、TLBはメモリアクセスを高速化す
るためのインプリメント上の手段と考えられるため、本
発明装置のMMU仕様としてはTLBに関する規定は行なわな
い。本資料でも、TLBに関する説明は行なっていない。 また、コンテキストの切り換えによるTLBのパージを
減らすため、《L2》として論理空間識別子(LSID)の機
能を導入することができる。LSIDは、コンテキスト毎に
ユニークに与えられた番号であり、LSIDまで含めてTLB
の論理アドレス比較を行なうようにすれば、コンテキス
トを切り換える際にもすべてのTLBをパージする必要が
なくなる。しかし、LSIDの機能についてもインプリメン
ト依存性が強いため、本発明装置のMMU仕様としては、L
SIDの詳細機能やビット数の規定を行なっていない。本
発明装置の仕様では、LSIDを示す制御レジスタのアドレ
ス割り当てと、LSIDを実装した場合のTLBやキャッシュ
の整合性確保に関する説明のみが行なわれている。 A3−4−1.ページング 本発明装置のアドレス変換は、ページングを基本とし
ている。ページサイズは4KBとして本発明装置全体で統
一されている。これによって、TLBの構造などをある程
度限定することができ、メモリ管理機構を内蔵できるチ
ャンスが大きくなる。また、基本的なパラメータを固定
化すれば、それにチューニングすることで性能向上が期
待できる。 アドレス変換に際し、本発明装置32の論理アドレスは
第293図のように分割され、これによって2段階のペー
ジングを行なう。 32ビットの論理アドレスは、4GBの論理空間を作る。
Rビット(論理アドレスのMSB)により、4GBの論理空間
は2GBのUnshared Region(UR)とShared Region(SR)
に別かれる。おのおののRegionは、SXフィールドにより
4MBずつのSectionに分かれる。さらに、おのおののSect
ionは、PXフィールドによりRKBずつのPageに分かれる。 したがって、2段階のページングのうち上位段のペー
ジテーブルは、SXをインデクスとして、下位段のページ
テーブルのベースアドレスを引き出すものとなる。これ
をSection Table(ST)と呼び、その一つのテーブルエ
ントリをそのエントリをSTEと呼ぶ。また、2段階のペ
ージングのうち下位段のページテーブルは、PXをインデ
クスとして、物理ページのベースアドレスを引き出すも
のとなる。これをPage Table(PT)と呼び、その一つの
テーブルエントリをそのエントリをPTEと呼ぶ。一つのS
TEの変更により一つのSectionが、一つのPTEの変更によ
り一つのPageが影響を受けることになる。 PTE,STEの総称名としてATE(Address Translaton tab
le Entry)という名称を用いる。 STのベースアドレスは、URの場合UATB、SRの場合SATB
という制御レジスタによって示される。UATBまたはSATB
の変更により、一つのRegion(UR又はSR)が影響を受け
る。以上述べた関係をまとめたものを第294図に示す。 A3−4−2.多重論理空間 本発明装置では、論理アドレスのMSBによって、共通
空間(Shared Region)と個別空間(Unshared Region)
が区別されている。それぞれのRegionに対して、アドレ
ス変換のテーブルベースレジスタUATB,SATBが存在する
が、このうちUATBのみはコンテキスト毎に切り換わるよ
うになっており、これによって多重論理空間を実現す
る。 すなわち、UR(論理アドレスH′00000000〜H′7fff
ffff)ではコンテキスト毎に別々の物理空間(物理メモ
リ)が割り当てられるのに対して、SR(論理アドレス
H′80000000〜H′ffffffff)ではコンテキスト間で共
通の物理空間(物理メモリ)が割り当てられる。Shared
Regionは主に割り込み処理ハンドラやOSが使用し、Uns
hared Regionは主にユーザプログラムが使用するもので
あるが、ユーザデータでもタスクやプロセス間で共用す
るものはSRを使用する場合があるし、OSの管理するデー
タでもタスクやプロセス毎に持つ必要のあるものはURを
使用する場合がある。 多重論理空間の機能を利用すれば、同一の論理アドレ
スから複数のプログラムを同時に実行することができる
ので、実行時にオブジェクトコードのリロケーションを
する必要がなくなる。また、他のタスクやプロセスのUR
を直接参照することはできないので、プログラム間のメ
モリ保護にも役立つ。 なお、UR,SRの区別と後述のメモリのリング保護の機
能とは、直接の関連はない。すなわち、ring3からSRを
参照できないとか、PCがURにある間はSRを参照できない
とかといった制限は、UR,SR自体の機能には含まれてい
ない。このようなメモリのアクセス制限を行ないたい場
合には、メモリのリング保護の機能を利用し、STE,PTE
に適当な保護コードを設定しておかなければならない。 〔多重論理空間の構成〕 第295図において ・Unshared Region/Shared Regionの切り替えは、論理
アドレスのMSBによって行なわれる。 ・Unshared Regionでは、UATBレジスタによってアドレ
ス変換される。 ・Shared Regionでは、SATBレジスタによってアドレス
変換される。 ・UATBレジスタのみコンテキスト毎に切り換わるため、
Unshared Regionでは、それぞれのコンテキストが別々
の論理空間を持つことができる。 アドレス変換が2段のページングとなっているため、
異なるコンテキストの2つのSTEが同一のPage Tableを
指すことにより、URの中での共用セクション、共有ペー
ジを設けることもできる。 なお、URとSRの境界にまたがるようなプログラムやデ
ータについては、以下のように考える。 ・64ビット拡張時には、現在連続しているURとSRの境界
が不連続になるため、H′7fffffffから先に伸びている
プログラムは、64ビット拡張時に使用できなくなる。こ
れは、本発明装置32で、H′7fffffffの次のアドレスを
H′00000000と考えてもH′80000000と考えても同じで
ある。 したがって、URとSRの両方にまたがるようなメモリア
クセスや、UR〜SRで連続するような命令のフェッチを行
なうべきではない。 ・しかしながら、URとSRにまたがっているか同化のチエ
ックを毎回行なうのは、インプリメント上の負担が大き
いため、URとSRの両方にまたがるアクセスがあったとし
てもEITとはしない。この場合、Regionとは関係なく、
アドレスがリニアアドレスであるという考え方を生か
し、H′7fffffffの次はH′80000000、H′ffffffffの
次はH′00000000のアドレスをアクセスするものとす
る。ただし、前項でも述べたように、この仕様を利用す
るようなプログラムを書くべきではない。 PSW,UATB,SATBに対するLDC命令や、LDATE,LDCTX命令
による論理空間の切り換えでは、現在実行中のプログラ
ム領域のアドレス変換に対しても影響を与えることがで
きる。したがって、使い方によっては次の命令から全く
別場所に飛んでしまうというケースも生じる。これはプ
ログラムの責任で処理しなければならない。具体的に
は、ATビットの変更を行なう場合はV=R領域を利用し
たり、LDCTXを実行する場合はSR(Shared Region)を利
用したりすることになる。 A3−4−3.リング保護 本発明装置のメモリ保護方式は、4レベルのリング保
護である。保護情報は、論理アドレスやUR,SRの区別に
は関係なくページ毎に指定することができる。 リング保護では、PSW中に示される現在リング番号(R
NG)と、アクセスすべき論理アドレスのSTE,PTEに含ま
れている保護コードとの関係によって、アクセスが可能
かどうかが決まる。RNGが小さい値であるほど、すなわ
ち内側のリングであるほど強いアクセス権を持ってお
り、RNG=3を最もアクセス権が弱い。rng1<rng2とし
た場合、RNG=rng2でアクセスできるページは必ずRNG=
rng1でもアクセスできることになる。 A3−5,MMU関係制御レジスタ MMUに関係する制御れしについて説明する。 ・PSW 別項参照。 MMUに関連するのは、RNG,STのフィールドである。 ・LSID 別項参照。 このレジスタの有無と有効なビット数は、インプリメ
ントに依存する。 ・UATB(Unshared region Address Translation table
Base) 第296図に示す。 ・SATB(Shared region Address Translation table Ba
se) 第297図に示す。 STB: Section Table Base Section Tableの物理ベースアドレス =: ′0′にreserved ユーザ向けのマニュアルでは、′0′を書き込むように
指導しておく。 ただし、′1′を書き込んでも無視される。 読みだし時は値不定である。 D: Direction Section Tableのサイズが小さい場合のSection Tableの
方向 D=D Section Tableの下位アドレス側が有効 D=1 Section Tableの上位アドレス側が有効 DとLLのフィールドは、小規模な用途で、有効な論理ア
ドレスの範囲を制限し、同時にSection Tableのサイズ
を縮小するために使用するものである。 LL: Length Section Tableのサイズ LL=00 1/2サイズ 512エントリ 2K Bテーブル 2G B Region LL=01 1/4サイズ 256エントリ 1K Bテーブル 1G B Region LL=10 1/16サイズ 64エントリ 256Bテーブル 256MB Region LL=11 1/64サイズ 16エントリ 64Bテーブル 64MB Region PI: Page In PI=0 Section Tableが物理アドレスに存在しな
い。 この場合には、STBはハードウエア的な意味を持たな
いので、OSで自由に使用することができる。ただし、PI
=0でもD,LLのフィールドは有効である。D,LLのふい
は、アドレス変換例外(ATRE)の未使用領域参照エラー
か、ページ不在例外(POE)かを区別するために使用さ
れ、例外の検出は前者が優先される。 つまり、PI=0の時にこのレジスタを使ってアドレス
変換を行おうとした場合、D,LLのフィールドにより未使
用領域参照エラーが検出されればアドレス変換例外(AT
RE)が発生し、そうでなければページ不在例外(POE)
が発生する。 PI=1 Section Tableが物理アドレス上に存在す
る。 PI=1であれば、このレジスタを使ってアドレス変換を
行なうことが可能である。ただし、D,LLのフィールドに
より未使用領域参照エラーが検出された場合には、アド
レス変換例外(ATRE)が発生する。 SATB,UATB中のPIビットは、正確にはPage Inではなく
Section Table Inの意味を表わす。また、後述するSTE
中のPIビットは、Page InではなくPage Table Inの意味
を表わす。しかし、あえて区別する必要もないと思われ
るので、いずれも同じ′PI′という名称を使用する。広
義の「ページ」は、「ページテーブル」や「セクション
テーブル」、つまりディスクへの追い出しの単位となる
ものをすべて含むことになり、ページテーブルやセクシ
ョンテーブルの不在にも「ページ不在例外」という例外
の名称をそのまま適用する。 Section Table,Page Table自体をページアウトするこ
とも可能であるが、ページインされているテーブルにつ
いては、テーブルのベースアドレス(STB,PTB)は物理
アドレスを表わすものとする。すなわち、ページテーブ
ルは論理空間ではなく物理空間に置かれていると考える
ことができる。また、Section TableやPage Tableが4K
のフルサイズでない場合にST,PTのページアウトを許す
と、64B,256B,1KB,2KB単位でページ不在となるケースも
生じる。つまり、UATB,SATB,STEでのPIビットは、必ず
しも4K単位でのページ不在を指すとは限らないので、注
意する必要がある。 セクションテーブル、ページテーブルの大きさが可変
になっているが、テーブルが最小(1/64)の大きさでな
い時には、STBとSXの有効なビットに重なりが生じる。
例えば、UATB,SATBでD=0,LL=00とした場合、以下の
ような計算によりSTEの実効アドレスを算出する必要が
ある。 ここで、′X′の重なっているビット、すなわちSTB
の2^6〜2^11のビットの扱いが問題となる。以下のよう
な案が考えられる。 STBの2^6〜2^11のビットは′0′でなければならない
ものとする。インプリメント上は、STBの2^7〜2^31とSX
を20ビット右にシフトしたものとを連結することによっ
て、STEのアドレスを算出することができる。(アライ
メント強制) STBの2^6〜2^11のビットが0でなくてもよいが、2^11
までの範囲でSTEの実効アドレスがラップアラウンドす
る。インプリメント上は、重なりのある5ビットのみの
加算を行ない、加算により生じた桁上がりは無視するこ
とになる。(ラップアラウンド) STBの2^6〜2^11のビットが0でなくてもよく、Sectio
n Tableに対して2^6より上位のアラインメントは全く強
制しない。インプリメント上は、まず重なりのある5ビ
ットの加算を行ない、桁上がりを生じた場合には最上位
桁まで桁上がりを伝搬させる必要がある。つまり、2^6
より上位のビットについてすべて加算を行なう必要があ
る。(アライメント自由) 現在が本発明装置の仕様となっている。LL=01,10
の場合、またPTBとPXのアライメントの場合も同じよう
にの仕様とする。 DとLLの機能は、小規模な用途でSection Tableの領
域を節約するために設けられているものである。DとLL
の指定が変わると、Section Tableが小さくなるため、S
Xの取り得る値に制限ができる。D,LLのそれぞれの値に
対して、許されているSXの値は第298図のようになる。 D=1,LL=00のreservedの部分は、ソフトウェアで使
用してはいけない。マニュアルにもreservedであること
を明記する必要がある。ただし、この値を実際にUATBや
SATBに設定した場合は、D=0,LL=00と同じ動作をす
る。つまり、LL=00の場合にはDは無視される。 論理アドレスとして、上の表に当てはまらない値を指
定した場合には、アドレス変更例外(ATRE)の未使用領
域参照エラーが発生する。ページ不在例外(POE)とア
ドレス変更例外(ATRE)が同時に発生した場合には、ア
ドレス変更例外(ATRE)が優先される。例えば、UATBの
D=0,LL=10,PI=0で論理アドレスH′40000000をア
クセスした場合には、POEではなくATREとなる。 DとLLの指定によるテーブル領域の節約のようすを図
示すると、第299図のようになる。 この時、使用する論理アドレスの範囲が狭いため、は
じめの数個のSTEのみが利用できれば済むというの例
であれば、第300図のようにすることによって、section
tableの大きさを節約することができる。 又、スタック領域やOS用の領域などで、終わりの数個
のSTEのみが利用できれば済むというの例であれば、
第301図のようにすることによって、section tableの大
きさを節約することができる。 ※D=1の場合、STBはsection tableの有効部分の先頭
アドレス(SXとしては途中の値に対応する)を指すので
はなく、SX=0に対応するSTE(実際には存在しない)
の置かれるべきアドレスを指す。STE中のPTBの場合も同
様である。 A3−6.STEとPTE STEとPTEは、メモリ上に置かれるアドレスの変換用の
ディスクリプタである。STEとPTEのフォマットについて
説明する。 ・STE(Section Table Entry)第302図に示す。 PTB:Page Table Base Page Tableの物理ベースアドレス W: Write可能 W=1 書き込みのアクセス権はPTEの保護コードに従
う W=0 PTEの保護コードにかかわらず、全リングから
書き込み禁止 違反した場合はアドレス変換例外(ATRE)のリング保護
違反エラーが発生 E: Execute可能 E=1 実行のアクセス権はPTEの保護コードに関わら
ず、全リングから実行禁止 違反した場合はアドレス変換例外(ATRE)のリング保護
違反エラーが発生 D: Direction Page Tableのサイズの小さい場合のPage Tableの方向 D=0 Page Tableの下位アドレス側が有効 D=1 Page Tableの上位アドレス側が有効 LL: Length Page Tableのサイズ LL=00 フルサイズ 1024エントリ 4K Bテーブル 4M B Section LL=01 1/4サイズ 256エントリ 1K Bテーブル 1M B Region LL=10 1/16サイズ 64エントリ 256Bテーブル 256KB Region LL=11 1/64サイズ 16エントリ 64Bテーブル 64KB Region PI: Page In PI=0 Page Tableが物理アドレス上に存在しない。 この場合には、PTBはハードウエア的な意味を持たな
いので、OSに自由に使用することができる。ただし、PI
=0でもD,LLのフィールドは有効である。D,LLのフィー
ルドは、アドレス変換例外(ATRE)の未使用領域参照エ
ラーやリング保護違反エラーか、ページ不在例外(PO
E)かを区別するために利用され、例外の検出は前者が
優先される。 つまり、PI=0の時にこのSTEを使ってアドレス変換
を行なおうとした場合、D,LLのフィールドにより未使用
領域参照エラーやリング保護違反エラーが検出されれば
アドレス変換例外(ATRE)が発生し、そうでなければペ
ージ不在例外(POE)が発生する。 PI=1 Page Tableが物理アドレス上に存在する。 PI=1であれば、このSTEを使ってアドレス変換を行な
うことが可能である。ただし、D,LLのフィールドにより
未使用用領域参照エラーやリング保護違反エラーが検出
された場合には、アドレス変換例外(ATRE)が発生す
る。 STBとSXの時と同様に、PTBとPXの場合にも、PTBのア
ラインメントは自由とする。すなわち、LL≠11の時に
は、PTBとPXの有効なビットに重なりの生じる場合があ
るが、重なった部分のアドレスについては最上位桁まで
加算を行なう。DとLLの機能は、小規模な用途でPage T
ableの領域を節約するために設けられているものであ
る。DとLLの指定が変わると、Page Tableが小さくなる
ため、PXの取り得る値に制限ができる。D,LLのそれぞれ
の値に対して、許されているPXの値は第303図のように
なる。 論理アドレスとして、上に当てはまらない値を指定し
た場合には、アドレス変換例外(ATRE)の未使用領域参
照エラーが発生する。 D=1,LL=00の部分に対しては、W,Eが特別な意味を持
つ。D=1,LL=00のSTEを使ってメモリアクセスを行な
おうとした場合には、次のような動作をする。この時、
SXの値は関係しない。また、PTBのフィールドとEビッ
トは、ハードウェアで使用しないので、OSから自由に利
用することができる。 第304図において ’*’はソフトウエアで自由に使用してよいビットであ
る。ハードウエア的にはこのビットが無視される。 このビットは、reservedを示す’=’とは異なり、将
来の使用拡張でも使用しないことがはっきりしているビ
ットである。’=’と’*’は、現在の使用におけるハ
ードウエア的な動作は同じであるが、将来の拡張のため
に仕様書上きの扱いが異なっている。 なお、未仕様領域参照エラーと予約ATEエラーの区別
は、アドレス変換例外(ATRE)が起動された際にスタッ
クに積まれるエラーコードによって行われる。これらの
エラーによるアドレス変換例外の起動は、STE,PTEの値
を設定した時に検出されるのではなく、値を使用する時
(アドレス変換の時、つまりメモレアクセスを行った
時)に検出される。 D=1,LL=00,W=0の機能は、一つのSection全体を未
使用領域としたい場合に利用する機能である。この場
合、このSTEに対するPage Tableは無い。 LL≠00の機能を利用して小さいサイズのSection Table,
Page Tableを使用する場合でも、論理アドレス中のSX,P
Xの位置は変わらない。したがって、複数のSTEから小さ
いサイズのPage Tableを使用する場合には、有効な論理
アドレスが飛びの値をとることになる。この様子を第30
5図に示す。 このように、小さいサイズのPage Tableを使った場合
には、有効な論理アドレスが連続領域とはならないこと
がある。しかし、STEを1エントリしか使用しないよう
な小規模な応用のため、あるいは、長さが半端になった
論理空間の最後の部分のテーブルについて、「テーブル
領域の節約」を行なうためにLL≠00の機能が容易されて
いるのだと考えると、LL≠00の時にアドレスが連続しな
くても、特に問題はない。 STEでは、D,LLによるアドレス変換例外(ATRE)の未
使用領域参照エラー、W=0,E=0によるアドレス変換
例外(ATRE)のリング保護違反エラー、PI=0によるペ
ージ不在例外(POE)が同時に発生する可能性がある
が、例外の検出順序はこの順とする。つまり、まず未使
用領域かどうかのチェックを行ない、次にアクセス権の
チェックを行ない、最後にページ不在のチェックを行な
う。これは、PTEの場合も同様である。したがって、ペ
ージ不在の時でも、リング保護関係の情報は有効であ
る。 ただし、この例外検出順序は、一つの段(STEまたはP
TE)の中での例外検出順序であり、これよりもさらにテ
ーブルを引く順序が優先する。つまり、,さたで発生す
る例外よりもSTEで発生する例外の方が優先される。 ・PTE(Page Table Entry)第306図に示す。 PFN: Page Frame Number 対応するページの先頭物理アドレス4KBが単位になる。 **: OSが自由に利用できるビット ハードウエア的には意味を持たない R: Referenced このページが参照されたとき、1にセットされる。 M: Modified このページの一部が変更されたとき、1にセットされ
る。 RL: Read Level RL=00 リング0のみから読みだし可能 RL=01 リング0〜1から読みだし可能 RL=10 リング0〜2から読みだし可能 RL=11 リング0〜3から読みだし可能 違反した場合はアドレス変換例外(ATRE)のリング保護
違反エラーを発生 T: Type T=00 書き込み禁止、実行禁止 T=01 書き込み禁止、実行可能 T=10 書き込み可能、実行禁止 T=11 書き込み可能、実行可能 「書き込み可能」の場合は、min(RL,AL)のリングから
書き込み可能、それより外側からは書き込み禁止とな
る。 「実行可能」の場合は、max(RL,AL)のリングから実行
可能、それより外側からは実行禁止となる。 違反した場合はアドレス変換例外(ATRE)のリング保
護違反エラーを発生 AL: Access Level for indicated type (T≠00の場合) AL=00 リング0のみからアクセス(書き込み、実行)
可能 AL=01 リング0〜1からアクセス(書き込み、実行)
可能 AL=10 リング0〜2からアクセス(書き込み、実行)
可能 AL=11 リング0〜3からアクセス(書き込み、実行)
可能 (T=00の場合) AL=00 リング0〜RLから読みだし可能 書き込み、実行は禁止(T,RLの本来の意味で使用) AL=01 アドレス変換例外(ATRE)の未使用領域参照エ
ラーを発生 AL=10(reserved) AL=11(reserved) T=00の場合は、ALによるアクセス可能リングの指定が
必要ないので、ALを別の意味に使っている。このうち、
AL=01の指定による未使用領域参照エラー発生の機能
は、一つのPage全体を未使用領域としたい場合に利用す
る機能である。この場合、このPTEに対する物理ページ
は存在しない。 NC: Non Cachable NC=1 キャッシュへの取り込みの禁止を指定 I/OレジスタやVRAMの領域などで、キャッシュへの取り
込みやメモリアクセスの順序の変更が許されないページ
の場合に、このビットをセットする。 NC=0 通常のページであるたとを指定 PI: Page In PI=0 Pageが物理アドレス上に存在しない。 この場合には、PFNはハードウエア的な意味を持たな
いので、OSに自由に使用することができる。ただし、PI
=0でもRL,T,ALなどのフィールドは有効である。これ
らのフィールドは、アドレス変換例外(ATRE)の未使用
領域参照エラーやリング保護違反エラーか、ページ不在
例外(POE)かを区別するために利用され、例外の検出
は前者が優先される。 つまり、PI=0の時にこのPTEを使ってアドレス変換
を行おうとした場合、RL,T,ALなどのフィールドにより
未使用領域参照エラーやリング保護違反エラーが検出さ
れればアドレス変換例外(ATRE)が発生し、そうでなけ
ればページ不在例外(POE)が発生する。 PI=1 Page Tが物理アドレス上に存在する。 PI=1であれば、このPTEを使ってアドレス変換を行な
うことが可能である。 ただし、RL,T,ALなどのフィールドにより未使用領域
参照エラーやリング保護違反エラーが検出された場合に
は、アドレス変換例外(ATRE)が発生する。 PFNと論理アドレスのoffsetの間では、有効なビット
が重なり合うことはないため、アライメントの問題は発
生しない。 PTEのRL,T,ALの値と、実際にそれをアクセス可能なリ
ングとの関係は、具体的には第307図のようになる。 図において ・ROはring0からのアクセス権、R1はring1からのアクセ
ス権を示す。ring0〜ring3の区別はPSW中のRNGフィール
ドで示される。 ・Rは読みだし可能、Wは書き込み可能、Eは実行可能
を示す。 T=00,AL≠00の場合、ALが特別な意味を持ち、第308図
のような動作をする。この時、offsetの値は関係しな
い。このうち、T=00,AL=01の場合には、ハードウエ
アで使用しないPTBのフィールドとRLフィールドを、OS
から自由に利用することができる。 T=01を指定すると、読みだしはできないが実行は可能
であるというページを作ることができる。これは、プロ
グラムのコピーを禁止し、プログラムの実行に対する課
金メカニズムを導入することを意図したものである。 一方、T=00,T=10を指定すると、読みだしや書き込
みは可能であるが、実行は禁止であるというページを作
ることができる。この機能を利用すれば、プログラムカ
ウンタがデータ領域に飛び込んで来た場合に、それをチ
ェックしてプログラムの暴走を阻止することができる。
実行を禁止する機能は、メモリのデータ保護のための機
能というよりも、デバックのための機能と考えることが
できる。 書き込みが可能である場合には、からなず読みだしも
可能となっている。 A3−7.64ビットへの拡張性 SR/URの切り換えビットを論理アドレスのMSBに固定す
ると、64bitへの拡張時に問題が生じる可能性がある。
本発明装置では、論理アドレスを符号付きの数と考える
ことるよって、この問題に対処する。 SRとURの双方を32ビットから64ビットに拡大するために
は、アドレス空間が二方向に伸びればよいわけである。
そこで、アドレスを符号付きの数と考え、UR領域が正方
向にSR領域が負方向に伸びると考えれば、この問題は解
決される。具体的には、32→64の拡張に対して、論理ア
ドレスは符号拡張するようにしておく。メモリマップは
第309図のようになる。 あるいは、図の書き換え方をかえて、第310図のよう
になる。 アドレスを符号付きと考えることにより、SR,UR双方
の領域で拡張に対する連続性が保たれる。その代わり、
H'80000000におけるOS領域とユーザ領域の接点が切られ
ることになるが、これは問題ないと考えられる。 なお、本発明装置の16ビット絶対アドレッシングモー
ド(@ads:16)で、論理アドレスを符号拡張するように
なっているのも、アドレスを符号付きとする考え方を適
用したものである。 A3−8.MMU機能のバリエーションとLSIDの機能 LSIDの機能は《L2》であるため、最初のチップでは実
装されず、将来のチップで導入される可能性が高い。し
たがって、最初に出たチップのためのLSIDの機能を利用
しないプログラムも、将来のLSIDの機能の実装を見越し
たものにしておくのが望ましい。かといって、最初のチ
ップでも不必要なオーバーヘッドは避けなければならな
い。そこで、こういったLSID(論理空間識別子)機能の
有無やMMU機能の各種のバリエーションと、プログラム
(OS)の互換性との関係について、検討を行なう必要が
ある。 一般的な話として、MMU関係の仕様のバリエーション
に対する対応には次の2つの方針がある。 互換性を維持するため、実装していない機能であって
も、縮退した機能でそのまま実行する。この場合、性能
は落ちるだけで、オブジェクトレベルの互換性は達成さ
れる。 実装していない機能については、EITで検出する。EIT
起動の目的は、まちがいの検出とエミュレーションであ
るが、エミュレーションでは極端な性能の低下を招く場
合があるので、実際問題として、オブジェクトレベルで
変更の必要な場合が多い。 したがって、オブジェクトレベルの互換性は難しい
が、あらかじめそれぞれのバリエーションの仕様が明ら
かになっていれば、ソースレベルで両方の仕様に対応で
きるようなプログラムを書くことは難しくない。 例えば、PSTLB命令の機能を実装しない場合に、PSTLB
をPTLBとして実行するのはの方針であり、EIT(RIE9
とするのはの方針となる。かかは個別に検討する
必要がある。 ・PSTLBのS/Tオプションについて TLBやキャッシュのインプリメント方式によっては、/ST
オプションの実装が難しい場合がある。しかし、/STオ
プションの指定は、TLBのパージ範囲だけに影響するの
で、互換性維持のためにの方針をとる。すなわち、/S
Tオプションの実装が難しい場合には、EITではなく/AT
想到の動作を行なうということにする。 ・LSID機能の実装とPTLB,PSTLBの/SSオプションについ
て PTLB,PSTLBの/SSオプションの実装については、TLBのキ
ャッシュのタグにLSIDの値を含めない場合にも、/SSオ
プションで全パージすることにより、の方針に合わせ
ることは可能である。しかし、LSID制御レジスタに値を
書き込んだり、それを読みだしたりすることを考える
と、オブジェクトレベルでの完全な互換性を達成するた
めには、SLID制御レジスタに相当するものを設けておく
必要がある。ところが、互換性の確保だけのためにレジ
スタを一実装するのは無駄が多い。また、ハードウエア
だけではなくソフトウエアに関しても、OSの中でLSIDの
操作を行なう部分は、LSIDの機能を活かさなければ無駄
な処理になってしまう。したがって、LSIDの有無につい
てはの方針をとる。それに合わせて、/SSオプション
の実装についてもの方針とする。 LSID機能の実装とPTLB,PSTLBの/SSオプションについて PTLB,PSTLBの/SSオプションの実装については、TLBや
キャッシュのタグにLSIDの値含めない場合にも、/SSオ
プションで全パージすることによりの方針に合わせる
ことは可能である。しかし、LSID制御レジスタに値を書
き込んだり、それを読みだしたりすることを考えると、
オブジェクトレベルでの完全な互換性を達成するために
は、LSID制御レジスタに相当するもおを設けておく必要
がある。ところが、互換性の確保だけのためにレジスタ
を一つ実装するものを設けておく必要がある。ところ
が、互換性の確保だけのためにレジスタに関しても、OS
の中でLSIDの操作を行なう部分は、LSIDの機能を生かさ
なければ無駄な処理になってしまう。したがって、LSID
の有無についてはの方針をとる。それに合わせて、/S
Sオプションの実装についてもの方針とする。 具体的なLSID関連の仕様は、次のようになっている。 −LSIDの機能の有無と/SSオプションの実装の有無を一
対一に対応させる。LSIDのあるプロセッサは/SSオプシ
ョンが利用できるし、LSIDのないプロセッサは/SSオプ
ションを利用できない。 −LSIDのあるプロセッサは、LSIDのないプロセッサに対
してオブジェクトレベルで完全上位互換とする。つま
り、LSIDのないプロセッサのために書かれたOSは、LSID
のあるプロセッサの上でもそのまま動く。ただし、LSID
の機能は生かすことができない。 −LSIDのあるプロセッサのために書かれ、LSIDの機能を
生かすようなOSは、LSIDのないプロセッサでは動かない
場合がある。具体的には、LSID制御レジスタの際に予約
機能例外(RFE)が発生したり、/SSオプションを指定し
た命令を実行した際に予約命令例外(RIE)が発生した
りすることになる。 また、MMU関連の命令におけるLSID関係の仕様は、次
のようになっている。 −LSIDのでは、LSIDのないときPSTLB/AS/AT@uraddr相
当の動作を行なう。また、LSID実装時は、その機能を生
かすため、LDCTXでTLB,キャッシュのパージは行わな
い。LSID実装時は、TLBやキャッシュのタグ部分にLSID
まで含まれているので、LDCTXによりLSIDが変更される
と、LDCTX実行前の論理空間でヒットしていたエントリ
がLDCTX実行後の新しい論理空間ではヒットしなくな
る。ヒットしなくても、新しいエントリのロードに伴っ
てリプレースされない限りパージはされないので、再び
LDCTXが実行されて以前の論理空間に戻った場合には、
そのエントリがそのまま有効になる。(LDCTXでキャッ
シュやTLBをパージしていたのでは、LSIDの意味がなく
なってしまう。) −LDATE/PTでは、LSIDのない時PSTLB/AS/PT相当の動作
を行なう。LSID実装時、prgaddrがSRであればPSTLB/AS/
PT相当の動作を行ない、prgaddrがURであればPSTLB/SS/
PT(LSID_of_TAG=R0)相当の動作を行なう。prgaddrが
SRかURかで動作が異なっているように見えるが、これは
LDATEの問題ではあく、PSTLBの動作がURとSRで異なって
いるためである。LDATE命令自体の動作は、ATEの変更に
伴って影響を受けるTLBやキャッシュをパージする、と
いうことで一貫している。 −LDATE/STでは、LSIDのない時PSTLB/AS/PT相当の動作
を行なう。LSID実装時、prgaddrがSRであればPSTLB/AS/
PT相当の動作を行ない、prgaddrがURであればPSTLB/SS/
ST(LSID_of_TAG=R0)相当の動作を行なう。(/PTと同
様) −LDC命令でUATB,SATBを変更した場合は、仮想定な命令
LDATE/ATを実行したと考えれば良く、LDATE/PT,LDATE/S
Tと同様の動作を行なう。すなわち、LSIDのない時、SAT
Bを変更した場合にはPSTLB/AS/AT(prgaddr=SR)相当
の動作を行ない、UATBを変更した場合にはPSTLB/AS/AT
(prgaddr=UR)相当の動作を行なう。LSID実装時、SAT
Vを変更した場合にはPSTLB/AS/AT(prgaddr=SR)相当
の動作を行ない、UATBを変更した場合にはPSTLB/SS/AT
(LSID_of_TAG=LSID,prgaddr=UR)相当の動作を行な
う。 付録4.本発明装置のフラグ変化 各命令のフラグ変化の表記法は、以下の通りとする。 − 変化なし + 本来のフラグの意味に合わせて変化する * 本来のフラグの意味とは異なった変化をする 0 0にクリアされる 1 1にセットされる A4−1.データ転送命令 第311図に示す。 A4−2.比較・テスト命令 第312図に示す。 A4−3.算術演算命令 第313図に示す。 ADDX,SUBXのX_flagは、destのサイズからの桁上げ、
桁下げを示す。SUBXでsrcとdestのサイズが等しい場
合、X_flagは符号なし演算としての大小関係といった意
味にもなる。 一方、L_flagの方は符号付き演算として大小関係を表
わす。 MUL,MULU,MULX,DIV,DIVU,DIVX,REM,REMU,NEGのM_fla
g,Z_flagは、オーバーフローの発生にかかわらずdest設
定値が基準である。 MULX,DIVXのM_flag,Z_flagは、reg設定値には関係し
ない。 DIVのV_flagは、0除算または(最小負数)÷(−
1)の時にセットされる。 DIVUのV_flagは0除算の時にセットされる。 DIVXのV_flagは、0除算または商がdestのサイズに入
らない時にセットされる。 NEGのV_flagは、destが最小負数であった時にセット
される。 INDEXのM_flag,Z_flagは、xreg設定値(結果の一部)
が基準である。L_flagは結果が負であること、V_flag
は、乗算または加算でのオーバーフローを示す。 A4−4.論理演算命令 第314図に示す。 NOTのM_flag,Z_flagは、dest設定値(反転結果)が基
準である。 A4−5.シフト命令 第315図に示す。 M_flag,Z_flagはdest設定値(シフト結果)が基準で
ある。 X_flagは最後にシフトアウトされた値が入る。 SHA,SHL,ROTでcountが0の場合には、X_flag=0とな
る。 SHAでは、count>0で符号の変化があった場合にのみ
V_flag=1。それ以外の場合はV_flag=0。 A4−6.ビット操作命令 第316図に示す。 A4−7.固定長ビットフィールド命令 第317図に示す。 固定長ビットフィールド命令では、BFCMP,BFCMPUがCM
P,CMPUに準じたフラグ変化をし、それ以外の命令がMOV,
MOVUに準じたフラグ変化をする。 BFINS,BFINSUの場合、第318図のBBBBBBBBがフラグ変
化の基準となる。 また、BFEXT,BFEXTUでは、抽出されたビットフィール
ドではなく、デスティネーションに設定される値を基準
としてフラグ変化する。これは、MOV命令などにおい
て、デスティネーション側に設定された値を基準として
フラグ変化するのに合わせたものである。 A4−8.任意長ビットフィールド命令 第319図に示す。 A4−9.10進演算命令 第320図に示す。 BCD数は符号拡張が無意味なので、基本的に符号なし
の数を扱うものと考え、ADDU,SUBUに準じたフラグ変化
とする。なお、ADDX,SUBXは、符号なし、符号付きの両
方の数を扱うため、多少変則的なフラグ変化になってお
り、ADDU,ADDDX,SUBU,SUBDXとは異なったフラグ変化で
ある。 本発明装置では10進演算はサポートしない。 A4−10.ストリング命令 第321図に示す。 SMOV,SCMP,SSCHのF_flagは、終了条件による終了(SS
CHの場合はサーチ成功)を示す。 V_flagは、エレメント数によって命令を終了した場合
を示す。 M_flagは、複数の終了条件を区別するために用いる。
R3に関係する条件で終了した場合には0、それ以外の0
またはR4の関係で終了した場合(《L2》のみ)には1と
なる。 SCMPのX_flag,L_flag,Z_flagは、最終エレメントの比較
結果を基準としてセットされる。 X_flagはエレメントを符号なしデータと考えた時の大
小、L_flagはエレメントを符号付きデータと考えた時の
大小を示す。 A4−11.キュー操作命令 第322図に示す。 QINSのZ_flagは、空のキューに挿入したことを示す。 QDELのZ_flagは、エントリの削除の結果キューが空に
なったことを示す。また、QDELのV_flagは、空のキュー
からエントリを削除しようとしたことを示す。 QSCHのF_flagは、終了条件による終了(サーチ成功)
を示す。 V_flagは、キュー終了値R2による終了(サーチ失敗)
を示す。 M_flagは、複数の終了条件を区別するために用いる。
R3に関係する条件で終了した場合には0、それ以外の0
またはR4の関係で終了した場合(《L2》のみ)には1と
なる。 A4−12.ジャンプ命令 第323図に示す。 ジャンプ関係の命令では、フラグは全く変化しない。 A4−13.マルチプロセッサ命令 第324図に示す。 A4−14.制御空間、物理空間操作命令 第325図に示す。 LDCでdestにPSWを指定した場合には、全フラグが変化
する。 A4−15.OS関連命令 第326図に示す。 本発明装置ではJRNG,RRNGはサポートしない。 A4−16.MMU関連命令 第327図に示す。 ACS命令のM_flagはread可、L_flagはexucute可、Z_fl
agはwrite可を示す。MOVPAのV_flagは、ページフォール
トまたはエラーにより物理アドレスが得られなかったこ
とを示す。F_flagは、ページフォールトを示す。 LDATE,STATEのV_flagは、ページフォールトまたはエ
ラーによりATEの転送ができなかったことを示す。 本発明装置ではACS命令以外のMMU関連命令をサポート
しない。 付録5.異種サイズ間の演算について 本発明装置では、異なるバイト数の整数の間で各種の
演算を行なうことができ、これを「異種サイズ間の演
算」と呼んでいる。「異なるサイズ」といっても、現在
は整数のみを対象としているため、データサイズの変換
はゼロ拡張または符号拡張のみの簡単な処理で済む。例
えば、32ビットの整数に8ビットの符号付き整数を加え
る場合、8ビット整数の符号ビット(MSB)を上位ビッ
トにまで拡張してから加算を行なうわけである。符号拡
張処理はゲート1〜2段で可能なので、一般の加算命令
と比べてそれほど複雑なわけではない。 A5−1.異種サイズ間の演算の有用性 異種サイズ間の演算は、次のような場合によく使用す
る。 オペランドの一方がイミディエート値の時 変数と定数の演算を行なう場合、定数のサイズはコンパ
イル時にわかるため、定数の方を小さいサイズとして扱
えば、命令長を減らすのに効果がある。例えば、32ビッ
トレジスタに8ビット定数の100を加える場合、32ビッ
トの加算命令を使うと定数100を指定するのにも32ビッ
トのフィールドが必要である。しかし、32ビットに8ビ
ットを加算する命令を使えば、定数100を指定するフィ
ールドが8ビットで済むため、命令が短くなる。 さらに、乗除算の場合には、命令長だけではなく性能
面でも影響がある。マイクロプロセッサでは32〜64ビッ
トの並列乗算器を持つのは苦しいので、どうしても加算
とシフトで乗算を行なうことになるが、乗算の計算量
は、2つのオペランドサイズの積に比例して多くなるた
め、2つのオペランドのうちの一方だけでもサイズの小
さい方が有利である。異種サイズ間演算の機能がない場
合には、例えば、32ビットの変数に3を掛けるだけでも
32ビット*32ビットの乗算を行なわなければならない。 アドレス計算 アドレスの計算では、演算のデスティネーションのサイ
ズをアドレス幅と同じにする必要がある。したがって、
32ビットプロセッサの場合、32ビットと他のサイズとの
演算をよく行なう。例えば、文字の変換テーブルなどに
おいて、テーブルのインデクスの範囲が8ビットにおさ
まる場合、インデクスとベースアドレスとの加算は、8
ビット符号なし整数と32ビット整数との加算として実現
される。 高級言語 一般に、高級言語では、サブルーチンパラメータのサイ
ズを必ずマシンの基本サイズ(例えば32ビット)に拡張
することが多い。これは、スタックを使ってサブルーチ
ンパラメータの受け渡しをするため、また分割コンパイ
ル等を容易にするためである。さらに、言語Cのよう
に、式の中の変数のデータサイズにかかわらず、式の評
価は必ずマシンの基本サイズで行なうという場合もあ
る。一方、メモリ上の変数、特に配列では、メモリ領域
の節約のため、必要最小限のサイズとするのが普通であ
る。したがって、配列とサブルーチンを同時に使用する
プログラムでは、データの移動中または演算処理の途中
のどこかでサイズの変換を行なわなければならない場合
が出てくる。式の評価とサイズの変換を同時に行なうた
めには、本発明装置のような異種サイズ間の演算が便利
である。 A5−2.本発明装置における実際 本発明装置では、異種サイズ間の演算をサポートする
ため、データサイズの指定に関する直交性が非常に強く
なっており、2オペランド一般形(G−format)の基本
演算命令のほとんどで異種サイズ間の演算が可能であ
る。つまり、2オペランド一般形の基本演算命令では、
ソースのサイズとディスティネーションのサイズが独立
に指定でき、必要に応じて符号拡張、ゼロ拡張、上位ビ
ットの切り捨て、などを行なうようになっている。デス
ティネーションのサイズがソースのサイズより小さい場
合にも演算は実行され、デスティネーションのサイズに
従ってオーバーフローが検出される。 以下に、各命令における異種サイズ間演算の実際例を
述べる。 B: Btye 8ビット H: Halfword 16ビット W: Word 32ビット MOV src.B,dest.W 8ビットのsrcを32ビットに符号拡張してdestに転送。 MOV src.W,dest.B srcの下位8ビットをdestに転送。 32ビット符号付き整数としてのsrcの値と、8ビット符
号付き整数としてのdestの値が異なる時は、オーバーフ
ローとなる。 ADD src.B,dest.W 8ビットのsrcを32ビットに符号拡張してdestに加算。 ADD src.W,dest.B destにセットされる値は、srcの下位8ビットをdest
に加算したものと同じである。しかし、命令の意味とし
ては、src(32ビット)とdest(8ビットを32ビットに
符号拡張)を加算し、それを8ビット符号付き整数に変
換してdestに格納するということである。したがって、
32ビットの和がdestの8ビットで表現できない値になっ
た時は、オーバーフローとなる。 本発明装置では、ソースとデスティネーションのデー
タサイズが異なる場合に、通常符号拡張を行なう。ただ
し、特にゼロ拡張も必要と考えられる命令(MOV,CMP,AD
D,SUB)については、ゼロ拡張と符号拡張を命令レベル
で切り分け、MOVU,CMPU,ADDU,SUBU命令としている。MOV
U,CMPU,ADDU,SUBU(加えてMULU,DIVU)では、デスティ
ネーションのサイズがソースのサイズよりも大きい時に
ゼロ拡張を行ない、結果を符号なし整数と考えてオーバ
ーフローの検出をする。 A5−3.異種サイズ間の論理演算 論理演算の場合は各ビットが全く独立なので、異種サ
イズ間の演算は意味がないし(フラグの変化を除けば、
小さい方のサイズで行なうのと同等)、論理演算のオペ
ランドに対するゼロ拡張や符号拡張もほとんど意味を持
たない。 しかし、例えばCで次のような関数を書いた場合に
は、意味はなくても 符号拡張→論理演算 というオペレーションを実行しなければならないことが
ある。 ただ、このような例は、言語としての規則性や対称性の
ためにそう決まっているだけであり、一部のトリッキー
なプログラムを除けばほとんど使わない機能であると言
える。 論理演算の異種サイズ間演算をサポートするかどうか
について、問題点をまとめると以下のようになる。 実行時 異種サイズ間の論理演算は、頻度としては非常に少な
く、論理的な意味も持たない。本質的に他の命令で代用
できるか、あるいはトリッキーなプログラムでしか使わ
ない。 コンパイル時 C言語では、論理演算でもゼロ拡張や符号拡張が必要
になることがある。あまり使わない機能であっても、コ
ンパイラとしては必ず正しいコードで出す必要がある。
命令の対称性が重要。 チップのインプリメント 符号拡張/ゼロ拡張の区別が全命令で統一的に行なわ
れていれば、インプリメントの規則性の面から、論理演
算でもゼロ拡張や符号拡張を導入するメリットがある。
しかし、そのためには命令の割り当てに多くのビットパ
ターンが必要となり、命令のエンコーディングが苦しく
なってしまう。現実的には、論理演算を含む全命令で符
号拡張/ゼロ拡張の区別を行なうことはできず、論理演
算の符号拡張やゼロ拡張に対してインプリメントの規則
性の面からのメリットは得られない。また、この部分は
メーカー間で見解の異なる可能性もあるため、仕様を合
わせるのが難しい。 結局、以上の中でとのどちらを重視するかという
ことになるが、実質的な性能向上をねらうのであれば、
やはりを選択するのが適当と考えている。つまり、 ・異種サイズ間の論理演算のように、実行する意味の少
ない演算が足を引っ張ることによって、性能向上がはば
まれるのはよくない。 ・の問題に関しては、符号拡張を含む異種サイズ間の
論理演算は頻度の少ない演算であるから、多少実行速度
が落ちてもよい。 例えば、 とすれば、多少実行速度は落ちるが、符号拡張〜演算命
令の統一的な置き換えが可能である。こうすれば、コン
パイラの負担はそれほど増えない。 したがって、本発明装置の仕様としては、異種サイズ
間の論理演算をサポートしていない。異種サイズ間の論
理演算に相当する命令ビットパターンを実行した場合に
は、動作を保証しないということになっている。 A5−4異種サイズ間演算機能のまとめ 本発明装置でサポートする命令と、整数のデータタイ
プとの関係をまとめると、次のようになる。 ・8,16,32,64ビット長の整数をサポートする。 ・符号付きの整数を優先してサポートする。 ・符号付き整数の算術演算に関しては、2オペランド命
令において異種サイズ間の演算がサポートされている。
ソースのサイズとディスティネーションのサイズは完全
に独立に指定でき、サイズの制限はない。ソースの方が
サイズが小さい場合は、符号拡張される。結果は符号付
き整数として扱われ、それに従ってフラグ類がセットさ
れる。 ・符号なし整数の演算は、一部の命令(MOV,CMP,ADD,SU
B,MUL,DIV)でのみサポートされている。サイズに関し
てはやはりソースのサイズとディスティネーションのサ
イズが完全に独立に指定できる。ソースの方がサイズが
小さい場合は、ゼロ拡張される。結果は符号なし整数と
して扱われ、それに従ってフラグ類がセットされる。 ・符号付きの整数と符号なしの整数の混在した演算はで
きない。ただし、加算命令などの場合は、デスティネー
ションの符号の有無はフラグに影響するだけなので、フ
ラグを見ないのであればADDまたはADDUで代用できる。 ・異種サイズ間の論理演算はサポートしない。 付録6.高級言語向きサブルーチンコール 高級言語におけるサブルーチンコールでは、単なるリ
ターンアドレスの退避だけではなく、フレームポインタ
の設定、ローカル変数の領域の確保、汎用レジスタの退
避といった処理も必要である。これらの処理はJSR,STM
などの命令に分解することも可能であるが、頻度が多い
こと、処理が定型的であることにより、一つの命令(EN
TER,EXITD)としてまとめられている。 A6−1.本発明装置でのサブルーチンコール 高級言語(特にC,PASCAL)のサブルーチンコールで
は、普通第328図のような処理を行なう。 本発明装置では、高級言語用サブルーチン命令ENTER
とリターン命令EXITDを設けている。いくつか注意する
点を述べる。 ・FP(フレームポインタ)とディスプレイレジスタ PASCALのようにスタティックスコープがある言語で
は、中間レベル(ローカル変数とグローバル変数の中間
のレベル)の変数のアクセスにディスプレイレジスタを
用いる。本発明装置のようにレジスタの多いプロセッサ
では、汎用レジスタ上にこのディスプレイレジスタを置
くのが有効である。これは、複数のFPを持つことに相当
する。 (実現方法は後述) ・パラメータ パラメータを渡すには、パケットにしてその先頭アド
レスをレジスタ等で渡す方法、パラメータをスタックに
積む方法、等があり、高級言語では後者の方が一般的で
ある。呼ばれたサブルーチンの側でスタック上のパラメ
ータをアクセスするにはFP相対のモードを使うことが多
い。 サブルーチン実行後には、呼んだ側でスタック上のパ
ラメータを解放する必要がある。言語によって、また分
割コンパイルをしなければ、呼ばれた側で正確なパラメ
ータ数がわかっているので、リターン命令の中で解放す
るパラメータ数(SPへの加算値)を指定することができ
る。本発明装置では、この目的でEXITD命令を設けてい
る。パラメータ数が動的に決まる場合もあるので(例え
ば、パラメータ数をサブルーチンに知らせるために、特
定のレジスタやスタックを使う場合など)、EXITD命令
におけるSPへの加算値としては、イミディエート値だけ
ではなくレジスタ上の値を使用することもできる。 しかし、言語Cのようにサブルーチンのパラメータの
個数が確定しない言語では、サブルーチンを呼ばれた側
からは、サブルーチンを呼ぶ側で決めたパラメータの個
数がわからない。したがって、呼ばれた側で実行するEX
ITD命令では、解放するパラメータの個数を指定できな
い。その場合には、サブルーチンを呼んだ側でADD #
n,SPを行なってパラメータを解放する。 結局、本発明装置のENTER命令では前の図の2.〜4.の
処理、EXITD命令では5.〜7.の処理、または5〜8の処
理(ただし、8.で解放するパラメータ数はサブルーチン
側で指定)を行なうことになる。1.はJSRと同じ処理に
なり、8.はサブルーチンを呼んだ側でADD***,SPを行
なう。 本発明装置における高級言語でのスタックフレーム
は、第329図のようになる。 ・local variablesとparametersがなるべくFPから近い
配慮となるように、ローカル変数確保よりレジスタセー
ブを後にした。 ・EXITD命令にはPCのリストア(RTS)の操作まで含めて
いる。 命令シーケンスの実際 (サブルーチン側でパラメータ数がわからない場合) 第330図に示す。 (サブルーチン側でパラメータ数がわかる場合) 第331図に示す。 A6−2.ブロック構造言語のためのディスプレイレジスタ
の構成例 ENTER−EXITDで処理するFPレジスタをダイナミックリ
ンクとして利用するためには、内側のブロック(最高の
レキシカルレベル)に対するフレームポインタにFPレジ
スタを割り当てるのがよい。 その他のレキシカルレベルのフレームポインタには、
値の変化の少ない順にR13,R12,R11・・・を使う。つま
り、レキシカルレベルの高い内側のブロックへ行くにし
たがって番号の小さいレジスタを使い、最小番号のレジ
スタの内容をFPと同じにする。 各サブルーチンでは、ENTER命令実行後、FPを自分の
レキシカルレベルに対応したフレームポインタ用レジス
タにコピーし、その番号以上のレジスタをディスプレイ
レジスタとして、その番号以下のレジスタを評価用とし
て利用すればよい。ただし、新しく書き換えたレジスタ
は必ず退避して値を保存しなければならない。 プログラム例(スタティックスコープ) 第332図に示す。 実行状態の例(ダイナミックリンクとディスプレイレジ
スタ) 第333図に示す。 ・proc0*,var0* proc0であるが、再帰呼び出しのため、最初のproc0とは
異なったフレームになっている。 ・FPのコピーにより破壊するレジスタは、コピー前にす
べてENTER命令で退避しなければならない。レジスタを
退避しておけば、サブルーチンの実行が終って一つ前の
関数に戻った時、レキシカルレベルの大小にかかわらず
ディスプレイはもとの値に戻る。 上の例では、レジスタの使い方について次のような関
係が成立する。 レキシカルレベルnのサブルーチン実行に関して R13・・R13−n+1のn個のレジスタはディスプレイ
レジスタとして参照のみを行ない、書き込みはしない。 R13−nのレジスタは、このレベルのローカル変数の
ディスプレイとして使用するため、ENTER実行後FPから
コピーする。このディスプレイは、このサブルーチン実
行中にさらに高いレベルのサブルーチンを呼んだ時に、
呼ばれたサブルーチンからこのレベルの変数をアクセス
するために使用する。このサブルーチンからこのレベル
の変数をアクセスするには、同じ内容であるFPを使うの
が良い。 R13−n−1・・R0の(13−n)個のレジスタは、レ
ジスタ変数や評価用として利用する。 R13−nのレジスタとR13−n−1・・R0のうちで使用
するレジスタは、必ずENTER命令で退避する必要があ
る。全部のレジスタが保存されなければならない。 付録7.制御レジスタと制御空間 制御レジスタ関係の仕様は、チップバス(コプロセッ
サやキャッシュ、TLBなどに接続されるバス)やインプ
リメント方法との関係が深いため、《LA》仕様となって
いる。 A7−1.制御空間の考え方 「本発明装置」では、チップバス上のメインプロセッ
サやコプロセッサに含まれるすべてのレジスタ、MMUや
キャッシュ、TLBなどの制御レジスタ、およびチップバ
ス上に接続されたコンテキストスイッチ用高速メモリに
一意的なアドレスを付け、これを制御空間と呼ぶ。「本
発明装置」の制御空間は、従来のプロセッサに見られた
コプロセッサ用のアドレス空間(Coprocessor−IDな
ど)をメインプロセッサの制御レジスタのアドレスと統
合化、一般化したものであり、次のような特徴を持つ。 ・「本発明装置」の制御空間には次のようなものが含ま
れる。 メインプロセッサの制御レジスタ PSW,各リングのスタックポインタなど MMU関係の制御レジスタ(「本発明装置」はMMUを内蔵し
ない) UATB,SATBなど インプリメントに依存して必要となるレジスタ [コプロセッサの制御レジスタ] [コンテキスト退避用の高速メモリ] 将来チップに内蔵することを狙ったもの [プロセッサ内の汎用レジスタ、テンポラリレジスタ] 外部からの診断、デバッグの目的 ・制御空間は、コンテキスト(プロセスやタスク)間で
共通の空間である。制御空間のアクセスはアドレス変換
を伴わないため、単純化されたプロトコルで高速のアク
セスが可能である。この機能は、特に高速コンテキスト
スイッチでも利用される。 制御空間の考え方は、将来、コプロセッサやコンテキ
スト退避用メモリがメインプロセッサに内蔵された時
に、特に有効になると考えられる。しかし、最初のバー
ジョンのチップでは、インプリメントの制約上、あるい
はチップバスの構成上、制御空間の操作を統一的に行な
うのが難しい場合があるので、将来に備えてアドレスの
割り当てのみを決めておき、制御空間操作命令はいくつ
かの制限を付けて使用してもよいということにする。 具体的には、次のような制限が付く。 ・プロセッサの診断用の目的で、R0〜R15やPCにも制御
空間のアドレスが割り当てられているが、これは《L2》
であり、「本発明装置」では実装しない。 ・LDC,STCは、本来メインプロセッサ内の制御レジス
タ、FPUの制御レジスタ、 コンテキスト退避用メモリなどを統一的にアクセスする
ことを狙ったものである。しかし、「本発明装置」では
インプリメントの制限により、メインプロセッサ内の制
御レジスタ以外(実行アドレスH'0〜H'07ff以外)のも
のについては、LDC,STCでアクセスできない。 ・「本発明装置」の制御空間のアドレスでは、バイトア
クセス、ハーフワードアクセスが利用できない。また、
ワードアクセスにおいてアライメントが強制される。 ・コンテキスト退避用メモリは、制御レジスタを置く領
域(H'0〜)と重ねることはできない。コンテキスト退
避用メモリとしては、H'ffff8000〜H'ffff ffffのアド
レスが割り当てられている(さらに拡張領域としてH'80
000000〜)ので、H'80000000〜H'ffffffff以外の値をCT
XBBに設定してLDCTX/CS,STCTX/CSを実行した場合には、
エラーとする。また、LDCTX/CS,STCTX/CSの機能自体も
《L2》となっている。 ・「本発明装置」ではLDCTX/CS,STCTX/CSをサポートし
ない。 第334図に示す制御空間では、バイトアクセス、ハー
フワードアクセスができないのにもかかわらず、バイト
アドレッシングとなっている。これは、一般の命令で利
用される論理空間と同じように、制御空間でも汎用アド
レッシングによる実行アドレス指定が可能であり、論理
空間と同じ形のバイトアドレッシングにしておかない
と、混乱を招くからである。また、制御空間で汎用アド
レッシングを利用可能としたのは、制御空間をコンテキ
スト退避に利用することを考えたためである。 LDC,STCでメインプロセッサ内の制御レジスタしかア
クセスできない場合には、バイトアドレッシングとした
意味がなくなってしまい、多少不自然な仕様になる。し
かし、その背景には上記のような将来的な見通しがあ
り、一部の機能のみを実現した場合に多少不自然に見え
るのはやむを得ない。 A7−2.メインプロセッサの制御レジスタ 制御レジスタのニモニックとアドレスについては、次
のようになる。制御レジスタのアドレスが8n+4の位置
にあるのは、レジスタを64ビットに拡張することを考慮
したためである。 *はコンテキスト毎に別々に用意されるレジスタ /は必ずしも実装(アドレス割り当て)をしなくても良
いレジスタ A7−3.制御レジスタの未使用ビット 制御レジスタのうち、使用していないビットについて
は、1を書き込んだ場合にそれをチェックしてEITとす
るのが望ましい。しかし、中途半端なチェックを行なう
と、互換性(特に下位チップとの互換性)を保つのが難
しくなること、チェックのためにオーバーヘッドが生じ
ること、により、PSWを除いて未使用ビットのチェック
は行なわないことにする。 CTXBFMなど《L2》の機能を持つレジスタについても、
《L2》が実装されていない場合にはエラーチェックが行
なわれないし、書き込んだ値がそのまま読み出されると
は限らない。 ただし、チェックが行なわれていなくても、空きビッ
トには必ず'0'を入れてもらうように、マニュアル等で
指導する必要がある。 PSWについては、未使用のビット’−’に'1'を書き込
もうとした場合に、予約機能例外(RFE)とする。 以下の制御レジスタの内容の説明における’− このビットに0(1)を書き込むことは可能である
が、このビットに1(0)を書き込もうとするとLDC,LD
CTXなどで予約機能例外(RFE)を発生する。 ’=’ 0にreserved(違反時も無視) ’#’ 1にreserved(違反時も無視) このビットは0(1)を書き込むべきビットである
が、このビットに1(0)を書き込もうとしても単に無
視され、このビットに0(1)を書き込んでも1(0)
を書き込んでも動作は同じである。 ユーザへのマニュアルには、将来の拡張のためこのビ
ットに0(1)を書き込むように明記する。 ’*’ 書き込み時の値は自由。 ハードウエアの動作は’=''#’と同じであり、どの
ような値が書き込まれても単に無視する。ただし、この
ビットは’=','#,とは異なり、将来チップの機能が
拡張された場合にも使用しないビットである。したがっ
て、ユーザが自由な値を書き込んでも構わない。ユーザ
へのマニュアルの中でも、このビットは無視されるとい
うことを明記し、ビットのマスク処理などは省いてもら
うようにする。 ・IMASK,SMRNG,DI,DCE,CTXBFEでは、未使用のビット
が’*’になっている。PS Wでは、未使用のビットが’
−’になっている。それ以外の制御レジスタでは、未使
用のビットは’=’である。 ・PSB,PSMの未使用フィールドも’−’である。 したがって、LDPSB,LDPSMでも予約機能例外(RFE)が発
生する。 ・’−’のビットの読みだした場合には、'0'が読み出
される。’=','*’のビットを読みだした場合に得ら
れる値は不定である。前に書き込んだ値がそのまま読み
出されるとも限らない。 A7−4.制御レジスタの内容 PSW 第335図に示す Processor Status Word 内容については本文を参照。 PSM,PSB PSWのうち、ユーザのアクセス可能な下位の2バイト
のみを抜き出したもの。LDPSB,LDPSM,STPSB,STPSM命令
によってアクセスする。制御レジスタのうち、PSB,PSM
のみがring0以外からアクセスできる。 IMASK 第336図に示す PSWのうち、個別にアクセスすることの多いIMASKのフィ
ールドを抜き出して別レジスタとしたものである。IMAS
Kの操作を容易にすることと、性能向上を狙ったもので
ある。IMASK以外のフィールドには、何を書き込んでも
単に無視される。 SMRNG 第337図に示す PSWのうち、個別にアクセスすることの多いSMRNGのフ
ィールドを抜き出して別レジスタとしたものである。S
M,RNGの操作を容易にすることと、性能向上を狙ったも
のである。SMRNG以外のフィールドには、何を書き込ん
でも単に無視される。 CTXBB 第338図に示す Context Block Base CTXBのベースアドレスを指すレジスタ。LDCTX,STCTX
命令で使用される。 CTXBBは「本発明装置」64への拡張を考え、「本発明
装置」32でも8バイトのアライメントを強制している。
したがって、CTXBBの下位3ビットは’===’とな
る。つまり、0にreservedであるが、違反時にも無視さ
れる。 DI(Delayed Interrupt) 第339図に示す DI(Delayed Interrupt)要求を示すレジスタ。 DI(Delayed Interrupt)は、ソフトウエアによって外
部割り込みを発生させるメカニズムであり、非同期に発
生する各種の処理要求をペンディングとしたい時や処理
順序をシリアライズしたい時に有効である。優先度の高
い外部割り込みの処理が終わった後で別に起動したい処
理がある場合、その要求をDIに登録しておくことによっ
て自動的に処理が起動される。 DIは、外部割り込みに対してDCEと同等の処理を行な
うものである。REIT命令などによってPSWのIMASKが変化
した場合に、DI<IMASKであればDIのEIT処理が起動され
る。このレジスタのDI以外のフィールドに何を書き込ん
でも単に無視される。 CSW 第340図に示す Context Status Word このレジスタは、コンテキスト毎に切り換えの必要な
情報のうち、ネストの行なわれないものを集めたもので
ある。DCE(Delayed Context Exception)要求を示すDC
Eフィールドと、CTXBのフォーマットを示すCTXBFMのフ
ィールドから成る。CTXBFMの機能は付録8を参照のこ
と。 CTXBFMの機能がインプリメントされない場合には、DC
EレジスタとCSWレジスタが全く同じ情報を扱うことにな
るので、CSWレジスタもインプリメントされない(アク
セス時RFE)場合がある。この時、CTXBに置かれるの
は、形式的にはCSWレジスタであるが、実際はDCEレジス
タとなる。 CSWとDCE,CTXBFMの関係は、PSWとIMASK,SMRNGの関係
に同じである。CTXBに置かれるのは、DCE,CTXBFMなどの
情報を圧縮したCSWの方である。 「本発明装置」ではDCE='111'に固定とする。 DCE 第341図に示す Delayed Context Exception CSWのうち、個別にアクセスすることの多いDCEのフィ
ールドを抜き出して別レジスタとしたものである。DCE
の操作を容易にすることと、性能向上を狙ったものであ
る。DCE以外のフィールドには、何を書き込んでも単に
無視される。 CSWレジスタがインプリメントされない場合、コンテ
キストスイッチ時にCSWレジスタの代わりにCTXBとの転
送が行なわれるのは、このDCEレジスタである。この場
合、コンテキスト退避の時は、’*’のビットがすべて
0となってCTXBに書き込まれる。また、コンテキストを
ロードする時は、’*’の部分のビットの値はチェック
されない。 CTXBFM 第342図に示す Context Block Format CSWのうち、個別にアクセスすることの多いCTXBFMの
フィールドを抜き出して別レジスタとしたものである。
CTXBFMの操作を容易にすることと、性能向上を狙ったも
のである。CTXBFM以外のフィールドには、何を書き込ん
でも単に無視される。 このレジスタは《L2》である。 EITVB 第343図に示す EIT Vector Base EIT(例外、割り込み)ベクトルテーブルの先頭の物
理アドレスを示す。EITVBは「本発明装置」64への拡張
を考え、「本発明装置」32でも8バイトのアライメント
を強制している。したがって、EITVBの下位3ビット
は’===’となる。つまり、0にreservedであるが、
違反時にも無視される。 JRNGVB 第344図に示す JRNG Vector Base JRNG命令のベクトルテーブルの先頭の論理アドレスを
示す。 JRNGVBによるテーブルのベースアドレスは、「本発明装
置」64への拡張を考え、「本発明装置」32でも8バイト
のアライメントを強制している。また、JRNGVBのLSBはE
nableビットとなっており、Eが0の時にはJRNG実行禁
止となる。したがって、JRNGVBの下位3ビットは’==
E'で表記されている。’=’のビットは、0にreserved
であるが、違反時にも無視される。 SP0〜SP3 第345図に示す Stack Pointer for ring3 ring0〜ring3で使用するスタックポインタ。 SPI,SP0〜SP3についてはアライメントの制約はなく、
LSBまで有効である。 SPI 第346図に示す Stack Pointer for Interrupt 外部割り込み用のスタックポインタ。 IOADDR,IOMASK 第347図に示す アドレス変換を行なわない場合(PSWのAT=00,10)にお
いて、I/O領域の物理アドレスを指定するレジスタであ
る。 通常MMUでアドレス変換を行なう場合には、PTE中のNC
ビットによってI/O領域の指定を行なうが、システムス
タート時などでアドレス変換ができない場合には、IOAD
DR,IOMASKの2つのレジスタを使ってI/O領域の指定を行
なう。 アドレス変換なしでメモリアクセスをする場合、物理
アドレスとIOMASKの論理積がIOADDRと等しければ、そこ
はI/O領域と見なされる。その領域のデータについて
は、データのキャッシュへの取り込みやプリフェッチが
行なわれず、命令の要求するメモリアクセスと実際の物
理的なメモリアクセスが1対1に対応する。 アドレス変換のある場合には、IOADDR,IOMASKレジスタ
は使用しない。また、プロセッサのインプリメントによ
ってキャッシュやプリフェッチを行なわない場合には、
必ずしもIOADDR,IOMASKレジスタを使用する必要はな
い。 UATB 第348図に示す Unshared region Address Translation Base 内容については付録3を参照。 SATB 第349図に示す Shared region Address Translation Base 内容については付録3を参照。 LSID (「本発明装置」では実装しない) 第350図に示す Logical Space ID 複数の論理空間の間の区別を行なう番号を入れる。 複数の論理空間に属するTLBや論理キャッシュなどを
混在させる時に、この番号を利用する。LSIDの有効なビ
ット数については、インプリメント依存である。 付録8.「本発明装置」のCTXB A8−1.CTXBについて 「本発明装置」はMMUをもたないため「本発明装置」
でサポートするCTXBフォーマットをどのようにするか現
在検討中である。 OSが、タスク、プロセスなどといった並行処理やコル
ーチンの機能をサポートしている場合、PSや汎用レジス
タなどのハードウエア資源の情報は、並行処理の単位と
なるそれぞれのプログラム毎に別々に持つのが普通であ
る。これらのハードウエア資源は、プロセッサと同様に
時分割で使用されるため、現在実行中でないプログラム
に対するハードウエア資源の情報は、メモリなどに退避
しておく必要がある。 「本発明装置」では、こういった並行処理の単位となる
プログラムの流れをコンテキストと呼ぶ。また、それぞ
れのコンテキストを実行するために、ハードウエア資源
の情報をメモリ上にまとめて退避したものをContext Bl
ock(CTXB)と呼ぶ。 CTXB自体のおかれる空間は、LDCTX,STCTX命令のオプ
ションとして、論理空間LS、制御空間CSより選択でき
る。OSの書きやすさという点ではLSを利用するのが適し
ているが、コンテキストスイッチを特に高速化したい場
合や、コンテキストスイッチ退避用のメモリをチップ内
に設ける場合には、CSを利用することもできる。ただ
し、CSの指定は、将来コンテキスト退避用のメモリをチ
ップに内蔵した場合に有効に活用されるものであり、現
在は《L2》となっている。また、「本発明装置」では、
現在実行中のコンテキストのCTXBの先頭アドレスを保持
するレジスタが設けられており、これをCTXB Base Regi
ster(CTXBB)と呼んでいる。 「本発明装置」のCTXBのフォーマットは、次のように
なっている。このうちの一部は、LDCTX,STCTX命令によ
り、ハードウエアでサポートされている。 「本発明装置」32での標準CTXBフォーマット 第351図に示す 一般に、コンテキストスイッチによって切り換える必
要があるのは、OSのPCやPSWではなく、ユーザプログラ
ムのPCやPSWである。ところが、ユーザプログラムのPC
やPSWは、普通はOS呼び出し時にスタック中に退避され
ている。上記のCTXBフォーマットにおいて、PC,PSWがス
タック中に置かれているのは、そのためである。 SPIを使用した外部割り込みの処理ハンドラの最後で
直接コンテキストスイッチを行なう場合は、上記のCTXB
フォーマットを実現するために、PC,PSWを別命令で転送
する必要がある。しかし、この場合はDCE,DIを活用し、
外部割り込みから抜ける時にDCE,DIを使ってコンテキス
トスイッチを行なうという方法がある。そうすれば、DC
EやDIでSP0を指定することにより、上記のデータ構造が
自然に実現できる。 A8−2.CTXBの可変性 CTXBに含まれる情報のうち、’*1'〜’*5'の付いた
部分は、システム構成などによって可変性のある部分で
ある。これらの点について説明する。 CTXBの内容やフォーマットは、以下のような要因によ
って動的に(あるいはコンテキスト毎に)変化すること
がある。 ・OSの構成やMMUの有無(*1〜*3) OSの構成によっては、コンテキストスイッチでSP1〜SP3
の切り換えを行なっても意味のないケースが考えられる
ため、SP1〜SP3を退避したくない場合がある。また、MM
Uを使用しない用途でのコンテキストスイッチでは、UAT
B,LSIDを切り換える必要がない。 (*1)JRNG〜RRNGでは、外側のリングの内側のリング
のスタックに退避されるため、現在リングよりも外側の
リングのSPの値は意味を持たない。特に、ring0でのみ
実行されるコンテキストスイッチの時点では、SP1〜SP3
の値が意味を持たない。SP1〜SP3は、直接あるいは間接
にSP0のスタックに保持されているため、SP0の切り換え
によってSP1〜SP3も間接的に切り換わることになるから
である。一方、TRAPA〜REITの中でコンテキストスイッ
チが起こった場合にはSP1〜SP3の切り換えも必要であ
る。したがって、SP1〜SP3をCTXBに含めたい場合と、そ
うでない場合がある。 (*2)MMUを実装しない。《L1R》仕様では、UATBは不
要である。 (*3)LSIDは、複数の論理空間を区別するための番号
である。LSIDの実装は《L2》なので、LSIDがCTXBに含ま
れる場合と、そうでない場合がある。 ・退避する汎用レジスタの指定(*4) コンテキストで使用しないレジスタやOSで使用するワ
ーキングレジスタについて、CTXBとの退避、復帰を行な
わなければ、無駄な転送がなくなり、コンテキストスイ
ッチ時間が短縮される。 ・コプロセッサ使用の有無(*5) FPUのレジスタは汎用レジスタとは別になるが、これ
もコンテキスト情報として持つ必要がある。したがっ
て、そのコンテキストがFPUを使用しているかどうかに
よって、CTXBが動的に変わるケースが生じる。 以上のようなCTXBのバリエーションに対処するため、
「本発明装置」では、以下のような方法をとっている。 ・最初のバージョンの《L1》のチップでは、LDCTX,STCT
XでCSW,SP0〜SP3,UATBの転送のみを行なう。R0〜R14に
ついては、別命令LDM,STMを利用して転送し、(*4)
に対処する。 ・それ以外のCTXBのバリエーションに対しては、現在の
CTXBのフォーマットを識別するレジスタ(CTXBFM)を導
入し、このレジスタによって、CTXBに何が含まれ、LDCT
X,STCTXで何を転送しなければならないかを知ることに
する。なお、CTXBFMとDCEの情報を合わせたものは、CSW
レジスタとしても扱われる。 [CTXBFM] 第352図に示す FR FPUレジスタを退避することを指定 「本発明装置」標準のFPUレジスタのコンテキスト退
避を指定する。この機能は、特に、将来FPUがチップに
内蔵された場合にに利用する。 RG R0−R14を退避することを指定 この機能は、特に、将来コンテキスト退避用メモリが
チップに内蔵された場合に利用する。 SP SPの退避を指定 SP=00 SP0,SP1,SP2SP3を退避する SP=01 reserved SP=10 SP0,SP3を退避する(《L1R》用) SP=11 SP0のみ退避する この機能は、JRNGによりOSを呼び出す場合に、SP1〜S
P3の無駄な転送を行なわないために利用する。 また、《L1R》でSP1 SP2を実装しない場合に利用す
る。 MM MMU関連レジスタの退避を指定 MM=00 UATBを退避 MM=01 UATB,LSIDを退避 MM=10 MMU関連レジスタは退避しない (《L1R》用) MM=11 reserved [ただし、CTXBFMの詳細は検討中である。] 《L1》で標準的なフォーマットのCTXBでは、LDCTX,STCT
Xにより、CSW(DCE,CTXBFM)、SP0〜SP3,UATBが転送さ
れる。これは、CTXBFMをすべて0にすることによって指
定される。 LDCTX命令では、CTXBからフェッチした新しいコンテ
キストのCSWの中のCTXBFMを見て、CTXBの以下の部分の
フォーマットを判断し、指定されたものをロードする。 また、STCTX命令では、現在のCTXBFMの値を見て、指
定されたものをCTXBに退避する。ただし、CTXBFMの機能
は《L2》となっており、将来の拡張である。つまり、CT
XB固定の仕様が《L1》,CTXB可変の仕様(上位コンパ
チ)が《L2》である。 《L1R》のチップについては、SP1,SP2,UATBの転送が不
要なので、CTXBにもこれらの値は含めない。CTXBにこれ
らのレジスタ値が含まれているかどうかの識別は、CTXB
FMによって行なうことが可能である。ただし、CTXBFMの
実装が重い場合には、LDCTX,STCTX命令の追加オプショ
ンにより直接CTXBのフォーマットを指定する仕様や、LD
CTX,STCTX命令の追加オプションによりCTXBFMの有効性
の有無を指定する仕様にすることも考えられる。 A8−3.ソフトウエアコンテキスト プロセスやタスク毎に持つ情報の中には、OSがソフト
ウエアによって管理する情報も含まれている。これらの
情報はOSによって一定していないので、当然ハードウエ
ア(LTCTX,STCTX命令)ではサポートできない。これら
の情報をソフトウエアコンテキストと呼ぶ。例えば、IT
RONの場合、タスク状態、終了時処理ルーチンのアドレ
ス、例外処理ハンドラのアドレス、wakeupのカウント、
キューの構成のためのリンク用領域などがソフトウエア
コンテキストに含まれる。 CTXBを論理空間(LS)に置いた場合には、汎用レジス
タなどのハードウエアコンテキストとソフトウエアコン
テキストを同じように扱うことができる。しかし、ハー
ドウエアコンテキストとして、CSなどの別空間を使用し
た場合には、ソフトウエアコンテキストもCSに置くか
(この場合は、LDC,STCなどの命令が有効である)、あ
るいは両者をポインタでつないでおいて間接参照する
か、といった方法をとる必要がある。 付録9.「本発明装置」のEIT処理 EIT処理の概要は以下のとおりであるが、細部の仕様
は検討中である。 通常のプログラム実行の流れをハードウエア機構によ
って中断し、それに割り込むような形で非同期に起動さ
れる処理を、「本発明装置」ではEIT処理と呼ぶ。 EIT処理には、次のようなものが含まれる。 ・内部割り込み(トラップ−trap) ・例外割り込み(例外−exception) ・外部割り込み(割り込み−interrupt) トラップ、例外、割り込みの区別は、プログラマから見
たそのEITの発生原因によって行なわれるものであり、
インプリメント上のメカニズムの違い(スタックに待避
される情報の違いなど)を意味するものではない。 プロセッサが命令実行中にEITを検出すると、シーケ
ンシャルな命令の実行を中断してEIT処理を開始する。E
IT処理では、EITを検出した時のプロセッサの状態をス
タックに待避し、EITハンドラを起動する。ここまでが
プロセッサのハードウエアによって行なわれる。一方、
起動されたEIT処理ハンドラでは、EITに応じてエラーの
回復、エラーメッセージの表示、エミュレーションなど
の処理を行なう。EIT処理ハンドラは、ソフトウエアに
より実現されるものである。大部分のEITでは、EIT処理
ハンドラの最後でREIT命令を発行することにより、中断
されたもとの命令列に復帰し、処理を再開することが可
能となっている。 「本発明装置」では、将来の機能拡張を考慮し、未定
義の命令、不当な命令についてのエラー検出やエミュレ
ーション用のメカニズムを強化する方針である。したが
って、命令フォーマットの組み合わせにより不当なオペ
レーションになる場合や、インプリメントされていない
機能を実行しようとした場合には、できるだけエラーと
して検出し、例外割り込みを発生する。 A9−1.EITの種類 「本発明装置」で発生するEITには、次のようなものが
ある。 [メモリ、アドレス関係] 命令またはオペランドアクセス時のアドレス変換におい
て、UATB,SATB,STE,PTEのPIビットが0であった場合に
発生する。意味的には、ページ不在、ページテーブル不
在、セクションテーブル不在を含めたものである。いわ
ゆるページフォールトの例外である。 アドレス変換例外(ATRE) Address Translation Exception(ATRE) アドレス変換中のエラーによって発生する。具体的に
は、STE,PTEでreservedのビットパターンを使用してい
た場合、UATB,SATB,STE,PTEによって未使用領域となっ
ている部分を参照した場合、リング保護に違反したメモ
リアクセスを行なった場合などに発生する。EIT発生の
原因や詳細な情報は、ATRE発生時にスタックに積まれる
情報によって区別される。 バスアクセス例外(BAE) Bus Access Exception(BAE) 命令またはオペランドアクセスにおいて、一定時間以
内にバスからの応答がなく、メモリアクセスができなか
った場合に発生する。いわゆるバスエラーである。 奇数アドレスジャンプ例外(OAJE) Odd Address Jump Exception(OAJE) 分岐命令で、分岐先のアドレスが奇数であった場合に発
生する。 この例外は、ジャンプ先をオペランドとして直接指定
する命令(JMP,ACB等)、スタックからリターンアドレ
スを得る命令(RTS,EXITD,RRNG,REIT)、およびJRNG命
令で発生し、EIT処理の起動時には発生しない。EIT処理
起動時に新PCが奇数であった場合には、システムエラー
例外(SEE)となる。[JRNG,EITは詳細仕様調整中] [命令、演算関係] 特権命令違反例外(PIVE) Privileged Instruction Violation Exception(PIVE) ring0以外から特権命令を実行しようとした場合に発生
する。 《L1》機能例外(L1E) L1 function Exception(L1E) 《L1》機能のインプリメントされていないプロセッサに
おいて《L1》の機能を実行しようとした場合に発生す
る。 《L1》を実装しているプロセッサであれば、この例外は
発生せず、このEITに対するベクトツ番号はreservedと
なる。 予約命令例外(RIE) Reserved Instruction Exception(RIE) 現在割り当てられていない命令やアドレッシングモー
ドのビットパターンを実行しようとした場合に発生す
る。いわゆる未定義命令の例外である。 「本発明装置」32で64ビットのサイズを指定した場
合、Pビットを1にした場合、未実装の《L2》命令を実
行しようとした場合、未定義、未実装のオプションを指
定した場合も、これに含まれる。また、命令によって禁
止されているアドレッシングモードを使用した場合(JM
P命令におけるイミディエート指定など)や、インプリ
メントされていない段数の付加モードを使用した場合
も、これに含まれる。 予約機能例外(RFE) Reserved Function Exception(RFE) 命令やアドレッシングモードのビットパターン以外
で、将来の拡張のために予約されている機能を利用しよ
うとした場合に発生する。 例えば、PSWに関しては、XAやreserved(’−’)の
ビットに1を書き込んだ場合、SMRNGのフィールドにres
ervedの値(SM,RNG=001など)を書き込んだ場合、非特
権命令のLDPSB,LDPSMによってPSMやPSBのreserved(’
−’)のビットに1を書き込んだ場合などに予約機能例
外(RFE)が発生する。このほか、実装されていない制
御レジスタをアクセスしようとした場合や、WAIT命令で
imask≧16を指定した場合にも、予約機能例外(RFE)が
発生する。 なお、「本発明装置」では、命令ビットパターン(アド
レッシングモードやサイズの指定を含む)のみでエラー
と判定できるものを予約命令例外(RIE)とし、アドレ
スやオペランド値によってエラーかどうかの状態が変化
するものを予約機能例外(RFE)としている。 コプロセッサ命令例外(CIE) Co−processor Instruction Exception(CIE) コプロセッサが接続されていないのに、コプロセッサ
用に割り当てられた命令を実行しようとした場合に発生
する。 コプロセッサコマンド例外(CCE) Co−processor Command Exception(CCE) コプロセッサとのインタフェースでエラーがあった場
合に発生する。 コプロセッサ実行例外(CEE) Co−processor Execution Exception コプロセッサの命令実行においてエラーがあった場合
に発生する。 不正オペランド例外(IOE) Illegal Operand Exception(IOE) 不合理なオペランドの指定を行なった場合に発生す
る。固定長ビットフィールド命令で32(64)ビット以上
のwidthを指定した場合などがこれに含まれる。 奇数アドレスへのジャンプやゼロ除算も意味的には不
正オペランド例外の一部と考えられるが、特別な意味を
持つために異なる例外に分類されている。 なお、「本発明装置」において命令のオペランドが不
当な場合の対策としては、不当オペランド例外やゼロ除
算例外とするケースのほかに、特にチェックを行なわな
いケース(CHK命令の上限値と下限値の大小関係な
ど)、適当な解釈をしてそのまま命令を実行するケース
(シフト命令でcountが大きい場合など)、などがあ
る。一方、命令を実行した結果が不当(オーバーフロー
など)な場合には、EITが起動されることはない。この
場合はV_flagをセットして命令を終了するケース(ADD,
MOVなど多数)、特に何もしないケース(UNPKssでのオ
ーバーフローなど)、などがある。 10進不正オペランド例外(DDE) Decimal Illegal Operand Exception(DDE) 符号付き10進演算命令において、0〜9以外のデータ
をオペランドとして指定した場合に発生する。 この例外も、意味的には不正オペランド例外(IOE)
の一部であるが、別の例外に分類されている。 予約スタックフォーマット例外(RSFE) Reserved Stack Format Exception(RSFE) REIT命令によってEITから復帰する際に、EITスタック
フレームのフォーマットを示す番号(FORMAT)が、REIT
命令で処理できないものであった場合に発生する。 リング遷移違反例外(RTVE) Ring Transition Violation Exception(RTVE) JRNG命令で外側のリングに移ろうとした場合、RRNG命
令で内側のリングに移ろうとした場合など、不当なリン
グ遷移を行なおうとした場合に発生する。 なお、JRNG命令で参照すべきJRNGVTEを含むページが
未使用領域となっていた場合には、リング遷移違反例外
(RTVE)ではなくアドレス変換例外(ATRE)の未使用領
域参照エラーが発生する。 ゼロ除算例外(ZDE) Zero Divide Exception(ZDE) 0除算を行なった場合に発生する。 [デバッグ] デバッグ例外(DBE) Debug Exception(DBE) デバッグに関係して発生する。 具体的には、命令のシングルステップ実行やブレーク
ポイントを実現するための例外であるが、詳細な仕様は
《LV》である。 [トラップ] 無条件トラップ命令(TRAPA) TRAPA Instruction TRAPA命令により発生する。 TRAPAのEITベクトルは、TRAPAのオペランドvectorに対
応して16種類用意されている。 条件トラップ命令(TRAP) Conditional TRAP Instruction TRAP命令により発生する。 [DCE,DI] 遅延割り込み(DI) Delayed Interrupt(DI) DIレジスタ中のDIフィールドが、PSW中のIMASKフィー
ルドよりも小さい値になった場合に発生する。 このEITは、コンテキストとは独立した非同期の事象
を処理するために有効である。 DI処理のEITベクトルは、各割り込み優先度毎に15種
類用意されている。 このEITは、REIT命令などの命令実行によって発生す
るという点では例外であるが、その時実行中のコンテキ
ストと関係なく起動されるという意味では割り込みであ
る。つまり、例外と割り込みの中間的なものである。
(IMASKフィールドを含むPSWはコンテキスト依存である
が、IMASKフィールドのみはコンテキスト独立として運
用されるのが普通である。) 詳しくは後の章を参照。 遅延コンテキスト例外(DCE) Delayed Context Exception(DCE) CSWレジスタ(あるいはDCEレジスタ)中のDCEフィー
ルドが、PSW中のSMRNGフィールドよりも小さい値になっ
た場合に発生する。 この例外は、コンテキストに依存した各種の非同期の
事象(入出力の完了など)を処理するために有効であ
る。 詳しくは後の章を参照。 [その他] リセット割り込み(RI) Reset Interrupt(RI) 外部からのリセット信号により発生する。 システムエラー例外(SEE) System Error Exception(SEE) EIT処理中に致命的なエラーが起きた場合に発生する。 [割り込み] 外部割り込み(EI) External Interrupt(EI) 外部からのハードウエア信号により発生する。 EITベクトルは外部から指定する。 一般に、外部割り込みのチェックは命令の切れ目で行
なわれるのが普通である。しかし、「本発明装置」の場
合は、実行時間の上限の決まらない高機能命令(任意長
ビットフィールド命令、ストリング命令、QSCH命令)が
存在する。これらの命令では、命令の実行途中であって
も外部割り込みを受け付けるようになっている。 固定ベクトル外部割り込み(FVEl) Fixed Vector External Interrupt(FVEI) 外部からのハードウエア信号により発生する。 EITベクトルは優先度毎に一つずつ決まっている。 いわゆるオートベクトルの割り込みである。 以上のEITのうち、予約例外、不正例外違反例外、の
区別は次のような考え方によっている。 予約XXX例外機能拡張によって解消される可能性のあ
るもの 将来の機能拡張によって、例外ではなくなる可能性が
ある。 メーカー間のインプリメントの違いの出る場合があ
る。 不正XXX例外意味的に明らかにエラーであるもの 予約例外とは異なり、将来の機能拡張があっても、永
久の例外のままである。メーカー間のインプリメントの
違いは出ないところである。 XXX違反例外リング保護の観点から実行を制限してい
るもの その他OSやシステム構成上の例外、複数の分類に当て
はまる例外など A9−2.EITのオペレーション プロセッサがEITを検出すると、以下の手順にしたが
ってEIT処理を行なう。ただし、リセット割り込み(R
I)、システムエラー例外(SEE)については、これとは
違った動作をする。また、以下の説明は「本発明装置」
32に限ったものであり、「本発明装置」64では、パラメ
ータ等が異なってくる可能性がある。 (E1)ベクトル番号の生成 プロセッサはそのEITに応じたベクトル番号をプロセ
ッサ内部で生成する。ただし、外部割り込みEIの場合
は、プロセッサの外部(周辺LSIなど)からEITベクトル
番号を得る。 (E2)EITVTEの読み込み 「本発明装置」では、それぞれのEITに対する処理ハ
ンドラの先頭アドレスと、EITのベクトル番号との対応
を示す表をEITベクトルテーブル(EITVT)と呼ぶ。ま
た、そのテーブルの一つのエントリをEITVTEと呼ぶ。
「本発明装置」のEITVTEは、EIT処理の自由度と拡張性
を考慮して8バイトとなっており、EIT処理ハンドラの
先頭アドレス(PC)だけではなく、PSWの一部のフィー
ルドもセットすることができる。そのため、EITVTEはPC
+PSWに準じた構成になっている。EITVTEのフォーマッ
トは、第353図のようになっている。 VS(Vector SM):EIT処理後のSM ただし、VSがそのままEIT処理後のSMとなるのではな
い。詳細後述。 VX(Vector XA):EIT処理後のXA 現在はOに reserved (違反時は無視) VAT(Vector AT):EIT処理後のAT VD(Vector DB):EIT処理後のDB VIMASK(Vector IMASK):EIT処理後のIMASK ただし、VIMASKがそのままEIT処理後のIMASKとなるので
はない。詳細後述。 VPC(Vector PC):EIT処理後のPC ’=': Oにreserved (違反時は無視) ’−': Oにreserved (違反時はシステムエラー例外) プロセッサは、(EI)で生成したEITベクトル番号に従
い、 (EITベクトル番号)×8+EITVTB の物理アドレスにあるEITVTEを読み込む。 (E3)PSWの更新 読み込んだEITVTEをもとに、以下のようにPSWを更新
する。 [外部割り込み以外の場合] スタックポインタの選択。 EIT発生前にSPI以外のスタックポインタを使っていた場
合は、VSによってEIT処理ハンドラで使用するスタック
ポインタ(SP0またはSPl)が選択される。 EIT発生前に既にSP1を使っていた場合には、VSに関係
なく、EIT処理ハンドラでもSP1をそのまま使う。 このような仕様になっているのは、EITがネストした
場合を考慮したためである。 [外部割り込みの場合](E4)プロセッサ情報のスタックへの退避 EIT発生前の旧PC、旧PSW,および発生した EITに関する各種の情報(EITNF−EITベクトルやスタッ
クフォーマットなどを含む)をスタックに退避する。こ
の退避に使用されるスタックは、新SMと新RNG(=00)
により選択されるスタックである。この時に生成される
スタックフレームは、第354図のようになる。 このうち、EITINFは、発生したEITにより生成される
スタックフレームのフォーマット(FORMAT)、EITのタ
イプ(TYPE)、EITのベクトル番号(VECTOR)などの情
報を32ビットに詰めたものである。追加情報の有無や内
容は、EITの種類によって異なる。REIT命令では、EITIN
F中のFORMATを見ることによって追加情報の有無やその
フォーマットを知り、EIT発生前のもとの命令列に戻る
ための情報を得る。 なお、「本発明装置」64になった場合に生成されるEI
Tのスタックフレームは、旧PCで1ロングワード、旧PSW
とEITINFを合わせて1ロングワード、という構成になる
予定である。 EITINFをPSWに隣接した場所に置いたのは、「本発明
装置」64でのアライメントの維持を考慮したためであ
る。また、PSWをスタックトップに置いたのは、将来
「本発明装置」64で、32ビットのコンテキストと64ビッ
トのコンテキストが混在した場合でも、スタック中に退
避されたPSW中のXAビットが読み出せるようにするため
である。 (E5)EIT処理ハンドラの起動 VPCをPCに転送し、EIT処理ハンドラを起動する。 なお、命令プリフェッチにおいて発生したEITは、フ
ァッチしようとした命令が必要になるまでEIT処理が遅
らされる。 これに対して、EIT処理ハンドラの最後に置かれたREI
T命令では、次のような処理を行なってもとの命令列に
復帰する。 (R1)スタックからの読み込み スタックより、旧PSWとEITINFを読み込む。読み込ん
だPSW中のXAビットが0であれば、EITを発生したコンテ
キスト(タスクやプロセス)が32ビットのコンテキスト
であったということがわかるので、続いてスタックより
32ビット幅で旧PCを読み込む。なお、「本発明装置」32
では、すべてのコンテキストが32ビットのコンテキスト
である。 さらに、EITINF中のFORMATにより追加情報の有無を判
定し、追加情報があれば、スタックからそれを読み込
む。追加情報には、EXPC,IOINF,ERADDR,ERDATA,SPIなど
があるが、その詳細な意味はインプリメント依存であ
る。 FORMATがプロセッサのサポートしていない値(EITで
発生するはずのない値)であった場合は、予約スタック
フォーマット例外(RSFE)となる。 (R2)PSWの復帰 スタックから読み込んだ旧PSWにより、PSWの全フィー
ルド(SMRNG,XA,AT,DB,IMASK,PSM,PSB)をEIT発生前の
値に復帰する。この時、旧PSWがreservedの値を含んで
いた場合には、予約機能例外(RFE)を発生する。 (R3)ストアバッファの再実行(インプリメント依存) FORMATと追加情報の値によっては、REIT命令の中で、
前回EITを発生したストアバッファによるライトサイク
ルの再実行を行なう場合がある。この時、ライトサイク
ルの実行に必要なアドレスとデータの情報としては、ス
タック上の追加情報の中にあったERADDRとERDATAが使用
される。詳しくは、EITのタイプの説明の項を参照。 なお、ストアバッフアのみを再実行する機能があるか
どうかということは、プロセッサのインプリメント上の
問題である。すなわち、REIT命令のストアバッファ再実
行機能を前提としてEIT処理が作られている場合には、
当然REIT命令でそれをサポートする必要があるし、スト
アバッファのみの再実行機能が無くても矛盾のないEIT
処理が実現できていれば、REIT命令でそれをサポートす
る必要はない。プログラマから見た場合は、EIT処理とR
EIT命令による処理がきちんと対応しており、REIT命令
によってEIT処理から戻った時に、EITを発生した命令列
が矛盾なく実行を続けられれば良いのである。この機能
の有無とプロセッサとしての機能の高低とは直接関係し
ない。 (R4)EIT検出時に実行していた命令列への復帰 スタックから読み込んだ旧PCをPCに復帰し、 PCの示す命令から実行を再開する。 この時、EITINF中のTYPEフィールドによって、次に受
け付けられるEITのタイプを変化させている。この機能
は、多重EITの処理を矛盾なく行なうために、また命令
のシングルステップ動作を、エミュレーションによる実
行を含めて正確に行なうために利用される。 なお、EITINFのVECTORフィールドは、REIT命令では特
に使用されない。にもかかわらずVECTORがEITINFに含ま
れているのは、EIT処理ハンドラのプログラムに対して
情報を提供するためである。 A9−3.EITのタイプ 「本発明装置」のEITを、EIT処理ハンドラ終了後の実
行再開時のPCの位置と、EIT処理の優先度に着目して分
類すると、以下のようになる。この分類は、EITINFのTY
PEフィールドの値にそのまま対応する。 [命令中断型EIT(TYPE=O,PC不定)] このEITが発生すると、直ちにそれが検出され、EIT処
理に入る。このEITが発生した場合、EITを発生した命令
系列に復帰することはできない。これに該当するのは、
RI,SEEである。 [命令完了型EIT(TYPE=1〜3,PC次命令)] このEITが発生すると、その時実行中の命令処理が完
了した後でそれが検出され、EIT処理に入る。一般に
は、このEITに対するEIT処理ハンドラの最後でREIT命令
を実行することにより、EIT発生時に実行していた命令
の次の命令から、命令の実行を再開できる。なお、TYPE
=1〜3の区別は、優先度などの関係によるものであ
る。これに該当するのは、TRAP,TRAPA,DBE,DI,DCEなど
である。 [命令再実行型EIT(TYPE=4,PC現命令)] このEITが発生すると、プロセッサやメモリの状態
は、EIT発生時に処理していた命令の実行開始前の時点
に戻される。一般には、このEITに対するEIT処理ハンド
ラの最後でREIT命令を実行することにより、EIT発生時
に実行していた命令から、命令の実行を再開できる。こ
れに該当するのは、POE,ATRE,BAE,RIE,RFE,PIVE,IOEな
どである。 命令完了型のEITは、以前実行していた命令に関するE
ITであり、命令再実行型のEITは、現在実行中の命令に
関するEITである。したがって、複数のEITが同時に発生
した場合には、一般に命令完了型のEITを先に処理する
必要がある。また、命令中断型のEITは重要度の高いEIT
であり、これが検出された場合には、他のEITを処理す
ることは無意味である。したがって、命令中断型のEIT
と他のEITが同時に発生した場合には、命令中断型のEIT
を先に処理する必要がある。結局、複数のEITが同時に
発生した場合の優先度は 命令中断型>命令完了型>命令再実行型となり、EITI
NFのTYPE=0〜4が、そのままEITの優先度を表わすこ
とになる。 EITの種類とTYPEとの対応は、RI,TRAPのように明確に
決まっているものもあるが、ある程度はインプリメント
依存の部分がある。したがって、ソフトウエアでEITの
要因を分析する際には、できるだけTYPEのフィールドを
参照したり、書き換えたりしない方がよい。 例えば、ページ不在例外(POE)の場合、これは命令
再実行型のEITであり、TYPE=4となるのが普通であ
る。しかし、メモリの書き込みにストアバッファを用い
るようなインプリメントのプロセッサにおいて、命令の
最後の書き込みサイクル(ストアバッファ使用)でPOE
が発生した場合には、この命令全体を最初から再実行し
なくても、最後の書き込みサイクルのみやり直せば処理
上の矛盾は生じない。そこで、このようなケースでのPO
Eを命令完了型のEITとし、エラーを発生した最後のライ
トサイクルの処理はREIT命令の中で行なうという場合が
ある。この場合は、POEでもTYPE=1となる。また、EIT
処理でスタック積まれるPCは、POE発生命令ではなく次
の命令になる。 命令再実行方式に忠実にしたがう限り、命令実行中に
エラーが発生した場合は、命令実行前の状態に戻してTY
PE=4のEITを起動するというのが原則である。しか
し、命令がもう少しで終了するというところでエラーが
発生した場合には、一応命令を終わったことにしてTYPE
=1のEITを起動し、残りの処理(ストアバッファのラ
イトサイクル)はREIT命令に任せるというインプリメン
トも可能なのである。このようなインプリメント方法を
とるのであれば、POEのTYPEが1と4の2通りになる。
つまり、一種の命令継続実行方式になっている。この場
合、TYPEの違いによってREIT命令で必要となる処理が変
わってくるので、REIT命令はそれに対応できるようにな
っていなければならない。 この方法では、命令最後のライトサイクルで発生した
エラーによるEITに対して、命令全体を再実行するので
はなく、最後のライトサイクルのみを再実行するという
形になっている。つまり、一種の命令継続実行方式にな
っている。この場合、命令継続実行のために退避される
内部情報に相当するのが、EITの追加情報としてスタッ
ク上に退避されるERADDRやERDATAである。 なお、ストアバッファを用いた書き込みサイクルで発
生するEITの場合、その書き込みを行なった命令の直後
にEIT処理に入るとは限らない。 A9−4.EITのスタックフォーマット EITの検出にともなって、EIT処理に必要な情報がスタ
ックに退避される。そのスタックフォーマットは第355
図の通りである。 PSW :EITを検出した時点のPSW Format:スタックフォーマット番号(8bit) Type :EITタイプ(8bit) Vector:EITベクタ番号(9bit) PC :EITのハンドラからの復帰後の、実行再開アドレ
ス この内、「その他の情報」は各EITのスタックフォー
マット番号に応じて異なり、EITの要因を解析するため
の情報、EITハンドラから復帰するための情報が含まれ
ている。スタックフォーマット番号に応じたスタックフ
ォーマットを第356図に示す。 PC :REIT命令でEITから戻った後に実行する命令
の先頭アドレス EXPC :EITの検出時に実行していた命令のPC。 IOINF :入出力に関する情報 Error Addr:EITを発生させたバスサイクルのアドレス Error Data:EITを発生させたバスサイクルのデータ(wr
iteのみ) SPI :EIT検出時のSPIの値 フォーマット番号0: 予約命令例外、予約機能例外、予約スタックフォーマッ
ト例外、リング遷移違反例外、《L1》命令例外、コプロ
セッサ命令例外、特権命令違反例外、不正オペランド例
外、固定ベクトル外部割り込み、遅延割り込み例外、外
部割り込み。 フォーマット番号1: バスアクセス例外、アドレス変換例外。 フォーマット番号2: デバッグ例外、奇数アドレスジャンプ例外、ゼロ除算例
外、条件トラップ命令、トラップ命令。 フォーマット番号3: DBG外部割込み、DBGトラップ命令、DBGデバッグ例外、D
BGアクセス違反例外(つまりDBG EIT専用) EXPCは次のような目的で導入されたものである。 ・エラー解析情報の提供 −ストアバッファの書き込みの際にTYPE=1のEITが発
生したような場合、その書き込みを行った命令を指して
いるのがEXPCである。PCは先に進んでしまっている。 −デバッグ例外では、PCは次の命令を指し、EXPCは前の
命令を指している。したがって、例えば、ジャンプ命令
実行時にデバッグ例外を起動するようにした場合、EXPC
によってジャンプ前のPCの値を、PCによってジャンプ後
のPCの値を知ることができる。 ・多重EITの処理 −TYPE=1のTRAPAなどのEITの場合は、その処理ハンド
ラの中でEXPCの情報が必要になることはない。しかしな
がら、TYPE=1のEIT(TRAPAなど)とTYPE=2のEIT
(デバッグ例外など)が同時に発生した場合、TYPE=1
のEITにおいて、TYPE=2で使用するEXPCを退避してお
かなければならない。TRAPAでもEXPCを退避するような
仕様になっているのは、このためである。 この場合、TRAPAの処理に対するREIT命令実行後のEXP
Cは、REIT命令の先頭を指すのではなく、スタックから
ポップした旧EXPCの値を復帰したものになっていなけれ
ばならない。すなわち、REIT命令の直後になっていたデ
バッグ例外を起動した直後にベンディングになっていた
デバッグ例外を起動した場合、スタックに退避されるEX
PCは、REIT命令を指すのではなく、TRAPA命令を指すも
のでなければならない。(なお、この例は、TRAPAのEIT
VTEでデバッグ例外をマスクすることを想定したもので
ある。) また、IOINFの構成は第357図のようになっている。 = :'0'にreserved WI :REIT命令におけるライトリトライの指示 メモリアクセス系のEIT(TYPE=1)で意味を持つ。 WI=0 ライトリトライ 要 WI=1 ライトリトライ 不要 MEL:アドレス変換例外の発生位置 0000 エラーなし 0001 アクセス権に関するエラー 0010〜1110(reserved) 1111 1/0領域に関するアクセスエラー MEC:メモリアクセス関係のエラーのエラーコー
ド 0000 エラーなし 0001 未使用領域参照 エラー 0010 (reserved) 0011 (reserved) 0100 readに関するリング保護違反エラー 0101 writeに関するリング保護違反 エラー 0110 executeに関するリング保護違反エラー 0111 (reserved) 1000 read時のバスアクセス不能 1001 write時のバス アクセス不能 1010 (reserved) 1011 (reserved) 1100 (reserved) 1101 I/0領域に対するメモリ間接アドレッシング 1110 I/0領域に対するexecute 1111 read時にI/0領域と1/0以外の領域をまたぐ write時にI/0領域とI/0以外の領域をまたぐ RW :バスサイクル種別 RW=0 write RW=1 read BL :バスロック状態 BL=0 バスロック中でない BL=1 バスロック中 PA :空間の指定 PA=0 (reserved)…論理空間(アドレス変換
あり) PA=1 物理空間(アドレス変換なし) AT :EITが発生したバスサイクルのアクセスタイプ AT=000 データ AT=001 プログラム AT=010 割り込みベクトルフェッチ AT=011〜111(reserved) SIZ:ライトリトライを行う際のデータサイズ 0000 (reserved) 0001 1バイト 0010 2バイト 0011 3バイト 0100 4バイト 0101〜1111(reserved) A9−5.「本発明装置」のEITベクトル・テーブル 第358図に示す リセット割込みとDBGモードのEIT(No.0〜5)に関す
るEITテーブルのエントリはSPI値とPC値で構成される。
その他のEITに関するEITテーブルのエントリはPSW値とP
C値で構成される。 EITVBのリセット時の初期値は'FFFFFOOO'であるた
め、リセット割込みでは物理番地の'FFFFFOOO'からエン
トリ(SPI,PC)がフェッチされる。 A9−6.EIT処理中のエラー EIT処理中(EIT発生から状態の退避を経て新PSWの設
定まで)に、別のEITが発生するような重大なエラーが
起きた場合には、システムエラー例外(SEE)となる。
システムエラー例外(SEE)となる可能性があるのは、E
ITVTEの読み込みに伴うバスアクセス例外、旧PC、旧PSW
の退避に伴うスタックのページ不在例外、アドレス変換
例外などである。また、EITVTEのVPCを含むワードのLSB
が'1'であった場合にも、システムエラー例外(SEE)と
なる。 システムエラー例外(SEE)の発生は、SPI,SPOのどち
らかのスタックを使用するかということには関係しな
い、SPOのスタツクでページ不在例外が起った場合に
も、SPIのスタックに切り換えてあるいはページ不在例
外のEITVTEで指定されるスタックに切り換えて)、EIT
処理中を継続するという仕様になっていない。 一方、JRNGによるリング遷移はEITでないので、JRNG
の処理中にページ不在例外が起った場合には、ページ不
在例外のEITVTEで指定されるスタックを使って、ページ
不在例外のEIT処理中を行うことになる。この点で、EIT
処理中に含まれるTRAPAとEIT処理中に含まれないJRNGで
は、システムエラーとなるまでのステップが一段異なっ
ているので、注意が必要である。(第359図参照) いずれにしても、OSを作る場合には、SPIにより指定
されるスタック領域はメモリ常駐とし、SPOにより指定
されるスタック領域も、特殊な使い方をする場合を除け
ばメモリ常駐となるようにプログラミングする必要があ
る。 A9−7.多重EIT TYP=0のEITを除けば、EITの検出とそれに対する処
理は、各命令の切れ目で行われる。したがって、場合に
よっては、命令の切れ目において複数のEITが同時に検
出される可能性がある。これを多重EITと呼ぶ。ここで
は、多重EITの処理順序について説明する。 例えば、TYP=0のTRAPAとTYP=3の外字割り込み(E
I)が同時に発生した場合、まずTRAPAに対するEIT処理
中が行なわれ、引続きEIに対するEIT処理中が行なわれ
る。その結果、PC,PSWとスタックの状態は第360図のよ
うになる。 したがって、この例では、EIT処理中終了後にまずEI
の処理ハンドラが実行される。EIの処理ハンドラが終了
した後は、その最後に置かれたREIT命令により、一段浅
いレベルにあるTRAPAの処理ハンドラに移る。つまり、
優先度の高いTRAPA処理ハンドラの方が後回しになるわ
けである。 ただし、上の例では、TRAPAのEIT処理中が先に行われ
るため、そこでPSWを変更してEIをマスクすることがで
きる。つまり、TRAPAのEITVTEで VIMASK<EIの優先度 となるような指定を行っておけば、TRAPAのEIT処理中で
IMASKが変更され、EIに対するEIT処理中は行なわれなく
なる。この場合は、TRAPAの処理ハンドラが実行され
る。そして、ハンドラの最後のREIT命令でIMASKが元の
値に戻った時に、マスクされていたEIが起動されること
になる。 このように、優先度の高い(TYPEの小さい)EIT処理
中におけるPSWの更新によってマスクされるEITには、DB
E,EI,DI,DCEのEIT、つまりTYP=2〜3のEITがある。逆
に言えば、マスク可能なEIT(処理要求を保持すること
が可能なEIT)が、優先度の低いTYP=2〜3になってい
るわけである。 これに対して、TRAPAの場合は、EIT処理中要求を保持
するレジスタやハードウエアは何も用意されていない。
PCも次の命令に進んでいるので、TRAPA命令を再実行す
ることもできない。したがって、TRAPA命令実行直後にE
IT処理中を行わないと、EIT処理中要求が失われてしま
う。TRAPAをTYP=1の高い優先度にしているのは、この
ためである。 また、TYP=4のEITは命令再実行のEITであるため、
他のEITに対する処理が終わった後でもう一度同じ命令
を実行すれば、再び同じEITが発生する。命令実行型(T
YP=4)のEITが最も低い優先度になっているのは、こ
のためである。したがって、多重EITの場合には、TYP=
4のEITの処理は行う必要がない。TYP=4のEIT起動要
求は、同時に発生しTYP=1〜3のEITの検出に伴ってキ
ャンセルされる。 REIT命令実行直後に受け付けられる。EITとは異なっ
ている。REIT命令では、スタック中からポップされたEI
TINFの中のTYPEによって、REIT命令終了直後に受け付け
るEITわ調整している。REIT命令実行後に受け付けられ
るEITのTYPEは第361図の通りである。 このうち、TYPE=2はデバック例外(DBE)である。
つまり、デバック例外に対するEIT処理中ハンドラのREI
T命令実行直後には、デバック例外を受け付けないとい
うことを意味している。 REIT命令実行直後かどうかによって、TYPE=2のデバ
ック例外の扱いが異なっているのは、1命令毎のシング
ルステップ実行を行うためである。この場合、デバック
例外に対するREIT命令の直後で再びデバック例外を起こ
していたのでは、被デバックプログラムの実行が全く進
まずに、デバック例外のみが続けて発生するという状況
になってしまう。したがって、上記メカニズムにより、
REIT命令の直後い”はデバック例外を発生せず、1命令
実行してからデバック例外を発生するようにしているの
である。 一般に、シングルステップ実行を行う場合には、次に
命令を実行するか、デバック例外を起動するかの二つの
内部状態を持つ必要がある。「本発明装置」では、この
二つの状態を、REIT命令実行直後かどうかといった内部
状態と、EITのTYPEとの組み合せによって表現している
と考えられる。 なお、この考え方によるシングルステップ実行は、デ
バック例外と同時にほかのEITが発生した場合にも適用
できる。 予約命令例外(RIE)のEIT処理中ハンドラで命令エミ
ュレーションを行う場合は、他のEIT(ページ不在な
ど)に対する処理ハンドラとは異なり、RIEの処理ハン
ドラの前後でデバック例外を起動しなければならない。
例えば、シングルステップ実行後に 通常命令→デバッグ例外→ページ不在例外であれば次
は通常命令を実行する必要があるが、 通常命令→デバッグ例外→予約命令例外(エミュレー
ション) であれば次はデバック例外の起動となる。これは、ペー
ジ不在例外がデバッガやデバック対象プログラムにとっ
て全く見えないものであるのに対して、エミュレーショ
ン例外は、デバッガ対象プログラムにとって「一命令の
実行」として見えるはずのものだからである。「本発明
装置」の場合は、予約命令例外のEIT処理中ハンドラの
中でEITINFのTYPEを調整することにより、以上のような
ことが可能である。 A9−8.「本発明装置」のDI A9−8−1.DIのオペレーション 「本発明装置」のDI(Delayed Interrupt)は、DIレ
ジスタ中のDIフィールドがPSW中のIMASKフィールドより
も小さい値になった場合に発生するEITである。この機
能は、コンテキストとは独立した非同期の事象をペンデ
ィングとして処理要求だけを登録したり、処理順序をシ
リアライズしたりする時など有効なものである。 DI処理のEITベクトルは、各割り込み優先度毎に15種
類用意されている。IMASKの値と、そのフラグ変化のそ
の時に許可される外部割り込みとの関係は、第362図の
ようになっている。 DIを起動するかどうかのチェックをする必要があるの
は、IMASKが大きくなった時、またはDIが小さくなった
時である。したがって、これに該当するのは、 LDC src,@psw ;pswは制御空間中のPSWのアドレス LDC src,@imask;imaskは制御空間中のimaskのアドレス LDC src,@DI :DIは制御空間中のDIのアドレス REIT WAIT の各指令である。このうち、LDC srd,@di以外の場合に
は、これらの命令を実行する前のDIフィールドの値が、
起動されるDIのレベル(優先度)となる。DIのレベル
は、DIとして起動されるEITのベクトル番号に影響す
る。また、LDC srd,@diによってDIが起動された場合に
は、LDC実行前のDIフィールドの値ではなく、LDCによっ
て新しくセットされたDIフィールドの値(つまりscr)
が起動されるDIのレベルとなる。なお、EIT起動時(外
部割り込み、例外、TRAPすべて含む)にもIMASKの変化
するところがあるが、この場合にはIMASKの値が大きく
なることはないため、DIは起動されない。 DIが起動された場合、DIフィールドは1111(要求な
し)にリセットされる。また、IMASKフィールドは、受
理されたDIのレベルを優先度とする外部割り込みが発生
したのと同じ変化をする。つまり、 となる。 A9−8−2.DIの使用例 [例;本発明装置の遅延ディスパッチ(deiayed dispat
ch)] 本発明装置では、外部割り込み処理ハンドラの中から発
行したシステムコールによってレディキューの状態が変
わった場合に、それに伴うディスパッチング(レジスタ
の入れ替えなど)が割り込み処理ハンドラから戻るまで
遅らされる。これは、多重割り込みに伴う矛盾を避ける
ためである。これをDIの機能によって実現する。 前提条件 ・システムコールはTRAPAのEITVIEでは、VIMASKでは、V
IMASK=14を指定しておく。これは、DI機能によって、
システムコール処理の最後のディスパッチングを行うた
めである。 ・ディスパッチングの処理を行う部分は、D114によって
起動される。 ・'I'は実行中の状態を表し は実行を中断した状態を表す。 一般のシステムコール処理 第363図に示す 外字割り込み処理ハンドラからのシステムコール 第364図に示す DIの機能を使えば、本発明装置の遅延ディスパッチの
処理をすなおに実現することができる。 また、多重割り込みやシステムコールのネストが起こ
った場合にも容易に対処できる。 A9−9.本発明装置のDCE A9−9−1.DCEのオペレーション 本発明のDCE(Delayed ontext Exception)は、DECレ
ジスタ(またはCSWレジスタ)中のDCEフイールドよりも
小さい値になった場合に発生するEITである。この機能
は、コンテキストに関連した非同期の事象(入出力の完
了など)の処理をペンディングとして処理要求だけを登
録したり、処理順序をシリアライズしたりする時などに
有効なものである。 DECレジスタ(またはCSWレジスタ)中のDCEフィール
ドは、DCE要求を入れるためのフィールドは、DCE要求を
入れるためのフィールドである。 DECレジスタ(またはCSWレジスタ)はコンテキスト毎
に固有のレジストであるため、コンテキスト毎に別々の
DCE要求を与えることが可能である。DCEは各コンテキス
トに付随したものであるから、コンテキストとは独立し
た外部割り込みの処理中(SM=0の場合)には、DCEは
起動されない。 また、他のコンテキストAでより高い優先度のDCE要
求が出ていても、そのコンテキストAにディスパッチさ
れない限り、コンテキストAのDCEは起動されない。別
のコンテキストBで出ているDCE要求がそれより低い優
先度あったとしても、コンテキストBに先にディスパッ
チされれば、コンテキストBのDCEが先に起動される。 DCEフィールドの値と、その時に起動されるDCEとの関
係は第365図のようになつている。 いずれの場合にも、SMRNG>DCEとなった時にDCEが起
動される。 (reserved)の指定をした場合、実際にはDCE=000と同
じ動作をする。ただし、将来の拡張のため、この機能を
利用したプログラミングを行なってはいけない。 DCEの起動される可能性があるのは、SMRNGが大きくな
った時、またはDCEフィールドの値が小さくなった時で
ある。したがって、この条件に該当する以下の命令にお
いて、DCEを起動するかどうかのチエックをする必要が
ある。 LDC src,@psw ;pswは制御空間中のPSWのアドレス LDC src,@smrng:smrngは制御空間中のSMRNGのアドレス LDC src,@dce ;dceは制御空間中のDCEのアドレス LDC src,@csw ;cswは制御空間中のCSWのアドレス ;ただし、CSWは実装されない場合がある。 REIT RRNG なお、EIT起動時(外部割り込み、例外、TRAPすべて
含む)やJRNG実行時にもSMRNGの変化することがある
が、EITやJRNGの場合はSMRNGの値が大きくなることはな
いため、DCEが起動されることはない。 DCE自体は、一つのEIT処理として起動される。DCEのE
ITが起動された場合、DCEフィールドは111(要求なし)
にリセットされる。SMRNGフィールドは、一般のEIT処理
と同じように、DCEのベクトル番号に割り当てられたEIT
VTEにしたがって変化をする。DCEはコンテキスト毎の処
理であるため、起動されたEIT処理ハンドラでは、SPIで
はなくSPOを使用するのが普通である。EITVTEの設定に
よっては、DCE処理でSM=0(SPI使用)に入ることも可
能であるが、これは運用上の問題として対処し、ハード
ウエアでは特にチエックは行なわない。 REIT命令やRRNG命令によつてDCEが起動された場合、
実際にDCEを起動する処理はREITやRRNGと同時に行なわ
れてもよいが、動作仕様上は、一旦REITやRRNGの実行が
終わってからEITを起動するという形になる。たとえ
ば、DCE=110の時にRRNGでring1からring3に戻ると、そ
こでDCEが起動されてring0に入る。この時、PRNGはring
1ではなくring3となっていなければならない。DCEとDI
や外部割り込みを比較すると、第366図のようになる。 入出力の完了通知などの場合には、外部割り込み処理
ルーチンの中で、該当するコンテキストDCEを起動する
という流れになることもある。 DCEをソフトウエアによってシュミレーションするこ
とは不可能ではないが、一般には、スタック上に退避さ
れたPSWやPCの変更をしなければならないため、かなり
面倒である。割り込んだプログラロムが、割り込まれた
プログラムのスタくックハフオーヘマツトをすべて知っ
ていなければならなにいからである。 A9−9−2.DCEのネスト DCEは多重ネストができるとより効果の大きいものに
りなる。したがって、DCE要求が複数発生した場合に、
どのような処理をするかが問題となる。 本案装置では、ネストの処理(要求のキユーイング)
はソフトウエアで行なう方針である。 《複数のDCE要求のキューイング処理例》 〔DCE要求設定時〕 〔DCE処理時〕A9−9−3.DCEの使用例 〔例;入出力管理プログラムの起動〕 外部割り込みによって入出力完了が通知され、それに
よって、プロセスAの入出力管理部(ring1)がプロセ
スAに対して非同期に起動されるものとする(第367図
参照)。 ・'I'は実行中の状態を表し は実行を中断した状態を表す。 の開始アドレスはプロセス(コンテキスト)毎に指
定されるべきものだが、実際にはDCEのEIT処理ベクトル
がプロセス間で共通であるため、OSでプロセス毎のDCE
要求テーブルを解析し、そこへジヤンプする必要があ
る。 この図の場合は、外部割り込みが発生した時にたまた
まプロセスAが実行中だつたわけである。他のプロセス
の実行中に入出力の外部割り込みが発生した場合、ring
1の入出力管理部の起動は、プロセスAへのディスパッ
チが行なわれるまで遅延させられる。 付録10.本発明装置の命令ビットパターン 〔表記法に関する注意〕 命令ビットパターンの表記は、次のように行なう。 ’−’ 0にreserved(違反時例外発生) ’+’ 1にreserved(違反時例外発生) このビットが0(1)であれば処理が正常に行なわ
れ、このビットが1(0)であれば予約命令例外(RI
E)を発生する。 ’=’ 0にreserved(違反時も無視)…Ver0.87の’
*’ ’#’ 1にreserved(違反時も無視) ユーザへのマニュアルには、将来の拡張のためこのビ
ットを0(1)にしておくように明記する。実際には、
このビットが0(1)であっても1(0)であっても動
作は同じである。 「違反時も無視」というのは、アーキテクチャ上あま
り好ましいことではないが、命令ビットパターンの割り
当て、将来の拡張性、命令の高速実行の上からやむを得
ない場合がある。 ’〜’ 0にreserved(違反時動作を保証しない) '!' 1にreserved(違反時動作を保証しない) ユーザへのマニュアルには、将来の拡張のためこのビ
ットを0(1にしておくように明記する。実際には、こ
のビットが0(1)の場合は正常な動作を行なうが、1
(0)の場合の動作はインプリメントに依存して異なっ
ている。 「違反時動作を保証しない」というのは、アーキテク
チャ上あまり好ましいことではないが、インプリメント
や命令ビットパターンの割り当て、命令の高速実行の上
からやむを得ない場合がある。例えば、LDATE,MULXの第
一ハーフワードの'!R'がこれに該当する。 A10−1.命令のフォーマット別ビット割り当て 〔ビット割り当てに関する注意〕 ・本発明装置では、使用できるアドレッシングモードが
命令毎にかなり異なっており、そのチェックをする必要
がある。チェックを容易にするため、許されるアドレッ
シングモードが区別しやすいようにビットパターンの割
り当てを行なう。特定のアドレッシングモードを禁止し
ているオペランドの場合は、原則として、それがそのオ
ペランドを含むハーフワードだけで分かるようになって
いる。 ・Pビットは、原則としてオペランド毎(レジスタ直接
指定とイミディエート指定を除く)、および暗黙のスタ
ック参照について一つずつ独立に入れる。命令パターン
中では、'P'または'Q'で表す。 ただし、一般形の命令でカバーできる場合は、同じ命
令の短縮形ではPビットが入らないこともある。(PUS
H,POP,PUSHAのみは、スタック参照に関するPビットが
ない。) ・ビットパターンのうちLVreservedで示されているもの
は、各メーカーで自由に使用してよい命令ビットパター
ンである。この命令ビットパターンは、例えばICEとの
インターフェースを行なうための、ユーザに開放しない
命令として利用することができる。 以下第368図に示す。 A10−2.予約命令例外の検出について 上記のビットパターン中で{RIE}で示されたパター
ンは、将来の拡張のために予約された(reserved)’の
ビットパターンである。この命令ビットパターンを実行
すると、予約命令例外(RIE)は発生する。このほか、
インプリメントされていないオプションやサイズ(未実
装の《L2》を含む)を指定した場合、未定義のオプショ
ンを指定した場合、命令ビットパターンの’−’の部分
を'1'にした場合、命令ビットパターンの’+’の部分
を'0'にした場合、命令中の'P','Q'のビットを'1'にし
た場合、reservedの条件(cccc)や終了条件(eeee)を
指定した場合にも、すべて予約命令例外(RIE)とな
る。現在、LDATE,MULXなどの例外を除けば、原則として
第一〜第四バイトについてはすべての命令パターンをチ
ェックし、パターンが違っている場合には、RIEにして
いる。第五、第六バイトについてはチェックを行わず、
パターンが違っていてもエラーとはしていない。 上記のビットパターンのうちで、特に{RIE−X}で
示したものは、第一HWが汎用アドレッシングモードを含
み、第二HWまで読まないとRIEであることがわからない
ビットパターンである。この場合は、第一HWのEaの拡張
部の後に第二HWが置かれる。現在使用していないビット
パターンのうち、将来の機能拡張にともなって実装の予
定のあるパターンや、他のメーカーのチップと動作の異
なりそうなパターンについては、特に積極的に検出を行
なうべきである。これは、その命令パターンを実行した
場合の間違いを防ぐためである。このような方針に基づ
いて場合、予約命令の例外(RIE)のチェックの優先度
は次のようになる。 ↑高優先度 (既に意味が決まっているもの) 未定義の《L2》機能の指定 64ビットサイズの指定(RR,MM,WW,SS=11) (命令の拡張に利用される可能性の高いもの) {RIE}となっている命令パターンの指定 BVPAT〜BVSCHの’+X'の’+’ PSTLB〜EXITD:Gのグループの第二HWの’−’ Pビット指定 (命令の拡張にはまず利用されないもの) LDATE〜INDEXのグループの第一HW'!R'の'!' STATE〜QINSのグループの第二HW'+W'の’+’ PSTLB〜EXITD:Gのグループの第一HW'+X'の’+’ ACB:R,SCB:Rの第二HWの’−’ ↓低優先度 現在チェックすべきビットパターンは前述のような仕
様になっているが、今後、このような方針に基づいて予
約命令例外の検出に関する詳細仕様の調整を行ない、一
部は変更の行われる可能性がある。 なお、命令をどこまで読んだ時にEITを起動するかと
いうことは、特に規定しないものとする。第一HWだけで
EITを起動することが明らかである場合にも、第二HWま
で読んでもよい。また、オペコード部だけでEITを起動
することが明らかである場合(予約命令例外など)に、
Eaの拡張部まで処理しても構わない。 A10−3.オペランドフィールド名索引 第369図に示す。 A10−4.アドレッシングモードのビット割り当て 共通ビットパターン ・サイズ関係 01 16bit 10 32bit 11 64bit ・アドレッシングモード00 @reg+など01 16bit相対間接モード10 32bit相対間接モード11 付加モード ・レジスタ指定00 (特殊)01 (SP)10 absまたは011 PC<d4>のサイズ指定部分とMISCモードのdisp:16,disp:3
2の指定部分が同じビット位置になっている。 未定義のアドレッシングモードを指定した場合(EA中
のPビット=1を含む)には、予約命令例外(RIE)と
なる。具体的には、以下のパターンの場合にRIEとな
る。 付加モードでリザーブのパターンを指定した場合に
も、予約命令例外(RIE)となる。M=1で<Rn>≠000
0,0001の場合、D=1で<d4>≠0001,0010以外の場
合、P=1の場合、XX=11の場合もこれに含まれる。 付加モードのある段で、PCに対して、×2、×4、×
8以外のスケーリングを指定した場合には、その段の終
了処理後の中間値として、インプリメントに依存した不
定値が入る。EITにはならない。《L2》未定義、5段以
上の付加モードを指定した場合にも、予約命令例外(RI
E)となる。〔詳細調整中。予約機能例外RFEとなる可能
性もある。〕命令によって使用できないアドレッシング
モードの組み合わせを指定した場合(JMP ♯imm−data,
CMP♯0,♯1など)にも、予約命令例外(RIE)となる。
《L2》未実装のために実行できない組み合わせを指定し
た場合も、これに含まれる。(これに当てはまるもの
は、レジスタ指定のビットフィールド命令である。) A10−5.命令オプションのビット割り当て いずれの場合にも、最初に記述した方(オプション値
が0,00‥の方)がアセンブラでのデフォルトになる。 cccc Bcc,TRAP/ccでの条件指定 eeee ストリング命令、QSCH命令での終了条件指定 p,q‥ Pビット指定(Q‥は、Pビットの必要なオペ
ランドが複数の場合) b /F=0,/B=1(BSCH,BVSCH,BVMAP,BVCPY,SCM
P,SMOV,QSCH) r /F=0,/R=1(SSCH) c /N=0,/S=1(CHK)−CHK,change index va
lueの'c' d /0=0,/1=1(BSCH,BVSCH)−dataの'd' m /NM=0,/MR=1(QSCH)−maskの'm' p /AS=0,/SS=1(PTLB,PSTLB,LDATE) −PTLB,specific spaceの'p' ttt /PT=000,/ST=001,/AT=110,{RIE}=010〜10
1,111(PSTLB,LDATE,STATE) xx /LS=00,/CS=01,{RIE}=10,11(LDCTX,STCT
X) A10−6.Bcc命令、TRAP/cc命令の条件指定(cccc) ccccの値の割り当ては、第370図のようになる。 A10−7.終了条件の指定(eeee) eeeeの値の割り当ては、第371図のようになる。 0000〜0101については、cccc(Bcond命令の条件指
定)のビットパターンに意味を合わせてある。特に、LT
U,GEUは、SUBX命令などにおいて、オペランドを符号な
しデータと考えた場合の比較結果がx−flagに反映され
るのに合わせたものである。 なお、《L2》の終了条件のうち、二つの条件が.or.で
結ばれているものについては、そのうちのいずれの条件
で終了したかを示すために、M_flagを使用する。m_flag
がセットされるのは、原則としてR4との比較によって 終了した時であり、具体的には第372図のような場合で
ある。 M−flag=1の条件を満たさなかった場合、および、
これ以外の終了条件で終了した場合には、M_flag=0と
なる。《L2》の終了条件をインプリメントしない場合に
は常にM_flag=0となるが、その場合でも、将来はM_fl
ag≠0となる場合が生じるということを、マニュアルに
明記しておくのが望ましい。 A10−8.BVMAP命令の演算コード R5の下位4ビットに入れる演算コードである。 これを第373図に示す。 A10−9.アドレッシングモード対応 各命令のオペランドと、禁止されているアドレッシン
グモードモードとの対応を第374図に示す。 ○の組み合わせに対しては、そのアドレッシングモー
ドモードが使用可能である。 ×の組み合わせに対しては、それを実行しようとした
場合に予約命令以外(RIE)が発生する。 付録11.高機能命令の詳細仕様と終了時のレジスタ値 各命令の解説の項では、高機能命令の詳細や終了時の
レジスタ値について明確に述べられていないので、ここ
でまとめて説明を行なう。 A11−1.高機能命令の仕様決定の方針 SMOV/B,SCMP/B,BVMAP/B,BVCPY/Bでは、@−SPとの対
応などからプリデクリメントの形で処理を行なうという
考え方と、SMOV/F,SSCH/Rなどとの整合性からポストデ
クリメントの形で処理を行なうという考え方とがある。
例えば、H'100〜H'1ffの領域をSMOV/B.Bによって転送す
る場合、SMOV/Bがプリデクリメントの仕様であればレジ
スタの初期値はH'200となるし、SMOV/Bがポストデクリ
メントの仕様であればレジスタの初期値はH'1ffとな
る。 [ポストデクリメントのデメリット] SMOV/FとSMOV/B,SCMP/FとSCMP/Bとの対称性が悪くな
る。例えば、H'000000ffまでの領域を占めるストリング
に対してSMOV/Bを実行する場合、SMOV/B.Bであればポイ
ンタの初期値としてH'000000ffを設定し、SMOV/B.Wであ
ればポインタの初期値としてH'000000fcを設定する必要
がある。 [プリデクリメントのデメリット] SSCH,BSCHなどのサーチ系の命令との整合性が悪くな
る。もし、SSCH、命令終了後のポインタ最終値が必ず終
了条件成立のエレメント(サーチ結果のエレメント)を
指すという原則を設けるとすると、/F,/B,/Rといった処
理方向によってプリ更新/ポスト更新を変えることはで
きなくなる。したがって、/Bのみプリデクリメントとす
るわけにはいかない。(実際にはSSCH/Bは存在しない
が、BSCH/Bなどの仕様との関連がある) TRONCHIPでは、[ポストデクリメントのデメリット]
の方を重視し、SMOV/B,SCMP/Bではプリデクリメントの
仕様にする。 次に、SMOV,SCMP,SSCHが終了条件によって終了した場
合、ポインタの更新を行なってから命令を終了するか、
ポインタの更新前に命令を終了するか、という問題があ
る。 [ポインタの更新前に命令を終了するデメリット] エレメントサイズによって命令を終了する場合には、
ポインタの更新が行なわれ、ポインタが次のエレメント
(/Fの場合はまだ処理の終わっていないエレメント)を
指すようになってから命令を終了するので、その仕様と
は合わなくなる。つまり、終了条件が成立するかどうか
によってポインタを更新して良いかどうかの状況が変わ
るため、仕様がわかりにくくなる上、高速なインプリメ
ントが難しくなる。 また、SSCHで、サーチが成功してから連続して次のサ
ーチを行なう場合には、次のSSCH実行前に別命令でポイ
ンタの更新が必要になる。SMOV,SCMPでも同様である。 [ポインタの更新後に命令を終了するデメリット] 命令実行後のポインタ値が終了条件(サーチ条件)成
立のエレメントよりも進んでいるので、SSCH命令として
はすなおな仕様ではない。BVSCH,BSCH命令の仕様とも合
わない。 TRONCHIPでは、[ポインタの更新前に命令を終了する
デメリット]の方を重視し、終了条件成立の場合には、
ポインタの更新後に命令を終了するという仕様にする。
したがって、SMOV/F,SCMP/F,SSCH/F,/R命令終了後のポ
インタは、終了条件の成立したエレメントの次のエレメ
ントを指すことになる。また、SMOV/B,SCMP/B命令の場
合はプリデクリメントでポインタを更新するため、命令
終了後のポインタは終了条件の成立したエレメントを指
すことになる。 SMOV/B,SSCMP/Bとの仕様を合わせるという意味で、BV
MAP/B,BVCPY/Bの場合にも、演算の対象となるビットフ
ィールドの最大オフセット+1をR1,R4で指定する。 ただし、BVSCH,BSCHについては、命令終了後のビット
オフセットが直接サーチ対象のビットを指している方が
便利だと考えられるため、/F,/Bともそのような仕様に
する。また、QSCHについては、ポインタがプリ更新とな
っているため、SSCH,BSCHとはポインタ更新のタイミン
グが異なっている。結局、BSCH/F(BVSCH/F)SSCH.F,QS
CH/Fのサーチのパターンをまとめると、次のようにな
る。 BSCH/F 現在ポインタの指しているものからサーチす
る。 サーチ終了後のポインタは、見付かったデータを指
す。 SSCH/F 現在ポインタの指しているものからサーチす
る。 サーチ終了後のポインタは、見付かったデータの次を
指す。 QSCH/F 現在ポインタの指している次のものからサーチ
する。 サーチ終了後のポインタは、見付かったデータを指
す。 ストリング命令の場合、エレメント数R2は符号なしの
数として扱われる。これは、R2を符号なしと考えること
により、R2=0の指定によってエレメント数をH'100000
000と解釈し、エレメント数による終了を行なわないよ
うにできるためである。この機能は、言語Cのstrcmp関
数の実現などに利用できる。また、インプリメント上
も、R2を符号なしと考える方がエレメント数による終了
の判定が楽になる。 一方、ビットフィールド命令のwidthは、以下のよう
な理由により、固定長ビットフィールド命令、任意長ビ
ットフィールド命令とも符号付きとして扱うことにす
る。 ・命令実行時、ビットフィールド命令のwidthはoffset
に加算される形になるが、offsetは符号付きである。wi
dthを符合なしとすると、符合付きと符合なしの数を足
すことになり、すっきしない。 ストリング命令のエレメントサイズの場合は、サイズ
を乗じた上でポインタに加算するのであるから、符号な
しの方が自然である。 ・命令実行の上で符号付きか符号なしかの違いが出てく
るのは、任意長ビットフィールド命令でwidthがH'80000
000〜H'ffffffffの場合である。widthを符号付きとして
おけば、widthがこの値の時V_flagをセットするだけで
命令を終了するが、widthを符号なしとした場合には、w
idthがこの値の時もビットフィールド操作を行なうこと
になる。しかし、widthがH'80000000〜H'ffffffffだと
すると、offset+widthの値を符号付きとして扱う場合
には既にオーバーフローしているし、offset+widthを
符号なし(あるいは33ビット符号付き)として扱う場合
にも、offsetの値によってはオーバーフローする。オー
バーフローに関しては、「offset+widthがオーバーフ
ローした場合には動作を保証しない」となっているので
あるから、同じようなインプリメントをするのであれ
ば、widthを符号なしとしても「動作を保証しない」ケ
ースが増えるだけである。widthを符号なしとして、し
かもwidth>H'800000000の場合の動作を保証するのであ
れば、ハードウエアの負担を伴う。 ・ストリング命令の場合は、終了条件によって命令を終
了する場合があったため、エレメントサイズによる終了
をしたくない時に0を設定するという使い方がある。0
で無限大(H'100000000)を表現するには、どうしても
エレメントサイズを符号なしとして扱う必要があった。
これに対して、BVMAP,BVCPYではwidth以外に命令終了の
要素がないため、プログラミング上、widthとして必ず
意味のある値を設定することになる。その場合は、「レ
ジスタ上の値は原則として符号付きの数と考える」とい
う原則にあわせる方が自然である。 [ストリング命令、任意長ビットフィールド命令の基本
原則のまとめ] ・サーチ系の命令では、ポインタ更新のタイミングはサ
ーチ方向に依存しない。 BSCH,,BVSCHでは、/F,/Bともサーチ終了後のポインタ
は見付かったビットを指す。 SSCHでは、/F,/Rともサーチ終了後のポインタは見付
かったエレメントの次のエレメントを指す。 ・実際にデータを操作する命令では、/Fの場合にポスト
インクリメント、/Bの場合にプリデクリメントの形で処
理を行なう。 これに該当するのは、SMOV,SCMP,BVMAP,BVCPYであ
る。 SSTR,BVPATは/Fのみであるが、やはり同じ原則にあて
はまる。 ・ストリング命令では、エレメントサイズは符号なしと
して扱われ、'0'の場合はH'100000000を表わす。一方、
任意長ビットフィールド命令では、widthは符合付きと
して扱われ、widthがH'00000001〜H'7fffffffの場合に
のみ、実際のビットフィールド操作を行なう。 A11−2.ストリング命令の詳細仕様 SMOV SMOVのオペレーションをまとめると、次のようにな
る。ただし、最終的な結果が同じであれば、メモリアク
セスの順番が下記のものと異なっていても構わない(他
の高機能命令も同様)。また、srcとdestがオーバーラ
ップしていた時に、正しくない方のオプションを使用し
た場合(src<destで/Fを使用した場合、およびsrc>de
stで/Bを使用した場合)の動作も、下記の通りでなくて
もよい。 [SMOV/Fのオペレーション] [SMOV/Bのオペレーション] SMOVでは、R2の初期値が何であっても、かならず1個
以上のエレメントは処理される。SMOVの終了要因をまと
めると、次のようになる。 1.エレメント(データ)数(R2)による終了エレメント
数によって命令を終了した場合には、V−flag=1とな
る。2のケースとは同時には起こらない。 2.終了条件による終了 この時は、F−flag=1となる。終了条件を満足した
エレメントの転送も行なわれる。 SCMP SCMPでは、エレメント数による命令の終了と終了条件
による命令の終了のほかに、比較データの不一致によっ
て命令を終了することがある。SCMPでデータの不一致に
より命令を終了した場合にも、終了条件により命令を終
了した場合と同様に、ポインタの更新が行なわれてから
命令が終了する。SCMPでは、エレメント数による終了要
因と他の終了要因とが同時に発生することはないが、終
了条件とデータ不一致の終了要因が同時に満たされる可
能性はある。 SCMPがエレメント数によって終了した場合には、次の
エレメントの比較は行なわず、次のエレメントが不一致
または終了条件成立であってもV−flag=0,F−flag=
0,Z−flag=1として命令を終了する。 SCMPのオペレーションをまとめると、次のようにな
る。ただし、最終的な結果が同じであれば、メモリアク
セスの順番が下記のものと異なっていても構わない。こ
れと等価の動作をすればよい。 [SCMP/Fのオペレーション][SCMP/Bのオペレーション] SCMPの終了要因をまとめると、次のようになる。 1.エレメント(データ)数(R2)による終了 この時、Z−flag=1,F−flag=0,V−flag=1とな
る。2,3のケースとは同時には起こらない。 2.終了条件による終了 この時は、F−flag=1となる。終了条件を満足した
エレメントの比較も行なわれ、その比較結果がZ−fla
g,L−flag,X−flagに設定される。比較が不一致だった
場合は、2,3の2つの終了要因が同時に満たされたこと
に相当する。 3.比較中のエレメントの不一致による終了 この時は、不一致のあったエレメントの比較結果がZ
−flag(=0),L−flag,X−flagに設定される。V−fl
agは0となる。 SSCH SSCHが終了条件(検索条件)によって終了した場合に
は、/F,/Rとも、命令実行後のポインタは終了条件の成
立したエレメントの次のエレメントを指す。また、SSCH
がエレメント数によって終了した場合にも、命令実行後
のポインタは次のエレメントを指す。 SSCHのオペレーションをまとめると次のようになる。 [SSCH/Fのオペレーション] [SSCH/Rのオペレーション] SSCHの終了要因をまとめると、次のようになる。 1.エレメント(データ)数(R2)による終了 この時、V−flag=1となる。2のケースとは同時に
は起こらない。 2.終了条件(検索条件)による終了 この時はF−flag=1となる。 SSTR SSTRはフラグ変化は起こらない。SSTRのオペレーショ
ンをまとめると次のようになる。 [SSTRのオペレーション] A11−3.高機能命令終了時のレジスタ値 TRONCHIPで高機能命令を実行した場合、命令終了時の
各レジスタの値は次のようになる。なお、RXinitは命令
実行前のレジスタRXの値を示す。また、Rxendは命令実
行後のレジスタRXの値を示す。 [BVSCH] /Fの時は、オフセットがR1int〜R1init+R2init−1
の範囲をサーチする。 /Bの時は、オフセットがR1int〜R1init−R2init+1
の範囲をサーチする。 R2init(width)≦0の場合は、V−flagをセットし
て命令を終了する。 R1,R2は不変である。 サーチが成功した場合 R0(base address):不変 R1(offset):サーチ結果 見付かったビットのビットオフセット。 R2(width):まだサーチしていないビットフィールド
と見付かったビットとを合わせたビットフィールドの長
さ つまり、/FであればR2init+R1init−R1end,/Bであれ
ばR2init−R1init+R1endとなる。 サーチが失敗した場合 R0(base address):不変 R1(offset):最後にサーチサーチしたビットの次のビ
ットオフセット。 つまり、/FであればR1init+R2init,/BであればR1ini
t−R2initとなる。 これはBSCHと同じ考え方である。 R2(width):0 [BVMAP] [BVCPY] /Fの時は、R1init〜R1init+R2init−1のビットオフセ
ットを持つ領域がsrc,R4init〜R4init+R2init−1のビ
ットオフセットを持つ領域がdestとなる。 /Bの時は、R1init〜R1init−R2init+1のビットオフセ
ットを持つ領域がsrc,R4init−1〜R4init−R2initのビ
ットオフセットを持つ領域がdestとなる。 R2init(width)≦0の場合は、何もせずに命令を終了
する。 R1,R2,R4は不変である。 R0(src base):不変 R1(src offset):/FであればR1init+R1init,/Bであれ
ばR1init−R2initとなる。 R2(width):0 R3(dest base) 不変 R4(dest offset)/FであればR4init+R2init,/Bであれ
ばR4init−R2initとなる。 R5(演算の種類) 不変(BVMAPのみ) [BVPAT] R4init〜R4init+R2init−1のビットオフセットを持
つ領域がdestとなる。 R2init(width)≦0の場合は、何もせずに命令を終
了する。 R2,R4は不変である。 R0(pattern):不変 R2(width):0 R3(dest base) 不変 R4(dest offset)/R4init+R2init R5(演算の種類) 不変 〔SMOV〕 /Fの時は、 R0init〜R0init+R2init*エレメントサイズ−1のアド
レスを持つ領域がsrc, R1init〜R1init+R2init*エレメントサイズ−1のア
ドレスを持つ領域がdestとなる。 /Bの時は、 R0init−1〜R0init−R2init+1*エレメントサイズ
のアドレスを持つ領域がsrc、R1init−1〜R1init−R2i
nit*エレメントサイズのアドレスを持つ領域がdestと
なる。 例えば、H'0000〜H'00ffのストリングをH'0300〜H'03
ffに転送する場合、SMOV/F.Wでコピーすると、 R0=H'0000,R1=H'0300,R2=H'0040 SMOV/B.Wでコピーすると、 R0=H'0100,R1=H'0400,R2=H'0040とすればよい。 ただし、終了条件が成立した場合には、処理が途中で
打ち切られる。終了条件の成立したデータもdest側に転
送される。 エレメント数によって終了した場合 (V−flag=1) R0(src address):/FであればR0init+R2init*エレメ
ントサイズ、 /BであればR0init−R2init*エレメントサイズ R1(dest address):/FであればR1init+R2init*エレ
メントサイズ、 /BであればR1init−R2init*エレメントサイズ R2(エレメント数):0 R3(終了条件1):不変 R4(終了条件2):不変 −終了条件が成立して終了した場合(F−flag=1) R0(src address):/Fの時終了条件の成立したsrcのエ
レメントの次のエレメントのアドレス /Bの時終了条件の成立したsrcのエレメントのアドレス R1(dest address):/Fの時終了条件の成立したsrcのエ
レメントの次のエレメントを転送すべきdestのアドレス /Bの時終了条件の成立したsrcのエレメントを転送すべ
きdestのアドレス /F,/BともR1init+R0end−R0initとなる。 R2(エレメント数):まだ転送されていないエレメント
の数 /Fの時R2init−(R0end−R0init)/エレメントサイ
ズ、 /Bの時R2init−(R0init−R0end)/エレメントサイズ
となる。 R3(終了条件1):不変 R4(終了条件2):不変 [SCMP] /Fの時は、 R0init〜R0init+R2init*エレメントサイズ−1のア
ドレスを持つ領域がsrcl、 R1init〜R1init+2Rinit*エレメントサイズ−1のア
ドレスを持つ領域がsrc2となる。 /Bの時は、 R0init−1〜R0init−R2init*エレメントサイズのア
ドレスを持つ領域がsrcl、 R1init−1〜R1init−R2init*エレメントサイズのア
ドレスを持つ領域がsrc2となる。 例えば、H'0000〜H'00ffのストリングをH'0300〜H'03
ffのストリングとを比較する場合、 SCMP/F.Wで比較すると、 R0=H'0000,R1=H'0300,R2=H'0040 SCMP/B.Wで比較すると、 R0=H'0100,R1=H'0400,R2=H'0040 とすればよい。 ただし、終了条件が成立した場合には、処理が途中で
打ち切られる。終了条件の成立したエレメントについて
も比較が行なわれ、その結果がL−flag,X−flag,Z−fl
agにセットされる。また、比較中に不一致のエレメント
が見付かった場合にも、処理が途中で打ち切られる。 ‐エレメント数によって終了した場合 (V−flag=1) R0(srcl address):F/であればR0init+R2init*エレ
メントサイズ、 /BであればR0init−R2init*エレメントサイズ ただし、R2init<0の場合には無変化 R1(src2 address):/FであればR1init+R2init*エレ
メントサイズ、 /BであればR1init−R2init*エレメントサイズ R2(エレメント数):0 R3(終了条件1):不変 R4(終了条件2):不変 ‐終了条件の成立、またはエレメント値の不一致によっ
て終了した場合 (F−flag=1.or.Z−flag=0) R0(srcl address)/Fの時終了条件の成立した(または
不一致であった) srclのエレメントの次のエレメントのアドレス /Bの時終了条件の成立した(または不一致であった) srclのエレメントのアドレス R1(src2 address):/Fの時終了条件の成立した(また
は不一致であった) srclのエレメントの次のエレメントと対応するsrc2の
エレメントのアドレス /Bの時終了条件の成立した(または不一致であった) srclのエレメントと対応するsrc2のエレメントのアド
レス /F,/BともR1init+R0end−R0initとなる。 R2(エレメント数):まだ比較されていないエレメント
の数 /Fの時R2init−(R0end−R0init)/エレメントサイ
ズ、 /Bの時R2init−(R0init−R0end)/エレメントサイ
ズ、 となる。 R3(終了条件1):不変 R4(終了条件2):不変 [SSCH] /Fの時は、 R0init〜R0init+R2init*エレメントサイズ−1のア
ドレスを持つ領域を検索する。 /Rの時は、 R0init〜R0init+R5*R2init−1のアドレスを持つ領
域を、R5毎に飛び飛びに検索する。 ただし、終了条件(検索条件)が成立した場合には、
処理が途中で打ち切られる。 ‐エレメント数によって終了した場合 (V−flag=1) R0(src address):F/であればR0init+R2init*はエレ
メントサイズ、 /RであればR0init+R2init*R5 R2(エレメント数):0 R3(終了条件1):不変 R4(終了条件2):不変 R5(ポインタ更新値):不変 ‐終了条件(検索条件)が成立して終了した場合(F−
flag=1) R0(src address):終了条件の成立したsrcのエレメン
トのアドレス R2(エレメント数):終了条件の成立したエレメント
と、まだ検索されていないエレメントの合計数 /Fの時R2init−(R0end−R0init)/エレメントサイ
ズ、 /Rの時R2init−(R0end−R0init)/R5となる。 R3(終了条件1):不変 R4(終了条件2):不変 R5(ポインタ更新値):不変 [SSTR] R1init〜R1init+R2init*エレメントサイズ−1のア
ドレスを持つ領域に、R3で指定されるデータを繰り返し
書き込む。他のストリング命令とは異なり、終了条件の
指定は行なわない。また、フラグのセットも行なわな
い。 R2init(width)≦0の場合は、即座に命令を終了す
る。R1,R2は不変である。 R1(dest address):R1init+R2init*エレメントサイ
ズ R2(エレメント数):0 R3(書き込みデータ):不変 [QSCH] ‐キュー終了値(R2)によって終了した場合 (V−flag=1) R0(entry address):R2init R1(privious entry):R0endで示されるエントリの直前
(/Fの場合) または直後(/Bの場合)のエントリのアドレス R2(キュー終了値):不変 R3(終了条件1):不変 R4(終了条件2):不変 R5(オフセット):不変 R6(マスク):不変 ‐終了条件(検索条件)が成立して終了した場合(F=
flag=1) R0(entry address):終了条件の成立しているキュー
エントリのアドレス R1(privious entry):R0endで示されるエントリの直前
(/Fの場合) または直後(/Bの場合)のエントリのアドレス R2(キュー終了値):不変 R3(終了条件1):不変 R4(終了条件2):不変 R5(オフセット):不変 R6(マスク):不変 付録12.オペランドが干渉した場合の動作 一つの命令が複数のオペランドを持ち、その中で、@
SP+@SPモードとSPを参照するモードとを併用した場合
には、@SP+,@−SPモードによって行進されたSP値が
いつから反映されるかということが問題になる。この問
題をより一般的に考えると、オペランドが干渉していた
場合の動作を明確に規定すればよいということになる。 この試料は、本発明装置で、命令中のオペランドが干
渉を起こした場合に、その動作をきちんと定義すること
を目的としたものである。資料の最初の方でこの問題に
対する考え方を述べ、資料のこうせはんでは、実際に本
発明装置の動作の規定を行っている。 A12−1.命令実行モデル オペランド干渉の問題を解決するために、まず、各命
令からメモリやレジスタに対して行われるread,write,r
ead−modfy−writeの基本アクセス操作をすべて含むよ
うな仮想的な命令パターンを考え、それを以下のように
モデル化する。 ・モデルを構成するRA1〜WW1の夫々の要素を「ステッ
プ」と呼ぶ。 ・@SP+,@−SPのアドレッシングモードを指定した場
合、SP値の更新は「実効アドレス計算」のステップ(RA
1,RA2,RA3,MA1,WA1)で行われるものとする。 ・各ステップは、次のいずれかのパターンでリソースを
アクセスする。ただし、「リソース」とはメモリまたは
プログラムから見えるレジスタを指す。 ‐リソースアクセスなし ‐一つまたは複数のリソースからのread ‐一つのリソースへのwrite(EX1〜EXn,MW1,WW1のみ) ‐リソースSPのread−modify−write(RA1,RA2,RA3,MA
3,WA1,WA2) ・各ステップでリソースの値の更新があった場合には、
次のステップから更新された値が反映される。 ・一般の命令では、このうち一部のステップのみが存在
する。 ・EX1〜EXnのステップは、実際には、命令の種類によっ
てEX1,EX2,EX3…のいくつかのステップに分かれてい
る。 上記のモデルでは、各ステップで書き込みを行なうリ
ソースが高々一つであること、SPのread modify−write
のケースを除けば、一つのステップ内でreadとwriteが
混在するケースはないこと、リソースに書き込んだ値が
次のステップから反映されること、といった条件を明ら
かにしているので、ステップ間で共通のオペランドをア
クセスした場合にも動作は明確に規定される。したがっ
て、各命令の動作を上記のモデルにうまく当てはめるこ
とができれば、オペランドが重なっていた場合の動作も
きちんと規定することができる。 本発明装置のほとんどの命令の動作は、上記の実効パ
ターンのサブセットとして成り立っている。ただしどの
動作がどのステップに対応するかということについて
は、命令動作の意味付けによっていろいろな解釈ができ
る。 例えばACB:G @SP+,SP,@SP+,newpcの場合には、次
ののような解釈をするのが自然である。つまり、ACB
命令の各動作ステップやオペランドと、上記のモデルと
の対応は、次ののように行なうのが普通であり、実
際、これが正しいTRON仕様となっている。 ACBのSTEPオペランドがモデルのR01に対応ACBのLIMIT
オペランドがモデルのR02に対応xregオペランドはEX1〜
EX3の中だけで扱い、R0n,M0n,W0nとは考えない。 roladdr,ro2addr,step,limit xregは内部変数であ
り、モデルで使用する意味での「リソース」には含めな
い この場合、命令実行前のSP値をinitSPとすると、 step: @(initSP) xreg初期値: initSP+size*2 limit: @(initSP|size) EXの後のxreg: initSP+size*2+@(initSP) ジャンプ条件: initSP+size*2+@(initSP)<@
(initSP+size) SP最終値: initSP+size*2+@(initSP) しかし、実際のACB命令の動作とモデルとの対応を次
ののようにすることも不可能ではない。 の動作は、厳密にはと同じではない。 ACBのstepオペランドがモデルのR01に対応 ACBのxregオペランドが読みだし時R02に、書き込み時
W01に対応 ACBのlimitオペランドがモデルのR03に対応‐roladdr,ro3addr,step,limit,xregは内部変数であ
り、モデルで使用する意味での「リソース」には含めな
い この場合、命令実行前のSP値をinitSPとすると、 step: @(initSP) xreg初期値: initSP+size limit: @(initSP+size) EXの後のxreg: initSP+size+@(initSP) ジャンプ条件:initSP+size+@(initSP)<@(init
SP+size) SP最終値: initSP+size+@(initSP) これはとは異なる動作である。 仕様書の命令の解説の項だけではが正しいかが正
しいかは厳密にはわからないため、命令によっては、モ
デルとの対応付けの曖昧な場合が出てくる。モデルとの
対応付けが違うと、上の例のように細かい動作が異なっ
てくることがある。 この資料では本発明装置の命令について、上記のよう
な方法で命令動作とモデルとの対応を決め手いくことに
より、オペランドが重なった場合の動作を明確に規定す
ることを目的としている。 A12−2.基本原則 命令について個別に検討する前に、オペランドの干渉
についての基本原則を述べる。 (原則1)短縮形と一般形では、全く同じ動作をしなけ
ればならない。すなわち、命令フォーマットの違いはオ
ペランド干渉の問題には影響しない。短縮形は完全に一
般形のサブセットとなるべきであり、動作の異なる短縮
形は混乱を招く。 命令実行モデルは、インプリメントへの依存性やイン
プリメントの都合を考えたものではないため、場合によ
っては、規定した通りにインプリメントできないことが
ある。例えば、ADD:L @SP+,SPがADD:G @SP+,SPと異
なった動作をする場合があるというのは、この例であ
る。このようなケースに関しては、命令実行モデルの方
はそのままにしておき、場合に応じて例外として扱う。 (原則2)基本的には、命令ビットパターンの中でのオ
ペランドの出現順序にしたがて、命令のオペランドとモ
デルでの第一readオペランド(R01)、第二readオペラ
ンド(R02)…との対応を決める。 こうしておけば、一般にはインゾリメント方法とも矛
盾しない。 命令実行モデルは、各命令の動作とビットパターンか
ら考えて、最も自然な形になるようにする。短縮形と一
般形を持つ命令の場合、命令実行モデルと実際の命令動
作との対応が自然になるかどうかは、どのフォーマット
の命令ビットパターンを基準にするかによって異なる
が、この場合は減速として一般形を基準にする。命令動
作とモデルとの対応という点に関しては、命令ビットパ
ターンの都合は考えるが、インプリメントの都合は特に
考えない。 (原則3)原則2があっても、汎用アドレッシングでな
いオペランド(ACBのxregなど)については、モデルで
の第n-readオペランド(R0n)、第m−writeオペランド
(W0m)としては扱わず、EXのステップ中だけで扱うの
が普通である。 (原則4)また、命令の意味の中に暗黙に含まれている
メモリアクセス(PUSH,POPでのスタック操作など)につ
いても、モデルでの第n−readオペランド(R0n)、第
m−writeオペランド(W0m)としては扱わず、EXのステ
ップ中だけで扱うのが普通である。 さらに、各命令ごとに特殊な事情のある場合や、多数
のオペランドを持つ場合(LDM,STMなど)には、これら
の原則が当てはまらないことがある。詳しくは命令ごと
に検討する。 A12−3.各命令での実際 本発明装置の命令をいくつかのパターンに分類してモ
デルとの対応付けを行ない、オペランドが緩衝した場合
の動作を明確にする。(原則1)により、命令フォーマ
ットが違ってもオペランドが干渉した場合の動作は替わ
らないので、命令フォーマットの違いによる場合分けを
行なう必要はない。 なお、動作例の中に出てくるinitSPは、命令実行前の
SPの意味である。また、動作例で出てくる命令のオペラ
ンドサイズは、断わりのない限りすべて32ビットとす
る。 は値の代入を、’〔〜〕’はコメントを示す。RA1〜WW1
のステップのうち、その命令で使用していないステップ
については、説明を省略してある。 Oオペランド(N) 該当命令: NOP PIB RTS RRNG TRAP REIT STCTX PTLB BVSCH BVMAP BVCPV BVPAT SMOV SCMP SSCH SSTR QSCH 命令の動作は、すべてモデルのEXのステップだけで行
なわれ、それ以外の部分は存在しない。したがって、オ
ペランドの干渉については特に問題とはならない。 高機能命令では、EXのステップ数が有限とはならない
場合も生じるため、このモデルでは正確に表現できない
ことがある。しかし、これはオペランドの干渉の問題に
は直接官界しないので、ここでは議論しない。 〔命令実行モデルとオペランドとの対応〕 EX.命令固有の動作 1オペランドイミディエート(1) 当該命令: BRA newpc Bcc newpc BSR newpc TRAPA vector WAIT imask オペランドを一つもつが、オペランドの値は命令コー
ド中で直接指定されるため、オペランドの干渉について
は問題とならない。newpc,vector,imaskはEXのステップ
で操作すると考える。 〔命令実行モデルとオペランドとの対応〕 EX.命令固有の動作(newpc,vector,imaskの参照を含
む) 1オペランドread(R) 該当命令: PUSH src LDPSB src LDPSM src JRNG vector このパターンの命令の場合、src,vectorをモデルの第
一readオペランド(R01)として扱う。 src=@SP+の場合、命令固有の動作を行なう時点で
は、既にSPのインクリメントが行なわれていることにな
る。 〔命令実行モデルとオペランドとの対応〕 例えばPUSH@SP+にこのモデルを適用すると、EXでPU
SH命令固有の動作(src==>@−SP)を行なう前に、R
A1.で既にsrc−@SP+によるSPの更新が行われることが
わかる。ただし、間違いを防ぐため、PUSH@SP+は禁止
(RIE)となっている(第375図参照)。 1オペランドaddress(A) 該当命令: PUSHA srcaddr PSTLB prgaddr LDCTX ctxaddr ACS chkaddr JMP newpc JSR newpc srcaddr,prgaddr,ctxaddr,chkaddr,newpcをモデルの
第一addressオペランド(AO1)として扱う。なお、AA1
では@SP+,@−SPのモードは利用できない。 〔命令実行モデルとオペランドとの対応〕 PUSHA @SPとJSR @SPの動作は第376図のとおり。 1オペランドwrite(W) 該当命令: POP dest STPSB dest STPSM dest destを第一writeオペランド(W01)として扱う。この
場合、EXのステップより前のWA1のステップでdestの実
効アドレス計算が行なわれ、値の書き込みのみEXより後
のWW1のステップで行なわれることになる。 〔命令実効モデルとオペランドとの対応〕 例えばPOP @−SPにこのモデルを適用すると、EX.でP
OP命令固有の動作 を行なう前に、WA1.で既にdest=@−SPによるSPの更新
が行なわれることがわかる。また、POP @(d,SP)にこ
のモデルを適用すると、EX.でPOP命令固有の動作 を行なう前に、WA1.でdest=@(d,SP)のアドレス計算
が行なわれ、destのアドレス計算にはinitSPが使用され
ることがわかる。 ただし、間違いを防ぐため、実際にはPOP @SPは禁止
(RIE)となっている。また、POP @(d,SP)について
は、@(d,Rn)のアドレッシングモードでRn=SPの時の
み実行禁止とするのは無理があること、スタック操作に
おいてPOP @(disp,SP)を使用する用途も考えられる
こと、により、禁止にはしていない。 POP命令の動作例は第377図のようになる。 1オペランドrmw(M) 該当命令: NEG dest NOT dest SHXL dest SHXR dest destをM01に対応させる。この場合、MA1で@SP+,@
−SPを指定することはできない。 〔命令実行モデルとオペランドとの対応〕 2オペランドread〜write(RW) 該当命令: MOV src,dest MOVU src,dest RVBY src,dest RVBI src,dest PACKss src,dest UNPKss src,dest,adj srcをR01、destをW01に対応させる。したがって、src
側の実効アドレス計算とそれに伴うSPの更新がすべて終
わってからsrcのフエッチを行ない、その後dest側の実
効アドレス計算を行ない、最後に命令固有の動作を行っ
て結果をdestにセットする。 UNPKssのadjはEXのステップで扱い、第n readオペラ
ンドとはしない。 〔命令実行モデルとオペランドとの対応〕 MOVの動作例は第378図のとおり。 PACK,UNPKの動作例は第379図のとおり。 2オペランドaddress〜write(AW) 該当命令: STC src,dest STP src,dest MOVA srcaddr,dest MOVPA srcaddr,dest STATE srcaddr,dest QDEL queue,dest 制御空間、物理空間など特殊な空間からの読みだしを
行なう命令では、特殊空間側の実効アドレスsrc,srcadd
rをAO1として扱い、特殊空間の実際のアクセスはEXのス
テップで行なう。また、QDEL命令でも、キューエントリ
を指定する側の実効アドレスqueueをAO1として扱い、キ
ューリンクの実際の操作はEXのステップで行なう。こう
しておけば、命令ビットパターンやインプリント方法と
もうまく対応する。AA1では、@SP+,@−SPを指定す
ることはできない。 destはW01として扱う。 STC,MOVAの動作例との対応は第380図のとおり。 mova @SP,@−SPの場合、srcaddrの実効アドレス計
算(AA1)のステップで既にSPが参照されており、dest
の実効アドレス計算(WA1)ステップにおけるSPの更新
はsrcaddrに反映されない。これに対して、STC @sp0,
@−SPがモデル通りの動作をするものと考えると、src
の実効アドレス計算(AA1)のステップではまだSPが参
照されておらず、制御レジスタとしてのSPのアドレス
(H'0124)が計算されるだけである。SPが参照されるの
はEXのステップであり、これはdestの実効アドレス計算
(WA1)ステップにおいてSPを更新した後である。した
がって、initSP−4がdestに転送されることになる。 ただし、STC @sp0,@−SPの動作については、以上の
ようなモデル通りの動作をするかどうかがインプリメン
ト依存になっている。つまり、モデル通りinitSP−4を
転送する場合と、モデルにた4いしては例外の扱いとな
るが、initSPを転送する場合とがある。 2オペランドread〜address(RA) 該当命令: LDC src,dest LDP src,dest LDATE src,destaddr BTST offset,base BSET offset,base BCLR offset,base BNOT offset,base BSETI offset,base BCLRI offset,base BFEXT offset,width,base,dest BFEXTU offset,width,base,dest BFINS src,offset,width,base BFINSU src,offset,width,base BFCMP src,offset,width,base BFCMPU src,offset,width,base CHK bound,index,xreg 制御空間、物理空間など特殊な空間への書き込みを行
なう命令LDC,LDP,LDATEでは、特殊空間側の実効アドレ
ス縦,destaddrをAO1、srcをR01として扱う。特殊空間の
実際のアクセスはEXで行なう。 ビット操作命令では、baseの実効アドレスをAO1、off
setをR01として扱う。baseとoffsetの合成を行ない、操
作対象となるビットを実際にアクセスするのは、EXの中
で行なわれる。固定長ビットフィールド操作命令でも、
ビット操作命令と同様に、baseの実効アドレスをAO1、o
ffsetをR01として扱う。offsetとbase以外のオペラン
ド、即ちwidth,src,destについては、EXの中でのみアク
セスし、第一readオペランド(R0n),第m−readオペ
ランド(W0m)としては扱わない。 CHKの場合は、ビットパターンとの関係から、indexを
R01、boundをAO1として扱い、boundの内容である(上限
値:下限値)の読みだしとxregへの書き込みはEXで行な
うことにする。 以上のような形で各命令の動作とモデルとの対応をつ
けておけば、命令ビットパターンやインプリメント方法
とも矛盾しない。 AA1では、@SP+を指定することはできない。src,off
set,index=@SP+の場合、dest,destaddr,base,bound
の実効アドレス計算で参照されるSP値としては、インク
リメント後の値が使用されることになる。CHK命令の場
合、これはアセンブラ表記でも順序と逆になっているの
で、注意が必要である。また、固定長ビットフィールド
命令でoffset=@SP+を指定し、src,widthなどで同じS
Pを指定した場合のSP値としては、やはりインクリメン
ト後の値が使用されることになる。アセンブラ表記で
は、BFINS,BFCMPの場合にoffsetよりもsrcの方が先に書
かれるようになっているが、実際にはoffsetの実効アド
レス計算で更新されたSPがsrcに反映されるので、注意
が必要である。 BFINS,BFEXTの動作例は第381図のとおり。 2オペランドread〜read(RR) 該当命令: CMP srcl,src2 CMPU srcl,src2 INDEX indexsize,subscript,xreg ACB step,xreg,limit,newpc SCB step,xreg,limit,newpc CMP,CMPUでは、srclをR01に、src2をR02に対応させ
る。 INDEXでは、indexsizeをR01に、subsriptをR02に対応
させる。xregはEXで扱う。 ACB,SCBではstepをR01に、limitをR02に対応させる。
xreg,newpcはEXで扱う。 したがって、srcl,indexsize,step=@SP+の場合、s
rc2,subscript,limitの実効アドレス計算で参照されるS
Pとしては、インクリメント後の値が使用される。ま
た、INDEX,ACB,SCB命令でindexsize,step=@SP+また
はsubscript,limit=@SP+の場合、xregとして参照さ
れるSPとしては、やはりインクリメント後の値が使用さ
れる。 CMPの動作例は第382図のとおり。 INDEXの動作例は第383図のとおり。 ただし、INDEX命令については、インプリメントの制
約によって、subscript=@SP+,xreg=SPの場合に必ず
しもモデル通りの動作ができない場合がある。詳しくは
2オペランドreadrmw(RM)の項を参照。 ACB,SCBの動作例は第384図のとおり。 2オペランドread〜rmw(RM) 該当命令: ADD src,dest ADDU src,dest ADDX src,dest SUB src,dest SUBU src,dest SUBX src,dest MUL src,dest MULU src,dest DIV src,dest DIVU src,dest REM src,dest REMU src,dest AND src,dest OR src,dest XOR src,dest SHA count,dest SHL count,dest ROT count,dest ADDDX src,dest SUBDX src,dest BSCH data,offset MULX src,dest,tmp DIVX src,dest,tmp src,count,dataをR01に、dest,offsetをM01に対応さ
せる。src=@SP+の場合、destの実効アドレス計算で
参照されるSPとしては、インクリメント後の値が使用さ
れる。 MA1では、@SP+,@−SPのモードを指定することは
できない。 MULX,DIVXの場合、srcがR01、destがM01に対応し、tm
pはEXの中で処理されるものとする。したがって、src=
@SP+の場合に、destの実効アドレス計算で参照される
SP値、およびtmpで参照されるSP値としては、インクリ
メント後の値が使用される。また、tmpとdestで同じレ
ジスタを指定した場合には、tmpの値が消え、最終的にd
estの値が残ることになる。 ADDの動作例は第385図のとおり。 このうち、一つのハーフワードの中で、レジスタ指定
RgR,RgMと汎用アドレッシング指定EaR,EaW,ShR,ShWの両
方を含む命令では、EaR,EaW,ShR,ShWで@SP+,@−SP
のモードを指定し、RgR,RgMでSPを指定した場合に、Ea
R,EaW,ShR、ShWによるSP値の更新がRgR,RgMとしてのSP
の読みだし値に影響するため、パイプライン実装が難し
いという意見がある。具体的に問題となるのは、以下の
ような命令である。 ADD:L @SP+,SP SUB:L @SP+,SP CMP:L @SP+,SP INDEX *,@SP+,SP (M0V:Lは含まない) そこで、これらの命令については、動作がインプリメ
ント依存になるものとする。つまり、ADD:L @SP+,SP
実行後のSP値は、インプリメントによって不定の値をと
るということにする。 EITの検出も難しいのず、EITとはしない。これらの命
令は、短縮形が一般形と同じ動作をするという原則には
違反することになる。 2オペランドaddress〜address(AA) 該当命令: QINS entry,queue entryをAO1に、queueをAO2に対応させる。キューリン
クの実際の操作はEXのステップで行なわれる。2オペランドaddress〜read(AR) 該当命令: CSI comp,update,dest CSI命令では、ビットパターンとの関係から、destをA
O1に、updateをR01に対応させるcompのアクセスと比
較、交換の実際の操作は、EXで行なわれる。 CSI命令のオペランドの処理は、アセンブラ表記とは
異なり、updateの実効アドレス計算、destの実効アドレ
ス計算、comp値の参照といった順序で行なわれる。dest
では@SP+,@−SPが使用できないが、updateでは@SP
+が使用できるので、compでSPを参照した場合には注意
が必要である。 CSIの動作例は第386図のとおり。 1オペランドread〜reglist(RL) 該当命令: ENTER local,reglist EXITD reglist,adjsp ENTER,EXITDでは、local,adjspをR01に対応させる。r
eglistの参照とスタックフレームの操作は、EXのステッ
プに含める。したがって、local,adjspの実効アドレス
計算の際に参照されるSP,FP,R0〜R13は、スタックフレ
ーム操作を初めてからの値ではなく、すべて命令実行前
の値を使用することになる。EXITDでは、アセンブラ表
記でのオペランド順と逆の順番で実効アドレスが評価さ
れるので、注意が必要である。 (ただし、命令再実行の関係で、local,adjspはレジ
スタ直接Rnとイミディエート#imm_dataのモードした使
用できない。)1オペランドaddress〜reglist(AL)★ 該当命令: LDM src,reglist STM reglist,dest LDM,STMでは、src,destをA01に対応させる。reglist
の参照と実際のレジスタ転送は、EXのステップに含め
る。したがって、src,destの実効アドレス計算の際に参
照されるSP,FP,R0〜R13は、レジスタ転送を始めてから
の値ではなく、すべて命令実効前の値を使用することに
なる。 LDM reglist,@SP+とSTM reglist,@−SPについて
は、SPが複数回更新されるため、一般命令での@SP+,
@−SPとは異なった扱いをする必要がある。すなわち、
モデルの「実効アドレス計算」のステップで@SP+,@
−SPによるSP値の更新を扱うのではなく、EXのステップ
でSP値の更新を扱うようにする。このため、SPをM01に
対応させる。 〔@SP+,@−SP以外のモードを使用した場合〕〔@SP+,@−SPのモードを使用した場合〕 LDM @SP+,reglist,の場合、reglist中にSPが指定さ
れていても、最後のMW1のステップでtmpaddrがSPにover
writeされるため、結果的にメモリからロードされたSP
値が消えてしまうことになる。LDM,STMの動作例は第387
図のとおり。 付録13.キャッシュやTLBの整合性確保について キャッシュやTLBの整合性の確保については、それぞ
れ関連する命令のところで説明を行なっているが、整理
すると以下のようになる。 〔ATを変更した場合の整合性〕 ・TLB,論理キャッシュ(データキャッシュ)の整合性 −LDC,LDCTX,EIT,REITによりPSWの中のATが変更された
場合、TLB,論理データキャッシュの整合性が保証され
る。(LSIDがない場合はバージされる。LSIDがある場
合、AT=00の物理空間に対して特別のLSIDを与えると考
えれば、必ずしもパージする必要はない。) ・命令パイプライン、命令キャッシュの整合性 −命令コード整合性の状態は変化しない。 ATを変更しても、命令コード整合性が保証されるわけ
ではない。 〔UATB,SATBの操作をした場合の整合性〕 ・TLB,論理キャッシュ(データキャッシュ)の整合性 −LDC,LDCTXによるUATB,SATBの操作では、TLB,論理デー
タキャッシュの整合性が保証される。(LSIDがない場
合、一般にはパージされる) ・命令パイプライン、命令キャッシュの整合性 −LDC,LDCTXによるUATB,SATBを操作しても、命令コード
整合性の状態は変化しない。インプリメントによって
は、命令キャッシュのパージによって命令コード整合性
が良くなる場合もあるが、それが保証されているわけで
はない。 例えば、論理空間A,論理空間Bの命令コードをそれぞ
れ書き換えた後、論理空間AでPIB命令を実行すると、
論理空間Aでの命令コード整合性は保証される。この後
LDCまたはLDCTXでUATBを操作し、論理空間Bに切り換え
たとしても、論理空間Bでの命令コード整合性は保証さ
れず、それを保証するためには論理空間Bでもう一度PI
B命令を実行する必要がある。ただし、論理空間BでPIB
命令を実行してもしなくても、再度UATBを操作して論理
空間Aに戻ってきた場合には、命令コードの整合性が保
証されている。 実際には、論理命令キャッシュのパージにより、UATB
操作の後は自動的に命令コード整合性が保証されるかも
しれないが、プログラミング上はこの機能を当てにして
はいけない。将来LSIDを導入してパージを避けることを
考えると、一般には、UATBを操作しても命令コード整合
性は変わらないと考えなければならない。 〔ATEの操作をした場合の整合性〕 ・TLB,論理キャッシュ(データキャッシュ)の整合性 −LDATEによるATEの操作では、TLB,論理データキャッシ
ュの整合性が保証される。(影響のある部分がパージさ
れる) −LDATEを用いず、一般のメモリアクセス命令でATEに使
用しているメモリ領域を書き換えた場合には、TLB,論理
データキャッシュの整合性は保証されない。 ・命令パイプライン、命令キャッシュの整合性 −ATEを更新した場合、そのATEによりアドレス変換され
る領域の「命令コードの整合性」は失われる。つまり、
その領域のメモリ内容をプログラムとして実行しても、
動作は保証されない。これは、LDATE命令を用いるかど
うかには関係しない。命令コードの整合性を回復する必
要があれば、別にPIB命令を実行する。 〔メモリの操作をした場合の整合性〕 ・論理キャッシュ(データキャッシュ)の整合性 −論理アドレスによってメモリをアクセスする場合に
は、論理データキャッシュの整合性が保証される。(キ
ャッシュの制御機構による) −LDP命令を使って、物理アドレスによりメモリアクセ
スする場合には、論理データキャッシュの整合性は保証
されない。 ・命令パイプライン、命令キャッシュの整合性 −メモリ内容を変更した場合、その領域の「命令コード
の整合性」は失われる。これは、論理アドレスによるア
クセスか物理アドレスによるアクセスかということには
関係しない。内容を変更したメモリをプログラムとして
実行するには、PIB命令を実行し、命令コードの整合性
を回復する必要がある。 [発明の効果] 以上の如き本発明装置による場合は、前述の従来装置
と異なり、「第390図の例では、 (1)PがレジスタR0上にある場合には、 @(R0,2,R1,*4) のように表現でき、 (2)Pが大域変数である場合には、 @(@(O,P),2,R1*4) のように表現できる。 さらに、 (3)Pが局所的変数であり、現在のフレーム・ポイン
タからディスプレイスメントdispの位置にある場合に
は、 @(@(R14,disp),2,R1*4) のように表現できる。 このように、本発明では、アドレス計算のための不要
な命令を実行することなく、容易にオペランドが参照で
きるデータ処理装置が得られる。また、コンパイラの構
成が容易となる。そして本発明の命令形式では、ベース
・アドレス指定を行なうフィールドがオペランドが先頭
に設けられ、アドレス修飾拡張はこのベースアドレスに
対して修飾するようにしているのでオペランドを調べな
がら順次アドレス計算を行えるのである。 そして本発明においては付加モード指定フィールドの
中で次の付加モード指定フィールドの有無を指定するの
で数の制限なしにこのフィールドを指すことができ、し
かもカウンタ等を用いることなく、その制御が可能であ
る。また各フィールドごとにアドレッシングモードを指
定できるので複雑なアドレッシングモードを容易に実現
できる。
【図面の簡単な説明】 第1図は、本発明装置のレジスタセット説明図 第2図は、本発明装置のビットについてのデータタイプ
説明図 第3図は、本発明装置のビットフイールドについてのデ
ータタイプの説明図 第4図は、本発明装置の符号なしビットフィールドにつ
いてのデータタイプ説明図 第5図は、本発明装置の整数についてのデータタイプ説
明図 第6図は、本発明装置の10進数についてのデータタイプ
説明図 第7図は、本発明装置のストリングについてのデータタ
イプ説明図 第8図は、本発明装置のキューについてのデータタイプ
説明図 第9図は、本発明装置の命令フォーマットの記述例を示
す説明図 第10図は、そのビットパターン図 第11〜21図は、本発明装置の命令フォーマット図 第22〜33図は、本発明装置のアドレッシングモードのフ
ォーマット図 第34図は、本発明装置のローカル変数配置例の説明図 第35〜38図は、本発明装置のアドレッシングモードのフ
ォーマット図 第39図は、命令MOVでの注意事項説明図 第40図は、PSWのフォーマット図 第41図は、PSSのフォーマット図 第42図は、PSHのフォーマット図、 第43図は、命令セットの記述例を示すフォーマット図 第44図は、命令MOVのフォーマット図及びそのフラグ変
化の説明図 第45図は、命令MOVUのフォーマット図 第46図は、そのフラグ変化の説明図 第47図は、命令PUSHのフォーマット図 第48図は、そのフラグ変化の説明図 第49図は、命令POPのフォーマット図 第50図は、そのフラグ変化の説明図 第51図は、命令LDMのフォーマット図 第52図は、そのフラグ変化の説明図 第53図は、ビットマップ指定の説明図 第54図は、命令STMのフォーマット図 第55図は、そのフラグ変化の説明図 第56,57図は、ビットマップ指定の説明図 第58図は、命令MOVAのフォーマット図 第59図は、そのフラグ変化の説明図 第60図は、命令PUSHAのフォーマット図 第61図は、そのフラグ変化の説明図 第62図は、命令CMPのフォーマット図 第63図は、そのフラグ変化の説明図 第64図は、命令CMPUのフォーマット図 第65図は、そのフラグ変化の説明図 第66図は、命令CHKのフォーマット図 第67図は、そのフラグ変化の説明図 第68図は、命令CHKのオペレーションの説明図 第69図は、命令ADDのフォーマット図 第70図は、そのフラグ変化の説明図 第71図は、命令ADDUのフォーマット図 第72図は、そのフラグ変化の説明図 第73図は、命令ADDXのフォーマット図 第74図は、そのフラグ変化の説明図 第75図は、命令SUBのフォーマット図 第76図は、そのフラグ変化の説明図 第77図は、命令SUBUのフォーマット図 第78図は、そのフラグ変化の説明図 第79図は、命令SUBXのフォーマット図 第80図は、そのフラグ変化の説明図 第81図は、命令MULのフォーマット図 第82図は、そのフラグ変化の説明図 第83図は、命令MULUのフォーマット図 第84図は、そのフラグ変化の説明図 第85図は、命令MULXのフォーマット図 第86図は、そのフラグ変化の説明図 第87図は、命令DIVのフォーマット図 第88図は、そのフラグ変化の説明図 第89図は、命令DIVUのフォーマット図 第90図は、そのフラグ変化の説明図 第91図は、命令DIVXのフォーマット図 第92図は、そのフラグ変化の説明図 第93図は、命令REMのフォーマット図 第94図は、そのフラグ変化の説明図 第95図は、命令REMUのフォーマット図 第96図は、そのフラグ変化の説明図 第97図は、命令NEGのフォーマット図 第98図は、そのフラグ変化の説明図 第99図は、命令INDEXのフォーマット図 第100図は、そのフラグ変化の説明図 第101図は、命令ANDのフォーマット図 第102図は、そのフラグ変化の説明図 第103図は、命令ORのフォーマット図 第104図は、そのフラグ変化の説明図 第105図は、命令XORのフォーマット図 第106図は、そのフラグ変化の説明図 第107図は、命令NOTのフォーマット図 第108図は、そのフラグ変化の説明図 第109図は、命令SHAのフォーマット図 第110図は、そのフラグ変化の説明図 第111図は、左シフトの説明図 第112図は、右シフトの説明図 第113図は、命令SHLのフォーマット図 第114図は、そのフラグ変化の説明図 第115図は、左シフトの説明図 第116図は、右シフトの説明図 第117図は、命令ROTのフォーマット図 第118図は、そのフラグ変化の説明図 第119図は、左回転の説明図 第120図は、右回転の説明図 第121図は、命令SHXLのフォーマット図 第122図は、そのフラグ変化の説明図 第123図は、命令XHXLのフォーマット図 第124図は、命令XHXRのフォーマット図 第125図は、そのフラグ変化の説明図 第126図は、命令SHXRのフォーマット図 第127図は、命令RVBYのフォーマット図 第128図は、そのフラグ変化の説明図 第129図は、命令RVBIのフォーマット図 第130図は、そのフラグ変化の説明図 第131,132図は、ビット操作命令の説明図 第133図は、命令BTSTのフォーマット図 第134図は、そのフラグ変化の説明図 第135図は、命令BSETのフォーマット図 第136図は、そのフラグ変化の説明図 第137図は、命令BCLRのフォーマット図 第138図は、そのフラグ変化の説明図 第139図は、命令BNOTのフォーマット図 第140図は、そのフラグ変化の説明図 第141図は、命令BSCHのフォーマット図 第142図は、そのフラグ変化の説明図 第143図は、固定長ビットフィールド操作命令の説明図 第144図は、ビットフィールド命令のフォーマット図 第145図は、命令BFEXTのフォーマット図 第146図は、そのフラグ変化の説明図 第147図は、命令BFEXTUのフォーマット図 第148図は、そのフラグ変化の説明図 第149図は、命令BFINSのフォーマット図 第150図は、そのフラグ変化の説明図 第151図は、命令BFINSUのフォーマット図 第152図は、そのフラグ変化の説明図 第153図は、命令BFCMPのフォーマット図 第154図は、そのフラグ変化の説明図 第155図は、命令BFCMPUのフォーマット図 第156図は、そのフラグ変化の説明図 第157図は、命令BVSCHのフォーマット図 第158図は、そのフラグ変化の説明図 第159図は、命令BVMAPのフォーマット図 第160図は、そのフラグ変化の説明図 第161〜163図は、命令BVMAPのフォーマット図 第164図は、命令BVCPYのフォーマット図 第165図は、そのフラグ変化の説明図 第166図は、命令BVPATのフォーマット図 第167図は、そのフラグ変化の説明図 第168図は、命令ADDDXのフォーマット図 第169図は、そのフラグ変化の説明図 第170図は、命令SUBDXのフォーマット図 第171図は、そのフラグ変化の説明図 第172図は、命令PACKssのフォーマット図 第173図は、そのフラグ変化の説明図 第174図は、命令UNPKssのフォーマット図 第175図は、そのフラグ変化の説明図 第176図は、命令UNPKssの説明図 第177図は、命令SMOVのフォーマット図 第178図は、そのフラグ変化の説明図 第179図は、命令SCMPの説明図 第180,181図は、そのフラグ変化の説明図 第182図は、命令SSCHのフォーマット図 第183図は、そのフラグ変化の説明図 第184図は、命令SSTRのフォーマット図 第185図は、そのフラグ変化の説明図 第186図は、命令QINSのフォーマット図 第187図は、そのフラグ変化の説明図 第188〜190図は、命令QINSの説明図 第191図は、命令QDELのフォーマット図 第192図は、そのフラグ変化の説明図 第193〜195図は、命令QDELの説明図 第196図は、命令QSCHのフォーマット図 第197図は、そのフラグ変化の説明図 第198〜200図は、命令QSCHの説明図 第201図は、命令BRAのフォーマット図 第202図は、そのフラグ変化の説明図 第203図は、命令Bccのフォーマット図 第204図は、そのフラグ変化の説明図 第205図は、命令BSRのフォーマット図 第206図は、そのフラグ変化の説明図 第207図は、命令JMPのフォーマット図 第208図は、そのフラグ変化の説明図 第209図は、命令JSRのフォーマット図 第210図は、そのフラグ変化の説明図 第211図は、命令ACBのフォーマット図 第212図は、そのフラグ変化の説明図 第213図は、命令ACBの説明図 第214図は、命令SCBのフォーマット図 第215図は、そのフラグ変化の説明図 第216図は、命令ENTERのフォーマット図 第217図は、そのフラグ変化の説明図 第218図は、命令ENTERの説明図 第219図は、命令EXITDの説明図 第220図は、そのフラグ変化の説明図 第221図は、命令EXITDの説明図 第222図は、命令RTSのフォーマット図 第223図は、そのフラグ変化の説明図 第224図は、命令NOPのフォーマット図 第225図は、そのフラグ変化の説明図 第226図は、命令PIBのフォーマット図 第227図は、そのフラグ変化の説明図 第228図は、命令BSETIのフォーマット図 第229図は、そのフラグ変化の説明図 第230図は、命令BCLRIのフォーマット図 第231図は、そのフラグ変化の説明図 第232図は、命令CSIのフォーマット図 第233図は、そのフラグ変化の説明図 第234図は、命令LDCのフォーマット図 第235図は、そのフラグ変化の説明図 第236図は、命令STCのフォーマット図 第237図は、そのフラグ変化の説明図 第238図は、命令LDPSBのフォーマット図 第239図は、そのフラグ変化の説明図 第240図は、命令LDPSMのフォーマット図 第241図は、そのフラグ変化の説明図 第242図は、命令STPSBのフォーマット図 第243図は、そのフラグ変化の説明図 第244図は、命令STPSMのフォーマット図 第245図は、そのフラグ変化の説明図 第246図は、命令LDPのフォーマット図 第247図は、そのフラグ変化の説明図 第248図は、命令STPのフォーマット図 第249図は、そのフラグ変化の説明図 第250図は、命令JPNGのフォーマット図 第251図は、そのフラグ変化の説明図 第252〜257図は、命令JRNGのフォーマット図 第258図は、命令RRNGのフォーマット図 第259図は、そのフラグ変化の説明図 第260〜262図は、命令RRNGの説明図 第263図は、命令TRAPAのフォーマット図 第264図は、そのフラグ変化の説明図 第265図は、命令TRAPのフォーマット図 第266図は、そのフラグ変化の説明図 第267図は、命令REITのフォーマット図 第268図は、そのフラグ変化の説明図 第269図は、命令REITのフォーマット図 第270図は、命令WAITのフォーマット図 第271図は、そのフラグ変化の説明図 第272図は、命令LDCTXのフォーマット図 第273図は、そのフラグ変化の説明図 第274図は、命令STCTXのフォーマット図 第275図は、そのフラグ変化の説明図 第276図は、命令ACSのフォーマット図 第277図は、そのフラグ変化の説明図 第278図は、命令MOVPAのフォーマット図 第279図は、そのフラグ変化の説明図 第280,281図は、命令MOVPAのフォーマット図 第282図は、命令LDATEの説明図 第283,284図は、そのフラグ変化の説明図 第285図は、命令STATEのフォーマット図 第286,287図は、そのフラグ変化の説明図 第288図は、命令PTLBのフォーマット図 第289図は、そのフラグ変化の説明図 第290図は、命令PSTLBのフォーマット図 第291図は、そのフラグ変化の説明図 第292図は、ATフィールドの説明図 第293図は、論理アドレスの説明図 第294図は、ページアドレスの説明図 第295図は、多重論理空間の説明図 第296図は、UATBのフォーマット図 第297図は、SATBのフォーマット図 第298図は、SXの制限を示す説明図 第299〜301図は、テーブル領域の説明図 第302図は、STEのフォーマット図 第303図は、PXの制限を示す説明図 第304図は、STEの説明図 第305図は、論理アトレスの説明図 第306図は、PTEのフォーマット図 第307図は、PTEの各値とアクセス可能リングとの関係を
示す説明図 第308図は、PTEの説明図 第309,310図は、本発明装置の論理アドレス拡張に係る
メモリマップ 第311図は、データ転送命令のフラグ変化の説明図 第312図は、比較テスト命令のフラグ変化の説明図 第313図は、算術演算命令のフラグ変化の説明図 第314図は、論理演算命令のフラグ変化の説明図 第315図は、シフト命令のフラグ変化の説明図 第316図は、ビット操作命令のフラグ変化の説明図 第317,318図は、固定表ビットフィールド命令のフラグ
変化の説明図 第319図は、任意表ビットフィールド命令のフラグ変化
の説明図 第320図は、10進演算命令のフラグ変化の説明図 第321図は、ストリング命令のフラグ変化の説明図 第322図は、キュー操作命令のフラグ変化の説明図 第323図は、ジャンプ命令のフラグ変化の説明図 第324図は、マルチプセッサ命令のフラグ変化の説明図 第325図は、制御空間、物理空間操作命令のフラグ変化
の説明図 第326図は、OS関連命令のフラグ変化の説明図 第327図は、MMU関連命令のフラグ変化の説明図 第328図は、サブルーチンコールの説明図 第329図は、スタッフクレームの説明図 第330,331図は、命令シーケンスの説明図 第332図は、プログラム例を示す説明図 第333図は、サブルーチンコールの説明図 第334図は、制御空間の説明図 第335図は、PSWのフォーマット図 第336図は、IMASKのフォーマツト図 第337図は、SMRNGのフォーマット図 第338図は、CTXBBのフォーマット図 第339図は、DIのフォーマット図 第340図は、CSWのフォーマット図 第341図は、DCEのフォーマット図 第342図は、CTXBFMのフォーマット図 第343図は、EITVBのフォーマット図 第344図は、JRNGVBのフォーマット図 第345図は、SP0〜SP3のフォーマット図 第346図は、SPIのフォーマット図 第347図は、IOADDR,IOMASKのフォーマット図 第348図は、UATBのフォーマット図 第349図は、SATBのフォーマット図 第350図は、LSIDのフォーマット図 第351図は、CTXBのフォーマット図 第352図は、CTXBFMのフォーマット図 第353図は、EITVEのフォーマット図 第354図は、スタッフクレームの説明図 第355,356図は、EITのスタックフォーマット図 第357図は、IOINFのフォーマット図 第358図は、EITのベクトルテーブル 第359図は、JRNGの説明図 第360,361図は、EITの説明図 第362図は、IMASKの説明図 第363,354図は、システムコールの説明図 第365図は、DCEの説明図 第366図は、DCE,DI,EIの比較図 第367図は、DCEの使用例の説明図 第368図は、ビット割当図 第369図は、オペランドフィールド名索引図 第370図は、ccccの割当て図 第371図は、eeeeの割当て図 第372図は、M_flagの説明図 第373図は、BVMAP命令の演算コード図 第374図は、アドレッシングモードの対応図 第375図は、命令実行モデルのオペランドとの対応図 第376図は、PUSHA@SP等の説明図 第377図は、POP命令の説明図 第378図は、MOV命令の説明図 第379図は、PACK命令等の説明図 第380図は、STC命令等の説明図 第381図は、BFINS命令等の説明図 第382図は、CMP命令の説明図 第383図は、INDEX命令の説明図 第384図は、ACB命令等の説明図 第385図は、ADD命令の説明図 第386図は、CSI命令の説明図 第387図は、LDM命令等の説明図 第388図は、従来の装置におけるデータ構造図 第389〜390図は、従来の装置におけるアドレス計算の説
明図 第391図は、従来の装置におけるオペランド拡張方法の
説明図 第392図は、本発明装置の命令のフォーマット図 第393図は、本発明装置の動作説明図 第394図は、本発明装置の拡張フィールドの基本フォー
マット図である。
───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 昭59−135550(JP,A) 特開 昭57−105042(JP,A) 特開 昭59−105150(JP,A) 特開 昭58−35642(JP,A) 特公 昭59−31733(JP,B2) 特公 昭44−10066(JP,B1)

Claims (1)

  1. (57)【特許請求の範囲】 1.オペレーションの種類を指定するオペレーションコ
    ード指定部分、少なくとも1つのオペランドの実効アド
    レス及びアドレッシングモードを示す実効アドレス指定
    フィールド、並びに該実効アドレス指定フィールド又は
    先行するものの中で示される少なくとも1つのアドレッ
    シングモードに対してアドレッシングの拡張修飾を行う
    複数の付加モード指定フィールドを備え、各付加モード
    指定フィールド内に、後行の付加モード指定フィールド
    の有無を示す情報を含む命令を記憶する手段と、この命
    令をデコードする手段と、デコードした命令を実行する
    手段とを備えることを特徴とするデータ処理装置。 2.メモリ間接参照を行うかどうかを示す間接参照指定
    フィールド、インデックスレジスタを加算するかどうか
    をインデックス加算指定フィールド、インデックスレジ
    スタが汎用レジスタであるときのそのレジスタ番号を示
    すインデックスレジスタ番号フィールド、及び加算すべ
    きディスプレイスメントの長さを示すフィールドのうち
    の少なくとも1つを含む付加モード指定フィールドを、
    記憶してある命令に有する特許請求の範囲第1項記載の
    データ処理装置。 3.付加モード指定フィールドで指定される付加アドレ
    ッシングモードでアドレス修飾を行うべき被修飾アドレ
    ス値を、前記付加アドレッシングモードを指定する前記
    付加モード指定フィールド以前に実効アドレス指定フィ
    ールド及び付加モード指定フィールドで指定された情報
    で一意的に決定すべくなしてある特許請求の範囲第1項
    記載のデータ処理装置。
JP62247419A 1987-09-30 1987-09-30 データ処理装置 Expired - Fee Related JP2902402B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP62247419A JP2902402B2 (ja) 1987-09-30 1987-09-30 データ処理装置
US08/260,031 US5680568A (en) 1987-09-30 1994-06-15 Instruction format with sequentially performable operand address extension modification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP62247419A JP2902402B2 (ja) 1987-09-30 1987-09-30 データ処理装置

Publications (2)

Publication Number Publication Date
JPS6491236A JPS6491236A (en) 1989-04-10
JP2902402B2 true JP2902402B2 (ja) 1999-06-07

Family

ID=17163157

Family Applications (1)

Application Number Title Priority Date Filing Date
JP62247419A Expired - Fee Related JP2902402B2 (ja) 1987-09-30 1987-09-30 データ処理装置

Country Status (2)

Country Link
US (1) US5680568A (ja)
JP (1) JP2902402B2 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5627987A (en) * 1991-11-29 1997-05-06 Kabushiki Kaisha Toshiba Memory management and protection system for virtual memory in computer system
EP0626641B1 (en) 1993-05-27 2003-04-09 Matsushita Electric Industrial Co., Ltd. Processor improved in address management
JP3493369B2 (ja) * 1994-12-13 2004-02-03 株式会社ルネサステクノロジ コンピュータ
JP2889845B2 (ja) * 1995-09-22 1999-05-10 松下電器産業株式会社 情報処理装置
US5913054A (en) * 1996-12-16 1999-06-15 International Business Machines Corporation Method and system for processing a multiple-register instruction that permit multiple data words to be written in a single processor cycle
US5995750A (en) * 1997-12-16 1999-11-30 Micro Motion, Inc. Memory protection system for a multi-tasking system
US6493698B1 (en) * 1999-07-26 2002-12-10 Intel Corporation String search scheme in a distributed architecture
WO2001025941A1 (en) 1999-10-06 2001-04-12 Cradle Technologies Multiprocessor computer systems with command fifo buffer at each target device
WO2001025900A1 (en) 1999-10-06 2001-04-12 Cradle Technologies Risc processor using register codes for expanded instruction set
US8874882B1 (en) * 2000-03-30 2014-10-28 Intel Corporation Compiler-directed sign/zero extension of a first bit size result to overwrite incorrect data before subsequent processing involving the result within an architecture supporting larger second bit size values
US7092869B2 (en) * 2001-11-14 2006-08-15 Ronald Hilton Memory address prediction under emulation
US20040030963A1 (en) * 2002-08-12 2004-02-12 Sun Microsystems, Inc., A Delaware Corporation Method and apparatus for debugging computer program
US6880065B1 (en) * 2002-09-30 2005-04-12 Palmone, Inc. Memory management method and system thereof
US7269825B1 (en) * 2002-12-27 2007-09-11 Unisys Corporation Method and system for relative address translation
US8112618B2 (en) 2004-04-08 2012-02-07 Texas Instruments Incorporated Less-secure processors, integrated circuits, wireless communications apparatus, methods and processes of making
EP1870814B1 (en) 2006-06-19 2014-08-13 Texas Instruments France Method and apparatus for secure demand paging for processor devices
US7552302B1 (en) * 2004-09-14 2009-06-23 Azul Systems, Inc. Ordering operation
US8055886B2 (en) * 2007-07-12 2011-11-08 Texas Instruments Incorporated Processor micro-architecture for compute, save or restore multiple registers and responsive to first instruction for repeated issue of second instruction
US8281109B2 (en) 2007-12-27 2012-10-02 Intel Corporation Compressed instruction format
WO2009101976A1 (ja) * 2008-02-15 2009-08-20 Nec Corporation プログラム並列化装置、プログラム並列化方法及びプログラム並列化プログラム
US7966474B2 (en) * 2008-02-25 2011-06-21 International Business Machines Corporation System, method and computer program product for translating storage elements
US10157164B2 (en) * 2016-09-20 2018-12-18 Qualcomm Incorporated Hierarchical synthesis of computer machine instructions
US10754789B1 (en) 2017-11-15 2020-08-25 Amazon Technologies, Inc. Address translation for storage class memory in a system that includes virtual machines
US10762137B1 (en) * 2017-11-15 2020-09-01 Amazon Technologies, Inc. Page table search engine
US10810133B1 (en) 2017-11-15 2020-10-20 Amazon Technologies, Inc. Address translation and address translation memory for storage class memory
JP7208448B2 (ja) * 2019-02-01 2023-01-19 富士通株式会社 情報処理装置、情報処理プログラム、及び情報処理方法

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3657705A (en) * 1969-11-12 1972-04-18 Honeywell Inc Instruction translation control with extended address prefix decoding
US3614741A (en) * 1970-03-23 1971-10-19 Digital Equipment Corp Data processing system with instruction addresses identifying one of a plurality of registers including the program counter
US3946366A (en) * 1973-01-26 1976-03-23 Sanders Associates, Inc. Addressing technique employing both direct and indirect register addressing
US3943495A (en) * 1973-12-26 1976-03-09 Xerox Corporation Microprocessor with immediate and indirect addressing
US3953833A (en) * 1974-08-21 1976-04-27 Technology Marketing Incorporated Microprogrammable computer having a dual function secondary storage element
US3949378A (en) * 1974-12-09 1976-04-06 The United States Of America As Represented By The Secretary Of The Navy Computer memory addressing employing base and index registers
DE2846495C2 (de) * 1977-10-25 1993-10-21 Digital Equipment Corp Zentraleinheit
US4206503A (en) * 1978-01-10 1980-06-03 Honeywell Information Systems Inc. Multiple length address formation in a microprogrammed data processing system
US4388685A (en) * 1978-08-04 1983-06-14 Digital Equipment Corporation Central processor with apparatus for extended virtual addressing
US4236206A (en) * 1978-10-25 1980-11-25 Digital Equipment Corporation Central processor unit for executing instructions of variable length
JPS5621240A (en) * 1979-07-27 1981-02-27 Hitachi Ltd Information processor
JPS5621242A (en) * 1979-07-28 1981-02-27 Fujitsu Ltd Pipeline control method for computer operation
JPS5725069A (en) * 1980-07-21 1982-02-09 Hitachi Ltd Vector data processing equipment
JPS57105042A (en) * 1980-12-23 1982-06-30 Canon Inc Data processing device
US4453212A (en) * 1981-07-13 1984-06-05 Burroughs Corporation Extended address generating apparatus and method
US4530050A (en) * 1981-08-26 1985-07-16 Hitachi, Ltd. Central processing unit for executing instructions of variable length having end information for operand specifiers
US4503492A (en) * 1981-09-11 1985-03-05 Data General Corp. Apparatus and methods for deriving addresses of data using painters whose values remain unchanged during an execution of a procedure
JPH0235743B2 (ja) * 1982-08-17 1990-08-13 Nippon Soda Co Hokozokukarubonsanbenjiruesuteruruinoseiho
US4531200A (en) * 1982-12-02 1985-07-23 International Business Machines Corporation Indexed-indirect addressing using prefix codes
JPS59135550A (ja) * 1983-01-21 1984-08-03 Matsushita Electric Ind Co Ltd アドレス修飾装置
US4613935A (en) * 1983-02-02 1986-09-23 Couleur John F Method and apparatus for pipe line processing with a single arithmetic logic unit
JPS59174948A (ja) * 1983-03-25 1984-10-03 Toshiba Corp 情報処理装置
US4612613A (en) * 1983-05-16 1986-09-16 Data General Corporation Digital data bus system for connecting a controller and disk drives
EP0150177A1 (en) * 1983-07-11 1985-08-07 Prime Computer, Inc. Data processing system
WO1985002279A1 (en) * 1983-11-11 1985-05-23 Fujitsu Limited Method of controlling pipeline
US4837676A (en) * 1984-11-05 1989-06-06 Hughes Aircraft Company MIMD instruction flow computer architecture
US4890220A (en) * 1984-12-12 1989-12-26 Hitachi, Ltd. Vector processing apparatus for incrementing indices of vector operands of different length according to arithmetic operation results
JPS61148551A (ja) * 1984-12-24 1986-07-07 Hitachi Ltd アドレス変換方式
JPS61160142A (ja) * 1984-12-29 1986-07-19 Hitachi Ltd デ−タ処理装置
JPH0789319B2 (ja) * 1985-04-22 1995-09-27 株式会社日立製作所 デ−タ処理装置における先行制御装置
JPS61245256A (ja) * 1985-04-23 1986-10-31 Mitsubishi Electric Corp 情報格納方式
EP0239081B1 (en) * 1986-03-26 1995-09-06 Hitachi, Ltd. Pipelined data processor capable of decoding and executing plural instructions in parallel
US4901316A (en) * 1986-05-27 1990-02-13 Nohmi Bosai Kogyo Co., Ltd. Disaster prevention monitoring and control facility
US4890218A (en) * 1986-07-02 1989-12-26 Raytheon Company Variable length instruction decoding apparatus having cross coupled first and second microengines
JPH07101385B2 (ja) * 1986-12-05 1995-11-01 株式会社東芝 情報処理装置
JPS63253433A (ja) * 1987-04-10 1988-10-20 Hitachi Ltd 演算処理装置
JPH0192851A (ja) * 1987-10-02 1989-04-12 Hitachi Ltd アドレス空間切替装置
US4825258A (en) * 1988-01-04 1989-04-25 Whitson John M Device for bore alignment of gun sights
JPH07120278B2 (ja) * 1988-07-04 1995-12-20 三菱電機株式会社 データ処理装置

Also Published As

Publication number Publication date
US5680568A (en) 1997-10-21
JPS6491236A (en) 1989-04-10

Similar Documents

Publication Publication Date Title
JP2902402B2 (ja) データ処理装置
US5182811A (en) Exception, interrupt, and trap handling apparatus which fetches addressing and context data using a single instruction following an interrupt
US5201039A (en) Multiple address-space data processor with addressable register and context switching
US5029069A (en) Data processor
JP2931890B2 (ja) データ処理装置
Sites et al. Alpha AXP architecture reference manual
KR100190252B1 (ko) 고속 프로세서에서의 브랜치 처리 방법 및 장치
US7487338B2 (en) Data processor for modifying and executing operation of instruction code according to the indication of other instruction code
US20040158689A1 (en) System and software for matched aligned and unaligned storage instructions
US20190042760A1 (en) Compiling techniques for hardening software programs against branching programming exploits
US9459872B2 (en) High-word facility for extending the number of general purpose registers available to instructions
US20060236077A1 (en) Microprocessor access of operand stack as a register file using native instructions
JPH0766324B2 (ja) データ処理装置
Kretz Extending C++ for explicit data-parallel programming via SIMD vector types
Hyde The art of assembly language
Agner Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms
JPH07120284B2 (ja) データ処理装置
US7810073B2 (en) Method of translating n to n instructions employing an enhanced extended translation facility
JP2556870B2 (ja) データ処理装置
US5212779A (en) System for guarantee reexecution after interruption by conditionally used store buffer if microinstruction being executed is a memory write and last microinstruction
JPH09288564A (ja) データ処理装置
US20070061551A1 (en) Computer Processor Architecture Comprising Operand Stack and Addressable Registers
JP2522048B2 (ja) マイクロプロセッサ及びそれを使用したデ―タ処理装置
JP2006302324A (ja) データ処理装置
Smith et al. 64 Bits

Legal Events

Date Code Title Description
S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313115

R371 Transfer withdrawn

Free format text: JAPANESE INTERMEDIATE CODE: R371

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313115

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees