前の記事　01-03_命令を増やせる

はじめに

Chapter99では直接開発と関係しませんが、ウラ話や小ネタを提供していきます！！
今回は、セキュリティキャンプ'23を振り返りながら、
森羅万象プロジェクトがどのようにして生まれたのかをお伝えできたらと思います！！
★特にseccamp'24に参加する皆様、キャンプの雰囲気やGWの参考になれば幸いです！！（が、少々ネタバレかもしれません！）

登場人物

一応、前に記事にしているので、よければどおぞ。

ア：Astalisks（Y3『故障を乗り越えて動くシステムのための分散合意ゼミ』、記事書いた人。だから基本こいつ視点。）
キ：Kyuta（Y4『CPU+コンパイラ自作ゼミ』）
シ：shinbunbun（Y3『故障を乗り越えて動くシステムのための分散合意ゼミ』）
ユ：yn0014（Y2『RISC-V CPU自作ゼミ』）
ワ：wakuto（Y2『RISC-V CPU自作ゼミ』）
※なお、「ア」以外のセリフは「ア」がいい感じにしゃべらせているだけなので、実際の会話とは異なります。何なら「ア」が捏造している気も、、。

ゆ：uchanさん（seccamp'23のグループワーク担当。Y4の先生。）

（'24はWXYZの区切りでなく、Sで統一されているはずです！）

1.グループワーク～何をしよう、、。

（あらすじ：seccamp'23は5日間、1日目と4日目に1hずつグループワークがありました。）

ゆ：「グループで、セキュリティに関する、長期的な活動を何か考え、5日目に発表してくださーい。」

ア：「よろしくおねがいしまぁす。てことはぶっちゃけなんでも良さそうですね。どうきめていきましょ。」

ワ：「まずはよく出るアイデアとして、CTFですかね。ここにいる人だと結構いいとこまでイケそうですよね。」
ア：（たしかに。名刺交換の時に話した人の中に自分で日本2位って言ってた人いたし、、。このメンバーでやったら強そう。）

キ：「毎週LT会とかもよく聞きますね。5人だと実質月1ペースですし。」
ア：（ふむふむ。みんなしゅごい人だから面白い話が聞けそう。）

シ：「同人誌を書くのもあるあるですね。出し方はわかりますよ。」
ア：（技術書典に出すのかな。というか出せるレベルなのしゅげぇ。）

ユ：「Tech記事とかもありですね。QiitaとかZennとかにあげていく感じの。」
ア：（そのうちプライベートでもあげれるようになりたいな。（って思ってたので結果的にはこのプロジェクト、めっちゃありがたかった。））

ア：「この辺は確かにすぐ思いつきますね。過去の事例とかでオモロいの知ってる、とかありますか？？」

シ：「RustでWebサーバつくるとかありましたね。言語的にセキュリティ高めなのでよいかも。」
キ：「CTFで攻撃したら代わりの置き土産的なのを置いて行って、互いに攻撃しあうのも面白いし続きそう。」
ワ：「OSS開発に参加するとかもありますね。最終的には自分たちで開発とか？」
ユ：「RPGを作ってセキュリティについて勉強できるものとか楽しいと思いますね。」
ア：（おぉ、どれも気になるぅ。でもこういうのってスペシャリストがいて成り立つもんだから私はきつそう、、？）

ア：「ちなみに、なにしてみたいとかってありますか？個人的にはグループ作ってブログがおもろそうって感じなんすけど、、。」

シ：「オリジナルのアプリとかWebサイトとか作ってみたいですね。それこそ記事をホストするような。」
ア：（なるほど。やったことない（←情報系大学4年なのに）から良い勉強になりそうやな。詳しい人がいるのありがたい。）

ユ：「得意なのは割とレイヤーが低いところですね。それこそOSとか5人で作ってみても良さそう。」
ア：（お、おぉ、。OSって作れるんだ。確かにゼミではLEDチカチカしてたけど、キャンプ前にやってたんか、、？）

