2 part forth (907ﾚｽ)
2 part forth http://mevius.5ch.net/test/read.cgi/tech/1073673931/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
464: デフォルトの名無しさん [sage] 2008/10/07(火) 00:25:52 >463 いや、別にWORDがサブルーチンである必要はないんじゃない？WORD毎の環境要らないんだし。 Cとの相性を考えるとサブルーチンにした方が良いと思うけど。 あと、CPUのアーキテクチャには疎いんだけど、最近のCPUでスタック持ってるのってあったっけ？ http://mevius.5ch.net/test/read.cgi/tech/1073673931/464
465: デフォルトの名無しさん [sage] 2008/10/07(火) 06:15:51 x86アーキテクチャには思いっきりスタックポインタがありますが？ >>464のいう「最近のCPU」が非ノイマンアーキテクチャとかを指すなら スタックがないCPUもあるかも知れないけど。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/465
466: デフォルトの名無しさん [sage] 2008/10/07(火) 06:37:45 >>464 前半は実装と仕様が混乱してそう。 後半は、たぶん、CPUの「レジスタアーキテクチャ」「スタックアーキテクチャ」と データ構造としてのスタックを混同している。 Wikipediaやblog読んで理解した気にならないで実際に自分で手を動かしてみなよ。 ちょっと恥ずかし過ぎるぞ、あんた。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/466
467: デフォルトの名無しさん [sage] 2008/10/07(火) 12:34:16 >>464 の言ってる「スタック」はハードウェアスタックのことと思われる。 >>463 の 「データスタックってのは、言ってみれば「無限に増えるアキュムレータ」って感じ。」 ってのは、確かにハードウェアスタックを思わせる記述だが。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/467
472: 464 [sage] 2008/10/07(火) 23:32:13 >465 いや、スタックポインタ（レジスタ）じゃなくてスタック。>467 の通りですな。>463で『アドレスを積む』とか 書いているからHWスタックのことかと思った。 スタックを内部に持つCPUの話があった記憶があったので勘違いしたわ。すまんね。 forthあんまり詳しくないんで済まんのだけど、『リターンスタックには、ワードを呼ぶと呼び出し戻るため のアドレスを積む』んだっけ？ 正規化の観点からは『まだ実行していないWORD』もリターンスタックに積めた方が便利だと思うけど。 WORDコンパイルの実装で手が抜けなくなるし…… http://mevius.5ch.net/test/read.cgi/tech/1073673931/472
484: 464 [sage] 2008/10/09(木) 01:15:39 446です。 forthは興味半分で使ったレベルでしかないですね…… concatenative俺言語の設計の参考にしているぐらいです。 >473 リターンスタックを「次に実行する命令の列」という形に抽象化すると、「現在処理中のWORD」と 「ソースコードを解釈したWORD」「Dictionaryに保持されているWORD列」…つまり呼び出されて いないWORDを対称（等価／交換可能）に扱うことができるようになるので、バーチャルマシンの 構造を簡単化することができるかと思います。 ……forthで許されているのかしらんけど。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/484
486: 464 [sage] 2008/10/09(木) 08:54:40 >485 >463は呼び出したWORDを積むことを前提にしているし、>451 >472で言ってるのが >463 >473で 思い切り否定されてるので、forthじゃそういう考え方無いのかな、と思った。 もしforthでもそういう使い方しているんだったらおいらの不勉強だね。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/486
499: 464 [sage] 2008/10/10(金) 01:36:27 >498 新しいかどうかなんて知らんよ。単にWORDの扱いを正規化できてVMが簡素になるっつうだけの話。 >497で言及している(ここ)(そこ)みたいな間接ポインタをVMで扱う必要も無くなるし。 まあ、その皺寄せをWORDに押し込んでるだけなんだけどね。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/499
508: 464 [sage] 2008/10/11(土) 00:37:41 >504 「必要がないから積まない」じゃなくて、「VMの原理を簡単にするために積む」んだって。 VMが辞書の中を行ったり来たりしないようにするのが目的。 もちろん、VMの仕事をWORDに移管しただけの話だし、スタックが大きくなるデメリットもあるけどな。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/508
512: 464 [sage] 2008/10/11(土) 02:18:22 >509 いや、基本はWORD呼び出し時に展開（そのWORDに定義されたWORD列をスタックに押し込む）。 WORDコンパイル時に全部インラインに展開するわけじゃないです。 ＃高速化を目的として、WORDコンパイル時にある程度はインライン化することになると思うけど。 WORDに定義されたWORD列を、実行時にその場で積んでその場で処理する必要があるから、 FIFOの仕組みが必要になります。 まあ、小まめにWORDの積み降ろしをやらなきゃいけないから、確かに重そうだけどね。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/512
514: デフォルトの名無しさん [sage] 2008/10/11(土) 06:54:12 >>464のやり方だと実行の度にリターンスタックに命令列のコピーが発生するわけだな。 対して普通のForthはリターンアドレス一つのコピーで済む。 Forthでは関数の戻り場所を実行時に入れ替えたりできる( >>59, >>62 ) わけだけど、 >>464のやり方だと命令列自体の入れ替えになるから相当面倒。 Forthの自由度をわざわざ減らしている気がするんだけどな。 でも作るというならがんがれ。 様々な進化があってこそ発展もある。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/514
515: 464 [sage] 2008/10/11(土) 13:07:00 >513 いや、実装はこっちの方がシンプルだよ。辞書の解釈を全部WORDに押し付けることができるから。 ただ、スタック操作が増えるから重くなる方向だけどね。 >514 リターンアドレス前提だと難しいよね。作業用スタックがもう一本ありゃいいんだけど。 俺言語のVMだと自前スタックで実装しているので大した話じゃないです。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/515
516: 464 [sage] 2008/10/11(土) 13:22:12 >514 ちょっと補足。 複数のWORDを押し込もうとすると確かに面倒だね。 俺言語でも 1. 無名WORDを作る 2. 1.のWORDに実行するWORDを押し込む 3. 1.のWORDをリターンスタックに押し込む といったパック化が必要になります。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/516
518: 464 [sage] 2008/10/11(土) 13:38:04 >514 思い出した……>59を実現するにはreverse自体のパック化も必須なんだっけ。 そういや>59みたいな操作をどうしようか悩んだな。 ただ、こういったWORDを跨ぐ暗黙的なリターンスタック制御てけっこう危険じゃない？ 個人的にはWORDはデータスタックの状態にのみ依存すべきだと思うけど、WORDを越えた 範囲までリターンスタックを操作できるようにすると、WORD同士の依存関係が出てしまって 連鎖性(concatenative)が崩れるような気がする。 forthの条件分岐でも、セパレーターを使った明示的な制御をしているわけだし。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/518
519: 464 [sage] 2008/10/11(土) 13:49:31 連投スマソ >517 そうか、CPUだともう一般的なのか……。さすがに天才的な変態が集まる業界だな。 やっぱりCPUのアーキテクチャ勉強しないといけないなあ。 IFは構文解析で逃げました。 block := block ? WORD1 ! WORD2 という三項演算子を用意して、条件分岐用WORDに解釈するようにしました。 不定ループの構文を用意するかどうかは検討中です。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/519
521: 464 [sage] 2008/10/11(土) 15:30:32 >520 どのみちリターンスタック（実行する命令列を保存する専用スタック）が必要なのはその通り。 WORDの動作：普通のForthでの実行と同じ動作でワード系列をコピー VMの動作： 順番にInterpretして実行する というところがポイントですな。VMは辞書のこととか考える必要がないのでシンプルになります。 その代わり「辞書からWORD列を拾ってリターンスタックに展開する」というWORDが必要になるけど。 確かにコピーする手間はムダな気もするんだけどね…… 辞書のWORD列を直接トレースするのと比べてどんぐらい余計な手間がかかってるんだろう？ ポインタ操作数回＆アクセス数回レベルだと思うけど。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/521
529: 464 [sage] 2008/10/12(日) 15:10:26 >522 その辺は「自由と責任」というやつですな。「銃で足をブッとばす自由」でもあるけど。 >どのへんが複雑だと思ったのかは興味がある… 自分でも何でだったっけな、と過去の記憶を探り出してみたけど、 ・実行中のWORDの次のWORDを辞書の中から探せるようにする仕組みが必要 ×実行中のWORDの中身を変更するのが大変（VMのスタックに積んでいるWORD含む） ×番兵などの終了処理が必須 --> VM側のスタックに積むことにすればpop&top参照で正規化できるし、元の値を コピーするからWORD変更にも影響されない。 ・VM側に「WORDを実行する」という手順が必要になる --> VM側のスタックに積むことにすればpushで正規化できる ぐらいかもしれない。 コンパイル時にWORDの中身が確定するforthだとあんまり問題にならなそうだね。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/529
530: 464 [sage] 2008/10/12(日) 15:20:28 >524 「スタックに複数のデータを押し込む操作は機械語レベルだとアトミックにならない」ということ？？ C++で実装しているから意識していなかったけど、そうかもしれないですね。 少なくともプリミティブで実装する必要あるね。 >ForthのVMよりも（多分プリミティブ）WORDの系列を作る部分が余分で、 これは狙ってやっていることだから仕様がないですね。 まあ、俺言語ではVM自体もWORD扱いにしているのですが…… http://mevius.5ch.net/test/read.cgi/tech/1073673931/530
532: 464 [sage] 2008/10/12(日) 23:25:00 本格的に触るのは……あの構文は色々と嫌だ。 [条件] IF [肯定時] ELSE [否定時] THEN とか。 せめて条件算子的だったらなぁ。[条件] ? [肯定時] : [否定時] ; >531 細かいことを言うと、nextルーチンが辞書内のスレッデッドコード構造の詳細を知らなきゃ ならないので、VMと辞書の関連が密になりそうな気がします。スレッデッドコードをスタックに pushしてVM内に取り込んじゃえば辞書内の構造を気にする必要無いし。 まあ、最適化のために作り込んでも良い気がするけどね。そこは将来の課題ということで。 >一カ所ポインタを書き換えるだけで済むはず。 WORD自体を置換する場合はそうですね。WORDの挿入や削除はたぶん難しいかと。 そんな特殊なことは禁止にして、新規にWORD定義させた方が良いかも知れないけど。 あるいは無名WORDとかスキップWORDを用意するとか。 >「WORDを実行する」という意味のインストラクションは必要ないよ。 あれ？VMに保存されている「現在実行中のWORD」って、間接ポインタじゃないの？ （nextの動作を考えると、間接ポインタじゃないと色々と面倒臭そうな） 実行前に間接参照からWORDを探す操作が一段余計に必要になるかと思ってた。 http://mevius.5ch.net/test/read.cgi/tech/1073673931/532
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.038s