463(4): デフォルトの名無しさん [sage] 2008/10/06(月) 21:49:04 AAS
・リターンスタックが普通のCPUで言うとことの「スタック」。
　ワード（Ｃで言うところの関数、実際にはサブルーチン）
　を呼ぶと呼び出し戻るためのアドレスを積む。

# 普通のCPUでCALL命令（68系だとBSR、JSR）を実行すると
# リターンアドレスがスタックに積まれるのは理解しているよね？

・データスタックってのは、言ってみれば「無限に増えるアキュムレータ」って感じ。

・「辞書」が命令コードストレージ、Ｃ言語でいえばTEXTセグメント

Forthの本質は上記３点をおさえて置けば理解できるんだが。

BPがリターンスタックと等価なんて言ってる人とか、

＞・リターンスタック：　実行する命令列（辞書で展開された単語含む）
＞リターンスタックというよりもオーダースタックといった方がちょうど良い気がするけどね

なんて言っている人、本当に理解できてるの？

473(2): デフォルトの名無しさん [sage] 2008/10/07(火) 23:56:37 AAS
>>472
意味が理解できん。
「まだ実行してないWord」を積む、って具体的に何を積むの？
まだ実行してないワードのアドレスなら辞書に入ってると思う（関節スレッディングの場合）

485(1): デフォルトの名無しさん [sage] 2008/10/09(木) 06:24:10 AAS
リターンスタックに積んであるリターンアドレスは、
「これから実行される命令列」へのポインタそのものと見なせるから、
そのアイデアが新しいとは思えないけどな。
Forthぐらいバーチャルマシンの実装が簡単な言語もないし。

ただ、リターンスタックの意味がよくわからないままに、
他の言語のように抽象構文木を再帰的に処理するような
実装にしていると、リターンスタック操作の実装で悩むの
かもしれない。

451(2): デフォルトの名無しさん [sage] 2008/10/05(日) 19:02:41 AAS
>442
大雑把にはこんな感じかね。
・データスタック：　引数＆戻り値
・リターンスタック：　実行する命令列（辞書で展開された単語含む）

リターンスタックというよりもオーダースタックといった方がちょうど良い気がするけどね

498(1): 496 [sage] 2008/10/10(金) 01:20:54 AAS
>>497
補足ありがとう。

>>486の書き込みの問題点を考えてみると、Forthのリターンスタックは、
明らかに「WORDを積」んではいない。
WORDを積むという表現で想起されるのは、>>497の( あっち ) を積むという
ことだとForth使いは受け取るだろうから。
そして ( ここ ) や ( そこ ) は明らかに>>484の「次に実行する命令の列」を
指し示しているわけなので、何が新しいのかよくわからない、という感想に
なるのだと思う。

497(3): デフォルトの名無しさん [sage] 2008/10/10(金) 01:03:18 AAS
>>495
その言い方で言えば、（ここ）はbarのアドレスですね。
正確には、bazの定義の中のbarのアドレス。
>>490 での例を少し補って、

: foo dup + ;
: bar　( あっち ) dup * ;
: baz foo ( ここ ) bar ( そこ ) ;

と書けば、「barというワード自身」というのは（ あっち ）のことになる。

504(2): デフォルトの名無しさん [sage] 2008/10/10(金) 08:52:55 AAS
>>502
だから、「次に実行する命令列」は辞書の中に既にあるんであって、
それはスタックである必要はなくて、いってみればアレイ。
辞書の中で実行は動的に行ったり戻ったりするから、
やっぱりリターンアドレスの保存は必要。

509(1): 504 [sage] 2008/10/11(土) 01:03:24 AAS
>>508
つまり、ワードを全部インラインにするということ？
それなら確かに理論的には可能だし、リターンスタック自体要らない。
普通は、大きくなるのはスタックじゃなくて辞書だな。

まあ、辞書からインラインで展開したものを
リターンスタックにコピーしてもいいけど、
ランタイムにやるなら相当動作が遅くなると思う。
それに、
なぜそのためにスタックというデータ構造を使うのかがわからない。
後ろから先に積んでいくことになるわけだが。

その発想はインストラクションキャッシュだと思う。
だから、むしろキューがいいと思う。
ソフトウェア的にやると相当遅いとは思うけど、
論理的には可能だと思うよ。

59(3): デフォルトの名無しさん [] 04/02/19 17:08 AAS
人少ないなぁ。

第4問

: AA reverse ." AA" ;

: BB AA ." BB" ;

: CC BB ." CC" ;

でCCを実行すると

CCBBAA

を出力するようなreverseを定義すれ。

‥‥‥実はコレ第3問のヒントだったりする。

62(4): デフォルトの名無しさん [] 04/02/20 12:42 AAS
懲りずに第5問。

: foo
　　." 1 "
　　resume
　　." 2 "
　　resume
;

: bar
　　['] foo call/cc
　　." 3 "
　　resume
　　." 4 "
　　drop
;

で、barを実行すると、

1 3 2 4

と表示するような、resumeとcall/ccをがんがって定義してみれ。
ちなみに、この2つのワードは以下のスタックコメントに示すような
引数と返り値を持つものとする。

resume ( continuation -- continuation' )
call/cc ( xt -- continuation )

# ワード名とスタックコメントの名前がアレですが、
# 字面に惑わされなければ、仕様を満たすのは簡単なはず。
# 第３問〜第５問は基本的に同じカラクリ、というのがヒント。

513(1): デフォルトの名無しさん [sage] 2008/10/11(土) 05:37:05 AAS
464のやり方は、ありえなくはないけどForth的じゃないね。
どっちかっていうとJava　VMのJITコンパイラみたいな。

Forthはシンプルな実装で軽い、ってイメージ。

517(3): デフォルトの名無しさん [sage] 2008/10/11(土) 13:26:05 AAS
464のVMだが、
ハードウェアレベルではもう一般化してる
インストラクションのプリフェッチとおなじだよね。
マシン語のデコーダレベルでのVMという感じか。

実装する場合の最難題は条件付きジャンプだと思う。
IFとか不定ループをどう載せるかが鍵だな。
これを考えると、VMが仕組みとして単純になるかどうかは微妙だと思う。
まあ、ベタでやればできそうな気はするが、
ハードウエアの仕組みをソフトウェアで二重にしてるだけのような気がしないでもない。

520(1): 517 [sage] 2008/10/11(土) 13:59:32 AAS
もうすこし考えてみたんだが、
ワードがどこかで他のワードを呼び出し、そのワードがどこかで他のワードを呼出し...
という場合には、
ワードシーケンスに展開する段階で、
展開すべき個所をたどるためのリターンスタックが必要な気がする。

だから、464のVMは、
普通のForthでの実行と同じ動作でワード系列をコピーして、
それから順番にInterpretして実行するという感じになって、
単なる二度手間ではないかな。

522(1): 514 [sage] 2008/10/11(土) 18:35:01 AAS
>>518
普通はリターンスタックとか継続とか触れない言語の方が多いから、
Forthではなく俺言語を作るつもりなら、言語デザイナであるお前様自身の
判断で実現可能にしてもいいし、そうでなくしてもいいと思うよ。
ただForthは言語レベルでリターンスタックを操れる結果、協調的マルチタスクやら
コルーチンやら言語実装のレベルで普通対処するものも、ライブラリレベルで実現できる柔軟さがある。
リターンスタックは他の言語にはないForthの特徴の一つだからね。
俺言語でなんとか実現する方法を悩んでみるのも楽しいんじゃない？

524(1): 517 [sage] 2008/10/11(土) 21:01:10 AAS
>>521
いや、そうではなくて、
「WORDの動作」の中の、「普通のForthと同じ動作で」ってところに、
リターンアドレスを保存するスタックという意味でのリターンスタックが、もう必要なのではないかということ。

あと、言葉の問題として、
大きい意味でのワードを展開する動作のところからもうInterpreter（=VM）の動作というのが普通だと思う。
つまり、VMの動作の前半をWORDの動作と呼んで違う名前にしたから、
残ったVMの動作が簡単に見えるというだけなんじゃないかな。
辞書中のワードから始めると、ForthのVMよりも（多分プリミティブ）WORDの系列を作る部分が余分で、
より複雑になってると思う。

でも、自分の言語を作るのをやめろといってるんじゃないよ。
むしろ応援してる。

ちょっと話題はそれるけど、Forthというか、スタック指向言語は、
コンパイラライターフレンドリーなんだよね。
だから、Forthコード書くよりForth（風オレ言語）VMを書く人が多かったりするわけだが、
ホントはForthでアプリケーションを書くときも「オレ言語」を作るつもりで書くと良いと思ってる。

531(1): デフォルトの名無しさん [sage] 2008/10/12(日) 15:50:56 AAS
>>529
んー、やっぱり、思い込みでForthを理解したつもりになるんじゃなくて、
本格的に触ってみたほうが良いと思うんだけどな。

＞実行中のWORDの次のWORDを辞書の中から探せるようにする仕組みが必要
通常、Forthは実行時には、スレデッドコードにコンパイルされた命令列を、
上にも出ているnextルーチンで辿るだけなので、仕組みというほどの仕組みはないよ。

＞実行中のWORDの中身を変更するのが大変（VMのスタックに積んでいるWORD含む）
間接スレッディングのForthだと定義済みのワードの変更は、一カ所ポインタを書き換える
だけで済むはず。

＞番兵などの終了処理が必須
番兵というかワードの最後にnextルーチンへのジャンプかnextルーチン自身を書き込むだけ。

＞VM側に「WORDを実行する」という手順が必要になる
スレデッドコードのForthの命令列は、ワードへのポインタが並んでいるだけで、
「WORDを実行する」という意味のインストラクションは必要ないよ。