キ：「せっかくCPUのゼミに参加したから、それを使えると嬉しいかも。はんだ付けとかの経験も活かせますね。」
ア：（O, Oh... CPUをつくる、かぁ。C言語とかで電話作れるって聞いたことあるし（←これはホント）、CPUもC言語で作るのか、、？（←答えは次章で））

ワ：「じゃぁ、CPUもOSもアプリも自作していく活動にしませんか？」

ア：（ファッ！？それはきつくないか？どれかだけでも一からは開発したことないのにぃ、、。）
シ：「いいっすね！！オリジナリティとしてはピカイチだろうし！」
ユ：「CPUとかOSの構造を知ることはセキュリティについての周辺知識を知るようなものですしね！！」
キ：「せっかくCPUゼミ、OSゼミ、分散システム（Webサーバ系？）ゼミの人がいるんだし！！！」
ア：（まぢ！？みんなやる気かい、、。）

ゆ：「ちょっと話聞いてたけどおもしろそうですね。私は見てみたいので是非それにしてください。みんな賛成そうですが「ア」さんどうします？」

ア：「じ、じゃあ決まりですね、全部自作！ということで！」

ーーというかんじで、森羅万象（をつくる）プロジェクトがはじまったとさ。

　　正直私（ア）は内心かなり反対だったんですよね、、。遠くから見てるか蒸発する未来しか見えなくて。
　　でもこのとき視えちゃったんですよ。私の（輝度の高い白が色々な色の点に見える（病院行ったけど珍しいらしい））目で、
　　この案が出たときに4人の目が虹色にキラキラしたのを。
　　たぶん思い込みなんでしょうけど、それでもみんな本気なんだなぁって。
　　今思えば、あのとき「もう少しハードル下げて現実的なものを」って提案しなくてよかったなぁって感じました。

　　ということで、もしseccampのグループワークないし「自分よりすごいと思うメンバーとグループになったとき」には、
　　みんな初めてのことをするだとか、割と攻めた目標を立ててガンバってみるのもありかもしれませんね。

2.GWから1週間後～どんなCPUにしよう、、。

（あらすじ・・・
ゆ：「ただGWやってもつまらないと思うので、（23年の）ネクストキャンプでやったTDD＋モブプロ形式はどうでしょう？」

ということで、TDD（テスト駆動開発）かつモブプログラミング形式で開発することが決まりました。）

★TDD（テスト駆動開発）・・・プログラムを一から書くとき、先に「このテストを満たすようにしたい！」っていうのを先に用意する手法。
（GPTに聞いたのを書き換えただけですが）単に足し算でも、、、

<!-- adder_test.go -->
func TestAdder(t *testing.T) {
    if adder(1, 2) != 3 {
        t.Error("1+2 should be 3")
    }
}

<!-- adder.go -->
func adder(a, b int) int {
    return a + b
}

↑↑のように、まずテストを書いてから、それを満たすようにプログラムを書いていきます。
足し算だから簡単、というわけではなく、テストケースって意外と種類書けるもので、、。

<!-- adder_test.go -->
func TestAdder(t *testing.T) {
    <!-- 普通に足し算 -->
    if adder(1, 2) != 3 {
        t.Error("1+2 should be 3")
    }

    <!-- 負の数が入ったときのテスト -->
    if adder(-1, 2) != 1 {
        t.Error("-1+2 should be 1")
    }

    <!-- 0が入ったときのテスト -->
    if adder(0, 2) != 2 {
        t.Error("0+2 should be 2")
    }

    <!-- 小数が入ったときは「小数は計算できない」というエラー文を返す -->
    if adder(1.5, 2) != "小数は計算できません" {
        t.Error("1.5+2 should be \"小数は計算できません\"")
    }

    <!-- intより大きい値が入ったときは「値は4294967295より大きくできません」というエラー文を返す -->
    if adder(300000000, 3000000000) != "4294967295以上の値は計算できません" {
        t.Error("300000000+3000000000 should be \"4294967295以上の値は計算できません\"")
    }

    <!-- 文字列は計算できない -->
    if adder("1", 2) != "文字列は計算できません" {
        t.Error("\"1\"+2 should be \"文字列は計算できません\"")
    }
}

