10/07/21 21:13:48
MSのコンパイラは通常はBPを使用せずSPのみでコード構成するな
何かの判断基準を上回った関数のみBPを併用
837:デフォルトの名無しさん
10/07/21 21:21:43
ほんとにか。へー
838:デフォルトの名無しさん
10/07/21 21:36:05
gccも-Oつければ基本そうだけど、i386用は-fomit-frame-pointerがないと省略しない
839:デフォルトの名無しさん
10/07/21 21:41:50
ジャンプ関係もできた
あとはぱーさ・・はすぐできた
終わり
840:デフォルトの名無しさん
10/07/21 22:06:50
なかなかすばやいな
841:デフォルトの名無しさん
10/07/21 22:18:38
おまえら、コンパイル終わった後のバイトコードをどうやって管理してる？
オレはセクションごとにSQLiteのレコードにシリアライズして放り込んでるんだが。
842:デフォルトの名無しさん
10/07/24 13:47:22
中田買ってから
ＰＤＦで英語版のエイホのやつ読んでみたら
日本語版にのエイホのやつ買っておけばよかったと後悔してしまった。
843:デフォルトの名無しさん
10/07/24 16:43:24
>>842
どんな点で？
844:デフォルトの名無しさん
10/07/24 20:09:32
アホの中田
845:デフォルトの名無しさん
10/07/25 04:40:29
日本語のAHO＞＞英語のAHO＞＞＞＞＞＞＞中田氏の
ってことだろ
846:デフォルトの名無しさん
10/07/25 10:41:28
日本語が得手の方のみお願いします
847:デフォルトの名無しさん
10/07/31 16:36:35
>>843
詳しいから。
848:デフォルトの名無しさん
10/08/07 23:31:13
スタックベースのVMで、関数の戻り値ってどう設計すべきでしょう？
構造体や多値をスタックで返したいけど、その型は事前に判りません。
今は別の戻り値スタックに置いて、
その頭に関数が返した型の情報を置いてます。(スタックを1本にしたい)
| SP ↑ヒープ
-------------------
|local2 BP-3
-------------------
|local1 BP-2
-------------------
|local0 BP-1
-------------------
|親BP BP+0
-------------------
|関数戻りaddr BP+1
------------------- ←関数リターン後のSPの位置(cdecl)
|arg0 BP+2
-------------------
|arg1 BP+3
-------------------
事前に型が判ってればarg0の上に呼び出し側で空きを作れますが、
判らない場合は、SP上の戻り値情報の位置を入れるスペースを作って、
0なら戻り値なし、0以外(N)ならSP-Nの位置に戻り値があるとかかなあ？
スタックトップ以降にも有効な値があるってのはどうなんだろう。
849:デフォルトの名無しさん
10/08/08 00:46:50
>>848
COMのVARIANTのようにするのが簡単だろうね。
850:デフォルトの名無しさん
10/08/08 14:33:37
関数リターンのアドレスを取っておく
データとサイズををプッシュしる
さっき取っておいたアドレスにジャンプする
っていうのはどうだろうか。
851:デフォルトの名無しさん
10/08/09 04:25:05
>>848
> スタックトップ以降にも有効な値があるってのはどうなんだろう。
戻値がスタックトップの上にあるか、下にあるかってのは、
意識の問題に過ぎないのでは?
有効な値のある場所をスタックトップと思えばいい。
852:デフォルトの名無しさん
10/08/14 20:35:49
KL1、ガード部の単一化ってどうやって実装するのがセオリーなんでしょうか。
というより、ガード部での単一化、コミットとチョイスをどうやって実装するのかが一番謎で……
853:デフォルトの名無しさん
10/08/15 20:27:23
>>852
セオリーは知らないけどSTMでやってみたら？
854:デフォルトの名無しさん
10/08/19 11:33:10
コンパイラ作るのって楽しいですね。ラムダ計算インタープリタつくるのとっても大変でした。つぎはリスプからラムダ式に変換するコンパイラをかこうとおもいます(;ﾟ∀ﾟ)=3ﾊｧﾊｧ
855:デフォルトの名無しさん
10/08/19 12:05:09
GCを使わない方法を考えてみて
856:デフォルトの名無しさん
10/08/21 19:34:46
>>852
セオリーがあるほど処理系はないのではないかと思います。あるとしたら、
www.klic.org にある Inside KLIC ドキュメントと KLIC 処理系がそうでしょうか。
KLIC が生成する C ソースを見てみるのが一番早いかもしれません。
> ガード部での単一化、コミットとチョイスをどうやって実装するのかが一番謎で……
ガード部の「単一化」という言葉に引きずられるとわかりにくいですが、
要するに一致するかしないかチェックすればよいのだと思います。
例えば、
foo([A|B], C) :- A = 1, list(B) | C = 2.
みたいなホーン節があったら、このガード節を
1. 第一引数がリストかチェックする
2. 第一引数に与えられたリストの CAR/CDR をそれぞれローカル変数 A, B に入れる
3. A が数値 1 かチェックする
4. B がリストかチェックする
のような手続きに書き換えれば良いのではないかと。
これら全部のチェックに通ったら、ガード部単一化成功と看做して
ボディ部の単一化を実行します。
どれかのチェックにひっかかったら、ガード部単一化失敗ということになります。
foo/2 のホーン節定義が複数あったら、各ホーン節定義についてチェックを行い、
チェックに失敗したら次のホーン節定義のチェックにジャンプする、という格好に
なります。