全体的に各種シミュレータやテストが提供されているので、それをパスすることを目指して作っていけます。テストが用意されていることでかなり実装しやすく感じました。テストプログラムが各ソフトウェアの完成度に合わせて用意されているので、一度に全部作る必要はなく段階的に実装することが可能です。ちなみに各ソフトウェアは自由な言語で記述できるので、私はRustを使いました。

パーサの実装について

パーサを実装しやすいようにJack言語はシンタックスが工夫されています。この頃たまたま「実践Rust入門」を読んでいて、パーサの実装に関して記載があったので参考にした記憶があります。

また途中でパースしたものをXMLで吐き出しそれをテストする流れになっていましたが、少し面倒だったので私はメモリ上でASTを作りました。

gihyo.jp

APIについて

各所で実装するプログラムはAPIが提示されているのですが、個人的には基本的には従うが完全には従わなくてもよいと思いました。実装に使う言語によってはよりよいインターフェースがあるはずです。

nand2tetrisのアセンブリパーサのAPI、ちょっと実装しづらい…
— ゆいき (@yuikijp) 2021年4月16日

コンパイラについて

実装したコンパイラは、単純化のために例えばほとんどの演算子の優先順位が不定です。そのため、私は標準ライブラリの実装でコードをかなり書き間違えてしまい大変でした。独自拡張として、慣れ親しんだ優先順位で解釈するコンパイラを作るのもありかもです。

括弧以外の演算子の優先順位が不定な言語でプログラム書くのしんどすぎるな
— ゆいき (@yuikijp) 2022年2月16日

制限

書籍としては完了したのですが、Pongを自前のVMやアセンブラを使って動作させることはまだできていません（速度の観点で）。最適化に関しては今後やる気が出たらやろうと思います。

大学の講義との関連

要所で大学で受講した講義のことを思い出しました。

1〜3章（論理回路）: 「論理回路実験（ブレッドボード上で論理ゲート等を組み合わせてカウンタなどを作る）」
4章（機械語、アセンブリ）: 「コンピュータシステムとOS（アセンブリを書く）」
10章（字句解析、構文解析）:「オートマトンと形式言語」、「プログラム言語処理（パーサを一部実装する）」
12章（標準ライブラリ）: 「主専攻実験: 組み込みOS（GBAのゲームを作る）」

大学のおさらい（一部）としてもなかなか良かったと思います。

まとめ

概念レベルでは知っていることも多かったのですが、ある程度動くものを一気通貫して作るという点では実際やってよかったと思いました。

*1:Noam Nisan、Shimon Schocken 著、斎藤康毅訳

*2:そもそも序盤はうろ覚えです…。

*3:テトリスではないことはよく知られています。

*4:memory-mappedです。

2021-08-22

ISUCON11 予選に参加しました

ISUCON

学生チーム "haigyo" としてISUCON 11予選に参加しました。
チームメンバは双方初参加の sudame と wakki です。全員慣れてるNode.jsでの参加でした。

2021-05-29

Dagger HiltのenableExperimentalClasspathAggregationオプションについて

Android

少し前の話題ですが、取り上げている記事が見当たらなかったためまとめます。

前提

Androidプロジェクトにおいて3つのモジュールが以下のような依存関係にあったとします。

app -> intermediate -> db

appモジュールはApplicationクラスを持ち、モジュール間の依存関係はimplementationで記述されているとします。

このとき、マルチモジュールの利点の1つとして、
appモジュールがdbモジュールに直接依存していないことによって、dbモジュール内のコードを直接参照することを防ぐことができます。 … (1)

問題

Dagger Hiltではルートのappモジュールにおいて全てのインスタンスを生成するためにそれらに直接参照できる必要があります。

つまりDagger Hiltを利用しようとすると、
appモジュールがdbモジュールに直接依存するか、intermediateモジュール内でdbモジュールへの依存関係をapiで定義する必要があります。 … (2)

これだと先ほどのマルチモジュールの利点 (1) が失われてしまいます。

github.com

解決策

この問題のワークアラウンドとして、Dagger Hilt 2.31.x-alpha以降からappモジュールの build.gradle ファイルに以下のような記述をすれば (2) の対応を行わずとも (1) の利点を保つことができるようになります。

hilt {
    enableExperimentalClasspathAggregation = true
}

ただし、まだExperimentalです。

詳しくはこちら dagger.dev

ざっとしかコードを読んでいないのですが、遷移的依存関係をコンパイル時に利用できるように CompileOnly コンフィグを利用して依存関係を処理しているようです。

https://github.com/google/dagger/pull/2154/files#diff-074bfa3b2e7f8ced706b26436ee5ae320b798417cae69aa14b50a348fec73712R169-R195

このような処理を行っているので、ビルド時処理が増えてしまいます。

これに関しては、以下のように述べられているので今後改善していくと思われます。

This solution is inefficient and will cause build performance impact, but it is a starting point that can be further optimized by using a smarter transform that can extract the necessary classes required by Dagger and Hilt.

github.com