bit[]に関するメモ

#1. 目的
整数演算に関するbitは、多倍長演算において、どの精度まで行えば結果が変わらないのかをVMに教えるための手段である。
したがって、bit=32であってもVMは64ビット演算をするかもしれないし、256ビット演算をするかもしれない。
しかしそれによって、最終的な結果が少しでも変わることは許さない。
この情報があればVM（特にJITコンパイラ）は、処理を高速化できる。

#2. 注意すべき点
レジスタやメモリのbitの情報は、高速モードでは一切生成されない。参照もされない。
あるタスクがあって、それは最初安全モードで動作していたとする。それが一度高速モードに切り替わって、また安全モードに
戻ったとしても、結果は正しく得られなければならない。高速モード中に情報が失われているので、チェック能力が下がるのは
かまわない。
つまりbitに依存した動作をすることは許されない。

#3. タスクセーブに関すること
タスクセーブでは、不定ビットは全て0か1に初期化される。と思ったが、これは必要ないかもしれない。
なぜなら高速モードではbitがないので、この不定ビットつぶしができない。つまり他のタスクからの情報が流出しうる。
となれば、やはり消すのは別のところでやるべきだ。malloc時に重要であると明示させるのがよさそう。
そうすればVMもしくはOSは、free時にゼロクリアできる。
同じ問題はレジスタでも起こり得る。だから重要な値を持つレジスタは明示的にデータを消さなければいけない。
その際には必要なビット幅でLIMMをするべき。その後にbit=0のLIMMをしてもしなくてもいい。
これは2度手間だけど、使用頻度を考えれば妥当。

#4. VMは安全モードの場合は、不定ビットをレジスタ内に残さず、常に符号拡張した状態で処理する。
これは値の範囲チェックをするため。高速モードでは、不定ビットを残していてもよい。
タスクセーブ時には、不定ビットは殺してしまう。
しかしこの方法では、高速モードから安全モードに移行した際に問題にならないか？
高速モードではどこまでビットをつぶすべきか分かっていないのだから。
さてこまった。となると、高速モードから安全モードに戻せないとしたほうがいいのかもしれない。
もしくはbitに不明という状態を許すか？不明の間は、しょうがないのでチェックができない。
分かったらすぐにチェックをする。まあこれもありかもしれない。・・・よしこれにしよう。

#5. LMEM



#6. SMEM
(1)SINT32のメモリに対して、bit=16のデータを書き込むことは許される。
  その場合、メモリのbitは16になる。書いた値が読み出せるかどうかのチェックはない。
(2)UINT32のメモリに対して、bit=16のデータを書き込むことは許される。
  その場合、メモリのbitは16になる。書いた値が読み出せるかどうかのチェックは少しある。
    それはデータが負ではないこと。負はどうやっても読み出せないから。
dat.bit=min(reg.bit, SMEM.bit)
(3)typ.bit >= dat.bit は原則OK。ただし、符号のチェックはある。
  unsignedなtypで、reg<0ならダメ。
(4)typ.bit < dat.bit の場合は、値の範囲が妥当なら問題ない。範囲がまずければやはりエラーになる。
(5)2F-0がある場合は、ダメな場合でもメモリのbitが0になるだけで、アプリは例外を起こさずに続行できる。
  しかしそれでも符号のチェックはある。
(6)2F-0でUINT系を全部エラーにしてしまえばいいかとも思ったけど、レジスタの用法はわからないので、
  将来のアプリに配慮した。

#7. LMEM, SMEMのプリフィクス
2F-0: マスクリード、マスクライト。
2F-1: レジスタ退避用のリードライト。
2F-2: メモリのbitを0にする。
