hungalab / cube_sim Goto Github PK

MIPSコアとは独立したモジュールを並列にエミュレーションしたい。

方法としては cpu.cc の void CPU::step()のような各サイクル実行されるメンバ関数を並列に動作させたいモジュールに実装し、vmips.ccのvoid vmips::step(void)から呼び出すのが無難そう。

問題はこれらをどうコミニュケーションさせるかをちゃんと考えないといけない。

ひとまずはDMACを実装したい。@zoubleton に協力を仰ぎたい。

これはGEYSER4のDMAC仕様&割付アドレスなどの情報
Geyser4_アドレス.txt

どのようにコミニュケーションさせるかは議論が必要。

これはどちらかと言えば、sube_sim側の問題というより、コンパイル環境の問題。

ちなみに、VMIPSのgdbserverと互換があったGDBは6.8より前で、7以降はダメだった。
GDB6.8のデバッグ形式はDWARF2じゃないといけない。
このデバッグ情報を付加してコンパイルするには-gdwarf-2をつける
(正確にはMakefileでリンク時にstripしている行もコメントアウト)

これでできる実行ファイル(ELF形式)でも、breakpointの設定や、グローバル変数のprintはできそう。
しかし、ローカル変数のロケーション情報が狂う。

例えば、printf.cのサンプルではmain関数内にbufとsという変数が定義されているがこのアドレスが0x0や0x64になってしまう。

この原因を探すために

$ /home/wasmii5/mips-cross/bin/mips--elf-readelf --debug-dump printf.elf

をしてみるとdebug_infoセクションのbufに関する情報が

<2><f4>: 省略番号: 6 (DW_TAG_variable)
    <f5>   DW_AT_name        : buf
    <f9>   DW_AT_decl_file   : 1
    <fa>   DW_AT_decl_line   : 11
    <fb>   DW_AT_type        : <0x12c>
    <ff>   DW_AT_location    : 3 byte block: 91 90 7f   (DW_OP_fbreg: -112)

ロケーションに関するものはDW_AT_locationで、グローバル変数や関数はここに実際のアドレスが入っているが、ローカル変数はDW_OP_fbreg: -112のようなオフセット指定になっている。

これはこの変数を含む関数のDW_AT_frame_baseとともに計算されるらしい。
ではmain関数の情報をみると

    <49>   DW_AT_external    : 1
    <4a>   DW_AT_name        : (indirect string, offset: 0xc5): main
    <4e>   DW_AT_decl_file   : 1
    <4f>   DW_AT_decl_line   : 4
    <50>   DW_AT_type        : <0x110>
    <54>   DW_AT_low_pc      : 0x81000030
    <58>   DW_AT_high_pc     : 0x81000108
    <5c>   DW_AT_frame_base  : 0x0 (location list)
    <60>   DW_AT_GNU_all_tail_call_sites: 1
    <61>   DW_AT_sibling     : <0x110>

DW_AT_frame_baseは0x0となっており、location listを参照するようになっている。

では.debug_locセクションを確認すると

.debug_loc セクションの内容:

    Offset   Begin            End              Expression
    00000000 81000030 81000034 (DW_OP_breg29 (r29): 0)
    0000000c 81000034 81000040 (DW_OP_breg29 (r29): 112)
    00000019 81000040 810000f4 (DW_OP_breg30 (r30): 112)
    00000026 810000f4 81000100 (DW_OP_breg29 (r29): 112)
    00000033 81000100 81000108 (DW_OP_breg29 (r29): 0)
    0000003f <リストの終端>

いろいろ試していてわかったが、どうやらローカル変数はフレームポインタ(r30)+オフセット
でアクセスしようとするらしい。
しかし、元々のプログラムでは逆アセンブルしても$fpは出てこない。

なぜだろう

VMIPSから備わる機能によりGDBが使える。
しかし、これはCPU側のレジスタファイルや、statusビット、PCなどしか覗くことができない。
現状、GDBを用いてアクセラレータの状態を覗くには、適当なところでbreakpointを設定し、print文でメモリの内容を表示するしかないが、これはメモリ上にマップされたものしか覗くことができない。

レジスタファイルやアクセラレータの状態をtriggerにできるようにしたい。

@zoubleton モデルの追加お願いします

問題はストア時間と、電圧をどのように模倣するかです。

後者はコンストラクタの引数か何かにするというのでなんとかなるような気がしますが、前者は難しいかもしれないです。

前者は例えば、同じアドレスに同じデータをstore_wordするのが何回連続して行われるかで判別するとか？

