参考資料:
  page0072 : バックエンド命令セットの仕様
  page0078 : bitについての説明

2014.05.01木:
  ソースはTAB=4想定で書いています

2014.05.02金:
  hikarupspさんの助言により、構造体名を変更。
    VM → OsecpuVm
    Jitc → OsecpuJitc
  ソースプログラムの基本構成を変更。
  float.cを追加。

2014.05.07水:
  現在の命名規則:
    型の名前は大文字から始まる
    マクロは全部大文字
    変数名や関数名は小文字から始まる
    数字の0は「最初」「先頭」「古い値」などを意味する
    数字の1は「最後」「末尾」「新しい値」などを意味する
  値の意味:
    0は「未設定」や「初期化済み」や「未使用」などを意味する
  gotoを結構よく使っているのは、インデントがむやみに深くなるのを避けるため。

2014.05.08木:
  OSECPU-VMではfloatの精度は32bitまでを保証する。
  倍精度である64bitをサポートするかは処理系依存。
  floatのサポートそのものがない場合も許す。

2014.05.22木:
  data文まではとりあえずできた。
  data命令でも浮動小数点を使えるようになりたいからそれは後日がんばる。
  次はLMEMだなー。その次がPADD。

2014.05.23金:
  プリフィクスについて：
    解釈できるプリフィクスは、認識した後に0クリアすること。そうしなければエラーになる。
    2Fプリフィクスは、フラグ的な指定なので、命令ごとに意味が異なる。
  LMEMに対する、2F-0プリフィクスについて：
    2F-0プリフィクスがない場合：
      (1) mem.bit < typ.bit なら、セキュリティ例外になる。
      mem.bit: メモリのbit[]値
      typ.bit: そのメモリの型での最大のbit値
      reg.bit: LMEM命令内のbit値で、これは命令実行後にRxxのbit[]値になる
    2F-0プリフィクスがある場合：
      (1) reg.bit = min(reg.bit, mem.bit) とする。結果が何であろうとセキュリティ例外にはならない。
      この場合、不定値をロードしてもレジスタが不定値なるだけで処理を続行できる。
      しかしこの値を使って演算しようとすると、エラーになる。
  SMEMに対する、2F-0プリフィクスについて：
    2F-0プリフィクスがない場合：
      (1) typ.bit > reg.bit なら、セキュリティ例外になる。
      (2) typで指定されている型で表現可能な範囲にregがないのであれば、セキュリティ例外になる。
      (3) mem.bit = typ.bit になる。
    2F-0プリフィクスがある場合：
      (1) typで指定されている型で表現可能な範囲にregがないのであれば、mem.bit = 0 になる。
      (2) そうでなければ mem.bit = reg.bit になる。
      つまり例外を起こさずに何とかする。
      この場合、unsignedな型は指定できない。
  SMEMに対する、2F-1プリフィクスについて：
    2F-1プリフィクスがあると、Rxxフィールドは無視されて、メモリは無条件にbit[]値を0にされる。
    明示的にメモリを不定値したい場合は、これが望ましい。適当なレジスタに不定値を代入して格納する方法だと
    高速モード時に不要なSMEM命令が残ってしまうかもしれない。
  SMEMに対する、2F-2プリフィクスについて：
    2F-2プリフィクスがある場合：
      (1) typ.bit > reg.bit なら、セキュリティ例外になる。
      (2) 実際に書き込まれるのは、typ.bitでマスクされた下位の値のみ。
      (3) mem.bit = typ.bit になる。
  （上記のメモは、もはや古い内容。メモだから残しているだけ。）
  data命令がpointer.cの中にあるのはうまくない！

2014.05.27火:
  レンジチェックに関する諸問題：
  (1) 高速モードから安全モードへ切り替えることを想定すると、bit[]に「不明」を認めなければいけない。
    しかしそうなると、レンジチェックの手順はかなり複雑になる。
    ソースデータに「不明」がある場合、結果が出た後に結果を正規化する必要がある。
  (2) 安全モードだけでも、C=(A+B)&3;のような計算をするときに、A+Bの結果を2ビットの精度で演算できるべきでは
    ないか？・・・となると、A+Bの計算をするときに結果が2ビットで収まらなくても構わないということを認めなければ
    いけない。そのために2F-0プリフィクスを付ける。
  (3) まず論点としては、レンジチェックをやめてしまえばいいのではないかということがある。ごみデータが現れることは
    高速モードじゃなくても十分に起こり得ることなのであって、そうなるとそれに気を使うのは面倒なだけではないか？
    しかしとりあえず、まだあきらめずにレンジチェックをやる方向で検討する。この(3)は思考過程を記録として残すために
    書いた。
  (4) 2F-0プリフィクスがある場合、レンジチェックはしないで、むしろ結果がそのレンジに収まるように符号拡張をする。
    そうしないと以後のレンジチェックに障るかもしれないので。
  例外検出に関する諸問題：
    例外を検出した時に、正常系だった最後の値を保持する（おかしくなった原因命令を実行する直前の状態にする）のは
    負担が大きいので、それはやらない。これについては、将来の逆再生機能に期待するべきだ。
  driver.cについて：
    確かMacOS版にバグの修正があった気がするけど、まだそこまで手が回らない。落ち着いたら確認する。

2014.05.28水:
  APIのグラフィックのmodeについて：
    bit0-1: 色指定モード(0:8色, 1:512色, 2:32K色, 3:16M色)
    bit2-3: 機能モード(0:pset, 1:or, 2:xor, 3:and)
	bit4:   (1:クリッピングする)
    bit5:   (1:fillしない)
    色指定について、8色モードの色の割り当ては変更になった。

2014.05.29木:
  rev1のremarkを整理： （ http://osecpu.osask.jp/wiki/?page0032 が微妙に間違っているので）
    DB(0xfe,0x01,0x00); // DEBUGINFO1（モジュール番号など）.
    DB(0xfe,0x01,0x01); // for構文終了.
    DB(0xfe,0x01,0x03); // CALL/CALLR切り替え用プリフィクス.
    DB(0xfe,0x01,0xfc); // ALIGNPREFIX0.
    DB(0xfe,0x01,0xfd); // ALIGNPREFIX1.
    DB(0xfe,0x01,0xff); // appackに対して、パディングFの出力を指示.
    DB(0xfe,0x05,0x02); // for構文開始.
    DB(0xfe,0x05,0x00); // DEBUGINFO0（行番号など）.
    DB(0xfe,0x05,0x01); // 関数呼び出し構文開始マーク（実行には関係ないので無視される）
  rev2のremarkをどうするか：
    cfe-n-len-...
    DEBUGINFO0は、cfd-uimm-0で代用する。
    cfe-0-0 :   DEBUGINFO1（モジュール番号など）
    cfe-1-0 :   関数呼び出し構文開始マーク
    cfe-2-1-n : for構文開始
    cfe-3-0 :   for構文終了
    cfe-4-0 :   CALL/CALLR切り替え用プリフィクス
    cfe-5-0 :   appackに対して、パディングFの出力を指示
    cfe-6-0 :   ALIGNPREFIX0
    cfe-7-0 :   ALIGNPREFIX1
  hh4は788を付ければ32bitで書ける。

2014.06.06金:
  chars: 05e2 460b8ba5145 : 7.5バイト。おしい。

