CPU実験の軌跡

3年後期にあるCPU実験を終えた聖狐が思ったこと, 薦めること, 止めた方がよいと思われることを挙げておきます
後々のCPU実験の参考になってくれると幸いです
尚, なるべく一般的なことを書いておくつもりですがこれが最良解ではないということを意識して読んでください
因みに聖狐の本職はHW係, 本職以外ではアセンブラ, 単純な擬似命令の実装, デバイスドライバ(謎)の作成を担当していました
一応班長(まとめ役)もやっていたはずです

仕様書はしっかりと作る, 途中で互換性の無い方向に変えない

これをいい加減(曖昧)に作ってしまうと後々で各班員の作業結果に齟齬が発生してその調整に無駄な労力を割かれることになります
『互換性の無い方向』の変更というのは途中で命令を削ったりレジスタ数や即値の仕様を変えたりといったこと, 最初からちゃんとしておきましょう
あとで必要になった命令を追加するのは仕方がないですが, 変更はなるべく複数人の作業にまたがらないようにしましょう

班員間の連絡は原始的手段でとる

下手にBBSやWikiのような高度なものを作っても使われなくなるだけ, メールや直接会話のほうが結局はロスが少なくなります

メールを出すなら影響を受ける班員にはためらわずCCすること, しないよりはずっとプラスに働くかと
深夜1時ぐらいに出したメールがすぐに返って来るほどの即時性にはうんざりすると思いますが…

監視する

中には聖狐のように実験期間中にネットゲームに夢中になって仕事をしなくなるような輩が現れるかもしれません
最終的に復帰してくれれば問題は無い(わけでもないが…)のですが, 作業のボトルネックになるのは危険なので何とか引き戻しましょう

独立する

お互いの作業は上手く分担すると意外にも同期を取らなくても最後の方まで持っていけるものです
どの作業がどのように干渉しあっているかを見極めて上手く振り分けましょう

ツールの開発順序, 開発担当者

表引き命令の表生成プログラムぐらいはHW係で出来るのならやっちゃったほうが楽です, 無理ならシミュレータ担当で
ライブラリ係に行きそうな内容かもしれませんが, 最初に実装するのは前2者ですから
また, 何は無くともアセンブラはとっとと作ることをお勧めします, 実は最初に使うのはHWのデバッグのトイプログラムだったりします
シミュレータは必要なデバッグ機能を意識して開発するのは勿論のこと, 速度もあってくれると有り難いです
また, アセンブリソースとバイナリのどちら(or 両方)を読み込めるようにするか, アセンブル/逆アセンブルできるようにするのかとかも最初に決めておきましょう
レジスタの状態表示は2進, 16進, 10進integer, 10進float, floatの(sign, exponent, mantissa)別表示ぐらいがついていると便利かな
(この辺は聖狐は殆ど関与していなかったのでたいしたことは言えませんが…)

HWにはデバッグ回路を

LED点灯実験の時に7-Segment LEDをいくつか買って来て(当然自腹ですが)取り付けることをお勧めします
付ける数は4つか8つにしておきましょう, 因みに7-Seg 1個あたり10本ほどの配線(信号 x 8, Common - 抵抗 x 1, 抵抗 - {GND|Vcc} x 1), つまり20箇所ほどの半田付けを要求されますので, 作業量とも相談して…
8桁で32bit全表示が出来ます, 4桁 + スイッチ(プッシュ式)でも殆ど苦労なく扱えました
転送回路なら番地と通信線のPin状態, CPUならボード上のスイッチを利用して任意のレジスタ(このために1つレジスタファイルを余分に必要とするが, それに見合う価値はあります)とPCを覗けるようにしておくとデバッグ効率はかなり高まります, 必要に応じて他の任意のラッチも監視できるようにしておきましょう

レジスタの仕様はコンパイラ中心だけど…

必要に応じてライブラリ側が好きなだけ要求できるように日ごろからの連絡を密にしておきましょう
意外と余っているところに余っているものです
HW係には0 registerをどうするか程度しか関係ありません(アセンブラ(をHWが作ったとき)で擬似命令を実装するときにちょっと要るかも)

時には臨機応変な対応を

理想論だけでは何事もうまくはいかないものです, 何か問題があったら臨機応変に対処する, 最悪仕方が無いので切り捨てるぐらいの覚悟は必要です(何)

さて, どれが我が班の成功でどれが我が班の失敗でしょう?