YamaKen
yamak****@bp*****
2005年 10月 14日 (金) 10:42:35 JST
At Thu, 13 Oct 2005 16:59:59 -0700, jun.l****@gmail***** wrote: > > On Fri, 14 Oct 2005 07:51:04 +0900 > YamaKen <yamak****@bp*****> wrote: > > > S Type > > 0000000|00G : #f (S = 0) > > .......|00G : Cons > > ------------------------------ > > 0000000|01G : () (S = 0) > > .......|01G : Closure > > ------------------------------ > > 0000000|10G : Unbound (S = 0) > > .......|10G : Others > > ------------------------------ > > ......0|11G : Integer (imm) > > ------------------------------ > > ......1|11G : Char (imm) > > ------------------------------ > > ここを > .......0|11G : Integer (imm) > ......01|11G : Const (imm) > ......11|11G : Char (imm) > とすれば、#f, (), unbound, #t, EOF, undef その他入れたければ 128M 種類が > 即値に入ります。int の表現範囲も犠牲になりません。 charも自由度の高いエンコーディングのためになるべく広く取っておき たいところです。それからNULL|tag形式は後述のように実行・サイズ効 率のためでもあるので。 あ、ついでですがshift無しでcharacter valueを扱う場合のためにint じゃなくてcharの方を011Gにした方がよいと思います。 ......0|11G : Char (imm) ------------------------------ ......1|11G : Integer (imm) > > S->Y of Others > > O Type content of O > > ........|001 : Symbol : vcell > > string name でないといけません。Others の定義は S->Y が ScmObj の > convention に縛られない、です。 stringの8byte alignを保証できるならそれでもいいんですが、さすが にちょっと移植性が気になります。heapと違って割り当てサイズ小さい し。 ScmObj の convention に縛られない、というのはわかるんですが、 ScmObjを格納してはいけないという制約もあるんでしたっけ? > > ........|011 : String : string length > > ........|101 : Vector : vector length > > .....|000111 : Values : unused, all 0 (for efficiency) > > .....|001111 : Func : ScmFuncTypeCode > > .....|010111 : Port : ScmPortDirection > > .....|011111 : Continuation : unused, all 0 > > .....|100111 : C Pointer : pointer type (0 = void *, 1 = ScmFuncType) > > この ScmFuncType というのは? sizeof(function pointer) != sizeof(object > pointer) への対策でしょうか。でもこういう platform は今でも使われてるん > ですか? C99-rationale には PDP-11 がどうとか書いてあった気がしますが。 > ;; 何々 pointer というのは C 規格 level での用語の意味。 ↓こいつの事です。 typedef ScmObj (*ScmFuncType)(); が、こっちを使う方が適切ですね。 typedef void (*ScmCFunc)(void); ポインタのサイズはvoid *と同じ事を仮定してますが、warningを黙ら せるために型を分けてありました。SCM_REINTERPRET_CASTを使えば void *だけで済むんですが、せっかく値が格納できる事だし将来の拡張も見 越して型チェックに使ってもよいかなと。 > > .....|101111 : Reserved > > .....|110111 : Special Constant : constant ID > > 1 : #t > > 2 : EOF > > 3 : Undef > > .....|111111 : FreeCell : unused, all 1 (for efficiency) > > > > > > ・定数はeq?さえできればOKなので即値向けの専用の型は作らない > > > > ・NULL|tagによく使う定数をエンコード。大抵のアーキテクチャで > > immediate operandに収まる事を期待。CONSP等にNULLチェックが必要 > > になるけどそこは妥協 > > > > ・#t, EOF, UndefはOthersに押し込める > > > > ・#fは効率のため0にエンコード (重要) > > 何故? >NULL|tag, #f==0 #f == 0についてはzero register, jnz, jz, cmovnz, cmovzの類での効 率化期待です。 #fや()は井上さん形式にすると5-6bit必要になるんでアーキテクチャに よっては最小のimmediate operand fieldに収まらなくなったりするし、 明示的な比較命令も必要になります。 > CONSP() が多いので code size は増えそうな気がしますが? というか↑のように > して他の即値と一緒に入れましょうよ。 逆にNFALSEP, FALSEPではコードサイズ減少が見込めるんでそうそう肥 大化はしないんじゃないかと思ってます。CONSPでもレジスタに残って る値のゼロ判定が追加されるだけだし。実際どうなるか確実な予測はで きてませんが。 まあ分類上醜いという気持ちはよくわかるんですが。 > > ・こいつらは定数ではなく普通のsyntaxやsymbolとして扱う > > > > - Quote > > - Quasiquote > > - Unquote > > - UnquoteSplicing > > そういや symbol 回りを独立させるとかいう話はどうなったのかなー…なんて > 言ってみたり ありゃ、なんかありましたっけ。もう思考がSigSchemeから離れて composer branchの方に戻っちゃってるんで思い出せない… ------------------------------- ヤマケン yamak****@bp*****
