一括表示

以前、ちょこっと書いたかと思いますが。
#59の拡張というか、検索文字列の連続取得というマクロを使っています。
GGWっていったかな、家に帰らないと作者がちょっとわからないのですが、なんと
なくnarutoさんだったような気もします。なお、使っているマクロそのものは、私
のvz.defにそのまま貼り付けてありますので、どこかで発見できると思います。
ところがこれ、オアシスポケット３で実行すると、異様に遅いのです。
[F05]に割り付けてあるのですが、キーを押すと画面左下に取得した文字列が表示
されたあと、編集画面にカーソルが戻ってくるまでに５秒以上かかるのです。
ポケ３の特殊性として、ＥＭＳを使う場合に著しく遅くなるというのがありますが、
この件はＥＭＳの有無にかかわらずほぼ同じくらい遅いです。

&tを使って遅い部分を抽出した結果、以下の部分に原因があるということまでは
わかりました。

:L      (p.0)??>Q                       ;ヒストリの終わりか?
        &SX(p,ps)                       ;取得文字列とヒストリの文字列の比較
        (r)??{  f..0=p,f.2-,            ;一致したらそのアドレスと記憶し、
                >Q}                     ;       ガードしないフラグを off
        &Sn(p)                          ;ヒストリの文字列の長さ取得
        p+=r+1,                         ;次の文字列へ
        >L
:Q      ps],                            ;ヒストリバッファポインタ復元

ラベルLの前に&tを置くと、そこまではすぐに到達します。
しかし、そこでリターンを押しても、カーソルが復帰するまでに数秒かかります。
ラベルQの後ろに&tを置くと、そこにたどり着くまでに数秒かかります。
しかし、そこでリターンを押すと、すぐにカーソルは復帰します。

さて、このようなループで、どこが遅くなるかお分かりになりますでしょうか。
あるいは、このようなときに原因を追求する何かよい方法をご存知ありませんか？
あと、マクロのコマンドや関数の個々の所要時間を測定する、何かベンチマーク
のようなマクロはありませんでしょうか。例えば

