- GREF_CALL を、と考えています。 -- yamanetoshi
- yamanetoshi さん次のインストラクションをお願いします。 -- ひげぽん
- PUSH_GREF をやりました（簡単なのが残ってた！）。yamanetoshi さんレビューをお願いします。 -- ひげぽん
- むむ。少々お時間頂戴できれば、と。 -- yamanetoshi
- ひげぽんさんへ、似た命令は、PUSH_GREFとなっていますが、GREF_PUSHではないでしょうか？ -- knishii2156
- ご指摘ありがとうございます。修正しました。 -- ひげぽん
- 問題ないと思います。knishii2156 さんコメント無ければクローズで良いと思っています。 -- yamanetoshi
- 使用例について確認させてください。PUSH_GREFなので、PUSH_GREFがdisasmされる例にすべきだと思いますが、GREF_PUSHが表示される例を採用したのは、なにか理由があってのことでしょうか？ -- knishii2156
- 寝ぼけていますね。申し訳ないです。修正しました。 -- ひげぽん
- 自分もあまりきちんと使用例見てなかったス。knishii2156 さんナイスでした。ザルなレビュアで申し訳ないです。 -- yamanetoshi
- LOCAL_ENV_CLOSURESを皆様の指摘に基づいてまとめました。確認をお願いします。 -- knishii2156
- 確認しました。良いと思います。knishii2156 さんご自身で気になる点や不明点がないのであればクローズしましょう。 -- ひげぽん
- では、異存がないようですので、一旦クローズします。yamanetoshiさんへ、なにかあれば教えてください。反映します。ひげぽんさんへ、次のインストラクションの担当をお願いします。 -- knishii2156
- 大丈夫でーす。knishii2156 さんの頑張りもひげぽんさんのリードも凄いですね♪ -- yamanetoshi
- とにかく、みなさんのおかげで終了できました。ありがとうございました。 -- knishii2156
- letrec に目をつけて Gauche のドキュメントを参照している点、細かく動作を追っている点が良いですね。よく調べたなあという印象です。この命令はとても難しいので理解しやすいように、概要から詳細へ説明を展開すると良いかもしれません。
以下のように展開します。
- この命令が果たす役割
- 命令中に行われる主な処理
- 命令詳細（knishii2156さんが力を入れたところ）
この命令が果たす役割
letrec （ここでドキュメント参照）を実現するために、letrec 動作に従い変数束縛をする
命令中に行われる主な処理
以下の順で変数の束縛が行われる
- 変数の個数を命令から取り出す
- 変数の個数分の letrec 用ローカル環境を作成する
- オペランドから各変数の初期値を取り出し束縛する
命令詳細
knishii2156 さんのまとめをここへ。
compile.scm の partition-letrec-inits 手続きを見ると分かるが初期値は 3種類しかない。
- 定数
- コンパイル済みコード（クロージャ）
- undefine
この undefine の部分がドキュメントで触れられている仮想的な undefine 初期値である。
undefine 値はこの命令の直後に別の命令で初期化される（それまでに参照された場合は undefine である）
あとコード例ですが gosh -fno-inline と起動すると、以下のコードでとてもわかりやすいコンパイル結果が得られます。
(disasm
(lambda ()
(letrec ([a (lambda () b)]
[b x])
a)))
- LOCAL_ENV_CLOSURESをまとめました。ひげぽんさん、お手数ですがレビューをお願いします。多分、間違っている部分も多々あると思いますが、よろしくお願いします。今回の使用例は、yamanetoshiさんがブログに示したコードをちゃっかり使用させいただきます。 -- knishii2156
- 使用例ですが、Gauche のマニュアルの引用にある通り、相互再帰な例の方が良いのではないか、って思ってたりします。 -- yamanetoshi
- 了解です。長くなりそうなので上に書かせていただきます。 -- ひげぽん
- 今日のところは、LOCAL_ENV_CLOSURESの走り書きですが、ここまでとします。イメージとしては、コンパイル済みか不明なコードを想定し、コードのサイズから、環境フレームを用意して、cpの指す値がコンパイル済みのコードなら、cpのcarとなる値からクロージャーを作り、VAL0と用意した環境フレームの先頭のアドレスに格納する。そうでないならcpのcarとなる値を環境フレームの先頭の値に格納する。こんなイメージでいます。でも、書いてみると、インストラクションのコードの内容からすでにずれていますね。もうちょっと調べてみます。 -- knishii2156
- LOCAL_ENV_CLOSURESをやります。まずは自分なりに調べてみてみます。３連休中に更新するのを目標にやります。 -- knishii2156
- キーワードのリンクについては更新しましたが、内容の更新は未着手です。もう少し時間をください。単純に書くと信じられない日本語になるので。 -- knishii2156
- はい。無理せず分からないところは皆で片付けましょう。難しい命令ばかりが残っているんですよね。 -- ひげぽん
- ひげぽんさん、お気遣いありがとうございます。難しいというのではなく、私がGaucheのVMの動作を完全に把握していないために混乱しているだけだと思います。多分、今担当しているLOCAL_ENV_CLOSURESはVMを知っていれば、30分程度で終わると思います。 -- knishii2156
- yamanetoshiさん、確認しました。２つのインストラクションとも意図は的確に説明できています。後、ひげぽんさんのほうからのリクエストがなければクローズしていいと思います。 -- knishii2156
- 確認しました。良くまとまっていると思います。 -- ひげぽん
- お二人共、確認ありがとうございました。ではこの件は close しましょうね。次は knishii2156 さんまとめ役で良いのでしょうか？自分がひら担当でひげぽんさんレビュアになりますか？ -- yamanetoshi
- はい。そうしましょう。しばらくこの３人でぐるぐるまわしましょうか。 -- ひげぽん
- そうしましょうか。次のインストラクションを選びますので、時間をください。 -- knishii2156
- レビューやりましょうか？ココサブさんを抜いた順では一応私の番になると思うで。ただ、これから外出しますので、早くても今夜から見ることになりますが、いいですか？ -- knishii2156
- BNEQC 及び BNEQVC をやりました。ひらは必要ありませんでした。レビューってどなたにお願いすれば良いんでしょ？ -- yamanetoshi
- 次は yamanetoshi さんお願いします。（ココサブさんはしばらくお休みかな？） -- ひげぽん
- CONST_APPLY をやりました。 yamanetoshi さんレビューをお願いします。少しペースが落ちていますが、コンプリートも近いのでみなさんがんばりましょう！ -- ひげぽん
- 了解です。確認しますね。 -- yamanetoshi
- とりあえず、_手続きがコンパイルに定数として_は_手続きがコンパイル時に定数として_ですよね？ -- yamanetoshi
- ありがとうございます。修正しました。引き続きレビューをお願いします。 -- ひげぽん
- 記述については問題ないと考えてます。ただ、確認というか教えて頂きたいのは_コンパイル時に定数として決まっておりオペランドに含まれる_というあたりで、これは 0.8.11 でも同様、なのでしょうか？ -- yamanetoshi
- スミマセン。スルーでお願いします (compile.scm 見てみます)。内容 OK ですので。 -- yamanetoshi
- compile.scm では CONST_APPLY は使われていないです。ただ vm.c の CONST_APPLLY を見ると命令列からのみ引数と手続きを取得しているので、コンパイル時に埋め込まれている（＝定数として決まっている）と推測しています。 -- ひげぽん
- ひげぽんさん、次のインストラクションをお願いします。 -- knishii2156
- ひげぽんさん、yamanetoshiさんありがとうございました。とりあえず、もう２、３日、そのままにしておきます。何かあれば、よろしくお願いします。 -- knishii2156
- 自分こそ微妙なレビュアで申し訳ありませんでした。_う２、３日、そのままに_との事で、できれば確認してみますね。現時点では特にコメントはありませんので、寝かせた後にリプライが無ければまとめ役マターでクローズして頂いて構わないと考えています。 -- yamanetoshi
- ping! -- ひげぽん
- 異論がないようですので、VALUES_N, PUSH_HANDLERSについてはクローズします。 -- knishii2156
- ひげぽんさんの指摘に基づいてPUSH_HANDLERS,VALUES_Nを修正してみました。（ひげぽんさんだともう少し前後の文章がスマートなのでしょうが）。見てもらって気になる点があれば、指摘してください。それにしても、前回のShibuya.lispでも聞いた覚えがありますが、Gaucheの異なるバージョンを見てみるというのも１つの手なんですね。 -- knishii2156
- 採用していただきありがとうございます（少し自信がないですが。）特に気になるところはありませんでした。 -- ひげぽん
- ひげぽんさんの指摘に基づいてPUSH_HANDLERS>Reading Gauche/[[VALUES_N>を修正してみました。（ひげぽんさんだともう少し前後の文章がスマートなのでしょうが）、 -- knishii2156
- PUSH_HANDLERS,VALUES_Nですが、今のところ、これ以上修正できなさそうです。なんかいい資料とかありませんかね。もうちょっとコードを見てみます。 -- knishii2156
- 長い間スミマセン。下記コメントにあります通り、レビューコメントはスルーで現状 OK な決裁でかまわないと、自分は思っています。他の方はいかがでしょうか？ -- yamanetoshi
- PUSH_HANDLERS について何点か。(1) before/after thunk が vm->handlers の実体である alist に追加される（acons)されるという点は書いた方が良いかと思いました。(2)使われていない疑惑ですが、僕も使われていないと思います。dynamic-wind は stdlib.c で同じく vm->handlers を触る方針で実装されているようです。(3)これは余談ですが、0.8.11 のPUSH_HANDLERS の実装は before に2回値が代入されていて変な感じです。ひょっとしたらバグかも。0.8.14のコードを見たら僕が想定しているコードに修正されていました。 -- ひげぽん
- VALUES_N は VALUES との違いを書くと良いと思います。僕の推測では VALUES はコンパイル時に多値の個数が分かっている場合に使われる。(values 1 2 3 4 5) の場合は5個。VALUES_N は個数が分からない場合。 a というリストがあって (apply values a) とした場合ですね。VALUES_N が使われていないのは stdlib.c にある C で書かれた values 手続きがあるからだと思いました。 -- ひげぽん
- PUSH_HANDLESRS,VALUES_Nを少し直してみました。ただ、もう少し検討したいので時間をいただいていいですか?. -- knishii2156
- 明日、プログラミングGaucheが届くので、この本も読んでみて、内容を修正したいと思います。 -- knishii2156
- おつかれさまです。上記了解です。微妙なレビューコメントで申し訳ないです。まとめ役がある意味最終決裁ですのでコメント却下、でも構わないはずですので。。 (そもそも (自分分については) コメントがダウトかビンゴかも微妙ですし -- yamanetoshi
- PUSH_HANDLERS および VALUES_N のコメントを以下に。 -- yamanetoshi
- まず VALUES_N 分から。VALUES とどう違うのか、という部分に着目してソースを確認してみては如何でしょうか？とりあえず_スタックにセットする_という記述はダウトと思われます。POP_ARG してるので。 -- yamanetoshi
- PUSH_HANDLERS ですが、説明の記述をもう少し、コンピュータ寄りから人間寄りに修正する事はできないでしょうか。特に_(cons (cons *--SP SCM_FALSE) vm->handlers)_とか_ドット対に設定する_な記述とか。 -- yamanetoshi
- 下記のインストラクションについては、使用している記述がなかったので、コード例は抜いています。PUSH_HANDLERSについてのSPの扱いがしっくりこなかったのですが、ほかに思い当たる表現がなかったの、このままにしています。ココサブさん、レビューをお願いします。 -- knishii2156
- ココサブさん大変そうみたいなのでレビュアやりましょうか？ってか、全部完了してからレビュ依頼の方が良いのでは？って思ってたりします。。 (ひらがあったら微妙? -- yamanetoshi
- yamanetoshiさんへ、よろしければお願いします。とりあえず、今回のPUSH_HANDLERS,VALUES_Nについては、ひらを行う必要はないです。関数等のひらはずっと前に終わっているようです。 -- knishii2156
- PUSH_HANDLERS, VALUES_Nをやります。 -- knishii2156
- ひげぽんさん、yamanetoshiさん、アドバイスありがとうございます。とりあえず、disasmについては後回しにして、次のインストラクションにとりかかります。PUSH_HANDLERS, VALUE_N wo -- knishii2156
- 下記の件、了解しました。一つ教えてください。インストラクションのdisasmはどうやって調べていますか？私はやみくもに調べて、disasmの結果が出たインストラクションのみを選んで、読んでいたのですが、今回はそうもいかず、困っています。何かいい手法をご存知でしたら、教えていただけないですか。 よろしくお願いします。 -- knishii2156
- 自分の場合は comple.scm（コンパイラ）を見ています。例えば BNLT で検索すれば、pass3/branch-core にたどりつき、特定の if で BNLT が発行されることが分かります。 -- ひげぽん
- 自分もこれ的にはそろそろ限界かも。最近 emacs な run-gauche で disasm するという手法を見出して例えば programming Gauche に例示されてるものを disasm してみる、というのも一つの方法かも。まだインストラクションの名前からなんとなく類推できるのがいくつか残ってますがそろそろ微妙。自分も良い手法というのはお伺いしてみたくはありますが、単純に勉強不足だったりするなぁ、というのもあるなぁ、と。。 -- yamanetoshi
- disasm は必須ではないと思うので、とりあえずページを完成させて、disasm はヘルプよろしくという形でも良い気がしますね。 -- ひげぽん
- knishii2156 さん、次のインストラクションをお願いします。 -- yamanetoshi
- 弱くてスミマセン。BNUMNE やります。可能であれば関連するナニも対応、とは思っていますが ... -- yamanetoshi
- 連休で止まってしまいましたね。さてどうしよう。 -- ひげぽん
- SLOT_REF / SLOT_REFC / SLOT_SET / SLOT_SETCをやります。ひさびさにひらメソッドで読んでく関数があります。ひげぽんさんお手伝いお願いします。Scm_VMSlotRefを私がほっていって、Scm_VMSlotSetをひげぽんさんがほっていく方向で進めたいと思います。 -- ココサブ
- 掘りました。 -- ひげぽん
- ありがとうございます。今週中に自分の分を掘って、まとめるところまで行きたいと考えています。 -- ココサブ
- この Wiki の認証方法を BASIC 認証に変えました。ID/Password は変更ありません。（トップページに載っています）。変更の詳細はこのWikiについて/認証をご参照ください。 -- ひげぽん
- ココサブさん、次のインストラクションをお願いします。 -- ひげぽん
- NOP をやりました。yamanetoshi さんレビューをお願いします。こんな楽なインストラクションがあるとは！ -- ひげぽん
- これって、disasm な結果 (使用例) は載せないんですか？ (わら -- yamanetoshi
- みつけられませんでした＞＜ -- ひげぽん
- ってか、vm.c 見てて思ったのですが、_boundaryFrame_って何でしょ？あ、とりあえずレビュー的には OK だと思っています。 -- yamanetoshi
- ありがとうございます。では完了とさせていただきます。継続フレームの境界の番兵として使われるみたいですね。 -- ひげぽん
- NOP は最後に食べようと思って取っておいたのに...（ぉ -- naoya_t
- GREF_TAIL_CALLをやります。ページは作成していますので、ココサブさん、レビューをよろしくお願いします。この命令では大半の処理がTAIL_CALL,CALLを呼び出す形になっていますので、参照する形式をとっています。 -- knishii2156
- TAIL_CALL, CALLを参照して簡潔にしているのが良いと思います。GREF_TAIL_CALLはおそらく GREF と TAIL_CALL を合成した命令のようなので、その点も書いておいた方がよいと思います。 -- ココサブ
- ココサブさん、指摘ありがとうございます。意図が適切に反映できているか確認をお願いします。 -- knishii2156
- 確認しました。良いと思います。 -- ココサブ
- ココサブさん、ありがとうございました。では、特に異論もないようなのでGREF_TAIL_CALLをクローズします。ひげぽんさんへ、次のインストラクションをお願いします。 -- knishii2156
- PUSH_PRE_CALL close します。次のインストラクションを knishii2156 さんよろしくです。 -- yamanetoshi
- なんかもの凄いナチュラルぶちカマしてます。 -- yamanetoshi
- TAIL_CALL ヤリます。 -- yamanetoshi
- CONSTF_RET / CONSTU_RET をまとめました。knishii2156さんレビューお願いします。 -- ココサブ
- 所用がありますので、レビューの件、しばらくお待ちください。 -- knishii2156
- 説明については問題ないと思います。ただ、CONSTU_RETでは、CONSTF_RETからコピーしたためか、CONSTU_RETがCONSTF_RETという記述になっていますので修正をお願いします。また、CONSTU_RETの使用例で、disasmの部分でとじ括弧が１つ足りないので、そこの修正をお願いします。 -- knishii2156
- 指摘ありがとうございます。どちらも直しました。少し見直せば気付くレベルのぽかしてすいませんでした。 -- ココサブ
- ココサブさんへ、遅くなってすいません。確かに修正されていることを確認しました。 -- knishii2156
- CONSTF_RET / CONSTU_RETをしめます。yamanetoshiさん次のインストラクションをお願いします。 -- ココサブ
- ココサブさん次のインストラクションをお願いします。 -- ひげぽん
- 動いてなくてすいません。今週中に CONSTF_RET, CONSTU_RET をまとめます。 -- ココサブ
- Reading Gauche/vm/insn/POP_HANDLERS をまとめました。内容がうすく恐縮ですが、yamanetoshiさんレビューをお願いします。 -- ひげぽん
- 了解しました。ちょっとお時間頂ければ、と。 -- yamanetoshi
- ひげぽんさん、重箱の墨をつつくような指摘なのですが、POP_HANDLERではなくPOP_HANDLERSでは？ -- knishii2156
- すみません。ありがとうございます。修正しました。 -- ひげぽん
- ええと指摘すべき事項はないので、OK です。レビューコメントという訳ではないんですが、一点確認したいのは_コードを見る限りこの命令は使われていないと思われる_と書いた所以というか根拠をお伺いできればな、と。 -- yamanetoshi
- ありがとうございます。では close します。根拠はコードを各所見て回りかつ、grep してみたという感じです。 -- ひげぽん
- 皆様、Shibuya.lispご苦労様でした。TAIL_CALLについて特に異存がなさそうなのでクローズします。ひげぽんさん、次のインストラクションをお願いします。見ると次は私がひら担当ですね。お手柔らかにお願いします -- knishii2156
- お疲れ様です。いま誰がボールを持っているか分からなくなりました。誰が誰を待っているとかありますでしょうか。 -- ひげぽん
- 私は誰も待っていない状態です。knishii2156さんがTAIL_CALLを閉じるかどうか悩んでいる状態でしょうか。私は閉じてもよいかなと思います。 -- ココサブ
- TAIL_CALLについてです。指摘事項が特にないようでしたので、ページでレビュー用資料として残しておいた項目を削除しました。また、使用例がイマイチだったので、ちょこっと修正しています。 -- knishii2156
- すいません。TAIL_CALLの背景についてはお手上げという状態です。今、Shiroさんのウェブサイトに資料をもとめて彷徨っている状態です。VMについての理解ができていないので背景を書くのは、きつそうです。 -- knishii2156
- 最近試してみたのですが、末尾呼び出しの時にスタックがどういった状態遷移か、というのを確認してみるのは良いかもしれないな、と思っています。 -- yamanetoshi
- 背景を追記してみました。こんな感じでいかがでしょうか。 -- ひげぽん
- ひげぽんさん、techtalkで忙しい中、サポートありがとうございます。それにしても、追記されたことは、初耳でした。これからは仕様もしっかり勉強していかなければということですね。皆様へ、週明けまで、そのままにしておきますので、他に直すべき点がありましたら、指摘してください。 -- knishii2156
- TAIL_CALL について修正を行いました。基本的には、ココサブさんの指摘を確認し、変更を実施しています。ただし、背景と使用例については、手つかずです。明日、調べてみます。説明についての確認をお願いします。ココサブさんの書き込みはそのままにしています。 -- knishii2156
- PROMISEについて、naoya_tさんの使用例のほうがシンプルなのでそちらを採用します。また、その使用例で、disasmの式中の括弧があっていないのを修正しました。週明けまで、異論がなければクローズします。 -- knishii2156
- 異論がないようなので、PROMISEについてはクローズします。 -- knishii2156?
- 皆様、対応が遅れてすいません。週末から、再びTAIL_CALLのページ作成にかかります。心配をおかけしてすいません。 -- knishii2156
- ひげぽんさんもフォロー可能と言われてますし、ここで色々検討できたら自分的にも勉強になるな、と思っています。微力ではありますがお手伝いしますので (微にも足りてなかったりしますが ... -- yamanetoshi
- 心遣いありがとうございます。もうちょっとvm.c以外にも調べてみます。わからない点があれば相談しますので、よろしくお願いします。 -- knishii2156
- yamanetoshiさん、ひらの件ありがとうございました。ココサブさんへ、TAIL_CALLのレビューをお願いします。 -- knishii2156
- 時間があいてすいませんでした。レビューしました。量が多くなりそうだったのでページに注釈の形でいくつか書きました。自分の理解がいまいちの所もあるのでknishii2156が違うなと思ったレビュー箇所とかはここで議論というか話あっていきましよう。 -- [[ ココサブ]]
- 上記にあるように自分が良くわかってないところがあるので、他の方もよければレビューお願いします。 -- ココサブ
- 横から失礼します。_説明_の部分はコメントが参考になるのでは？と思ったりしています。自分もまだきちんと理解できていないのですが、色々なケースでどう評価されるのか、は確認すべき、というかしたいなぁ、と思っています。 -- yamanetoshi
- 自己フォローで。コメントはソースコードのコメントを指してます。念の為。 -- yamanetoshi
- このインストラクションは末尾再帰呼び出しの最適化が大きく関与するので。1.末尾呼び出し最適化の背景（仕様できまっているとか）2.Gauche全体で末尾呼び出しがどう扱われるかの概略、3.その中でこのインストラクションが果たす役割。という流れが見えると良いと思いました。全て knishii2156 さんが説明を書くとかではなくて外部リンクでも良いのですが、読み手的にはそういう形がうれしいかなと。 -- ひげぽん
- どうするかは、しばらく、考えさせてください。これはけっこう時間がかかるかも。 -- knishii2156
- うお。すみません。難しすぎましたか。お手伝いしますので分からないところがあったら聞いて下さい。 -- ひげぽん
- yamanetoshiさんへ、TAIL_CALLの関係のひらをお願いします。SCM_VM_STACK_SIZE,CONT_FRAME_END,CONT_FRAME_SIZE等のひらのお願いします -- knishii2156
- 確認ですが、SCM_VM_STACK_SIZE とか CONT_FRAME_SIZE ってどこに出てきますか？ -- yamanetoshi
- yamanetoshiさんへ、すいません。SCM_VM_STACK_SIZEのページはもうすでに作成されていましtaCONT_FRAME_END -- knishii2156
- yamanetoshiさん、すいません。SCM_VM_STACK_SIZE,CONT_FRAME_SIZEのページはすでに作成されていました。CONT_FRAME_ENDのひらをお願いします。たしかCONT_FRAME_ENDのページはまだ未着手のはずです。 -- knishii2156
- TAIL_CALL の関連項目にリンク切れなナニがありますが、気にしなくて良いですか？ -- yamanetoshi
- TAIL_CALLをやります。 -- knishii2156
- 次のインストラクションを選ぶので、しばらくお待ちください。 -- knishii2156
- PROMISEのレビューの件です。naoya_tさんの使用例のほうが、確かにシンプルでわかりやすいので、naoya_tさんの使用例を採用することにします。よろしいでしょうか？ -- knishii2156
- knishii2156 さん、次のインストラクションをお願いします。 -- yamanetoshi
- 以前から放置していた Scm_MakeHashTableSimple 以下のひらを実施してます。 -- yamanetoshi
- CONST_RET にします。弱いですがご容赦頂ければ、と思います。 -- yamanetoshi
- ひら不要です。 > ココサブさん -- yamanetoshi
- レビューお願いします。> ひげぽんさん -- yamanetoshi
- 読みました。良いと思います。CONST と RET の合成命令である事を追記すると更によいかもしれません。次の GO サインを出してしまって良いと思います。 -- ひげぽん
- 結構無理矢理気味ですが、合成命令な旨を盛り込んでみました。空いてる時にチェックしてみて下さいまし。 -- yamanetoshi
- うわ。CONST_RET は僕待ちだったのか。失礼しました。確認しました。 -- ひげぽん
- チェックありがとうございます。自分こそ knok しなきゃ、って思いつつ微妙に放置気味でした ... 別途 close しておきますね。 -- yamanetoshi
- リング2 を作りました。まとめ役は yamanetoshi さんです。インストラクションを選択し開始してくださいませ。 -- ひげぽん
- naoya_t さんがお忙しそうですね。他の方々にいくぶんか余裕があるならば、 naoya_t さんの負担を軽くするようなフローを考えたいのですがどうでしょうか？＞ココサブさん、knishiiさん、yamanetoshiさん -- ひげぽん
- 分かりました。なにかアイデアあるのであれば基本賛成の方向ッス。 -- yamanetoshi
- ありがとうございます。例えば「naoya_t さんに順番がまわる頻度を半分にする」などを考えています。 -- ひげぽん
- 私も賛成です。アイデアを一つ、「担当のバトンのリングを2つにして片方だけnaoya_tさんがいるリングにする」。 -- ココサブ
- 同じく、私も賛成です。多忙な場合、たしかに大変ですからね。 -- knishii2156
- では。ココサブさんの案を採用してもう一つバトンリングを作りましょう。 -- ひげぽん
- 皆さんすみません。当面軽めのリングで参加させて頂ければと思います。 -- naoya_t
- POP_LOCAL_ENV は今どういう状態でしょうか。もしお見合い状態ならば確認できればと思います。現在→のような状態です。PROMISE レビュー中（naoya_tさん）、POP_LOCAL_ENV レビュー中（naoya_tさん？ココサブさん？）、LOCAL_ENV 着手中（naoya_tさん）。 -- ひげぽん
- すみません。週末にしか進められていないですね。お見合いでなく独りで止めてます：（１）PROMISEの用例どうしようか（２）POP_LOCAL_ENVはココサブさんのアドバイスを織り込む形にしたい（３）LOCAL_ENVの用例探し -- naoya_t
- naoya_tさん、PROMISEのレビューをお願いします。なおdisasmの結果は、インターナルクロージャーについては無視した記述にしています。 -- knishii2156
- お疲れさまです。使用例についてですが、lazyやdelayで使われている事を示せていれば良い気もしますが、ちょっと考えさせて下さい。 -- naoya_t
- ココサブさん、ひらの件、対応ありがとうございました。対処となるページができていることを確認しました。 -- knishii2156
- 残り少なくなってきましたね。naoya_t さん。POP_LOCAL_ENVのまとめと、新たなインストラクションへの着手をお願いします。 -- ひげぽん
- 現時点で、終わっていない命令一覧。APP-VEC, BNEQC, BNEQVC, BNGE, BNGT, BNLE, BNLT, BNUMNE, CONS-PUSH, CONST-APPLY, CONST-PUSH, CONST-RET, CONSTF-RET, CONSTU-RET, GREF-CALL, GREF-TAIL-CALL, LIST2VEC, LOCAL-ENV, LOCAL-ENV-CALL, LOCAL-ENV-CLOSURES, LOCAL-ENV-JUMP, LOCAL-ENV-TAIL-CALL, LREF-PUSH, LREF0-PUSH-GREF, LREF0-PUSH-GREF-CALL, LREF0-PUSH-GREF-TAIL-CALL, LREF1-PUSH, LREF2-PUSH, LREF3-PUSH, NOP, POP-HANDLERS, PUSH-GREF, PUSH-GREF-CALL, PUSH-GREF-TAIL-CALL, PUSH-HANDLERS, PUSH-PRE-CALL, RECEIVE-ALL, SLOT-REF, SLOT-REFC, SLOT-SET, SLOT-SETC, TAIL-APPLY, TAIL-CALL, TAIL-RECEIVE-ALL, VALUES-N, VECTORP -- ひげぽん
- 現時点で、 -- ひげぽん
- 今日は、PROMISEのページを作るまでとします。ココサブさんへ、もし、お時間があるようでしたら、Scm_MakePromise関数関連でひらを行っていただきたいのですが、どうでしょうか？お時間がとれない場合は、私のほうでやります。 -- knishii2156
- 少々遅くなりましたが、ひらやりました。不足がでてきたら教えてください。 -- ココサブ
- PROMISEをやります。ただし、今回disasm等がまったくわからないので、わかるところまでやって、不明な点は別途相談させてください。 -- knishii2156
- knishii2156 さん次のインストラクションをお願いします。 -- ひげぽん
- knishii2156 さん CHECK_STACK のレビューをお願いします。 -- ひげぽん
- ひげぽんさん、レビューの件、しばしお待ちください。 -- knishii2156
- おそらく問題ないと思います。もし他の方で、余裕がありましたら、確認をお願いします。 一点だけ教えてください。このコマンドが現在使用されていないというのは、どこを見て判断されたのですか？ -- knishii2156
- ありがとうございます。compile.scm、code.c、vm.c などコードを発行しそうなところをみて判断しました。今週末中に特にご指摘がなければ close します。 -- ひげぽん
- close とします。 -- ひげぽん
- naoya_tさん NUMADD2 に1行追加( NUMIADD2とは異なり計算結果を正確数に正規化しようと試みる。 )したので確認願います。 -- ココサブ
- ひげぽんさん NUMSUB2 / NUMMUL2 / NUMDIV2 / NUMIADD2 / NUMISUB2 / NUMIMUL2 / NUMIDIV2 / NUMSUBIのレビューお願いします。 -- ココサブ
- お疲れ様です。→NUMSUB2シリーズ: 「正確数に正規化しようと試みる」について。正規化は分かるのですが正確数の部分が分かりませんでした。オペランドに応じて正確数か非正確数が決まるのではないでしょうか。またそれぞれの命令でパフォーマンスのためにショートカットが設けられていることに言及するとより良いかも。また正規化の説明もあると良いと思いました。NUMIADD2シリーズ：良いと思います -- ひげぽん
- レビューありがとうございます。正確数の部分は確かにおかしかったです。「正確数に正規化しようと試みる」の箇所直しました。また、ショートカットなどについて補足という形で使用例のしたに追記しています。 -- ココサブ
- ありがとうございます。確認しました。良いと思います。 -- ひげぽん
- それでは閉じます。次のまとめ役はひげぽんさんお願いします。 -- ココサブ
- 了解です。火曜日ぐらいにページをまとめます。 -- ひげぽん
- NUMSUB2などをやります。 -- ココサブ
- ココサブさん、次のインストラクションをお願いしますね。 -- yamanetoshi
- naoya_tさん次のインストラクションをお願いします。 -- ひげぽん
- 了解しました。次を選びますのでしばらくお待ちください。 -- naoya_t
- naoya_tさん。RT, RF, BNNULL, RNEQのレビューをお願いします。 -- ひげぽん
- 見ました。良いと思います。BNNULLは (if (not (null? '())) ...) だけでなく (if (null? '()) ...) の場合にも吐かれるので使用例にサンプルを追加してみましたが如何でしょうか。 -- naoya_t
- すみません。RNNNULL の間違いでした。再度チェックをお願いできませんでしょうか。すみません＞＜。 -- ひげぽん
- RNNULL見ました。良いです。R系の中に１つだけB系が入ってて不思議に思っていたところでした。 -- naoya_t
- ありがとうございます。 -- ひげぽん
- これにて完了とします。 -- ひげぽん
- ひげぽんさん、NUMLT2 のレビュをおねがいします。レビュがパスしたら関連インストラクションもまとめて片付ける方向で考えております。 -- yamanetoshi
- 1月4,5日までお休みします。 -- ココサブ
- RF のレビューをお願いします＞naoya_tさん。RTなどは RF が固まったら追記します。 -- ひげぽん
- RF良いと思います。引き続きよろしくお願いします。 -- naoya_t
- もう一つヤッた方が良さげですね。NUMLT2 をやります。 -- yamanetoshi
- RF / RT / RNEQ / RNEQV / RNNULL をやります。 -- ひげぽん
- 遅くなりましたがPUSH_LOCAL_ENVをまとめました。knishii2156さん、レビューお願いします。 -- naoya_t
- FALL_THROUGHを見落としていました・・・ちょっと待ってて -- naoya_t
- → 出来ました。よろしくお願いします。 -- naoya_t
- naoya_tさん、問題ないと思います。私も、最初確認したときにFALL_THROUGHを見落としていました。 結局、vm.cでは、SCM_VM_PUSH_LOCAL_ENVの後にSCM_VM_LOCAL_ENVも実行されるというこですよね。 -- knishii2156
- knishii2156さんどうもありがとうございます。その通りです＞SCM_VM_PUSH_LOCAL_ENVの後にSCM_VM_LOCAL_ENVも実行される -- naoya_t
- ではPUSH_LOCAL_ENVはクローズします。 -- naoya_t
- naoya_tさん、御苦労さまでした。つぎはひげぽんさんですかね。 -- knishi2156?
- NUMEQ2 close しますね。次、naoya_t さんでいいのでしょうか？ -- yamanetoshi
- 止まるのもあれなので１つ進めますか？ -- ひげぽん
- CALLはクローズとさせていただきます。次は naoya_t さんですね。いろいろ溜まっちゃってますがお願いします。 -- ココサブ
- CALLやります。気合入れねば -- ココサブ
- 関連項目 出し完了しました。ひらする必要なものがあるので、ひげぽんさんお手伝いお願いします。 -- ココサブ
- まとめてみました。knishii2156さんレビューお願いします。また、今回モノが大きいので他の方も良かったらレビューしていただけると嬉しいです。 -- ココサブ
- 今回ものが大きいので、ちょっと時間をください。 -- knishii2156
- 問題ないと思います。ただ、今回規模が大きいのと、私がVMの仕組み自体を理解していないので、他の方で時間がとれるようでしたら、念のため確認をお願いします。 -- knishii2156
- うが。お手伝いできませんですみません。罪滅ぼしにレビューを。以下3点。 -- ひげぽん
- CHECK_STACK で何をしていて何がうれしいかを軽くでも書いておくと良いと思います。
- 例：実行しようとしているクロージャが使用するスタック量と現在の残りスタック量と比較し足りない場合は拡張する。
- SCM_PROF_COUNT_CALL(vm, VAL0); で何をしていて何がうれしいかを軽くでも書いておくと良いと思います。
- 例：プロファイラが有効な場合に CALL されたクロージャとその回数の統計データを更新する。
- SCM_PROC_SUBR の場合の「PCがRETを指しているならばRETを実行する」ですがもう少し詳しい方が良いと思います
- 例：SCM_PROC_SUBR は一部のものを除いて PC を更新することはない。つまり別の場所に jump して戻らないものは少ない。このことから <FRAME作成> <subrのcall> <RETによるFRAME破棄>のうち後半2つのどちらも CALL 内で済ませてしまう場合がある。これにより命令のディスパッチが RET の分1つ減るので速度的にうれしい。
- みなさんレビューありがとうございます。ひげぽんさんの指摘を反映させました。 -- ココサブ
- CALL って面白いですね。レビューコメントという訳ではないにせよ、色々確認させて頂くことがあるかもしれません。ひげぽんさんのコメントもとても参考になります。 -- yamanetoshi
- ありがとうございます。 -- ひげぽん
- ココサブさん他皆様、御苦労さまでした。 -- knishii2156
- ココサブさん、次のインストラクションをお願いします。 -- knishii2156
- yamanetoshiさん、BNEQVのレビューをお願いします。 -- knishii2156
- naoya_t さん、Reading Gauche/vm/insn/NUMEQ2 のレビューをお願いします。 -- yamanetoshi
- おっと呼ばれてた。しばらくお待ちください -- naoya_t
- NUMEQ2良いと思います。遅くなって申し訳ありません。 -- naoya_t
- いえ。どうもありがとうございます。って次のコールはまたまた naoya_t さんなんですが ... -- yamanetoshi
- BNEQVをやります。 -- knishii2156
- NUMEQ2 を、と考えています。 -- yamanetoshi
- naoya_t さん次の方を指名してください。 -- ひげぽん
- もしかして、周回遅れだった自分がもう一度、じゃないかな・・・ -- naoya_t
- 私が編集したIS_A関連の関数等の見直しについては時間をください。PUSH_LOCAL_ENVのレビューもあるので。できる範囲で少しずつ対応していきます。 -- knishii2156
- VMインストラクションのページを見ると、次はyamanetoshiさんがまとめ役なので、yamanetoshiさんにお願いするということでいいのでしょうか？順番が前後していてよくわからないので教えてください。 -- knishii2156
- ひげぽんさん、EQVのインストラクションのリンクを貼る際に、NEGATEを参照したのですが、NEGATEのdisasm後のインストラクションCONSTがLREF0にリンクされているのですが、これは正しいのでしょうか？ -- knishii2156
- 失礼しました。間違いですので修正しました。 -- ひげぽん
- Reading Gauche/gauche/system.h/SCM_SYSCALL3にshiroさんからコメントが。ページを作った人はフォローをお願いします〜。 -- ひげぽん
- ひげぽんさん PEEK_CHARのレビューお願いします。 -- naoya_t
- おつかれさまです。とても細かくて恐縮ですが、説明中「入力ポート」「ポート」と表記揺れがある点が気になりました。それ以外は OK です。 -- ひげぽん
- ナイスつっこみであります。「入力ポート」のほうに統一しました。 -- naoya_t
- ありがとうございます。 -- ひげぽん
- それでは、PEEK_CHARはcloseします。 -- naoya_t
- naoya_tさん。次のインストラクションお願いします。 -- ココサブ
- knishii2156さん次のインストラクションに着手をお願いします。 -- ひげぽん
- 次のインストラクションは、EQVをやります。 -- knishii2156
- EQVのページを作りました。EQと類似のインストラクションなので、表現はEQと同じようなページになっています。ひらは不要でしたが、勉強のため、週末コードを追ってみます。 -- knishii2156
- ひげぽんさん、EQVのレビューをお願いします。念のため、コードについて、d.hatena.ne.jp/knishii の１１月１７日から２０日まで切り出して貼っています。 -- knishii2156
- EQ,EQVについて、disasm後のインストラクションのリンクを貼りました。また、Scm_Eqvpですが、]]が表示されていたので、その部分を削除しました。ご確認をお願いします。 -- knishii2156
- EQVについてはcloseします。 -- knishii2156
- knishi2156 さん、とりあえず Scm_VMIsA について指摘を。Scm_ClassOf() 関数の定義とか gauche.h にて定義されている SCM_*P マクロなどを確認された方が良いかと思います。あと、ココサブさんからの指摘についても正確に反映できていないように読めます。確認をお願いします。識者な方々、この指摘のビンゴ / ダウト含め、フォロー頂ければ幸いです。 -- yamanetoshi
- 失礼しました。knishii2156 さんの間違いッス -- yamanetoshi
- yamanetoshiさんご苦労様です。確認ありがとうございます。再確認については時間をください。もう一度読み直してみます。 -- knishii2156
- 色々さしでがましい指摘、スミマセン。この件、優先度を下げても良いのではないかと思っています。次のインストラクションもありますし。 -- yamanetoshi
- お手数をおかけしています。今後も指摘をお願いします。皆様のCode Readingの実力に届いていないので、指摘をいただかないと気づかず、それがもとで大きなミスをするかもしれません。 -- knishii2156
- ココサブさん、Reading Gauche/vm/insn/NEGATEのレビューをお願いします。 -- ひげぽん
- 確認しました。良いと思います。 -- ココサブ
- 確認ありがとうございます。 -- ひげぽん
- MEMV 完了しました。次はひげぽんさん。お願いします。ちょｗ。おれ。 -- ひげぽん
- knishii2156さん、伝えるのを忘れていてすいません。まとめ役が担当部分をクローズしたら次のまとめ役の方にバトンを渡すことになっています。よろしくお願いします。 -- ココサブ
- MEMV のレビューをお願いします＞naoya_tさん -- ひげぽｎ?
- IS_Aまとめました。yamanetoshiさんレビューお願いします。 -- ココサブ
- 了解ッス。ちょっと時間下さいまし。 -- yamanetoshi
- レビューコメント投げる前に確認です。レビューの範疇は、この場合には IS_A の記述のみでしょうか？それともボトムアップされてきた関数についての記述も対象でしょうか？もしかすると何度か確認入れているかもしれないですね。自分でも見てみます。 -- yamanetoshi
- とりあえず IS_A について。やはりクラスが再定義された場合の記述は必要ではないでしょうか。 -- yamanetoshi
- 自己フォローです。これ、もう少し考えさせて下さい。あった方が良いのかイレギュラーなソレと見て記述は omit するのか。 -- yamanetoshi
- IS_A はこれで十分なようにも思えます。他の方々のご意見もお伺いしたいところではあります。あと、配下のソレ達についてもコメントがあれば別途投入予定です。 -- yamanetoshi
- レビューの該当部分ですが、多くても、ここ数日で私が編集した関数等のページだけでいいのではないでしょうか？その他は以前チェックされていると思うので。 -- knishii2156
- 確認です。範疇的には Scm_VMIsA とか instance_class_redefinition とかになりますか？他にあれば教えて下さいまし。 -- yamanetoshi
- yamanetoshiさんへ、私が編集した項目は以下の通りです。SCM_CLASSP, Scm_VMIsA, Scm_VMApply2, is_a_cc, instance_class_definitionです。Scm_GenericChangeClassはきっとココサブさんが編集したのではないかと思います。間違いや誤解を生じる表現があると思いますので、念のためご確認ください。 -- knishii2156
- あ、すみません。レビューの範疇に関する質問は自分も newcomer なので確認のためでした。確認した方が良いという意見多数であれば、と考えていますがいかがでしょうか？ > all -- yamanetoshi
- こういうケースでのレビューの範疇については、私もわからないので、教えてください。 -- knishii2156
- レビューの範囲について。ぼくの意見としては IS_A のページが正しく過不足なくまとめられているかがレビューだと思っています。あくまでもひらのページは理解を助けるものと言うことで。もちろん余裕がある場合はひらのページに関しても精査し改善点を指摘することはとても良いことだと思います。 -- ひげぽん
- IS_A OK ってコトで良いと思います。色々時間をかけてしまい、申し訳ないです。又、Scm_VMIsA へのコメントについても問題あれば指摘下さい。ぢつはひら隊長が OK 出してるので無用な指摘だったか、と思い始めていたりします。 -- yamanetoshi
- 了解です。こちらこそレビューに時間をかけさせてすいません。ひらの方に関しては全ページ作成の確認と確認後に指摘した後はしっかり見てなかったので Scm_VMIsA の指摘はありがたいです。 -- ココサブ
- ページ作成ありがとうございます。IS_Aに必要なページが全てできている事を確認しました。いくつか指摘します。 -- ココサブ
- SCM_VMApply2は関数呼び出しと同じようなものです。これはprocを返している辺りとかが理解を邪魔してしまったかもしれません。 -- ココサブ
- Scm_VMIsAの Scm_VMPushCC(is_a_cc, data, 2); によって instance_class_redefinition によるクラスの再定義後に is_a_cc 経由で Scm_VMIsA が呼ばれます。そうすると k->refefined がFALSEになっているはずなので SCM_MAKE_BOOL(Scm_TypeP(obj, klass)); が返される。 -- ココサブ
- 指摘ありがとうございます。こちらでも再度確認し、修正します。 -- knishii2156
- Scm_VMIsAについて修正しました。ココサブさんが指摘された件で、１点気になることがあります。k->redefinedはどこでFALSEに設定されるのか？それがわかりません。Scm_VMIsA関数で特にポインタ操作を行っている部分も見当たらないようなので、ご存知でしたら教えてください。 -- knishii2156
- instance_class_redefinitionにある Scm_VMApply2(SCM_OBJ(&Scm_GenericChangeClass), obj, newc); というのが change-class の呼び出しになっているようです。あとはコードとis-a?の動きあたりからの推測でした。今追いかけていたので、分ったらここかブログに書きます。 -- ココサブ
- 結論としては「新しく定義されたクラスのredefinedはfalseになっていて、instance_class_redefinition(obj, k)でobjのクラスを新しいのに置き換えたためfalseになる」。細かいことはブログ参照でお願いします。新しく疑問が出たら、こっちの方に書いた方がよいでしょうね。 -- ココサブ
- ダイアリー見ました。ココサブさんありがとうございました。後日、時間を作って自分でも、もうちょっと追いかけてみます。 -- knishii2156
- IS_A行きます。ひらが完了してないのがあるのでknishii2156さんお手伝いお願いします。 -- ココサブ
- 了解しました。みなさんに追いつけるよう頑張ります。 -- knishii2156
- ひら開始しました。完了は週末になりそうです。今日のところはScm_VMIsAのページのもとを作るまでです。 -- knishii2156
- knishii2156さんひらのお手伝いありがとうございます。pthread.hなどgaucheディレクトリの下にあるファイルはReading Gauche/pthread.hではなくReading Gauche/gauche/pthread.hのように階層分けをしています。SCM_INTERNAL_MUTEX_LOCKなどのページは一応できていますので、必要であればそちらの加筆・修正にしてReading Gauche/pthread.h/SCM_INTERNAL_MUTEX_LOCKの方は削除していただけますか。編集するときにフォームを空の状態で更新すればページの削除ができます。 -- ココサブ
- ココサブさんに指摘された不要なページを削除しました。ページ作成スクリプトについては次回から使用します。教えていただきありがとうございました。 ひらですが、一応、SCM_CLASSP,Scm_VMIsAが残っていたので、これらの関数についてページを作成しました。確認をお願いします。前回みたいに日本語の表現がよくない部分もあると思いますので。 IS_Aのページについてはまとめ役が編集すると考えていますので、編集していません。 -- knishii2156
- ココサブさん。次のインストラクションをお願いします。（シフト表があたらしくなりました。） -- ひげぽん
- 皆さんへの連絡事項。knishii2156さんには通常の役割分担のサイクルに入っていただこうと思います。サイクル表の方は僕が追記しておきます。 -- ひげぽん
- 現状まとめ。MEMV（ひげぽん）はレビュー待ち。PEEK_CHAR（naoya_tさん）まとめ待ち。EQ（knishi2156さん）もうすぐ close。 -- ひげぽん
- EQについてはおそらくもう修正の必要はなさそうなので、次のインストラクションを読んでいきたいと思っていますが、どうしょうか？もう１つ簡単そうなものをやってから、難易度の高いものをやっていきたいと思っています。 -- knishii2156
- ではもう普通に読んでいただくサイクルに入っていただきましょう。 -- ひげぽん
- 役割についてわからなくなったので教えてください。まとめ役とひらメソッド隊長の違いとは。まとめ役が命令のページを作り、メソッド隊長がその中にある未読の関数他のページを作り読んで行く。ひらメソッド隊長が未読の関数を読み終えた段階で、まとめ役が命令のページをまとめる．．．という認識であっていますでしょうか？ -- knishii2156
- 自分もニューカマーなので、復習がてらフォロー入れてみますね。knishii2156 さんが言われてる事はおおよそビンゴだと思います。ただ、ひらメソッド隊長はあくまで隊長であって、ひらメソッドの手伝いは誰でもして良い、のでしたっけ？ (お手伝いに入った場合、手分けが微妙だったりした覚えあり) -- yamanetoshi
- はい。その理解であっています。まとめ役がページの作成とないように責任を持ちます。（リーダーです）。ひらメソッド隊長はあくまでもお手伝いという感じですね。 -- ひげぽん
- 説明ありがとうございます。まとめ役が主導するということですね。了解しました。 -- knishii2156
- 人も増えたので再告知。この Wikiに書き込みがあった際に指定したアドレスにメールを送ることが可能です。現時点で naoya_t さんと僕が受け取っています。希望者がいればここでお知らせ下さい。 -- ひげぽん
- 試しに受け取ってみます。ご面倒をおかけしますがよろしくです。 -- yamanetoshi
- 設定しました。（以前教えていただいた gmaiのアドレス）。届いているかご確認下さい。 -- ひげぽん
- はやいッスね。着信してます。ってメルアド言い忘れてるあたり、微妙ですね ... -- yamanetoshi
- ひげぽんさん、私にもメールされるように設定をお願いします。メールアドレスは、以前お知らせしたGmailアドレスでお願いします。 -- knishii2156
- knishi2156さん、連絡事項はここに書いていただけますでしょうか。（twitter などに書いてしまうと伝わらない可能性や、他の人に伝わらないなどが起きてしまったり、情報が散逸するので） -- ひげぽん
- すいません。了解しました。以後、Reading Gaucheについてはここに書きます。 -- knishii2156
- ご意見を頂戴したいとかんがえています。BNEQ の_VAL0 レジスタの値とスタックの先頭を eq? に渡し、#f が戻される_という説明の記述は_val0 レジスタの値とスタック先頭に格納されている値が等価 (同じオブジェクトを指している) であるとき_という記述の方が妥当であるように感じています。じつは EQ の記述を見てそう感じたのですが、これって正にココサブさんが言われているように「自分の書いたところは自分のレビュー通るのか不安」ってナニだなぁ、と (とほほ)。みなさまのご意見お伺いしたいと考えています。 -- yamanetoshi
- 現状のままでも特に問題ないかと思いますが、あえて変えるなら。EQ のレビューの文章にも書きましたが、「等価」や「等しい」だと曖昧かもしれません。「eq? の意味で等しい」などの表現に統一し、eq? の説明にリンクを貼るというのはどうでしょう？ eq? の意味を EQ 関連の全てのインストラクションで説明するのは冗長だと思うので。 -- ひげぽん
- EQのレビュー。レビュー隊長ではないですが、knishii2156さんからtwitterでお願いされたので。 -- ココサブ
- EQ obj1 obj2のobj1 obj2は無い方が正しい流れですね。あそこにはSCM_VM_INSN_ARGとかFETCH_LOCATIONとかでPCにある引数がある場合に記入される感じになっています。 -- ココサブ
- 変数比較より、シンボル比較の方が良いかもしれないですね。(eq? max max)とかもできますし。 -- ココサブ
- 修正した方がよさそうなのはこんなところでしょうか。対応お願いします。他は大丈夫だと思います。こういうレビューをしていると自分の書いたところは自分のレビュー通るのか不安になったりしますね。これもレビューをする効果だったりするのかもしれません。 -- ココサブ
- ココサブさんへ、対応ありがとうございます。（レビュー担当はhigeponさんでした。すいません。）さきほど指摘事項についてEQのページを修正しました。 -- knishii2156
- 説明文の_eq?に渡し、等しい場合＃tを、そうでない場合＃fを_という部分に微妙さを感じてしまったのですが、元になってるのは自分がヤッた BNEQ なんですね (とほほ)。SCM_EQ マクロは_オブジェクトとして等価_であれば C の真を戻す、事が分からないとマズいのかな、と思いはじめてたりします。 -- yamanetoshi
- SCM_EQ に「(xとyが同じオブジェクトであるか?)」を追記しました。 -- ココサブ
- 意図するゴールは同じでも表現によって全然意図が変わってみえてしまうこともあると思いますので、違和感があるようでしたら、修正します。 -- knishii2156
- レビューしてみました。変数比較、シンボル比較では比較対象の一部しか表現できていないと思うので、以下のような文章ではどうでしょうか？。「オブジェクト比較のインストラクションの1つ。このインストラクションは VAL0 レジスタに置かれたオブジェクトとスタックの先頭のオブジェクトが eq? の意味で等しい場合＃tを、そうでない場合＃fをVAL0にセットする」。ちなみにR6RSなどでも eq? の例では引数が obj1, obj2 などとなっているのでオブジェクトを比較するという言葉は適切かなと考えています。 -- ひげぽん
- ご確認ありがとうございます。いろいろ勉強になりますね。さきほど、EQのページを修正しました。もし、この表現で問題ないようでしたら、closeしたいと思います。 -- knishii2156
- 説明の記述の eq? の部分に SCM_EQ へのリンクがあった方が良い？これ、今気がついたのですが「eq? の意味で等しい」という文言がリンクになってた方が良いのでしょうか？ -- yamanetoshi
- SCM_EQ へのリンクを入れて close としましょう。 -- ひげぽん
- SCM_EQのリンクを入れました。こんな感じでOKでしょうか？問題なければcloseということに。 -- knishii2156
- naoya_tさん、Reading Gauche/vm/insn/MEMVのレビューをよろしくお願いします。 -- ひげぽん
- Reading Gauche/vm/insn/MEMV やります。Scm_Memv のひらをお願いします。＞ yamanetoshiさん -- ひげぽん
- APPLY 完了という事で、次のまとめ役はひげぽんさんですね。次のインストラクションをお願いします。 -- yamanetoshi
- では knishiii2156 さんに EQ をやっていただきましょう。今回だけ変則的に、ひら隊長はココサブさん、レビューひげぽんで行きましょう。naoya_tさん、yamanetoshiさんは気づいた点があればフォローをお願いします。 -- ひげぽん
- まず、EQについてのページを作成し、編集を開始しました。関連項目以外はEQについての記述は完成していません。遅くとも１１月８日までには完成したいと思っています。NEXT1以外については特に難しいところはなさそうですね。ともかく、やさしいコマンドなのに進行速度が遅くてすいません。 -- knishii2156
- yamanetoshiさんが書いたBNEQのページを参考にして、EQのページをまとめてみました。Scheme初心者ということもあるので、記述等に間違いがあると思います。確認をお願いします。とにかく遅くなってすいません。 -- knishii2156
- knishii2156さんと、みなさんに提案。そろそろ雰囲気がつかめてきたと思うので、knishii2156 さんに EQ 命令を読み進めてもらうのはどうでしょうか？。そこまで複雑ではないですし、さらに感じをつかんでいただくには適切かなと思いました。賛成反対ご意見お聞かせください。 -- ひげぽん
- 不明点をここ、あるいは自分のページを作って頂いてどんどん確認入れていく形 (もちろん識者な方々がそれにフォローを入れてさしあげる必要がありますが) であれば、理解を深めるためのログが残るという意味でも良い資料になると思います。 -- yamanetoshi
- knishii2156がやりたい、やってもよいのであれば読み進めて欲しいです。不明点などはyamanetoshiさんがおっしゃっているような形でフォローしていけばよいと思います。 -- ココサブ
- 自己フォローです。自分も knishii2156 さんがやっても OK とゆーのが前提ッス。 -- yamanetoshi
- 皆様へ、お心遣いありがとうございます。EQの件、やってみます。ただ、knishii2156のハンドル名でページって作れましたっけ？（変なページができると嫌なので試してはいないのですが）。 ３連休は、ココサブさんが読まれたNUMADD2をもう一度読み直していました。どうしてGCの部分が気になり、一日でおわるだろうと思っていましたが、追いかけ始めて道にまよって終わりました。ココサブさんの注意を素直に聞いておけば．．．よかったのに。 とりあえず、今日の夜帰宅後、開始します。もし、仮にページがうまく作れないようでしたら、http://d.hatena.ne.jp/knishiiに途中経過を書いておこうと思います。 -- knishii2156
- 変なページが出来ても簡単に消せますので。気軽にページを作ってみて下さい。 -- ひげぽん
- もう１本・・・PEEK_CHARやります。 -- naoya_t
- ココサブさん、ひら対応(peekc)よろしくお願いします。 -- naoya_t
- ひら対応しました。まとめお願いします。 -- ココサブ
- yamanetoshi さん次のインストラクションをお願いします。 -- ひげぽん
- Reading Gauche/vm/insn/APPLY にしてみます。ココサブさん、ひら対応よろしくです。 -- yamanetoshi
- 了解です。APPLYは深くなりそうだなぁ。 -- ココサブ
- 見切って選んでませんので、手伝います。理解が浅いので、ひらの手伝いはともかく纏めきれるかどうかが微妙ッス。 -- yamanetoshi
- APPLYは面白そうですね。難しかったら皆の力で乗り切りましょう。 -- ひげぽん
- 出来を置いておけばひら自体はそこまで深くなさそうです。ただ、Scm_VMApplyにてTAIL_CALLとRETがからんでくるのが面倒。TAIL_CALLはまとめてないし、RETはまとめきてれないです。RETをまとめるためにも(RETとTAIL_CALLにはそれなりに関係がある)TAIL_CALLを先にまとめるのが良いかもしれないです。 -- ココサブ
- 確かにこれらはすべて関係がありますね。もし良ければ僕が次のローテの時に TAIL_CALL か RET をやりましょうか。 -- ひげぽん
- げ。もしかしてナチュラルに地雷踏んでますか？ (とほほ -- yamanetoshi
- 一応ひらは完了しました。yamanetoshiさん、APPLYはなかなかの難敵かもしれませんね。RETはまとめ役のバトン渡しとは別枠で自分がまとめる必要があるのだと思ってましたが、ひげぽんさんがやってもよいというと心が揺れます。 -- ココサブ
- そうか。ココサブさんが以前やっていつか戻る約束なのでしたね。譲りますｗ。 -- ひげぽん
- まとめ着手します。ちょっと時間かかりそうです。 -- yamanetoshi
- まとめました。ひげぽんさんレビューおねがいします。 -- yamanetoshi
- お疲れさまです。2つ提案があります。(1)NEXT1 直前の PC, VAL0, スタック がどういう値に設定されているかを書きませんか。そうすれば次の命令である TAIL_APPLY の存在が見えてくると思います。(2)Reading Gauche/04.項目列挙/VMインストラクションの表に TAIL_APPLY あたりをやってから戻るという備考を入れませんか。よろしくお願いします。 -- ひげぽん
- 確認です。TAIL_APPLY ではなくて TAIL_CALL ですよね？ -- yamanetoshi
- Scm_VMApply を見れば出てくると思いますが、TAIL_APPLY です。 -- ひげぽん
- 0.8.11を見る限りでは TAIL_CALL になっているようにみえます。 -- ココサブ
- うげ。そうなのですか。失礼しました。0.8.13を見ていたのが仇に。すみません。 -- ひげぽん
- むむむ。色々フォローありがとうございます。なんとゆーかどきどきしてました。でも、0.8.13 だと考え方というか体系が微妙に異なっているのでしょうか。あと、ひげぽんさんのコメント確認前に APPLY の記述も変更しております。ご確認頂けますでしょうか。 -- yamanetoshi
- 混乱させてしまい申し訳ありませんでした。補足の追記情報確認しましたがばっちりだと思います。Reading Gauche/04.項目列挙/VMインストラクション の備考に例の追記をして、次のリーダーにバトンタッチしましょう。 -- ひげぽん
- 了解です。備考の追記もしましたのでバトンタッチなコールしますね。 -- yamanetoshi
- Reading Gauche/vm/insn/LENGTHをやりました。yamanetoshiさんレビューをお願いします。 -- ひげぽん
- 了解しました。 -- yamanetoshi
- コメント一点のみ。使用例の CONST の部分ですが、自分の環境では _0 CONST (1 2 3)_と出力されます。リストが引数として CONST に渡されている形での記述が必要ではないでしょうか。 -- yamanetoshi
- ありがとうございます。閉じ括弧]] の位置が悪く(1 2 3)が消えていました。修正しました。これにて close とします。 -- ひげぽん
- 連チャン指名になりますが、naoya_t さん次のインストラクションもお願いします。エントリ追加頂き、ありがとうございます。 -- yamanetoshi
- REVERSEやります。 -- naoya_t
- naoya_tさん、はじめまして、knishii2156です。Reading Gaucheに参加させていただくことになりました。ココサブさんが読んだNUMADD2でさえ、読めていませんが、みなさんと一緒にReadingできるようがんばります。 -- knishii2156
- knishii2156さんはじめまして！一緒に頑張りましょう。 -- naoya_t
- REVERSEをやりました。yamanetoshiさんレビューお願いします。 -- naoya_t
- naoya_t さん、みなさま。自分の次は、と Reading Gauche/04.項目列挙/VMインストラクション を確認してみたら naoya_t さんがまとめ役となってました (ひげぽんさん曰く「追いついてしまった」との事)。こーゆーケイスで今後どうすべきか、みなさまのご意見をお伺いしたいと思っています。 -- yamanetoshi
- 自分が替わりに？とも思ったのですが、ひげぽんさんの次が自分だったり。でも Branch Not シリーズだったらなんとかなるっちゃなんとかなるのかな、とも。よくよく見たら今後も追い付くケースは頻発しそうですね ... -- yamanetoshi
- こういうことは何回かあると思うので、まずは「追いついたとしてもそのままその人にお願いする」方針をとってみるのはどうでしょうか？。それで身動きが完全にとれなくなった場合はそのときにリセットするなり分担するなりしてみるとか。 -- ひげぽん
- そのままお願いする形は良いかもしれませんね。サイクルを維持できますし。 -- ココサブ
- じゃあそうしましょうか。yamanetoshiさん表に次のリーダー(naoya_tさん)のエントリを追加してバトンタッチして下さいませ。 -- ひげぽん
- そういえばもしかしたら Reading 再開が naoya_t さんに伝わってないかな？ -- ひげぽん
- むむ。自分も微妙なのですが、各作業のフローというかガイドライン的なドキュメントってあったんでしたっけ？なんとなく必要性を感じています (ある事を忘れているのであれば申し訳ないです) 。 -- yamanetoshi
- ちないみに、何に関しての基準が足りないと感じていますでしょうか？ -- ひげぽん
- 今正に、という所だとレビューってどこまでチェックするのか、とかレビュ隊長 OK でクローズしちゃって良いのか、とか？ごめんなさい、どこかに記述があったかどうかを調べずに指摘しています。 -- yamanetoshi
- でもソレ的なナニ (フローとかドキュメントとか) を用意するよりも、がんがん読んで成果を投入した方が良いよな、とも思ってたり。 -- yamanetoshi
- リーダーとレビュー隊長がOKなら良いと思います。あとから修正できるのでリーダーはレビュー隊長からOKがでたら、自信を持って次の人にバトンタッチしても良いと思います。（ちなみに今回はバトンタッチの前に knishiiさんに理解に問題ないかフォローする方が良いかも） -- ひげぽん
- BNEQ をヤッてみます。 -- yamanetoshi
- こちらもひら対応不要な模様です。久しぶりなので微妙ッス。ココサブさん、みなさま、レビューおねがいします。 -- yamanetoshi
- 関連項目の重複と、リンク先が違っているところがあったので直しました。確認お願いします。説明の方はOKだと思います。 -- ココサブ
- 丁寧な確認、ありがとうございます。確認してみます。 -- yamanetoshi
- リンク先違いは致命的なミスだった模様。ご指摘ありがとうございます。関連項目云々はスデに確認不可能なのでしょうか。 -- yamanetoshi
- 差分で確認できると思います。NEXT1が2つあったので1つ削除しました。 -- ココサブ
- 修正を確認しました。どうもありがとうございました。これで close しちゃって良いのでしたっけ? -- yamanetoshi
- close しちゃっていいでしょう。他の方からの指摘待ちでもいいかもしれませんが, -- ココサブ
- knishii2156 さん、もし可能であればご確認頂いてコメント下さいませ。確認微妙なようであれば、その旨コメント頂けますでしょうか。 -- yamanetoshi
- yamanetoshiさん、申し訳ないです。全然追いついていません。とりあえず、BNEQは手をだしていません。ごめんなさい。 -- knishii2156
- 大丈夫ですよ♪もう少しネカせておきますので、もし良ければ確認入れてみて下さいな。 -- yamanetoshi
- ではいったん close しましょう。次の人へのバトンタッチをお願いします。 -- ひげぽん
- 了解なんですが、次のまとめ役は naoya_t さん？なのでしょうか ... -- yamanetoshi
- 追いついてしまいましたね。追いついた場合どうするか？というのを naoya_t さん含めて皆さんに投げてみると良いと思います。（ここだと読まれなそうなので新しいコメントとして） -- ひげぽん
- NUMADD2をひらする必要もなかったので、まとめちゃいました。naoya_tさん、他皆様レビューお願いします。 -- ココサブ
- ココサブさんへ、今、vm.c case(SCM_VM_NUMADD2)のルーチンのScm_MakeInteger()の前まで読みました。馬鹿正直に読んでしまいました。ほとんどリストにまとめられていたんですよね。でもまあ、レビューということなので、もう少し読んでいきます。それにしても、３２ビット整数を２ビットシフトさせて３０ビットにして、加算後、３２ビットに戻すのか？ここがわかりません。なぜ？ -- knishii2156
- knishi2156 さん、はじめまして。yamanetoshi と言います。自分も gauche の理解は微妙なのですが、いくつかヒントというかコメントを投下しておきますね。gauche.h のコメントも、なのですが RubyHackingGuide の 2 章も見てみてはいかがでしょうか。(http://i.loveruby.net/ja/rhg/book/object.html) # もしかしたらナチュラルにハズしてるかも、と思いつつ ... -- yamanetoshi
- Schemeの世界のオブジェクト（今回はInteger）がメモリ上でどう表現されているか？という問題ですね。下位2bitはオブジェクトの種類を表すタグビットとなっています。gauche.h の TAG STRUCTURE あたりを見ると良いかも。 -- ひげぽん
- Reading Gauche/gauche.h/ScmObj/タグについても参考になると思います。 -- ココサブ
- yamanetoshiさん、はじめまして。コメントありがとうございます。早速読んでみます。それにしても、早く追いつかねば。ひげぽんさん、たしかにgauche.hのTAG STRUCTUREに説明がありますね。気づいてなかったです。ココザブさんへ、なるほど、こうなっているんですね。 -- knishii2156
- 今、NUMADD2のルーチンで、make_bignum関数で呼び出されているScm_Error関数まで到達。Scm_Errorが深くて苦労しています。見るとgcのファイルのデータまで呼び出しているんですね。ひらメソッドで皆さんがまとめた内容だけみていれば楽なのですが、それをやるとレビューにならないし難しいところですね。 ちなみに、DCL_LOCK_STATE - gc/include/private/gc_locks.hで、たとえば、PCR_sigset_tなどはどこで定義されているのでしょうか？うーんわからん。 -- knishii2156
- まとめたドキュメント読んじゃっても問題はないですよ。それとGCなんですが、「暫く保留にして、読まないとGaucheが理解できなさそうなら先に読む。大丈夫そうならブラックボックスということで後で読む -- naoya_t 2007-09-26 (水) 23:56:25」という方針で行っています。Bohem GCを読んでるサイトもあるようで http://www.boehmgc.net/index.php?DCL_LOCK_STATE()%2Fgc-7.1 でDCL_LOCK_STATEを読んでますね。 -- ココサブ
- 大丈夫だと思います。ただ、Scm_MakeInteger, Scm_Add関数については読み込んでいません。途中までは読んだのですが、端からつぎつぎ忘れていってしまっています。下の階層の関数名から、とりあえず、意味するところはココサブさんが書かれた内容で問題ないように思います。 -- knishii2156
- 同じく close をお願いします。 -- ひげぽん
- NUMADD2を close しました。ローテーション的にはひげぽんさんですね。ひげぽんさん(?)お願いします。 -- ココサブ
- では shibuya.lisp 無事終了したので再開しましょう。3つ同時並行で、naoya_tさん、yamanetoshiさん、ココサブさんインストラクションを選んで進めて下さい。なお knishii2156さんは最初の3インストラクションはレビューに参加していただく形で進めましょう。（レビューに参加すれば必然的に読むことにもつながりますし理解できなければそこでみなで相談できるので）。3回レビュー参加後、簡単そうなインストラクションを担当していただく形で読み進めサイクルに参加してもらいましょう。 -- ひげぽん
- a -- knishii2156
- 上のコメントはタイプミスです。進め方のイメージはココサブさんの説明でつかめました。これから読む３つのインストラクションのレビューに参加して力をつけていきます。もっともPukiWikiを使ったことがないので、まずはそれを勉強ですかね。そうしないとコードを読めてもページに書けないできないので。お手数をおかけしますが、よろしくお願いします。 -- knishii2156
- Reading Gaucheへの参加を希望します。ひげぽんさん、ココサブさんよろしくお願いします。 -- knishii2156
- knishi2156さんようこそ。ココサブさんのLTで人が増えた！。ココサブさんの手柄（？）なので、ココサブさん現状どう進めているかを軽く knishii さんに説明してもらえると助かります。その後 knishii さんにどうやって参加していただくか考えましょう。 -- ひげぽん
- 参加ありがとうございます！今はGauche VMの命令(PUSHとかCALLとか)は具体的にどんなことをしているのかをまとめています。VMインストラクションにまとめた命令とまとめていない命令が列挙してあります。まとめ方ですが、役割を命令ごとに分担して進めています。役割は「まとめ役」、「ひらメソッド隊長」、「レビュー隊長」の3つなります。それをひげぽんさん, naoya_tさん, yamanetoshiさん, 私の4人で役割を交代しながら進めています。まず、「まとめ役」が読む命令のページを作成します。未読の関数(シンボル)があった場合そこを「ひらメソッド隊長」を中心にしてひらメソッドで読んでいきます。未読関数がなくなった辺りで本格的にページを「まとめ役」がまとめ、その後「レビュー隊長」中心にして作成したページのレビューを行います。レビューを元に修正などしたりして、ページが完成完成したら次の命令に進むといった感じです。 -- ココサブ
- Readingについてのイメージが大体つかめました。詳細は実際にやってみないとわからないと思いますので、その都度質問します。初心者なので、作業のアサインがしにくかもしれませんが、よろしくお願いします。 -- knishii2156
- 今取り掛かっているインストラクションはないはずです。残りのインストラクションをまとめ終えるのが当面の目標だと思います。並行していくつ読んでいくかが課題でしょうか。 -- ココサブ
- 実践期間がまだ短いので3つ並行で進めればいいかと私は思います。 -- ココサブ
- 自分もそのままで良いと思います。ついていけるかどうか微妙ですが ... -- yamanetoshi
- さて、皆さん再開したいのですが誰か現状を整理してもらえると助かります。分からなくなってきました。 -- ひげぽん
- 上の書き込み、ひげぽんさん発だと思ってました。。。色々と混乱させちゃってるみたいで申し訳ないです。 -- yamanetoshi
- というわけで yamanetoshi さんが VEC_SETI系に完全に納得いただいたら先に進みましょう。ゆっくり正しく理解したいですね。 -- ひげぽん
- 微妙な止め方をしてしまったようで恐縮至極です。色々とフォロー頂き、ありがとうございます。 -- yamanetoshi
- いえいえ。理解の一助に慣れたならうれしいです。 -- ひげぽん
- _I の表記についてですが、(1)即値埋め込みによる引数と、(2)スタックやVAL0で渡される引数を記法を分けるというのはどうでしょうか。今後は記法を分けて書く。これまでのものは気付いたときにゆっくり直していく。という方針。 -- ひげぽん
- VAL0, スタック経由の引数は斜体。即値埋め込みはノーマルとか。 -- ひげぽん
- 即値埋め込みの記法 CONSTI(num)
- 引数の記法 VEC_SETI(vec, ind, val[VAL0])
- VEC_SET と VEC_SETI を例に取ると、どういった条件でそう翻訳されるか、という事を理解していないのが一番の敗因だと思います (< 自分)。コメント投入時点もそう思っていたのですが、手間をかけて表記を変更するほどの事は無いと思っています。 -- yamanetoshi
- コメントの書き方が言葉足らずでした。。。しかもその後のコメントで_変数と定数_とか書いてますが、その根拠も不明ッス。 -- yamanetoshi
- コードを見てて、なんでこんなコトになってるんだろう、という率直な疑問からのコメントでした。 -- yamanetoshi
- では「VEC_SET と VEC_SETI」はどういう条件で翻訳されるのかをみなで調べましょう！ -- ひげぽん
- compile.scm の pass3/asm-vec-set が見るべきところですね。 -- ひげぽん
- そうですね。 k が添え字になるんでしょうか。それで、「kが定数であり数値として問題なければ VEC_SETI にする」といったところでしょうか。 -- ココサブ
- 僕なりの答えを書いておきます。まず Gache VM ではコンパイルで出力される実行命令列は同じ動きをするコードであれば「短い方が良い」「スタックに引数を積まない方が良い」という前提があります。これはその方がコードの実行が速いからです。例えば vector-set! がループの内側で100万回実行されることを想像すると「短い方がよい」というのは理解しやすいでしょう。早速 VEC_SET/VEC_SETI の関係を見ていきます。話は簡単で VEC_SETI は VEC_SET の短い版です。つまり「ある特定の条件下では VEC_SET の代わりに短い版の VEC_SETI が利用できる」というのがここでのメインの話です。「特定の条件」は2つ。一つ目は添え字 (vector-set! v k value) でいうところの k が定数であること。もう一つは k がある範囲の整数であることです。まず定数について、定数でない場合とはどういう場合でしょうか？(vector-set! v 3 4) は k = 3 で定数です。逆に (vector-set! v index 4) は定数ではないですね。定数でないということは「コンパイル時に値は分からない」ということなので「スタックに引数として積まれたもの」や「VAL0におかれたもの 」に「実行時に」アクセスしなければなりません。さて定数の場合は命令を短くすることが出来るのはなぜでしょうか。1命令に使う1ワードという単位のデータ列の中にこっそり定数を埋め込めるからです。これはコンパイル時に値が決まっているから出来ることです。埋め込むというのは具体的には通常の1ワード（＝32bitの）のバイト列の中に命令の種類を表すビット列と引数である定数を表すビット列を詰め込むことを指します。「k がある範囲の整数である」という条件も埋め込まれることから来る制限で例えば (vector-set! v 0xffffffff 4) などでは、どう考えても添え字 k が 1ワードに詰め込めないので範囲を指定しているわけです。まとめると「命令実行高速化のため VEC_SET の添え字 k が定数かつ特定の範囲に収まるときに代わり VEC_SETI を使う」というのが僕の考えです。 -- ひげぽん
- 成程ッスね。ってか、VM が理解するのが word サイズな命令だ、ってコトを知らなかった時点でダウトな気がしています。。。どうもありがとうございました。 -- yamanetoshi
- さて今は naoya_t さんが CONSTF、CONSTU のレビューが残るのみかな？ -- ひげぽん
- 今進行中のものにケリがついたら仕切り直しませんか。（何となくその方がよい気がする） -- ひげぽん
- _Iで終わる即値埋め込み系インストラクション_の説明、というコメントについては仕切り直しの時にご検討頂くという方向でお願いしたいと思います。 -- yamanetoshi
- であれば naoya_t さんまとめの VEC_* と LIST2VEC、APP_VEC はレビュー隊長としては OK 認定と考えています -- yamanetoshi
- ちょっと止まっていますね。みなさん現在の状態を確認しましょう。 -- ひげぽん
- う。止めてますね。残りの LIST2VEC と APP_VEC は問題ないと思います。 -- yamanetoshi
- VEC_LEN / VEC_REF / VEC_SET / VEC_REFI / VEC_SETI までのコメントを以下に。 -- yamanetoshi
- VEC_SET について、スタックから取り出す順の明示は必要ないでしょうか。 -- yamanetoshi
- VEC_SET について_セットして返る_という表現が VEC_REF の系列と微妙に異なるのが気になります。 -- yamanetoshi
- VEC_SETI では、ind の説明は不要でしょうか？ -- yamanetoshi
- この「説明」というのはインストラクションに埋め込まれた即値である旨でしょうか。 -- naoya_t
- ここは自分の_ワカッテナイ_部分なコメントです。インストラクション込み、なソレ、というのが分かりやすければ、という素人目線が入ったコメントなんで修正不要とお考えであればその通りで構いませんので。 -- yamanetoshi
- それはIで終わる即値埋め込み系インストラクションのすべてについて言える（＝直すなら全部直したほうがいい）と思うので、他の皆さんにも意見を伺いたいところです。 -- naoya_t
- ちょっと面倒そうですが対応に賛成です。確かにインストラクション込みって分かりづらいですね。 -- ココサブ
- 即値が埋め込まれている命令に関する記述がどこかに一つあれば良いようにも思います ... -- yamanetoshi
- SET と SETI とか REF と REFI の違いが面白いですね。変数か定数かで云々というあたり -- yamanetoshi
- 残りは明日でご勘弁下さひ。 -- yamanetoshi
- naoya_tさん次のインストラクションをお願いします。あれ？一周した？ -- ひげぽん
- 一周しましたね。とりあえずVEC残りをまとめます。 -- naoya_t
- CONST系の残りをやります。ひらは不要そうです。 -- ココサブ
- ASSQ,ASSVのレビューをお願いします。>ココサブさん -- ひげぽん
- 「引数で与えられた item を」のところが読んでみてひっかかりました。「スタックから取り出した item と」のように 1. 引数を具体的にスタックで説明する 2. 接続詞が「を」だと変に感じる。この文章の流れだと「と」かなと思う。 -- ココサブ
- 2の方は主観が入っているかもしれないです。yamanetoshiさん, naoya_tさんからの意見を期待。 -- ココサブ
- ありがとうございます。ASSQをちょっと変えてみました。いかがでしょうか。 -- ひげぽん
- 良いと思います。 -- ココサブ
- ありがとうございます。ASSVにも適用しました。 -- ひげぽん
- Scm_Assv のひらをお願いいたしますです。>yamanetoshi さん -- ひげぽん
- APPEND のレビューおねがいします。> ひげぽんさん -- yamanetoshi
- naoya_tさんAPPENDのひらをよろしくお願いします。 -- yamanetoshi
- まとめます。 -- ひげぽん
- 皆さんありがとうございます。では同時進行3つを試してみましょう。naoya_tさんのインストラクションが終わったら仕切り直しで。ローテーションはきっと誰かが考えてくれる（？） -- ひげぽん
- 先日ひげぽんさんに代打してもらった分１つ行きます。インストラクション選定中。→VECシリーズの残りをまとめて行きます。 -- naoya_t
- GREF_PUSH 一応完了です。naoya_t さんレビューおねがいします。 -- yamanetoshi
- ローテーションについて。4人をそれぞれ A, B, C, D とする。満たしたい条件は以下3 つ-- ひげぽん
- 同時に進行するのは2組
- 「まとめ」と「レビュアー」の組が毎回同じであることを防ぐ。
- 一人の人に連続して負荷がかからないようにする。
今のローテーションルールでは3つめが満たされていなくて微妙という意見がある。
さてどうするか？
やってみると分かるが、1つめの条件と、２つめの条件を満たそうとすると３つめを満たすのは難しい。
となると話は簡単で以下の選択肢のどれかを選ぶことになる。
- 同時に進行する数を変える
- ペアが同じやり方に戻す
- 多少一人に対して連続しても許容する
さてみなさんご意見をお聞かせ下さい。僕は過激に同時進行３つにするという案に1票。
- こないだ書いたローテーションルールは、全組み合わせを考えても i, ii, iii のすべてを満たすのが無理ということが分かった上での案です。で、同時進行最大４つ、平均３つぐらいというのもありかもしれません。そろそろ復帰します。 -- naoya_t
- うーん、難しいですね。同時進行の数を、というのは反対ではないのですが、自分的に心配なのは yamanetoshi の gauche に関する根本的な知識の薄さだったりしています。(とほほ -- yamanetoshi
- 同時進行数を増やすde -- ココサブ
- 同時進行数を増やすでいいと思います。 -- ココサブ
- CURIN, CUROUT, CURERR作成しました。ひげぽんさんレビューお願いします。 -- ココサブ
- お疲れ様です。目を通しました。良いと思います。 -- ひげぽん
- ありがとうございます。完了にします。yamanetoshiさん次のインストラクションお願いします。(ローテーション的にはそうなってますよね・・・?) -- ココサブ
- 了解です。ちょっと時間下さいまし。 -- yamanetoshi
- GREF_PUSH ヤります。そろそろ残存するインストラクションのまとめは手に余るかも、です。。。 -- yamanetoshi
- お疲れ様です。もしも残存するインストラクションが厳しかったら、ちょっとやり方を変えてみなであれこれやるのもいいかもしれませんね。とりあえずもしも厳しそうでしたら。もう一度声を上げていただけると助かります。 -- ひげぽん
- どうもありがとうございます。ちょっと言ってるコト弱いッスね ... (とほほほ -- yamanetoshi
- みなであれこれやりましょう。 -- naoya_t
- ココサブさん次のインストラクションおねがいします。ローテーション的に若干の (?) 微妙さを感じていたりします。(レビューア と次のまとめ役が同一なあたり) -- yamanetoshi
- そうですね。もっと良い案募集。 -- ひげぽん
- ごめんなさい。微妙と言いつつ今より良い解は無さげな事に気づいてたりします。失礼しました (とほほ -- yamanetoshi
- CURIN, CUROUT, CURERRをやります。 -- ココサブ
- naoyta_t?さんの代打でNOT をやりました。ココサブさんレビューをお願いします。 -- ひげぽん
- 確認しました。オッケーです。 -- ココサブ
- はやっ。ありがとうございます。さて次はどうしよう。 -- ひげぽん
- CONSTI_PUSH、CONSTF_PUSH、CONSTN_PUSH 作成完了しとります。レビューお願いします。 > naoya_t さん -- yamanetoshi
- あと、一連の PUSH シリーズについて TAIL-CALL のリンク先も修正してます。 -- yamanetoshi
- TAIL-CALL のリンク先ありがとうございます。 -- ひげぽん
- 僕が激しく流れを止めてますね。すみません21日までちょっとさわれないです。 -- naoya_t
- 了解です。では僕が naoya_t さんの部分を引き受けます。 -- ひげぽん
- naoya_tさんの代わりにレビューさせていただきます。確認しましたが OKです。 CONSTF_PUSH などは Mosh でも真似したいなあ。次の指名をお願いします。＞yamanetoshiさん -- ひげぽん
- 了解です。レビューありがとうございました。次ココサブさんなんですね。回し方が微妙な気がしてきましたが、とりあえずコールしておきますね。 -- yamanetoshi
- ココサブさんの代わりに合図を出します。naoya_tさん次のインストラクションお願いします。 -- ひげぽん
- SETTER 配下のレビューコメントを以下に -- yamanetoshi
- 説明の記述はデフォルトな動作に関するもののみで良いのでしょうか? SETTER の説明はこれで問題ないかと思いますが、Scm_Setter については ... と感じてしまいました。 -- yamanetoshi
- ただ、追い掛けてみたら proc が ScmProcedure でない場合のナニはエラー処理なんで Scm_Setter についてもこれで問題ないようにも思えます。 -- yamanetoshi
- 一般化された set! については知りませんでした。勉強になります。 -- yamanetoshi
- SETTER における_プロシージャのsetterメソッド_という表現 (これは Scm_Setter についても同様 ?) に若干の違和感を感じています。具体的にどうすべき、という指摘ができないので修正不要と判断されればこのままでも構いません。 -- yamanetoshi
- レビューありがとうございます。_プロシージャのsetterメソッド_という表現は確かに違和感を感じるので_プロシージャオブジェクトと対応付けられているsetterメソッド_と表現を変えてみました。どうでしょうか。また、1週間ほどここには立ち寄らないと思います。申し訳ありませんがよろしくお願いします。 -- ココサブ
- 良いと思います。次の合図はどうなるのだろう、と思いつつ自分のソレに取りかかります。 -- yamanetoshi
- yamanetoshi さん次のインストラクションをお願いします。 -- ひげぽん
- BT と BNNULL をやりましたのでレビューをお願いします。＞ココサブさん -- ひげぽん
- 確かにcompile.scmをみてもBTが無いようなので、使用例の 「見えるが違うかな」 のところを 「見える」 にしても良いかと思います。 -- ココサブ
- BNNULLの関連項目の変更・追記しました。 -- ココサブ
- BNNULLの説明のNULL以外のとき, NULLのときの要素(オペランドに関する記述, VAL0レジスタに関する記述)の順序を統一した方が分かりやすいかと思います。 -- ココサブ
- 以上細かい指摘ばかりですが、BTとBNNULLのレビューです。 -- ココサブ
- 丁寧なレビューをありがとうございます。ご指摘の点を修正しました。次のインストラクションに行きましょう。 -- ひげぽん
- SETTERやります。 -- ココサブ
- vectorシリーズ行きます。まずはVECから。 -- naoya_t
- すみません。yamanetoshiさんと並行して、もう一本Reading が走ると思うんですが次は誰でしょう？。ひょっとして僕が止めている？ -- ひげぽん
- ぼくの認識では naoya_t さんではないかと。CONS 修正後に start になるのでしょうか。ローテ的には (1) のはずですので、次は naoya_t さんとひげぽんさん？ひら略でいきなり review になったので ... -- yamanetoshi
- naoya_t / yamanetoshi / ひげぽん組ですね。すみません。インストラクション決めます。 -- naoya_t
- とりあえず自分の番なので CONS_PUSH を投入してみました。今回コレのみ、という事でご勘弁下さひ。あと、(1) から順に、だとレビュー対応は naoya_t さんで宜しいのでしょうか。 -- yamanetoshi
- いや本来１つずつでいいんですよww／レビュー担当了解です。 -- naoya_t
- CONSのように、VAL0とスタックから取られた値のそれぞれどちらがcar,cdrになるのか明記したほうが良いかなと思います。 -- naoya_t
- CONS をパクッてやろうと思ったのですが、微妙さを感じてしまい、表現を微妙に変えていたりします。どちらが良いか精査おねがいできますでしょうか > naoya_t さん、みなさま -- yamanetoshi
- 微妙な差ではありますがスタックの一番上の値をpopする動作を明示している点で、yamanetoshi方式がよいと思います。CONSもそうしたいです。皆さん異存はありませんか？ -- naoya_t
- 異存ありませんです。よっぽど大きな変更でなければ、基本的にレビュー担当（naoya_tさん）とページ担当（yamanetoshiさん）が合意に至れば決めてしまってかまわないと思います。 -- ひげぽん
- あとリンク先のページ名をTAIL_ に統一しましょう（今すでにページのあるTAIL-RECEIVEも）。これはやっておきます。 -- naoya_t
- このコメントの意図を図りかねております。表示を _ に統一、という意味でしょうか？いちいち > とかを使わなくても良い形にする、という意図？ -- yamanetoshi
- む。使用例の部分で手戻りがある、という意味ッスか？違うかなぁ。 -- yamanetoshi
- 私はページ名は _ で統一、使用例の表記は - のままと理解しました。自分がまとめ役のところは一応見直してみました。 -- ココサブ
- ページ名を _ で統一し、使用例というかdisasmでダンプした部分だけ - 表示で > でリンク、です。ココサブさんが正解です。 -- naoya_t
- 自分は一応この方向で修正済みだった思っていたもので ... もし微妙な部分があればご指摘下さいまし。 -- yamanetoshi
- CONS_PUSHは閉じてよいと思います。次いきましょう。 -- naoya_t
- ありがとうございます。では close しますね。次はひげぽんさんがまとめ役でしょうか。 -- yamanetoshi
- では次 yamanetoshi さんお願いします？（あっている？） -- ひげぽん
- ところで自分がいつも同じ人をレビューし、同じ人にレビューされるのは刺激が足りないのでその辺も回転させたいのですがどうでしょうか。（うまい回転方法は思いついていない） -- ひげぽん
- WRITE-CHAR 行きます。 -- ひげぽん
- naoya_tさんレビューをお願いします。 -- ひげぽん
- 了解です。（ひら／レビュー隊長はとりあえず次回から逆回転とか？） -- naoya_t
- 使用例の、n=2（出力ポートを指定する場合）の引数の順序が逆ですね：Function: write-char char &optional port -- naoya_t
- 失礼しました。修正いたしました。 -- ひげぽん
- どうもありがとうございます。あと、使用例（n=2）のVM命令への展開順が違うようです。 -- naoya_t
- あわわすみません。修正しました。 -- ひげぽん
- 確認しました。良いと思います。typoひとつ直しました。 -- naoya_t
- LIST-STAR のコメントです。これは LIST にも言える事なのですが、一つ目とか二つ目という表現にちょっとひっかかってしまいます。_先頭から_とか_末端から_という修飾語は不要でしょうか？他には特にコメントはありません。てーか、list* なんて命令があったのさえ知りませんでした。勉強になります。 -- yamanetoshi
- LISTの概要を下敷きにしたのがバレバレですが、一つ目二つ目というのは無くてもよいかもしれません。ちょっと変えてみましたが如何でしょうか。 -- naoya_t
- OK だと思います。LIST もこうなってれば、と思うのですがアレはあれでレビュー済みなんでしょうしねぇ。 -- yamanetoshi
- ありがとうございます。LISTの方の書き換えについては個人的には賛成ですが、当時のレビュー隊長のひげぽんさんのご意見を伺うのがよいかと。 -- naoya_t
- LIST_STAR にあわせる形で良いと思います。 -- ひげぽん
- LIST_STAR にあわせる形に直してみました。確認お願いします。 -- ココサブ
- OKです。 -- ひげぽん
- どうもです。 -- ココサブ
- m/LSET[0-4]?/ 行きます -- ココサブ
- LREFと対になっていた命令だったこともあり形になりました。naoya_tさんに感謝です。ひげぽんさんレビューお願いします。 -- ココサブ
- はやっ。レビューさせていただきました。問題ないと思います。 -- ひげぽん
- レビューありがとうございます。完了にします。ひげぽんさん次のインストラクション選定お願いします。 -- ココサブ
- 一応修正完了したので、ココサブさんにバトンを渡したいと思っています。次のインストラクション選定をよろしくです。 -- yamanetoshi
- インストラクション選びます。＜暫くお待ちください＞ -- naoya_t
- インストラクションなページの名前付けについて確認したい事があります。自分は vm.c のマクロの名前に沿ってページの名前を付けていましたが、実際のインストラクションとは異なる名前になっているようです (disasm で出力されたインストラクションのリンクを作成している時点で判明)。例えば CAR-PUSH というインストラクションのページ名を CAR_PUSH としています。以下の対処のどちらが望ましいと思われるか、ご意見をお伺いしたいと思います。 -- yamanetoshi
- ページの名前をインストラクションと合わせる。確かにインストラクションとしては _ (アンダースコア) ではなくって - (ダッシュ) だよな、と。 -- yamanetoshi
- ページの名前はそのままにしておいて、ハイパーリンクな部分で誤魔化す。CAR-PUSH みたいな感じで。 -- yamanetoshi
- （最初にこの問題に当たったのは僕かな・・・）C言語的に(VM_)CAR_PUSHなので /vm/insn/CAR_PUSH みたいにページを作って、ハイパーリンクでCAR-PUSH、で良いかと思います。 -- naoya_t
- いえ。自分も vm.c の定義をそのまま使ってました。こっちの方が修正は楽なので、自分的にはこっちなんですよね (わら -- yamanetoshi
- みなさまの確認を頂けておりませんが、とりあえずハイパーリンクで、な方向で修正着手します。 -- yamanetoshi
- 統一基準をReading Gauche/04.項目列挙/VMインストラクションのページに書いておきました。使用例ではdisasm出力に準じてハイフン、それ以外ではCソースに準じて下線としましょう。 -- naoya_t
- LREF*_PUSH の一連のナニを投入しました。ココサブさんをはじめ皆様方、レビューよろしくです。 -- yamanetoshi
- お疲れ様です。軽く目を通してみました。良いのではないでしょうか。LREF と PUSH の合成命令であることを明記すると良いかもしれません。 -- ひげぽん
- 使用例のインストラクションはそのインストラクションのページに jmp できるようになってないといけないですね。 -- yamanetoshi
- 全てに目を通しました。内容的にはオッケーだと思います。yamanetoshi さんがおっしゃるようにインストラクションへのリンクをつけると便利になると思います。 -- ココサブ
- 現時点のリーダーは yamanetoshiさん、naoya_tさんです。（自分が見失っていたのでメモ） -- ひげぽん
- RECEIVEのレビューがまだですが、だいぶ固まっているので、次のインストラクションをお願いします＞yamanetoshiさん -- ひげぽん
- MEMQ行きます。 -- naoya_t
- RECEIVE行きます。 -- ひげぽん
- dynamic-windの一部のReading Gauche/vm.c/dynwind_after_ccを読んでいたら、VAL0も多値に含まれている(VAL0は多値の一つ目?)ような記述になっていました。VALUESの「values は最大でSCM_VM_MAX_VALUES - 1 個の多値をサポートし、それ以上ではエラーとなる。（現時点では19個）」という説明の再検討が必要かもしれません。 -- ココサブ
- VAL0 が多値の一部という認識は正しいです。ただし (values 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0) をやるとエラーになり一つ減らすと OK なので 19個が現時点で最大なのはあっている気がします。 -- ひげぽん
- 「SCM_LIMIT_MODULE_MUTATIONフラグが立っているため他のモジュールの束縛を探索しないため」の文章において「ため」が続いているのを直したほうがよいかもしれません。また GLOCが既にあるかどうかの件は、set! の式がコンパイルされたときに既に、束縛が存在しているかどうかでコンパイル結果が違うというニュアンスの文章が入るともっと良くなって理解の助けになるかも。 -- ひげぽん
- レビューありがとうございます。「ため」が続いている所は表現を少し変えてみました。GLOCに関しては手続きオブジェクト自体を変更しているイメージで捕らえています。そちらも少し追加しているので再びレビューお願いします。 -- ココサブ
- 細かい指摘にもかかわらず修正ありがとうございます。良いと思います。 -- ひげぽん
- 次行きましょう。 -- ひげぽん
- GSET は完了にしました。次はひげぽんさんがまとめ役ですね。 -- ココサブ
- GSETまとめてみました。ひげぽんさん他みなさんレビューお願いします。 -- ココサブ
- 勉強になります。細かい指摘ですが、説明の項で_既に symbol がGLOCであればそのまま上書きする事ができる。そのため束縛の探索を減らすことできる。_という文章の最後の部分は_そのため束縛の探索を減らすことができる。_ではないかと思います。 -- yamanetoshi
- おお、そうですね。指摘ありがとうございます。修正しました。 -- ココサブ
- PUSHシリーズが終わっているので先行して GSET やります。 -- ココサブ
- naoya_tさんDEFINEのレビューをお願いします。 -- ひげぽん
- そして次のインストラクションの開始も待たれています。＞naoya_tさん。引っ越しでお忙しいと思うのでパスなり委譲なりの手段もあるのでお返事待っていますー。 -- ひげぽん
- 復活しました。DEFINEのレビューと次のインストラクション選定に着手します。 -- naoya_t
- 拝見しました。良いと思います。一点、関連項目にFETCH_OPERANDへのリンクが２つあると思ったら片方はVM_ASSERTにリンクしていました。VM_ASSERTと表示するのが正しそうなので修正しておきました。 -- naoya_t
- レビューありがとうございます。また修正もやっていただき助かります。では次のインストラクションに行きましょう。 -- ひげぽん
- DEFINEのひらの手伝いをよろしくお願いします。<(_ _)>＞ココサブさん。 -- ひげぽん
- 了解です。ちまちま進めていきます。 -- ココサブ
- 一応ひら完了しました -- ココサブ
- お疲れ様です。ありがとうございます。 -- ひげぽん
- DEFINE流し読みしたのですが気づいた点が2つ -- ココサブ
- define-const -> define-constant -- ココサブ
- 「実装上の違いは define-const が GLOC の setter を使わないこと。」はどっちかというと逆で define-const は特別なsetterを使うからで、defineでは特にsetterを定めていないという感じかもです。 -- ココサブ
- ご指摘ありがとうございます。修正しました。 -- ひげぽん
- Reading Gauche/04.項目列挙/VMインストラクション の表に今回の分と次回以降のローテーションを記入しました。基本このサイクルでまわせたらと思います。お気づきの点があればご指摘をお願いします。 -- ひげぽん
- PUSH シリーズで。とりあえず CAR_PUSH、CDR_PUSH、CAAR_PUSH、CADR_PUSH、CDAR_PUSH、CDDR_PUSH でヤッてみます。(微妙に eazy でスミマセン -- yamanetoshi
- ひげぽんさんの隊長アナウンスを待って、こちらの隊長をナニした方が良さげですよね？ -- yamanetoshi
- お待たせしました。例の表に書いてあるとおりの隊長で PUSH シリーズの開始をお願いします。 -- ひげぽん
- 了解しました。 -- yamanetoshi
- ひら対応は必要なかった模様です。それも含め、ココサブ隊長及びみなさま、レビューよろしくです。 -- yamanetoshi
- 見ました。完了にしてオッケーだと思います。 -- ココサブ
- DEFINE行きます。 -- ひげぽん
- ローテーションが一巡したようなので、各セクションの隊長任命お願いします。多分yamanetoshiさんがもう１つインストラクションを始めていいんじゃないかと思いますが -- naoya_t
- NUMシリーズ行きます。とりあえずNUMADDIから。 -- naoya_t
- ひら隊長higeponさんよろしく・・・と思ったら特にやる事なさそう・・・なのでまとめに入ります。 -- naoya_t
- NUMADDIまとめました。ココサブさん他みなさんレビューお願いします。 -- naoya_t
- 1点だけ気になったことがあります。命令に12bit使っている訳ではないのでそこを「命令とデータをあわせても32bitで1命令なので・・・」くらいにして良いかなと思いました。 -- ココサブ
- そうでした！空白の4ビットがあるんだった＞12bitの件 -- naoya_t
- 修正確認しました。完了にして大丈夫だと思います。 -- ココサブ
- どうもありがとうございます。 -- naoya_t
- BNUMNEIやります。 -- ココサブ
- BNUMNEIまとめました。ひげぽんさん他みなさんレビューお願いします。 -- ココサブ
- 僕が止めていましたすみません。丁寧な説明で良いですね。完了で良いと思います。 -- ひげぽん
- ありがとうございます。完了にします。 -- ココサブ
- Scm_ResolveAutoloadから掘っていたら、hashな所までたどり着きました。yamanetoshiさんが掘っていた辺りと衝突するわけですが、_掘り残し_に入っていないページであればやっていって大丈夫ですか? > yamanetoshiさん -- ココサブ
- ペース的に微妙になるかも、ですがこのまま PUSH な関連インストラクションを継続した方が良いのでしょうか？NUMADD 関連も同じカンジっぽいですが ... -- yamanetoshi
- 簡単そうであればもちろんやっていただいて構いませんし、歓迎です。ただ難しい様であれば次の方に交代してまわしていったほうが良いと思います。 -- ひげぽん
- 判りました。とりあえずまわす方向で、という事で一旦 close させて頂ければ、と思います。GREF な掘り残しもありますし。 -- yamanetoshi
- まわるとなると次は私ですかね? -- ココサブ
- そうですね。ココサブ→ひげぽん→yamanetoshi→naoya_tと滞らずにまわるようにしましょう。 -- ひげぽん
- PUSH に立候補してみます。 -- yamanetoshi
- ぜひ進めてください。 -- ひげぽん
- ガワのみ作成。PUSHです。作り方微妙だったらご指摘下さい。 -- yamanetoshi
- お疲れ様です。指摘が一つ。関連インストラクションの数が多くて大変だと思いますが、 SCM_VM_ は削るべきだと思います。 -- ココサブ
- ありがとうございます。修正しときました。 -- yamanetoshi
- よく見たらひらが完了してますね。別途まとめに着手します (今日はへろへろなので無理ッス)。関連インストラクションもこのまま続行した方が良いのでしょうか？ -- yamanetoshi
- 一応ベースでまとめてみました。みなさまレビューよろしくです (で良いのでしょうか -- yamanetoshi
- 確認させて頂きました。良いと思います。 -- ひげぽん
- 使用例が微妙だったので修正してます。 -- yamanetosh?
- ひげぽんさん、レビュー担当との事にて、これで締め、で良いのかと思いますが、関連なソレ達をどうしましょ？ -- yamanetoshi
- GREFまとめました。yamanetoshiさん他みなさんレビューよろしくです。 -- naoya_t
- READ_CHARのレビューをお願いします。> naoya_tさん -- ひげぽん
- 使用例として、n≠1の例に加えn=1の例も挙げてみてはどうかと思い書き足してみましたが如何でしょうか。 -- naoya_t
- お。良いですね。ありがとうございます。これにて完了で良いですかね。 -- ひげぽん
- 文字を返す の所を 文字をVAL0にセット などに変更したほうが良いのではないでしょうか。 -- ココサブ
- 反映しました。ありがとうございます。 -- ひげぽん
- さて次のインストラクションは naoya_tさんと yamanetoshiさんが並行して進めれば良いと思うのだけどどうでしょう。 -- ひげぽん
- そうですね。 -- naoya_t
- では READ_CHAR をやります。 -- ひげぽん
- READ_CHARの階層が違っていたようなので、勝手ながら変更させていただきました。 -- ココサブ
- 雰囲気的に僕が次のインストラクションをやると良さそうな気がしているんですがどうでしょう？（順番は狂いますが、それぞれ抱えているものがありそうですし。） -- ひげぽん
- GREF / GLOBAL_REFのひらメソッドが思いのほか深いですね。GREF命令の概略をとらえるにはとりあえず今ある程度の情報でよいかと思いますが、どうしましょうか。 -- naoya_t
- 良いと思います。心が折れない程度に深追いするのが良いかと。 -- ひげぽん
- これ以上掘り下げるのを freeze して書きかけの項目の記述が未完なもの限定でヤッておきます。ヤリかけなものについては yamanetoshi に控えておく、という事にとりあえずしておきます。微妙だったら教えて下さいまし。 -- yamanetoshi
- そうですね。ひげぽんさんが次のまとめ役になるといいと思います。 -- ココサブ
- ええと、GLOBAL_REFはこのまま残りを続行の方が良いでしょうか？それとも今から開始される READ_CHAR 方面？てーか自分はレビュー隊？ココサブさんはざくざく掘ってるっぽいのでしょうか。ちょっと道に迷ってるカンジです。 -- yamanetoshi
- どうでしょう？＞naoya_tリーダー 。基本的には yamanetoshiさんがどれだけ深追いしたいかに依存するかとは思いますが。 -- ひげぽん
- おそらく深みにハマるのは今からです。まだまだ浅いッスか？根性キメて GW にざっくり掘ってみる、ってのもまた一興。(何 とりあえず naoya_t リーダーの判断マターで。 -- yamanetoshi
- そうですね・・・とりあえずVMインストラクションを読む間は、インストラクションの概要をつかむことに重点をおいて、ひらは掘りきらなくても良い、みたいな感じで良いのかなと思っています。ところで最近PIC用Schemeコンパイラを書いていますが、GaucheのVM設計などがものすごく参考になっています。自分で作ると読む楽しさが倍増しますね。 -- naoya_t
- たしかにわし的には VM 云々よりは_ひら_中心でヤッてる感じだったりします。VM にフォーカスを、というのは成程なぁ、と感じています。 -- yamanetoshi
- どっちかだけと考えず、VMインストラクションの合間に掘りかけの所を追っていくなりすればいいのではないかと思います。 -- ココサブ
- なるほど。なかなかリキが足りてませんが、頑張ってみたいと思います。 -- yamanetoshi
- 質問です。Scm_HashCoreInitSimpleのページを作成したんですが、その関数に記述されている hash_core_predef_procs 関数が_調べるもの_に入ってません。現時点でこれは何がどうなってるのかワケワカな状態なんですが、とりあえずこちらに throw だけしてみます。 -- yamanetoshi
- symbols.scmに抜けているシンボルがあったということだと思います。 hash_core_predef_procs は使われているので_調べるもの_に追加して読んでいけばいいのではないでしょうか。 -- ココサブ
- 了解ッス。 -- yamanetoshi
- WORD_BITSの定義が2つありました。Reading Gauche/gauche/arith.h/WORD_BITSとReading Gauche/gauche.h/SCM_WORD_BITSになります。同じ内容なので問題はないのですが、気になりました。gauche/arith.hを読んでいるファイルはその前にgauche.hを読んでいるようなのでなおさらです。しかし、gauche/arith.hでWORD_BITSが出てくる位置を考えるとこれはこれでありな気もしてきます。みなさんはどう感じますか。 -- ココサブ
- わしもよくヤルのですが思考のエアポケットに落っこちてる風に見えます。てーか、(SIZEOF_LONG * 8) なマクロが複数あるのが微妙、という意味なのでしょうか ... # ナチュラルだったらスミマセン。 -- yamanetoshi
- ええとですね。同じ定義は本来一つであるべきだと思うのですが、複数にしてある理由も分からないでもないといった所です。 -- ココサブ
- 「同じ内容なので問題ない」というのは「動作上」は問題ないのつもりで書きました。 -- ココサブ
- きちんと読んでいないので推測多分ですが、C な世界の WORD_BITS と Scheme な世界の WORD_BITS を明示的に切り分けている、のではないかな、と。もしかするとこのあたりはココサブさんが言われている_分からないでもない_というトコロなのでしょうか。 -- yamanetoshi
- ビット数の定義である時点でその分け方ではないように思います。WORD_BITSはgauche.hで定義されていれば現在は問題なく動くと思います。arith.hではビット関係の定義が固まっている所があり、そこでWORD_BITSが定義してあると見やすいと思いました。そこが 「分からないでもない」 です。 -- ココサブ
- うーん。類推でモノを言うのは良くないッスね < 自分。で、自分トコで持っている gauche-0.1 なソースを見てみた所では SCM_WORD_BITS は定義されてなくて、WORD_BITS は bignum.c にて定義されている事を確認してます。これが gauche/arith.h に括られたのかな、というのは類推です。ただ今追いかけてるバージョンのソースツリーを見るに、WORD_BITS は bignum.c の中限定に見えます。逆に SCM_WORD_BITS は bits.c とか extlib.c あたりの中限定使用に見えますね。このあたりに製作者の shiro さんの何らかの意図があるように感じます。 -- yamanetoshi
- あわわ、SCM_WORD_BITS, WORD_BITSで別の名前だったんですね。一緒の名前と勘違いしていた事が前提となっていた疑問でした。大変申し訳ないです。しかし、「使い分けはあるはず」と「別のバージョンのを見る」というのは大事だと思いました。レポジトリでSCM_WORD_BITSが出てくる所を探してみました。するとScmBits型が導入された辺りで SCM_WORD_BITS が登場している事が分かりました。ScmBits と関わりがあるワードサイズは SCM_WORD_BITS を使っているみたいです。 -- ココサブ
- わはは。最初はそうかな、と思っていたんですが、free software ってソースという事実がある、という面を再認識しました。でもさすがにリポジトリを追い掛けるリキはなかったです。とても勉強になります。 -- yamanetoshi
- LISTやります。ひらメソッドとレビューはどなたにお願いすればよろしいですか? -- ココサブ
- ひらメソッドを yamanetoshiさん、ひげぽんがレビューでいかがでしょうか。（naoya_tさんは GREF中のため） -- ひげぽん
- まとめてみました。ひげぽんさんレビューをお願いします。 -- ココサブ
- 反応遅れてすみません。見ました。問題ないと思います。_(__)_ -- ひげぽん
- レビューありがとうございます。 -- ココサブ
- ココサブリーダー。次のインストラクションをお願いいたしまする。 -- ひげぽん
- 多値の実装が知りたいので VALUES 行きます！ -- ひげぽん
- ああ、ちょうどVALUES読みたいと思っていたところでした！行きましょう！ -- naoya_t
- naoya_tさんレビューをよろしくお願いします。 -- ひげぽん
- 現在のGaucheではVALUESで返せる値の個数は19個までなのですね。（今回ソース見て初めて知った！）vm->vals が20個分確保されていながら19個しか使われていない件とか・・・書いておいた方がいいでしょうか。 -- naoya_t
- ご指摘ありがとうございます。追記しました。 -- ひげぽん
- お疲れさまです。良いと思います。次いきましょう。GREF の方もそろそろまとめに入ります。 -- naoya_t
- 現在進行中の作業は、(1) GREF : GLOBAL_REF のひら、(2) LREFのレビュー〜締め（ココサブリーダー）、(3) PAIRP、CHARP、EOFP、STRINGP、SYMBOLP、VECTORP、IDENTIFIERP のチェック（naoya_t/ひげぽん) ですね。 -- naoya_t
- 助かります。 -- ココサブ
- naoya_tさんお疲れさまです。上記の私がチェック担当のものはチェックしました。問題ないと思います。 -- ひげぽん
- 〜〜Pシリーズは問題ないと思いますので閉じましょう。するといま動いているのはGREF１つですね。次のインストラクションはひげぽんリーダーでよろしくです。 -- naoya_t
- ネットに繋がりました。ログを追いかけつつ参加していきます。 -- ココサブ
- 次に行って良い、と見てPAIRP着手してみます。微妙だったらコメント下さひ。 -- yamanetoshi
- GREFをやろうと思います。 -- naoya_t
- ところでインストラクションの進捗率はどれくらいなんだろう？1/6くらい？ -- ひげぽん
- 1/8くらい？・・・ところで、JVMのインストラクションは去年一度さらったのですがまた見返してみます。 -- naoya_t
- なんとか-PUSHというシリーズはPUSHでないやつとの対比で大体わかった気になってるので気分的には1/5〜1/6くらいかな・・・ -- naoya_t
- 次のインストラクションのリーダーをyamanetoshiさんに投げます。よろしければ１つインストラクションを選んで下さい。分岐シリーズ（Bで始まる）だとBFを参考にできるのでやり易いかと思います。あるいは何とかPとか。 -- naoya_t
- リプライ遅くなりました。ええと最初は BT が次だな、とか思っていたのですが、disasm で BT が出力される適当な命令が分からなかったので_なんとかP_なシリーズいかせて頂きます。最初は NULLP あたりでお願いします。簡単なのばっかで申し訳ないッス。 -- yamanetoshi
- NULLP作っておきました。別途、こちらへも情報投入しておけば良いのでしょうか？ -- yamanetoshi
- ひらメソッド隊長とレビュー隊長の欄はうまく順繰りに回るように設定します。（とりあえずNULLPの行を作っておきました） -- naoya_t
- NULL_P チェックしました。良いと思います。つぎにいきましょう。空リストという表現が素敵。 -- ひげぽん
- いいですね。次は１周回ってひげぽんリーダーですね。 -- naoya_t
- あら、ちょっと先走ってしまいました？まだ修正可能ッス。 -- yamanetoshi
- NULLPについては一応説明を書いてみた、という状態になっています。チェックおねがいします。GREF方面のひら手伝いに参ります。 --
- NULL_P チェックしました。良いと思います。つぎにいきましょう。空リストという表現が素敵。 -- ひげぽん
- 類似なインストラクションについて記述を追加しちゃって良いのでしょうか？ 勿論 NULLP の修正要求があれば手を戻します。追加しつつ、Scm_ResolveAutoload のひら手伝いができればな、と。 -- yamanetoshi
- 書いておきたいことがあったら、備考欄を作ってとりあえず書き留めておかれると良いかと思います。類似なインストラクションについての記述いいですね。 -- naoya_t
- 了解ッス。参考になります。 -- yamanetoshi
- しばらくまともにネットに接続できる状態で無いことをここに明記していないですいませんでした。4/12から復帰できるはずです。 from ネットカフェ -- ココサブ
- BFのレビューをおねがいします。＞naoya_tさん -- ひげぽん
- コメントをBFのページに書きました！ -- naoya_t
- お返事遅れてすみません。ご指摘の点反映いたしました。 -- ひげぽん
- 良いと思います！次に行きましょう。２本ぐらい並列で行けると思うので、yamanetoshiさんとnaoya_tがそれぞれ次のインストラクションを選んでスタート、で良いでしょうか。 -- naoya_t
- 良いですね。並列賛成です。 -- ひげぽん
- ほとんどコピペで行けそうなCARシリーズ（CAAR, CADR, CDAR, CDDR）４インストラクションをまとめて片付けました。チェックよろしくお願いします。 -- naoya_t
- car/cdrの深さ４までの組合せがどのようにコンパイルされるか等CAARの備考に書きました。 -- naoya_t
- お疲れさまです。完了で良いと思います。備考も面白かったです。GJ! -- ひげぽん
- プログラムの基本要素だと思うので次はBFやります。 -- ひげぽん
- 頑張るというレベル以前のナニで CDR まとまったみたいです。VMインストラクションな文書は自分がモディファイするのでしょうか? あと、次のソレはひげぽん/naoya_tさんで決めて頂いて構わないです。 -- yamanetoshi
- あと、無茶でない範疇で (どういった意味か自分でも分かりませんが)、まとめを振られても OK、とも思っております。 -- yamanetoshi
- お申し出ありがとうございます。ではやはり、リーダーを順々に変わっていくサイクルに入っていただくのが良いと思います。扱うインストラクションはリーダーが選べますし（簡単なものでも良いでしょう）、ページをまとめる上で理解も一層深まるように思います。もちろん最大限僕等がフォローしますです。もしOKであれば、ひげぽん→naoya_tさん→（ココサブさん)→yamanetoshiさんという感じかな。2つのインストラクションが同時並行で進みます。 -- ひげぽん
- わかりました。微妙なソレは適宜指摘して頂ければ幸いです。よろしくお願いします。 -- yamanetoshi
- LREFのレビュー〜締めがココサブさん不在で保留になっているのを除くと、いま進んでいるのはBFだけですね。もう１つ投げますか？ -- naoya_t
- お。ばっちりですね。お疲れさまです。> CDR。VMインストラクション に関してはリーダー（つまり今回は yamanetoshiさん）が担当したインストラクションの管理をしています。現在のステータスはレビューですね。（naoya_tさんがOKを出せば完了）。次のインストラクションは僕がリーダーをやります。 -- ひげぽん
- ココサブさん不在中ということで、先にリーダーやります。CAR行きます。 -- naoya_t
- ひげぽんさんyamanetoshiさん：ひらメソッドのお手伝いお願いします。 -- naoya_t
- yamanetoshiさん、そろそろリーダーやってみませんか? -- ひげぽん
- そうですね。やってみませんか? -- naoya_t
- う。これはまだ時期尚早ではないかと思います。実は今日から新しい職場でばたばたしてるのもあったり、JUMP 云々の件も compile.scm にソレらしき記述を見つけた位で具体的にイメージできてなくって、もう少し VM について何かの手応えを持ってからの方がテンパッてナチュラルな失敗をしないんじゃないかな、と思っております。ココサブさん ip unreachable (twitter 情報) ?? そげなのも分かってはいるのですが ... ワガママ言って申し訳ないです。 -- yamanetoshi
- レビューもありますし多分大丈夫だと思いますよ。まだまだインストラクションはありますのでそのうちお願いします！ココサブさんやっぱり4/12までunreachableなのでしょうか。とすると・・・僕の番？ -- naoya_t
- おお。なるほど。ではもうしばらく様子を見ましょう。 -- ひげぽん
- どうもありがとうございます。あと、次のリーダーさんが大変な思いをしない方向で、を心掛けたいと思っています。 -- yamanetoshi
- では。ココサブさんリーダーをお願いします。 -- ひげぽん
- JUMP完了しました。使用例が見つけられないので保留にして次に行くのはどうでしょうか。レビューをお願いします。＞naoya_tさん -- ひげぽん
- 拝見しました。PC = *PC ですね。後で使用例を見つけたら追加する、ということで良いかと思います。次いきましょう。 -- naoya_t
- ありがとうございます。 -- ひげぽん
- 次はJUMPをやります。 -- ひげぽん
- PRE_CALLは完了。LREFは結局誰がボールを持っていることになるのかな? -- ひげぽん
- う。_LREF に関して現状まとめ。_のいっちゃんケツのコメントをご勘弁頂ければ幸いッス。naoya_t さんが言われている_VMのインストラクションの概要が理解できる程度_というあたりが全然分かっていませんでした。 -- yamanetoshi
- ありがとうございます。Scm_VMDefaultExceptionHandler、Scm_ReportErrorを yamanetoshi さんがまとめてくださった時点で naoya_t さんがページをまとめるという認識であっていますでしょうか。くどくてすみません。こういう共同作業は誰が何をやるのかを確認しないとお見合いが発生しがちなもので。_(__)_ -- ひげぽん
- 見合いを発生させてるかも、ですね。スミマセン。_Scm_VMDefaultExceptionHandler、Scm_ReportError_については現状でまとまっている認定で勘弁して欲しい、というのが自分の認識ですが、リーダーの判断に従います。動き方が判ってないのに微妙な動作が多くってスミマセン。 -- yamanetoshi
- ありがとうございます。こちらこそすみません。では naoya_tリーダーの判断を待ちましょう。 -- ひげぽん
- Scm_VMDumpの詳細ですが、LREFのインストラクション概要としては「（指定されたdepth/offsetにフレームないし値が存在しない場合）VMをダンプして強制終了」程度にしておいて、VMインストラクションが一巡したあたりで改めて掘り下げるというのは如何でしょうか。 -- naoya_t
- はい。賛成です。 -- ひげぽん
- お疲れ様です。自分も異存はありません。 -- yamanetoshi
- それでは、PRE-CALLの次にやるインストラクションをひげぽんリーダーで選んでおいて下さい。 -- naoya_t
- で、LREFはココサブリーダー中心にレビューしてもらって一旦閉めたいと思います。 -- naoya_t
- LREF0をテンプレートにして、環境フレーム内のdepthとoffsetが異なるのみのLREFシリーズ各インストラクション（LREF1, LREF2, LREF10, ...）のページを作りました。 -- naoya_t
- PRE_CALLがまとまったので、ひげぽんさんレビューお願いします。 -- ココサブ
- LREF に関して現状まとめ。 -- ひげぽん
- LingrにてReadingのページから実際のソースへリンクはないの？と聞かれました。あった方が良さそうだと思うんですがどうでしょう？どこにリンクしよう? -- ひげ?
- http://lambdarepos.org/Gauche/0.8.13/HTML/ ないし http://lambdarepos.org/Gauche/0.8.13/src/ みたいな感じに置いてあればいいですよね。 -- naoya_t
- おーよいですねー。1つの質問と1つの要望？があります。質問「lambdarepos.orgは永続的に管理される予定ですか?1-2年でみれなくなってしまうようであればもっと永続性のあるところに置いた方が良いかなあと」要望「ページを作る際に手間をかけずソースにリンクを張りたいので、わかりやすいパーマリンクを作れそうでしょうか?（少なくともHTML版の奴はURLを推測しようがないので面倒そうです）」 -- ひげぽん
- 質問の答え「永続的管理（5年10年とかそれ以上とか）は現時点（2008/3/21）では確実ではないです。」要望の答え「GNU globalの出力のファイル名（と相互リンク）を一括変換できそうな気がします！」 -- naoya_t
- ありがとうございます。となると。手間が全然かからなければソースへのリンクを張る。って感じでしょうか。皆さんどう思いますか。 -- ひげぽん
- naoya_t さんが紹介されているコンテンツを今見ました。具体的にどうなるのか、というイメージが全然できてませんが面白そうだな、と。 -- yamanetoshi
- ソースへのリンクを張る形式でよいと思います。ただ、気になる点が2つあります。1つ目は読んでいるGaucheのバージョンは0.8.11だが、一例としてあげられているのは0.8.13であること。こちらは、0.8.xならば問題ない気もします。2つ目は既存のページはどうリンクを張るのか?スクリプトでやってしまうのでしょうか。それとも新規に作るページだけとりあえずリンクを張る形でいくのでしょうか。 -- ココサブ
- 0.8.11でも0.8.12でも作れます。（自分が0.8.13ベースで読んでるので0.8.13を例に挙げてみました） -- naoya_t
- ありがとうございます。 -- ココサブ
- 記述の方法云々とカブるんですが、ひらメソドなのにソースを貼らない、という部分に若干微妙さを感じてたりします。例えば今やっているReading Gauche/code.c/Scm_CompiledCodeDumpなんかも結構長い関数ですが、ソースが見えないのはちょっと微妙な感じもします。新参者が微妙なコメントでスミマセン。 -- yamanetoshi
- なるほど。僕的にはひらメソッドは概要が一番大事だと思うので、ソースもみてみたいなあという人用にソースへのポインタさえあれば十分だと思っています。なのでソースへのリンクは無しという方針も方向性によっては全然ありだと思います。 -- ひげぽん
- 了解しました。ソースへのリンクはあっても良いとは思いますが、ひげぽんさん判断に委ねます。 -- yamanetoshi
- すみません。自分で言い出して何ですが、1.ソースを置く場所、2.リンクの手間（自動化はむずかしい？）から見合わせようかと思います。 -- ひげぽん
- 左側のMENUにこのページへのリンクを追加しました。 -- ひげぽん
- メソド、マクロ等の記述の標準のようなものがあるのでしょうか。自分で書いてて記述の方法がばらばらな気がしてきています。これはレビューアな方の指摘を待った方が良いのかなぁ -- yamanetoshi
- 例えばマクロならばSCM_LIST1、関数ならばScm_Consなどが標準的なものだと思います。もし何か具体的に迷っている点があればここに書いてもらえれば皆で相談できると思います。 -- ひげぽん
- あと手前味噌で恐縮ですがReading Gauche/00.ページ作成スクリプトを利用するとページ作成が楽になります。 -- ひげぽん
- 存じてはおるのですが ... Gauche で書いてあるヤツはまだ投稿まではできないのですよね。まだ短いものしか見てないのでアレですが、規模が大きくなってくるとシンボル抽出は自動の方が楽ですよね。 -- yamanetoshi
- そちらの環境でうまくうまく動かないのであれば、状況を教えてもらえればサポートできるかもしれません。 -- ひげぽん
- 今、ヤッてみたのですが、Gauche なスクリプトで_調べるもの_を抽出して perl のスクリプトでページが作成される事までは確認できてます。ありがとうございます。 -- yamanetoshi
- 了解です。良かった。良かった。 -- ひげぽん
- CLOSUREを完了にしました。ココサブさんリーダーでPRE_CALLお願いします。 -- naoya_t
- （雑談）そういえばいずれ id:yamanetoshiさんが参加したいとおっしゃっていました。 -- ひげぽん
- おお！よろしくお願いします。今の仕組みなら人数を増やすのも簡単ですね。 -- naoya_t
- 人数増えるのは嬉しいですね。 -- ココサブ
- 歓迎頂き、嬉しく思っています。とりあえず現在に至るまでを追い掛けてみたいと思っています。どうぞよろしくお願いします。-- yamanetoshi
- RET が保留となりましたので次のリーダー naoya_t さんお願いします。 -- ひげぽん
- Reading Gauche/vm/insn/CLOSURE をやります。 -- ひげぽん
- LREF0 の進捗状況ってどうなっているでしょうか？すみません。追いきれてなくて。 -- ひげぽん
- 環境フレームのことをどこかでまとめたいという話までは認識しています。それ以外で何かありますでしょうか＞ココサブさん＠レビュー隊長 -- naoya_t@LREF0まとめ役?
- 特に無いです。ただ、LREF等を進めている内に追記したい事がでてくるかもしれないと思っています。 -- ココサブ
- ではお手数ですが次のアクションと人を決めてくださいませ＞naoya_tリーダさん。 -- ひげぽん
- LREF（無印）は保留にして、ひげぽんリーダーでRETの次のインストラクションを選んで始めてください。このやり方は、進み具合が把握しやすくてとても快適です。 -- naoya_t
- ありがとうございます。お見合いをできるだけ減らすように声かけしていきましょう。 -- ひげぽん
- 次はReading Gauche/vm/insn/RETをやります。 -- ココサブ
- お願いします。現在 LREF0 と RET が進行していて僕の手が空いているので遠慮なく仕事をふってくださいません。同時進行するインストラクションは2つがちょうど良いと思うのでどちらかが終わった時点で次のインストラクションに取りかかります。 -- ひげぽん
- 一応ページが形になったので、レビューお願いします。Reading Gauche/vm.c/POP_CONTの辺りの理解があやしいので、念いりにお願いします。 -- ココサブ
- 読んでみました。いろいろ見てまわって考えたのですが、手続き呼び出しの手順とスタックの関係をまとめる形にすると理解が進みそうです。SCM_VM_PUSH_PRE_CALL で PUSH_CONST、RET で POP_CONT という形で継続フレームには戻り先情報（呼び出し後の継続）が積まれていると思います。 (disasm (lambda () (display 3) 3)) などすると感じが掴めます。さて今後どうすすめましょうか。＞ココサブリーダー。 -- ひげぽん
- 本件どうしましょう? -- ひげぽん
- 遅くなってすいません。保留にして、 PRE_CALL と GREF_CALLあたりのCALL インストラクションをまとめたいと考えています。 -- ココサブ
- 了解しました。 -- ひげぽん
- CONSTIの次は、Reading Gauche/vm/insn/LREF0をやります。 -- naoya_t
- 新しい作業ログはこちら。 -- ひげぽん
- VMインストラクションの行程表が出来ました！Reading Gauche/04.項目列挙/VMインストラクション -- naoya_t
- いいですね。担当や取り組んでいる・取り組んだインストラクションがわかりやすいです。 -- ココサブ
- これはGJ! -- ひげぽん
- 次はReading Gauche/vm/insn/CONSTIをやります。 -- ひげぽん
- CONSTIの関連項目のリンクが別のページに繋がっていたので直しておきました。 -- naoya_t
- お。何かなおったらと思ったら小人さんだ。ありがとうございます。 -- ひげぽん
- ページ作りました。レビューをお願いします。＞naoya_tさん。1つ分かっていないのがCONST と CONSTI にコンパイルする時の分岐の部分です。CONSTIのサポートする整数範囲は動作から知ったのですがコンパイラからもできれば知りたい。もし分かる人があれば教えてください。 -- ひげぽん
- Reading Gauche/vm/insn/CONSTのまとめ役なので。このページに関してはOKとして先に進むのが良いと思うのですがどうでしょうか。もしOKであれば、naoya_tさんは次のインストラクションのまとめ役を。並行してココサブさんが次の次のインストラクションのまとめ役を進めていただければと思います。今回のように分担があれば僕にふってください。よろしくお願いします。 -- ひげぽん
- という感じでまとめ役が次の人にバトンを渡していけばきっとうまくまわっていくと願う。 -- ひげぽん
- 次の次ですね。CONST_PUSHを進めます。 -- ココサブ
- よろしくです。何か必要なことがあったら僕にふってください。 -- ひげぽん
-- naoya_t 2007-12-11 (火) 11:08:39
