Mercurial > hg > Papers > 2019 > anatofuz-thesis
changeset 30:3ad581842874
swap chap2,3
author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Tue, 12 Feb 2019 17:22:22 +0900 |
parents | 96e9cf9c2ea2 |
children | 883ce7c5921e |
files | paper/chapter2.tex paper/chapter3.tex |
diffstat | 2 files changed, 109 insertions(+), 109 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/chapter2.tex Tue Feb 12 17:02:56 2019 +0900 +++ b/paper/chapter2.tex Tue Feb 12 17:22:22 2019 +0900 @@ -1,74 +1,49 @@ -\chapter{Perl6} -\section{Perl6の概要} -Perl6は現在開発が勧められているプログラミング言語である。 -スクリプト言語Perl5の次期バージョンとして当初は開発されていたが、 現在では互換性の無さなどから別言語として開発されている。 +\chapter{Continuation Based C} +\section{CbCの概要} +Continuation Based C (CbC) は当研究室で開発を行っているプログラミング言語である。 +現在はCコンパイラであるgcc及びllvmをバックエンドとしたclang、 MicroCコンパイラ上の3種類の実装がある。 + +C言語を用いてプログラミングを行い場合、本来プログラマが行いたい処理の他に、 mallocなどの関数を利用したメモリのアロケートなどのメモリ管理が必要となる。 +他にもエラーハンドリングなどの雑多な処理が必要となる。 + +これらの処理をmeta computationと呼ぶ。 +実装しているプログラムにおけるエラーの原因が、 通常の処理かmeta computationなのか区別を行いたい。 +また、 プログラム自身の検証や証明も、 通常の関数などと meta computationは区別したい。 +通常C言語などを用いたプログラミングの場合、 meta computationと通常の処理を分割を行おうとすると、 それぞれ事細やかに関数やクラスを分割せねばならず容易ではない。 + +CbCでは関数よりmeta computationを細かく記述する為に、 CodeGearと呼ばれる単位を導入する。 +CodeGearでは、 データの入出力としてDetaGearという単位を導入する。 +CbCでは、 これらCodeGear と DetaGearを基本単位として実装していくプログラミングスタイルを取る。 + +\section{CodeGear} + +CbCではC言語の関数の代わりに CodeGear を導入する。 +CodeGearはC言語の関数宣言の型名の代わりに \_\_codeと書く事で宣言出来る。 +\_\_codeはCbCコンパイラでの扱いはvoidと同じ型として扱うが、 CbCプログラミングではCodeGearである事を示す、 識別子として利用する。 + +CodeGear間の移動はgoto文で行い、 gotoの後に対応するCodeGear名を記述することで遷移する。 +通常C言語の関数呼び出しでは、 スタックポインタを操作し、 ローカル変数や、 レジスタ情報をスタックに保存する。 +これらは通常アセンブラのcall命令として処理される。 + +CbCの場合、 スタックフレームを操作せずに次のCodeGearに遷移する。 +この際Cの関数呼び出しとは異なり、 プロラムカウンタを操作するのみのjmp命令として処理される。 +通常Schemeのcall/ccなどの継続と呼ばれる処理は、 現在のプログラムまでの位置や情報を、 環境として所持した状態で遷移する。 +CbCの場合これら環境を持たず遷移する為、 通常の継続と比較して軽量であるから、 軽量継続であると言える。 +CbCは軽量継続を利用するためにレジスタレベルでの実装が可能となり、 Cよりも低級な言語と言える。 -Perl6は仕様と実装が分離されており、 現在はテストスイートであるRoastが仕様となっている。 -実装は歴史的に様々なものが開発されており、 Haskellで実装されたPugs、 Pythonとの共同実行環境を目指したParrotなどが存在する。 -PugsやParrotは現在は歴史的な実装となっており、 開発は行われていない。 -現在の主要な実装であるRakudoは、 Parrotと入れ替わる形で実装が進んでいる。 -Perl6そのものはスクリプト言語として実装されており、 漸進的型付け言語である。 -言語的な特徴としては、 独自にPerl6の文法を拡張可能なGrammer、 Perl5と比較してオブジェクト指向言語としての機能の強化などが見られる。 - -\section{Rakudo} - -RakudoとはNQPによって記述され、 MoarVM、 JVM、 Javascript上で動作するPerl6の実装である。 -Rakudo自体はNQPで実装されている箇所と、 Perl6で実装されている箇所が混在する。 -これらは拡張子によって区別され、 NQPは.nqp、 Perl6は .pm6が拡張として設定されている。 -実際にNQPで実装されている箇所の一部をCode\ref{nqp_on_rakud}に示す。 -\lstinputlisting[frame=lrbt, label=nqp_on_rakud, caption=Rakudoの実装の一部]{./codes/src_main.nqp} - -Rakudoをソースコードからビルドする際は予めNQPインタプリタであるnqpをビルドする必要が存在する。 -Rakudoのビルド時にはこのnqpと、 nqpが動作するVMを設定として与える必要がある。 -この両者を指定しない場合、 ビルド時に動的にNQP、 MoarVMをソースコードをダウンロードし、 ビルドを行う。 - -\section{MoarVM} -MoarVMとはRakudo実装で主に使われる仮想機械である。 -RakudoではPerl6とNQPを実行する際に仮想機械上で実行する。 -この仮想機械はOSレベルの仮想化に使用するVirtualBoxやqemuと異なり、プロセスレベルの仮想機械である。 -Rakudoではこの仮想機械にMoarVM、 Javaの仮想機械であるJVM(JavaVirtualMachine)が選択可能である。 -MoarVMはこの中でRakudo独自に作成された仮想機械であり、 現在のRakudoプロジェクトの主流な実装となっている。 - -MoarVMはC言語で実装されており、 レジスタベースの仮想機械である。 -MoarVMはNQPやPerl6から与えられたMoarVMバイトコードを評価する。 - -\section{NQP} -NQPとはRakudoにおけるPerl6の実装に利用されているプログラミング言語である。 -NQP自体は、 Perl6のサブセットとして開発されている。 -歴史的にはPerl6の主力実装がParrotであった際に開発され、 現在のRakudoに引き継がれている。 -RakudoにおけるNQPは、 Parrot依存であった実装が取り払われている。 - -基本文法などはPerl6に準拠しているが、 変数を束縛で宣言する。インクリメント演算子が一部利用できない。 -Perl6に存在する関数などが一部利用できないなどの制約が存在する。 - -NQPのコード例をCode\ref{fib_nqp}に示す。 -\lstinputlisting[frame=lrbt, label=fib_nqp, caption=フィボナッチ数列を求めるNQPのソースコード]{./codes/fib.nqp} +CodeGear間の入出力の受け渡しは引数を利用して行う。 +これは軽量継続時に、 CodeGearの入出力のインターフェイスを揃えることで、 引数で与えられたレジスタを変更せずに繊維する事が可能であるためである。 -Perl6はNQPで実装されている為、 Perl6におけるVMはNQPの実行を目標として開発されている。 +実際にCbCで書いたコード例をCode\ref{cbc_example_test}に示す。 + +\lstinputlisting[frame=lrbt, label=cbc_example_test, caption=加算と文字列を設定するCbCコードの例]{./codes/cbc_example_test.cbc} -NQP自体もNQPで実装されており、 NQPのビルドには予め用意されたMoarVMなどのVMバイトコードによるNQPインタプリタが必要となる。 -実際にNQP内部で入力として与えられたNQPから加算命令を生成する部分をCode\ref{nqp_code_add_ops}に示す。 - -\lstinputlisting[frame=lrbt, label=nqp_code_add_ops, caption=NQPが加算命令を生成する箇所]{./codes/nqp_ops.nqp} +この例では、 cg1, cg2, cg3という CodeGear を用意し、これらをcg1,cg2,cg3の順で軽量継続していく。 +入出力としてmain関数で生成したTEST構造体を受け渡し、 cg1で数値の加算を、 cg2で文字列の設定を行う。 +main関数からcg1へのgoto文では、 Cの関数からCodeGearへの移動となる為、 call命令ではなくjmp命令で行われる。 +cg1からcg2、 またcg2からcg3へは、 CodeGear間での移動となるためjmp命令での軽量継続で処理される。 +この例では最終的に test.number には1が、 test.stringにはHelloが設定される。 -MoarVMを利用する場合、 MoarVMの実行バイナリであるmoarに対して、 ライブラリパスなどを予め用意したNQPインタプリタのバイトコードに設定する。 -設定はオプションで与える事が可能であり、 moarを実行することでNQPのインタプリタが起動する。 -NQPのビルドには、 このNQPインタプリタをまず利用し、 NQP自体のソースコードを入力して与え、 ターゲットとなるVMのバイトコードを生成する。 -このバイトコードはNQPソースコードから生成されたNQPインタプリタのバイトコードであり、 次にこのバイトコードをライブラリとしてmoarに与え、 再びNQPをビルドする。 -この2度目のビルドで、ソースコードからビルドされたVMバイトコードでNQP自身をビルドした事になる。 -処理系自身をその処理系でビルドする事をセルフビルドと呼び、 NQPはセルフビルドしたバイナリを利用する。 -2度目のビルドの際に生成されたNQPインタプリタの事を小文字のnqpと呼び、これがNQPのインタプリタのコマンドとなる。 - - - - -%Data Gear はデータの単位であり、int や文字列などの Primitive Type を持っている。 - -%Code Gear は 任意の数の Input Data Gear を参照して処理を行い、Output Data Gear を出力し処理を終える。 -%また、接続された Data Gear 以外には参照を行わない。 - -%処理やデータの構造が Code Gear、Data Gear に閉じているため、これにより実行時間、メモリ使用量などを予測可能なものにすることが可能になる。 -
--- a/paper/chapter3.tex Tue Feb 12 17:02:56 2019 +0900 +++ b/paper/chapter3.tex Tue Feb 12 17:22:22 2019 +0900 @@ -1,49 +1,74 @@ -\chapter{Continuation Based C} -\section{CbCの概要} -Continuation Based C (CbC) は当研究室で開発を行っているプログラミング言語である。 -現在はCコンパイラであるgcc及びllvmをバックエンドとしたclang、 MicroCコンパイラ上の3種類の実装がある。 - -C言語を用いてプログラミングを行い場合、本来プログラマが行いたい処理の他に、 mallocなどの関数を利用したメモリのアロケートなどのメモリ管理が必要となる。 -他にもエラーハンドリングなどの雑多な処理が必要となる。 - -これらの処理をmeta computationと呼ぶ。 -実装しているプログラムにおけるエラーの原因が、 通常の処理かmeta computationなのか区別を行いたい。 -また、 プログラム自身の検証や証明も、 通常の関数などと meta computationは区別したい。 -通常C言語などを用いたプログラミングの場合、 meta computationと通常の処理を分割を行おうとすると、 それぞれ事細やかに関数やクラスを分割せねばならず容易ではない。 - -CbCでは関数よりmeta computationを細かく記述する為に、 CodeGearと呼ばれる単位を導入する。 -CodeGearでは、 データの入出力としてDetaGearという単位を導入する。 -CbCでは、 これらCodeGear と DetaGearを基本単位として実装していくプログラミングスタイルを取る。 - -\section{CodeGear} - -CbCではC言語の関数の代わりに CodeGear を導入する。 -CodeGearはC言語の関数宣言の型名の代わりに \_\_codeと書く事で宣言出来る。 -\_\_codeはCbCコンパイラでの扱いはvoidと同じ型として扱うが、 CbCプログラミングではCodeGearである事を示す、 識別子として利用する。 - -CodeGear間の移動はgoto文で行い、 gotoの後に対応するCodeGear名を記述することで遷移する。 -通常C言語の関数呼び出しでは、 スタックポインタを操作し、 ローカル変数や、 レジスタ情報をスタックに保存する。 -これらは通常アセンブラのcall命令として処理される。 - -CbCの場合、 スタックフレームを操作せずに次のCodeGearに遷移する。 -この際Cの関数呼び出しとは異なり、 プロラムカウンタを操作するのみのjmp命令として処理される。 -通常Schemeのcall/ccなどの継続と呼ばれる処理は、 現在のプログラムまでの位置や情報を、 環境として所持した状態で遷移する。 -CbCの場合これら環境を持たず遷移する為、 通常の継続と比較して軽量であるから、 軽量継続であると言える。 -CbCは軽量継続を利用するためにレジスタレベルでの実装が可能となり、 Cよりも低級な言語と言える。 +\chapter{Perl6} +\section{Perl6の概要} +Perl6は現在開発が勧められているプログラミング言語である。 +スクリプト言語Perl5の次期バージョンとして当初は開発されていたが、 現在では互換性の無さなどから別言語として開発されている。 -CodeGear間の入出力の受け渡しは引数を利用して行う。 -これは軽量継続時に、 CodeGearの入出力のインターフェイスを揃えることで、 引数で与えられたレジスタを変更せずに繊維する事が可能であるためである。 +Perl6は仕様と実装が分離されており、 現在はテストスイートであるRoastが仕様となっている。 +実装は歴史的に様々なものが開発されており、 Haskellで実装されたPugs、 Pythonとの共同実行環境を目指したParrotなどが存在する。 +PugsやParrotは現在は歴史的な実装となっており、 開発は行われていない。 +現在の主要な実装であるRakudoは、 Parrotと入れ替わる形で実装が進んでいる。 +Perl6そのものはスクリプト言語として実装されており、 漸進的型付け言語である。 +言語的な特徴としては、 独自にPerl6の文法を拡張可能なGrammer、 Perl5と比較してオブジェクト指向言語としての機能の強化などが見られる。 + +\section{Rakudo} + +RakudoとはNQPによって記述され、 MoarVM、 JVM、 Javascript上で動作するPerl6の実装である。 +Rakudo自体はNQPで実装されている箇所と、 Perl6で実装されている箇所が混在する。 +これらは拡張子によって区別され、 NQPは.nqp、 Perl6は .pm6が拡張として設定されている。 +実際にNQPで実装されている箇所の一部をCode\ref{nqp_on_rakud}に示す。 +\lstinputlisting[frame=lrbt, label=nqp_on_rakud, caption=Rakudoの実装の一部]{./codes/src_main.nqp} + +Rakudoをソースコードからビルドする際は予めNQPインタプリタであるnqpをビルドする必要が存在する。 +Rakudoのビルド時にはこのnqpと、 nqpが動作するVMを設定として与える必要がある。 +この両者を指定しない場合、 ビルド時に動的にNQP、 MoarVMをソースコードをダウンロードし、 ビルドを行う。 + +\section{MoarVM} +MoarVMとはRakudo実装で主に使われる仮想機械である。 +RakudoではPerl6とNQPを実行する際に仮想機械上で実行する。 +この仮想機械はOSレベルの仮想化に使用するVirtualBoxやqemuと異なり、プロセスレベルの仮想機械である。 +Rakudoではこの仮想機械にMoarVM、 Javaの仮想機械であるJVM(JavaVirtualMachine)が選択可能である。 +MoarVMはこの中でRakudo独自に作成された仮想機械であり、 現在のRakudoプロジェクトの主流な実装となっている。 + +MoarVMはC言語で実装されており、 レジスタベースの仮想機械である。 +MoarVMはNQPやPerl6から与えられたMoarVMバイトコードを評価する。 + +\section{NQP} +NQPとはRakudoにおけるPerl6の実装に利用されているプログラミング言語である。 +NQP自体は、 Perl6のサブセットとして開発されている。 +歴史的にはPerl6の主力実装がParrotであった際に開発され、 現在のRakudoに引き継がれている。 +RakudoにおけるNQPは、 Parrot依存であった実装が取り払われている。 + +基本文法などはPerl6に準拠しているが、 変数を束縛で宣言する。インクリメント演算子が一部利用できない。 +Perl6に存在する関数などが一部利用できないなどの制約が存在する。 + +NQPのコード例をCode\ref{fib_nqp}に示す。 +\lstinputlisting[frame=lrbt, label=fib_nqp, caption=フィボナッチ数列を求めるNQPのソースコード]{./codes/fib.nqp} -実際にCbCで書いたコード例をCode\ref{cbc_example_test}に示す。 - -\lstinputlisting[frame=lrbt, label=cbc_example_test, caption=加算と文字列を設定するCbCコードの例]{./codes/cbc_example_test.cbc} +Perl6はNQPで実装されている為、 Perl6におけるVMはNQPの実行を目標として開発されている。 -この例では、 cg1, cg2, cg3という CodeGear を用意し、これらをcg1,cg2,cg3の順で軽量継続していく。 -入出力としてmain関数で生成したTEST構造体を受け渡し、 cg1で数値の加算を、 cg2で文字列の設定を行う。 -main関数からcg1へのgoto文では、 Cの関数からCodeGearへの移動となる為、 call命令ではなくjmp命令で行われる。 -cg1からcg2、 またcg2からcg3へは、 CodeGear間での移動となるためjmp命令での軽量継続で処理される。 -この例では最終的に test.number には1が、 test.stringにはHelloが設定される。 +NQP自体もNQPで実装されており、 NQPのビルドには予め用意されたMoarVMなどのVMバイトコードによるNQPインタプリタが必要となる。 +実際にNQP内部で入力として与えられたNQPから加算命令を生成する部分をCode\ref{nqp_code_add_ops}に示す。 + +\lstinputlisting[frame=lrbt, label=nqp_code_add_ops, caption=NQPが加算命令を生成する箇所]{./codes/nqp_ops.nqp} +MoarVMを利用する場合、 MoarVMの実行バイナリであるmoarに対して、 ライブラリパスなどを予め用意したNQPインタプリタのバイトコードに設定する。 +設定はオプションで与える事が可能であり、 moarを実行することでNQPのインタプリタが起動する。 +NQPのビルドには、 このNQPインタプリタをまず利用し、 NQP自体のソースコードを入力して与え、 ターゲットとなるVMのバイトコードを生成する。 +このバイトコードはNQPソースコードから生成されたNQPインタプリタのバイトコードであり、 次にこのバイトコードをライブラリとしてmoarに与え、 再びNQPをビルドする。 +この2度目のビルドで、ソースコードからビルドされたVMバイトコードでNQP自身をビルドした事になる。 +処理系自身をその処理系でビルドする事をセルフビルドと呼び、 NQPはセルフビルドしたバイナリを利用する。 +2度目のビルドの際に生成されたNQPインタプリタの事を小文字のnqpと呼び、これがNQPのインタプリタのコマンドとなる。 + + + + +%Data Gear はデータの単位であり、int や文字列などの Primitive Type を持っている。 + +%Code Gear は 任意の数の Input Data Gear を参照して処理を行い、Output Data Gear を出力し処理を終える。 +%また、接続された Data Gear 以外には参照を行わない。 + +%処理やデータの構造が Code Gear、Data Gear に閉じているため、これにより実行時間、メモリ使用量などを予測可能なものにすることが可能になる。 +