「コンパイラ・スクリプトエンジン」相談室13

1 名前：デフォルトの名無しさん mailto:sage [2009/01/28(水) 20:49:02 ] プログラミング言語処理系の開発に興味のある人達のスレッドです。 字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換， CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン， SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化， JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。 意味論に関する話題も歓迎です。 過去スレ 1 pc.2ch.net/tech/kako/981/981672957.html 2 pc2.2ch.net/test/read.cgi/tech/1021136715/ 3 pc5.2ch.net/test/read.cgi/tech/1070089173/ 4 pc5.2ch.net/test/read.cgi/tech/1100097050/ 5 pc8.2ch.net/test/read.cgi/tech/1106129164/ 6 pc8.2ch.net/test/read.cgi/tech/1115335709/ 7 pc8.2ch.net/test/read.cgi/tech/1129287390/ 8 pc8.2ch.net/test/read.cgi/tech/1131273918/ 9 pc8.2ch.net/test/read.cgi/tech/1135082582/ 10 pc8.2ch.net/test/read.cgi/tech/1146844753/ 11 pc11.2ch.net/test/read.cgi/tech/1160879890/ 12 pc11.2ch.net/test/read.cgi/tech/1188688416/ 関連リンクは多分 >>2-10 あたり 202 名前：デフォルトの名無しさん mailto:sage [2009/06/29(月) 00:17:14 ] #pragma有効で組むか さもなくば死か この時代にCを開発用途に使えたという時点である意味幸運だったとも言える 203 名前：デフォルトの名無しさん mailto:sage [2009/06/29(月) 12:13:13 ] 8080でのスタックフレームってめんどくさいよな 204 名前：デフォルトの名無しさん mailto:sage [2009/06/29(月) 23:59:31 ] 高級言語を意識して設計されてないから仕方ない Z80だとIX/IYで強引にやるのか？汎用/裏レジスタで最適化とかしてたら凄いが 205 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 00:51:28 ] IX/IYは人間向きのレジスタで、 便利ではあるけど遅いからコンパイラは使わない。 (HD64180あたりになると結構速かったが) LSI-C(MSX-C)はもちろん裏レジスタ使いまくり。 206 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 22:30:31 ] むかし見たLSI-C80の広告ではIXかIYをフレームポインタに使っていた コードが掲載されていた。 MSX-Cは裏レジスタ,IX,IYを使うコードは生成しなかったと思う。 付属のライブラリでは使っているかもしれませんが。 スタック上のローカル変数アクセスの方法はどうだったか記憶にありません。 MSX-Cのアセンブリ言語出力をZ80に最適化するプログラムを書いた人もいるようです。 僕も出力を見ていたときすこし考えたことありました。 アセンブリ言語レベルで8080から8086に変換するプログラムの存在を古い本で読んだのも思い出しました。 207 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 23:41:00 ] コンパイラが将来性のない 回顧主義者おっさんのたまり場であることがよくわかる だから日本は研究でも実業でもこの分野でチョン以下になる。 208 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 23:51:29 ] >>207 そんな愚にも付かないことを言ってるヒマがあったら、 LLVM向けに何かメジャーな言語を移植するのだ。 209 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 00:01:25 ] LLVMは糞だろ 210 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 00:22:10 ] >>209 どこがどう糞なの？ 211 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 23:55:53 ] >>210 Milepost GCCがあるから不要 自分でコードをチューニングするという古臭い時代は終わったの 自動的に学習して最適なコードを出力してくれるからLLVM自体不要なの 212 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 00:01:16 ] 幼稚園児かｗ 213 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 00:15:27 ] >>211 というか、同じようなアイデアのllvm-gccのほうが有名なわけだが？ 214 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 00:20:21 ] >>211 完全自動化だし、今年後半のコンパイラ関係の 賞総なめにするって言われてるけどねぇ EUレベルの国家プロジェクトと田舎大学の糞プロジェクト 比較されてもねぇ 215 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 00:23:40 ] 幼稚園児だな 216 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 07:15:50 ] ヒント：実績 217 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 17:26:47 ] Milepost GCCのICIな人たちが次はLLVMでやってみるって言ってんですがねえ… 218 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 18:29:02 ] 基地外は相手にするなよ 219 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 21:43:00 ] >>217 妄想乙 220 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 00:33:17 ] >>219 君がろくに論文も読んでないのが良く分かりました。 221 名前：デフォルトの名無しさん mailto:sage [2009/07/05(日) 14:42:00 ] このスレふつうのコンパイラをつくろうを 宣伝したやつフルボッコにするからな 222 名前：デフォルトの名無しさん mailto:sage [2009/07/05(日) 15:27:47 ] まず>>221が・・・ 223 名前：デフォルトの名無しさん mailto:sage [2009/07/05(日) 15:45:49 ] >>221 >>221 >>221 224 名前：デフォルトの名無しさん mailto:sage [2009/07/05(日) 15:59:24 ] >>221 >>221 >>221 >>221 >>221 >>221 225 名前：デフォルトの名無しさん mailto:sage [2009/07/05(日) 19:14:05 ] 著者の関係者なのか？ 226 名前：デフォルトの名無しさん mailto:sage [2009/07/05(日) 22:26:25 ] 8080でLLVM実装まだ？ 227 名前：デフォルトの名無しさん mailto:sage [2009/07/06(月) 17:28:44 ] ゼッパチでよければ 228 名前：デフォルトの名無しさん mailto:sage [2009/07/07(火) 16:05:46 ] x86用のコードを吐くCコンパイラの、64bit整数(long long)まわりを読んでいます。 addl $1,%eax adcl $0,%eax みたいな簡単なものは理解できたのですが、シフト演算や乗算・除算になると 追い方が悪いのか理解力が弱いのかさえ分からなくなってきました。 この手のことを解説したサイトって無いのでしょうか。 229 名前：デフォルトの名無しさん mailto:sage [2009/07/07(火) 17:55:56 ] >>228 たぶん自分で調べたほうが早い。 最適化をかけないデバッグビルドで、 演算させるたびに何か関数(printf)でも呼び出す形にするといいよ。 230 名前：デフォルトの名無しさん mailto:sage [2009/07/07(火) 18:16:51 ] デバッガ知らないの？gdb? 231 名前：デフォルトの名無しさん mailto:sage [2009/07/07(火) 18:21:05 ] 前提知識であるx86のアセンブリの知識はあるの? 232 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 01:09:36 ] $(GCC)/gcc/longlong.h まじお勧め 233 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 06:52:57 ] >>229 そうですか。急がば回れってことなんでしょうか。 おれ、このリーディングが終わったらまとめ書くんだ。 >>230 acid 使い方が分からないので、スタックトレースにしか使ってません。 >>231 数年前に、はじめて読む8086を流し読みした程度の知識です。 分からない命令はインテルのpdf引きながら読んでいます。 >>232 www.opensource.apple.com/source/gcc/gcc-937.2/gcc/longlong.h mullを1回で、(long)*(long)はできるのですね。おもしろい。 234 名前：デフォルトの名無しさん [2009/07/08(水) 09:10:38 ] >>230 gcc使う人はたいていデバッガ使わないでしょ。 デバッガに頼り切ってるのはVS厨が多い。 235 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 09:36:37 ] > gcc使う人はたいていデバッガ使わないでしょ。 そういう人って デバッグがデバッガに頼り切りではないという面もあるにしろ デバッガを使いこなせてないという面もあるんじゃないかな。 236 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 09:59:40 ] >>234 それは偏見。 組み込みLinux開発ではgdbくらい使いこなせないとお話になりません。 237 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 17:28:59 ] >>236 それは偏見。 組み込みLinux開発ではgdb使ってるようではお話になりません。 238 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 17:31:41 ] gdbは使いこなせるけど使ってないケースもあるわけで 239 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 17:35:33 ] printfの方が高機能なわけで 240 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 17:56:46 ] Caper良さそうなのですが字句解析(Lexar)には 何を使うのがいいでしょうか？ おすすめを教えてください。 241 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 18:34:20 ] Caper良さそうなのですが字句解析(Lexar)には 何を使うのがいいでしょうか？ おすすめを教えてください。 242 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 18:53:24 ] 手書きでOK 243 名前：デフォルトの名無しさん [2009/07/08(水) 19:48:27 ] 手書きでいいと思う 文字列→数値のパースみたいなランタイムの処理に流用しやすいし 244 名前：デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:21:38 ] 本気で速度気にするならflex出力を手修正とかがいいんじゃないか 245 名前：デフォルトの名無しさん [2009/07/09(木) 01:22:53 ] アセンブリから機械語にどうやって変換しているんですか？ 246 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 01:54:23 ] まずOPコードを暗記するんだ 相対アドレスも数をこなせば暗算できるようになる 247 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 09:40:02 ] >>245 アセンブラを使う。 gccに-vオプションつけてみな。 248 名前：デフォルトの名無しさん [2009/07/09(木) 09:50:38 ] >>241 Caperはgcc+Perlで開発されているので字句解析にはPerlを使うと馴染みやすい。 Linuxには必要なものがすべて揃っている。 249 名前：デフォルトの名無しさん [2009/07/09(木) 10:10:50 ] >>247 あなたの作っているコンパイラに対してアセンブラは自前ですか？ 250 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 10:16:58 ] 母国語でおｋ 251 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 16:11:15 ] アセンブラどころかリンカもローダも自作したが 最初は使えるものを使って、徐々に置き換えていけばいいんじゃない 252 名前：デフォルトの名無しさん mailto:sage [2009/07/21(火) 23:01:50 ] Richard Bornatのコンパイラの本でお勧めですか？ 253 名前：デフォルトの名無しさん mailto:sage [2009/07/21(火) 23:26:02 ] 日本語でおｋ 254 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 21:58:11 ] やさしいコンパイラ（デコイ本）はやめたほうがいい ふつうの方は神本確定の出来だった 255 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 00:56:59 ] やさしいコンパイラ貶して ふつうの方宣伝してる人は まったく具体的な指摘がないんだよな 256 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:09:34 ] と、ここぞとばかりに架空の傾向を持ち出すわけですね。 257 名前：デフォルトの名無しさん [2009/07/25(土) 09:32:51 ] ふつうのコンパイラ良書なんでしょうか 学生なのでちょっと資金余裕がなくて 258 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 09:38:48 ] 研究室で買ってもらえばいい。あるいは図書館。 259 名前：デフォルトの名無しさん [2009/07/26(日) 02:01:07 ] mingw-jpの使い方まったくわからないので どなたか教えてもらいたいのですが 260 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 17:17:33 ] 言語ワークベンチは究極的には完全にプログラミング方法を変えるかもしれない www.infoq.com/jp/news/2009/05/Language-Workbench 261 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 17:40:02 ] >>260 なんかスタイルシートが効いてなくて生々しいレイアウトになってない？ 262 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 17:57:19 ] >>261 今見たが、特に問題ないぞ。 263 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 11:25:26 ] >>261 うちの環境だとこうなってる IE6　ちゃんと出る FireFox　スタイルシートが効かない Google Chrome　スタイルシートが効かない上に画像も表示されない 264 名前：263 mailto:sage [2009/07/27(月) 11:30:13 ] 今見たら直ってました。 265 名前：261 mailto:sage [2009/07/27(月) 12:19:46 ] うーん。うちのFirefoxだと変わらずだな。 エラーコンソールになんか出てるけど、それが原因を示してるのかわからん... 266 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 13:05:55 ] >>265 リロードしたらＯＫになったよ、うちのFX 267 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 14:00:29 ] うちもFirefoxだと一度目はスタイルシート読み込まれないな まぁスレには関係ない話題だが 268 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 14:39:17 ] >>260 どっちかというと設計よりの話だね。 269 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 04:41:50 ] .NET周りで使えるもの、という条件だが。 ・Lexical analyzer and parser generator 単純だがよくできている。構文木を食わせてソースコードを吐かせるBison式。 最初これで作りかけていたが、パーサーを構築できてもそのパーサーが予定の挙動をしない場合、デバッグの方法が困難。 （テーブルに分解されてしまうため、ソースが追いかけられない） パーサーの動作は高速と思われる。 ・Irony パース、構文木構築までをやってくれるコンパイラを動的に構築してくれる。 簡単なGUIのパーサーチェッカーが付いていて、開発がかなり楽 （すごい楽かはもっと楽なものがあるのかどうか知らないので……） 動的に構築する分lapgより遅いかもしれないが、とりあえず自分の目的にはこれで十分なので。 ただ、コンパイル済みコードを吐かすために自分用の構文木を もう一度作り直す羽目になるのは激しくビミョー……。 （別にそのまま構文木を消化していったっていいわけだが。 　まあ少なくともテキスト形式で出力するにはあの構文木のオブジェクト構造は向いてないな） 270 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 04:55:36 ] 修正と補足。 「構文木を食わせて〜」は、「BNF定義を食わせて〜」が正しい。 lapgもIronyもどちらもEBNFではなくBNF式。（Wikipediaで調べた限りでは） ただしどちらもパースに正規表現が使える。 lapgは非Ascii文字の正規表現パースがどうも挙動が怪しい……。 Ironyはホワイトスペースの除去以外にも非構文要素を取り除けるチャンスがあるので小回りが効くようだ。 (といったところも気に入っている) 271 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 13:51:44 ] JetBrains Meta Programming System これが最強他は全て旧世代の糞技術 272 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 14:25:38 ] >>271 どんなものか説明してみれ 273 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 14:32:14 ] .NET向けの旧来のスタイルのものとしてはGPPG/GPLEXが定番 GPPGはIronRubyにも使われてる 274 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 15:05:06 ] ドラゴンブック買ってきたぞ！さあ読むぞ！ 275 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 16:48:45 ] >>273 なるほど……。 現在はMPPG/MPLEXと名前が変わってるようだけどね。 どうせいずれVisual Studioの胸を借りる（SDKを使ってオレ様IDEを作る）予定なので、 はじめからこちらで構文解析を実装しておいた方が 構文の強調、InteliSenceなどで使い回しが利くかもしれない。 結構進んでてあとはエラー周りくらいだったんだが、破棄してしまうかなぁ……。 276 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 16:55:06 ] MPPG/MPLEXはまた別物だよ(MSがVisual Studio SDK用にカスタマイズしたもの?) 本家はttp://plas.fit.qut.edu.au/gppg/Default.aspxで開発継続中でドキュメントも充実してる 277 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 17:30:29 ] >>276 HPみてみたら、GPPG is closely related to the “Managed Package Parser Generator” application って書いてるね。 今仕様を決めているスクリプトは文法がPythonに似ているので IronPythonがどうなってるか調べてみたら、こっちはパーサーを自前で書いてる……？ （ソースコード中に直接コメントでBNFが書いてある） 278 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 17:42:08 ] ともあれ、BNF定義の中に直接コード片が埋め込めるGPPG/MPPGの仕様は興味深いね。 ただそれだけに、PDFドキュメントだけじゃなくて実際に動くサンプルプロジェクトが欲しいところだなぁ。 どっかにお手ごろなのが落ちてないかな。 279 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:06:36 ] >>276のサイトにあるパッケージには電卓のサンプルが付いてる。 言語なら ttp://www.iunknown.com/2007/11/lolcode-on-dlr.html これなんか手ごろで面白い。あとは大規模だけどIronSchemeやIronRubyくらいかな。 280 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:20:30 ] >>278 > ともあれ、BNF定義の中に直接コード片が埋め込めるGPPG/MPPGの仕様は興味深いね。 >>276のサイトも見ないで聞くがyaccなんかのアクションとは違うもの？ 281 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:41:28 ] 同じです 言語定義が処理系を実装する言語に依存しないというのは，むしろ流行りの売り文句です 282 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:47:36 ] >>281 > 同じです じゃあ>>278は何が興味深いんだろうか？ > 言語定義が処理系を実装する言語に依存しないというのは，むしろ流行りの売り文句です JavaでいうとSableCC的なやつかな JavaCC+JJTree、ANTLRでもできるが 283 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:06:25 ] > GPGP is a generator for LALR(1) parsers. It accepts a > “YACC/BISON-like” input specification and produces a C# output > file. The parsers that it produces are thread-safe, with all parser > state held within the parser instance. プログラミング言語非依存でもないよ。 284 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:09:44 ] >>280,281 278だが、その点で言えば、269で挙げたLexical analyzer and parser generatorはC++/Java/C#形式で吐き出せるよ。 だがこちらとしては、実装言語の非依存性などどうでもよい。 パーサーを実装しやすい仕様になっていればそれでいいわけ。 実装しやすさという観点で言えば、BNF式ごとにコードが埋め込めるGPPGは小回りが利きそうだし、 コンパイラやエラー処理があらかじめ一通り実装された状態で使えるIronyよさげ、というわけで。 285 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:14:10 ] >>284 話の流れが見えてなくてすまないが、要は昔ながらのコンパイラ・コンパイラが 欲しくてGPPGがそうだってだけ？ 仕様が興味深いというから何か目新しいネタがあるのかと期待しちゃったんだが 286 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:16:39 ] ANTLRみたいなのって，C#にも対応してるよと謳ってるのが多いけど ランタイムの実装が糞すぎて使い物にならないのが多いんだよね 287 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:28:14 ] >>286 学者風情が作った糞ライブラリに 期待するなよｗ自作しろ 288 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:37:36 ] >>284>>286>>287 ノイズレスはやめてくれ 289 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:47:26 ] >>285 他のやつらとこのスレの趣旨的にはどうか分からないが、 オレとしては自分で仕様を決めたスクリプトを他の形式にコンパイルするのに 必要十分な環境をそろえられればいい。 GPPG(MPPG)はスレの流れからするとyaccに仕様が近いようだが、（いわゆる昔ながらのコンパイラ・コンパイラ） 別にそれにこだわりはない。 むしろIronyによる作りやすさを評価してるくらいだ。 ともあれ、構文木を作った後が大変なんだがな……。 290 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 21:50:56 ] 確かに、はじめてyaccを知ったときは大変興味深かった。 >289はGPPG？で今その感動を味わっているわけだ。 291 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 21:55:08 ] >>289 あんなバグフィックスも含めて、 ちゃんとメインテナンスされてるどうかわからんツールよく使えるな。 近況はブログにでも書いてて欲しい。 292 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 22:02:23 ] >>291 リリース版しか見てないだろ。 Subversionのリポジトリみたら今月に至るまでコミットされつづけてるぞ。 というか、作者に連絡して修正パッチを投げてさっき返事が来たところだ。 codeplexにおけるプロジェクトratingsも★5つだし、どこが気に入らないのか知らないが、 まあオレが使いこなせれば済むことだからいいや。 293 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 22:27:30 ] yaccを知らずに僕らは生まれた〜 lexを知らずに僕らは育った〜 294 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 10:06:57 ] PEG世代の歌か？ 295 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 00:01:46 ] 夏休みなんで C++でPEGかpackratのパーサ作ってみたいのですが 何を参考に作るのが面白いでしょうか？ 296 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 00:13:52 ] ポリエチレングリコール？ いやいや・・ 297 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 00:23:12 ] >>295 PEGは新しい概念で古い言語向けにはあまり実装されて無いんじゃね？ Haskell、Pythonあたりを使うことをお勧めする。 298 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 11:42:07 ] ttp://pdos.csail.mit.edu/~baford/packrat/ Packrat の総本山に、C++ 実装へのリンクがいくつかあるよね。 299 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 12:00:32 ] PEGって使いやすいの？ CFGに比べた利点・欠点とか こういうのが書きやすいとか書きづらいとかありますか。 300 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 12:29:13 ] 原理的には、バックトラックのあるトップダウンパーザの受け入れる文法そのもの なので、CFGに比べて、原理を理解してしまえば直感的。 利点とも欠点ともとれるけど、レキシカルアナライザと統合される。 ナイーブな（メモ化なし）実装だと、指数的に時間がかかり、かつ無駄が多い。 301 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 12:41:16 ] C#の処理系ってことでIronMetaを眺めてみたが、こりゃあ異次元行ってるな。 ぱっと見ただけじゃさっぱりわからんぞ……。 302 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 12:56:06 ] ? これ別にC#をパースしてるわけじゃないと思うよ yaccみたいにテキスト的に処理してるだけだろ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef