Kの開発メモ #0008
- (by K, 2014.05.01)
- ここは川合の開発の進捗などをレポートするところです。
2014.05.01 Thu
- OSECPU-VMのrev2の最初のバージョンをリリースしました。まだテストしかできません。
- page0074
- で、まあこの段階であれこれいう気にはならないだろうけど、しかしもし何か意見があったら下の「こめんと欄」で教えてください。特に「これじゃあまだぜんぜん読みやすくなってない、ここはこうしたほうがいいんじゃないの？」みたいな突込みは歓迎します。
2014.05.02 Fri
- いろいろとソースに手を加えているところ・・・。
- うわー、昨日のosecpu101aは結構バグバグだった・・・すみません。
- とりあえず今日のところまでをリリース。構造体名はhikarupspさんの提案を採用しました。→page0074
2014.05.07 Wed
- 今日は分岐処理を書いています。
- ところで、一応確認なのですが、このソースはrev1の頃よりは読みやすいんですよね？？？
- テストしていたらfloat.cにバグ発見。直した。
- hh4Decode関係をためしに改造中。
- さて行数は減るのか？・・・減りそうな予感。
- この結果は明日のお楽しみ。
2014.05.08 Thu
- hikarupspさんとttwilbさんがhh4Decode族の仕様に不満を持っていたので、根本的な構造を見直しました。確かにその方が格段にすっきりですね！
- hikarupspさんが改造案を提示してくれたので、できればそれを使おうかなと思ったのですが、とりあえず自分で作りかけていたほうがより短そうだったので、今回は取り込まずにそのままにしました。
- とりあえずRev1のころよりも読みやすくなったと感じてもらえているようなのでよかったです。
2014.05.14 Wed
- data構文を作りかけです。
- これができるようになったらメモリアクセスやポインタ演算を作ります（そうでないとテストがやりにくいので）。
2014.05.15 Thu
- JITC版のフレーズ高速化のことはどこに書いたかなーと思ったら、page0022にちゃんと書いてあった。
2014.05.22 Thu
- とりあえず現時点での短期的な目標：
- 6月中旬までに、ASKAでアプリを書けるようにしたい。できればrev1相当のことができるようになりたい。
- そうすれば、セキュリティキャンプで学生が使ってくれるので、バグ探しがはかどる。
- ということで、構造体サポートは急がない。
- hikarupspさんが、hh4に興味を持ってくれたのはうれしい。
- data構文はとりあえず動いているようです。
2014.05.23 Fri
- OSECPU-VMを名乗る最低ライン（レベル0）：
- セキュリティチェックは一切なしでもOK（だからbit[]もいらない）
- Rレジスタは16ビット
- FレジスタはなくてもOK
- 構造体サポートも省略
- APIは互換性がなくてもよい
- OSECPU-VMの実装レベル1：
- セキュリティチェックは一切なしでもOK（だからbit[]もいらない）
- Rレジスタは32ビット
- FレジスタはなくてもOK
- 構造体サポートは必須
- APIは互換性がなくてもよい
- OSECPU-VMの実装レベル2：
- セキュリティチェックは一切なしでもOK（だからbit[]もいらない）
- Rレジスタは32ビット
- Fレジスタは32ビット
- 構造体サポートは必須
- APIは互換性がなくてもよい
- OSECPU-VMの実装レベル3：
- セキュリティチェックはフル実装
- Rレジスタは32ビット
- Fレジスタは64ビット
- 構造体サポートは必須
- APIは互換性がなくてもよい
- LMEM命令のサポートまであと少しというところまでできた。
こめんと欄
- いくつか気になったところがあります。括弧内はその例となるコードの場所です。
- 私はまだ社会に出てプログラムを書いた経験がないので、もし見当違いなことを言っていたらごめんなさい。
- 後にelse節が続くif文には、内部が一行でも波括弧を付けた方が見やすいと思います。(jitc.c:88)
- 個人的にはif文の波括弧を省略するのは、読み違える危険や、コードを追加した時の括弧のつけ忘れが起きると思います
- 確かに省略した方が見やすい部分はあると思います…しかしswitch文にした方が見やすいと思います。(exec.c:51)
- Kさんのことだから、きっとコンパイラの最適化などの関係で、switch文は使わない理由があるんだ、と勝手に予想
- 確かに今回のソース中にswitch文は一つもない…
- MacOSX 10.8 cc: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)でコンパイル・実行してみました
- 一つだけ警告が出ました
- test.c:17:6: warning: passing 'char [11]' to parameter of type 'unsigned char *' converts between pointers to integer types with different sign [-Wpointer-sign]
- 文字列を渡すことが想定されている引数の型はchar*にするのが良いと思います。（これはコンパイラの問題かな…）
- バイト列はunsigned char *として区別すると良いと思います。
- すごく細かいことですが、"VM"はすべて大文字で"Jitc"は先頭のみ大文字というのは命名規則的に微妙だと思います。また、あまりにも識別子が短いと、ソースコードを組み込むときに衝突するかもしれないので、"OSEC_VM", "OSEC_JITC"などはどうでしょう…（接頭辞は適当です…） -- hikarupsp 2014-05-01 (木) 22:50:26
- (jitc.c:71)変数宣言と同時に代入する場合は、一行一変数のほうが見やすいと思います。 -- hikarupsp 2014-05-01 (木) 22:56:18
- (jitc.c:7)静的配列は関数外で宣言した方がstaticだとわかりやすいのではないでしょうか。 -- hikarupsp 2014-05-01 (木) 22:57:31
- いっぱいコメントありがとうございます！ まず基本方針を。行数が増えると見通しが悪くなりそうなので、行数が増える系の改善案には慎重です。ifの波カッコとか、一行一変数とか。 -- K 2014-05-02 (金) 05:46:55
- VMはやっぱりVmのほうがいいかなあ。確かにそんな気もします。名前が短いと他と衝突しやすくなるのは確かですが、組み込む用途があるかどうかを考えてからにしようと思います。 -- K 2014-05-02 (金) 05:51:52
- switchを避けているのは、switchを使っても行数が減らないためです。 unsigned char * vs char * の件は、今回はtest.cの中だから許してもらうとして、今後はたぶん指摘に従って修正すると思います。 -- K 2014-05-02 (金) 05:56:53
- 細かい書き方もさることながら、なんでこんな手順で処理しているの？！みたいな突っ込みも歓迎しますので、よろしくお願いします。 -- K 2014-05-02 (金) 05:59:06
- 行数を増やさないという方針は納得しました。ふと気付いたのですが、page0071によると、今作っているのはインタープリタですよね？なのにjitcとexecが分離しているのは、将来のjitc化を見据えてのことなのでしょうか？ -- hikarupsp 2014-05-03 (土) 11:31:20
- 将来のjitc化というのは、今作っている物がやがてjitcになるということではなくて、jitc版を新たに開発するときにベースにする、という意味です。多分osecpu1xx系列はインタープリタで行くと思うので…。 -- hikarupsp 2014-05-03 (土) 11:37:15
- せめてもの高速化ということでしょうか…なんかあまり意味のない質問でしたね、ごめんなさい。 -- hikarupsp 2014-05-03 (土) 11:40:54
- すばらしい、ご明察です！ そうです、jitcがあるのは将来のJITC版も似た構造にしようともくろんでいるからです。「一度やれば十分な構文上のエラーチェック」と、「実行時に毎回チェックしなければいけないこと」を分離したかったということもあります。高速化は一応関係ないです。高速性を意識するとそれ以前にやるべきことが多くあって、何やってんだって感じですね・・・。 -- K 2014-05-03 (土) 18:13:11
- あと、インタプリタ版でもJITC版と全く同じ挙動ができないといけなくて、それはつまりバイトコード列を渡して「これをJITコンパイルせよ」というAPIができるということなのですが、このときに構文上のエラーがあればそれは実際の実行より前のJITC時に検出しなければいけないのです。実際に実行してみるまで気づきませんでした、だとJITC版と挙動が大きく違うことになります。とまあそんなわけで、やっぱりjitcとexecは分離すべきだろうということになりました。 -- K 2014-05-03 (土) 18:17:08
- 遅くても同じ動作をすることが最重要ですもんね。…また質問で、hh4DecodeIntegerでLIDR命令(FD)命令をデコードするときにもdrに代入しているのはなぜなのでしょうか？ -- hikarupsp 2014-05-04 (日) 11:51:13
- FLIMMのmod=1,2のfimmは、hh4エンコードされていないデータになるんですね…これがなければ、hh4DecodeをinstrLengthを使ってシンプルに実装できそうなのですが… -- hikarupsp 2014-05-04 (日) 12:01:55
- instrArgTypesという関数を用意して、そこで引数のタイプを返すというのはどうでしょう？返すのはconstな文字列へのポインタで、たとえばLB命令なら"suu"、FLIMMのmod1だったら"ufuu"、mod2だったら"uduu"、すべてunsignedだったらNULLを返すようにすれば、そこまで冗長にならないと思います。 -- hikarupsp 2014-05-04 (日) 12:08:08
- DRレジスタは、rev1でいうところのdebugInfoで、つまりエラーが起きたときに、それがソースコード上の何行目かを保持するレジスタです。これをやってやらないとJITCのときのエラーの場合、エラー箇所を探しにくくなります。 -- K 2014-05-05 (月) 07:56:01
- >FLIMMのmod=1,2のfimmは、hh4エンコードされていないデータになるんですね ・・・そうなのです。他にもhh4エンコードにならない命令があります。2Eのデータ命令とかです。 -- K 2014-05-06 (火) 08:48:52
- すばらしいソースをありがとうございます。hh4Decode()が冗長になるという意見で、少し過激なアイデアですが、hh4Decode()後もHH4Reader->lenを保持しておいて、signedに変換する処理はjitc.c内で行うとかはどうでしょうか。何か誤解してたらすみません。 -- ttwilb 2014-05-07 (水) 11:19:30
- みなさんhh4Decode族の仕様にご不満のようで・・・（苦笑）。今の形式だと基本的にどんなフォーマットにも対応できるのでいいかなーと思っています。でもみなさんのアイデアも悪くないと思います。もしよかったらいろいろ改造してみてください。うまくできたら教えてくださいね。 -- K 2014-05-07 (水) 14:56:57
- ちょっと実装してみました！これなら複雑な命令の数が増えても行数があまり増えなくて個人的には好きです。> gitリポジトリ -- hikarupsp 2014-05-08 (木) 01:24:16
- ソースコードはRev.1と比べて格段に読みやすいです！まだ機能が少ないからかもしれませんが、拡張しやすく作られているなぁ、と読んでいて感じました。 -- hikarupsp 2014-05-08 (木) 01:27:26
- hh4Decodeって名前が良くないのかもしれないです。hh4をデコードしているだけだと思ったら、命令ごとに違う動作をしてもはや命令デコーダーになっていた…みたいな。decodeInstructionみたいな名前にしてコードもosecpu-vm.cに移した方がすっきりするのかもしれないです。 -- hikarupsp 2014-05-08 (木) 01:31:26
- >hh4をデコードしているだけだと思ったら、命令ごとに違う動作をしてもはや命令デコーダーになっていた…みたいな ・・・確かにそうかも・・・。 -- K 2014-05-08 (木) 07:02:55
- hikarupspさん、gitリポジトリありがとうございます！ -- K 2014-05-08 (木) 11:40:43
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
