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

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

[1からを表示]
50:デフォルトの名無しさん
09/04/28 23:31:19
そういえばこんなのが出るとか

Flex & Bison - by J Levine (2009/8/31)
URLﾘﾝｸ(www.amazon.co.jp)

51:デフォルトの名無しさん
09/04/29 08:10:34
> 内容は>>46の一番下と同じなのだけど、絶版で値段が高騰しているのが問題かな。

うわわわ。絶版してたのか。

52:46=49
09/04/29 10:37:05
>>47
> yaccやbisonのサンプルを探してみても、
> 文書を解析するところまでで、
> その先を実際にどうやっているかの例がなかなか・・・。
>
> 日本語の文書！！

日本語で書かれていて意味解析以降も
全部載っているドキュメントを探してきた。

URLﾘﾝｸ(ecs.kuis.kyoto-u.ac.jp)

Flexの解説 (GNU公式ドキュメントの日本語訳) もあった。

Flex入門
URLﾘﾝｸ(ascii.asciimw.jp)

53:52の続き
09/04/29 10:41:59
読みやすいように、要点だけ説明しておこう。
まずは字句解析から。

まずはソースファイルを読み込み、字句解析にかける。
字句解析では文字列を切って、種類を表すタグを付ける。
(タグはenumなどの定数)

例えば、

int main(void) {return 0;}

ならば、字句解析の結果は
elem(INT, "int");
elem(ID, "main");
elem(PAREN_L, "(");
elem(VOID, "void");
elem(PAREN_R, ")");
elem(BRACE_L, "{");
elem(RETURN, "return");
elem(INTLITERAL, "0");
elem(SEMICOLON, ";");
elem(BRACE_R, "}");
のようになる。
(elemはC++のクラスのつもり)

引数は左がenum定数で右は文字列ね。
一行を1つの構造体 (またはクラスやタプル) に入れると便利。
(Flexだと種類と文字列を別々に取得するんだったかな?)

54:52の続き
09/04/29 10:55:29
字句解析の結果を構文解析にかける。
上の例だと、ベタに書くと以下のようになる。

Program
: INT ID PAREN_L VOID PAREN_R BRACE_L RETURN INTLITERAL SEMICOLON BRACE_R
;

「=」の右側には、どういう種類の文字列がどういう順で並んでいるかを書く。
これだと本当に上の例しか読めなくなるので、
例えばVOID型で中身の無い関数も定義できるようにすると、以下のようになる。
(「|」は「または」という意味, 複数のパターンのどれでもいい場合に使う)

Program
: INT ID PAREN_L VOID PAREN_R BRACE_L RETURN INTLITERAL SEMICOLON BRACE_R
| VOID ID PAREN_L VOID PAREN_R BRACE_L BRACE_R
;

これで、以下のコードも読めるようになった。

void main(void) {}

55:52の続き
09/04/29 10:58:05
しかし、こうやって全部のパターンを網羅していくときりが無いよね。
だから、部分的に抜きだして共通化する。
上の例だと、

Program
: ReturnType ID PAREN_L VOID PAREN_R BRACE_L Body BRACE_R
;

ReturnType
: INT
| VOID
;

Body
: // 空の場合は何も書かない
| RETURN INTLITERAL SEMICOLON
;

こんな具合に、共通でない部分を追い出してやるわけだ。
# void型なのにreturnしている関数や
# int型なのにreturnしていない関数も読めるようになったことに注意。

構文解析では、一度に完璧な定義を書こうとせずに、
少しずつ解析できるパターンを増やしていくとやりやすいと思う。

56:デフォルトの名無しさん
09/05/02 17:46:16
>>30
LLVMもbisonパーサから手書きのパーサにかえたんだっけ。
案外、手書きの方が開発しやすいのかな?

57:デフォルトの名無しさん
09/05/05 15:51:13
構文の規模や性質や、頻繁に規則をいじるかどうか、などなどによる。

58:デフォルトの名無しさん
09/05/19 01:30:41
FlashのActionScriptで自作言語を作ろうとして
URLﾘﾝｸ(www.hakkaku.net)
URLﾘﾝｸ(www.hakkaku.net)
を先日から見ているんだが、字句解析の部分がさっぱりわからん。
構文解析のkmyaccの部分は良く分かるんだが、lexにあたる部分を
手書きしているらしく、なんか自力でトークンを探して分割したり
クラスをゴリゴリ作ったりしている。正直ムリポ。

その辺に落ちてるlex/flexで代用したいんだが、どうやればいいんだろう？
もしそれがムチャなことなら、「kmlex」的なものはないだろうか？

59:デフォルトの名無しさん
09/05/19 04:26:19
このレベルがわからないんじゃ
言語なんて作るの無理

60:デフォルトの名無しさん
09/05/19 07:28:20
AS3.0以降はRegExpあるから、自作してもすぐ出来るだろ

61:デフォルトの名無しさん
09/05/19 07:50:10
RegExpで字句解析するの？

62:デフォルトの名無しさん
09/05/19 08:10:18
RegExpで字句解析しないの？

63:デフォルトの名無しさん
09/05/19 08:23:56
な・・・RegExpで字句解析しただと！？

64:デフォルトの名無しさん
09/05/19 09:11:48
パース、構文木生成、式解釈、ニーモニック生成、コード出力をやるだけだ。
慣れたらゼロからでも数日で実装できる。

65:デフォルトの名無しさん
09/05/26 01:25:57
LLVMを勉強したいです
書籍ってありますか？

66:デフォルトの名無しさん
09/05/26 02:14:25
本家のドキュメントがよい。

67:デフォルトの名無しさん
09/05/26 09:20:42
本家にkaleidoscopeっていう処理系を作りながらllvmを憶えるチュートリアルがあるよ。

68:デフォルトの名無しさん
09/05/26 23:32:34
>>61
「文字列の先頭からアルファベットに引き続く、空白までの連続部分のマッチ」に
該当すれば、それを予約語として認識し、文字列からその部分を取り除いて
再度先頭から…を繰り返しているんだろう。

>>62
getChr()で一文字づつ文字を読み込んで、「空白の次にアルファベットだから
このトークンは予約語」というアタリの付けかたをしているんだろう。

