オレオレ言語
符号ビットで埋めるのは結構面倒くさいし、コストがかかるもんな。いうてもコスト面はこのインストラクションがどうネイティブに変換されるのにもよるけどね。。
2020-06-03 06:36:14引数を8/16ビット数値とみなして符号ビットで埋める命令はwasm 1.1で追加されとるな。。 i32.extend8_s i32.extend16_s i64.extend8_s i64.extend16_s i64.extend32_s やったああ!! pic.twitter.com/k9HuFpDLHV
2020-06-03 06:34:24つまりi8の要件として 1. 0-255以外の代入は許さない 2.演算のあと8-31bitは符号ビットで埋める としておけばビット・ローテート以外は問題なさそうですな。なかなかコストが高いですな。。
2020-06-03 06:15:07しかしこれでは負の数と正の数との比較が正しくなくなってしまう。0xffと1の比較はi8で見れば1のほうが大きくなければならないが、i32の比較命令では先ほどのビットクリアしただけでは大小関係が逆転してしまうということ。
2020-06-03 06:04:53i32での255はi8であれば-1である。これに1を加算するとi32では 1 0000 0000 256となる。この状態で他の値を比較するとi8で見た場合結果がおかしくなる。この値と0を等価比較した場合、i8では8bit以降は無効であるから等しいが、i32の比較命令では有効であるので結果偽になってしまう。
2020-06-03 05:56:51(2)これに1を加算すると0となる。これはi8で考えても結果は同じ。また0から1を減算すると-1となってすべてのビットが1となるがこれは最初に検証した結果と同じ。
2020-06-03 05:38:31-1をi32に代入すると、全部のビットが1となる。 11111111111111111111111111111111 これはi8で考えても-1である。 11111111
2020-06-03 05:33:328bit整数演算の場合、意図的に8-31bitに何か値を入れない限りはビット・ローテーション以外は演算結果が不正になることはなさそうな気がする。
2020-06-03 05:29:498bit幅だと、8-31bitまでの空きビットの取り扱いを考える必要がある。演算を32bit幅で行い、その結果が8bit幅で考えた場合におかしくなるかもしれないので。まずは8-31bitはそのまま放っておくことを考える。
2020-06-03 05:14:068bit/16bitの疑似型の演算をどうしようか考えている。wasmではi32のみなので、8/16bitの演算はi32のインストラクションを使ってそのビット幅での演算となるようにしなければならない。
2020-06-03 05:06:02floatのビットパターン文字列をJSで得るのってArrayBufferとDataView使えば簡単でしたな。。 let view = new DataView(new ArrayBuffer(4)); view.setFloat32(0,-10); view.getUint32(0).toString(2).padStart(32,'0'); '11000001001000000000000000000000'
2020-06-02 18:46:54そして何かにとりつかれたようにwasmインストラクションをJSで実行するwasmモジュールを作り始めてるという。。インタプリタ実装に役に立つかなあと思って。。 pic.twitter.com/8wFk3Yxh6W
2020-06-02 18:42:09