page0072 のバックアップ(No.3)

Rev2のベタ命令セット

最初に4バイトのシグネチャがある。
```
05 EC 02 00
```
- ちなみにこの末尾の00はサブリビジョンで、将来のバージョンでは01や02になる可能性がある。
- なお、OSECPU-VM命令セットは、他の様々な用途に応用される可能性があると思うが、その場合は、このシグネチャを強要しない（推奨もしない）。それぞれがそれぞれの方法でOSECPU-VMの命令セットであることを判断する。
  - 応用を示唆する例：すべてがOSECPUアプリになる？
- というか、そもそもここに書く命令セットは「ベタ」であって、サイズの追及もされていない冗長なものなので、これをそのまま応用することはないような気もする。
シグネチャの後はhh4エンコードで命令列を並べる。データ系命令以外はこれに従う。
- hh4: http://osask.net/w/634.html
- [Q]なぜ以前のようにバイト列で定義しないのですか？
- [A]OSECPU-VMは32bitに限定されない仕様に近づくから。・・・完全に32bitの制約が無くなるのが「第三世代OSASK」で、OSECPU-VMはそのうちの32bit以下だけをサポートしたものに相当する。
- 32bit前提じゃなくなると、immやtypが32bit固定だとは言いにくくなる。だから単純なバイト列では規定できない。それで可変ビットなhh4を採用。hh4なら固定ビット方式もできる。

命令表：（rはRxxのこと、pはPxxのこと、bitは定数32を入れておくとよい、uimmは符号なし整数のこと）

2013年のころのバイトコードと比較すると、データの流れが左から右になっている。
- なぜ？・・・そのほうがデコーダが書きやすいから。
typはpの直後に来る。
- なぜ？・・・そのほうが型推論を書きやすいから。
bitってなんですか？
- Rxxの演算精度のこと。bit=32の場合、Rxxは32bitかそれ以上で計算してほしいということ。
- これが何のために必要かというと、今まではcharの演算で済むときでさえ無条件で32bit演算していたわけで、これは32bitのCPUでは大して問題にならないとしても、8bitのCPUにとっては大きなロスになる。bitを指定できないとこの無駄をVMは「気づくことすらできなかった」が、bitが入ることこれを反映して無駄を取り除けるようになる。
- 「第3世代OSASK」では、bitは64や256などを指定してもよくなる。
- このようにアーキテクチャが固有の標準bitを持たないことを「ビットフリー」ということにする。

コメント	お名前	NameLink