69:デフォルトの名無しさん
09/05/28 17:16:46
ドラゴンブック二版の邦訳買ってきたよ。すごい紙薄い。

70:デフォルトの名無しさん
09/05/28 18:16:41
いい紙なのかな。TAOCPみたいな？

71:デフォルトの名無しさん
09/05/29 00:45:48
バラシテスキャンしないと

72:デフォルトの名無しさん
09/05/29 22:22:08
URLﾘﾝｸ(up2.viploader.net)

バーコード邪魔

73:デフォルトの名無しさん
09/05/29 22:49:06
[これはひどい]

絵本とかでバーコードがシールになってて、買ったらはがせるのあるけど、
そうしてほしいところだな。技術書だから無理に決まってるけど。

74:デフォルトの名無しさん
09/05/29 22:53:56
なんか本当に剣と魔法の挿絵になってね？

75:デフォルトの名無しさん
09/05/29 23:01:57
楯が Syntax Directed Translation
剣が LALR Parser Generation
鎧が……読めにゃい
竜が Complexity of Compiler Design かな？

76:デフォルトの名無しさん
09/05/29 23:24:16
拡大
URLﾘﾝｸ(up2.viploader.net)

77:デフォルトの名無しさん
09/05/29 23:32:24
Data Flow Analysis か

78:デフォルトの名無しさん
09/05/30 00:32:32
コンパイラ第2版ってどこ改訂されたの？

79:デフォルトの名無しさん
09/05/30 02:55:37
全面的に

80:デフォルトの名無しさん
09/05/30 03:02:46
読みやすくなってる？

81:デフォルトの名無しさん
09/05/30 16:40:02
>>75
もう画像流れてるわ
第一版と同じで鎧は syntax directed translation じゃなかろうか

default を「省略時解釈」とか、そういうのが無くなってるといいんだが

82:デフォルトの名無しさん
09/05/30 18:24:48
> 第一版と同じで鎧は syntax directed translation じゃなかろうか
それは盾だって>>75に

> default を「省略時解釈」とか、そういうのが無くなってるといいんだが
往年の教科書では定番だったよねそういう訳

83:デフォルトの名無しさん
09/05/30 19:28:33
最近の本は「既定の…」になるの？ｗ

84:デフォルトの名無しさん
09/05/30 21:09:37
ごめん、data flow analysis だな

85:デフォルトの名無しさん
09/06/06 01:03:33
検索でここまで辿り着きました。
宜しくお願いします。

現在、オブジェクト指向のクラスの実装などが、
コンパイラでどのように実現されているのかに興味を持ち、勉強中です。

コンパイラの本も何冊か買い、簡単に目を通しましたが、
殆どが手続き型言語のコンパイラの解説で終わっており、資料の少なさに困っています。

自分で探した範囲で、オブジェクト指向型言語のクラスの実装等に触れられている本は、
『コンパイラの構成と最適化』（朝倉出版）しか見つけることが出来ませんでした。

『コンパイラ―原理・技法・ツール』の第2版版が最近出版されたようなので、
書店で立ち読みをして見ましたが、オブジェクト指向言語に関しては、
余り記述がされていないようです（短時間立ち読みをした程度なので、見落としてるだけなのかもしれませんが…）。

上で記述した以外に、オブジェクト指向言語の具体的な実装について書かれたコンパイラ等の書籍などがご存知の方がいらっしゃいましたら、本の題名等をご教示頂けると幸いです。

86:デフォルトの名無しさん
09/06/06 01:21:19
なぜそんなにオブジェクト指向にこだわるのか理由がよく分からないな。
まあ、単純にオブジェクト指向を特徴としている言語の実装が知りたいなら、
ソースコードを入手して眺めるのが一番早いだろう。
RubyやPythonなんかでどうだ？

87:デフォルトの名無しさん
09/06/06 01:24:05
>>85
gcc読んでここでその成果全部書けよ
そしたら教えてやるから

88:デフォルトの名無しさん
09/06/06 01:40:21
>>85
"Rubyソースコード完全解説"

89:デフォルトの名無しさん
09/06/06 01:43:11
『いまどきのプログラミング言語の作り方』に、ちょっとだけ載ってたかなあ

90:デフォルトの名無しさん
09/06/06 03:16:32
>>86
OOPにこだわる切欠は、自分で作ったCのプログラムを逆アセンブルして、アセンブリ言語の勉強をしていた時、JavaなどのOOP言語では、どのようにソースコードがバイトコードなどに置き換えられ、クラス等がどの様に実装されているのかに興味を惹かれたためです。

PythonやRudyに関しては、恥ずかしながら名前しか知りませんでした。
ソースコードもダウンロードしてみました。
再度の質問になり恐縮ですが、これはコンパイラのソースコードではないかと考えていますが、その様な理解で良いのでしょうか？
どちらにせよ、自分の勉強不足は明らかなので御指摘を元に、勉強してみます。
アドバイスをありがとう御座います。

>>87
まだ勉強を始めたばかりで、恥ずかしながらgccについては、知りませんでした。
gccについて、これから勉強してみたいと思います。

>>88
検索して見つけることが出来ました。
Amazonで買おうかとも思いましたが、プレミアが付いているようで、とても高いですね。

Webで本文が見られるみたいなので、それを見させていただきます。

ご教示ありがとうございます。

>>89

Amazonでも今は取り扱っていないようですね。
評判の良い本のようなので、購入を検討してみます。

ありがとうございました

91:デフォルトの名無しさん
09/06/06 03:31:26
>>90
RubyやPythonは、オブジェクト指向のスクリプト言語だ。
現代のスクリプト言語はいったんバイトコードにコンパイルされてから実行される形式が一般的で、
従ってコンパイラと呼びうるすべての要素がソースコード内に含まれている。

そしてそこから先（バイトコードをどのように動かすかの仮想マシンの実装）もあるわけだ。
いい教材になるわけで。

92:90
09/06/06 10:21:50
>>91

そうなんですか。
その事については、知りませんでした。
コンパイラの動作をソースコードを読むことで確認出来るというのは、
私のように学習を目的としている者にはありがたい話です。

Rudyは書籍やWebでの資料が充実しているようなので、これから調べてみます。

ご教示、ありがとう御座いました。

