memo0008 のバックアップ(No.15)

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関係をためしに改造中。

↑

こめんと欄

いくつか気になったところがあります。括弧内はその例となるコードの場所です。
- 私はまだ社会に出てプログラムを書いた経験がないので、もし見当違いなことを言っていたらごめんなさい。
1. 後にelse節が続くif文には、内部が一行でも波括弧を付けた方が見やすいと思います。(jitc.c:88)
  - 個人的にはif文の波括弧を省略するのは、読み違える危険や、コードを追加した時の括弧のつけ忘れが起きると思います
  - 確かに省略した方が見やすい部分はあると思います…しかしswitch文にした方が見やすいと思います。(exec.c:51)
  - Kさんのことだから、きっとコンパイラの最適化などの関係で、switch文は使わない理由があるんだ、と勝手に予想
  - 確かに今回のソース中にswitch文は一つもない…
2. 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 *として区別すると良いと思います。
- hikarupsp 2014-05-01 (木) 22:42:51
すごく細かいことですが、"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

コメント	お名前	NameLink