= 長椅子印
* m
1 @[ "benchmark"
    ?.
    ;a=開始時刻
    (100){
        p[=ps, ps],
    }
    ;b=終了時刻
    ;&m(a,b)
*

見たいな感じで、１つずつのコマンドの速度を計ってみるとか。


ということで、お知恵をお貸しいただければ幸いです。
 

　もしかして，としきさんの hs がやたらでっかいとかいう問題ではないかと
思ったりもするのですが，たとえ大きくても数千バイトくらいのものでしょう
から，数秒も帰ってこないというのはＬＸ並みですね。

　でも，ともかく時間がかかっているのは，ふたつの拡張文字列関数だと思い
ます。特に，&SX()の方でしょうか。

　マクロの全体像が不明なので想像ですが， このマクロは #59 で選択文字列
を取得する前に，バッファをすりかえておき， ps 以外のバッファに取得した
文字列と取得文字列の履歴を逐一比較して，既に履歴に存在すればそれを利用
し，なければ &Sh()でコピーして利用するというものだと思います。

　履歴をすべて走査するわけですから，バッファが大きければそれだけ取得す
るたびに膨大な時間がかかると思います。多分このマクロはＬＸのシスマネあ
たりから呼ばれる最小バッファの VZ で，履歴の有効利用を目的にしたような
ものだと想像します。NaruTo さんのかもしれないということなら，NaruTo さ
んは LXer だったので可能性がありそうな。

　もしも，としきさんの hs が大きなものだったらとしたら，マクロと環境の
相性はあまりよくないと言えるかもしれません。

　あ，そう，ベンチマーク。…と言えば，高橋先生が作っていたような記憶が
あります。 IBM-PC だと普通に千分の一秒とか測定できたようですが，NEC-98
だとできなかったんじゃなかったかな。やり方は多分としきさんの長椅子印サ
ンプルのようにループの前後でファンクションコールすればよいと思います。
ん？　ひとつずつコマンド測定？　資料としても面白いなぁ。

hsですか。
あとで値を小さくして状況が改善されるかやって見ます。

> ものだと想像します。NaruTo さんのかもしれないということなら，NaruTo さ

作者はNaruToさんで間違いありませんでした。
GGW0.41というものですが、これ、ＷＥＢで検索しても引っかからないようです。
これも失われてしまったマクロという事でしょうか。
っていうか、私はこれをどこから入手したんだろう？
どっかのISH会議室あたりかな。

> 　あ，そう，ベンチマーク。…と言えば，高橋先生が作っていたような記憶が

どこら辺にありますか？
教えていただけないでしょうか。

> あります。 IBM-PC だと普通に千分の一秒とか測定できたようですが，NEC-98
> だとできなかったんじゃなかったかな。やり方は多分としきさんの長椅子印サ

そう、これはファンクションコールの制限ですね。
ポケ３でどのくらいの精度まで測定できるかは知らないのですが、マクロの場所を
教えていただければ、あとでやってみたいと思います。

> ん？　ひとつずつコマンド測定？　資料としても面白いなぁ。

これは、コマンド毎に大きな差がつくようなら面白いかもしれませんね。
 

> どこら辺にありますか？

　現在，うちの環境がむちゃくちゃな状態で，
Aptiva 引退寸前：ラックからおろされてカウンタに一時置き状態
mouse-jp 日曜日に納品：何故かエクスプローラで落ちまくり，初期不良かも
ThinkPad A21e 中部ノートセンターに入院中
ThinkPad A21m 入院中のeをほぼ見限って競売で購入：本日納品未セットアップ
…みたいな感じ

　とてもマクロを探せるような状態じゃないんで，勘弁してください。

　時期的には，PK から DC への移行直前，BEVERLYBOY さんのリクエストでス
トップウォッチを制作した頃だったと記憶しているのですが，なにせ，ほれ。
v(^_^;;

　なので，過去ログ第一人者の文太さんに聞いてくだされば，簡単に鬼車で検
索してくれるはず。（わーい，振ってやったぞ。）

　ところで，コマンド測定ですけれど，同じ条件でできるはずがないので無理
があるのではないかと思いはじめました。

めざらさん、こんにちは。

　むさいさんでも（おい）、マシン自体の管理には悩まされるですね。楽しいで
すか？　いえ、純粋な質問なんですが、僕は、マシンに悩まされると、ただただ
苦痛で。ただ、達人たちは、マシンの不調を楽しむものらしい、と耳にしたもの
ですから。

　マウス・マシン、落ちますか。やっぱ大魔人さんが正しいのかも…。いえ、つ
いついスペックを高めにして注文してしまうものですから、僕のＸＰも、無理な
マシン構成になっているのか（オプションに入れないでよ＞マウス）、落ちます。
ひやひやする。原因まったくわからないし、マウスと相談する気にもなれないの
ですが（根性なし）。onigsed.exeで落ちられたらたまらんですよ。どーなってる
の？

> 　なので，過去ログ第一人者の文太さんに聞いてくだされば，簡単に鬼車で検
> 索してくれるはず。（わーい，振ってやったぞ。）

　えーと、僕、何かめざらさんに振りましたっけ？
　あ、としきさん要望の２件？　う、確かに振ってるかも。でも、めざらさんし
か解決できないしぃ。

　で、鬼車は正規表現エンジンなので（知ってるくせに、ったく）、ログ検索は
ygrep  しかありません。 （あ、僕のおねだり、ygear でのディレクトリ指定時
「\*.*」付加の「サポート」は却下？　ほんと、これ欲しい…。たぶん、本人使
わないのに、骨だけ折れる改造なんでしょうね。やっぱ、とらじさん、とらじさ
ん、かな。あれは、読めない…。）

　とにかく、条件がわかれば、グレップできますけど、ちょっと情報不足な感じ
ですけど…。

> 　ところで，コマンド測定ですけれど，同じ条件でできるはずがないので無理
> があるのではないかと思いはじめました。

　なんだとするとなおさら…。あ、住所録からたどれるのかな？


　そう、興味ないかもしれませんが、cgrepをBruce.さんが改良してくれました。
http://www.kt.rim.or.jp/%7ekbk/cgrep/cgrep301b.lzh

　ＴＳのＭＬぐらい入っていたって損ないと思うけど…。


　万が一、マシンの不調でめげてるのでしたら、元気だしてくださいね。
　文太の奴がついてます。（はぁ？）

　「絶対番地」のあたり読ませていただきました。うん、これは、いい。

　マシンが落ちることはないのですが，基本的なソフトウェアすら落ちるのは
楽しくないですね。…と言うか，妻に買ってあげたマシンなので，なかなか事
情は複雑です。今までお下がりの Aptiva を使っていて，度重なる不調にうん
ざりしている様子だったし，CD-R を焼けるマシンがなかったのですね。 地区
の子供会の会長なんて役になって，どうも CD-R でファイルを引き継いだこと
もあり，少し必要が出てきたかなと。

　どうせ買うならと，悩んだ挙げ句に少し欲張りなマシンを選択したのが運の
尽きかな。テレビなぞパソコンで見ないんだから，何もnVIDIA GeForceFX5200
なんて必要なかったですよね。BTO ってのは注意しなくちゃでした。

> 　とにかく、条件がわかれば、グレップできますけど、ちょっと情報不足な感じ
> ですけど…。

　ベンチマークってだけでは無理でしょうか。確か，ストップウォッチの頃だ
と思うので，1996年の夏なんですけどねぇ。なんて書いているうちに，としき
さんが発見したみたい。めでたしめでたし。

> 　そう、興味ないかもしれませんが、cgrepをBruce.さんが改良してくれました。
> http://www.kt.rim.or.jp/%7ekbk/cgrep/cgrep301b.lzh

　あ，どもです。あとで何が変わったのか見てみますね。
　ＴＳのＭＬも，そうね，入っておいた方がいいですかね。

> 　「絶対番地」のあたり読ませていただきました。うん、これは、いい。

　どうなのでしょうね，「絶対番地」。
　「ファイルの」と前置きすれば，「絶対」とも言えるのかな。先頭からの番
地ですから，「ファイルの先頭からの相対番地」と言うのも変な気もしてきま
したが。

　めざらさん、こんにちは。ちょっとお疲れ＆＆多忙モードゆえ簡単に。

> 　マシンが落ちることはないのですが，基本的なソフトウェアすら落ちるのは
> 楽しくないですね。

　なんだか落ちが激しくなってきた…。ひぇ〜。こういうのすごくゲンナリする。

> > 　そう、興味ないかもしれませんが、cgrepをBruce.さんが改良してくれました。
> 　あ，どもです。あとで何が変わったのか見てみますね。

　変更点を示すdocが入ってないのだ、と思い出しましたのでメモっておきます。

　入っているのは、cgrep.exe,  cgrep32.exe で意味は名前のとおり。旧版まで
との違いは、

　１　-b のバイトオフセットが正しくでる。
　２　-r  でディレクトリ再帰ができる（これは長いあいだかかって出来上がっ
ていた Bruce. さんの仕様の追加。でかいっす。）
　　　ただし、多少、指定にくせがあります。検索ファイル名は必ず指定する。
まず間違いなくワイルドカードが使われると思うけど、' ' でそれをはさむこと。
無指定だと途方に暮れることになる（※）。

>cgrep -M -rc:\bunta "文太" '*.txt'
オプション、ディレクトリ指定オプション（指定ディレクトリ）、検索パターン、
検索ファイル名パターン

　この順番です。

　32 ビットだと何がいいか。sed  でもそうですが、メモリーを多く使えますか
ら、-f とかが膨大になっても大丈夫。

　たとえば、以下のような「行う」→「行なう」の間違いを発見するために、僕
は昨晩、ygear を諦め、下のような sed スクリプトにして逃げることになった。
（※２）

s/\([^流移銀旅平修先進一二三十百発刊執遂苦同通犯善避蛮品実乱並紀慣孝各単]\)$
行\([^方事儀政動程作為進使かきくけこな]\)/▲\1行\2▼/g

　こういうのが６００行もあると、

>Sed -f HYOKIA.SED c:\target.txt |Sed -f HYOKIB.SED |Sed -f HYOKIC.SED$
|Sed -f HYOKID.SED |Sed -f HYOKIE.SED >result.txt

　なんてことになってしまうのです。

　ygearだと窓あふれ。あれ何とかなるのかなぁ…？


（※）止まります。いちおう「バグ」とのことだったので、もしかしたら、ドッ
ク付きの新版にバーアップしてくださる意図を Bruce. さんはおもちなのかも…？
　ただ、 そもそも１６ビットの dos 汎用ツールをコンパイルできる環境を今時
ふたたび構築する、というところから今回始まってますので、さて？　けっこう
偉人たち続々登場、という感じで、賑やかに大変だったのです。

（※２）ygrepよりcgrepが優れている点（それぞれモチモチなわけですから相違点
ですが）に、グローバルにマーキングできる、というのがあります。ygrep -Mは、
最初のヒットにしかマークしない。grepなんだから、s/あ/▲あ▼/gでなく、
s/あ/▲あ▼/でいいだろ、と言われれば、まぁねぇとしか答えようがないのだけど、
でも、２つ目だってマークしてくれなければ、やっぱまずいですよね。
　でも、ygrepには、-rがあった。そこで、Bruce.さんは、cgrep -rを（昔）新設
したのです。

> 　変更点を示すdocが入ってないのだ、と思い出しましたのでメモっておきます。

　ありがとうございます。
　せっかく勧められたので，TSNET に入会してきました。で，文太さんのどた
ばたぶり(笑)も拝見致しましたので，パターンの指定書式もよくわかりました。

　ディレクトリの再帰検索は便利そうですね。

　実は多分 VZ に出会う前に， C マガジンの付録 CD に入っていた cgrep を
愛用していた時期もありました。当時は正規表現なんて知らなくて，普通の検
索にしか使ってなかったんですよね。VZ に付いてきた wgrep が圧縮ファイル
の中身も検索できたので，ストレージ貧乏だった当時は飛び付いたね，すぐ。

　だから，また新たなる出会いって感じですかね。

> 　せっかく勧められたので，TSNET に入会してきました。
　それはよかった。テキストオタクとしては、入ってなきゃ、嘘ですよ。
　もっとも、sedの話題もawkの話題も、なかなか出ないのですけどね。僕には、
何の話がわかりませんが、 perlのcgiとかなら、ネタ振りでも何でもいいじゃな
いですか。ああ、そっちに時代か。

> 　で，文太さんのどたばたぶり(笑)も拝見致しましたので，
　がんばってるでしょ。 うふ。sedでももgrepでも、ニッポン語に対する進化の
発端を自分が担ったことを、生涯、誇りにできる、と勝手に思ってたりします。
Bruce.さん、多謝でありまする。いえ、serowさんに足を向けて寝られない、と
言ってたあの人を、尊敬せずにはいられません。

　何書いてるのだか、な奴に、「おらよ」って。すげえなぁ。

　cgrep, wgrep, cgrepですか。ygrepは？　ygearは？
　あんまり、あのへんは強烈じゃないんですね。それまで、行で検索していたの
が、発言単位で検索できる、それも面倒なオプション指定がメニューで出る、っ
てみたとき、死ぬほどありがたったんですね。あ、住所録つくってくってことは、
グレップなんかに頼る必要がない、頼っても、それ以上を俺は残してる、ってこ
とか。それは言えます。

> 　だから，また新たなる出会いって感じですかね。

　新たなる出会いに幸あれ。

　VZ FAQ 更新、ありがとうございます。 勉強になります。あ、こんなことも知
らなかったよ、情けねー、こぼしました。多謝です、m(_Ｂ_)m

　マシン、絶不調。ファンみたい。全面対決の時間がとれるまで１０分以上連続
で電源を入れ続けない態勢にしたほうがよさそうなので、あんまり登場しないと
思います。m(__)m

> 　時期的には，PK から DC への移行直前，BEVERLYBOY さんのリクエストでス
> トップウォッチを制作した頃だったと記憶しているのですが，なにせ，ほれ。

これが手がかりになりました。
多分、PK14#17904(96/07/10)のことだと思います。
これを参考にして、ちょっと作ってみたいと思います。
 

hsを減らしたら、大幅に改善しました。
ただ、hsのサイズというよりも、ヒストリーに記録されている文字列の個数に依存
しているような気もしますが、今朝の通勤電車の中でちょっと試しただけなので
詳細は不明です。こちらのマシンは母艦と違って、長い文字列を記憶させておく
ニーズも高くないので、手ごろなサイズを手探りしてみようかと思います。

しかし、大幅に改善したといっても、今までhs1024で１３０個以上の文字列を記憶
していた場合で１０秒ぐらいかかっていたのが、hs16で１個しか文字列を記憶して
いない状況でも２〜３秒かかっているという状況で、まだまだ遅いような気がしま
す。これをもっと改善しようというと、やはりマシン語を使わざるを得ないのかな。

ベンチマークマクロは、私も自分で探してみます。
例えば、xxというコマンドは母艦に比べて１００倍遅いけど、yyというコマンドは
母艦と比べて１０００倍遅い、みたいな相対値がわかれば十分ですから。
 

> していた場合で１０秒ぐらいかかっていたのが、hs16で１個しか文字列を記憶して
> いない状況でも２〜３秒かかっているという状況で、まだまだ遅いような気がしま
> す。これをもっと改善しようというと、やはりマシン語を使わざるを得ないのかな。

　次の履歴の先頭に移動するのに時間がかかっていたものかと思っていたので，
少しあてが外れました。１個しか文字列がないのに２〜３秒というのは異常だ
と思います。そのマクロは手元にないし，ログを検索しても出てこないので，
本当に幻のマクロのようですね。送っていただけたらテストできるんですけど
ねぇ。

　他の環境でもそのようなんでしょうか？

> と思います。そのマクロは手元にないし，ログを検索しても出てこないので，
> 本当に幻のマクロのようですね。送っていただけたらテストできるんですけど

過去ログを検索したら見つかりました。DC16#01296(95/03/13)です。
もしお手元にないようならお送りします。
もっとも、某所で公開中のポケ３用のvz.defにはりつけてありますので、私の
実際の環境がどうなっているかというのまで含めて検討するのであれば、そちら
のほうがいいかもしれません。

> 　他の環境でもそのようなんでしょうか？

ポケ３以外の環境では瞬時にカーソルが復帰します。クロック25MHzのPC-98など
でも、ワンテンポすら遅れずに戻ってきます。
 

> 過去ログを検索したら見つかりました。DC16#01296(95/03/13)です。

　あ，16階でしたか。見つかりました。探し方が悪かったようです。

> ポケ３以外の環境では瞬時にカーソルが復帰します。クロック25MHzのPC-98など
> でも、ワンテンポすら遅れずに戻ってきます。

　うーむ，それではポケ３のメモリの問題ですね。
　それじゃ実験しても意味が無さそうですね。(^^ゞ

> 　うーむ，それではポケ３のメモリの問題ですね。
> 　それじゃ実験しても意味が無さそうですね。(^^ゞ

やっぱりそこですかね。
となると、ベンチマークマクロで実験してみる価値はありそうです。
 

> となると、ベンチマークマクロで実験してみる価値はありそうです。

ということで、ベンチマークを取り始めています。
ポケ３では、いくつかのシステム関数や、代入文すらも、１０００回もループを
回してやれば１０秒とか時間がかかるので、十分測定可能です。
が、母艦だと、６５０００回ループも２秒程度なので、精度の高い測定のためには
二重ループとかにする必要があります。が、単純に二重ループなコードを書いても、
内部変数というのかな、ｒの関係で二重になってくれませんよね。
こういった時にはどうすればよいのでしょうか。ロングな変数を使うのかな？
もしかしてFAQかもしれませんが、教えていただけると幸いです。
 

> 二重ループとかにする必要があります。が、単純に二重ループなコードを書いても、
> 内部変数というのかな、ｒの関係で二重になってくれませんよね。
　
　外側のループにはラベルを使えばよいのではないでしょうか。
　ラベルの内部は変数一つ使って，(i++<1000)?>L とか。
　
　純粋な二重ループは内部レジスタが一つなので不可能です。
　また，rと内部レジスタは別物です。

> 　また，rと内部レジスタは別物です。

ということもわかっていないくらい、私はマクロに関する技術がないのですよ。
あとでラベルを使ったやり方でやってみます。ありがとうございました。
 

どうも、測定方法が悪いのか、結果が信用できません。
やり方としては、めざらさんのお薦めに逆らって、というか、以下のように、

        i=1000,
:A      (1){f..0=p,}
        i--,(i>0)?>A

内部ループを単純ループにして、外部ループをラベルにしてみました。
以下、所要時間の結果です。単位は秒です。
ループ回数は「外部ループ＊内部ループ」で表記しています。

                     ポケ３                    母艦         
             1000*1  1000*5  5*1000    1000*1000  1000*10000
f..0=p,        39      80      51          22         212   
f.2-,          39      78      50          14         141   
f..0=p,f.2-,   45     105      77          34         342   
p+=r+1,        39      80      50          18         179   
&SX(q,ps)      39      80      51          22         228   
&Sn(p)         39      78      49          13         126   

母艦の方は、ループの総回数が１０倍になれば所要時間も１０倍になっているので、
方法としてはそれほど大ハズレではないような気もします。
が、ポケ３の方の結果、これはいったいどう解釈すればよいやら。
まぁ、オーダーというか、数値の桁は信用できると思いますので、母艦に比べて
数百倍遅い、というのは間違いないところなのでしょう。
 

> が、ポケ３の方の結果、これはいったいどう解釈すればよいやら。
　
　むう。メモリへのアクセス速度に変動があるということでしょうか。
　例えば（？）LX なんかは電源管理のために速度が大きく変動する訳ですが，
ポケ３も一種の節電機構があるということはありませんか？

> 　例えば（？）LX なんかは電源管理のために速度が大きく変動する訳ですが，
> ポケ３も一種の節電機構があるということはありませんか？

あります。常用環境で節電ＯＮにしています。
今回は常用環境の所要時間を測るのが目的だったため、節電ＯＮのままで計測して
います。

とりあえずわかったことは、ポケ３の場合、外部ループのためのループカウンタの
演算とか比較に長い時間を取られてしまうようで、外部ループの回数が少ない方が
速い、というのは間違いないようです。
あと、母艦の場合は測定項目によってきちんと速度差が生じるのにポケ３だと速度
の差が生じないというのが大きな謎ですが、これはもしかして、じつはそれぞれの
測定項目は５０００回の繰り返しでは１秒程度で終わっていて、残りの数十秒は全
てループカウンタ等の処理に費やされているのではないか、という疑いもあります。
ただ、そうだとすると、３番目の項目の、代入とフラグ変化を一度に行うものが、
それぞれを一つずつ行ったものと値は異なっているというのが良くわからない。

う〜ん、きちんとした値を出すには、やはり節電ＯＦＦにしないとダメそうです。
が、そうすると結局、省電力ＯＮになっている常用環境でスピードを出すにはどう
するか、という問題が残ってしまうわけで。
あとは、問題となっているループの部分を丸まるマシン語に書きかえるくらいしか
解決策はないのでしょうが、さすがにそれをやるだけの知識と根性とスキルはあり
ません。
 

興味の有る話題なので、横から失礼します。

> あと、母艦の場合は測定項目によってきちんと速度差が生じるのにポケ３だと速度
> の差が生じないというのが大きな謎ですが、これはもしかして、じつはそれぞれの
> 測定項目は５０００回の繰り返しでは１秒程度で終わっていて、残りの数十秒は全
> てループカウンタ等の処理に費やされているのではないか、という疑いもあります。

これ、LXでも有ります。経験的に、節電ONとOFFでは天と地ほどの差が出るんですよ。
だからこそ、マクロ実行中に節電OFFという技が生まれ、高橋版にも取り入れられた
わけですね。ただ、これもマクロ実行中のみという欠点があるんですね。そこで、
 kVZ の出番です。(^_^)

 kVZを常駐しておけば、VZだろうがその他のコマンドだろうが処理中は常にフル
パワーで動作し、処理が終わってキー入力待ちになった瞬間に省電力モードに移行
するので、スピードと省エネが両立出来ます。

通常の省電力システムは一定時間ごとにCPU等の状態をチェックして、ON/OFFを切り
替えているのでタイムラグが有りますが、kVZではタイムラグが有りません。(^_^)
なので、劇的な省電力効果が期待できます。(たぶん)

もう察しがついていると思いますが、つまり、オアポケ３用VZにアイドルコールを
仕込むのが最善の策ではないかなという提案です。

私が以前アセンブルしたオアポケ３用VZが有りますので、としきさんが人柱^H^H
動作試験をしてくれればうれしいなぁと。

> 私が以前アセンブルしたオアポケ３用VZが有りますので、としきさんが人柱^H^H
> 動作試験をしてくれればうれしいなぁと。

ポケ３用のアイドルコードって、ax=$4102,int 0ABhを使ったものですよね。
それ、ほしい。ぜひ試させていただけませんか？
 

> > 私が以前アセンブルしたオアポケ３用VZが有りますので、としきさんが人柱^H^H

実際はオアポケ３用にアセンブル出来ているかも判らない代物なんですが。(^^;
 
> ポケ３用のアイドルコードって、ax=$4102,int 0ABhを使ったものですよね。
> それ、ほしい。ぜひ試させていただけませんか？

以前板塀に書き込んだ時のものでよければメールしますが、おそらく問題が
あると思いますし、アイドルコールも仕込んでません。これが万が一動いたら
次のステップに行こうという長期計画です。

＃節電OFFでも変らないとは・・・早くも計画倒れか。

> 実際はオアポケ３用にアセンブル出来ているかも判らない代物なんですが。(^^;

チェックします。というか、させてください。

> 以前板塀に書き込んだ時のものでよければメールしますが、おそらく問題が
> あると思いますし、アイドルコールも仕込んでません。これが万が一動いたら
> 次のステップに行こうという長期計画です。

結構でございます。送付方よろしくお願いします。
なんでしたら、URLだけ送っていただくというのでも構いませんよ。
該当の場所からダウンロードしますから。
 

> 結構でございます。送付方よろしくお願いします。

 0:51 頃にメールで送りました。・・・もしかして届かなかったカナ。

>  0:51 頃にメールで送りました。・・・もしかして届かなかったカナ。

確認しました。届いております。
まだ会社でして、仕事の合間のメールチェックなものでタイミングがずれました。

> 確認しました。届いております。
> まだ会社でして、仕事の合間のメールチェックなものでタイミングがずれました。

差分にするのが面倒なので、そのままLHAで固めたんですが問題ないですよね。

もし、無事に動くようでしたら、ポケ3のBIOS関係を教えて欲しいんですが。
キー入力関係と節電ON/OFFくらいですかね。

＃ここで続けてもいいですが、板塀に移動したほうがいいかなぁ。

> 差分にするのが面倒なので、そのままLHAで固めたんですが問題ないですよね。

問題ありません。ちょっと試して見ただけですが、無事に動いております。
今のところは異常が見つかっておりません。とりあえず、しばらく使ってみます。
＃ベクターに上がっている版と、微妙に異なっていますね。


> ＃ここで続けてもいいですが、板塀に移動したほうがいいかなぁ。

そうですね。
konnoさんのところのＶｚ改造掲示板（？）か私のところに移動して、もしこの
マクロが速くなれば、またこちらに報告に来るという形でいいと思います。
 

> 問題ありません。ちょっと試して見ただけですが、無事に動いております。
> 今のところは異常が見つかっておりません。とりあえず、しばらく使ってみます。

よかった、これで続けられますね。

> ＃ベクターに上がっている版と、微妙に異なっていますね。

300byteくらいっだたかな、アセンブルオプションとかに違いが有るのかも
しれませんね。

> konnoさんのところのＶｚ改造掲示板（？）か私のところに移動して、もしこの
> マクロが速くなれば、またこちらに報告に来るという形でいいと思います。

では、オアポケ3の話題と言うことで続きは板塀で。BIOS情報とか資料的な
ものは1箇所にあったほうがいいですよね。

> konnoさんのところのＶｚ改造掲示板（？）か私のところに移動して、もしこの
> マクロが速くなれば、またこちらに報告に来るという形でいいと思います。

　ご配慮ありがとうございます。わたしが誘導すると何だか出てけって言って
るように聞こえると困るなぁって。

　わたしの方は，マクロ側のアプローチとして，ループ部分の高速化について
考えておきますね。

> 今回は常用環境の所要時間を測るのが目的だったため、節電ＯＮのままで計測して
> います。

とりあえず、４項目だけですが、節電ＯＦＦにして計測してみました。
・・・変わらない。(^^;
多分、省電力設定は無関係なのでしょう。
以前にもにどこかに書いたことがありますが、ポケ３でＶｚを使っていると、節電
ＯＮにしてあるにも関らず、まるで節電ＯＦＦであるかのように電池が消耗してし
まいます。きっとポケ３用のＶｚは、マシンを常にフル稼動させているのでしょう。

え〜と、省電力設定以外に関係のありそうなものってなにか思いあたりませんか？
 

> とりあえずわかったことは、ポケ３の場合、外部ループのためのループカウンタの
> 演算とか比較に長い時間を取られてしまうようで、外部ループの回数が少ない方が
> 速い、というのは間違いないようです。

　ええ，そうなんですね。先般の逆順比較でもループ部分だけ機械語にしたら
劇的に速くなるなど， VZ マクロはループに弱いのではないかと思われるフシ
もあります。

> あとは、問題となっているループの部分を丸まるマシン語に書きかえるくらいしか
> 解決策はないのでしょうが、さすがにそれをやるだけの知識と根性とスキルはあり
> ません。

　いや，ちゃんとした言語の書けるとしきさんなら，ループ部分を機械語にす
るくらいわけないと思いますよ。根性はともかく，知識とスキルは問題がない
のでは？

　わたし，この間機械語部品を書きましたけれど，「はじめて読む８０８６」
を参照して初めて書いたようなものでも一応動きましたよ。

> hsを減らしたら、大幅に改善しました。
> ただ、hsのサイズというよりも、ヒストリーに記録されている文字列の個数に依存

hs1024のままで、ヒストリーに記録されている文字列を１０個くらいにしたら、
１秒くらいで帰ってくることがわかりました。なんか、hs16の時よりも速いよ
うな気がする。(^^;
もしかして、hsを小さくし過ぎたのかな。そして、文字列の方が長いから後ろ
のバッファを壊して、どこかよその世界まで探しに行っていたとか。

ちょっと今日は時間切れでこれ以上追求できないけど、あとでちょっと試して
みましょう。
＃明日は人間ドック、そのあとそのまま宿直勤務。
 

> もしかして、hsを小さくし過ぎたのかな。そして、文字列の方が長いから後ろ
> のバッファを壊して、どこかよその世界まで探しに行っていたとか。

　その可能性…と言うよりも， おそらくそれが結論かと思いますが， いくら
hs を小さくしても，vz.def の *H ヒストリー の :string で設定された文字
列が強制的に書き込まれるようですから，それによって後ろのバッファが破壊
されて ps に連結してしまうと考えられます。ところがヒストリーバッファの
サイズは変だし，ヒストリーバッファのサイズよりも大きな文字列を格納しよ
うとすると，さらにバッファが壊されていくという現象に一票。(^^;

　まぁ，他所の世界と言っても，ヒストリーバッファがいくつか続いていると
ころですから連続したヌルが出現するまでさほど時間はかからないと思います。
するとやっぱり，バッファの問題だけではないような気がしますね。

> 　その可能性…と言うよりも， おそらくそれが結論かと思いますが， いくら

う〜む。今回の件は、対照実験として行ったものが、正常系だと思っていたのが実は
異常系で、結果として間違った方向に突っ走ってしまったようです。

> するとやっぱり，バッファの問題だけではないような気がしますね。

きっと、ループの部分が妖しいのでしょう。
 

階層が深くなってきたという事もありますが、どこにレスをつけていいかわから
なくなってきたので、ここにつけます。

> :L      (p.0)??>Q                       ;ヒストリの終わりか?
>         &SX(p,ps)                       ;取得文字列とヒストリの文字列の比較
>         (r)??{  f..0=p,f.2-,            ;一致したらそのアドレスと記憶し、
>                 >Q}                     ;       ガードしないフラグを off
>         &Sn(p)                          ;ヒストリの文字列の長さ取得
>         p+=r+1,                         ;次の文字列へ
>         >L
> :Q      ps],                            ;ヒストリバッファポインタ復元

このルーチンのマシン語化を考えています。
マクロから受け取る必要がある変数は、f,p,psの３個。
いずれもポインタ渡しなので、戻り値のための特別な考慮は不要。

ということで、なんか、自分でも書けそうな気がしてきました。
ついては、マシン語ルーチンとの変数の受け渡しに関しての参考になるような、
だれかの講座とか誰かのサンプルマクロを紹介していただけないでしょうか。
例によってまた、ヒントだけいただければ自分で探します。
 

　おっ，ご自分で書きますね。(^^)

> ついては、マシン語ルーチンとの変数の受け渡しに関しての参考になるような、
> だれかの講座とか誰かのサンプルマクロを紹介していただけないでしょうか。

　機械語の講座としては，Emmett 博士の「Emmett のマシン語勉強会」があり
ますね。ライブラリには上がってなかったかもしれないです。

　1997年1月からFGALDC/MES/15で始まっています。#3935が起点です。

> 　機械語の講座としては，Emmett 博士の「Emmett のマシン語勉強会」があり
> ますね。ライブラリには上がってなかったかもしれないです。

手元にあったものを無事にサルベージできました。
ＬＺＨで固めてあったので、ライブラリからダウンしたのか、それとも石部屋
から入手したのかもしれません。

で、これを参考に、以下のようなものをでっち上げてみました。

;si=p,di=ps,bx=f,
L:
        mov al,byte ptr [si+0]   ;(p.0)?
        xor ah,ah                ;
        cmp ah,al                ;
        je Q                     ;     ?>Q
                                 ;
        xor bp,bp                ;&SX(p,ps)
SX:
        mov ah,[si+bx]
        mov al,[di+bx]
        cmp al,ah
        jnz DIFF
        dec ax                   ;文字列終端ならalもahも０のはず
        jc MATCH                 ;０をデクリメントすればキャリーが立つはず
        inc bx
        jmp SX
MATCH:  
        xor al,al
        jz SXEND
DIFF:
        mov al,1
SXEND:
                                 ;
        cmp al,1                 ;(r)?
        je L1                    ;   ?{
        mov word ptr [bx+0],si   ;   f..0=p,
        xor al,al
        mov byte ptr [bx+2],al   ;   f.2-,
        jz Q                     ;>Q}
L1:                              ;&Sn(p)
        xor al,al
        xor bp,bp
        dec bp
Sn:
        inc bp
        cmp byte ptr [si+bp],al
        jne Sn

        add si,bp                ;p+=r+1,
        inc si                   ;
        jmp L                    ;>L
Q:                               ;
        ret

まだ、実際にマクロに組み込んで試してはいません。なにせ恐くて。
簡単で結構ですから、ちょっとロジックをチェックして見ていただけませんか？
特に私、Ｖｚのマクロにおける条件分岐の、真と偽の判定に使う数値の扱いが
まだ良くわかっていないので、もしかしたら条件が思いっきり反転してしまっ
ているかもしれません。文字列演算の関係なんか、一致していたら偽、なんて
コードを書かざるをえないのはマクロの仕様が美しくないところなんだと思い
ますが、おかげで頭がこんがらがってしまいました。

なお、こういうのは最適化とは言わないな、普段の自分のコードとは違って、
ちょっとだけマニアックなコードになっています。具体的に言うと、アセンブ
ル後の結果においてヌルが入らないようになっているのです。
だからと言ってあんまりうれしいことはないと思いますが、もしかするとＶｚ
のマクロの場合に限って、この性質があるとうれしいことがあるかもしれない
ような気もします。って、そもそもこのコードが正しいかどうかが不明なうち
に、そういう細工をするべきではないかも。
 

> 簡単で結構ですから、ちょっとロジックをチェックして見ていただけませんか？

　わたしが添削を？？ 世にも恐ろしいことを考えないでください。(笑)
　多分，暴走しても VZ が落ちるだけでしょうから，実行してみた方が早いと
思いますよ。て言うか，わたしはまだどのケースでどのレジスタを使うかなん
て基本もマスターしていないですもん。読むのは苦痛です。(^^;

　条件分岐に限って言えば， VZ よりもアセンブラの方がよほど親切なんじゃ
ないでしょうか。比較でも符号ありなしを選べますし，ジャンプ命令も豊富で
すし。あ，マクロの方の話でしたっけ。これは，マクロの方をもっと単純に書
けばよいのだと思います。 例えば，(p.0)?? なんていうのは (p.0==0)? とす
ればいいし， (r)?? も (r==0)? としておいてニーモニックに置き換えれば，
そのまま適切なジャンプ命令が使えると思ったりもするんですよね。

> ちょっとだけマニアックなコードになっています。具体的に言うと、アセンブ
> ル後の結果においてヌルが入らないようになっているのです。

　これ，多分 Emmett 博士の講座にも出てきたと思いますが，途中にヌルが入
らなければ，文字列としてグローバルマクロ内部に置けるという利点があるこ
とになっています。逆に言えば，ローカルに追い出せばよいというだけのこと
なので，わたしはあまり気にしていませんでした。

> 　多分，暴走しても VZ が落ちるだけでしょうから，実行してみた方が早いと

は〜い。
明日の午後はヒマになる予定なので、ちょっと試してみます。

> すし。あ，マクロの方の話でしたっけ。これは，マクロの方をもっと単純に書
> けばよいのだと思います。 例えば，(p.0)?? なんていうのは (p.0==0)? とす
> ればいいし， (r)?? も (r==0)? としておいてニーモニックに置き換えれば，
> そのまま適切なジャンプ命令が使えると思ったりもするんですよね。

この辺は、元のマクロをなるべく生かしたいという思いもあったりします。
というか、論理を変えずにうまく変形できる自信がないというか。
先にも書いたように、どっちが０でどっちが１か、というのが完全にこんがら
がっているのです。

> らなければ，文字列としてグローバルマクロ内部に置けるという利点があるこ
> とになっています。逆に言えば，ローカルに追い出せばよいというだけのこと

ここのところも、元のマクロをそのまま置き換えられるように、というような
事を考えてしまっていたりしたのでした。
 

> で、これを参考に、以下のようなものをでっち上げてみました。

このコードにはバグがありますね。アセンブルする直前に気がつきました。
ということで、ちょっとだけ書き直して、以下のようなソースになりました。

L:
        mov al,byte ptr [si+0]   ;(p.0)?
        xor ah,ah                ;
        cmp ah,al                ;
        je Q                     ;     ?>Q
                                 ;
        xor bp,bp                ;&SX(p,ps)
SX:
        mov ah,[si+bp]
        mov al,[di+bp]
        cmp al,ah
        jnz DIFF
        dec ax                   ;文字列終端ならalもahも０のはず
        jc MATCH                 ;０をデクリメントすればキャリーが立つはず
        inc bp
        jmp SX
MATCH:  
        xor al,al
        jz SXEND
DIFF:
        mov al,1
SXEND:
                                 ;
        cmp al,1                 ;(r)?
        je L1                    ;   ?{
        mov word ptr [bx+0],si   ;   f..0=p,
        xor al,al
        mov byte ptr [bx+2],al   ;   f.2-,
        jz Q                     ;>Q}
L1:                              ;&Sn(p)
        xor al,al
        xor bp,bp
        dec bp
Sn:
        inc bp
        cmp byte ptr [si+bp],al
        jne Sn

        add si,bp                ;p+=r+1,
        inc si
        jmp L                    ;>L
Q:                               ;
        ret

これをアセンブルして組み込んだマクロ全体は以下のようなものになりました。

24 ^L [F05] "検索文字列の連続取得"
	?.
	p[=ps,				;ヒストリバッファポインタの複写
	&>				;バッファとフラグの参照
	q[6+f,				;
	(mb||ct<2)?{f.3+,#G >Z}		;ブロックモードのとき
	(f.3||cm-59)?>B			;連続実行でない
	&s				;高速表示機ではコメントアウトする
	ly[,
	&Sn(ps)				;ヒストリの先頭の文字列の長さ取得
	(f.2)?{				;ガードしないフラグが on のとき
		&Sm(ps,ps+r[++,(ps-2)..0-r)	;先頭の文字列を削除
		>M}
	&Sh(q,ps)			;ヒストリの先頭の文字列を
	&Sm(ps,ps+r[++,f..0-ps)		;	元の位置に
	&Sc(f..0,q)			;		戻す。
:M	#b				;取得する文字列のライトアップ
	cp+=0],				;	|
	(mr-$80)?#28?{cp--,#d}		;	|
:A	(ct>1)?{ct[, #d (ct>=0])? >A }	;	|
	#B				;	^
	(ly-0]-1)??{#z#e mb2,}		;画面表示位置補正
	#?				;	
:B	ps[=q,				;ヒストリバッファポインタのすり替え
	#G				;バッファに文字列取得
	&s
	f.2+,				;ガードしないフラグの on
	
	si=p,di=ps,bx=f,
	&01
;:L	(p.0)??>Q			;ヒストリの終わりか?
;	&SX(p,ps)			;取得文字列とヒストリの文字列の比較
;	(r)??{	f..0=p,f.2-,		;一致したらそのアドレスと記憶し、
;		>Q}			;	ガードしないフラグを off
;	&Sn(p)				;ヒストリの文字列の長さ取得
;	p+=r+1,				;次の文字列へ
;	>L
;:Q	
	p=si,
	ps],				;ヒストリバッファポインタ復元
	f.3-,				;ブロックフラグ off
	&Sh(ps,q)			;バッファからヒストリへ複写
	&Sn(ps)				;取得文字列の長さを得る
:Z	q],f],p],
	(r)				;取得文字列の長さを内部レジスタに

0:	f[2+$,."123$(00,01)$[256]"

1:	&i(3+$)."$
	$(8A,04,32,E4,3A,E0,74,34,33,ED,8A,22,8A,03,3A,C4)$
	$(75,0B,48,72,04,45,E9,F1,FF,32,C0,74,02,B0,01,3C)$
	$(01,74,09,89,37,32,C0,88,47,02,74,10,32,C0,33,ED)$
	$(4D,45,38,02,75,FB,03,F5,46,E9,C4,FF,C3)"

で、早速実行してみたら・・・う、速い。
見事、１秒未満というか、ほぼ即時にカーソルが帰ってくるようになりました。
もしかしたらまだバグが残っているかもしれませんが、とりあえず一発で完動
しました。一発完動教の教徒じゃないのですが、なんか帰依してしまいそう。

ところで、200LXとか使っている人がいたら教えてほしいのですが、そういった
比較的低速のマシンでこのマクロを動作させた場合、マシン語を使った場合と
使わなかった場合で大きく速度は異なりますでしょうか。
多分、クロックが20MHz以上のマシンならばマシン語を使わずとも実用的に問題
ない速度が出ると思いますので、それ以下の速度のマシンを使っている方に教
えていただきたいです。もしあまり差がないという事であれば、ポケ３だけが
著しく遅いという事になります。マシン語化したら体感的に速度が向上したと
いうのであれば、単にクロックスピードの問題だという事がわかるので、私と
してはちょっとだけほっとします。
   

　わたしの環境 HP200LX 2MB RAM i186 無改造品で，GGW.def を実行してみる
と，機械語バージョンを使用するまでもなく，瞬時に取得できています。

　思えば，作者の NaruTo さんは，かの震災の折りに何よりも先ず LX の保護
を優先したような LXer で， ドキュメントによれば v1.5x 時代は機械語版を
作り，v1.6では文字列関数版にとどめたということですね。もしも LX で速度
面に不満があれば迷わず機械語版を作成していたに違いありません。でも，そ
れはしなかった。LX でも速度に不満がなかったからですよね，おそらく。

　そんなわけで，今回の現象はオアポケ特有だと思います。 わずか 16バイト
のバッファの走査が 2〜3秒かかるというのは，どう考えても異常で， 人間の
目よりも遅いかもしれません。でも，文字列関数を使うマクロがすべてオアポ
ケで遅くなるとしたら，もっと以前から大騒ぎになっていると思います。他の
検索文字列取得マクロの場合はどうなのでしょう。ガード機能がある分，時間
がかかるのは当然なのですが，それにしても，…と思います。

> 　そんなわけで，今回の現象はオアポケ特有だと思います。 わずか 16バイト

(;_;)

> 目よりも遅いかもしれません。でも，文字列関数を使うマクロがすべてオアポ
> ケで遅くなるとしたら，もっと以前から大騒ぎになっていると思います。他の

ですよねぇ。
ベンチマークの結果から考えると、なんとなく、文字列関数ではなくループの
制御に問題があるような気もしますが、それにしたって、他にループを使うマ
クロは山のようにありますが、同様に、問題があるという話は聞かないし。
でも、hs16でヒストリ内の文字列が１個だけのときはループの回数も１回だけ
で脱出してしまうはずですが、それでも遅いという事は、やはり文字列関数？
なんか、どっかで割り込みがかかっているのかなぁ。

参考までに、１つ教えてください。
hs16のときに２０字を越えるような長い検索文字列を使っても、きちんとヒス
トリに記録されているような感じです。これって本当にヒストリに入っている
のでしょうか。それとも、何かのバッファを壊しているのでしょうか。

> 検索文字列取得マクロの場合はどうなのでしょう。ガード機能がある分，時間

他のマクロって、どんなものがありますでしょうか。
手頃なものを紹介していただけないでしょうか。
また、検索文字列取得マクロに限らず、文字列関数を使いまくるマクロだの、
ループぐるぐるなマクロというものでも結構です。

あ、そうだ。
同じくNaruToさんのVZTOWER.DEF、これもイニシャライズのところのカウントが
ちょっと長いような気もするけど、でも、数十秒というか、１分まではかから
ないな。それに、ゲームが始まってしまえば、まぁまぁ十分速いと思うし。