93:デフォルトの名無しさん
09/06/06 11:25:22
>>92
Rubyソースコード完全解説という神書籍があってだな、絶版だが、初版が無料公開されているのでオススメ

Rubyソースコード完全解説
URLﾘﾝｸ(i.loveruby.net)

94:デフォルトの名無しさん
09/06/07 19:53:04
>>90
参考までに、Javaのバイトコード仕様はSunのサイトで閲覧できる (英語)。
SunのJDKに付属しているjavapとかで逆アセンブルできるよ。
他にEclipse用のプラグイン「Bytecode Outline plugin for Eclipse」とかでも。
Eclipse用だと「Classfile Inspector」（有料 99Euro)ってのもあったけど、いまググったら
サイトが消滅したようだ。

95:デフォルトの名無しさん
09/06/08 07:45:39
速攻MinCamlコンパイラ概説

URLﾘﾝｸ(min-caml.sourceforge.net)

96:デフォルトの名無しさん
09/06/08 10:54:28
>>85
英語は読めますか?

97:デフォルトの名無しさん
09/06/08 11:07:20
あんまり道を示しすぎてもパンクすると思うんだが。
85とは関係なしに紹介したいサイトがあるなら、俺が消化するから構わず続けてくれ。

98:デフォルトの名無しさん
09/06/08 11:54:40
URLﾘﾝｸ(www.amazon.com)
URLﾘﾝｸ(www.amazon.com)
この辺りの概説書にはOOの実装のこと"も"解説してる。
URLﾘﾝｸ(www.amazon.com)
はOO関連のコンセプトの整理がうまい。実装についても書いてある。

全般的な概説書はやはり記述がプアになるので、C++に限れば一番詳しいのは、訳書の
URLﾘﾝｸ(www.amazon.co.jp)
これだけど、今は絶版なので、
URLﾘﾝｸ(www.amazon.com)
原書を読めばいい。
ARM(注解 C++リファレンスマニュアル)も詳しく説明している。これも絶版なので、
URLﾘﾝｸ(www.amazon.com)

Objectのslot accessでC++と全く異なるアプローチで有名なのが、
URLﾘﾝｸ(code.google.com)
Selfの元の論文が、
URLﾘﾝｸ(research.sun.com)
にある。JITと相性がよい。

もちろんaccessが遅くていいなら他にも幾らでもやりかたはある。
Objective-Cなんかはhash引いている。

99:デフォルトの名無しさん
09/06/08 13:07:35
普段はレキサ・パーサレベルの話しか出ないのに、堰を切ったようにいろいろ出てくるな
実はみんな、教えることに飢えてたのか？

100:デフォルトの名無しさん
09/06/08 19:40:03
lexerかparserより先に進んだ質問者がなかなかいないからじゃないかな

101:デフォルトの名無しさん
09/06/08 23:19:24
じゃあ俺がお前らの意見を聞いて
万人が理解できるlexerとparserの
サンプル書いてやる

ということでまず何をすればいいぉ？

102:デフォルトの名無しさん
09/06/09 00:00:12
文法決めれ

103:デフォルトの名無しさん
09/06/09 00:09:06
>>101
かっこに対応した四則演算とかどうだ

104:デフォルトの名無しさん
09/06/09 19:58:23
四則演算はネット上にゴロゴロしてるからイラネ

105:デフォルトの名無しさん
09/06/09 20:18:37
forループとif-else-endifの構文サンプル

106:90
09/06/09 22:05:49
>>93

教えて頂いて、ありがとう御座います。
絶版の資料が無料で公開されているのは、ありがたいですね。

>>94

Javaのバイトコードにも、興味があります。
Java仮想マシン仕様は、日本語の書籍でも出版されているので、今度読むつもりでした。
仮想マシンの概念は、コンピュータのアーキテクチャとも密接に関わってくる事項なので、興味深いですね。

>>96

正直、英語はまともには読めません。
日本語の資料で勉強するのに限界を感じているので、
英語の勉強をやり直そうと思ってます。

>>98

今まで知らなかった資料が多いので、参考になります。
英語の資料が多いですね。
コンパイラの勉強の前に、英語をやり直して、
資料をまともに読めるようになってから、勉強をし直すべきかもしれません。

コンパイラの勉強は、思っていたよりもしんどそうですが、
今まで知らなかった資料を紹介していただいたので、今後の勉強の指針が見えた気がします。
教えていただいた資料を参考に、頑張ってみます。

107:デフォルトの名無しさん
09/06/09 22:28:05
>>105
それだッッッ
ブロックの扱いがどうやればいいのか
悩みまくっている俺にはおいしいです ^q＾
^

108:デフォルトの名無しさん
09/06/09 22:57:09
>>101 lexer parser 何てどうとでもなるから
cps とか ssa あたりの内部表現の評価手法を,
最適化方法に合わせた一覧として提示してくれ

109:デフォルトの名無しさん
09/06/10 00:05:45
>>108
どうとでもならない人のための相談室スレだと思うんだ。
だから、出来る人は我慢して、ここはレベルを下げて欲しいんだ。

110:デフォルトの名無しさん
09/06/10 00:11:32
平行すりゃいいじゃん
誰か一人のためのスレってわけでもないんだし。

111:デフォルトの名無しさん
09/06/10 00:32:56
>>108
オレは専門家じゃないのでCPSもSSAもどちらの用語も知らなかったが、
これってLLVMで全部実装されてるんじゃね？
やはりLLVMの包括的な解説記事が欲しいところだな。

112:デフォルトの名無しさん
09/06/10 00:43:18
>>107
Pascalのone pass compiler読め。
URLﾘﾝｸ(homepages.cwi.nl)

113:デフォルトの名無しさん
09/06/10 01:19:43
>>111
LLVMは既に提出されているものをうまくつなぎ合わせてるだけ
つなぎ合わせ方法はいくらでもある
各要素項目を網羅的に解説したものがほしい

つか、現場にいるとそっち系をゆっくり、みてる暇がない

114:デフォルトの名無しさん
09/06/10 01:43:17
>>113
実務者としては、実装されてない方法より
既に実装されているものの解説のほうが遥かに役に立つ。

>各要素項目を網羅的に解説したものがほしい
この分野に詳しくないので外野の意見だが、それなら洋書を漁って読めばいいんじゃね？

