2013_0003 のバックアップ(No.1) - kiwi-log

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

2013.08.21 Wed

neriさんはCLEをスタックマシンベースに改造するらしいです。
- http://nerry.hatenablog.com/entry/2013/08/20/071532
```
スタックベースにするとレジスタベースの時より機能密度が上がることが期待できます。
```
- これは僕も何度も聞いたことがあります！
- でもこれってどうなのかな。僕はOSECPUでレジスタマシンでも負けないというか、レジスタマシンのほうがむしろ機能密度が高くなると証明したつもりになっています。
- スタックマシンだと確かにテンポラリ変数の扱いは有利です。長い式も有利です。でも実際のプログラムは i++; とか a = b + c; 程度の式ばかりで、むしろスタックに積みおろしをするための指示子の分（実質1ビット程度？）のぶんだけ損をしている気がします。
- しかしまあ結局はやってみないと分からないので、neriさんの結果から目が離せません！

2013.08.24 Sat

neriさんの検討が面白いです。
- http://nerry.hatenablog.com/entry/2013/08/24/064220

僕だったらスタックマシンの試作を

|4|   load c
|4|   load b
|4|4| add
|4|4| store a
=24

とかにするかなあ。loadは使用頻度が高いので、0～Dで、14レジスタに対応。
- いくつかは定数ロードにしてもいいかも。
add はF0とか。
store a はE0とか。

しかし3レジスタの16に勝つのは難しい。とはいえ、OSECPUの場合
```
|12|4|4|8| add a,b,c
```
なので、28だったりする。・・・あれ？

OSECPUの3項型addが長いのは、2項型を優先しているため。
```
|8|4|8| add a,b
```
これなら20で済む。

OSECPUの第三項が8なのは定数を優先しているため。
```
|8|4|4| add a,2
```
これなら16で済む。

スタックマシンの場合2項型とかを工夫することはできず、つねに24になる気がする。
でもloadをひとつつぶしてそれをaddにするなら、addだけは20にできます。でもこれをやりすぎると、短い形式でloadできるものが減ります。
あとstoreも、load元へ書き戻すという命令を作れば、そしてそれもloadをつぶして実現するなら、2項演算みたいになって、addはついに16になるかも！
まあload元へ書き戻すのはよくても、add命令を4にするのはやりすぎかなあ。他の演算命令はどうするんだっていう話になるし。だからやっぱり演算子は8のままで。
ちなみにOSECPUの改善案では、演算子に応じてよく使う定数演算が変わるだろうということで、それを配慮してもっとコンパクトにしようとしています。つまり、文脈が活かせるレジスタマシンはやっぱり機能密度的に有利なんじゃないかと。