2 part forth (907ﾚｽ)
上下前次1-新
444: 2008/10/05(日)13:26 AAS
込み入った話は分からんけど、
とりあえずBF書けたらチューリング完全じゃなかったっけ？
445: 2008/10/05(日)14:12 AAS
なんか話が噛み合ってない気がする。
446: 2008/10/05(日)15:11 AAS
なんでそこまでチューリングマシンにこだわるのかわからん。
Forthがチューリングマシンであろうとなかろうと
Forthで実用的なプログラムは書ける。
あともう一人、やたらリターンスタックを排除したがる奴も
何をしたいのかさっぱりわからん。
447: 2008/10/05(日)17:47 AAS
まず当たり前の大前提の確認からだけど、Forthはチューリング完全だから。
仮にForthの仕様からリターンスタックだけを排除したとしても（それはForthとは呼べないだろうが）
チューリング完全だ。理由は>>442
リターンスタックがBPで代用できるとか正直意味わからん。
スタック演算自体理解してない希ガス。
448(1): 2008/10/05(日)18:27 AAS
リターンスタックという名前がいかんのだろ。
449: 2008/10/05(日)18:35 AAS
>>437
スタックオートマトンとスタックマシンをごっちゃにしてる気がする。
450: 2008/10/05(日)18:39 AAS
>>448
むしろリターンスタック以外の名前があるなら知りたいものだが。
451(2): 2008/10/05(日)19:02 AAS
>442
大雑把にはこんな感じかね。
・データスタック： 引数＆戻り値
・リターンスタック： 実行する命令列（辞書で展開された単語含む）
リターンスタックというよりもオーダースタックといった方がちょうど良い気がするけどね
452: 2008/10/05(日)19:25 AAS
リターンアドレスを積んでいるからリターンスタック
それでいいと思うが、難しく考えすぎじゃね？>>451
453(1): 2008/10/05(日)19:28 AAS
Aスタック←→Bスタック
だったら勘違いが起きなかったと思う。
454: 2008/10/05(日)19:34 AAS
>>453
むしろ勘違いを引き起こしそうなんだが。
リターンスタックが難しいんじゃなくて、
リターンアドレスをスタックに積むという
当たり前の関数呼び出し規約を説明しなければ、
理解されない時代になったということか…
455: 2008/10/05(日)21:59 AAS
なんでリターンスタックの名前で混乱とか勘違いがあるの？
ひょっとして、リターンと聞いて戻り値を連想しちゃう人がいる、とか？
だとしたらかなりキビシい状況だな。
456: 2008/10/06(月)01:09 AAS
カールスタックの方が一般的じゃね？
457: 2008/10/06(月)01:09 AAS
あ、カールじゃなくてコールスタック
458: 2008/10/06(月)01:24 AAS
カールはスナックだな
459: 2008/10/06(月)07:35 AAS
カールと言えば薄べったいのが出てることを最近知った。
従来品に比べて口の裏に張り付きにくいのはメリットだが、
少し物足りない気がした。
460: 2008/10/06(月)11:21 AAS
Forth では昔からリターンスタックと呼んできたので、その伝統に則ればいいと
思うんだけどな。Wikipedia だと項目はコールスタックで立てられているが。
461(1): 2008/10/06(月)12:10 AAS
コールスタック->カールスナック->コーンスターチ->張り付かないならカールじゃない
勉強し過ぎでしょう。
462: 461 2008/10/06(月)12:30 AAS
補：そもそもForthが一般的じゃない
463(4): 2008/10/06(月)21:49 AAS
・リターンスタックが普通のCPUで言うとことの「スタック」。
ワード（Ｃで言うところの関数、実際にはサブルーチン）
を呼ぶと呼び出し戻るためのアドレスを積む。
# 普通のCPUでCALL命令（68系だとBSR、JSR）を実行すると
# リターンアドレスがスタックに積まれるのは理解しているよね？
・データスタックってのは、言ってみれば「無限に増えるアキュムレータ」って感じ。
・「辞書」が命令コードストレージ、Ｃ言語でいえばTEXTセグメント
Forthの本質は上記３点をおさえて置けば理解できるんだが。
BPがリターンスタックと等価なんて言ってる人とか、
＞・リターンスタック： 実行する命令列（辞書で展開された単語含む）
＞リターンスタックというよりもオーダースタックといった方がちょうど良い気がするけどね
なんて言っている人、本当に理解できてるの？
464(18): 2008/10/07(火)00:25 AAS
>463
いや、別にWORDがサブルーチンである必要はないんじゃない？WORD毎の環境要らないんだし。
Cとの相性を考えるとサブルーチンにした方が良いと思うけど。
あと、CPUのアーキテクチャには疎いんだけど、最近のCPUでスタック持ってるのってあったっけ？
465(1): 2008/10/07(火)06:15 AAS
x86アーキテクチャには思いっきりスタックポインタがありますが？
>>464のいう「最近のCPU」が非ノイマンアーキテクチャとかを指すなら
スタックがないCPUもあるかも知れないけど。
466: 2008/10/07(火)06:37 AAS
>>464
前半は実装と仕様が混乱してそう。
後半は、たぶん、CPUの「レジスタアーキテクチャ」「スタックアーキテクチャ」と
データ構造としてのスタックを混同している。
Wikipediaやblog読んで理解した気にならないで実際に自分で手を動かしてみなよ。
ちょっと恥ずかし過ぎるぞ、あんた。
467(1): 2008/10/07(火)12:34 AAS
>>464 の言ってる「スタック」はハードウェアスタックのことと思われる。
>>463 の
「データスタックってのは、言ってみれば「無限に増えるアキュムレータ」って感じ。」
ってのは、確かにハードウェアスタックを思わせる記述だが。
468(1): 2008/10/07(火)13:28 AAS
post,preのincやdec付きレジスタ間接参照命令があればデータスタックと等価だよね？
リターンスタックってのはサブルーチンコール時に戻りアドレスをpushする為のレジスタの事でしょう？
なら今時のCPUで無い物の方が珍しいと思うんだけど
469(1): 2008/10/07(火)20:49 AAS
x86って俺の生まれる前からあるな。
定年過ぎた方には最近なんでしょうけど。
470: 2008/10/07(火)21:09 AAS
定年過ぎて無く立ってプロセッサ自体３０年の歴史しかないじゃないか
471: 2008/10/07(火)21:36 AAS
最近のCPUは古いアーキテクチャのものがほとんどだよね。
細かいところは違うんだろが。
>>468
>戻りアドレスをpushする為のレジスタ
レジストリって意味？
RISCだと、戻りアドレスを保存するレジスタがあること多いよね。
まあ、リターンスタックは、
リターンアドレスを積むため専用（原則）のスタック
ってことがわかれば、いいじゃない。
データスタックと別にある利点もわかってるわけでしょ。
本当は「リターンスタックがあること」じゃなくて、
データスタックが複数のワードを横断して固定されていること、
の方が特徴だよね。
普通の言語の実装だと、
データスタックがサブルーチンごとに別々にリターンスタックの中にあって、
受け渡すデータはコピーする、
という感じなわけだ。比喩的に言えば。
アセンブリレベルでもリターンアドレスのpush/popが自動になってるなら、
気付かない人がいてもしょうがない。
472(3): 464 2008/10/07(火)23:32 AAS
>465
いや、スタックポインタ（レジスタ）じゃなくてスタック。>467 の通りですな。>463で『アドレスを積む』とか
書いているからHWスタックのことかと思った。
スタックを内部に持つCPUの話があった記憶があったので勘違いしたわ。すまんね。
forthあんまり詳しくないんで済まんのだけど、『リターンスタックには、ワードを呼ぶと呼び出し戻るため
のアドレスを積む』んだっけ？
正規化の観点からは『まだ実行していないWORD』もリターンスタックに積めた方が便利だと思うけど。
WORDコンパイルの実装で手が抜けなくなるし……
473(2): 2008/10/07(火)23:56 AAS
>>472
意味が理解できん。
「まだ実行してないWord」を積む、って具体的に何を積むの？
まだ実行してないワードのアドレスなら辞書に入ってると思う（関節スレッディングの場合）
474: 2008/10/08(水)04:22 AAS
>>469
いまでも現役バリバリで使われていて
マイクロソフトの最新OS「ＶＩＳＴＡ」がポーティングされる
x86アーキテクチャが「最近のCPU」では無いとでも？
あるいはCore2DUOとかがX86アーキテクチャじゃないとでも思ってる？
475: 2008/10/08(水)06:31 AAS
>>472
Forthと関係なく、関数の呼び出し元に戻るためにアドレスをスタックに積む、
という動作は、アセンブリレベルでは普通の関数呼び出し規約。
Forthは言語レベルでリターンスタックを操作できる言語だけど、
普通は意識しなくてもいいから、リターンアドレスが何のために存在しているのか
理解できない人がいても不思議じゃないけど、せめてもう少し自分で勉強して欲しい。
476: 2008/10/08(水)06:35 AAS
＞forthあんまり詳しくないんで済まんのだけど、
とか、逃げをうたず自分で触ってみろよ。
477(1): 2008/10/08(水)14:37 AAS
441だけど盛り上がってるね。
自分なりのまとめ。
リターンスタックはBPとcall/retの役割がある。
call/retを他の命令で書くと
・関数の呼び出し
push $LNEXT
jmp func
$LNEXT:
・関数のret
pop ecx ; $LNEXTのアドレスがecxに入る
jmp [ecx]
・関数のはじめ
push ebp
mov ebp, esp
・関数のおわり
mov esp, ebp
pop ebp
こうなる。
つまりBPはリターンスタックのトップと同じ。
BPを基点にすればデータスタックだけでも同じ事ができる。
「ボクが考えたforth」ではリターンスタックは必要ない。
478: 2008/10/08(水)18:17 AAS
>>441=477
それを実際に作って発表したら
いままで君をバカにしていた連中にギャフンと言わせられるよ。
ガンバ。
479(1): 2008/10/08(水)18:47 AAS
で、その「ボクが考えたforth」では、
パラメタはどうやって渡すんだ？
480: 2008/10/08(水)19:05 AAS
どう考えても普通にCALL/RETした方が速そうだけど
わざわざ面倒くさくしてどうするの？
あと、ENTER/LEAVEとか使わないの
481: 2008/10/08(水)21:00 AAS
>>477
もはやどこから突っ込んで良いものやら…
二つほど疑問が。
一つ目。
>>479も言ってるけれど、その実装だとパラメタの受け渡しが面倒そうなのだが。
たとえば、その実装方法で、
: foo drop drop 3 4 5 ;
1 2 foo
としたときにスタックがどのように変化していくのか書いてみてくれ。
解決方法を考えられなくもないが、たぶん独立したリターンスタックが
あるほうがシンプルだと思われ。
二つ目。
リターンスタックを操作する命令はどうやって実装するの？
これも独立したリターンスタックがあるほうがシンプルだと思われ。
forthじゃない何かをつくろうとしているのだろうか？
482: 2008/10/08(水)21:16 AAS
二つ目用の問題も書いておくよ。
: bar 1 2 3 >r >r 1 + r> r> ;
483: 2008/10/08(水)23:38 AAS
混乱してるようだから、
まず、ネイティブの場合とスレッディングの場合を分けて考えた方がいい。
ネイティブForthで自然な実装では、
SP=リターンスタックポインタ(RSP)
BP=データスタックポインタ(DSP)
となってる。
UNIX/Cの普通のスタックを知ってれば、機能的な対応は明瞭なはず。
リターンスタックが伸びても、DSPは別フレームに移らないのがForthのポイント。
ちなみに、Forthでも局所変数が使えるヤツがあって、
その局所変数には、リタースタック中にフレームを作って割り当てるのが普通。
これも、標準のスタックがわかってれば意味は明瞭。
スレッディング（直接・間接）方式だと、
呼出しはCallじゃないから、
BPをRSPにしてもかまわんが、
パラメタとリターンアドレスの混合は、
Forthでは無謀。動的にチェックが必要な上に、完璧にはできそうにない。
484(1): 464 2008/10/09(木)01:15 AAS
446です。
forthは興味半分で使ったレベルでしかないですね……
concatenative俺言語の設計の参考にしているぐらいです。
>473
リターンスタックを「次に実行する命令の列」という形に抽象化すると、「現在処理中のWORD」と
「ソースコードを解釈したWORD」「Dictionaryに保持されているWORD列」…つまり呼び出されて
いないWORDを対称（等価／交換可能）に扱うことができるようになるので、バーチャルマシンの
構造を簡単化することができるかと思います。
……forthで許されているのかしらんけど。
485(1): 2008/10/09(木)06:24 AAS
リターンスタックに積んであるリターンアドレスは、
「これから実行される命令列」へのポインタそのものと見なせるから、
そのアイデアが新しいとは思えないけどな。
Forthぐらいバーチャルマシンの実装が簡単な言語もないし。
ただ、リターンスタックの意味がよくわからないままに、
他の言語のように抽象構文木を再帰的に処理するような
実装にしていると、リターンスタック操作の実装で悩むの
かもしれない。
486(2): 464 2008/10/09(木)08:54 AAS
>485
>463は呼び出したWORDを積むことを前提にしているし、>451 >472で言ってるのが >463 >473で
思い切り否定されてるので、forthじゃそういう考え方無いのかな、と思った。
もしforthでもそういう使い方しているんだったらおいらの不勉強だね。
487: 2008/10/09(木)10:46 AAS
>>486
485のいってる意味は、
スレッディング方式のforthでは、
辞書は実行されるワードのポインタのリストとみなせるわけで、
リターンアドレスというのは、辞書内への戻りアドレス、
つまり、これから実行されるワードのリストへのポインタといえる
ということと思われる。
ワードのポインタを直接リターンスタックに積み込むような、
インストラクションキャッシュみたいな仕様のリターンスタックの実装は、
ちょっと聞いたことが無い。
というかそれじゃリターンスタックじゃない。
488(2): 2008/10/09(木)20:52 AAS
487の言わんとすることを俺なりに解釈してみる…
: foo dup + ;
: bar foo drop ;
bar の処理中に foo を実行するときに、
foo の次の drop のアドレスをリターンスタックに積む。
それで、foo の実行終了時にリターンアドレスから戻り先を取る。
これが、さっき積んだ drop のアドレスということ。
で、「drop のアドレス」っていうのを「ポインタ」と呼んでいる。
489: 2008/10/09(木)21:08 AAS
fooが呼ばれたときのリターンアドレスは 「dropのアドレス」というより
「dropの直前のアドレス」だ。
微妙なニュアンスに聞こえるかもしれないが。
: bar foo ( ここ ) drop ;
( ここ ) と書いた部分に戻ってくる。
490(1): 2008/10/09(木)21:12 AAS
: foo dup + ;
: bar dup * ;
: baz foo ( ここ ) bar ( そこ ) ;
foo が呼ばれたときリターンスタックには( ここ )が積まれてる。
bar が呼ばれたときリターンスタックには( そこ )が積まれてる。
bar というワード自身がリターンスタックに積まれているのではない。
491(1): 2008/10/09(木)21:16 AAS
ついでに >>56 のリターンスタックを使ったパズルの説明でも書いておこう。
問題は、
: foo twice ." Hello" ;
で、
HelloHello
を出力する twice を定義しろというパズル。
492: 2008/10/09(木)21:22 AAS
解答は、
: twice r> dup >r >r ;
何が起きているか説明すると、twice が呼ばれたとき、リターンスタックには、
: foo twice ( ここ ) ." Hello" ;
上の( ここ )が積まれている。
twice は最初に r> を実行して、( ここ ) をリターンスタックからデータスタックに移している。
次の dup で ( ここ ) がデータスタックに二つ積まれた状態になる。
最後に、 二つの >r で ( ここ ) が二つリターンスタックに戻される。
493: 2008/10/09(木)21:27 AAS
さて、定義されたワードの終端に到達したので Forthは、
リターンスタックからリターンアドレスを一つ取り出してそこに戻ろうとする。
: foo twice ( ここ ) ." Hello" ;
↑これの ( ここ )に戻ってくるわけだね。
そして、Helloを出力する。
そしてまた定義されたワードの終端に到達するので、Forth は
リターンスタックからリターンアドレスを一つ取り出してそこに戻ろうとするわけだ。
つまり、もう一度 ( ここ ) に戻る。
もう一度、Helloが出力されたら、次にリターンスタックからpopされる
リターンアドレスは foo を呼び出したアドレスなので、ここでようやく、
foo の実行が終了することになる。
494: 2008/10/09(木)21:29 AAS
リターンスタックに積まれているリターンアドレスは、
次に実行すべきワード単体ではなくて、
それ以降、実行すべきコード全体の先頭を指し示すアドレスだ、
と、理解できたかしらん？
495(2): 488 2008/10/10(金)00:34 AAS
（ここ） は分かってるつもりなんですが、
メモリアドレス的に的確に伝えるには難しいような気が。。。
: baz foo ( ここ ) bar ( そこ ) ;
16bitアドレス環境として、スレデッドコードで考えると、
（ここ）は foo のアドレスと同じか、それとも +1 でしょうか？
# foo のアドレス +2 すると bar のアドレスですよね
なんかアホなこと言っているようですみません。
496(3): 2008/10/10(金)00:55 AAS
>>495
「barのアドレス」と書くとbazの定義の中のbarの呼び出しのあるアドレスなのか、
それともbar自身の定義のアドレスなのか混乱するから、
( ここ ) と表現したわけで、その違いがわかってるなら問題ないですよん。
あとポインタってわかるよね？
497(3): 2008/10/10(金)01:03 AAS
>>495
その言い方で言えば、（ここ）はbarのアドレスですね。
正確には、bazの定義の中のbarのアドレス。
>>490 での例を少し補って、
: foo dup + ;
: bar ( あっち ) dup * ;
: baz foo ( ここ ) bar ( そこ ) ;
と書けば、「barというワード自身」というのは（ あっち ）のことになる。
498(1): 496 2008/10/10(金)01:20 AAS
>>497
補足ありがとう。
>>486の書き込みの問題点を考えてみると、Forthのリターンスタックは、
明らかに「WORDを積」んではいない。
WORDを積むという表現で想起されるのは、>>497の( あっち ) を積むという
ことだとForth使いは受け取るだろうから。
そして ( ここ ) や ( そこ ) は明らかに>>484の「次に実行する命令の列」を
指し示しているわけなので、何が新しいのかよくわからない、という感想に
なるのだと思う。
499(1): 464 2008/10/10(金)01:36 AAS
>498
新しいかどうかなんて知らんよ。単にWORDの扱いを正規化できてVMが簡素になるっつうだけの話。
>497で言及している(ここ)(そこ)みたいな間接ポインタをVMで扱う必要も無くなるし。
まあ、その皺寄せをWORDに押し込んでるだけなんだけどね。
500(1): 496 2008/10/10(金)01:42 AAS
>>499
なんていうか…
「(ここ)(そこ)みたいな間接ポインタ」というそれそのものが、
アセンブリ言語の時代からある「リターンアドレス」という概念なんですよ…。
Forthはそれをリターンスタックに分離して保存・復帰しているだけのこと。
501(1): 2008/10/10(金)06:35 AAS
>>491
>そして、Helloを出力する。
. "Hello"
がなんでHelloを出力することになるの？
"Hello" .
じゃないのはなんで？
文字列リテラルは特別扱い？
502(1): 2008/10/10(金)08:32 AAS
>500
今は実際のリターンアドレスの話をしとらんよ。
リターンスタックを「次に実行する命令の列」という形に抽象化するっつうとるだろうに。
503(1): 2008/10/10(金)08:46 AAS
>>501
." とか、 前付きの " は、Forthではただの引用符じゃなくて、一つのワード。
だから、Helloとの間に空白が要る。
但し、終わりの " はセパレーターだから、空白なしで良い。
前にも出てたけど、
Forthでは文字列リテラルはポインタと長さの二つの数値で表す。
「.」は、トップアイテムを一つpopして値をプリントするワードだから、
" Hello" .
だと5がプリントされるだけ。文字列ポインタがスタックに残る。
「."」 が 「次の " までの文字列をプリントする」というワード。
文字列をスタックに積んだときは
" Hello" type
とやる。
504(2): 2008/10/10(金)08:52 AAS
>>502
だから、「次に実行する命令列」は辞書の中に既にあるんであって、
それはスタックである必要はなくて、いってみればアレイ。
辞書の中で実行は動的に行ったり戻ったりするから、
やっぱりリターンアドレスの保存は必要。
505: 2008/10/10(金)09:06 AAS
>>503
＞「."」 が 「次の " までの文字列をプリントする」というワード。
なんじゃそら
ﾜﾛﾀ
506: 2008/10/10(金)17:24 AAS
factorだと文字列リテラルはあるよ
507: 488 2008/10/10(金)22:08 AAS
>>496,497 サンクス
スレデッドコードと書いておいて誤解がなかったようだ。
497 のレスだと、俺の中では「次のワード」という認識になる。
（あっち）という表現を使えば確かに誤解はなくなる。
なんだか、リターンスタックのデータ内容と、
（サブルーチン）リターンアドレスを混同した希ガス
508(1): 464 2008/10/11(土)00:37 AAS
>504
「必要がないから積まない」じゃなくて、「VMの原理を簡単にするために積む」んだって。
VMが辞書の中を行ったり来たりしないようにするのが目的。
もちろん、VMの仕事をWORDに移管しただけの話だし、スタックが大きくなるデメリットもあるけどな。
509(1): 504 2008/10/11(土)01:03 AAS
>>508
つまり、ワードを全部インラインにするということ？
それなら確かに理論的には可能だし、リターンスタック自体要らない。
普通は、大きくなるのはスタックじゃなくて辞書だな。
まあ、辞書からインラインで展開したものを
リターンスタックにコピーしてもいいけど、
ランタイムにやるなら相当動作が遅くなると思う。
それに、
なぜそのためにスタックというデータ構造を使うのかがわからない。
後ろから先に積んでいくことになるわけだが。
その発想はインストラクションキャッシュだと思う。
だから、むしろキューがいいと思う。
ソフトウェア的にやると相当遅いとは思うけど、
論理的には可能だと思うよ。
510: 2008/10/11(土)02:00 AAS
サンクス >693
５ ソースコード
６ ｂｏｏｓｔ：：ｓｐｉｒｉｔ
というので激しく不安になるな。
というか、スクリプトの入門というのなら、ＢＡＳＩＣタイプ言語の作成とかＣタイプ言語の作成
とか分散しないで、どっちか一つに集中すべきじゃない？
入門だったら、むしろ構文はシンプルなforthライクにして、エンジンの中身に拘るべきだと思うけど……
511: 2008/10/11(土)02:02 AAS
誤爆スマソ
512: 464 2008/10/11(土)02:18 AAS
>509
いや、基本はWORD呼び出し時に展開（そのWORDに定義されたWORD列をスタックに押し込む）。
WORDコンパイル時に全部インラインに展開するわけじゃないです。
＃高速化を目的として、WORDコンパイル時にある程度はインライン化することになると思うけど。
WORDに定義されたWORD列を、実行時にその場で積んでその場で処理する必要があるから、
FIFOの仕組みが必要になります。
まあ、小まめにWORDの積み降ろしをやらなきゃいけないから、確かに重そうだけどね。
513(1): 2008/10/11(土)05:37 AAS
464のやり方は、ありえなくはないけどForth的じゃないね。
どっちかっていうとJava VMのJITコンパイラみたいな。
Forthはシンプルな実装で軽い、ってイメージ。
514(5): 2008/10/11(土)06:54 AAS
>>464のやり方だと実行の度にリターンスタックに命令列のコピーが発生するわけだな。
対して普通のForthはリターンアドレス一つのコピーで済む。
Forthでは関数の戻り場所を実行時に入れ替えたりできる( >>59 >>62 ) わけだけど、
>>464のやり方だと命令列自体の入れ替えになるから相当面倒。
Forthの自由度をわざわざ減らしている気がするんだけどな。
でも作るというならがんがれ。
様々な進化があってこそ発展もある。
515: 464 2008/10/11(土)13:07 AAS
>513
いや、実装はこっちの方がシンプルだよ。辞書の解釈を全部WORDに押し付けることができるから。
ただ、スタック操作が増えるから重くなる方向だけどね。
>514
リターンアドレス前提だと難しいよね。作業用スタックがもう一本ありゃいいんだけど。
俺言語のVMだと自前スタックで実装しているので大した話じゃないです。
516: 464 2008/10/11(土)13:22 AAS
>514
ちょっと補足。
複数のWORDを押し込もうとすると確かに面倒だね。
俺言語でも
1. 無名WORDを作る
2. 1.のWORDに実行するWORDを押し込む
3. 1.のWORDをリターンスタックに押し込む
といったパック化が必要になります。
517(3): 2008/10/11(土)13:26 AAS
464のVMだが、
ハードウェアレベルではもう一般化してる
インストラクションのプリフェッチとおなじだよね。
マシン語のデコーダレベルでのVMという感じか。
実装する場合の最難題は条件付きジャンプだと思う。
IFとか不定ループをどう載せるかが鍵だな。
これを考えると、VMが仕組みとして単純になるかどうかは微妙だと思う。
まあ、ベタでやればできそうな気はするが、
ハードウエアの仕組みをソフトウェアで二重にしてるだけのような気がしないでもない。
518(1): 464 2008/10/11(土)13:38 AAS
>514
思い出した……>59を実現するにはreverse自体のパック化も必須なんだっけ。
そういや>59みたいな操作をどうしようか悩んだな。
ただ、こういったWORDを跨ぐ暗黙的なリターンスタック制御てけっこう危険じゃない？
個人的にはWORDはデータスタックの状態にのみ依存すべきだと思うけど、WORDを越えた
範囲までリターンスタックを操作できるようにすると、WORD同士の依存関係が出てしまって
連鎖性(concatenative)が崩れるような気がする。
forthの条件分岐でも、セパレーターを使った明示的な制御をしているわけだし。
519: 464 2008/10/11(土)13:49 AAS
連投スマソ
>517
そうか、CPUだともう一般的なのか……。さすがに天才的な変態が集まる業界だな。
やっぱりCPUのアーキテクチャ勉強しないといけないなあ。
IFは構文解析で逃げました。
block := block ? WORD1 ! WORD2
という三項演算子を用意して、条件分岐用WORDに解釈するようにしました。
不定ループの構文を用意するかどうかは検討中です。
520(1): 517 2008/10/11(土)13:59 AAS
もうすこし考えてみたんだが、
ワードがどこかで他のワードを呼び出し、そのワードがどこかで他のワードを呼出し...
という場合には、
ワードシーケンスに展開する段階で、
展開すべき個所をたどるためのリターンスタックが必要な気がする。
だから、464のVMは、
普通のForthでの実行と同じ動作でワード系列をコピーして、
それから順番にInterpretして実行するという感じになって、
単なる二度手間ではないかな。
521(1): 464 2008/10/11(土)15:30 AAS
>520
どのみちリターンスタック（実行する命令列を保存する専用スタック）が必要なのはその通り。
WORDの動作：普通のForthでの実行と同じ動作でワード系列をコピー
VMの動作： 順番にInterpretして実行する
というところがポイントですな。VMは辞書のこととか考える必要がないのでシンプルになります。
その代わり「辞書からWORD列を拾ってリターンスタックに展開する」というWORDが必要になるけど。
確かにコピーする手間はムダな気もするんだけどね……
辞書のWORD列を直接トレースするのと比べてどんぐらい余計な手間がかかってるんだろう？
ポインタ操作数回＆アクセス数回レベルだと思うけど。
522(1): 514 2008/10/11(土)18:35 AAS
>>518
普通はリターンスタックとか継続とか触れない言語の方が多いから、
Forthではなく俺言語を作るつもりなら、言語デザイナであるお前様自身の
判断で実現可能にしてもいいし、そうでなくしてもいいと思うよ。
ただForthは言語レベルでリターンスタックを操れる結果、協調的マルチタスクやら
コルーチンやら言語実装のレベルで普通対処するものも、ライブラリレベルで実現できる柔軟さがある。
リターンスタックは他の言語にはないForthの特徴の一つだからね。
俺言語でなんとか実現する方法を悩んでみるのも楽しいんじゃない？
523: 514 2008/10/11(土)18:47 AAS
あとForthのVMって相当シンプルだよ。
アセンブリ言語で書かれた昔のForthとかコアの部分はアセンブリ言語で数行レベルだった気がする。
どのへんが複雑だと思ったのかは興味がある…
524(1): 517 2008/10/11(土)21:01 AAS
>>521
いや、そうではなくて、
「WORDの動作」の中の、「普通のForthと同じ動作で」ってところに、
リターンアドレスを保存するスタックという意味でのリターンスタックが、もう必要なのではないかということ。
あと、言葉の問題として、
大きい意味でのワードを展開する動作のところからもうInterpreter（=VM）の動作というのが普通だと思う。
つまり、VMの動作の前半をWORDの動作と呼んで違う名前にしたから、
残ったVMの動作が簡単に見えるというだけなんじゃないかな。
辞書中のワードから始めると、ForthのVMよりも（多分プリミティブ）WORDの系列を作る部分が余分で、
より複雑になってると思う。
でも、自分の言語を作るのをやめろといってるんじゃないよ。
むしろ応援してる。
ちょっと話題はそれるけど、Forthというか、スタック指向言語は、
コンパイラライターフレンドリーなんだよね。
だから、Forthコード書くよりForth（風オレ言語）VMを書く人が多かったりするわけだが、
ホントはForthでアプリケーションを書くときも「オレ言語」を作るつもりで書くと良いと思ってる。
525(1): 2008/10/11(土)21:33 AAS
Forthの用語って独特な言い回しがあるからな。
知らない人は結構混乱する。
スレデッドコードのForthの場合、ソースコードを解釈してスレデッドコードを
生成することをコンパイルといい、スレデッドコードを生成する部分を外部インタープリタ、
スレデッドコードを解釈実行する部分を内部インタープリタと呼ぶ。
（これで良かったよな？同志？）
このスレでVMと言った時に内部インタープリタだけなのか、外部インタープリタも含むのか？
どっちだろうか？
526: 2008/10/12(日)00:45 AAS
>>525
テキストを読み込んで、
1) ワードを辞書内で特定
2) だめならリテラルに変換
3) ダメならエラーで終了。
という部分が外部インタープリタ
1)または2)で成功したときに
モードに応じてコンパイル（Forth的意味）するか実行する
のが内部インタープリタ
だと思ってました。
Forthはテキストインプットも弄れるという面白さもあるよね。
Forth VMというと、外部も含むのかな。
上のリターンスタック云々の話は、
内部インタープリタのことだと思うけど。
527: 2008/10/12(日)07:57 AAS
内部インタプリタて（スレッドコードで実装してる場合は）nextルーチンのことじゃなかったっけ。
528: 2008/10/12(日)08:49 AAS
そうNEXTルーチン。アセンブリ言語で数行、という奴。
529(1): 464 2008/10/12(日)15:10 AAS
>522
その辺は「自由と責任」というやつですな。「銃で足をブッとばす自由」でもあるけど。
>どのへんが複雑だと思ったのかは興味がある…
自分でも何でだったっけな、と過去の記憶を探り出してみたけど、
・実行中のWORDの次のWORDを辞書の中から探せるようにする仕組みが必要
×実行中のWORDの中身を変更するのが大変（VMのスタックに積んでいるWORD含む）
×番兵などの終了処理が必須
--> VM側のスタックに積むことにすればpop&top参照で正規化できるし、元の値を
コピーするからWORD変更にも影響されない。
・VM側に「WORDを実行する」という手順が必要になる
--> VM側のスタックに積むことにすればpushで正規化できる
ぐらいかもしれない。
コンパイル時にWORDの中身が確定するforthだとあんまり問題にならなそうだね。
530: 464 2008/10/12(日)15:20 AAS
>524
「スタックに複数のデータを押し込む操作は機械語レベルだとアトミックにならない」ということ？？
C++で実装しているから意識していなかったけど、そうかもしれないですね。
少なくともプリミティブで実装する必要あるね。
>ForthのVMよりも（多分プリミティブ）WORDの系列を作る部分が余分で、
これは狙ってやっていることだから仕様がないですね。
まあ、俺言語ではVM自体もWORD扱いにしているのですが……
531(1): 2008/10/12(日)15:50 AAS
>>529
んー、やっぱり、思い込みでForthを理解したつもりになるんじゃなくて、
本格的に触ってみたほうが良いと思うんだけどな。
＞実行中のWORDの次のWORDを辞書の中から探せるようにする仕組みが必要
通常、Forthは実行時には、スレデッドコードにコンパイルされた命令列を、
上にも出ているnextルーチンで辿るだけなので、仕組みというほどの仕組みはないよ。
＞実行中のWORDの中身を変更するのが大変（VMのスタックに積んでいるWORD含む）
間接スレッディングのForthだと定義済みのワードの変更は、一カ所ポインタを書き換える
だけで済むはず。
＞番兵などの終了処理が必須
番兵というかワードの最後にnextルーチンへのジャンプかnextルーチン自身を書き込むだけ。
＞VM側に「WORDを実行する」という手順が必要になる
スレデッドコードのForthの命令列は、ワードへのポインタが並んでいるだけで、
「WORDを実行する」という意味のインストラクションは必要ないよ。
532: 464 2008/10/12(日)23:25 AAS
本格的に触るのは……あの構文は色々と嫌だ。
[条件] IF [肯定時] ELSE [否定時] THEN とか。
せめて条件算子的だったらなぁ。[条件] ? [肯定時] : [否定時] ;
>531
細かいことを言うと、nextルーチンが辞書内のスレッデッドコード構造の詳細を知らなきゃ
ならないので、VMと辞書の関連が密になりそうな気がします。スレッデッドコードをスタックに
pushしてVM内に取り込んじゃえば辞書内の構造を気にする必要無いし。
まあ、最適化のために作り込んでも良い気がするけどね。そこは将来の課題ということで。
>一カ所ポインタを書き換えるだけで済むはず。
WORD自体を置換する場合はそうですね。WORDの挿入や削除はたぶん難しいかと。
そんな特殊なことは禁止にして、新規にWORD定義させた方が良いかも知れないけど。
あるいは無名WORDとかスキップWORDを用意するとか。
>「WORDを実行する」という意味のインストラクションは必要ないよ。
あれ？VMに保存されている「現在実行中のWORD」って、間接ポインタじゃないの？
（nextの動作を考えると、間接ポインタじゃないと色々と面倒臭そうな）
実行前に間接参照からWORDを探す操作が一段余計に必要になるかと思ってた。
533(1): 2008/10/12(日)23:34 AAS
＞VMと辞書の関連が密
というか、それがFORTHの肝のような気がする。
534: 2008/10/13(月)00:16 AAS
スレデッドコード自体、ワードへのポインタを並べたものでしかないから、
ジャンプとかコールとかそういう類のインストラクションをデコードする必要がない、
という意味ね。
あとForthの実装にはダイレクトスレデッドなものもあるよ。
nextルーチンからみると命令列を順に辿ってるだけであって、
「辞書からワードを毎回探している」ってわけじゃないしね。
それより、スタックに命令列を毎回pushするオーバーヘッドのほうがよほど大きいと思うし、
nextルーチンに比べてシンプルとも思えないんだな。
ま、いろいろ悩んで勉強して、これだ！と思える言語デザインに邁進してください、と。
このスレが本当に久しぶりに活性化したのは間違いないしね。
535: 2008/10/13(月)00:21 AAS
>>533
間接スレデッドの場合、Forthコンソールの側から見ると、
逆コンパイルしやすかったり、便利な面はたしかにあるけれど、
VMつうかnextルーチンから見ると、単にポインタを辿っているだけなので、
構造として、VM実装と辞書構造が密、というわけでもないと思う。
実際VM実装テクニックとしてのスレデッドコードは、今や、Forth以外でも
当たり前の技術になってるし。
536: 2008/10/27(月)00:52 AAS
jonesforth読んだ。
ソース付きなので理解しやすい。
OS Xで動かそうとしたが挫折した。
OSXのGASではマクロが対応してないみたいだ。
537: 2008/11/23(日)01:13 AAS
急にスレが進んだと思ったら、止まるのも急だよなこのスレ
やっぱ誰も使ってないってこったな
538: 2008/11/26(水)17:30 AAS
http://www.intellasys.net/index.php?option=com_frontpage&Itemid=64
なんか並列forthマシンっぽいｗ
539(1): 2008/12/27(土)14:00 AAS
factor使ってる奴いる？
540: 2008/12/27(土)21:13 AAS
とりあえず入れてみたけど特に使ってないなｗ
541: 539 2008/12/28(日)01:26 AAS
factorおもしろいぜ。デプロイするとスタンドアロンで動く物もできるし。
542: 2008/12/29(月)13:31 AAS
やっぱだめだこの言語。
人間工学から著しく反してる。
543: 2008/12/29(月)19:52 AAS
サルが人間工学語ってやがる。
上下前次1-新書関写板覧索設栞歴
あと 364 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.023s