現実的にには内部でMMUやらバス周りでかかる時間に加えて、外部メモリでさらなる遅延が発生するはずである。今はどんなモジュールに対しても一律な遅延にしているがこれを変更する。

NAMACHA のパーツを活用して作ります

MIPS R3000には8つの割込みを利用できる。うち2つはSW割込み、残り6つはHW割込み。

SW割込みに関してはCP0のstatusレジスタにSWが1を書き込むことで発生する(CPU側は毎サイクルビットが立っていないかをチェックする)。

一方でHW割込みにはGEYSERでは

• HW3 DMAC
• HW5 Router
  に対応する。

CMAやSNACCでは同一アドレス空間上に2つの物理メモリが存在するため、これを可能にするモジュールを作ります

もともとvmipsにあるMakefileはautomakeで作られていて、/usr/binなどにインストールするインストーラ的な機能もあるが、わかりにくいので必要最小限のものだけをビルドするためのMakefileが欲しい

最終的に実装が必要かもしれませんが、優先度が低いので一旦放置します

真面目に作ります

オリジナルでは1サイクルで全てを実行し、分岐発生時のみ遅延スロットとして後続命令を実行してから分岐先に移動している。
適切なエミュレートおよび #1 のためには5段パイプラインの振る舞いを正確に再現する必要がある。

基本的な

1. IFステージ
2. IDステージ
3. EXステージ
4. MEMステージ
5. WBステージ
   の構成で想定する

遅延スロットを考慮するということは分岐先の判定はIDステージで行うはず。

これらを踏まえると次のハザードがある(フォワーディングでは対応不可)

1. データハザード

• MEMステージのロード結果を直後の命令のEXEステージで必要とする場合
  • 1サイクルだけIF,ID,EXを停止させる
  • その後 MEMステージからフォワード

2. 制御ハザード

• IDステージの分岐先の計算に直前のEXEステージの計算結果を必要とする場合
  • 1サイクルだけIFを停止させる (下記参照)
  • その後 EXEステージからフォワード
• IDステージの分岐先の計算に直前or 2サイクル前 (下記参照) のMEMステージのロード結果を必要とする場合

コプロ命令に関しては要確認. 例えば

• TLB書き換えはどのステージで行われるのか
• MFC0などのストール

DMACや複数コアをバスに接続することを想定して、mapperにアービタを組み込みます

アービトレーションを追加するにあたり

1. アクセス権のないclientからのrequestWordは無視する
2. バスアクセス権の要求と解放をcacheやcpuに実装する

必要がある(と思われる)

Geyserにはキャッシュを操作するcache命令が実装されている

これは便利なので実装したい

オリジナルの実装ではキャッシュらしきものはあるがdirect mapでしかも、ブロックサイズ=1のキャッシュと呼んで良いのかわからない代物。加えてライトスルー方式。

キャッシュミスペナルティも考慮したn-way associative cache化したい。

順番としては

1. キャッシュとしての振る舞いをエミュレーション
2. キャッシュミス時のstallを実装
   という手順で進めていく。

ただし、キャッシュミス時のstallを実装するには少なくとも以下を考慮する必要がある。

• 5ステージパイプラインでは命令キャッシュとデータキャッシュでミスするステージが異なる
  • 命令キャッシュはFetchスレージ
  • データキャッシュはMEMスレージ
  • 当然同時にミスすることも考慮しなくてはいけない
• 遅延スロットの取り扱い
  • VMIPSでは厳密にパイプラインをエミュレーションできてない
    • 多くはEXEステージを毎サイクル実行?

あとMIPS R3000ってデータハザードでパイプラインの停止とかインターロックって実装されてたのか忘れたから調べる

それなりに頑張って作ってきたのでしっかりとドキュメントを残してlost technologyにならないようにしたい。
かといってLaTeXなり、パワポなりでドキュメントを作るのは辛い&読みづらい。
C++であればDoxgenを使って自動生成してもらうのが無難そうではある。

masterにpush->Doxgenでドキュメント生成->github pages化

というのもあるみたいだが、github pagesだとリポジトリがprivateでもpagesはpublicになってしまう。まぁ見られても問題ないものではあるが、一応BASIC認証くらいはかけておきたい。

そうなるとここで紹介されいているように、Doxgenでの生成をWercker、生成した静的ページをHerokuへpushとやるのが良いのかもしれない。やや大げさな気もする。

@zoubleton このあたりのサービス詳しそうなので何か良い案があれば教えてください。

今アクセラレータはルータ経由でしかアクセスできないが、バスで結合した方式も使えるようにする