Essen Rev2
(0)
- EssenRev1が完成しないうちから、Rev2の構想が進んでしまいました。
(1)
- EssenRev2では実行方式がJITコンパイル方式になります。
- EssenRev1では「速度はどうでもいい、速さがほしければインラインC言語で書けばいい」という立場をとっていましたが、JITコンパイル方式にするだけで性能が100倍くらい変わりそうで、やっぱりそんなに差が出るのならJITコンパイル方式を採用すべきかもなあ、と考え方が変わったのです。
- 10倍未満なら、まあそんなもんだよなーと思えたのですが・・・。
- JITコンパイル方式だと、変換速度は実行速度にほとんど影響しないので、アルゴリズムをあまりがんばらなくてもよくなります。それは気楽なので、メリットの一つです。
- もちろん、ダメダメなコードを生成してはいけませんが。
(2)
- JIT00 : 仮想アセンブラ(JIT00) → 機械語
- それぞれのレイヤは、C言語のライブラリ関数として実装されます。別々の実行ファイルになるわけではありません。実行したいプログラムを文字列として読み込んで、それをJIT01にかけて、その結果をJIT00にかけて、出てきたバイナリをC言語の関数呼び出しで呼び出せば、それで実行できるという仕組みです。
(3) 主な仕様
- 真偽値はintだが、最下位ビットのみで真偽をあらわす。他のビットはごみ。C言語のように0かそれ以外かという基準ではない。
- そもそも0かそれ以外かという基準だと、すべてのビットを見なければいけないということであり、ハードウェア的にやさしくない。
- しかもどのビットが化けても偽が真に化ける。EssenRev2ならビット化けのリスクは1ビット分しかない。
- なお、真偽値を0か-1かであらわすことにすれば、ビット化けのリスクはもっと減らせるが（ビット化けがあっても多数決で修正できる）、それはそれでコストが増すのでやらないことにする。
- C言語ではintは16ビット以上、longはint以上、long longはlong以上というだけで、それ以上の規定がない。これはよくないとKは思っている。だからEssenRev2ではこうする。
- intは32ビット以上。longは64ビット以上。
- Essenでは上記さえ満たしていれば、intのビット幅とlongのビット幅が逆転していても問題はない。さらに「intがそのマシンにとって自然なビット幅」というルールはない。
- 同様にfloatは32ビット以上。doubleは64ビット以上。
- intとfloatを基本型として、それ以外は拡張型とする。
- こう書けば機種異存のないコードが作りうるという仕様になっているだけで、仕様の範囲で書きさえすれば自動的に機種依存しなくなるというレベルは目指さない（それをやると遅くなるなどの弊害があるので）。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
