CPU実験の振り返り(シミュレータ係，後編)
最終発表からかなり遅れてしまいましたが，これ以上遅くなって記憶が風化しないうちにメモします．
前回の続きとして12月から書いていきます．前回の記事を読んでない方はこちらからどうぞ．
12月 2ndシミュレータ完成
コンパイラがとりあえず動き，コアも完成に近づいたところでISAの改善点が浮かび上がってきました．具体的には，
- シフトの即値命令，lui(addi命令1回で即値を埋められない桁に即値を埋める命令)がほしい
- アドレス等，桁の大きい即値を作ることが頻繁にあったため
- 浮動小数点レジスタと整数レジスタの区別はないほうが良い
- 浮動小数点の即値を入れるのが大変だったため
- ブランチの即値をより長くとれるように
- 自班のISAでは簡単のため，4バイトアラインされた位置にしかメモリアクセスしないので2桁節約可能
などがあります．
この中でも特に効果の大きいlui命令は1stISAにも組み込み，残りは2ndISAとしてまとめて改善を行うことにしました．自班の1stISAではlui命令がないと32ビットの即値を作るのに最大で8命令(シフト命令とaddi命令の繰り返し)かかったのでluiは必須といっても過言ではありません．
以上，2ndの仕様が決まったので，シミュレータは先周りして2ndシミュレータを作成しました．
この時，1st, 2nd共通の機能拡張も行いましたが，今考えてみれば蛇足だったと思う機能もありました．レイトレのプログラムの実行に予想以上に時間がかかったので，統計情報などをとらないことで実行だけを高速に行える機能をこの頃実装しました．確かに早くはなったものの，シミュ係の私として後々頻繁にシミュレータを使うことになるのは速度予測をテストするためであり，これには細かな統計情報が必要だったので，私はこの機能をあまり使いませんでした．コア係やコンパイラ係は使ってくれるかもしれませんが，個人的にはあまり使えなかったなと思いましたので，高速化するとしたら別の手法がおすすめです．
また，この月の後半にはコア係がデバッグ地獄に巻き込まれていました．私はそれなりにフリーであったものの，直接助ける術はなかったのでまごついていました．とりあえずテストプログラムのアセンブリをできるだけ書いてほしいといわれたので，バグを見つけやすそうなプログラムをいろいろ書きました．コンパイラを経由すると思った通りのコードにならないので，直接アセンブリをスムーズに書ける能力もあるとよさそうです．
1月 1stシミュ時間予測完了，1stコア完動，班全員単位確定
短い冬休みの余韻に浸ってしばらくたつと，コア係からとりあえず画像は出力できたという報告が．
……背景が赤いし，視点も違うし，なんか右上にヒストグラムみたいなのが出てるし…．とりあえず床の模様が出ていないので，「床がおかしければfloor関数を見直せ」という実用的な激うまギャグにに従うと…
とりあえず進歩したものの，見慣れた画像とは程遠い…．全体が大きく異なるので，局所的な問題ではないだろうと推測を進め，「浮動小数点テーブルがおかしいのではないか」という意見が出ました．これを見直した結果…．
感動しました！
実機の結果とシミュレータの結果もdifをとって差がないことを確認し，めでたく単位確定です．
…と言いたいところですが，シミュ係にはまだ時間予測が残っています．
あらかじめ作っておいたシミュレータの時間予測と実機の結果を比べると，速度競争で使うSLDファイルではギリギリ5%以内の精度で予測できたものの，実行時間が短いものほど誤差が大きくなっている模様．様々なファイルで実行時間の絶対誤差を調べたところ，定数分ずれているどころか，反比例するような傾向が見られました．実行時間が短くなるほど遅くなるような機構を様々考え，UART通信のキューが詰まっているのではないかと気づきます．今まではキューは詰まっていないという仮定をおいていたので，新たに近似的なキューを実装し，シミュレーションを行い，それも考慮に入れた時間予測を行った結果，ほとんどのSLDファイルで5%以内の時間予測ができました．
これにより単位が確定しました(速度予測で必要なSLDファイルだけ精度が高ければよかったのですが，この頃はそのことを知らなかったので，とりあえず精度を上げようと必死になっていました)．
2月 2ndコンパイラ完成，2ndコア完動，2ndシミュ時間予測完了．
試験が終わり，一段落したところで，2ndコンパイラ完了の知らせが届き，2ndコアの開発，デバッグが本格的になってきました．この時点で発表まで残り数日しかなかったため，時間予測のためにコアを待っている余裕はなく,私も急いでそれに取り組みます．
2ndコアも1st同様デバッグに悩まされ，前日は班員で徹夜をしてそれぞれの作業に取り組みました．今回はクラス全体で進捗が例年より遅れていたため，多くの班が発表会には2ndコアを間に合わせようと前日(当日)徹夜をしていました．私は朝6時まで時間予測の改善と発表資料作成に取り組んでいましたが，自班を含め徹夜をしていた班から完動報告が来なかったため，半分諦めて3時間程仮眠をとりました．起きてみると，私が寝た1時間後に2ndコアが完動したという報告がコア係から来ていました．徹夜をしていた中で2ndコアを完成させたのは彼だけだったので，彼の勝負強さ，根気強さには感服します．急いで時間予測に掛け，何とか発表会前に配布されていたSLDファイルすべてでの時間予測を行い，7~8割近くのファイルに対して5%以内の精度で時間予測ができたことを確認しました．
しかしながら，同時に最適化をしていたコンパイラ係から，最新の最適化を施したコードが動かないという報告が．おそらくシミュレータ，アセンブラのバグではないかと思われていましたが，複数ファイルで精度の高い予測をしなければならないと勘違いしていたため，時間予測の確認に追われてそちらの対応に間に合わず，最後の最適化は最終発表には組み込めませんでした．徹夜までしてもらったのに申し訳ないです…．
しかしながら，班員のファインプレーが重なり，8班中3位，実行時間42.3sを達成しました．今回はボードの性能低下，必須要件の増加などがあったため，もう少し遅い結果になってもおかしくないと思っていたので驚きました．やはり班員の皆さんは偉大です…．
感想
シミュレータ係としてCPU実験に参加してみた感想として，最初と最後に負担が大きいというのがまず挙がります．シミュレータはほかの係のデバッグツールになるため，できるだけ早く(そして速く)動くものを作らなければなりませんし，コアが動いてから時間予測の確認もあります．コアの完成がかなりギリギリになると予想されるため，シミュレータ係はコアが動く前にほぼ時間予測を完成させなければなりませんし，コアの完成から発表会までのわずかな時間で確認と微調整を終わらせなければなりません．逆にそれ以外は自分や班員の役に立ちそうなものを作ったり，班員のリクエストに答える以外は割とフリーになります．ただ，班員のリクエストにはなるべく早く答えられた方がいいので，全体的にフリーな時間が多いほうが向いているかもしれません（どの係にも言えることですが）．
また，ここまで大きなグループ開発も行ったことがなかったため，新鮮でしたし，最後の徹夜も含めてなんだかんだ楽しかったです．でもどうせなら地下でいろいろ取り組みたかったなあという思いもあります．今年は使えるようになるんでしょうかねえ…．