のように、すべてのケースに対応できないと親切な関数とはいえなかったり。
（まあ、開発者が思いつかなかったテストをして良い感じに（我々からすると悪い感じに）イケちゃったやつを
巷では「脆弱性」だったり「バグ」だったりって言うんですけどね、、。）

↑↑くらいのテストが書けると、実装する関数に必要十分な機能を書きやすかったり、まとめられることに気づいたり↓↓もできます。

<!-- adder.go -->
func adder(a, b int) int {
    <!-- 小数、大きい値、文字列の場合はエラー文を返す -->
    if a != int(a) || b != int(b) {
        return "エラー：整数以外の値は計算できません"
    }
    <!-- 条件を満たしている時点で計算 -->
    return a + b
}

★モブプログラミング・・・複数人で一つのコンピュータを共有してプログラムを書く手法。
さすがにオンラインだとPC自体を共有できんので「VScodeのLive Share」を使うといいかもしれません（当プロジェクトはコレ）。
CPUなんぞ何も知らない筆者でも、この方式をとることでおいてかれなかったので、おすすめです。
逆にできない人はわかるまでできる人に聞きましょう。歩調合わせになるし開発も早くなります（自分にブーメラン）。

ア：「CPUもOSもWebサーバもやるって言ったけど、全部自作ならCPUからつくることになるんですかね、、？」
ワ：「ですね。CPUが知らない命令をOSやWebで使っても動かないので。」
ユ：「大丈夫ですよ、OSにオープンソースのLinuxとかがあるように、CPUにもRISC-VっていうOSSがあります。
　　　プログラミング言語みたく、ある程度の文法を押さえておけば、作りたい命令を用意できたりするんですよ。」
ア：（ほほう、、ニュースをみると意外と商用利用されてる？もしかして意外と有名、、？）

ア：「じゃあ、RISC-Vでやるとすると、使うのはC言語とかになるんすかね、、？ポインタとか苦手だな、、。」
キ：「いいえ。RISC-VはVerilogを使いますね。（詳しくは「01-02_加算器をつくる」で解説？してますが、）
　　　C++やPythonにもCPUを書くライブラリはあっても最終的にVerilogに落とす必要があるので最初からVerilogでよいかと。」
ア：（ほえぇ、、。あ、でも学部2年の時に授業で出てきたような、、？）

ア：「Verilogでやるとすると、環境構築大変そうだなぁ、、。なんかおすすめの方法とかあるんかね？」
シ：「EDA Playgroundとか使えば、ブラウザだけでVerilogのコードを書いてシミュレーションできますよ。」
　　　あとnix-shellとか使うとライブラリやパッケージも統一できますね。」
ア：（ははぁ、、。続々と新しい単語が、、、。これはdocker-compose的なイメージで管理できて（←？？）便利そう。）

ア：「最初にやるCPUは大体決まったかしら。今後OSやWebサーバを作るけど、最終的なビジョンってありますか？
　　　私は知らない人もみんなが「何してるのかがわかるもの」を作りたいと漠然にありますが、、。」
ワ：「CPU自作は経験ありますが、Webの方となると初めてなのでワクワクしますね。最後までやり遂げたい感はあります。」
ユ：「それぞれ得意分野があるので、得意なところはリードして、初めてのところはレクチャー受けて、相互理解していけたら。」
キ：「それで言うと、作りたいものは作る、は徹底したいですね。奇想天外な仕様になっても「つくりたいからつくるんだ」の精神でいきましょう。」
シ：「最終的には、自分たちで作ったものをみんなが作れるようにして、作った人がつながるコミュニティとか夢ありますね。」
ア：「それなら、私も（こんな感じですが）記事を書いて開発をサポートできそう、なんだかいけそうな気がしてきたっちゃ！！」

