予定

今まで最適化について検討と検証をいろいろやってみました。

ソースコードは検証目的で書いてたのであんまりすっきりした書き方にはなってないです。しかし、最適化を行う上でのプログラム構造の問題も見えてきました。

この辺で、いったんソースをきれいに書き直して、今まで考察した内容を全て反映したバージョンを作ろうと思います。

ポイントとなるのは、フラグレジスタをブール型変数8個にすることと、レジスタ変数などアクセス回数が多いものは、ローカル変数にすることです。

いや、1で固定されてるフラグは必要ないので7個ですね。

トランスレートしたコード実行と、エミュレーション実行を切り替える際に、レジスタ変数を引き継ぐために、現状だと値をコピーしてますが、このオーバーヘッドを無くすために、エミュレーションコードとトランスレートコードを同じメソッド内に共存させる構造にしようと思います。

かなりオブジェクト指向のかけらもないコードが出力されることになりますが、まあ出力したコードを普通は見なくて良いはずなので気にしないことにします。
出力されたコードを読まないといけない場面に直面するのは、これの開発者だけなので。

フラグレジスタの演算は、論理演算子三項演算子の組み合わせになります。それが効率のいいコードにコンパイルされるといいのですが。

あー、それからこの際なので、Javaに持って行くことを意識して、プロパティとかJavaにない機能を使っているところをただのメソッド呼び出しに変えたりとかもやってしまおうと思います。

ていうか、トランスレータだけをC#で組んで、エミュレータJavaアプレットにしてしまった方がいいかもしれないですね。

ついでにVRAMのミラーがなんか変なのを直そうと思います。

あと、不要なフラグレジスタ操作の除去を行う最適化をもっと強力にしようと思います。
現状は、分岐命令を間に挟んだ場合は最適化されないようになってます。分岐があると、使っているフラグを調べるのが難しくなるので、分岐命令は全てのフラグを使用する扱いにしています。

分岐先のアドレスを静的に確定できる場合がほとんどであることが分かってきたので、そのような場合は分岐先で使っていないフラグの操作を削除しちゃいます。
これは、たぶん再帰処理で書くことになりそうです。
できれば再帰じゃないアルゴリズムの方がいいんですけどね。

現状、昨日までの最適化で、6502の1フレーム分の処理が0.77msまで縮まったのですが、上に挙げた内容を実装するとどこまで速くなるでしょうか。
正直、目標値である0.08msはきついと思います。
何かのブレイクスルーが無いと、もう一桁の高速化は厳しいでしょうね。
なにかアイディアを思いつくといいのですが。

もうちょっと具体性のある技術情報もブログに載せていければいいんですけど、大抵は携帯で文章を書いているので薄っぺらな文章になっちゃってますねえ。