コンパイラをかきたいんですけど・・・

ひょんなことから書かなければいけないんですが、
何か注意しないといけない点とかあればご教授願います。

似たような題名のスレがありますがネタじゃなので....

察しの通りだと思いますが、学校の課題です。
そんな複雑な言語じゃないのでコード生成までの理論などは
一通り理解したつもりなんですが、コンパイラを実際に書く
となると何かいろいろと不安です。識別子テーブルの管理とか・・・

しかもあろう事か、4人で分担して作れという内容なのでさらに
不安拡大です。うまく連携できるかなぁ....

卒論ですか？
普通の授業の課題だったら、たまらんなー。

ちなみに言語は何？

間違えた、こっち
http://piza.2ch.net/test/read.cgi?bbs=tech&key=981672957

多人数での開発を教えている学校にアドバイスもらったら？
すっげーいい経験になるよ思うよ。アドバイスじゃなくて、課題の方な。

「yaccやlexを使うな」との制限もありました...

>>3
普通の授業です(泣).
言語はPascalの簡易バージョン(独自)らしいです

その言語の使用が教科書にしか載っていなくて(Webとかでも教えてくれない)
しかもその教科書がまた高い....

とりあえず、 >>5 お勉強します

>>6

今回はコンパイラという課題もさることながら、
多人数開発がさらにネックになりそうです。。

こんな私が4人の中で一番詳しいと言うことで
リーダーにさせられました

がんばって設計中です.......

>>7
んじゃ再帰下降とかLL(1)で、さらにPascalつーことで1パス・・。
スタックマシンにして型定義にこだわらなければ長くても１週間程度で終りそう。
レジスタ割り付けとかあるんなら別だけど。

そういやターゲットは何ですか？
つまり所謂ネイティブコンパイラですか？

＃全然知らないんだけどa.outとかELFとかってのは
＃フォーマット難しいんでしょうか？

>>10
ターゲットは「仮想スタックマシン」だそうです。
仮想的なアセンブリを対象にしたコードを生成
すればよいみたいなので、ネイティブなコード
あたりはあまり心配いらないみたい。
＞純粋なテキストで仮想アセンブリを生成でいい

しかも、その仮想アセンブリをインタプリタのように
実行するプログラムも作れと言う、端から見て
非生産的な課題内容です・・・・・・

普通だろ

>>12=9

今改めて考えてみて気づきました、確かに普通ですね・・・
やはりもう少し考えをまとめ上げてから設計した方がいいのかも

仮想機械の手直しだけで他の環境に移植できるから汎用性は上がる
実行効率は落ちるけど。
必要なら「仮想機械→ネイティブコード」って手があるし。(参考JavaVMなど)

(ちなみにgccでも内部処理は「仮想機械→ネイティブコード」ね。)

9さんありがとうございます。。

なにやらいろいろと新しく気づく点が多くて参考になっています。
でもその分、ますますコンパイラづくりがうまくいくかどうか不安に・・・
(utc ...)

大學学部の授業なみだな

http://piza.2ch.net/test/read.cgi?bbs=tech&key=967778156&st=49&to=49
http://piza.2ch.net/test/read.cgi?bbs=tech&key=967778156&st=77&to=77

