ジェネリックプログラミング
はじめに
- OSECPU-VMはrev2になって、「32bitに限定されない演算ビット幅」という概念が導入されました。これをどう発展させたいと思っているのかについてです。
(1)
- たとえばあるOSでは、ファイルサイズは32ビットで十分とされていて、それを前提にプログラムを書いたとします。しかしのちにファイルサイズは64ビットで取り扱わねばならない、となって、プログラムの書き直しが必要になるかもしれません。
- その際に、「ファイルサイズのビット数」みたいなパラメータがプログラム内にあれば、書き直しを回避できます。これはつまり、型番号や演算ビット数を定数パラメータで記述できるようにしておくべきだ、ということです。
- 今のOSECPU-VMはこれに対応できていませんが、定数パラメータや条件コンパイルなどのオプションを含んだ高度なバイナリがあって、それを評価して具体的な数値だけになったソースを実行するのが今のOSECPU-VMの役割なので、これはこれでいいのです。
- というか、そういう機種依存のない汎用的な処理までOSECPU-VMに入れてしまうと、VMがどんどん大きくなってしまって、移植がやりにくくなってしまいます。
- どうしても機種依存のあるVMとAPIだけをCで書いて、残りは（性能に問題ない限りは）OSECPU-VMのバイナリで書くというのが理想です。
(2)
- あるプログラムは、SINT32を使った構造体を使っていて、その構造体をデータファイルに記録していたとします。そのプログラムをバージョンアップして、その構造体にSINT64を使うようにした場合、構造体の対応関係は明らかなので、データファイルの方をコンバートしたいと考えています。
- この場合、コンバータをプログラマが書く必要はないです。データファイルには、この構造体を出力したもの、という情報が含まれているからです。
- 現状ではこういうことは一切できていませんが、こういうことができるようなシステムをOSECPU-VMで実現したいと思っています。
- つまりこうです。OSECPU-VMが出力するファイルは、たとえバイナリファイルであっても、それがSIN32の配列なのか、UINT8の配列なのか、hh4の配列なのか、構造体だったらそれぞれのメンバ名はなんなのか（まあただの番号になっているかもしれませんが）、とにかくそういうことが分かるようになっています。
- これはすごく便利なことです。バイナリファイルとは思えないほどの可読性になります。バイナリエディタもバイナリエディタとは思えないほどのものになるでしょう。もちろんこのファイルをOSECPU-VMアプリからオープンして読み書きするのも簡単です。
- そしてこういう仕様だからこそ、データコンバートはほぼ自動でできるのです。
(3)
- 動作中のプログラムの、すべての変数やアクセスしているデバイス状態を一時的に保存して復元する機能をOSECPU-VMに付けようと思っていますが、その場合、上記の仕組みが使えるので、変数の型が変わっても平気です。
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
