memo0004 のバックアップ(No.35)

Kの開発メモ #0004

(by K, 2013.04.23)
ここは川合の開発の進捗などをレポートするところです。

↑

2013.04.23 Tue

今日は定数同士ではない演算の最適化パターンをいくつか登録しました。
- !(R10 < 100) が R10 >= 100 に変換されるとか（→これはif文のサポートのためにほしかった）。
- R00 = R01 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10; は R00 = R01 + 55; になるとか。
- R01 = R02 * 0; が R01 = 0; になるとか。
- パターン方式なので、複雑な書き方をするとあきらめてしまいます。まあアセンブラなのでその程度で十分かなーと。
現在のサイズ：
- osecpu.exe : 10.0KB
- osectols.exe : 14.0KB
osectolsが大きくなっていますが、osecpu.exeのデバッグ用のツールまで内包したので、大きくなるのは気にしないことにしました。どうせこれはバイトコードに移植してしまうので、大きくなってもOSECPUの移植性に影響しません。
今日の成果:
- http://osecpu.osask.jp/download/osecpu031a.zip

↑

2013.04.24 Wed

時間がなくてなかなかif文に取り掛かれません・・・。
今日の成果:
- （少しバグ取りした程度です。）
- http://osecpu.osask.jp/download/osecpu032a.zip

↑

2013.04.25 Thu

よしif文ができた！
- 「&&とか||がなくて、&と|で代用しなければいけない」ってあたりは正直微妙だけど、x86用のASKAは&とか|すら全部できなかったわけで、あの頃と比べればこれでも格段に便利だ！
そろそろアプリを作って、このサイトをもうちょっととっつきやすくしないとなあ・・・。
今日の成果:
- http://osecpu.osask.jp/download/osecpu033a.zip

↑

2013.04.26 Fri

アプリを少し整理しました。
今日の成果:
- http://osecpu.osask.jp/download/osecpu034a.zip

↑

2013.04.30 Tue

昨日作ってしまったosectolsのバグをやっつけた。
現在はosecpu.exeの一部をOSECPU-ASKAで書くという、おもしろいことをやっているところ。
- 機種依存しない部分は、osecpu.exeから追い出したいと思っているので。
- というか昨日はこれをやろうとしてosectolsにバグを作ってしまったのだ。
やっとapp0000だけならフロントエンドコードでも実行できるようになった。これからサポートできるフロントエンドコードを増やしていく予定。
- 実際にosecpu.exeの下請けとして実用コードを書いてみると、OSECPU-ASKAの微妙なバグとか、osecpu.exeのJITコンパイラのバグとかがぽろぽろと見つかる。今はバグを取らずに回避して書いているけど、そのうち直したい。

↑

2013.05.01 Wed

とりあえずapp0002まではフロントエンドコード対応した。もう少しいじって、いったんリリースするつもり。不安定リリースだけど。
さっきふと気づいたこと。OSECPUでは機械語が三項形式になっているけど、これだと単純な代入命令（CP命令）はあまり使わないということが判明。まあ自分の体験談でしかないけど。
- http://www.mztn.org/lxasm64/freq64_32.html これとは大違いだなあ。
- レジスタがたくさんあることも関係しているかもしれない。

↑

2013.05.02 Thu

テストアプリは全部フロントエンドコード対応した。
APIのレジスタの使い方を元に戻したので、コードリビジョンをさらに増やした。
今日の成果:
- http://osecpu.osask.jp/download/osecpu035a.zip
- アプリのサイズがまともになっています。まあ今までがひどかっただけではありますが。
- osecpu.exeから機種依存しない部分を切り離す改造を入れています。

↑

2013.05.03 Fri

関数呼び出しの仕様を整理していたら、不満が爆発。OSECPUがいろいろと気に入らない。
- Pxxはどうして32本しかないんだ。やっぱり64本必要だ。
- プログラムカウンタはP00じゃなくてP3Fであるべきだ。
- R00～R0Fがテンポラリレジスタなのは使いにくい。R30～R3Eがテンポラリになるべきだ。
今ならいくらでも修正できるのだから、何度でも修正して考察して、納得いく仕様を探すべきだ。

↑

2013.05.07 Tue

現在ちまちまと上記改良を適応中。
やっとバグが取れて動くようになった。
このレジスタの使い方には満足しているので、当分変えない予定。

↑

2013.05.08 Wed

ちょっと時間ができたので、いろいろ書いておく。
まず、OSECPUはJavaよりもセキュアかどうかという点に関しては、現状では明らかに負けているし、将来についても追い越せる保証はない。
- まあほぼ同程度には追いつけるかもしれない。
Javaと違うところといえば、レジスタマシンであることと、ガーベージコレクションを使わないことだろうと思う。あとポインタもある。
- これが機能的な特徴かな。
- だからOSECPUは、Javaもどきを作ったというよりは、C言語もどきを目指しているといった方が近い。
- C言語のプログラミングスタイルの延長で、相応のセキュアさを実現しよう、と。
性能面での特徴としては、Javaよりも実行開始までが高速で、実行速度もそんなに負けないんじゃないかと思う。
- これはベンチマークしないと比較できないなあ。
あとはosecpu.exeもアプリも極端に小さい。
移植は容易だと思う。

↑

2013.05.10 Fri

昨日はループのフロントエンドバイトコードを改良した。
あとは関数呼び出しのフロントエンドバイトコードを改良したい。
そこまでできたら一区切り。