みなさんありがとうございます〜
こんなけサイトがわかればもうお腹いっぱいって感じです(＝/

>>2 でもちらっと書いたんですが、できればこれからは
コンパイラを作るための理論的な話より
実際にコンパイラのプログラミングをするときの実践的な
アドバイスが何かあればお願いしたいです
コンパイラソフトの設計へぼいと泥沼と化すとか....

# っとまで書いてみて、こんなのコンパイラに限った話じゃ
# ないですね... なのでsage

ちなみ、
4人で話し合って設計しているときにほかの2人が言った言葉
「設計なんて、実際にプログラムを書き始めてみないとわからない」

私としては、4人の分担している部分を1つにまとめるときに
面倒なことにあまりならないようにするため、せめて
連携するところ(他の人の作った関数を呼び出す・他の人に関数を呼び出される)
　　　　　　　(「インターフェース」と呼ばしてもらいます〜)
がそれなりにきっちりと設計されていないままプログラミングを始める
のが危険に感じられてしょうがなく、話し合いといえど実質私が
一人でそんなインターフェースを作っているのが不安です。

# 長文スマソ

>>22
俺もプロの方々の意見を聞きたいのでage!
どうやって分担してるのかな？

gccの基本部分ってストールマンが独力で設計したの?

今のところは、字句解析・構文解析・識別子管理テーブルと
全体のプログラムをまとめ上げる部分(これら以外の部分ともいえる)
の4つにわけてそれぞれを分担しようと思っています。

実際にプログラミングするにあたって、やっちゃいけない処理
(泥沼化・連携ミスを誘発しそうなこと)とかの話が聞ければ幸いです。

たとえば、文字列をわたすのに
int　foo(　const char* const) ;
とかするなんていうのは基本になるんだと思うんですが〜
(言い忘れましたが、Cで書くことにしてます)

>>24
力及ばなくて申し訳ない、わかりません

>>22
> 「設計なんて、実際にプログラムを書き始めてみないとわからない」
詳細設計はともかく、全然設計しないと破綻する可能性が高い。

> 連携するところ(他の人の作った関数を呼び出す・他の人に関数を呼び出される)
> 　　　　　　　(「インターフェース」と呼ばしてもらいます〜)
> がそれなりにきっちりと設計されていないままプログラミングを始める
> のが危険に感じられてしょうがなく
あなたの感覚は正しいです。
インターフェースやグローバル変数、構造体、テーブル
モジュールの分割やヘッダファイルの分割はやっといた方がいいです。

まぁ、とりあえずあなたが中心のようですからあなたが叩き台を作って
みんなの意見を聞いて、それを反映させて設計書を作ってみましょう。

グループでやって泥沼化するのが嫌なら、いっそ全部一人でやる
というのはどうでしょうか？で、四人でやったことにして提出する。
一人でやる方が作業効率もいいかもしれません。

>>28
チーム開発も課題に含まれてるような気がする・・・。

失敗しても良い今、チームでやることの大変さや
楽しさを味わっておくのも、また一興かと。

>>28
もちろん、そんな案も話し合いながら出しましたが、
>>29
のような立場です。

>>27
大方は、そこでおっしゃってくれたようなことを
念頭に置いて設計してます。
とにかく、あとあとみんなが困らないような設計
にできるようがんばります〜

優良スレなのでage

>>24
http://cruel.org/freeware/rmslecture.html#34

基本だけど、とりあえず最低限の機能を仕上げて、
その後あーだこーだやれば破綻はしない。

　関係ない話だが、そんな課題が出る学科ってうらやましいなぁ・・・。
情報系じゃないからそんなのぜってぇ出ないよおれ・・・。
応援age。

↓ここなんか参考になるかも
http://www.tokumaru.org/

>>25
C だとメモリ管理に要注意。

字句解析ルーチンでトークンを切り出して（このときに、
おそらく malloc する）、それを構文解析ルーチンに渡
し、構文解析ルーチンがシンボルテーブルに登録したり、
シンボルテーブルから検索するワケですが、誰が最終的に
free() するのか、同じ文字列を複数のルーチンで共有し
て良いのか、それとも strdup() して渡すべきなのか、
設計時に良く考えておかないとハマります。

最適化や型システムを実装しだすと DAG みたいなサイク
ル有りのグラフ構造が出てくるけど、こいつも解体すると
きに無限ループしないように注意ね。

もし、使う言語に指定がなければ Java で組むことにした方
が楽だと思う。C で組む場合には xmalloc とか ccmalloc
みたいなツールを拾ってきて、メモリの使用状態をチェック
しておきましょう。

>34
そうだねえ。
Cだとコンテナ系モジュールが最初から揃ってないと辛い気がする。
スタックや連想リストぐらいは用意しないとね・・
思考の妨げになるから。
C++でも良いんならそれでやればいいと思う。

>>32
>その後のあーだこーだ
で破綻しそうな気がするので、極力インターフェースを
固めてしまいたいのですが、どんなにきっちりとした
設計を作ってもやはり最終的にはあーだこーだやらないと
いけないんでしょうねぇ・・・

>>33
「マイクロコンピュータを作る」なんていう実験まであるので
ある意味つらすぎです。私は後半これをするのですが、
前半で(今)やっている人たちは、論理回路をしこしことしながら
「ぜんぜんわからん」と言ってます。実質教科書に書いてある
答えを写してレポートを完成させるのが実験内容みたいな
ものらしいです・・・・ってスレと関係ないや。

>>35
C++も考えたのですが、ほかのメンバーがわかってそうにないので
Cにしました。というか私もあまりわかってないかも・・・
(「クラスにすれば楽かな」程度しかC++はわかってません)
ちなみに、言語はなにで書いてもいいらしいです。
ジョークのつもりでJavaをあげたりしてましたが、実は
いい選択肢だったんですね・・・・

>>34
メモリ管理は今かなり悩んでいます。基本は、メモリを確保
した側が解放する、て方針が一番わかりやすいのだと思うのですが、
それが返って設計に悪影響を及ぼしてしまっている気もするんです・・

「メモリを確保した側が解放する」にはとらわれない方がいいのかな。
でもそれだと、メモリリークが怖いし・・・・

ん〜、設計てこうやって悩むんですね・・・
でみんなから「んなタコな設計つくんな」と怒られるんですね・・・(utc..)

>>22
>「設計なんて、実際にプログラムを書き始めてみないとわからない」

その2人の名誉のために書きますけど、決して
「設計が大事でない」て言ってたのではなくて
「設計大事なのはわかるが、実際にプログラムを書いてみないと
　しっかりとした設計は見えてこない(含インターフェース)」
です。

もしかしたらその2人ここ見てたら困るので....

>>34
boehmGCとかいうGCライブラリを使う、ってのは
駄目人間な選択肢でしょうか？
w3mやモジラでも使っているらしい。
free()って書かなくて良いのは気楽です。

インタプリタ作って遊んでいます。

>スタックや連想リストぐらいは用意しないとね

最近出た本「プログラミング作法」(だったっけ？
似た別の名前だったら御免)をベロ真似しながら、
StackやHashを最初に揃えた。
道具ない(開発言語はC)とヤッテラレナクなるのは
目に見えてたので、ボトムアップしてます。

>>40
リストやキューだったら 4.4BSD 由来の <sys/queue.h> が
便利。

http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/queue.h
http://www.freebsd.org/cgi/man.cgi?query=queue&apropos=0&sektion=3&manpath=FreeBSD+5.0-current&format=html

ヘッダしかないと思ったらマクロなんだね。
見栄えが悪くなるのは仕方ないか

>>37
> メモリ管理は今かなり悩んでいます。基本は、メモリを確保
> した側が解放する、て方針が一番わかりやすいのだと思うのですが、
多分、シンボルテーブルだとそれは無理
シンボルテーブルはシンボルが出現した場合、確保を行い、
そのテーブルの寿命はプログラム終了まで続くはず。
その場合、テーブルを一気に解体する関数があった方が楽。

また、解体する時に
> 同じ文字列を複数のルーチンで共有し
の場合、リファレンスカウンタかなんか実装してないと
２重free()の危険があり、これはメモリリークよりタチが悪いです。

Introduction to Compiler Construction with Unix by Schreiner and Friedman,Jr
って本があるけど、これにはlex, yacc使ってるけど具体的に疑似マシン語まで出力する方法が
サンプルプログラムで具体的に説明されています。古い本なのでまだ出版されているかは
知りません。
今調べたら85年出版で絶版でした。ごめん。俺もってるけど。

>>1はもしや東京大学？

>> 1

つーか完成したら見せてほしいよー

ageます

コンパイラ理論の実践が目的で、使う言語が何でも良いなら、
「OOPでない(よりよいCとしての)C++」にしたら？
std::stringやSTLを使って、枝葉の部分(メモリ管理やらコンテナやら)に
労力を取られないようにするのもひとつの手かと。

>>43
Pascal 風の言語だと、シンボルテーブルに登録されたシンボ
ルの寿命はブロックが終わるまでですね。

ブロックが１レベル深くなるたびにそのことを記録しておいて、
ブロックから抜けたら、まとめてそのブロックのシンボルを削
除するのが普通だと思う。予想されると思いますが、データ構
造はスタックを使うと相性が良いです。

なお、Pascal 風の関数・手続きの文法では、仮引数宣言はブ
ロック開始の前、仮引数のスコープは当然ブロック内になるの
で、それだけは注意してください（私は、これでバグを出した
経験が……）。

とりあえず、ドラゴンブックの上下読むことをお勧めしますが。
エイホ、ウルマン著のコンパイラ上・下だっけ……？
うろ憶えですまん。

>>49
書棚から引っ張り出してきたよ。

コンパイラ I 原理・技法・ツール
A.V.エイホ, R.セシィ, J.D.ウルマン共著, 原田賢一 訳
サイエンス社
ISBN 4781905854

コンパイラ II 原理・技法・ツール
A.V.エイホ, R.セシィ, J.D.ウルマン共著, 原田賢一 訳
サイエンス社
ISBN 4781905862

この本はコンパイラ理論の古典的名著（いわゆるバイブル）
だけど、記述はかなり理論より。実際にコードを書くには、
もの足りないかも。

ま、その辺は別の情報源で補って下さい。

>>43
> リファレンスカウンタ
この言葉、初めて聞きました(この時点でだめだめかも...)
考え方自体はよくわかったのですが、今回
>>34
> 同じ文字列を複数のルーチンで共有
するようなことはなく、文字列は極力どこかの所属で
必要時に参照するのみ、にしようと思っています。

>>43
>>48
48 のおっしゃっているとおり識別子の寿命はその識別子が
ブロック宣言されたブロックが終わるまでなので、
いらなくなったら即消去とする予定です。

>>48
>データ構造はスタックを使うと相性が良いです。
スタックはブロックが深くなる・浅くなる　の部分で
用いられると思うのですが、
今回データ構造に関しては、下手にいろいろと考え出すと
痛い目を見る可能性が高いと判断して(逃げてます。。)
教科書どおりのものにしようと考えています。

それによると、ブロック情報を専門に管理する部分が別にあり、
そこがスタック状になっているのでこのことだと理解してます。

識別子はハッシュ的にテーブルへ登録され、同じブロック内の
識別子がリストで結ばれ、1つの識別子へのポインタをブロック情報が
格納している・・・・ような気がする構造になっています(謎)
(授業で聞いた言葉並べて、わかった気になっているだけかも...)

>>47
そのことも考えての、
>>37
だったのですが、メモリ管理やらコンテナやらに
労力を取られない分 STL を使いこなす分に
労力を取られそうです(

STL・・・
やはり使いこなせた方がよいですね・・・
近いうち時間取れたら考えてみます。

>>45
東大ですか・・・
いろんな意味で「とおい」ところです

>>46
完成しなかったらどうしましょ(w

こちらで出してもらった本は、たいがいが図書館に
あるようです。その点では私のところは
恵まれている大学なのかも

いっちー萌えage

あぁ、こんな素直な奴がうちに来ないかなー（妄想）

完成したら
公開してちょ >>1

>>57
>>46
しつこいね。

>>1
完成したら見せてね&hearts;

>>58
「お前モナー」
って言ってホシイの？

あーあ。せっかくまともに進行してたのが>>46のせいで台無しになたな

>>58 俺は46しか書いた覚えは無い。57なんかと一緒にすんな。
>>60 ごめん。

これだけじゃなんなので、
http://www19.freeweb.ne.jp/computer/yaneurao/yaneSDK1st/
にあるyaneSDK内のyaneScriptなんてどうよ。

なんだかんだいろいろと言われてるけど、
具体的な実装の例としてはいいんじゃない？

いつぞやＣマガでTurboCのソース公開してたよな・・・
どっかに無いもんかね。

識別子は消す必要ないと思われ。
状況によって消す必要があるのは、「識別子と、
それを束縛する値のペア」つまりいわゆる変数であって、
識別子(=名前そのもの)にIDを持たせたりしての管理体制は、
処理系のスタートから終了までずっと万世一系でいけるはず。

つまり、アッチで出た変数名Aとコッチで出た変数名Aは
同じ識別子だと思ってよいわけです。同じ変数ではナイけど(^^;。

＃ていう話でしょうか？はずしてたらごめん。

蛇足(かつInterpreter)だけどPostScript。
あれは変数(?)のScopeをユーザーProgramで明示的に制御します。
具体的にいえば、Dictオブジェクトを作成してDictStackに積めば
1つ内側の名前空間に移動し、DictStackをPOPすれば
1つ上の名前空間に戻ります。
なんかその手順はまさに普通の言語の処理系が中でやってること
そのものって感じで、いじっていて楽しい(快適かどうかは別)し、
色々処理系に教えられるものがあります。
＃処理系は自作のモドキなのにも関わらず(^^;

今更言ってもどうしようもないんだろうけど、
随分昔、「ポケコンジャーナル」に
結構こってりとコンパイラ(ALGOL系言語ってのかな)の作り方が
載っていたなあ。無学だった俺には超新鮮でタメになった。

＃ナニがタメになったかというと、「体系立ったコンパイラの作り方」
＃というものが存在するのをソレで知ったので。感謝。

>>61
>いつぞやＣマガでTurboCのソース公開してたよな・・
まじですか！

>>64
TurboCのソースなんて欲しいか？

>>65
ほしいほしい！

>>61
ざっと読んでみましたが yaneScanner (字句解析), yaneParser
(構文解析), yaneVirtualCPP (仮想マシン), yaneVM2i386 (JIT
コンパイラ) とも、きわめて基本に忠実なコードになってますね。

ただし、コードの質はさほど高くありません。実用の処理系として
は論外ですが、勉強のために読むコードとしても

1. コメントが腐っている
2. ソースコードがあまり整理されてない

点はマイナス。いずれにせよ、実装の「一例」として参照する分に
は悪くないと思います。

個人的には、コンパイラの学習用に読むのでしたら lcc を勧めて
おきます。作者が lcc について書いた本もあるようですが、こち
らは読んでないのでコメントは避けます。

http://www.cs.princeton.edu/software/lcc/

>>66
GCCでいいじゃんとか思うのですが……

コメントは面白いと思った

>>69
個人的には、コメントもやね氏のページの RSP も笑わせてもらいま
した。でもまあ、技術的な話と、お笑いは別ってことで。

>>68
どうやって速くしてるのが知りたい

>>61
何号ですか？

>>71
そうかぁ
つーかgccは100万行とかあるんだっけか？
>>67さんのいうlccはどんなもんなんですか？

TurboCのソース公開してるならおれも読みたい
>>61教えてくれ

自分も選択課題で出されたから気になるなぁ。

チーム制でやるなんて面白そう。やっぱり学部３年？　２年とかだったら恐ろしい…。

>>72
ごめんわからない。１年前くらいだと思う。
結構話題になったんで、そこらへんの
プログラマ日記サイトの過去ログ探せばわかるかも。

そんな無責任な>>76

情報が少なすぎるっつーの。
結構話題になったって、だったらどこで話題になったのか教えてくれ。

http://cmaga.zdnet.co.jp/backno.htmlから探すしかないかな。

>>79を見て、どれだと思う？>>61

>>1
わからなかったら上回生のディレクトリを見なさいっ。
ただし成績は可にしますが。

>>81は湯淺太一で>>1は京大生。

>>82
匿名掲示板で身元を詮索するなよ……
っつーか、スレッドの趣旨と全然関係ないので sage

>>83
いや言ってみただけで湯淺太一大先生なわけないし気にしないで。
そもそも「浅」じゃなくて「淺」だし。
でも>>81はネタじゃなくホントに>>1の先生っぽいような……。

>>80

ごめんよう。全然わかんねー。
えーとな、かなり前なんだよ。
'99より前っぽいんだよ。

>>85
かなり探したんだがそれらしい物はまったく見つからなかった。
君の勘違いなんてこたないよね？

>> 86
そう言われると自信が無くなってくる・・・
すまん。こっちでも調べてみるよ。

もし勘違いだったらマジですいません。

>>73
リンクをたどれば書いてありますが lcc は ANSI C コンパイラです。
gcc などの本格的なコンパイラに比べると最適化が弱く実用には適し
ませんが、ソースコードは非常にコンパクトかつ素直な構成になって
います。

>>88
lccってワイド文字とかサポートしてないでしょ。
ライブラリ関数が不足しているのはROM化する分にはフリースタンディング環境
だからと割り切れるけど、wchar_tが使えないのはANSI Cとしては論外。
他にも動作が変なところがあるけど、それはまあバグということで。

>>1
最近はWirthの教科書ないのか？
Pascal風コンパイラ（整数のみ）が載ってたぞ。
題名忘れたけど・・・・
相当参考になったよ。

これだな。

[ヴィルトのコンパイラ構成法]("Compiler Construction")[10]を書いてきた。「A+D=P」から2回書き直していることになる。なんというか、教科書を書くのがすきというか。前書きでも「最近の学生どもは基本的な仕組みを理解しとらんから」云々などという文句をたれていて、ああ学生達もうるさい爺さんがいて可哀想、とも思うけど羨ましかったりもして。ちなみに単なる焼き直しではなく、分割コンパイルとか、以前はスタックマシンを想定していたのだが、RISCコードを生成するときの最適化などの現実的な（？）話題も盛り込んでいる。

[1] ニクラウス・ヴィルト『アルゴリズム＋データ構造＝プログラム』,マイクロソフトウェア,ISBN
[2] ニクラウス・ヴィルト『Modula-2プログラミング』,マイクロソフトウェア,1986
[3] ニクラウス・ヴィルト『データ構造とアルゴリズム』,近代科学社,1990,ISBN4-7649-0162-5

ヴィルトのコンパイラ構成法
http://www.amazon.co.jp/exec/obidos/ASIN/4795297061/qid%3D988380359/sr%3D1-2/249-58/249-4393191-9372355

翻訳系構成法序論
http://www.amazon.co.jp/exec/obidos/ASIN/4764901129/qid=988380461/sr=1-1/249-4393191-9372355

Wirth
http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Wirth%2C%20Niklaus/107-1434289-3206952

http://www.yfcbookshelf.com/compiler.htm

日本人がlccつったらふつー、LSI-Cのことでは？
別にいいけどサ。

なんかもう顔を出しづらくなっちた。

>>81
ホンニン？　だとしてもそんな時間まで起きてると体に
悪いですよ〜

っていうか、どう考えてもうちの大学だな。＞１
おれも同じ部屋で引きこもり寸前でやってます。
湯淺は直接関係ないよね。

マスでもかいとけ

数年前、高校の授業中にマスかきました。

ageてみる

>>98
よくぞageてくれた。

切り番get!

age!

なんであげるのん？>101のわんちゃんさん

コンパイラを作る方法 PASCAL処理系作成の理論と実装
翔泳社
1993年11月発行
259P 26cm
ISBN: 4-88135-072-2
価格: 3,107円（税別）

http://cocoa.2ch.net/test/read.cgi?bbs=linux&key=985427152

こっちでがいしゅつです>103
【コンパイラ・スクリプトエンジン】相談室
http://piza.2ch.net/test/read.cgi?bbs=tech&key=981672957&ls=50

昔話になっちゃうんだけど、MZ-80を使ってたころWICSという
BASICもどきのインタープリタとコンパイラがあって、
コンパイラはWICS自身で記述されていた。
当時はソース公開あたりまえの時代だったから
とても勉強になったもんだよ。
技術的には最先端ではなかったけど基本は抑えていたし。
一人で全体を読んで把握するのに無理の無い規模だったし。

他のレポート多すぎ
これにあまり時間さけない・・・

//↑グチ

憂慮スレ。age

A.T.シュライナー／H.G.フリードマンの
『Cコンパイラ設計yacc/lexの応用』は
どう？
古いけど。

>>105
無理のない規模っていえば PL/0
でもyacc/lex使って作ったほうが楽。

>っていうか、どう考えてもうちの大学だな。＞１

ここまで聞くと、どうしても大学を知りたくなった。

コンパイラだろうとマスだろうとすきなようにかけ。

ところで、ちゃんできたんだろうか？
できなかったらどうなる？

それらしい動作はするものの、まだ挙動不審
2,3日ほど集中してやればかなりまともに動きそうだけど、
他の試験＆レポ関連で現状のままとりあえず課題は提出になりそうです。。
↓はコンパイルできた

PROGRAM EXAMPLE1;
　VAR N:INTEGER;
　FUNCTION F(N:INTEGER):INTEGER;
　　VAR NN:INTEGER;
　　BEGIN
　　　IF NN=0 THEN F:=1 ELSE F:=N*F(N-1)
　　END;

　BEGIN
　　FOR N:=1 TO 3 DO
　　　BEGIN
　　　　CALL WRITELN;
　　　　CALL WRITEI(F(N))
　　　END
　END.

>>88
これって無料のWindowze用コンパイラ、lcc-winの原型？

よく見たらリンクついてました。
でもlcc-winのソースは有料。

>>113
世話になったついでにソースコード公開しとき

俺の大学（情報学部）は3年になってもBASICでソートやってた。
バカばっか。

あげ

>>117
少なくともあなたがいるなら馬鹿ばっかりともいえないでしょう。自力でがんばれ！