yao の変更点 - osecpu-wiki

追加された行はこの色です。
削除された行はこの色です。
yao へ行く。
yao の差分を削除
* yaoのページ
-(by [[yao]], since 2013-09-21)

- [[OSECPU-Lisp>https://github.com/yuta-aoyagi/osecpu-lisp]]の作者です。
- ご意見・質問などありましたら、下のコメント欄などにお気軽にどうぞ。
- このwikiのページは更新があるたびにひととおり読んでいます。

** 目次
#contents

** OSECPU-Lisp
- OSECPU-VM上で動作するPure Lispのインタプリタです。

- 今後OSECPU-Lispに関することはここに書いていきます。
- 2013-09-21現在、OSECPU-Lispのチュートリアルを書いています。%%数日中に第1版を公開する見込みです。%%
2013-09-23、第1版(コミットID: f5fde0d688)を公開しました。
- 2013-10-19、第2版(コミットID: de4e847063)を公開しました。
- リポジトリをクローンして( git clone https://github.com/yuta-aoyagi/osecpu-lisp.git )、「git diff (AのコミットID) (BのコミットID)」を実行するとAとBの変更点を読めます。

** OSECPU-compilers
- 自己記述できるコンパイラを作ろうというプロジェクトです。
- 最初のリリースは1024バイトコンテストには何とか間に合った(はず)。
-- 先に「リリース」とだけ書いたこのページの編集は、このwikiの時刻で10/23 23:59:56になっています。
-- (近い時刻の編集はPukiWikiのバックアップに残らなかったような気がするので一応主張しておきます。)

リリース. http://www16.atpages.jp/aoyagi/data/c000.tgz

- この最初のリリースはドキュメントもなしにtgzで固めただけなので、後でちゃんとしたリリースをやり直します。
- c000は、普通に考えられる中でもっとも低級なアセンブラです。
-- 入力からコメントを取り除きオペコードを変換して、16進ダンプを生成します。
-- この出力をapp0031.oseに渡すことで任意のバイナリを生成することができます。
- リンクしたアーカイブを展開して「make BINTRANS=(app0031.oseへのパス) build」で自身のコンパイルを行います。
-- ブートストラップのため、1段目を手で実行したものがアーカイブに同梱されています。
- コンパイルに成功したら(diffにPATHが通った状態で)「make check」を実行すると自己生成に成功したかどうかがテストされます。
-- エラーが発生しなければ成功です。

- さて、1024バイトコンテストに応募するための要件ですが、出力されるバイナリはバックエンドコードで840バイト、これにappackをかけてフロントエンドコードを得ると212バイト、さらにappack flags:8をかけて最終サイズが211バイトです！
-- (「当初は512バイト切ればいいなー」と思ってたのに半分未満とは……さすがOSECPU-VM、常識が通用しない。)
-- というわけで、QRコードの271バイトの部に応募できますね。よろしくお願いいたします＞Kさん

** 進捗報告
*** 2013-11-29
- ずいぶん久しぶりなので進捗を書いておきたいと思います。
- (1)Linuxの導入
-- 1024コンテストの後、開発に使っているWindows機にLinux(Damn Small Linux)をQEMUとともに導入、OSECPU-VMのLinux版ビルドを試みる。
-- 名前のとおり小さいディストリビューションなのでGTKはなく、フレームバッファ版のblikeをビルド(このあたりがよくわかっていない)。
-- うまく動かなかったので、osecpu.cからウィンドウを扱っているコードをコメントアウトしてビルドし、コンソールアプリだけは動くことを確認。
- 番号つけたのはいいけど、進捗に書けることは(1)しかなかった。今はOSECPU-VMと関係のないプログラムを開発している。今年中に最初のリリースを行う予定。
- その後はOSECPU-VMに戻って、
-- OSECPU-Lispのチュートリアル拡充
-- OSECPU-Lispにquote構文を導入
-- OSECPU-compilersのちゃんとしたリリース
-- まだ構想段階の(ため明言はしたくない)プロジェクト2つ
- などをやりたい。

*** 2014-03-15
- 「ずいぶん久しぶり」から3か月半も経ってしまいました。何やら新しいプロジェクトが動き始めたようなので、こちらも進捗報告の時間です。
- 「進捗どうですか？」「進捗ダメです」
- (1)VPS契約(2月上旬)
-- 前回の報告にあったWindows機がお亡くなりになりマシンが1台減ったので、どうせならLinux使えるところで何か経験しようということで。
-- ちなみにこのWindows機に仮想Linux機を置いていたので、今は使えない状態になっている。(ディスクは無事だったのでその気になれば取り出せるが)
-- まだOSECPU-VM関係でなにかやろうという環境にはなっていない。
- (2)新規プロジェクト「JSECPU-VM」始動(2月下旬)
-- (先に、前回の報告にあった「OSECPU-VMと関係のないプログラムを開発」のところ。開発する動機がなくなってしまったのでリリースともども破棄した(2月上旬))
-- 名前だけで察していただけると思うけど、OSECPU-VMのJava実装である。
-- 標準のosecpu.exeを可能な限り再現すること、VMに統合されたデバッガとプロファイラを実現、可能な限り高い自動テストカバレッジ、前の3項目を犠牲にしない範囲で高速な実行、前の4項目を犠牲にしない範囲で読みやすいコードベース。以上の5項目を並べた順に目標としている。
-- 現在のところ、バックエンドコード記述のapp0000とapp0001が実行できる。(というかそれしか実行できない。さっさとラベルの対応をまともにするべし、と)
- (1月下旬に書いたメモより)
-- OSECPU-VMプロジェクトへの貢献は、周りへの影響が大きい順に次の5種類があるように思われる。
+++ VM仕様自体の改善。
+++ 標準の実装osecpu.exeの改善。
+++ VMを他のプラットフォームに移植。
+++ バックエンドとして使う(典型的には言語処理系)。
+++ アプリを作る。
-- 単にアプリを作る(e.)よりは、VMを移植すれば(c.)すでに存在するすべてのアプリの移植が済んだことになり、影響が大きい。VM仕様自体を改善すれば(a.)、またさらに影響が大きい。上のリストはそのような観点で並べられている。
-- これまでの活動は、osecpu.exeのバグ報告(b.)、OSECPU-Lisp(アプリなのでe.だが、言語処理系なので同時にd.でもある)、OSECPU-compilers-0(同様にd.とe.に該当)といったところである。
-- バグ報告はバグを見つけられないとできないので、a.やb.にあたる貢献は私の力ではそろそろ難しくなってきている。
-- 以前のプロジェクトはd.やe.だが、ある程度規模が大きいアプリを開発しようとするとデバッガの支援がないと辛い。
-- したがって、デバッガを含むVMを新たに開発することにした。
-- 標準のosecpu.exeにデバッガを実装するというb.の貢献も考えたが、Javaプラットフォームに載せられればさまざまな携帯機器も視野に入ってくるので、あえてc.の活動を始めた。

*** 2014-07-30
- 「「ずいぶん久しぶり」から3か月半も経って」からさらに4か月半です。
- なんといっても最大の変化はrev2のリリースでしょう。
- rev1時代にセキュリティにかかわる重大なバグを見つけて(2014-04-02)修正されるまで活動を中断しようと思っていましたが、修正されなかったのでずいぶんと長いお休みになってしまいました。
- rev2がリリースされあれよあれよと機能面でrev1に追いつき、面白いことができそうになってきたので活動再開です。
- ここ2週間ほどちまちまコードを書いてはいますが、しばらく忙しいのでいつ公開できるかは全く未定です。
- <追記 date="2014-08-01">
- (言うまでもなさそうですが報告として) 以下のプロジェクトを凍結します。
-- OSECPU-Lisp・OSECPU-Compilers・JSECPU-VM(rev1)
--- (いずれもrev1専用ですがrev1の開発は中断しているため)
-- Forthインタプリタ(5月中旬/未公開のまま)
--- (rev1専用であり、また、indirect threded codeの実行ができるようになったところで飽きたため)
-- RubyのDSLとして実装されたrev2(osecpu106a)向けアセンブラ(5月下旬/未公開のまま)
--- (うかうかしているうちにosecpu109aがリリースされて不要になったため)
- 下2つはメタプログラミングのいい勉強になりましたけどね。前者はASKAコードをRubyで生成しただけですが、後者はDSLのコードを生成するDSLを書くところまで洗練させてしまったので(メタ)^2プログラミングと言えるかもしれません。
- </追記>

- <さらなる追記 date="2014-08-18">
- ちょくちょく進捗報告するとモチベーションを維持しやすいので、さらに追記です。
- 私の趣味(開発の傾向)を知っている人なら、rev2が標準入出力に対応してから始まった開発であるというヒントから何をしているか分かるかもしれません。そうです、言語処理系です。
- R5RS(Revised^5 Report on the Algorithmic Language Scheme)のうちrev2で実装できないのはほんの数か所でしかないので、それ以外の全機能を実装することを目標の一つとしています。
- 現状、関数readとwriteのごく一部だけが動作するようになっています。
- これほど開発が遅いのは、忙しい以外に理由がもう一つあります: ASKAを改善するツールの開発から行っているからです。
-- ある程度大きなプログラムの開発になると、ASKAを直接使っていては不便なことが出てきます。
-- そこで、ASKAソースを出力するようなトランスレータのごく薄い層を開発しています。[1]関数定義の定型パターンの生成、[2]ラベル番号の管理、[3]Doxygenによるドキュメント作成のごく小さなサポート、の3点が今のところ実装されています。
-- [1]例えば[[page0095]](1)の関数funcなら
 defun(, @[func@], @[_r, a, b@], @[R30 = a; R31 = b; @], @[; _r = R30@], @[
     Int32s a:R30, b:R31, r:R30;
     r = a + b;
 @])
-- と定義できるようになります。
-- ちょっと苦しいですがdefun((後述), 関数名, 引数, 入力の定義, 出力の定義, 処理本体)と読めないことない、といったところでしょうか。
-- 上の記述から、[a]L_funcからLOCAL(n)へのマクロ定義、[b]func(_r, a, b)のマクロ定義、[c]処理本体を囲む beginFunc(L_func); do { ～ } endFunc(); 、の3つを自動的に生成します。
-- [2]defunが内部で使っているdeflabelがLOCAL(n)を管理しています。これを直接使えば、関数以外のラベル(データ定義・goto文のラベル)も定義できます。
-- ラベル番号が自動的に管理されるので、その副作用として、上記のdefun定義だけを別のファイルに書いておいてincludeできるようになります。
--- その直接の帰結として、テストドライバから関数定義をincludeしてユニットテストができるはずです。(これは必要になりつつあるのでサポートに加える予定です)
--- また、一群のdefun定義を集めたファイルをincludeすることができるということは、ソースコードレベルのライブラリを作成・配布できることをも意味します。
--- (defunの定義自体は汎用のマクロプロセッサGNU m4で書かれているので、書いているプログラムに応じた拡張を自由に定義できます)
-- [3]上の例ではdefunの第1引数は空ですが、ここに書かれたものは[b]のマクロ定義の直前に展開されます。
--- DoxygenでASKAソースをC言語として入力すると、マクロ定義と一部の変数定義を認識してくれます(ノイズもたっぷり拾うので、これを除去するフィルタも開発中です)。
--- そこそこ見栄えのするドキュメントがコードから自動生成されるので見ていて面白いです。
-- (とまあ、都合のいいことばかり書いてきましたが、強力なマクロによるメタプログラミングなので、管理できずに破綻して生のASKAに書き直す可能性もありえます)
-- というわけで、開発が遅いのはrev2用の開発環境を作るのに凝っているから、という話でした。
- 中間コードの最小限のインタプリタができたあたりがいいタイミングだと思うので、秋の終わりごろ開発を公開に切り替えるつもりです。
- </さらなる追記>

- <追記 no="3" date="2014-09-01">
- 上で述べたユニットテストがサポートに加わりました。`make -kC tests'というコマンドで、今のところ4つのテストケースが(コンパイル込み)数秒で走り、37の表明を検査しています。
- テストケースでDAT_SAを変える必要が出てきたので、DAT_SAの要素数を人間が数えなくて済むようなサポートを実装しているところです。
- </追記>

- <追記 no="4" date="2014-09-17">
- 上で述べたDAT_SAのサポートが加わりました。何件かのテストケースでうまく動いているようです。
- そのほかには、今開発している以外のASKAプログラムに流用可能なマクロを抽出したりしてます。
- これだけ手間をかけているのに実行されるべきコードがほとんど増えていないのが泣けます。
-- 手間をかける場所を間違っているというのは認識してますが、こういう開発はある種の趣味ですので。
- </追記>
// [[members]]

** コメント欄
-うわあああ!す、すまん…すまん…(・＿； じつはblikeのlinuxフレームバッファー版はずいぶん前から壊れてまして… -- ''けめっぽ'' SIZE(10){2013-11-30 (土) 17:33:12}
-すまん…すまん…(・＿； というかOSECPUのドライバー部分、私と違ってもっと優秀な誰かが(blikeを介さずにもっと誰でもメンテできるように一般的なライブラリーで)書き直してくれると、いいな…と思っております。 ちら…ちら… -- ''けめっぽ'' SIZE(10){2013-11-30 (土) 17:37:07}
-おお！yaoさんが帰ってきた！！ -- [[K]] SIZE(10){2014-07-31 (木) 06:51:06}

#comment