Mercurial > hg > Papers > 2019 > anatofuz-prosym
comparison Paper/anatofuz.tex @ 19:3e4ffa621ae9
add after work
author | Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Wed, 07 Nov 2018 22:35:07 +0900 |
parents | b2a795a294c4 |
children | 2bf64cfb91b1 |
comparison
equal
deleted
inserted
replaced
18:0cce27e3a63a | 19:3e4ffa621ae9 |
---|---|
232 その為gdbでMoarVMをCbCとオリジナル版での並列デバッグを人間が同時に行うことは困難である. | 232 その為gdbでMoarVMをCbCとオリジナル版での並列デバッグを人間が同時に行うことは困難である. |
233 Perlなどのスクリプトを用いて自動的に解析したいため,ログを残す為にscriptコマンドを実行した状態でgdbを起動する. | 233 Perlなどのスクリプトを用いて自動的に解析したいため,ログを残す為にscriptコマンドを実行した状態でgdbを起動する. |
234 CbC側はcbc\_nextにbreak pointを設定し,オリジナル側は次のオペコードの設定のマクロにダミーの関数を呼び出すように修正し,そこにbreak pointを設定する. | 234 CbC側はcbc\_nextにbreak pointを設定し,オリジナル側は次のオペコードの設定のマクロにダミーの関数を呼び出すように修正し,そこにbreak pointを設定する. |
235 CbC側ではCodeSegmentの名前を直接確認できるが,オリジナル版はLABLEの配列の添え字から自分でどのオペコードに対応しているかを探す必要がある. | 235 CbC側ではCodeSegmentの名前を直接確認できるが,オリジナル版はLABLEの配列の添え字から自分でどのオペコードに対応しているかを探す必要がある. |
236 CbCとオリジナルのCODES,LABELの添字は対応している為,ログの解析を行う際はそれぞれの添字を抽出し違いが発生している箇所を探索する. | 236 CbCとオリジナルのCODES,LABELの添字は対応している為,ログの解析を行う際はそれぞれの添字を抽出し違いが発生している箇所を探索する. |
237 違いが生じている箇所が発見できた場合,その前後のCodeSegment及びディスパッチ部分にbreak pointをかけ,それぞれの変数の挙動を比較する. | |
238 主にcbc\_return系の命令が実行されている場合は,その直前で命令を切り替えるcbc\_invoke系統の命令が呼ばれているが,この周辺で何かしらの違いが発生している可能性が高い. | |
239 その為,アセンブラレベルの命令を確認しながらデバッグを進めることとなる. | |
240 | |
237 | 241 |
238 | 242 |
239 \subsection{CbCコンパイラによるバグ} | 243 \subsection{CbCコンパイラによるバグ} |
240 現在までのCbCは複数個の入出力をCodeSegmentに与えるユースケースで利用していた. | 244 現在までのCbCは複数個の入出力をCodeSegmentに与えるユースケースで利用していた. |
241 CbCコンパイラ自身はそれぞれ用意したテストスイートを通化するものの,MoarVMの様な巨大なプロジェクトのCSをコンパイルを実行する場合,予期せぬバグが発生した. | 245 CbCコンパイラ自身はそれぞれ用意したテストスイートを通化するものの,MoarVMの様な巨大なプロジェクトのCSをコンパイルを実行する場合,予期せぬバグが発生した. |
242 主にCS間のgotoにおけるtail callフラグの除去や,DSとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDSのアドレスの周辺を利用してしまう. | 246 主にCS間のgotoにおけるtail callフラグの除去や,DSとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDSのアドレスの周辺を利用してしまう. |
243 その為DSの構造体の値が書き換わり,CからDSにreturnした際にDSの構造体が破壊されるバグである. | 247 その為DSの構造体の値が書き換わり,CからDSにreturnした際にDSの構造体が破壊されるバグである. |
248 このバグは先程の並列デバッグを行いながらプログラムカウンタや変数の動きをトレースする事などで発見することが出来る. | |
244 現状ではCbCコンパイラがプログラマの意図と反する挙動を取るためCbCコンパイラのバグを回避するプログラミングが要求されている. | 249 現状ではCbCコンパイラがプログラマの意図と反する挙動を取るためCbCコンパイラのバグを回避するプログラミングが要求されている. |
245 本来コンパイラ側のバグを回避するプログラミングをプログラマに要求するスタイルは好ましくない. | 250 本来コンパイラ側のバグを回避するプログラミングをプログラマに要求するスタイルは好ましくない. |
246 従ってCbCコンパイラ自身の信頼性を向上させる事も今後の課題となっている. | 251 従ってCbCコンパイラ自身の信頼性を向上させる事も今後の課題となっている. |
247 | 252 |
248 \subsection{Threaded Code} | 253 \subsection{Threaded Code} |
285 % \end{tabular} | 290 % \end{tabular} |
286 % \end{table} | 291 % \end{table} |
287 | 292 |
288 | 293 |
289 \section{今後の課題} | 294 \section{今後の課題} |
290 | 295 本論文ではCbCによってPerl6の処理系であるMoarVMインタプリタの一部改良とその手法を示した. |
296 CbCのCodeSegment部分を用いることできめ細やかな記述が出来,デバッグし辛い箇所もbreakpointの設定などが容易になった. | |
297 | |
298 今後CbCでの開発をより深く行っていくにあたり,CbCコンパイラそのものの信頼性を向上させる必要がある. | |
299 MoarVMの開発を行うにあたり新たに発見された複数のバグを修正し,より安定するコンパイラに改良を行う. | |
300 | |
301 現在CbCMoarVMで直接バイトコードを入力した場合のnqpのテストは\%パスする. | |
302 また数値の計算と出力などの簡単なNQPの例題を作成し,オリジナルのNQP,moarvmでバイトコード化したものを入力した際も正常に動作している. | |
303 今後はさらに複雑な例題やPerl6の独自文法でも動くかどうかの実験を行う. | |
304 | |
305 MoarVMではGCからオブジェクトを守る為にMVMROOTというマクロを利用し,局所変数のポインタをスタックに登録する処理を行っている. | |
306 GCの制御を効率的に行えば本来は必要ない処理であり,実行するとCodeSegmentの優位性が損なわれてしまう. | |
307 従ってMoarVMのGCの最適化を行う. | |
308 | |
309 また高速化という面では,Perlの特徴である正規表現に着目し,正規表現の表現のみ高速で動く最適化の導入なども検討している. | |
310 | |
311 Perl6の開発は非常に活発に行われている為,CbCMoarVMの最新版の追従も課題となっている. | |
312 現在はinterp.cからPerlスクリプトを用いて自動でCbCのCodeSegmentを生成している. | |
313 今後の開発領域の拡大と共により効率的にCbCコードへの自動変換も開発していく. | |
291 | 314 |
292 %å\subsection{MoarVMの処理流れ} | 315 %å\subsection{MoarVMの処理流れ} |
293 %MoarVMはC言語で実装されており,Perl5で記述されたConfigure.plを | 316 %MoarVMはC言語で実装されており,Perl5で記述されたConfigure.plを |
294 | 317 |
295 | 318 |