115:デフォルトの名無しさん
09/06/10 01:45:38
>>108
Tiger Bookや"Practical Improvements to the Construction
and Destruction of Static Single Assignment Form."は読んだの？

116:デフォルトの名無しさん
09/06/10 01:48:23
>>114
> 実務者としては、実装されてない方法より
> 既に実装されているものの解説のほうが遥かに役に立つ。

ぶっちゃけここで質問している人が、
現実に使われているコンパイラのソースを参考にして、
自分のコードに反映させるのは難しいと思う。
そのくらいコンパイラは複雑化している。

さらに学習用のコンパイラは関数型言語で書かれているものが多く、
実務指向の人とは相容れないものがあるだろう。

謙虚な気持ちで学習するのが一番。

117:デフォルトの名無しさん
09/06/10 02:21:44
>>114
> 実務者としては、実装されてない方法より
> 既に実装されているものの解説のほうが遥かに役に立つ。

要素手法が見えにくいんだよね。まとまってしまうと。
ましてや、cps とか ssa 使った状態での複合リダクションとなると。

> この分野に詳しくないので外野の意見だが、それなら洋書を漁って読めばいいんじゃね？
そりゃたくさん持ってるさ
ただ、現場をかかえてるとそっちばっかやってるわけに行かなくなるんだよな

>>116
> さらに学習用のコンパイラは関数型言語で書かれているものが多く、
> 実務指向の人とは相容れないものがあるだろう。

それは気にならないんだけど、細切れの論文掻き集めて整理やり直す時間はとれねぇよ

118:デフォルトの名無しさん
09/06/10 11:16:43
実務指向でコンパイラを今時つくりたい、なんて人はいないと思う
スクリプトでDSLをさっくり組むならともかく

119:デフォルトの名無しさん
09/06/13 19:19:12
>>90
URLﾘﾝｸ(www.amazon.co.jp)コンパイラとバーチャルマシン-Text-今城-哲二/dp/4274133087
↑この本に、オブジェクト指向も例外処理も分かりやすく載ってるよ。
薄くてすぐに読めるし、お薦め。
ただ、日本語で概要が載っているだけなので、
実装するには自分で知恵を絞らないとだけど。

現代的なコンパイラは、内部で何度も変換を繰り返して、
最終的に実行可能なコードをはく。
オブジェクト指向の場合は、最初の方で非オブジェクト指向の
Cみたいなコード (AST) に変換してしまうと、
後はよく書籍に載っているような方法が使えていいと思う。

コンパイラを全部 (シンタックスシュガーの除去から
アセンブラの出力まで) 自作するのは、大規模過ぎて現実的じゃない。
だから、自分が関心を持っている部分以外は
なるべく既存のものを利用するといいと思う。

例えばCのコードを書きだすコンパイラを書けば、
アセンブラごとにジェネレータを自分で書かなくても
多くの環境で動くし、最適化もCコンパイラに頼める。
例外処理などはCでは実装しにくいので、
必要ならLLVM IRを出力するという方法もあるよ。

120:デフォルトの名無しさん
09/06/13 19:25:19
>>118
「実務」の中身によるんじゃないかな?

121:119
09/06/13 19:32:59
以前、Javaバイトコードに変換するコンパイラも書いたことがあるけど、
Javaだと「.class」ファイルはクラス単位でオブジェクト指向になっていて、
オブジェクト指向「からの」変換はJVMが担当している。
だから、バイトコードの仕様を読んでも、あまり参考にはならないと思う。

同じ理由で、JVMをターゲットにした (「.class」ファイルを生成する)
コンパイラも皆、参考にならないと思う。

122:デフォルトの名無しさん
09/06/13 20:10:29
リンゴの本見ればコンパイラなんて3日で書けるだろ

123:デフォルトの名無しさん
09/06/15 10:39:22
>>121
最近はclassファイルを扱うためのライブラリがたくさんあるよ。

124:デフォルトの名無しさん
09/06/15 11:15:34
>>121 が言ってるのは、Java のオブジェクト指向的な面
（動的バインディングとか）が実現されてるのは、Java VM自体
なので（invokevirtual命令とか）、オブジェクト指向言語を
ふつうのCPU上で実現するコンパイラの参考にはならん、と
いうこと。

125:デフォルトの名無しさん
09/06/16 21:52:36
ドラゴンブック超える神本の出版が確定！

プログラミング言語を作る
プログラミング言語を作るなんて究極の楽しみだ!

126:デフォルトの名無しさん
09/06/17 09:50:36
>>125
著者の「プログラミング言語を作る」のサイトはぐだぐだ進行な上に
今ブログをチェックしてみたら最新エントリがエロゲの話で
しかもトンデモ理論だったので失笑せざるを得なかった

立ち読みはしてみるつもりだけど、はずれじゃないかなぁ

127:デフォルトの名無しさん
09/06/17 10:18:52
前橋さんが言語本出すのか。
まあ、変なものにはならないでしょ。

128:デフォルトの名無しさん
09/06/17 18:57:40
>>125
作者乙

129:デフォルトの名無しさん
09/06/17 20:24:01
>>128
あの人の作る言語は神レベルの美しさだぞ
お前こそ何言ってるんだｗ？

130:デフォルトの名無しさん
09/06/17 20:26:33
>>１29
どの人？？

131:デフォルトの名無しさん
09/06/18 08:43:47
>>125 >>129 は信者だろうな。

ポインタ本とか、Java謎本とか、結構悪くなかったと思うけど、今回もそういう
他に類例のないところを押さえる趣向かねぇ。

ドラゴンブックに代わる、なんてことはないないw

132:デフォルトの名無しさん
09/06/18 09:01:10
>ドラゴンブックに代わる、なんてことはないないw
学術書と実用系趣味本を一緒にすること自体おかしいよね

133:デフォルトの名無しさん
09/06/18 09:59:07
ドラゴンブック買ったけど、全然役に立たなかった。オナニー書籍
りんご本のほうがよほど役に立ったわ

というくらい

134:デフォルトの名無しさん
09/06/18 10:21:41
>>133
具体的に書かれてないと、単に難しいことが理解できなかった可哀想な趣味グラマにしか見えないな

135:デフォルトの名無しさん
09/06/18 10:50:14
ドラゴンブック喧嘩せず

