1 / 30

C--

C--. Mizukami Tatsuo 2001/07/18. コンパイラを書こう！. 以下の性質がほしいよね 出力コードが最適化されてて、暴速 Intra- inter- procedual register allocation Instruction selection, scheduling Jump elimination, et al どのマシン用にもバイナリが出力できる SPARC, MIPS, Alpha, PowerPC, Pentium …. ⇒時間・人力がとてもかかる. 解決方法1. 中間言語に C を使用する 長所

tara
Télécharger la présentation

C--

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. C-- Mizukami Tatsuo 2001/07/18

  2. コンパイラを書こう！ • 以下の性質がほしいよね • 出力コードが最適化されてて、暴速 • Intra- inter- procedual register allocation • Instruction selection, scheduling • Jump elimination, et al • どのマシン用にもバイナリが出力できる • SPARC, MIPS, Alpha, PowerPC, Pentium … ⇒時間・人力がとてもかかる

  3. 解決方法1 中間言語にCを使用する • 長所 • ほとんどのマシン言語にコンパイル可能 • プラットホームに特化した最適化も豊富 • 短所 • そもそも中間言語用として設計されてない GC, tail call, multiple result, …

  4. My source code My favoriate Front end C code SPARC x86 PowerPC Arm MIPS Alpha

  5. 解決方法２ 中間言語にJVMLを使用する • 長所 • write-once, run-anywhere • 短所 • 抽象化レベルが高い • Java用にのみ設計されている。 • write-once, test-anywhere

  6. My source code My favoriate Front end JVML SPARC x86 PowerPC Arm MIPS Alpha

  7. 解決方法３ 新たな中間言語を設計する • どのようなソース言語にも対応 • どのようなマシン言語も出力可能 • 従来のコンパイラ技術も使える • GC,例外処理にも対応 だから、作ってみました。 「 C-- 」

  8. My source code My favoriate Front end ？ C-- SPARC x86 PowerPC Arm MIPS Alpha

  9. 誰もが気にする名前の由来 • C--は • Cのサブセットではない • ‘C’は設計の基準となったのが、Cだから • では、‘--’は？ • より、アセンブラに近いから?　(推論) • C++に対抗意識をもった？ (推論)

  10. C--の目標 C--は実装が難しいコンパイラ技術をカプセル化する。ただし、 • コード出力はCと同じくらい簡単 • 最適化はCと同じくらい良い • GC, 例外処理のポリシーは利用者が決定

  11. C--の特徴 • Portable • High-Performance • Exploits existing code generator • Independent of particular generator • Independent of target architecture • Inter-operable • Human writable, readable

  12. C--とCの差異 • ローカル変数はレジスタに割り当て 　(レジスタは無限) • 明示的なメモリアクセス • tail call • multiple result • 自由なCalling conventions (指定も可能) • その他 (GC, 例外はそのときに説明)

  13. /* Ordinary recursion */ sp1(word4 n) { word4 s, p; if n==1 { return( 1, 1); } else { s, p = sp1(n-1); return( s+n, p*n); } }

  14. /* Tail recursion */ sp2(word4 n) { jump sp2_help(n, 1, 1); } sp2_help(word4 n, word4 s, word4 p) { if n==1 { return( s, p); } else { jump su_2help(n-1, s+n, p*n); } }

  15. C-- Status

  16. GC : 概論 C--にはどのようなGCが望まれるのか？ • accurate garbage collection • not conservative GC • ソース言語の特徴に対応したGC • オブジェクトのサイズ・数... • Mark, Copy, et al

  17. GC : 問題点と解決方法 • データの型 • front endがポインタ型の情報を作成 • Runtime Systemに登録して使用 • メモリ管理（マシン非依存、ポリシー決定可) • Runtime Systemを導入 • Interfaceを使用して、好きなGCを作成

  18. GC : データ型 • 関数で使用されるレジスタの型を静的に決定し、保存した構造体をDescriptorという • 使用者が好きにデザインしてよい • f(x : pointer, y : int) 例) data { gc1 : bit32 2; /* this procedure has 2 variable */ bit8 1; /* x is a pinter */ bit8 0; /* y is a non-pointer */ }

  19. GC : データ型の登録・取得 • コンパイラが登録を行う。 span GC gc1 { f(bits32 x, bits y) { ... code for f ... } } • データ型の動的な取得 • 現在のProgram Counterをキーとして、対応するProcedureのDescriptorを得る。

  20. GC : メモリ管理 • 例えば、以下のようなCopy GCが行われる (次のページはそのソースコード) • gc関数の呼び出し • 現在のStack frameから最古のStack frameまでスイッチし、以下の手順を行う。 • フレーム内の変数のアドレスを得る。 • その変数がポインタか判断 • ポインタならその先をcopyする • from-spaceとto-spaceのスイッチ

  21. struct gc_descriptor { unsigned var_count; char heap_ptr[1]; }; void gc(void) { activation a; FirstActivation(tcb, &a); for(;;) { struct gc_descriptor *d = GetDescriptor(&a, GC); if(d != NULL) { int i; for(i = 0; i < d->var_count; i++) if(d->heap_ptr[i]) { typedef void *pointer; pointer *rootp = FindVar(a, i); if(rootp != NUL) *rootp = gc_forward(*rootp); } } if(NextActivation(&a) == NULL) break; } gc_copy(); } Copy GCの作成例

  22. Botton of stack Activation record Top of stack Walking a stack Activation handle Pointer to an activation record Pointer to first calle-save register Pointer to second calle-save register

  23. 例外処理 • GCのところで説明したRuntime Interfaceを再利用しても、実現可能。 • GCではProcedureに対応するポインタ情報を登録していた • 例外用の情報も登録可能。

  24. 例外処理の対処方法 • 主に４つの実装方法がある • Continuation-passing style (SML/NJ) • Constant-time "stack-cutting" (OCaml) • Unwind stack in run-time system (Poly M3) • Custom code to unwind stack (Self) C--は特定の例外処理に束縛してよいのか

  25. 最新の論文の例外処理機構 • 例外処理の方式をfront endが選択でくるようにC--を拡張している　 [Norman and Simon, 2000] • 例外処理の選択には、次の視点がある • stackを一段づつ上るか • Runtimeが処理するか

  26. Alternatives for control transfer Stack walk required?

  27. Stack cutting Stackを頭から順に調べることなく、例外ハンドラにジャンプする • 長所 • Constant timeでTrap可能 • 短所 • callee-save registerの復帰ができない

  28. Stack unwinding • スタックを頭から順に調べて、例外がキャッチされるかを調べる • 長所 • callee-save registerの復帰が可能 • 短所 • Stackの深さの分だけ時間がかかる

  29. Reference(1) • Simon Peyton Jones, Thomas Nordin, and Dino Oliva. C--: A Portable Assembly Language.In Proceedings of the 1997 Workshop on Implementing Functional Languages, St Andrews, ed C Clack, Springer Verlag LNCS, 1998. • Simon Peyton Jones, Norman Ramsey, Fermin Reig. C--: a portable assembly language that supports garbage collection.International Conference on Principles and Practice of Declarative Programming, 1999.

  30. Reference(2) • Norman Ramsey, Simon L. Peyton Jones: A single intermediate language that supports multiple implementations of exceptions. PLDI 2000: 285-298

More Related