memo0004 の編集 - osecpu-wiki

* 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
//-app0016.askですが、これをまじめにフロントエンドエンコードしたら30バイトになることを確認しました。もちろんシグネチャ4バイトは削っていません。
//--ちなみに現状は106バイトというとんでもないことになっています（笑）。
// OSECPU_HEADER();
// 
// for (R02 = 1000000; R02 != 0; R02--) {	// j:R02
//     R01 = 0;
//     for (R00 = 10000; R00 != 0; R00--) { // sum:R01, i:R00;
//         R01 += R00;
//     }
// }
//--これで30バイトってことは、シグネチャ以外の正味の部分は26バイトというわけで、x86の32bitモードと比較すれば、6バイトしか多くない。
** 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対決というのは、以下のような画像を描くのにどのくらいの大きさのアプリを書かなければいけないのかというものです。
~
http://osecpu.osask.jp/download/bball.png
 第一世代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倍もの差をつけて圧勝しています！
-他にもアプリを書いたのですが、とにかく何を書いても小さくなってくれる感じなので、楽しくてたまりません。
~
http://osecpu.osask.jp/download/app0022.png
--これを表示するためのプログラムは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に行けたらすごいと思ったけど、さすがにそれは無理っぽい（笑）。
** 2013.05.24 Fri
-ver.0.40へのtodoをまとめて、詳細を設計した。
--PADDLMEM, PADDSMEMという複合命令のサポート
--関数記述支援
--文字列表示APIをまともにする（9バイトでcharsが書けるようになる？！）
** 2013.05.27 Mon
-関数記述支援のためにENTER/LEAVE命令を作ってみたものの、なんか動作がおかしい。どうなっているんだ・・・。
** 2013.05.28 Tue
-昨日のバグ： JITコンパイラが生成するx86コードでスタック操作がおかしくなっていた。そりゃ死ぬよな・・・。

-app0024が273まで減らせそうとか書いたけどそれは無理っぽい。280くらいが限界かと思われる。無圧縮では680。
--なんかくやしくて小さくする方法を探したけど、そう簡単には改良できそうにないので保留に。

-charsの9バイトと、helloの16バイト版を実装。まあいろいろと問題はあるんだけど、とりあえずということで。
--helloは末尾に!を付けています（efg01版では付けていなかった）。それで16バイトです。付けなければ15バイトにできます。ASCIZ文字列に対して、ファイル終端なら0x00を省略できるという仕様を追加したためです。
--charsの世界一記録をついに奪還。

-システムライブラリが大きくなりすぎだよな・・・。どうしたものかなあ。まずは重複部分をまとめて小さくする努力をするべきかな。

-今日の成果:
--http://osecpu.osask.jp/download/osecpu040a.zip

** 2013.05.29 Wed
-1週間くらい前から、Livaさんという人に開発を手伝ってもらっています（今はここ以外のところで連絡を取り合っています）。まだダウンロードしてちょっと遊んでもらっている程度ですが、「ここをこうしたらどうか」みたいな提案ももらっていて、とても助かっています。

-charsとhelloをさらに小さくしたので、今夜リリース予定です。

-LivaさんがMacOSへの移植を開始した模様。とりあえずコンソールアプリはすでに動くらしいです。

-MacOSのgccで、Cの関数をアセンブラ（というか機械語）から呼ぼうと思ったら苦戦。結局、本来の引数以外にも引数が必要らしく、末尾にEBXの値を積んだらおとなしくなりました。
--末尾＝最初にPUSH。
--https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#//apple_ref/doc/uid/TP40002492-SW4
--ここにはEBXを勝手に使うなみたいなことは書いているけど（Table 3）、引数リストにも追加しろなんて書いてないよう。それで失敗の連続。
--しかしLivaさんが偶然EBXを積んでみたら通ったと教えてくれて、無事に解決したのでした。
--今上記ドキュメントを読み直したら、スタックのアラインがどうのこうのって書いてあるから、そっちが原因だったのかも。
--結局アラインだけの問題でした。めでたしめでたし。・・・それならSegmentationFaultじゃなくて、AlignmentErrorとかのエラーメッセージにしてくれればいいのに・・・。

-今日の成果:
--http://osecpu.osask.jp/download/osecpu041a.zip
--http://osecpu.osask.jp/download/osecpu042a.zip
--http://osecpu.osask.jp/download/osecpu043a.zip

** こめんと欄
-CLEではC言語ルーチンを呼び出す直前にスタックアラインしてiます。 -- ''neri'' SIZE(10){2013-05-30 (木) 10:01:37}
-途中でエンター押してしまった。。ちなみにCLEはOSX版が最初のターゲットで当時はブログ書いてなかったのでその辺りの記事は存在しません。 -- ''neri'' SIZE(10){2013-05-30 (木) 10:03:49}
-おお！さすが！！・・・やっぱり先人は違うなあ。 -- ''K'' SIZE(10){2013-05-30 (木) 10:40:37}

#comment