136:デフォルトの名無しさん
09/06/18 12:07:40
ドラゴンブックは、
字句解析、構文解析はツールを使うから詳しくなる気はないし、
構文解析向けの言語理論にも興味ないって人にはまったく不向き。
構文解析ツール作ってみたいなって人、
計算機科学科の学生には今でもいい本の一つ。

137:デフォルトの名無しさん
09/06/18 14:08:10
そこから先のバックエンドについても、高度な話の基本になるところを
押さえてあるからね。

138:デフォルトの名無しさん
09/06/18 16:24:11
>>136
「内容に興味のない人には不向き」っていうことですねわかります

139:デフォルトの名無しさん
09/06/18 16:44:12
>>138
当たり前の事ではないか

140:デフォルトの名無しさん
09/06/18 17:41:11
特定書籍の信者って面白いね。
反撃が全部「ぼくは君をこういうキャラに設定したぞ。どうだ悔しいだろう」だし。

141:デフォルトの名無しさん
09/06/18 17:45:52
>>140
具体的に書かれてないと、単に難しいことが理解できなかった可哀想な趣味グラマにしか見えないな

142:デフォルトの名無しさん
09/06/18 20:23:54
>>140
構文が曖昧です。君からキャラへの変換は明示的なキャストが必要です。

143:デフォルトの名無しさん
09/06/18 22:43:48
coinsの利用についてはどうよ?

COINSコンパイラ・インフラストラクチャ
URLﾘﾝｸ(www.coins-project.org)

144:デフォルトの名無しさん
09/06/18 22:52:47
coinsは最凶最悪

145:デフォルトの名無しさん
09/06/19 00:01:52
>>139
いやだから、内容に興味があるのは”前提”として、
その人たちにとって良い本かを議論しないと意味ないじゃんという話
まぁ全体的にいい本っていう論調だし俺も同意するが

146:デフォルトの名無しさん
09/06/19 00:06:19
まずドラゴンブック読めない奴はゴミ
これ世界の常識あるね

147:デフォルトの名無しさん
09/06/19 06:51:19
このスレで勧められ板から、ドラゴンブックせっかく奮発して買ったのに、
いきなりしょっぱなからはじめから変な数式ばっかでいやになった…。

論文とかたまに見るけど、どうして人にわかるように書かないんだろうか？
大学行ってたら、小学生でもわかるように、って習わなかったんだろうか？

148:デフォルトの名無しさん
09/06/19 07:24:21
小学生でもわかるように書くと厚さと著作にかかる時間とが値段が10倍になりますがよろしいか。

149:デフォルトの名無しさん
09/06/19 07:26:33
>>147
え？あの程度の数式読めないの？
何それこわい

150:デフォルトの名無しさん
09/06/19 07:28:12
10倍じゃ全然きかないか

151:デフォルトの名無しさん
09/06/19 07:36:55
>>147
貴様は人間の屑だ

152:デフォルトの名無しさん
09/06/19 08:23:43
>>147
ただ単に読むのが早すぎただけでしょ。積読して、適正になったらまた読む

153:デフォルトの名無しさん
09/06/19 10:09:04
小学生でもわかるように、ってのは無理。

大学の教科書で、小学生でもわかるように書いてあるものなど皆無です。

高校生で奮発して読もうと思っているなら、学校の先生にでも相談しなさい。
多分集合の記号とか論理式とかでつまづいてるんじゃないかと思うんだけど。

154:デフォルトの名無しさん
09/06/19 23:36:05
先に簡単なの何冊か読めばいいのに

155:デフォルトの名無しさん
09/06/20 00:00:30
ドラゴンブックが一番簡単
これも読めないゆとりは来るな

156:デフォルトの名無しさん
09/06/20 00:07:00
ドラゴンブック読まなくてもコンパイラ作れるけどね

157:デフォルトの名無しさん
09/06/20 00:13:25
読まないと読めないは違う

158:デフォルトの名無しさん
09/06/23 16:33:02
数年前、文系の見方で書いたとかいうコンパイラの本ってあったよね
日本のコンパイラの第一人者が監修になってたから、わりと買った人多い？
たとえ話がぜんぜん例えになってなくて大混乱
巻末のJavaで書いたコンパイラのプログラムはほとんどCからの丸写しみたいなつくりだった。

159:デフォルトの名無しさん
09/06/23 16:38:45
上のほうですでに出てたかｗ

160:デフォルトの名無しさん
09/06/23 17:15:05
むしろ、ドラゴンブックは、それさえ読めれば、相当なコンパイラが書ける本だろ。
確かLSI-Cの作者がそう言ってたと中村正三郎か誰かが書いていた記憶がある。

161:デフォルトの名無しさん
09/06/23 17:27:01
コンパイラを書けるくらいの人なら読める

162:デフォルトの名無しさん
09/06/23 17:45:10
>>160
「ドラゴンブックを読めば誰でもLSI-Cぐらいのコンパイラは書ける」だなｗ

163:デフォルトの名無しさん
09/06/23 19:39:56
LSI-Cのひとはyacc互換のコンパイラコンパイラも作っていましたよね。
「ドラゴンブック読めば誰でもコンパイラコンパイラは書ける」なの？

164:デフォルトの名無しさん
09/06/23 19:57:12
スクリプトエンジンプログラミング　買ってきた。半分くらい読んだとこ。

なんか書いてみたいなレベルの自分にとっては、ぴったりのイメージ
なんだが、この本あんまり話題に上らないね・・・

C++出来ない自分にゃ読み替えるのが大変w

javaVM向けの中間言語を吐くやつのサンプルとかがあると、最高
だったんだけど。

165:デフォルトの名無しさん
09/06/23 20:40:34
>>162
LSI-Cは1980年代始めから中頃までが全盛期だと思うが、
当時最高の最適化を行なう最強コンパイラですよ。
作者はデータフロー解析、レジスタカラーリングは、
原論文をバリバリ読んでいた人だと思う。
かなりの腕前の人。

166:デフォルトの名無しさん
09/06/23 21:33:02
>>165
いやいや、>>162は作者がそう言ったので
中村正三郎か誰かがしょんぼり、という話ｗ

