木曜日, ５月 23, 2013命令セット現在設計中のプロセッサは、命令語長4ビット、データ語長32ビットの合わせて36ビット幅で内部メモリへのアクセスを行います。 命令フェッチの際、4ビット長の命令と同時に読み出された32ビット長のデータを、命令実行の際のオペランドYとします。
命令（4ビット） オペランドY（32ビット）
レジスタとしては、プログラムカウンタPCの他に、32ビットのレジスタXに1ビットのキャリーフラグCを付加した33ビット長のアキュムレータAccを持ちます。
プログラムカウンタPC
アキュムレータAcc（33ビット）： キャリーフラグC レジスタX（32ビット）
ちなみにDE0-Nano上のFPGA（EP4CE22）では36ビット×16Kワードの内部メモリが確保可能なので、プログラムカウンタPCは14ビットになります。 その他、各プロセッサ要素固有の内部状態として、排他制御用のロック状態フラグlockがあります。ロック状態フラグはLOCK（TRYLOCK）命令でセットされ、UNLOCK命令でリセットされます。ロック状態のセットは対象となるプロセッサでしか実行できませんが、リセットはオペランドでプロセッサを指定できるので、任意のプロセッサで実行可能です。 命令コードとその動作内容を、内部状態の変化として表したものが以下の表になります。ただし、これはあくまでも暫定的なもので、実装の都合により変更される可能性があります。（8/16変更しました）
基本的に4ビットの命令コードで命令実行内容が決定されますが、一部ジャンプ命令等はオペランドYの上位4ビットを利用して命令の拡張が行われています。 ジャンプ命令は条件に応じてPCの値を変化させるものですが、その後PCの下位ビットがメモリバンクと一致しない間は内部的にHALT命令を実行し、回転待ちを行います。 PUT命令によるメモリ書込みは、実際にはスレッドが目的のメモリバンクに到達した時点まで遅延されます。ここでもし、あるバンクへの書き込みが未完了の状態で、また同一バンクへの書き込みを実行しようとした場合（collision=1）、一旦PC := PCとして一周分の回転待ちの間に全ての遅延書き込みを完了させた上で、再び書き込み命令を実行します。二度目の書き込みでは全ての遅延書き込みが完了しているため、今度は必ず成功します。 PUT命令によるオペランド書き換えの際、実際にはYの上位4ビットの値で命令コードの書き換えも行われます。これは、命令コードとオペランドを同一メモリにした方が効率が良い（パリティビットが使える）のと、排他制御の際に同時書き換えができた方が都合が良いといった理由があります。ただ、オペランドだけ書き換える際にも命令コードを指定しなければならないので、ハンドアセンブルの場合は若干面倒です。基本的には、こういった作業をコンパイラ等で自動化することを想定した設計となっています。 ここで、設計上最も悩ましいのがランダムアクセス読み出しです。このプロセッサでは配列やテーブルの機能を実現するために最低限必要な命令として、DATA命令を実装しています。DATA命令はLOAD命令と同様にオペランドYの値をレジスタXに代入しますが、同時に代入実行前のレジスタXで指定された番地へのジャンプも実行します。基本的な使い方としては、レジスタXに戻り番地を入れて目的のDATA命令へのジャンプを実行することになりますが、このジャンプの飛び先を変化させることでランダムアクセスが可能になります。とはいえ、いちいちジャンプ命令のオペランドを書き換えていたのでは、あまりに効率が悪くて話になりません。 ところがなんと、不思議なことに同じ命令を利用することでこれが解決します。 例えば、1000番地にデータとしてオペランド値123を持つDATA命令を置いたとします。100番地からのコードで、まずLOAD 1000でレジスタXに1000を代入し、次に101番地で次の命令番地の102をオペランドとするDATA命令を実行します。するとまず、101番地のDATA命令の結果、レジスタXの値は102となり、1000番地にジャンプします。次に1000番地のDATA命令の実行により、レジスタXの値は123となり、102番地へのジャンプが実行されます。この結果、101番地のDATA命令は、表面的にはレジスタXで指定した番地のデータを取得（X := [X]）し、ついでにオペランドで指定された番地へのジャンプ（PC := Y）を実行する命令として動作します。101番地と1000番地のDATA命令は実行内容は同じですが、プログラム内での意味合いは全く違ったものになりますので、101番地の方は同じ命令コードでGETという名前を割り当てることにします。
GET命令によるランダムアクセス読み出しは、ハードウェア的には簡単な命令を一つ実装するだけで済むので非常に低コストです。しかし、実行時にはジャンプを2回実行しなくてはならないため、回転待ちのコストが掛かります。特に、上の例の様にGET命令の戻り番地を命令の次の番地にした場合、必ず1周分の回転待ちが発生します。これがもし、GET命令、DATA命令、戻り番地を隣接するメモリバンクに配置することが可能であれば、回転待ちは2命令分にまで減少します。実際には、同じDATA命令にアクセスするGET命令が複数あると考えられるので、そう単純にはいきませんが、命令やデータの配置を工夫することで、実行効率の改善が期待されます。こういった最適化の技法は、今後興味深い研究対象として発展する可能性があります。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
水曜日, ５月 22, 2013JRubyの導入現在、DE0-Nano用のプロセッサ設計と平行して、JRuby関連の環境整備をしています。 JRubyはJava仮想マシン上で動くRuby環境で、Jarファイル一つでお手軽に導入可能な便利なものです。このRubyという言語は非常に自由度が高く、その上に別の言語（ドメイン特化言語）を構築するようなことも可能です。プロセッサの回路設計は論理合成のためにVHDLやVerilog HDLといったハードウェア記述言語を利用しますが、マルチプロセッサの様な大規模な回路をCAD無しで直接記述するのは結構大変なので、ここではRubyを利用したより上位の記述をもとに、VHDLのコードを自動生成する方式を採ります。また、マルチプロセッサ用のソフトウェア開発においても、Rubyを利用したコンパイラを構築する予定です。 このJRubyですが、Windows環境ではDLL呼び出しの機能もあるので、JNAの代わりにそれ自体でJTAGのアクセスが可能です。というわけで、さっそくJRubyを利用したJTAGデモプログラム（jtag_demo.jar）を作ってみました。JRubyのJarファイル（jruby-complete.jar）は結構大きいので、今度は同梱せずにネットから最新版を自動的にダウンロードするようにしてあります。
ダウンロードしたjruby-complete.jarをjtag_demo.jarと同じフォルダに置いておくか、Javaの拡張フォルダ（jre/lib/ext）に移動すれば、次からはダウンロード無しで実行が可能です。このやり方で、かなりコンパクトなファイルのみで回路データとコンフィギュレーションプログラムを配布することが可能になります。JavaとRubyのソースコード（Rubyの方は実行コード）はJarファイル内に同梱してありますので、同様の仕組みを利用したい方はご参照ください。 |
