Bootstrap Lisp の2
２、３の論点がある
bootstrap言語に対する要求
目的をハッキリしておく必要がある。
bootstrap言語は、システムまたはアーキテクチャを新規に開発したときに、最小の手間で実装でき、最大の効果を発揮することが求められる。
前回に書いたように、旧来、この役割はforthが適任だった。プロセッサそのものをForthに認められるようなスタックマシンにすれば、アセンブラそのものが十分な表現能力を持った物とすることができた。
しかし、現在はbootstrap環境であっても高度なプロトコルや対話環境は要求事項になりつつある。このため、Forthよりも一般的で使い勝手の良い言語を実装することにも意義がある。
もちろんForthでLispを実装することも不可能ではないが、明示的にLispを支援する機構を備えたスタックマシンと、それに対する各種ライブラリを整備することが目的といえる。
要するに、この試みは『C言語(gcc)が動作しなければプロセッサにあらず』という風潮、言い換えれば、とりあえず自分のプロセッサをgccに移植するという圧力からプロセッサ作者を解放するという目的を持つ。
メモリ拡張性
16+16bitでは、64k個のペアしか扱えないことになる。これは幾つかの目的、例えばFATファイルシステムの解釈だとか、他の用途には使えない可能性が高い。これはあまり望ましくない。
32+32bitにすることは十分に検討できる。この場合、文字列をpackして格納する(1ペアに4文字まで格納する)ことも考慮に値するだろう。
例えばCAMPUS LIsPは1024固定数のペアを持ち(ver 1.2の場合)、すべての数の上位ビットをタグとして予約している。このような実装はある程度常識的といえる。
(通常の使用状況において、)carとcdrの両方が整数値であるペアは非常に少ないので、ポインタのビット数を削ってcdr部の即値としては32bit使えるようにすることは一定の意義があるように思える。これはコーディングを少々複雑にする。
今後は32bit+32bitで検討する。
ポインタのフォーマット
ポインタは、本当のポインタ(整数)以外に、以下の情報を持つ必要がある。
これらはポインタの上部(または下部 - 対象CPUがバイト単位のアドレスを採用しているならこちらも検討の価値があるだろう)をつぶして入れることになる。当然、4Gものペアをアドレスすることは出来なくなる。
ごく一部のRISC(sparc)はタグ付き加減算命令として下位を無視した加減算を提供し、整数に対してこのようなフラグが埋め込まれる事態を想定している。
他
- lambdaをどう実現するのか(束縛をどう保存するのか)
- 誰がS式を評価するのか
- パケットバッファや割り込みのための独自の拡張
- packed辞書機構
- 他のlisp方言への準拠
例えば継続は強力な手段で、スタックマシンによる実装であればそれほど難しい問題でも無いが、絶対に必要かと言うと絶妙な所だと言わざるを得ない。