167:デフォルトの名無しさん
09/06/23 22:14:46
>>164
ちょっと薄い本だけど、日立の人が書いた、Javaのバイトコード
を吐くコンパイラがサンプルで載ってる本あったね。

って調べたらあった↓
URLﾘﾝｸ(www.amazon.co.jp)

168:デフォルトの名無しさん
09/06/23 23:13:16
>>167
著者の最初に名前上がってる人、コボラーだね。

169:デフォルトの名無しさん
09/06/23 23:15:27
まじかよｗ
興味あったけど買うのよしたｗ

170:デフォルトの名無しさん
09/06/23 23:19:24
作者じゃないが。最近発売された「プログラミング言語を作る」がインタープリタ
もバイトコードコンパイラのソースも載ってるぞ。買って読んでないから内容は
知らんが。

171:デフォルトの名無しさん
09/06/23 23:20:09
MiniCamlで良いじゃん。

172:デフォルトの名無しさん
09/06/24 00:34:54
スレ住人に聞くけどJIT関係の最適化に関するプロファイリングネタはここでいいのかな？

173:デフォルトの名無しさん
09/06/24 04:30:55
さっきJavaで書かれた独自形式の中間言語を出力する
コンパイラが欲しいと書いてる人がいたが、
よくよく考えてみると、.NETやJavaなどのそれ自体が
中間言語でかかれててJITコンパイラまで付いてる環境では、
下手に独自で作るよりもその環境の中間言語を出力してしまう、
要するにコンパイラそのものを作ってしまったほうが簡単なんだよな。
中間言語の書式や(基本的に)仮想マシンの仕様を考えなくて済む。

だからJavaにおけるGroovy、.NETにおけるIronPythonなど、
中身はインタプリタというよりもコンパイラそのものだ。

174:デフォルトの名無しさん
09/06/24 05:51:31
そこでLLVMやCOINSが出てくるわけだ。

175:デフォルトの名無しさん
09/06/24 07:32:42
プログラミング言語を作るは神本
ドラゴンブック不要といわれる理由がよくわかる
読んでみろ

176:デフォルトの名無しさん
09/06/24 07:41:40
はい。

177:デフォルトの名無しさん
09/06/24 08:03:25
はいじゃないが。

178:デフォルトの名無しさん
09/06/24 10:29:52
>>170,175
信者か作者かしらんがいい加減うざい

179:デフォルトの名無しさん
09/06/24 11:43:34
そう思わせるのが目的のアンチかもよ

180:デフォルトの名無しさん
09/06/24 22:29:32
プログラミング言語を作る
買って読んでみたぞ

普通の本だろこれ
金返せよ

181:デフォルトの名無しさん
09/06/24 22:40:43
え？俺の本からは神様が出てきたぞ？正に神本だと思ったｗ

182:デフォルトの名無しさん
09/06/24 23:16:58
>>181
作者乙

183:デフォルトの名無しさん
09/06/24 23:20:30
間違えた、紙だったｗ

>>182
偽エスパー乙

184:デフォルトの名無しさん
09/06/24 23:25:07
無理に面白いこと言おうとしなくてもいいよ

185:デフォルトの名無しさん
09/06/25 07:31:29
ドラゴンブック持ってないのに
コンパイラの本書いてるやついるけど
あいつは何なの？

186:デフォルトの名無しさん
09/06/25 07:35:37
分かりません。

187:デフォルトの名無しさん
09/06/25 14:13:43
>>169
いや、コボラーはコボラーでもIBMの奴隷って意味のコボラーじゃないからw

188:デフォルトの名無しさん
09/06/27 23:40:48
>>160
確か、LSI-Cの作者がそれしか読んでないとかいってただけだと思う。
万人に当てはまるわけではない　と

189:デフォルトの名無しさん
09/06/28 00:30:24
大昔の話じゃいろいろ説明をつけないと通じないんだなあ……
というかその大昔の時点で意味わかってなかったのか？

LSI-Cの最適化は凄いとよく言われたが
詰めが甘くて実際には骨折り損だという話もあったよ
コンパイル時間はMS-Cの倍だったしね

190:デフォルトの名無しさん
09/06/28 01:40:22
>>189
8080版の最適化の話だろすごかったの

191:デフォルトの名無しさん
09/06/28 07:18:31
LSI-C(笑)

192:デフォルトの名無しさん
09/06/28 07:19:14
4004（笑）

193:デフォルトの名無しさん
09/06/28 09:20:58
>>189
知りもしないことをよくもまあ

194:デフォルトの名無しさん
09/06/28 11:56:45
知ってる人だけ。。。
MSX-Cは変数が自動でレジスタに割り当てられるんだけど、
そうなるとポインタを介したアクセスと一貫性がなくなる。

195:デフォルトの名無しさん
09/06/28 12:01:02
MSX-C ＝ LSI-C

196:デフォルトの名無しさん
09/06/28 21:23:22
>>194
変数のポインタを取り出せばメモリ上に確保しなおしてたよ
それともループ内に持ち込んだ変数を割り込み処理で外部から変更した時に関与が出ないって意味で言ってる？

197:デフォルトの名無しさん
09/06/28 21:59:34
#include <stdio.h>
#pragma nonrec

main()
{
　　　　int n;
　　　　int *p;

　　　　p = &n;
　　　　n = 10;
　　　　*p = 100;
　　　　printf("n = %d\n", n);
}

MSX-C のマニュアルに載ってたサンプル。
これで「n = 10」と表示されるそうな。

198:デフォルトの名無しさん
09/06/28 23:10:50
なんじゃこりゃ。
これが仕様なの？

199:デフォルトの名無しさん
09/06/28 23:30:24
往年の8ビットマイコン用Cコンパイラの#pragmaか
コード書く人もコンパイラの振る舞いにあわせて組んでたんだね

200:デフォルトの名無しさん
09/06/28 23:40:43
逆だろ。
pragmaはコンパイルの動作を指定するためにある。

201:デフォルトの名無しさん
09/06/29 00:14:16
MSX-CでC言語を勉強したんだけど、これによくはまった。
レジスタに割り当てないこともできるけど。
#pragma nonrecはローカル変数をstaticがついているかのようにする。
non-recursiveの略。CPUの制限でスタック上の変数にアクセスするのが
遅いからです。コードの再利用のことを考えてのことだと思う。
あとMSX-Cはlongと浮動小数点数がないんです。
#ifもない。if文で代用とマニュアルにありました。実行されないコードは
生成されない。
なにかの役に立つかな？

