こんぱいら

おれがコンパイラを開発します

どーぞみまもってくらさい

まずＨＳＰみたいにかっこいい名前を考えます

コンパイラなど誰でも作れる。別に見守るほどのこともない。

終了

そんなに簡単なのですか？
ONITAMAやひろゆきにあこがれてます

exeを作るだけならHSPで簡単に出来る。

終了

ひろゆきといってもｺｺのひろゆきじゃないですよ

インタプリタかコンパイラでまよったのですが
インタプリタのほうが簡単だそうなのでそっちからいきます

開発環境はWinXP,VC++と便利なツールがありそうだが理解してから使う

俺のイメージなんですがインタプリタだと１行読み込んで
トークンに分解して１トークンずつＶＣの命令に変換していく方法
なんだけどおかしいでつか？

＞ＶＣの命令

開いた口がふさがりません

>>4>>6
俺のレベルでは思いつかないのでみちびーてください

＞開いた口がふさがりません

たとえばHSPならmesとかいうメッセージあるだろ？
それをMessageBox()に読み替えて実行していくんだけど無理ですか？

おまんこ〜♪

EXE作成機能付きインタプリタを作るだけならHSPで簡単に出来る。

終了

HSPライクをつくるのでＨＳＰはつかいたくない

バカにもわかるようにおせーてください

言語仕様とか構文解析できた後のことを得に知りたい

HSPも使えないやつがHSPを超えられるはずが無い。

終了

垂れ餡スクリプト

http://age.tubo.80.kg/age02/img001/31.lzh

ヒント [F5]

こらっ、やめなさい！！

>HSPも使えないやつがHSPを超えられるはずが無い。

別に使えないわけではない
ＤＬしたが使っていないだけ

説明できる能力がないのなら馬鹿リンクおながいします

>>14
はっきり言うけど、そんなこと書いてる奴がコンパイラを作れるわけがない。
自力で調べ上げられる程度の実力は必要だぞ。

>そんなこと書いてる奴がコンパイラを作れるわけがない。

そんなのわかっている。
コンパイラと名のつく書籍でもよんだほうがよっぽど近道だ

だがあえてｺｺで解決したい

解決したいのはお前だけ。
オナニーは友達と慰めあいながらやってね

>>17
>オナニーは友達と慰めあいながら
ｸﾛｽｵﾅﾆｰ（・∀・）ｲｲ!

そんなに簡単ならＨＳＰぐらいのシステムをつくれるやつ

レスくらはい

何人いるか知りたい

★ ウィンドウサイズについて 　投稿者：dora 　(04/05/14(金) 18:04) No.12746 ntnara024019.nara.nt.ftth2.ppp.infoweb.ne.jp

ディスプレイの解像度より広いウィンドウを作成する事は不可能です
か？

誤爆した
ｽﾏｿ

おーぃ
ちょっときーてくれ
コンパイラでどこまで自分で作りこむかきめたいのだが
ソースをオブジェクトに変換するのに
これソースで
int a;
int b;
a = a + b;

これオブジェクトな
eax a[]
eab

みんな自分でやってる？

おまいらよ、コンパイラつーか高級言語をつくる上で一番大事なのは、
人間がつかいやすく、かつマシン語と互換性があるかどうか？ということだ。
つかいやすく、かつマシン語と互換性がある高級言語ほど普及する。
例えばつかいやすく、かつマシン語と互換性が高い高級言語の例はＣだ。
だがＣのマシン語との互換性は不完全だ。
Ｃからマシン語にはコンパイルできるが、マシン語からＣへの逆コンパイルは事実上不可能だからだ。
最近一番普及し出した高級言語はJavaだ。
JavaはＣ以上に、１使いやすい、２マシン語と互換性が高い、という条件を満たしている言語だ。
だからマシン語からJavaへの逆コンパイラは多く存在する。
おまいらよ、Java以上にマシン語と互換性の高い言語をつくってみろ？
かつ、アセンブラにならず使いやすいという高級言語の利点を生かした言語をだ。
そうすれば、その言語はＣやJava以上に普及するぞ！！

>>1
板を私用に使わないでください。

自己紹介
http://etc.2ch.net/intro/
夢・独り言
http://life4.2ch.net/yume/

>JavaはＣ以上に、１使いやすい、２マシン語と互換性が高い、という条件を満たしている言語だ。

ネイティブコードとは互換性はないんでつよね？

