実はDiksamは当初JVM用のバイトコードを吐く言語として実装しようとしてました。
でもやめたのは、企画の趣旨上いずれVM側も作るつもりだったのですが、JVMを自分で作ることを考えると、難しいというよりも*1むしろ「変」なので、ちと作る気になれなかったためです。
具体的にすぐ思いつくのがこれ。
- doubleやlongがスタックで2スロット食って、iloadとかで指定するスタックフレームのインデックスも実際にそうなってること。
- コンスタントプールでもdoubleやlongは2スロット食って、コンスタントプールのインデックスも実際にそうなってること。
「longは8バイトでintは4バイトだから当たり前じゃん」というのはあまりにもCPUアーキテクチャに近いレベルの話ではないか。現状主流のCPUを前提にするだけでも、アライメントの問題もありこのままのインデックスで実メモリに配置できるわけでもないのに、こんな定数をバイトコードに埋め込んでしまってどうする。どうせ実行時に読み替える必要があるのなら、サイズに関係なく、0, 1, 2, ... と連番で振るほうがずっとマシだろう。
そもそも私はJavaとかの言語が「intは32ビット」と決めうちにしてしまっているのも気に食わない(というかメリットがさっぱり理解できない)のですが、それについてはまた今度。