OSECPUを機能密度の高さでアピールするとしたら、何で示すのが分かりやすいかな。
- hello対決：予定18バイト（シグネチャが4バイトなので）
- chars対決：予定13バイト（シグネチャが4バイトなので）
- カラーグラデーション対決（app0006のこと）：
- bball対決：
- invader対決：

↑

2013.05.14 Tue

カラーグラデーションは、28バイトで書けそうなことが分かった。APIの仕様をつめれば27バイトまでいくかもしれない。
- と思ったら24バイトになってしまった。われながらすごい。APIの仕様をつめれば23バイトも可能じゃないかと思う。
いろいろできた。でもまだテストが終わってないのでリリースできない。アプリの小ささが我ながら驚異的。

↑

2013.05.15 Wed

さらにもう少し改良して、リリースできるところまで来た。
今回のバージョンアップポイントは、機能密度を追求したこと。
- カラーグラデーションは22バイトになった。APIの仕様を詰めれば21バイトも可能だと思う。シグネチャが4バイトもあるのにこのサイズにできたことはかなりがんばっていると僕は思う。
今日の成果:
- （今夜アップロード予定）
- http://osecpu.osask.jp/download/osecpu036a.zip

↑

2013.05.16 Thu

長い間サポートしてこなかった（整数）除算命令をついにサポート。
OSECPUにラインを引くAPIを追加して、bball対決をしました。bball対決というのは、以下のような画像を描くのにどのくらいの大きさのアプリを書かなければいけないのかというものです。
```
第一世代OSASK       199バイト
TownsOS             185バイト
MS-DOS/NEC PC-9801  114バイト
Human68k+IOCS       116バイト
MSX-DOS/MSX2        140バイト
「はりぼてOS」      350バイト（改良の余地あり、参考記録）
OSECPU               92バイト
```
- OSECPUは2位と1.24倍もの差をつけて圧勝しています！
他にもアプリを書いたのですが、とにかく何を書いても小さくなってくれる感じなので、楽しくてたまりません。
- これを表示するためのプログラムは27バイトです。
今日の成果:
- http://osecpu.osask.jp/download/osecpu037a.zip

↑

2013.05.17 Fri

あれこれ言い訳をして、中途半端になるのはきっとよくない。だからこうしたい。
- シグネチャを2バイトにする。
- API番号をまともにする。
まともにしたらこうなった。
- グラデーション（app0006）： 28→23
- グラデーション（枠なし、app0020）： 22→19
- XORのlines（app0022）： 27→22
- bball（app0023）： 92→86
- app0019： 2254→334
今日の成果:
- http://osecpu.osask.jp/download/osecpu038a.zip
おっと、app0019は簡単に313バイトに減らせることが分かった。・・・もっとがんばればもっとできるかもしれない。

↑

2013.05.19 Sun

改良方法を複数思いついた。これをやればいずれのアプリもさらに小さくなる予定。
- グラデーション（app0006）： 23→18?
- グラデーション（枠なし、app0020）： 19→13?
- XORのlines（app0022）： 22→21?
- bball（app0023）： 86→71??
- app0019： 313→???
時間ができたらこの改良を適用したい。

↑

2013.05.20 Mon

上記の数字はほぼ達成。でもフロントエンドからバックエンドに変換するプログラムがまだできてない。
- グラデーション（app0006）： 18
- グラデーション（枠なし、app0020）： 13
- XORのlines（app0022）： 20
- bball（app0023）： 71
- app0019： 313→???
自分で言うのもなんだけど、これ以上の改善は不可能なんじゃないかと思う。基本エンコードをhh4からレンジコーダに変えたらあるいはもう少し減るかもしれないとちょっと思うけど、でもそれも容易ではなさそうな・・・。
- そしてレンジコーダを入れたら、メモリダンプから中身を読むのはほぼ不可能になりそう。まあtek5圧縮したら同じくらい読めなくなっているけど。
- ちなみにapp0019以外は、tek5するとかえって増えてしまう。つまりそれくらい既に高密度になっている。

↑

2013.05.21 Tue

app0019はtek5しなくても702バイトで書けるようになり、tek5すると297バイトになる模様。300を切れたのはうれしい。
- というか無圧縮でも702バイトって、それは結構すごいんじゃないか？
僕は学生の時に雑誌に載っているバイナリダンプをせっせと入力していたのだけれども、あの時代にこの機能密度が発明されていたらなあ。僕は入力量を大幅に減らせたんじゃないかと思う。
今日の成果:
- http://osecpu.osask.jp/download/osecpu039a.zip

↑

2013.05.22 Wed

(1)そうかー、03/19から作ってきたわけだから、約2ヶ月でここまでできたのかー。僕にしてはすごくハイペースだなあ。
2ヶ月の間に、CPUの仕様の設計と改良、JITコンパイラの開発、アセンブラ（コンパイラ？）の開発、サンプルアプリの開発、機能密度の追及までやってしまった。言語処理系に関して言えば、今利用しているもののうち、プリプロセッサ以外は全部作ったことになる。
しかもOSECPUは僕の今までの集大成みたいなところもある。第一世代OSASK、第二世代OSASK、第三世代OSASKの設計、ASKAの設計、nask、GO、SGOの設計、tek、blike、エミュレータ的要素（JITコンパイラ）のすべての要素が入っている。そして間違いなく今までで最高の機能密度だ。最高傑作であることは言うまでもない。
(2)app0024（旧app0019）は、273までは減らせそう。無圧縮では681。もちろんOSECPU側のさらなる改良も必要。
- 256に行けたらすごいと思ったけど、さすがにそれは無理っぽい（笑）。

↑

こめんと欄

コメント	お名前	NameLink