* Kの開発メモ #0008
-(by [[K]], 2014.05.01)
-ここは川合の開発の進捗などをレポートするところです。

** 2014.05.01 Thu
-OSECPU-VMのrev2の最初のバージョンをリリースしました。まだテストしかできません。
--[[page0074]]
--で、まあこの段階であれこれいう気にはならないだろうけど、しかしもし何か意見があったら下の「こめんと欄」で教えてください。特に「これじゃあまだぜんぜん読みやすくなってない、ここはこうしたほうがいいんじゃないの?」みたいな突込みは歓迎します。

** 2014.05.02 Fri
-いろいろとソースに手を加えているところ・・・。
--うわー、昨日のosecpu101aは結構バグバグだった・・・すみません。
-とりあえず今日のところまでをリリース。構造体名はhikarupspさんの提案を採用しました。→[[page0074]]


* こめんと欄
-いくつか気になったところがあります。括弧内はその例となるコードの場所です。 
--私はまだ社会に出てプログラムを書いた経験がないので、もし見当違いなことを言っていたらごめんなさい。 
++後に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 *として区別すると良いと思います。 
-- [[hikarupsp]] SIZE(10){2014-05-01 (木) 22:42:51}
-すごく細かいことですが、"VM"はすべて大文字で"Jitc"は先頭のみ大文字というのは命名規則的に微妙だと思います。また、あまりにも識別子が短いと、ソースコードを組み込むときに衝突するかもしれないので、"OSEC_VM", "OSEC_JITC"などはどうでしょう…(接頭辞は適当です…) -- [[hikarupsp]] SIZE(10){2014-05-01 (木) 22:50:26}
-(jitc.c:71)変数宣言と同時に代入する場合は、一行一変数のほうが見やすいと思います。 -- [[hikarupsp]] SIZE(10){2014-05-01 (木) 22:56:18}
-(jitc.c:7)静的配列は関数外で宣言した方がstaticだとわかりやすいのではないでしょうか。 -- [[hikarupsp]] SIZE(10){2014-05-01 (木) 22:57:31}
-いっぱいコメントありがとうございます! まず基本方針を。行数が増えると見通しが悪くなりそうなので、行数が増える系の改善案には慎重です。ifの波カッコとか、一行一変数とか。 -- [[K]] SIZE(10){2014-05-02 (金) 05:46:55}
-VMはやっぱりVmのほうがいいかなあ。確かにそんな気もします。名前が短いと他と衝突しやすくなるのは確かですが、組み込む用途があるかどうかを考えてからにしようと思います。 -- [[K]] SIZE(10){2014-05-02 (金) 05:51:52}
-switchを避けているのは、switchを使っても行数が減らないためです。 unsigned char * vs char * の件は、今回はtest.cの中だから許してもらうとして、今後はたぶん指摘に従って修正すると思います。 -- ''K'' SIZE(10){2014-05-02 (金) 05:56:53}
-細かい書き方もさることながら、なんでこんな手順で処理しているの?!みたいな突っ込みも歓迎しますので、よろしくお願いします。 -- ''K'' SIZE(10){2014-05-02 (金) 05:59:06}
----
-行数を増やさないという方針は納得しました。ふと気付いたのですが、[[page0071]]によると、今作っているのはインタープリタですよね?なのにjitcとexecが分離しているのは、将来のjitc化を見据えてのことなのでしょうか? -- [[hikarupsp]] SIZE(10){2014-05-03 (土) 11:31:20}
-将来のjitc化というのは、今作っている物がやがてjitcになるということではなくて、jitc版を新たに開発するときにベースにする、という意味です。多分osecpu1xx系列はインタープリタで行くと思うので…。 -- [[hikarupsp]] SIZE(10){2014-05-03 (土) 11:37:15}
-せめてもの高速化ということでしょうか…なんかあまり意味のない質問でしたね、ごめんなさい。 -- [[hikarupsp]] SIZE(10){2014-05-03 (土) 11:40:54}
-すばらしい、ご明察です! そうです、jitcがあるのは将来のJITC版も似た構造にしようともくろんでいるからです。「一度やれば十分な構文上のエラーチェック」と、「実行時に毎回チェックしなければいけないこと」を分離したかったということもあります。高速化は一応関係ないです。高速性を意識するとそれ以前にやるべきことが多くあって、何やってんだって感じですね・・・。 -- [[K]] SIZE(10){2014-05-03 (土) 18:13:11}
-あと、インタプリタ版でもJITC版と全く同じ挙動ができないといけなくて、それはつまりバイトコード列を渡して「これをJITコンパイルせよ」というAPIができるということなのですが、このときに構文上のエラーがあればそれは実際の実行より前のJITC時に検出しなければいけないのです。実際に実行してみるまで気づきませんでした、だとJITC版と挙動が大きく違うことになります。とまあそんなわけで、やっぱりjitcとexecは分離すべきだろうということになりました。 -- ''K'' SIZE(10){2014-05-03 (土) 18:17:08}
-遅くても同じ動作をすることが最重要ですもんね。…また質問で、hh4DecodeIntegerでLIDR命令(FD)命令をデコードするときにもdrに代入しているのはなぜなのでしょうか? -- [[hikarupsp]] SIZE(10){2014-05-04 (日) 11:51:13}
-FLIMMのmod=1,2のfimmは、hh4エンコードされていないデータになるんですね…これがなければ、hh4DecodeをinstrLengthを使ってシンプルに実装できそうなのですが… -- [[hikarupsp]] SIZE(10){2014-05-04 (日) 12:01:55}
-instrArgTypesという関数を用意して、そこで引数のタイプを返すというのはどうでしょう?返すのはconstな文字列へのポインタで、たとえばLB命令なら"suu"、FLIMMのmod1だったら"ufuu"、mod2だったら"uduu"、すべてunsignedだったらNULLを返すようにすれば、そこまで冗長にならないと思います。 -- [[hikarupsp]] SIZE(10){2014-05-04 (日) 12:08:08}
-DRレジスタは、rev1でいうところのdebugInfoで、つまりエラーが起きたときに、それがソースコード上の何行目かを保持するレジスタです。これをやってやらないとJITCのときのエラーの場合、エラー箇所を探しにくくなります。 -- [[K]] SIZE(10){2014-05-05 (月) 07:56:01}
->FLIMMのmod=1,2のfimmは、hh4エンコードされていないデータになるんですね  ・・・そうなのです。他にもhh4エンコードにならない命令があります。2Eのデータ命令とかです。 -- ''K'' SIZE(10){2014-05-06 (火) 08:48:52}
-すばらしいソースをありがとうございます。hh4Decode()が冗長になるという意見で、少し過激なアイデアですが、hh4Decode()後もHH4Reader->lenを保持しておいて、signedに変換する処理はjitc.c内で行うとかはどうでしょうか。何か誤解してたらすみません。 -- [[ttwilb]] SIZE(10){2014-05-07 (水) 11:19:30}

#comment

トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS