「コンパイラ・スクリプトエンジン」相談室16 (649ﾚｽ)
上下前次1-新
512: 2016/04/24(日)01:48 ID:M7ZCbRga(1) AAS
「作業の自動化スクリプト」専用のスクリプトならgradleあたりが参考に良さそうだな
ちなみに俺はantは好きだけどmavenは大嫌い
513: 2016/04/25(月)02:57 ID:ouB2BnTZ(1/2) AAS
まあ秀丸はテキスト処理に特化した
自動化スクリプトの参考にはなるかもね
あれはスクリプトっていうよりマクロだけど
514: 2016/04/25(月)10:50 ID:9hQeUDgV(1) AAS
しかし秀丸には、CやWindows APIの命令が、多数というか、
かなり含まれている感じだが。
515: 2016/04/25(月)17:05 ID:lstHaTya(1) AAS
だからなんだよって感じだが。
516: 2016/04/25(月)17:27 ID:ouB2BnTZ(2/2) AAS
そのまま車輪の再発明をしてしまうと
元の秀丸を使った方が便利だから
自作スクリプトを秀丸と差別化する必要はある
517: 2016/04/26(火)03:16 ID:r83feNEN(1) AAS
そうか。秀丸に存在しない命令を考えなければならないな。
518: 2016/04/27(水)00:31 ID:Toh8P/+A(1/2) AAS
相変わらず手書きパーサー書いてるが、できるだけ1発でパースしつつ（LR法？）
外側から順に何度も段階分けながらパースする（LL法？）なコードも混じってる…
意味解析までたどり着くまでで力尽きそうｗ
519(1): 2016/04/27(水)06:02 ID:vmi3tpS2(1) AAS
よほどの理由がないなら手書きなんかやめといた方が
Bison GLR 使ってた時は不自由さがなくてよかった
semantic predicate 機能は成熟しただろうか
520: 2016/04/27(水)07:02 ID:h/kgFFlp(1) AAS
趣味でやってるんだろ
ほっといてやれや
521: 2016/04/27(水)23:38 ID:Toh8P/+A(2/2) AAS
手書きパーサー製作も残すは四則演算＆関数呼び出しとなったが
ツリーの形状はこんな感じで良いのだろうか？
外部ﾘﾝｸ:pastebin.mozilla.org
>>519
本よむところから始めるのはしんどいのでな・・・
522: 2016/04/28(木)00:23 ID:mWNt94gr(1/2) AAS
関数呼び出しだとこれでいけそう
外部ﾘﾝｸ:pastebin.mozilla.org
小さな計算でもツリーが深くなってnew()するノードの数がもりもり増えるけど
何かもっと良い方法あったら教えてちょ
523(1): 2016/04/28(木)12:59 ID:Jc879At1(1/4) AAS
手書きパーサなら
木構造にせずに操車場アルゴリズムかその亜種でLL(1)するのも手だぞ。
文法と文をそれぞれ入力したらテーブル作ってLR(1)するクラスを作るって手もあるけど
大真面目に書いてc++で500行〜1000行くらいにはなったと思う。
524: 2016/04/28(木)14:16 ID:7cooGRk/(1) AAS
lexとyaccは、既存のものを使うべきか、自作すべきか、悩ましいね。
525: 2016/04/28(木)15:44 ID:Jc879At1(2/4) AAS
yaccは、やる気と暇があるなら
どういう文法なら曖昧性が無いか、とか、shift/reduce conflictとdangling elseとは何か、とか
いろんな事についてよく理解できるようになるって点で一度試しに書いてみる事をお勧めしたい
今までに俺が余暇でC実装した名の付いたアルゴリズムの内だとかなり難しい部類に入るけどな。
lexは文法全く固まってないなら使ったらどう？って程度じゃない？
割と簡単に使えるけど、同じくらいとは言わないものの簡単に自作できるし
ASCII範囲の文字は簡単に指定できるけどUnicodeなんかに対応する為にカスタムコードを挟むなら普通に全部組んだほうが楽な事もあるし。
526: 2016/04/28(木)15:46 ID:Jc879At1(3/4) AAS
個人的にはPEGが気になるのですよー
527: 2016/04/28(木)18:30 ID:FI1Tv7gT(1) AAS
コンパイラを作るはずがコンパイラジェネレーター作りがメインになってしまう不思議
528: 2016/04/28(木)18:36 ID:Jc879At1(4/4) AAS
そして思うのだ
コンパイラジェネレータを書くのに向いてる言語とは・・・・・・
529: 2016/04/28(木)22:17 ID:mWNt94gr(2/2) AAS
>>523
そうだな。ここだけツリーにしないで、再帰関数で直接出力すれば良さそうだ
530: 2016/04/29(金)05:30 ID:o23yQzXI(1/3) AAS
バイトコードのテキストを読み込んだら
バイトコードの1行と対の関係になる命令ノードを
行数だけ配列にして上から順に実行するイメージであってる？
なんか構文木のまま実行するのと大して変わらない気がするけど
メモリの節約とかどうなんだろう
531(2): 2016/04/29(金)10:04 ID:GdtJdaFL(1) AAS
バイトコードのテキストってのが若干意味不明だが
バイトコードならアセンブル(バイナリ化)しておかないか普通
a = b + c * d
を二分木のASTで
(st (ldptr local[0]) (add (ld local[1]) (mul (ld local[2]) (ld local[3]))))
みたいに格納して、ポインタ1つあたり64 bits、ノード構造体のサイズが24 bytesと仮定して
glibc mallocを使うことを仮定して全部で32 bytes * 7 = 224 bytesのヒープを消費する。
一方でレジスタ型VMを仮定して、簡単の為に1命令32 bits固定長とすると、例えば
ldptr r0, local[0] / ld r1, local[1] / ld r2, local[2] / ld r3, local[3] /
mul r4, r2, r3 / add r5, r1, r4 / st r0, r5
の7命令で与式が表現できるから、
配列の中身の長さが2^nに拡大されて予約される事を仮定すると4 bytes * 8 = 32 bytes
これに配列の管理領域が2ワード16 bytes、
glibc mallocを使うことを仮定すると2箇所の領域の管理で2ワード16 bytes必要で
合計で64 bytesのヒープを消費する。
ただ、配列には配列の問題点と言うかでっかい領域を再確保するのが難しい事があるから
文単位ではリストや木を、式単位では配列を使うってのがインタプリタとしては良いんじゃないかなとは思う。
532: 2016/04/29(金)13:14 ID:mG1yRheY(1) AAS
コンパイラ作りって、インタプリタよりも、10倍の労力がかかるよな。
533(1): 2016/04/29(金)15:48 ID:qwAEwLKu(1) AAS
この辺はlispやschemeで思索しながらやると楽なんだよ
534: 2016/04/29(金)17:57 ID:ZvoRtCQG(1) AAS
コード生成の方は関数型の基礎だけでもやってないとかえって遠回りに
535: 2016/04/29(金)20:10 ID:YATvpu7C(1) AAS
>>533
最終的になんで苦労してまで構文木をSchemeで生成するんだろう？っておもって結局そのままLispのMacroに化けるのである(割とマジで)
Lisperが他の言語取得者のタメにDSLを組むことはあってもLisperはLispのママ扱う方がよかったりするのよね。
536: 2016/04/29(金)21:15 ID:o23yQzXI(2/3) AAS
>>531
ありがたい。メモリが4倍くらい節約できるのね
もしかしたら構文木のまま動かした方が動的ロードで
面白いことが簡単に実現できるんじゃないかと迷ってたけど(evalとか)
パフォーマンスではバイトコードがかなり強力なのね
537: 2016/04/29(金)23:41 ID:o23yQzXI(3/3) AAS
>>531
＞バイトコードならアセンブル(バイナリ化)しておかないか普通
たしかに普通は読み込み速度的にバイナリデータが望ましいのだけど、
手さぐりで試作するからメモ帳で読み書きできるテキスト形式でやってみるんだ
538(2): 2016/04/30(土)01:17 ID:oV2mml7H(1) AAS
lispインタプリタって一番簡単な実装(pure lisp?)だと何行くらいで実装できる？
539: 2016/04/30(土)07:15 ID:wSqWni75(1/2) AAS
>>538
基本関数だけならものすごい小さいよ
Lispが生まれた時代のマシンのメモリ量なんてアドレスのビット数が16以下だし。
540: 2016/04/30(土)10:02 ID:oKKjAnDv(1) AAS
>>538
何で実装するかにも依る
swiftやrubyだと100行オーダーで書けるらしい
外部ﾘﾝｸ:xavier.hateblo.jp
C実装だと2000行くらいみたい
外部ﾘﾝｸ:github.com
541: 2016/04/30(土)16:03 ID:ASEjigO2(1) AAS
行というかWin32で20KByteコアのそこそこ速いScheme処理系はCで作ったな
何行だったかは忘れたが数千行にはなる
ライブラリやフレームワークにどこまで対応するかだと毎回思う
上下前次1-新書関写板覧索設栞歴
あと 108 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.010s