>>23
じゃあアセンブラでいいじゃん。何か？
とりあえずここに来る前にましなアイコン書け。
そしてVisual E++をVisualにマシン語だけで書いて見れ。

PascalのPコードでもいいの？

ぼく知障になっちゃったかな？
こんぱいらじゃないよ。こんばんはだよ。
「は」って書いて「わ」って読むんだよ。
はいぼく〜こんばんは〜(藁

>>28
あぁ、おまえ知障になっちゃったのか。
でも、自分で気付いたみたいだからえらいねえ。

とりあえず、>>1をこんぱいるしてください

>>1はそろそろこんぱいらを開発したのかな？

>>30
バグ直してないのにコンパイルするな

compile 集める 編纂する

俺、C言語の勉強してて、
ウインドは作れない物の、Cの概要を理解する事ができた。

でも、いろいろ悩んだんだけど、JAVAへ移行する事にしますた！
俺はWin使ってるけど友達にはMac使ってるヤツ多いし。
OS依存のない物の方がいいだろうし。

まだ参考書すら買ってないけど、明日にでも参考書買ってこようと。
がんばるぞー！
と、どこかで意気込みを言いたかったので、糞スレのここで。

じゃ。>>1が作ったコンパイラでコンパってきます。

いや、次世代言語信長の開発はどうなったんだ？

今日も暇なので書店でコンパイラ技法などを斜め読みしてきた

見通しできてからでないとモチベーションあがらないので
とににかく言語仕様や構文解析などはすっ飛ばす。

調べる項目も山積しているのでひとつひとつ解決していくが
かなりつらい

見通しとしては

int a,b,c
a = b = c = 1;
if(a == 1 )c = 100;
のようなものは１対１のアセンブラに置き換えることができるので楽勝だが
printf()等の表示の部分どのように実現しているかわからない
コマンドラインにどうやって出力するのか解析が大変だ
そもそもapiを実装したのだがapiのコールをアセンブラでどうやって
かくのか....これも地道に解析するのか....
ビジュアルは重要だかね.

>>34
やっぱり最初はビジュアルほしいよね
ウィンドウの実装は簡潔にしたいもの

そうするとイベントドリブンは必須か

コンパイラのソースでも読めよ。

>>39
なんかいいのあったら教えてください

>>37
>apiのコールをアセンブラでどうやってかくのか

apiのコールは我が「Visual E++」で実現済みだ。
原理を説明すると、まずcall文でapiをｺｰﾙするんだよ。call[apiの文字列]というふうに書く。
この[apiの文字列]は、dllに記述されているﾊﾟﾌﾞﾘｯｸﾈｰﾑで書くんだ。
次に[apiの文字列]の部分をｱﾄﾞﾚｽに変換するんだが、これはＰＥﾌｧｲﾙ内のIMPORTｾｸｼｮﾝのｱﾄﾞﾚｽになるんだ。
IMPORTｾｸｼｮﾝには使用するapiの数だけ6バイトごとにjmp文＋ｱﾄﾞﾚｽが書いてある。
つまりcall[apiの文字列]はIMPORTｾｸｼｮﾝに書かれている該当するapiの先頭ｱﾄﾞﾚｽを指すわけだ。
だからIMPORTｾｸｼｮﾝには、どの順番でapiを並べるかを決めておかなくてはならない。これは自分で決めるんだ。
次にIMPORTｾｸｼｮﾝに書かれているapiごとのjmp文＋ｱﾄﾞﾚｽだが、これはimportｾｸｼｮﾝのﾙｯｸｱｯﾌﾟﾃｰﾌﾞﾙへジャンプするためのものなんだ。
ﾙｯｸｱｯﾌﾟﾃｰﾌﾞﾙにはDLLごとに使用するapi文字列の先頭ｱﾄﾞﾚｽが書かれてるというわけだ。
とまあ、つまりこのｱﾄﾞﾚｽはこれを指す、あのｱﾄﾞﾚｽはあれを指すというふうに、実際のＰＥﾌｧｲﾙを調べてつじつまを合わせるようにしてプログラムをつくれば、実際のdllとのﾘﾝｸはＰＥﾌｧｲﾙが自動的にやってくれるよ。
つまりおれらは、単にこのｱﾄﾞﾚｽはこれを指す、あのｱﾄﾞﾚｽはあれを指すというふうにつじつまさえ合わせていけばいいんだよ。
「Visual E++」はこのやりかたでapiの呼び出しを実現してるんだから、間違いないよ。
わかったかな？おまいらよ？

ここまで読んで損したって思わせるスレは久しぶりだ。私は悲しい。

「車輪の再発明」と言か「石器の再発明」だな、このスレは。

想像を絶する忌まわしいスレだ

>>37
>printf()等の表示の部分どのように実現しているかわからない
>コマンドラインにどうやって出力するのか解析が大変だ
確かに大変そうだ。
ならいっそﾌｧﾐｺﾝｴﾐｭに文字を表示するコンパイラを作ってはどうか

>>23
HSPは、JavaやCより普及しましたか。

>>41
今の俺には理解できないよ
混合モードみたがPUSHの連続がパラメータでCALLで関数のアドレス入れてる
のはだいたいわかったくらい

33: // ウインドウを作成します。
34: hWnd = CreateWindow(wcex.lpszClassName, // ウインドウクラス名
35: "Windowsプログラムの雛型", // キャプション文字列
36: WS_OVERLAPPEDWINDOW, // ウインドウのスタイル
37: CW_USEDEFAULT, // 水平位置
38: CW_USEDEFAULT, // 垂直位置
39: CW_USEDEFAULT, // 幅
40: CW_USEDEFAULT, // 高さ
41: NULL, // 親ウインドウ
42: NULL, // ウインドウメニュー
43: hInstance, // インスタンスハンドル
44: NULL); // WM_CREATE情報

004010DA mov esi,esp
004010DC push 0
004010DE mov edx,dword ptr [ebp+8]
004010E1 push edx
004010E2 push 0
004010E4 push 0
004010E6 push 80000000h
004010EB push 80000000h
004010F0 push 80000000h
004010F5 push 80000000h
004010FA push 0CF0000h
004010FF push offset string "Windows\x83v\x83\x8d\x83O\x83\x89\x83\x80\x82\xcc\x90\x97\x8c^" (0042001c
00401104 mov eax,dword ptr [ebp-8]
00401107 push eax
00401108 push 0
0040110A call dword ptr [__imp__CreateWindowExA@48 (004252d8)]
00401110 cmp esi,esp
00401112 call __chkesp (004012e0)
00401117 mov dword ptr [ebp-34h],eax

>>45
うまくいかない（T T）
実行時に落ちる

void main(void){

char* a = "こんぱいらだよ%d";
long c;
c = 4545;
__asm{
push a
push c
call printf
add esp,8
}

}

>>45
ちなみに俺はコンパイラを作ったあとにエミュとOS開発する予定だ

>>42-44
すまん

>>50
OS開発なら、モナーOSのメンバーに入りゃいいじゃねーか。

>>47
user32.dllのCreateWindow
>>48
文字を1文字づつ読んで何かしているようだが
そのあとCreateWindowに渡して表示させているようだが
>>49
値を>>48に渡しているようだが
つまりこれは、なんらかの値をウィンドウに出すプログラムということで

>>45
ちょっと無造作に貼り付けてしまってすまん
>>41がAPIコールの実装方法をレスしたがｻｯﾊﾟｲわからんかったので
CreateWindowのAPIを混合モードでだしてみたんだ
だからその二つを>>47と>>48に貼り付けたってわけ
で>>45がそれは大変そうだというから
>>49ではインラインアセンブラでprintfを実現しようとしたが

実行エラーというわけなんだ

>>51それ検索したが見つかんないよ

>>48
簡単なインタプリタを作られたつもりのようだが、
失礼だが1>>は根本的に間違っておられる。
コンパイラを作るならWindowsAPIを呼ぶのではなく、
直接バイナリレベルからWindowsのシステムコールを呼ばなければ意味が無い
表示させたい文字とCreateWindowを呼ぶ処理をバイナリ化し、
保存したバイナリファイルの拡張子を「.exe」にする。
そして実行。
これこそが真のコンパイラだ

考えれば考えるほど疑問が山積するが

例えば混合モードで
void main(void){
printf("もなー");
}
とた場合
void...が始まるまでにすげーながいアセンブラがあるがなんだろうか
ソースを書いた３行のアセンブラはおっかけることができるが
その前後のアセンブラはとてもじゃないが量がおおすぎる
このへんは固定でヘッダフッタとしてつくアセンブラなら納得できるが..

>>1の理解力の速さには敬意を表します

>>1がどの程度のことを知りたいのか知らないがコンパイラを開発してEXEを作るならPEの解析から始めろ。
OSの開発するならもっと違う勉強しろ。アーキテクチャレベルから。
何のエミュ作るかは知らんがエミュ作るならBIOSの解析が必要。シュミレートするだけならエミュじゃないし。

>>47
apiｺｰﾙでCreateWindowを呼んだってあまり意味はねーな。
その前にｳｲﾝﾄﾞｳｸﾗｽの登録がされてないし、ﾒｯｾｰｼﾞﾙｰﾌﾟの処理もされていない。
一瞬で終了するｳｲﾝﾄﾞｳができるだけだ。

>>59
沢村ちゃんも休日なのに早起きだなぁ。

つーか、「コンパイラ」が作りたいんだろ？
OMFかCOFFのオブジェクトファイル吐かせるようにして外部参照の解決は
リンカに任せりゃいいじゃん。
呼び出し規約を合わせればAPIや他の言語で作ったライブラリも使えるし。

オブジェクトファイルのフォーマットが分からないとかリンカって何？とか
言うんなら、これを全部音読してから出直してこい↓

「Linkers & Loaders」 （オーム社）
ttp://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06437-9

Win上で動く物を吐くCコンパイラを作るならこんなAPIが使える
http://www.microsoft.com/japan/msdn/library/?url=/japan/msdn/library/ja/jpdllpro/html/_win32_commandlinetoargvw.asp
ただしUnicodeなので9Xだと面倒くさそう
http://www.honet.ne.jp/~tri/program/unicows01.html

「コンパイラ・スクリプトエンジン」相談室 ３
http://pc5.2ch.net/test/read.cgi/tech/1070089173/

こんばんわ

http://mona.sourceforge.jp/
モナOS

>>58
実行形式のファイルを解析するのか

>>55
0040110A call dword ptr [__imp__CreateWindowExA@48 (004252d8)]
これでいいんだよな？
>>59
大丈夫。SDKくらいわかるよ。
ただＷｉｎ３２ＡＰＩをよびだすアセンブラはこうなってるのかと
みたかっただけ

>>58
>>1がどの程度のことを知りたいのか知らないがコンパイラを開発してEXEを作るならPEの解析から始めろ。
自分がコンパイラたるものとは何かを具体的に知らないから困っている
おおよそこんな項目はこんなことだと思う
１字句解析
２構文解析
３意味解析　　←　ここまではテキスト処理なのでわかりやすい
４中間コード生成　←　これがＯＳ依存のアセンブラコードとすれば対応が難しい
５オブジェクトコード生成　←　9A 2B 3F とかの機械語を指す
６リンク　←　５をつなげる（このへんになると具体がわからん）
７実行ファイル生成　←　？もうＶＣ＋＋のコンパイラまかせなので？

>>60

>OMFかCOFFのオブジェクトファイル吐かせるようにして外部参照の解決は
>リンカに任せりゃいいじゃん。

VC++だからCOFFを調べたらいいんだね..

>>62の誘導でＣマガジンの２０００年５月ごうみて
インタプリタを作ろうを読んだが
リヌクスかぁコンパイラもインタプリタもいっしょじゃん

なんか日記みたいになってきたけどもう夢でおわるのか。。

とりあえず本読むか
>>60紹介してる本立ち読みしてくる
あとエイホの本もみてみる

あとバイトしないと買えないな

>>69
働いてねーのかよ！

重複スレなんだから削除依頼出しとけと。

>>66
「コンパイラ」と「コンパイラドライバ」を混同してる悪寒。

>>1
せっかくのやる気をそぐようで悪いけどまずはプリプロセッサから作ってみては

>>71
ﾟд゜＜　わかった。山崎以外のスレがあるとは知らなかった
>>72
ヒントくれてありがとう
コンパイラやリンカーはコンパイラドライバに呼ばれる仕組みなのか！！
コンパイラドライバってどこにあるんだーーー

>>73
たぶんそのほうがいいと自分でも思っている
全体的な構想やフレームワークが見えてないと続かない......

ﾟд゜＜　削除の仕方がわからん

>>74
コンパイラドライバはコンパイラと普通1対1に対応する存在（だと俺は思っている）
つまり1がコンパイラを作ったらそれに対応するコンパイラドライバを作ることも1だと思う
あとプリプロセッサ・リンカ・makeもあれば処理系としては一通りそろったも同然じゃない？

コンパイラドライバ、プリプロセッサ、コードジェネレーター、アセンブラ、
リンカ、ライブラリアン位は欲しいな。

>>76-77
糞スレにレスありがとうございます
>つまり1がコンパイラを作ったらそれに対応するコンパイラドライバを作ることも1だと思う

コンパイラドライバは結局つくらないといけないんですね
もう一式つくると　いうことですね

>>78
コンパイラドライバなんて対して面倒じゃないと思う。
予めDLLでMakeを作っておいてから、
コンパイラドライバはコマンドライン引数を解釈して、
メモリ上に動的にMakeFileを作りDLL化したMakeに送つける。
タダのmakeもMakeFileを丸ごと読み込んでDLL化したMakeにこれまた送りつける。
1石2鳥ｳﾏｰ(゜Д゜)

コンパイラドライバならLSI C-86 試食版にソースが入ってるから、これを読め。
makeとプリプロセッサのソースも入ってる。
古いDOS用の処理系だがGCCのソースよりは読みやすいので勉強用には丁度良い。

>>79
＞予めDLLでMakeを作っておいてから、
この意味がわからないんですが、DLLでMakeを作る？
俺の使ったことのあるのはMakeは例えばBSD系でソースを落としてきて
/cofigureしてMekeで自動コンパイルというのしか使ったことありません

ひょっとしてMake=コンパイラドライバと考えていいんでしょうか

と　ここまで書いていて

＞コンパイラドライバはコマンドライン引数を解釈して、
＞メモリ上に動的にMakeFileを作りDLL化したMakeに送つける。

Make(DLL化）= コンパイラドライバ　とｹﾃｰしていいですね

>>80
>コンパイラドライバならLSI C-86 試食版にソースが入ってるから読め。

読んでみます！すんげー長い道のりになりそうな悪寒......

>>78 = 1にやる気があるなら糞スレじゃない。
もちろんsageでな

みんな叩くだけ叩いてる様子だが、コンパイラ作りなんて時間のある学生には
勉強になるんじゃないか？
仕事で疲れてるだろうが暖かく見守ってやろうぜ

俺も作ったよ。BASICコンパイラだけど。

make
依存関係が書かれたMakefileとファイルのタイムスタンプから必要なコマンドを実行する

コンパイラドライバ
与えられたソースから実行可能ファイルを生成するために必要なプログラムを順次呼び出す

>>81
DLLは余計だったな。

言いたかったのはコンパイラドライバはコマンドラインをから
架空のmakefileを作り出させる。
それを引数にしてmakeを呼び出す。
もちろんタイムスタンプ無確認で全て実行するオプションをつけとく。
(そういうオプションを持ったmakeを作っておく)
終わったら架空のmakefileは消す。

……っていう事をコンパイラドライバの一形態として考えていたんだけど。、
直接各プログラムを呼ぶのと何も変わんないよな。
makefileに書き出すかCreateProcessの引数にするだけしか違わない。
鬱ﾀﾞｼﾉｳ……。

>>1はもう来なくなったか？

ｻﾝｸｽｺ！
コンパイラ開発にいどむには力不足というのをひしひしと感じている
今は＞＞８０の言うLSI試食版のコンパイラドライバを読んでいます

＞＞８６−＞＞８７
微妙に理解できない状態です。
とりあえずMakeとコンパイラドライバは異なると覚えておきます

沢村＠名無しさんのVisualE++も参考にして
とりあえずバイナリデータをバイナリエディタで書いて
コマンドプロンプトで実行したりして遊んだりしている状態でです

最近はVBばっかりやってたのでC忘れているのにｶﾞｸﾌﾞﾙ（ﾟд。でして
＞＞８６
＞俺も作ったよ。BASICコンパイラだけど。
BASICってインタプリタタイプなんですね
Cマガジン見てたんですけど
１　ソースプログラムを読みながら逐次実行
２　構文木などの中間形式にコンパイルしてそれを解釈実行
３　仮想マシンのためのコードを生成して仮想マシン上で実行

インタプリタってあいまいで難しいですね
コンパイラは完全ネイティブのバイナリデータに変換するから分かりやすいですけど

おまいらよ、おれはつい最近つーか、たったいまさっきtcl/tkつーコンパイラの存在を知ったよ。
いまＤＬしてるところで、まだ開けて見てないんだが、Webでの説明を見た限りじゃなんか良さげだった。
つーか、ＧＵＩに関しては、Visual C++よりもちゃんとしたＧＵＩアプリが簡単につくれるとのことだ。
ただ計算的な処理には不向きということだが、そこは何かＣ言語で書いて追加できるとのことだ。
おれはちょっとこのtcl/tkを調べてみるが、ホントにＧＵＩに関して良さげだったら、いま開発中の「Vicual E++」は、
このtcl/tkで書き直してもいいな。Visual C++じゃエディタの予約語の色づけとかチョー面倒だしな…
そして内部のメインの処理だけをＣ言語で書くようにすればいいからな…
それができそうかどうかをまず調べてみようと思う。
次に調べたいことは、おれが次につくりたい高級言語に、tcl/tkはオープンソースらしいから、パクレる部分があるかどうかということだ。
ともあれ、おれのコンパイラの開発は飛躍的に前進しそうだな。
おまいらよ、おれはtcl/tkいま知ったぞ。おまいらは、tcl/tk知らなかっただろう？

Tcl/Tk、ＤＬしたが、何やこれわぁ！？スクリプトやないか？
実行ファイル作成できんのか？ＨＳＰ以下か？ゴミソフト！！！

ﾌﾟｹﾞﾗ

>>91
なぁおっちゃんよー
ＶＥ＋＋って全部のＡＰＩ使えるの？

仕組みも公開してくれませんか

yacc/rexをぐぐったけどＣ構文の解析器なんですね

perlとrubyを取り入れたＣの文法にしたいという構想はあるですけど
yaccとかはＣ解析器だから無理っぽいですね
まだ試していませんがWindows版はないようなので

沢村の言うことは信用するな。

ところで1は何を作りたいんだ？
漏れの脳内では1は既にCコンパイラを作ることになっているぞｗ

>>95
いや、別にyacc/lexはC言語しか作れないわけじゃないよ。

>沢村の言うことは信用するな。

突然Tcl/Tkを発見したと言い出すからﾋﾞｯｸﾘしたも

>ところで1は何を作りたいんだ？
>漏れの脳内では1は既にCコンパイラを作ることになっているぞｗ

まずCのコンパイラは作ります。
コンスタントで少しずつなんだけど必ず完成させるつもりです
ただLSI試食版の
コンパイラドライバ　→　パーサ　→　コードジェネレータ　→　リンカ
コンパイラドライバはパーサとコードジェネレータをソース毎に実行させるとして
パーサとコードジェネレータが何者かわらんのですが
パーサはyaccみたいなものと考えて
コードジェネレータが吐くものがオブジェクトコードになっているので
アセンブラに展開していると考えています

リンカは複数のオブジェクトコードと
ライブラリを連結させていると見ているのですが、あいまいですね

目的は自分の開発した言語でプログラミングを楽しむことです

>いや、別にyacc/lexはC言語しか作れないわけじゃないよ。

ｽﾏﾝ....調査不足

>>92
Tcl/Tkを馬鹿にした時点で、あなたはゴミ。

>>98
言語処理系のバグなのか、書いているプログラムが間違っているのか
切り分けに四苦八苦して楽しみたいわけですね。ｗ

>>98
順番が違う。LSI Cの場合は
プリプロセッサ→パーサ→コードジェネレータ→アセンブラ→リンカ
でこのプログラムを順に呼び出す存在がコンパイラドライバ。
(ちなみにジェネレータは直訳すると生成者。念の為)

>切り分けに四苦八苦して楽しみたいわけですね。ｗ

同じバグでも愛着があると思います。脳内ではこれは仕様なんだと素直に思える
飛躍ですがMyOSつくたらもっと楽しいﾊｽﾞﾃﾞｽ

>順番が違う。LSI Cの場合は
>プリプロセッサ→パーサ→コードジェネレータ→アセンブラ→リンカ
>でこのプログラムを順に呼び出す存在がコンパイラドライバ。

spawnv()で実行ファイルを呼び出しているのを確認できました（・∀・）
わかって読むのとそうでないのとではぜんぜん違う...
だいぶ楽に読めるようになりますた感謝

よかった。98でCコンパイラ作るって言ってくれて。
実はその気になっていてライブラリ関数を作ってみていたんだ。
(まだctype.h程度、何も出来ていないも同然。)
余計なお世話だったらｽﾏｿ。

>>103 ==1
もう遅いみたいだけどLSI Cのコンパイラドライバ、LCCには呼び出すコマンドを表示するだけの -z オプションがある。
それに確かVC(BCCも)はコンパイラとコンパイラドライバを兼ねているんでわかってなかったんだと思う。

>実はその気になっていてライブラリ関数を作ってみていたんだ。

1人でｼｺｼｺやてるよりモチベーションがあがるので助かります
ライブラリを全部そろえるのはどうしようか迷っていました
全部オブジェクト形式（アセンブラ）で記述するとなると...
あと既存のものを流用しようとも考えましたが、それも勉強しないと
読めません

>コンパイラドライバ、LCCには呼び出すコマンドを表示するだけの -z オプションがある。

ソースしか読んでなかったので使ってみたいと思います

>それに確かVC(BCCも)はコンパイラとコンパイラドライバを兼ねているんでわかってなかったんだと思う。

統合環境でポンとコンパイルばかりしてきたから一度もコンパイル手順を
きちんとしたことがないんです（。。）

実際に何かやろうとするとオツムがついていかなくて大変っす

>>105
でも手抜きのヘボ物なんで期待しないでちょうだい
ところでもう完璧にWin32用と決め付けて
short 2byte
int 　4byte
long 4byte
long long 8byte(long long自体の実装は後回しでもいいけど)
でlimits.h と stdint.hを書いちゃったけど平気？

>>98
>目的は自分の開発した言語でプログラミングを楽しむことです

俺もこれを目指して勉強中です。アセンブラをちょこっと齧って、今はオブジェクト
ファイル形式を調査中。最終的に俺言語が作れなくても、かなり良い勉強になりますね。

ちなみにこんなのもあるよ。Windows でも動くみたい。

http://fabrice.bellard.free.fr/tcc/
http://b2c-1.rocketbeach.com/~bitwalk/tcc.html

>>108
俺は最初にDOSのバッチファイル互換のインタープリタを作って見たよ。
最初に簡単なインタープリタを作ってみるのもいいかも。

>でlimits.h と stdint.hを書いちゃったけど平気？

16bitとかは知らないので平気ぽ

>ファイル形式を調査中。最終的に俺言語が作れなくても、かなり良い勉強になりますね。

(・∀・）同士！
PEのフォーマットが知りたいんです。何かわかったら教えてくらさい
おながいします

＞最初に簡単なインタープリタを作ってみるのもいいかも。
インタープリタの方がいまはわからないです

>コンパイラドライバ、LCCには呼び出すコマンドを表示するだけの -z オプションがある。

確かに
プリプロセッサ　CPP
パーサ CF
ジェネレータ CG
アセンブラ r86
の順で読み出していました
パーサとジェネレータのソースがない.........
Mekeのソースはあるんですがなんだろうｺﾚﾊ

さすがにLSIもタダで製品のコードジェネレータのソースを晒すほど気前よくはあるまい。

コンパイラの内部構成
ttp://www.msc.cs.gunma-u.ac.jp/~nakano/Compiler/gaiyou.html
ttp://www.msc.cs.gunma-u.ac.jp/~nakano/Compiler/index.html

>>112
リンクありがとん
一読して思いましたが、かなり勘違いが多いのに気づきましたｼｮﾎﾞｰﾝ

My言語作成の前にC言語をまねてから、と考えていましたが
その前に電卓作ってミニモデルつくってみたほうがいいと......

１　コンパイラドライバ
２　プリプロセッサ
３　字句解析器
４　構文解析器
５　コードジェネレータ
６　アセンブラ
７　リンカ

いまの段階では電卓作って、３，４、もしくわ３，４，５，６をやって
いこと思います
今、題材をC言語にして２，３，４に手をだすのは体力不足でした......ｽﾏﾝ

(110も114も1だけど)
>>110
PEやOBJ(OMF/COFF)のフォーマットなんて知らなくても
NASM(かなんか)の構文と適当なリンカのオプションを理解すれば
PEやOBJのことはそいつらに任せられるから何とかなるでしょ？

とか言いつつもPEの解説がここにあると言ってみるﾃｽﾄ
http://www.interq.or.jp/chubu/r6/reasm/PE_FORMAT/intro.html

>>114
6 アセンブラは自作不要。既存のでいいよ

一応報告。
stdarg.h stddef.h stdbool.h assert.h作りました。
中身はたいしたことないものばかりです（ぉ。

>PEやOBJのことはそいつらに任せられるから何とかなるでしょ？

だいぶ気がらくになりました

>>116
かなりもたついてますが、また進展がありましたら教えてださい