202:デフォルトの名無しさん
09/06/29 00:17:14
#pragma有効で組むか
さもなくば死か
この時代にCを開発用途に使えたという時点である意味幸運だったとも言える

203:デフォルトの名無しさん
09/06/29 12:13:13
8080でのスタックフレームってめんどくさいよな

204:デフォルトの名無しさん
09/06/29 23:59:31
高級言語を意識して設計されてないから仕方ない
Z80だとIX/IYで強引にやるのか？汎用/裏レジスタで最適化とかしてたら凄いが

205:デフォルトの名無しさん
09/06/30 00:51:28
IX/IYは人間向きのレジスタで、
便利ではあるけど遅いからコンパイラは使わない。
(HD64180あたりになると結構速かったが)
LSI-C(MSX-C)はもちろん裏レジスタ使いまくり。

206:デフォルトの名無しさん
09/06/30 22:30:31
むかし見たLSI-C80の広告ではIXかIYをフレームポインタに使っていた
コードが掲載されていた。
MSX-Cは裏レジスタ,IX,IYを使うコードは生成しなかったと思う。
付属のライブラリでは使っているかもしれませんが。
スタック上のローカル変数アクセスの方法はどうだったか記憶にありません。
MSX-Cのアセンブリ言語出力をZ80に最適化するプログラムを書いた人もいるようです。
僕も出力を見ていたときすこし考えたことありました。
アセンブリ言語レベルで8080から8086に変換するプログラムの存在を古い本で読んだのも思い出しました。

207:デフォルトの名無しさん
09/06/30 23:41:00
コンパイラが将来性のない
回顧主義者おっさんのたまり場であることがよくわかる

だから日本は研究でも実業でもこの分野でチョン以下になる。

208:デフォルトの名無しさん
09/06/30 23:51:29
>>207
そんな愚にも付かないことを言ってるヒマがあったら、
LLVM向けに何かメジャーな言語を移植するのだ。

209:デフォルトの名無しさん
09/07/01 00:01:25
LLVMは糞だろ

210:デフォルトの名無しさん
09/07/01 00:22:10
>>209
どこがどう糞なの？

211:デフォルトの名無しさん
09/07/01 23:55:53
>>210
Milepost GCCがあるから不要
自分でコードをチューニングするという古臭い時代は終わったの
自動的に学習して最適なコードを出力してくれるからLLVM自体不要なの

212:デフォルトの名無しさん
09/07/02 00:01:16
幼稚園児かｗ

213:デフォルトの名無しさん
09/07/02 00:15:27
>>211
というか、同じようなアイデアのllvm-gccのほうが有名なわけだが？

214:デフォルトの名無しさん
09/07/02 00:20:21
>>211
完全自動化だし、今年後半のコンパイラ関係の
賞総なめにするって言われてるけどねぇ
EUレベルの国家プロジェクトと田舎大学の糞プロジェクト
比較されてもねぇ

215:デフォルトの名無しさん
09/07/02 00:23:40
幼稚園児だな

216:デフォルトの名無しさん
09/07/03 07:15:50
ヒント：実績

217:デフォルトの名無しさん
09/07/03 17:26:47
Milepost GCCのICIな人たちが次はLLVMでやってみるって言ってんですがねえ…

218:デフォルトの名無しさん
09/07/03 18:29:02
基地外は相手にするなよ

219:デフォルトの名無しさん
09/07/03 21:43:00
>>217
妄想乙

220:デフォルトの名無しさん
09/07/04 00:33:17
>>219
君がろくに論文も読んでないのが良く分かりました。

221:デフォルトの名無しさん
09/07/05 14:42:00
このスレふつうのコンパイラをつくろうを
宣伝したやつフルボッコにするからな

222:デフォルトの名無しさん
09/07/05 15:27:47
まず>>221が・・・

223:デフォルトの名無しさん
09/07/05 15:45:49
>>221
>>221
>>221

224:デフォルトの名無しさん
09/07/05 15:59:24
>>221
>>221
>>221
>>221
>>221
>>221

225:デフォルトの名無しさん
09/07/05 19:14:05
著者の関係者なのか？

226:デフォルトの名無しさん
09/07/05 22:26:25
8080でLLVM実装まだ？

227:デフォルトの名無しさん
09/07/06 17:28:44
ゼッパチでよければ

228:デフォルトの名無しさん
09/07/07 16:05:46
x86用のコードを吐くCコンパイラの、64bit整数(long long)まわりを読んでいます。

addl $1,%eax
adcl $0,%eax

みたいな簡単なものは理解できたのですが、シフト演算や乗算・除算になると
追い方が悪いのか理解力が弱いのかさえ分からなくなってきました。
この手のことを解説したサイトって無いのでしょうか。

229:デフォルトの名無しさん
09/07/07 17:55:56
>>228
たぶん自分で調べたほうが早い。

最適化をかけないデバッグビルドで、
演算させるたびに何か関数(printf)でも呼び出す形にするといいよ。

230:デフォルトの名無しさん
09/07/07 18:16:51
デバッガ知らないの？gdb?

231:デフォルトの名無しさん
09/07/07 18:21:05
前提知識であるx86のアセンブリの知識はあるの?

232:デフォルトの名無しさん
09/07/08 01:09:36
$(GCC)/gcc/longlong.h
まじお勧め

233:デフォルトの名無しさん
09/07/08 06:52:57
>>229
そうですか。急がば回れってことなんでしょうか。
おれ、このリーディングが終わったらまとめ書くんだ。

>>230
acid
使い方が分からないので、スタックトレースにしか使ってません。

>>231
数年前に、はじめて読む8086を流し読みした程度の知識です。
分からない命令はインテルのpdf引きながら読んでいます。

>>232
URLﾘﾝｸ(www.opensource.apple.com)
mullを1回で、(long)*(long)はできるのですね。おもしろい。

234:デフォルトの名無しさん
09/07/08 09:10:38
>>230
gcc使う人はたいていデバッガ使わないでしょ。
デバッガに頼り切ってるのはVS厨が多い。

