タグ

ブックマーク / qiita.com/miura1729 (7)

  • mrubyのJIT2 (仮称) - Qiita

    mrubyのJIT2(仮称)なるものを作ろうとしているのだが、考えがまとまらないので取りとめもなく書く。真に受けて何か損害をこうむっても知らん、その代わり何かいいことがあっても私は何も貰えない。 mrubyのJIT2(仮称)はLLVMベースを考えています。これまでLLVMのトラウマがあったわけですが、LLVMもいろいろ変わっていて(変わり過ぎですけど)、ちょっと試してみたい気もあるってのもあるしラズベリーパイも買ったのでこれでも動かしたいってのもある。 今考えている構造はこんな感じ mrubyのバイトコードからさらにSSAベースの中間コード(IR)にする IRを生成する際にある程度の型推論を行いその型情報はIRに入れられるようにする(LuaJITのパクリじゃなくてLuaJITにインスパイアされたって奴ですね) 前作と違い、Tracingではなくmethod JITにする(LLVMでTrac

    mrubyのJIT2 (仮称) - Qiita
  • どきっ!mrubyだらけのTracing JITコンパイラ解説 バグりもあるよ - Qiita

    みなさーん、プログラマの石川某くんはいつもデスマにはまっていていつJITの勉強しているんだろと思ったことはありませんか?その秘密は、mruby-meta-circular。Cも機械語も使いません。だから、忙しい某君にもできるのです。サンプルCoDeを無料で送ります。続きはWebで というわけで(どういうわけだ(定番の突っ込み))、mrubyとmrubyのVMであるRITE VMの命令だけでTracing JITの仕組みを解説しようと思います。 mrubyのJITと基的な構造は大体同じです。 インタープリタ 初めにベースになるVMを見てみましょう。おそらく世の中で2番目にたくさん作られているプログラム、フィボナッチ級数それだけが動くよう注意深く命令セットが選ばれています。これから先、このVMをFibVMと呼びます。また、mrubyのVMはRITE VMです。 この2つを区別することが非常に

    どきっ!mrubyだらけのTracing JITコンパイラ解説 バグりもあるよ - Qiita
  • mrubyのJITの概要 - Qiita

    まあ、VMをぶん回すようなプログラムだと、大体5~10倍くらいの速度が出るようです。文字列処理やIOなどCで書かれたライブラリを多用すると速度の差は縮まるでしょう。 内部構造 mrubyのJITはTracing JITです。Tracing JITそのものはググってください。mrubyのVMのバイトコード命令をフェッチして命令毎の処理に分岐するところで制御を乗っ取って実行回数をカウントします。実行回数がある閾値になったら機械語を生成し、次にこの命令を実行したら生成した機械語を呼び出します。 概要をつかむのは名古屋Ruby会議03で発表させてもらったスライドがいいと思います https://www.slideshare.net/miura1729/mrubyjit 内部構造の詳細はこちらを見てください あなとみー おぶ mrubyのJIT (その1) このあと、連続していてその13まであります

    mrubyのJITの概要 - Qiita
  • segmentation faultの出たmrubyを楽しくデバッグする方法 - Qiita

    mrubyを使っていてsegmentation faultとか出て困ったことは無いでしょうか。こういう場合にgdbでデバッグするノウハウを書きます。gdbの使い方についてはここでは説明しません。 逆アセンブラ gdbでデバッグするならmrubyのバイトコードの逆アセンブラが必要です。標準ではcodedump関数が用意されていますが、なぜかここで説明するような使い方はできないようです。mrubyのJITで使っているものがここにありますので、コピーしてcodedump.cあたりにでも入れておいてくください。 これを使うと、変数mrbとirepが見えていれば、こんな感じでdisasm_irep関数を呼び出すことで逆アセンブルできます。見えていない場合、gdbのupコマンドで呼び出し元を辿っていて見えるところがあればそこで実行可能です。disasm_irepは値を返さないのでcallを使う方がよさ

    segmentation faultの出たmrubyを楽しくデバッグする方法 - Qiita
  • mrubyのバイトコードの命令の解説 - Qiita

    mrubyでコンパイラを作ってみたり、Rubyを書く以外の方法でmrubyのバイトコード列を書く場合、バイトコードの命令を知る必要があります。 バイトコード命令は単純そうで意外と奥が深いようです。ここではmrubyのJITを作成する経験で得たバイトコードの裏仕様を解説したいと思います。 OP_NOP 何もしない命令 これって実はcodegen.cで定義されている正規のコードジェネレータでは出てこないんですよね。でもバイトコードのパッチとかやりたいときはないと困る重要な命令です。 命令の仕様ではオペランドはないのですが、実際にはオペランドの領域があるのでなにか隠しデータを保存しておくのにも便利です。 OP_MOVE MOVE Rm, RnでレジスタRnの内容をRmに代入する命令。n, mはレジスタの番号 こんなにいらんだろ?って思うほどいっぱい生成されます。OP_SENDで解説しますが引数は

    mrubyのバイトコードの命令の解説 - Qiita
  • mrb_state 解説(必ずしも徹底ではない) - Qiita

    mrubyを改造したり、mrubyを何かアプリケーションとかに組み込むときに必ず必要になる物に、mrb_state型の構造体へのポインタ(多くの場合はmrbという名前で参照されている)があります。これは、mrubyで使う大域変数や状態を1つの構造体にまとめた物です。 mrubyのインタプリタを使うときにはmrb_state型の構造体のインスタンスを用意してそれをインタプリタに渡します。複数のインタプリタが欲しいときには複数のインスタンスを用意します。 こうすることで、構造体のインスタンスを複数用意することで複数のmrubyインタプリターをプログラムコードは共有して使えます。これは、並列性は息を吸うのと同じくらい普通で、メモリの一滴は血の一滴くらいメモリが貴重な1組み込み界隈ではとっても嬉しい仕様なわけです。 mrb_stateはmrubyの大域変数や状態が全て入っているので、mrb_sta

    mrb_state 解説(必ずしも徹底ではない) - Qiita
  • mrubyのJITにおけるメソッド再定義の対処方法 - Qiita

    Rubyはメソッドの再定義が出来るのですが、これがJITコンパイラを作るときに問題になります。メソッドそのものを再定義しなければならないのはもちろん、各所に散らばっているそのメソッドを呼び出している元も書き換えなければならないからです。さもなければ、再定義されているかを毎回チェックする必要があり、大幅に速度が落ちます。 mrubyのJITではコードの自己書き換えを駆使することで速度を落とさず再定義に対処しています。ただし、メモリ効率が悪いので、頻繁な書き換えには向きません。 mrubyのJITではこんな感じで生成コードを管理しています。この場合は、メソッドfooの場合です。 entry tableってのがあって、RITE VMの命令毎に対応する機械語コードのアドレスが入っています。Tracing JITなのでプログラムが全て機械語になっている保証はないですので、これを見て対応する機械語命令

    mrubyのJITにおけるメソッド再定義の対処方法 - Qiita
  • 1