ーー開発から1年弱経ってますが、現在もTDD＋モブプロ形式で開発を続けています。（ちょっとTDDは怪しいですが。）
　　今後の記事に書く予定ですが、無知な私が「おいらがわかりやすいほうじゃなきゃ嫌や！！」とゴネて決まった、結構大事な仕様があったりします。
　　「開発前は全く理解できなかったAとBの、判別がつきどっちが良いか提案できるようになった」ことは
　　私のエンジニア生活の中で一番の収穫なことは言うまでもありません。
　　こればかりはグループのメンバー、GWを設けてくれた運営陣、ゼミで拾ってくれた先生に感謝です。
　　（すみません先生。私はまだキャンプ当日の課題終わってません。取り組んではいるので、'24年末までには必ず、、。）

そんなこんなで、一旦は良い感じに決まったのですが、、。

ゆ：「あれ、全部自作するんじゃないんですか？？ゴールはいいけど、RISC-Vとか、既存のもの使っちゃうんですか？？？？」

3.GWから2週間後～独自性を出すために、、。

ユ：「RISC-Vで作らないとなると、命令とかbit長まで独自で考えないといけませんね。」
ワ：「ですね。それにVerilogでやるとRISC-Vに思考が寄っちゃうので、chiselを使ってみるのはどうでしょう、」
キ：「コンパイラや他のコンポーネントでは、後々メモリ関連のバグがでると厄介なので、厳密に定義するRustを使う方針でいきましょう。」

ユ：「ちなみにCPUの詳細とかも大まかに考えてみませんか？いっそのこと32bitとか64bitでないものを作ってしまおう、的な。」
ワ：「32bitをそのまま持ち運べると面白いことができそうなので、48bitとかどうでしょう、8の倍数だから計算のしやすさはある程度担保されてますよ。」
キ：「じゃぁ64bitでええやんと言われたら、そこはロマンでしょ、と返す勢いで行きましょう。明確にオリジナリティが出ますし。」

シ：「コード管理はデファクトスタンダードのgithubで、CI/CDもある程度GitHub Actionsで自動化しましょう。
　　VScodeのliveshareを使えばモブプロも大丈夫そう。
　　nix-shellは些か敷居が高めかもなので、あと、みんながとっつきやすいものを使ったほうがと思ったので。」
ワ：「であれば、仕様書の表が美しく書けるよう、Asciidocを使ってみましょう。」

ーー確かこれがseccamp終了2週間後の話で、mtg3回目のときにはもう開発し始めていたと記憶しています。
　　この部分は（筆者以外の）グループメンバーの技術力の高さと即断即決（当たって砕けろ精神？）が活きたかもですね。対応力がすごい。
　　私は何も知らないので「Pythonのライブラリとchiselは違うの、、？」とか「.adocは.mdとどこが違うの？」とか聞いて、理解するのがやっとでした。

　　最後に、とりあえず開発開始前にまとまったものを列挙しておきますね。
　　　　・作りたいもの、必要十分な機能を持ったもの、みんながわかるものを作る
　　　　・CPUはchisel、コンパイラはRust、仕様書はAsciidocで作成し、GitHubで管理
　　　　・CPUは独自命令、48bit、ハーバードアーキテクチャで作成する（これらの点がオリジナリティである）
　　　　・週1回、2h程度のモブプロを、VScodeのliveshareとDiscordの音声チャンネル使用して行う

そんなこんなで、再度良い感じに決まったのですが、、。

ゆ：「あれ、全部自作するんじゃないんですか？？最初から日本語やプログラミング言語を使っちゃうんですか？？？」

・・・・（さすがに日本語を使って）続く