235:デフォルトの名無しさん
09/07/08 09:36:37
> gcc使う人はたいていデバッガ使わないでしょ。
そういう人って
デバッグがデバッガに頼り切りではないという面もあるにしろ
デバッガを使いこなせてないという面もあるんじゃないかな。

236:デフォルトの名無しさん
09/07/08 09:59:40
>>234
それは偏見。
組み込みLinux開発ではgdbくらい使いこなせないとお話になりません。

237:デフォルトの名無しさん
09/07/08 17:28:59
>>236
それは偏見。
組み込みLinux開発ではgdb使ってるようではお話になりません。

238:デフォルトの名無しさん
09/07/08 17:31:41
gdbは使いこなせるけど使ってないケースもあるわけで

239:デフォルトの名無しさん
09/07/08 17:35:33
printfの方が高機能なわけで

240:デフォルトの名無しさん
09/07/08 17:56:46
Caper良さそうなのですが字句解析(Lexar)には
何を使うのがいいでしょうか？
おすすめを教えてください。

241:デフォルトの名無しさん
09/07/08 18:34:20
Caper良さそうなのですが字句解析(Lexar)には
何を使うのがいいでしょうか？
おすすめを教えてください。

242:デフォルトの名無しさん
09/07/08 18:53:24
手書きでOK

243:デフォルトの名無しさん
09/07/08 19:48:27
手書きでいいと思う
文字列→数値のパースみたいなランタイムの処理に流用しやすいし

244:デフォルトの名無しさん
09/07/08 23:21:38
本気で速度気にするならflex出力を手修正とかがいいんじゃないか

245:デフォルトの名無しさん
09/07/09 01:22:53
アセンブリから機械語にどうやって変換しているんですか？

246:デフォルトの名無しさん
09/07/09 01:54:23
まずOPコードを暗記するんだ
相対アドレスも数をこなせば暗算できるようになる

247:デフォルトの名無しさん
09/07/09 09:40:02
>>245
アセンブラを使う。
gccに-vオプションつけてみな。

248:デフォルトの名無しさん
09/07/09 09:50:38
>>241
Caperはgcc+Perlで開発されているので字句解析にはPerlを使うと馴染みやすい。
Linuxには必要なものがすべて揃っている。

249:デフォルトの名無しさん
09/07/09 10:10:50
>>247
あなたの作っているコンパイラに対してアセンブラは自前ですか？

250:デフォルトの名無しさん
09/07/09 10:16:58
母国語でおｋ

251:デフォルトの名無しさん
09/07/09 16:11:15
アセンブラどころかリンカもローダも自作したが
最初は使えるものを使って、徐々に置き換えていけばいいんじゃない

252:デフォルトの名無しさん
09/07/21 23:01:50
Richard Bornatのコンパイラの本でお勧めですか？

253:デフォルトの名無しさん
09/07/21 23:26:02
日本語でおｋ

254:デフォルトの名無しさん
09/07/24 21:58:11
やさしいコンパイラ（デコイ本）はやめたほうがいい
ふつうの方は神本確定の出来だった

255:デフォルトの名無しさん
09/07/25 00:56:59
やさしいコンパイラ貶して
ふつうの方宣伝してる人は
まったく具体的な指摘がないんだよな

256:デフォルトの名無しさん
09/07/25 01:09:34
と、ここぞとばかりに架空の傾向を持ち出すわけですね。

257:デフォルトの名無しさん
09/07/25 09:32:51
ふつうのコンパイラ良書なんでしょうか
学生なのでちょっと資金余裕がなくて

258:デフォルトの名無しさん
09/07/25 09:38:48
研究室で買ってもらえばいい。あるいは図書館。

259:デフォルトの名無しさん
09/07/26 02:01:07
mingw-jpの使い方まったくわからないので
どなたか教えてもらいたいのですが

260:デフォルトの名無しさん
09/07/26 17:17:33
言語ワークベンチは究極的には完全にプログラミング方法を変えるかもしれない
URLﾘﾝｸ(www.infoq.com)

261:デフォルトの名無しさん
09/07/26 17:40:02
>>260 なんかスタイルシートが効いてなくて生々しいレイアウトになってない？

262:デフォルトの名無しさん
09/07/26 17:57:19
>>261
今見たが、特に問題ないぞ。

263:デフォルトの名無しさん
09/07/27 11:25:26
>>261
うちの環境だとこうなってる
IE6　ちゃんと出る
FireFox　スタイルシートが効かない
Google Chrome　スタイルシートが効かない上に画像も表示されない

264:263
09/07/27 11:30:13
今見たら直ってました。

265:261
09/07/27 12:19:46
うーん。うちのFirefoxだと変わらずだな。
エラーコンソールになんか出てるけど、それが原因を示してるのかわからん...

266:デフォルトの名無しさん
09/07/27 13:05:55
>>265
リロードしたらＯＫになったよ、うちのFX

267:デフォルトの名無しさん
09/07/27 14:00:29
うちもFirefoxだと一度目はスタイルシート読み込まれないな
まぁスレには関係ない話題だが

268:デフォルトの名無しさん
09/07/28 14:39:17
>>260
どっちかというと設計よりの話だね。

269:デフォルトの名無しさん
09/08/01 04:41:50
.NET周りで使えるもの、という条件だが。
・Lexical analyzer and parser generator

単純だがよくできている。構文木を食わせてソースコードを吐かせるBison式。
最初これで作りかけていたが、パーサーを構築できてもそのパーサーが予定の挙動をしない場合、デバッグの方法が困難。
（テーブルに分解されてしまうため、ソースが追いかけられない）
パーサーの動作は高速と思われる。

・Irony
パース、構文木構築までをやってくれるコンパイラを動的に構築してくれる。
簡単なGUIのパーサーチェッカーが付いていて、開発がかなり楽
（すごい楽かはもっと楽なものがあるのかどうか知らないので……）
動的に構築する分lapgより遅いかもしれないが、とりあえず自分の目的にはこれで十分なので。

ただ、コンパイル済みコードを吐かすために自分用の構文木を
もう一度作り直す羽目になるのは激しくビミョー……。
（別にそのまま構文木を消化していったっていいわけだが。
　まあ少なくともテキスト形式で出力するにはあの構文木のオブジェクト構造は向いてないな）

次ページ