[HOME]  [全部表示 会議室風]  [全部表示 保存用]  [HOME]  [リストへもどる] [リストへもどる]

一括表示


  VTDOSでSORT.DEF(高橋版) - konno 18/10/12-21:41 No.8314
 ┣ Re: VTDOSでSORT.DEF(高橋版) - konno 18/10/12-21:49 No.8315
 ┃ ┗ Re^2: VTDOSでSORT.DEF(高橋版) - 文太 18/10/12-22:22 No.8316
 ┃ ┗ Re^3: VTDOSでSORT.DEF(高橋版) - konno 18/10/12-22:52 No.8317
 ┃ ┃┃┣ Re^4: VTDOSでSORT.DEF(高橋版) - 文太 18/10/12-23:40 No.8318
 ┃ ┃┃┗ どうでもいいこと - 文太 18/10/13-00:13 No.8319
 ┃ ┃┃┣ Re^4: VTDOSでSORT.DEF(高橋版) - 10♯ 18/10/13-06:42 No.8321
 ┃ ┃┃┗ Re^5: VTDOSでSORT.DEF(高橋版) - konno 18/10/13-16:18 No.8325
 ┃ ┃ ┗ Re^4: VTDOSでSORT.DEF(高橋版) - 10♯ 18/10/13-06:44 No.8322
 ┃ ┃ ┗ Re^5: VTDOSでSORT.DEF(高橋版) - konno 18/10/13-16:41 No.8327
 ┣ Re: VTDOSでSORT.DEF(高橋版) - 10♯ 18/10/13-06:32 No.8320
 ┃ ┗ Re^2: VTDOSでSORT.DEF(高橋版) - konno 18/10/13-15:59 No.8324
 ┃ ┗ Re^3: VTDOSでSORT.DEF(高橋版) - 10♯ 18/10/13-18:43 No.8331
 ┣ Re: VTDOSでSORT.DEF(高橋版) - としき 18/10/13-14:40 No.8323
 ┃┃┣ Re^2: VTDOSでSORT.DEF(高橋版) - 10♯ 18/10/13-16:34 No.8326
 ┃┃┗ Re^3: VTDOSでSORT.DEF(高橋版) - konno 18/10/13-17:06 No.8329
 ┃┃┃ ┗ Re^4: VTDOSでSORT.DEF(高橋版) - 10♯ 18/10/13-18:44 No.8332
 ┃ ┗ Re^2: VTDOSでSORT.DEF(高橋版) - konno 18/10/13-16:49 No.8328
 ┃ ┣ Re^3: VTDOSでSORT.DEF(高橋版) - としき 18/10/13-17:39 No.8330
 ┃ ┃ ┗ Re^4: VTDOSでSORT.DEF(高橋版) - 文太 18/10/13-19:25 No.8333
 ┃ ┃ ┗ ddは取りあえず避けたほうが - 文太 18/10/13-19:34 No.8334
 ┃ ┃ ┃ ┗ aa, bb, cc がオススメ - 文太 18/10/13-19:47 No.8335
 ┃ ┗ SORT.DEF(高橋版)の問題はここ? - konno 18/10/15-23:17 No.8342
 ┃  ┗ Re: SORT.DEF(高橋版)の問題はここ? - としき 18/10/16-00:19 No.8343
 ┃   ┣ Re^2: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/16-00:48 No.8344
 ┃   ┃ ┗ Re^3: SORT.DEF(高橋版)の問題はここ? - konno 18/10/16-02:10 No.8346
 ┃   ┃ ┗ Re^4: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/16-03:07 No.8347
 ┃   ┃  ┣ Re^5: SORT.DEF(高橋版)の問題はここ? - 文太 18/10/16-18:45 No.8349
 ┃   ┃  ┃ ┗ Re^6: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/16-19:11 No.8350
 ┃   ┃  ┃ ┣ Re^7: SORT.DEF(高橋版)の問題はここ? - 文太 18/10/16-20:53 No.8351
 ┃   ┃  ┃ ┃ ┗ Re^8: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/16-21:14 No.8352
 ┃   ┃  ┃ ┃ ┣ Re^9: SORT.DEF(高橋版)の問題はここ? - 文太 18/10/16-23:14 No.8355
 ┃   ┃  ┃ ┃ ┗ Re^9: SORT.DEF(高橋版)の問題はここ? - 文太 18/10/16-23:32 No.8356
 ┃   ┃  ┃ ┃ ┃ ┗ Re^10: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/17-00:16 No.8358
 ┃   ┃  ┃ ┗ Re^7: SORT.DEF(高橋版)の問題はここ? - konno 18/10/17-01:40 No.8360
 ┃   ┃  ┃  ┣ Re^8: SORT.DEF(高橋版)の問題はここ? - 文太 18/10/17-08:29 No.8361
 ┃   ┃  ┃  ┃┃┣ Re^9: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/17-10:02 No.8363
 ┃   ┃  ┃  ┃┃┗ Re^10: SORT.DEF(高橋版)の問題はここ? - 文太 18/10/17-14:23 No.8364
 ┃   ┃  ┃  ┃┃ ┗ Re^11: SORT.DEF(高橋版)の問題はここ? - 文太 18/10/17-16:24 No.8365
 ┃   ┃  ┃  ┃┃  ┗ 基点ポインタ(?)の絶対アドレス - 文太 18/10/17-17:20 No.8366
 ┃   ┃  ┃  ┃┃┣ Re^9: SORT.DEF(高橋版)の問題はここ? - konno 18/10/17-18:49 No.8367
 ┃   ┃  ┃  ┃┃┗ Re^10: pc ズレ、やばいかも - konno 18/10/17-20:37 No.8370
 ┃   ┃  ┃  ┃ ┗ Re^9: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/18-06:04 No.8372
 ┃   ┃  ┃  ┃ ┗ Vz文化 - 文太 18/10/18-13:15 No.8373
 ┃   ┃  ┃  ┃  ┗ Re: Vz文化 - 10♯ 18/10/18-14:42 No.8374
 ┃   ┃  ┃  ┗ Re^8: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/17-09:46 No.8362
 ┃   ┃  ┃   ┗ VZk の pc ズレ問題 - konno 18/10/17-19:10 No.8368
 ┃   ┃  ┗ Re^5: SORT.DEF(高橋版)の問題はここ? - konno 18/10/16-22:22 No.8353
 ┃   ┃   ┗ Re^6: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/17-00:21 No.8359
 ┃   ┗ Re^2: SORT.DEF(高橋版)の問題はここ? - konno 18/10/16-01:19 No.8345
 ┃    ┗ Re^3: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/16-09:33 No.8348
 ┃     ┗ Re^4: SORT.DEF(高橋版)の問題はここ? - konno 18/10/16-23:13 No.8354
 ┃      ┗ Re^5: SORT.DEF(高橋版)の問題はここ? - 10♯ 18/10/16-23:43 No.8357
 ┗ VTDOSでSORT.DEF(高橋版)の bl が変? - konno 18/10/22-00:27 No.8410
  ┗ Re: VTDOSでSORT.DEF(高橋版)の bl が変? - 10♯ 18/10/22-06:01 No.8411

(8314) 8314VTDOSでSORT.DEF(高橋版)  投稿者:konno   2018/10/12(金) 21:41
   コメント数 4

問題の切り分けのため、新スレにします。>文太さん,ALL
#8307 で書いたんですが

> 関連の記事が、#6580 あたりにありますが、必ず落ちるマクロとして
> 1997/10/06  23:03             8,273 SORT.DEF (高橋版)があります。
> これで、同じく高橋さんの
> 1998/08/23  21:18            18,312 dseg.map
> をファイル先頭から最後までブロックしてマクロ起動し
> メニューが出たらそのまま Enter すると、ソートされます。
> Esc で終了すると、VTDOSが'REP MOVSB 命令ラップアラウンド' で落ちます。

これは、どうも違う原因で落ちているようなので、皆さんのお知恵をいただきたく
 関連の記事、#6580 の一部を貼り付けます。


SORT.DEF(高橋版)はやっぱり落ちますね。調べてみたところ、
メニューを抜けた時のファイルクローズ処理で落ちているようです。
マクロの最後のサブルーチンです。

06:	; close
	(u)??.
	(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
	bx=u,ax$3E00,&i($21) dx=pq..149,ax$4100,&i($21) u-,   ; ★

ここをコメントにすると、編集ファイルを閉じた時に落ちます。

;	F_CLOSE		equ	3Eh		; Close a File Handle
;	F_DELETE	equ	41h		; Delete a Directory Entry

ここではこの2つのDOSコールを読んでいますが、おそらく
VTDOSはF_CLOSEのタイミングでエラーメッセージを出しているのでしょう。
エラーメッセージ自体はまったく同じです。


あらためて、検証してみるためにトレースしてみると

	(u)??.
	&t 					;★ここからトレース
	(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
                  ^^^^^^^
この、&#T のところで落ちました。
以前試したときはここは通ったと思ったので、タイミングの問題か?

それで、&t の後に、.(ピリオド)を入れて、終了させたところ
テキストはソートされていましたが、F3 テキストの切り替えで見ると
全く同じパスが二つ並んでいました。げげげ

裏のテキストが変更前のテキストだろうと思い、カーソルで選択したら
VTDOSがエラーで落ちました。


この問題を回避するには、マクロのどこを修正すればいいか、皆様のお知恵を
拝借したく存じます。
作業用のパス名を変えれば良さそうな気がするんだけど、読めないの(;_;)


      - No.8314 -    このTreeへ           [リストへもどる] pre

(8314) 8315Re: VTDOSでSORT.DEF(高橋版)  投稿者:konno   2018/10/12(金) 21:49
    8314 番 konno さんへのコメント    コメント数 1

#8313 のまたぎレスです。

>  konnoさん、ビンゴ、というべきなのか、どういうべきなのか、上の指定で、高橋版
> sort.defが見事に
> 2018-10-12 20:21:49 VZ(15F3) 15F3:09DA 'REP MOVSW 命令ラップアラウンド'

VTDOS は再起動してから試して、この結果ですか?
続きはこのスレでお願いします。m(__)m


      - No.8315 -    このTreeへ    コメント元:8314 へ [リストへもどる] soft

(8314) 8316Re^2: VTDOSでSORT.DEF(高橋版)  投稿者:文太   2018/10/12(金) 22:22
    8315 番 konno さんへのコメント    コメント数 1

>VTDOS は再起動してから試して、この結果ですか?
>続きはこのスレでお願いします。m(__)m
 はい。2回やって(1回目も再起動していました)、2個の同じログが残っています。
 残されたコード列は、もちろん2つが同一で、前回、僕が10#さんに解析してもらった
(Vzソースをkonnoさんに見てもらった)ものとは、違いました。

      - No.8316 -    このTreeへ    コメント元:8315 へ [リストへもどる] soft

(8314) 8317Re^3: VTDOSでSORT.DEF(高橋版)  投稿者:konno   2018/10/12(金) 22:52
    8316 番 文太 さんへのコメント    コメント数 3

>  はい。2回やって(1回目も再起動していました)、2個の同じログが残っています。

うーむ、SCASB_MODE=1 でエラーが出るとすると、初めての事例となりそうです。
#8307 にも書きましたが、SCASB_MODE=1 では落ちたことがないのです。

>  残されたコード列は、もちろん2つが同一で、前回、僕が10#さんに解析してもらった
> (Vzソースをkonnoさんに見てもらった)ものとは、違いました。

私の環境ではこんな感じです。

2018-10-12 19:13:04 VZIBMJ(17DE) 17DE:149A 'REPNE SCASB 命令ラップアラウンド'

AX=000A BX=CADA CX=FFF4 DX=0100 SI=0001 DI=0001 BP=CADA DS=4364 ES=4364 FLAGS=0646

CS:IP=17DE:149A
17DE:148A 46 C3 51 57 06 1E 07 8B FE B9 FF FF B0 0A F2 AE 
17DE:149A 8B F7 07 5F 59 C3 B2 00 EB 1F E8 F9 FF 73 03 FF 

SS:SP=271D:C7F6
271D:C7E6 33 00 3C 1B 1A C8 08 C5 02 00 00 00 B8 91 64 43 
271D:C7F6 1D 27 13 7A 7E 1F 88 14 36 19 02 00 1F 19 E6 16 

-u 17DE:148A
17DE:148A 46            INC	SI                                 
17DE:148B C3            RET	                                   
17DE:148C 51            PUSH	CX                                 
17DE:148D 57            PUSH	DI                                 
17DE:148E 06            PUSH	ES                                 
17DE:148F 1E            PUSH	DS                                 
17DE:1490 07            POP	ES                                 
17DE:1491 8BFE          MOV	DI,SI                              
17DE:1493 B9FFFF        MOV	CX,FFFF                            
17DE:1496 B00A          MOV	AL,0A                              
17DE:1498 F2            REPNZ	                                   
17DE:1499 AE		SCASB	 		;★		   
17DE:149A 8BF7          MOV	SI,DI                              
17DE:149C 07            POP	ES                                 
17DE:149D 5F            POP	DI                                 
17DE:149E 59            POP	CX                                 
17DE:149F C3            RET	                                   
17DE:14A0 B200          MOV	DL,00                              
17DE:14A2 EB1F          JMP	14C3                               
17DE:14A4 E8F9FF        CALL	14A0                               
17DE:14A7 7303          JNB	14AC                               
17DE:14A9 FF460A        INC	WORD PTR [BP+0A]                   
-q

これは、VZ.MAP では

 0000:1490       ENDLIN

このへんですね。これは、CORE.ASM の
;--- Scan line start ptr  ---
endlin	proc
	pushm	<cx,di,es>
	movseg	es,ds
	mov	di,si
	mov	cx,-1
	mov	al,LF
  repne	scasb				;★
	mov	si,di
	popm	<es,di,cx>
	ret
endlin	endp


想像ですが、どこかでメモリかレジスタやフラグの状態がおかしくなって
scasb や、movsb movsw などに来ると、エラーチェックに引っかかって
落ちてしまうのではないかと。

SCASB_MODE=0 での実験でも、ソートしたテキストをセーブはできたのですが
その後 VTDOS が落ちました。
解決の道は遠いかもしれないですね。


      - No.8317 -    このTreeへ    コメント元:8316 へ [リストへもどる] pre

(8314) 8318Re^4: VTDOSでSORT.DEF(高橋版)  投稿者:文太   2018/10/12(金) 23:40
    8317 番 konno さんへのコメント    コメント数 1

>うーむ、SCASB_MODE=1 でエラーが出るとすると、初めての事例となりそうです。
 がーん。
 いまさら、がーん、もないぞ。

>解決の道は遠いかもしれないですね。
 のようですね。

 細かに、ありがとうございました。core.asm、とても勉強になりました。m(__)m

      - No.8318 -    このTreeへ    コメント元:8317 へ [リストへもどる] soft

(8314) 8319どうでもいいこと  投稿者:文太   2018/10/13(土) 00:13
    8318 番 文太 さんへのコメント

 基本的に、降参、撤退なので、だんだんこのことを考えることは
さすがになくなっていくと思うのですが、僕の環境が、Win7, 32bitだと
いうことも関係してるのか、してないのか、なんて考えたことがあります。
あまりポピュラーなOS環境ではないですよね。

 WindowsUpdateがあると、やっぱりマシン全体に、何かが変わるのね
と感じさせてくれます。Updateした直後の再起動のときなんか如実に。
今日、少しびびった。

 いつから、こんなに無関心になったのだろうと考えていて。かつては、
落ちるなんて、滅多になかったはずなので。最近突然、という意味では
ないです。窓が落ちて、書いた文章を失って、なんてことに「慣れたり」
するには、1年とか、かかっていると思います。


      - No.8319 -    このTreeへ    コメント元:8318 へ [リストへもどる] soft

(8314) 8321Re^4: VTDOSでSORT.DEF(高橋版)  投稿者:10♯   2018/10/13(土) 06:42
    8317 番 konno さんへのコメント    コメント数 1

この課題が出たの2015年のようですが、
sort.defでendlinが直接の問題箇所だったのを僕も覚えています。
ていうか、ここまで突き止めて対処療法にしかならないけどって断った上で
付けたのがscasb_modeです。
この事がどう受け止められたかはよく分りませんが、
VZのワークに異常が起こってるので本来すべき対応ではありません。
sort.defは僕が知る限り問題発生時の対応が最も困難なマクロの一つで、
開発当時の高橋氏の協力でも得られない限り原因究明は無理です。

      - No.8321 -    このTreeへ    コメント元:8317 へ [リストへもどる] soft

(8314) 8325Re^5: VTDOSでSORT.DEF(高橋版)  投稿者:konno   2018/10/13(土) 16:18
    8321 番 10♯ さんへのコメント

> ていうか、ここまで突き止めて対処療法にしかならないけどって断った上で
> 付けたのがscasb_modeです。
> この事がどう受け止められたかはよく分りませんが、
> VZのワークに異常が起こってるので本来すべき対応ではありません。

VZに潜在的なバグがあるとは以前から言われていましたが、高橋さんにも
全ては把握できなかったようで、今も残っていると思います。
なので、異常があることが分かっただけでもありがたいです。

SCASB_MODE=1 で、取りあえず以前の環境と同様に使えるようになって
いるとすれば、これは大変にありがたい機能です。
使い続けていればそのうちバグの真因がわかるかもしれませんし。

> sort.defは僕が知る限り問題発生時の対応が最も困難なマクロの一つで、
> 開発当時の高橋氏の協力でも得られない限り原因究明は無理です。

真の原因は他にありそうな気がするので、もう少しあがいてみます。


      - No.8325 -    このTreeへ    コメント元:8321 へ [リストへもどる] soft

(8314) 8322Re^4: VTDOSでSORT.DEF(高橋版)  投稿者:10♯   2018/10/13(土) 06:44
    8317 番 konno さんへのコメント    コメント数 1

mapファイルとロードアドレスの4バイトのズレはなんなんでしょうね?
      - No.8322 -    このTreeへ    コメント元:8317 へ [リストへもどる] soft

(8314) 8327Re^5: VTDOSでSORT.DEF(高橋版)  投稿者:konno   2018/10/13(土) 16:41
    8322 番 10♯ さんへのコメント

> mapファイルとロードアドレスの4バイトのズレはなんなんでしょうね?

あう、すみません、急いでいたのでつい別のバージョンのものを参照して
しまいました。

K07T1
 0000:148C       ENDLIN

こちらが該当のアドレスだと思います。

K07T4
 0000:1490       ENDLIN

こっちのほうが手近にあったもので、つい。(^^;
どうせソースにアドレスは無いと思って。(^^;;

プロの前でごまかしは効きませんね。m(__)m


      - No.8327 -    このTreeへ    コメント元:8322 へ [リストへもどる] pre

(8314) 8320Re: VTDOSでSORT.DEF(高橋版)  投稿者:10♯   2018/10/13(土) 06:32
    8314 番 konno さんへのコメント    コメント数 1

マクロの資料が手元に無いので今僕これを読むこと出来ないですけど、
^^^の部分は、VZはこういった構文を許容するんだって素朴な印象です。

#マクロ呼び出しのパラメータに-0へのポップを渡す?

この部分を含めてですが、このdefはどの部分を取っても今これを解析することは
相当困難に見えます。

F_CLOSEで落ちてる、って当時の解釈は誤認だったようですね。

      - No.8320 -    このTreeへ    コメント元:8314 へ [リストへもどる] soft

(8314) 8324Re^2: VTDOSでSORT.DEF(高橋版)  投稿者:konno   2018/10/13(土) 15:59
    8320 番 10♯ さんへのコメント    コメント数 1

> マクロの資料が手元に無いので今僕これを読むこと出来ないですけど、
> ^^^の部分は、VZはこういった構文を許容するんだって素朴な印象です。

これは、めざら資源>VZ Editorの歴史>軟体補完計画>作者順によるマクロ一覧

http://mezala.la.coocan.jp/vz/history/maclib1.html

この一覧の中にあります。

SORT.DEF sort.def 高橋版 1997/10/06 01826 高橋洋光 − SORT.LZH

ついでに、サンプルデータに使っている DSEG.MAP も近くにあります。

DSEG.MAP dseg.map 1998/09/02 02002 高橋洋光 − DSEG.LZH

これは、VZのソース、ワークエリアを読む参考書として重宝しています。

高橋版の SORT.DEF は、shadow さんをはじめ、多くの人が使用していて
特に問題は無かったと思われます。


> #マクロ呼び出しのパラメータに-0へのポップを渡す?
> この部分を含めてですが、このdefはどの部分を取っても今これを解析することは
> 相当困難に見えます。

普通の言語ではありえない省略を駆使するのは、FGALDCでは常識だったのです。
&t のトレースで大まかな流れは掴めてきましたが、とんでもない技を使ってVZを
騙しているみたいですね。

> F_CLOSEで落ちてる、って当時の解釈は誤認だったようですね。

どうやらそのようです。
SCASB_MODE=1 で落ちないのは、隠れた問題を先送りしている可能性が高い
のでしょうかね。
高橋版の SORT.DEF を攻略できれば、本当の原因が見えてくるのではないかと
思ったのですが、甘かったようです。


      - No.8324 -    このTreeへ    コメント元:8320 へ [リストへもどる] soft

(8314) 8331Re^3: VTDOSでSORT.DEF(高橋版)  投稿者:10♯   2018/10/13(土) 18:43
    8324 番 konno さんへのコメント

> これは、めざら資源>VZ Editorの歴史>軟体補完計画>作者順によるマクロ一覧
> この一覧の中にあります。
> SORT.DEF sort.def 高橋版 1997/10/06 01826 高橋洋光 − SORT.LZH

この本体は僕も入手してるんですけどね。
マクロの仕様が染みついてないのでマニュアル無しには読めないんです。

マクロ本体もそうですが、処理の大部分がマシン語ですね。

      - No.8331 -    このTreeへ    コメント元:8324 へ [リストへもどる] soft

(8314) 8323Re: VTDOSでSORT.DEF(高橋版)  投稿者:としき   2018/10/13(土) 14:40
参照先:http://toshiki.la.coocan.jp/
    8314 番 konno さんへのコメント    コメント数 2

このマクロ、私にもぜんぜん読めませんがね。

> 	(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
>                   ^^^^^^^
> この、&#T のところで落ちました。

1つめの&#Tは通るのですよね。
ここで2つめの&#Tに、保存しておいた id の値を使っていると思うのですが
スタックではなく別の変数に退避させておいたらどうなるでしょうか。
あと、あまり関係あるとは思いませんが、+512のバックアップオプションの
有無で挙動が変わったりとかします?
      - No.8323 -    このTreeへ    コメント元:8314 へ [リストへもどる] pre

(8314) 8326Re^2: VTDOSでSORT.DEF(高橋版)  投稿者:10♯   2018/10/13(土) 16:34
    8323 番 としき さんへのコメント    コメント数 1

> ここで2つめの&#Tに、保存しておいた id の値を使っていると思うのですが
> スタックではなく別の変数に退避させておいたらどうなるでしょうか。

普通に考えるとわざわざスタックを使う必要が全くないから謎なんですよね。

      - No.8326 -    このTreeへ    コメント元:8323 へ [リストへもどる] soft

(8314) 8329Re^3: VTDOSでSORT.DEF(高橋版)  投稿者:konno   2018/10/13(土) 17:06
    8326 番 10♯ さんへのコメント    コメント数 1

> > ここで2つめの&#Tに、保存しておいた id の値を使っていると思うのですが
> > スタックではなく別の変数に退避させておいたらどうなるでしょうか。
>
> 普通に考えるとわざわざスタックを使う必要が全くないから謎なんですよね。

#8314 に書きましたが
> それで、&t の後に、.(ピリオド)を入れて、終了させたところ
> テキストはソートされていましたが、F3 テキストの切り替えで見ると
> 全く同じパスが二つ並んでいました。げげげ

おそらくここで、VZを騙して普通なら出来ない同じパス名を作って、id で区別
させているのではないかと想像しました。

オリジナルのほうはその後閉じてしまって、ソート後のテキストのみが
同じパス名で残るという仕組みのようです。

そのままセーブすれば、上書き保存になるという、ビックリなやり方です。
読めていないので外していたらすみません。


      - No.8329 -    このTreeへ    コメント元:8326 へ [リストへもどる] soft

(8314) 8332Re^4: VTDOSでSORT.DEF(高橋版)  投稿者:10♯   2018/10/13(土) 18:44
    8329 番 konno さんへのコメント

あー、VZのマクロってローカル変数無いんでしたっけ。
だからスタックがあるのか…
      - No.8332 -    このTreeへ    コメント元:8329 へ [リストへもどる] soft

(8314) 8328Re^2: VTDOSでSORT.DEF(高橋版)  投稿者:konno   2018/10/13(土) 16:49
    8323 番 としき さんへのコメント    コメント数 2

> 1つめの&#Tは通るのですよね。
> ここで2つめの&#Tに、保存しておいた id の値を使っていると思うのですが
> スタックではなく別の変数に退避させておいたらどうなるでしょうか。

読めてないので、改造はまだ無理ですが、ヒントはもらえました。

> あと、あまり関係あるとは思いませんが、+512のバックアップオプションの
> 有無で挙動が変わったりとかします?

これはオプションだったのですか。
説明も読んでなかったもので。

	o32+64+512, ;(ec)?o|=2,		;options

ここの、o の数値を変更すれば動作が変わるんですね。

		; +512	Back Up

これを追っかければ何をしているかわかるかな。


      - No.8328 -    このTreeへ    コメント元:8323 へ [リストへもどる] pre

(8314) 8330Re^3: VTDOSでSORT.DEF(高橋版)  投稿者:としき   2018/10/13(土) 17:39
参照先:http://toshiki.la.coocan.jp/
    8328 番 konno さんへのコメント    コメント数 1

> 読めてないので、改造はまだ無理ですが、ヒントはもらえました。

確かに、読まないと、どの変数があいているかわかりませんね。
でも、いざとなったら、2文字の変数を使ってしまう、とか。

> 	(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
           ↓
> 	(u<0)?{&s dd=id,&#T(u) #C u-,&#T(dd) &d.}

こんな感じ、かな。

> 説明も読んでなかったもので。

大丈夫、私はこのマクロ、使った記憶すらない。
でも、メインマシンのVzディレクトリに解凍してあったんだよなぁ。
うん、PC-98のころは使ったことがあったかもしれない。

      - No.8330 -    このTreeへ    コメント元:8328 へ [リストへもどる] pre

(8314) 8333Re^4: VTDOSでSORT.DEF(高橋版)  投稿者:文太   2018/10/13(土) 19:25
    8330 番 としき さんへのコメント    コメント数 1

dd=id, &#T(-dd)
or
dd=-id, &#T(dd)
ではないかしら。

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

;#O "c:\1.txt" #m a=-id,	;存在すること
#O "c:\1.txt" #m a=id,		;存在すること
#O "c:\2.txt" #m		;同

&#T(-a)

*

      - No.8333 -    このTreeへ    コメント元:8330 へ [リストへもどる] pre

(8314) 8334ddは取りあえず避けたほうが  投稿者:文太   2018/10/13(土) 19:34
    8333 番 文太 さんへのコメント    コメント数 1

c:\wk\sort.def 131
03:	;--- sort ---
	ax..3=dd,

今、上から変数だけ書きだしてます。
あと5分くらいで終了の予定です。

      - No.8334 -    このTreeへ    コメント元:8333 へ [リストへもどる] pre

(8314) 8335aa, bb, cc がオススメ  投稿者:文太   2018/10/13(土) 19:47
    8334 番 文太 さんへのコメント


used vars: dfgiknoptuvx, dd, kk


      - No.8335 -    このTreeへ    コメント元:8334 へ [リストへもどる] soft

(8314) 8342SORT.DEF(高橋版)の問題はここ?  投稿者:konno   2018/10/15(月) 23:17
    8328 番 konno さんへのコメント    コメント数 1

SORT.DEF(高橋版)を色々な環境で試してみました。

・MSDOS Player
ソート実行時に固まった。
&t でステップ実行したら固まらずに終了した。
其の後は普通に動くようになった。何で?

・DOS窓VZ
普通に動いた。


ここからは、SCASB_MODE=0 のVTDOS環境です。

・VZS 榊原版VZ
常駐ではソート実行時に固まった。
非常駐では動いた。何で?

・その他のVZは皆駄目でした。
 なお、非常駐VZだと、エラーになってもVZが落ちるだけで
 VTDOSは動き続けますね。


・SORT.DEF(高橋版)のオプションを変更
;	o32+64+512, ;(ec)?o|=2,		;options
	o32+64, ;(ec)?o|=2,		;options

こう変更して、バックアップ無しとしたら
普通に動いてしまった。 あれぇ?

マクロの中に
:f	&Sc(dx=pq..149,pq) &Sy(dx) &Sc(bx,"sort.$$$$$$")

こういう行があるので、バックアップのファイル名で使用していると
思われるが、どうも何かがおかしい。
それで、その後にあるマシン語を逆汗したら

	sub_1		proc	near
4E		dec	si
4E		dec	si
8B 0C		mov	cx,[si]
4E		dec	si
2B F1		sub	si,cx
3B F7		cmp	si,di
74 07		je	loc_ret_5		; Jump if equal
56		push	si
51		push	cx
E8 FFF0		call	sub_1	         	; ★★ (014E)
59		pop	cx       
5A		pop	dx       
                                 
		loc_ret_5:	         	;  xref 7810:0157
C3		retn             
	sub_1		endp     


こういうサブルーチンがあるんですが、この中で

E8 FFF0		call	sub_1	         	; ★★ (014E)

この行、自分自身を呼び出していますよね。
これ、条件次第では無限ループになってしまうのではないでしょうか。

上記の実験で固まったときは、Ctrl+Breck も効かないので
ここで無限ループになってしまったのではないでしょうか。

もしかして、これを直せたら、SORT.DEF(高橋版)の問題は解決してしまうかも。

なお、動いたと言ってもソートが正常に出来ているかはわかりません。


      - No.8342 -    このTreeへ    コメント元:8328 へ [リストへもどる] pre

(8314) 8343Re: SORT.DEF(高橋版)の問題はここ?  投稿者:としき   2018/10/16(火) 00:19
参照先:http://toshiki.la.coocan.jp/
    8342 番 konno さんへのコメント    コメント数 2

> この行、自分自身を呼び出していますよね。

sortで自分自身の呼出しと言ったら、普通、再帰だと思います。
高橋さんなら、当然、quick sortを使っていそうだし。
あと、cxもdxもdiも変えずにsiだけを変えているように見えますから、
いつかどこかで止まるような気はします。

以上、勘だけでものを言ってみました。
      - No.8343 -    このTreeへ    コメント元:8342 へ [リストへもどる] soft

(8314) 8344Re^2: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/16(火) 00:48
    8343 番 としき さんへのコメント    コメント数 1

※一回編集しています

この部分のコードを見る限りは、ある内容のバイト列とそれの2バイトの長さから成る表を逆向きにスキャンしているようですね。
これは再帰呼び出しである必要は無いように見えますけど再帰呼び出しにしている理由が分りません。
あと、終了条件が後方スキャンしてるsiのdiに対する一致なので何を出力してるのか不明です。
スキャンしてる表に問題があれば固まるので、固まるか固まらないかだけのルーチンになってるように見えます。
率直に言うと意味が分らないので不可解なコードではあります。
クイックソートのようには見えないかな?

      - No.8344 -    このTreeへ    コメント元:8343 へ [リストへもどる] soft

(8314) 8346Re^3: SORT.DEF(高橋版)の問題はここ?  投稿者:konno   2018/10/16(火) 02:10
    8344 番 10♯ さんへのコメント    コメント数 1

10#さん、#8345 に書いたように、このサブルーチンは使われていないようです。
でも、もし使ったとしたら

56		push	si
51		push	cx
E8 FFF0		call	sub_1	         	; ★★ (014E)

ここで、プッシュ2回してループしているので、たとえ一回のループで抜けた
としても、プッシュポップの辻褄が合わなくてハングアップしてしまうような
気がします。

とりあえず、バックアップオプションを使わなければ動作するようですが
できれば不具合の原因を突き止めたいものですね。


      - No.8346 -    このTreeへ    コメント元:8344 へ [リストへもどる] pre

(8314) 8347Re^4: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/16(火) 03:07
    8346 番 konno さんへのコメント    コメント数 2

> 56		push	si
> 51		push	cx
> E8 FFF0		call	sub_1	         	; ★★ (014E)
> 
> ここで、プッシュ2回してループしているので、たとえ一回のループで抜けた
> としても、プッシュポップの辻褄が合わなくてハングアップしてしまうような
> 気がします。

最早どうでもいいようなミクロな話ですけど、push/popの数が一致してて
且つ、終了条件にヒットすればpopしたsi→dxの内容が使われることは無いので、
この手続きの中では問題にはなりませんね。

しかし、このマクロもマシン語コードもVZのワークを多々直接参照してるようなので、
コワいことやってるなーって素朴な印象です。
p*系の変数からオフセット足したアドレスを参照してたりとか…
マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか?
あと、pfにprをコピーしてたりとかしますね。
率直に言ってコワイ。

      - No.8347 -    このTreeへ    コメント元:8346 へ [リストへもどる] pre

(8314) 8349Re^5: SORT.DEF(高橋版)の問題はここ?  投稿者:文太   2018/10/16(火) 18:45
    8347 番 10♯ さんへのコメント    コメント数 1

*字句、修正しました

 まったく的はずれだったら、どうかお許しください。

 僕は、自分が逃げたとはいえ、Vzの脆弱性やvtdosの不具合が少しでもなくなって
くれることをひたすらに願っています。
 そして、10#さんは、やっぱりプロ、さすが、と驚嘆しています。背伸びをして申し
あげると、少し勉強になってもいます。

>マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか?
>あと、pfにprをコピーしてたりとかしますね。
>率直に言ってコワイ。

	pf[=pr,bl[=kp-k,#N #P #m  
	(r<0||wa..13+v<bl+v) bl],pf],?{ #C r+,>e}		;<v>僕、読んでませーん。
								;変数調べただけ m(__)m

 この件なのですが、間違っているかもしれませんが、内部ワークを「参照」するのは、ほぼ公認です。
 ちゃんと書き戻せば、いっときの書き換えもOK。
 バグさえなければ、コードセグメントだって、commnad.comの常駐部だって書き換えて「DOSを
騙す」(意味がちゃんと分かってません)ことも、Vzマクロはできます。

 pfにprをコピーはマクロ初心者でも、仕組みが分かればやります。
ps[=pa, nantoka syori  ps],
(バッファすり替え=検索バッファにゴミを残さない)は、この手のことの最初の一歩で(おそらく)、
ポインタの知識のある人なら、Vzマクロを始めて1週間としなくても、なるほど、と使う技です。
pf(#Nするので、ファイル名ヒストリーバッファに)にゴミを残さないためにpr(リネーム用ワーク)
とすり替えています。

 もしpfの内容を何がしかの理由で、prにコピーしたければ、histcopyで&Sh(pr,pf)(length注意)
で、c.mosさんがvz1.6で表に出してくれた関数で、できます。


@wa..13 @wb..13 @tmax 
テキスト構造体
dw  text buffer end ptr

 テキストバッファの終端を示すポインタですね。
 EMSにいることも(=異セグ)あるのではなかったでしたっけ?
 とにかく、wa..13は、テキストバッファを参照して、#Cをしていいか判断しているようです。
 ラインバッファなら異セグにいかないので、僕でもワークとして使います。bl(ラインバッファサイズ)、
これがこのマクロのワークだとドックにありますね。

 これを眺めてみてください。
http://mezala.la.coocan.jp/vz/notes/segmap.html

Text record(オープンファイルごとに。wa..XX) wa..13はここの欄

 上のサイトに「内部ワーク」(参照するだけなら僕もする)の地図があります。(先日は、害が
ないので、ファンクションキーラベルを書き換えました。驚いたことに、あの長大なツリーの基点。
見る意味はありません。)ここからテキストバッファでもテキストスタックでもファイラプールでも、
どこでもアクセスできます。普通マシン語を使うでしょうが、セグメントを一瞬変えれば、
. or .. (ポインタ演算子)でも、書き替えられます。

 危険な行為かもしれませんが、危険にならないようにプログラムするのが我々の仕事です。
 コワクはないですよ、きっと。

 SSの参照先は僕も気になりますが、スタックセグメントって、DOSから見ると、Vzのデータ
セグメントのことではなかったかと思うので、そこでポインタで示された内容(アドレス)の意味
が分かれば、たとえば前回のコード列内の(SS:[0640])も、どこだか、何を指しているのか、
分かりそうだと思っていました。Vzマクロから見れば、上の「内部ワーク」のことでしょう。
 (僕は、SS:[0640]に意味を見出してはいませんが。たとえ意味が分かっても何もできません)


see #08276
3C70:0107 368B3E4006     MOV    DI,SS:[0640]

 とにかく、sort.def, 逆アセコード内のSSは、vzの挙動を把握しているkonnoさんが調べれば
分かるのか分からないのか、というところなのでしょう。

-------------------------------------------------------------------------------------------

 最後に無知な文太が一言:
 Vzの世界では、「ローテクはハイテク」という言い回しで表現されてきました。
 コマンド・関数・変数としてc.mosさんが表に出してくれたものを、短く賢く使って、マクロを書くのが正道
という意味なのでしょう。と同時に、ローテクは後ろでVz自体が、(いわゆる)ハイテク・Vzコードが、
ガサッガサッと動いて仕事をしてくれていることを意味するので、マシン語が偉いってわけじゃないよ、
という意味だとも僕は解しています。

 上のコードをみて、#N #P #m  #C(ローテク技)をしているとき、色々やって調べてる(調整してる)な、
と思ったものですから。
 だから、すいません、マシン語マクロばかりがコワイわけではありません。普通のマクロもvtdosを
落とせる、と僕は思っています。
 ブロックをコピーしただけで、テキストスタック(EMS上のあること多し)がガサっと動いて、EMS
の窓がこれまた動くのだと思いますので。このとき、マクロバッファもファイラプールも窓移動で、
ガサッガサッと。
 分かってない奴の、分かったような、分かんないような、抽象論でした。m(__)m


 背伸びはせず、格好つけず、知ったかぶりせず、書いたつもりです。それでも、間違いが含まれている
可能性は、すいません、僕のばあい、いつも、あります。m(__)m

 有益なことが言えるとも思えませんので、レス不要ですよ。


      - No.8349 -    このTreeへ    コメント元:8347 へ [リストへもどる] pre

(8314) 8350Re^6: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/16(火) 19:11
    8349 番 文太 さんへのコメント    コメント数 2

c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
僕のvzでは例えばpcは0111hになってたりとかします。
こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか?

※追記
あと、VTDOSにはEMSを禁止するオプションもあります。
これはVZにもありますが、問題切り分けには使えます。
      - No.8350 -    このTreeへ    コメント元:8349 へ [リストへもどる] soft

(8314) 8351Re^7: SORT.DEF(高橋版)の問題はここ?  投稿者:文太   2018/10/16(火) 20:53
    8350 番 10♯ さんへのコメント    コメント数 1

 ありがとうございます。

>c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
>僕のvzでは例えばpcは0111hになってたりとかします。
>こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
>マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか?

 よりによって、僕がこれに何かコメントを返すのは、躊躇われますが、大間違いなこと
を書けば、さすがに、konnoさんが、やんわり修正してくれるでしょう。
 はい、「改版の時点で厳密な管理」はされてきたと思います。前に書いた、Vzの伝統
です。めざらさんのセグマップで「絶対アドレス」と書かれてますよね。pcが0111hなのは、
10#さんのところでも僕のところでも、同じはずです。
 コードは(残りのぶんだけ)太っていい。でもデータは動かすな、なのかな?

 sort.defなどのマクロに関していえば、マクロ語のなかで、ax=pc,のようにすれば、
マシン語ルーチンでもなんら問題ないはずですよね、マシン語で、mov ax,0111とかは
あんまりしないではないのでしょうか。してないのではないでしょうか。この辺は、
分かりません。上のように「厳密な管理がなされている」という前提なら、問題ではない
のだろうとも考えますが。

 これが厳格に守られてきたのが「伝統」なのだろうと僕は思っています。
 たぶん、間違ってない歴史的エピソード。Win95のころ、Win対応として、ちゅーぱっち
というのが出ました。VzがWin環境で動くようになった(詳細は不明。テンポラリーファイル
の管理、かな?)。しかし、上のdseg内のアドレスへの配慮はなかった。既存マクロが動かない
という大きな問題がniftyで指摘されたようなことはなかったと思いますが、niftyのfgaldcには、
そこの空気があったのです、おそらく。「これでは、既存マクロが動かないよ」、とたぶん、
高橋さんは言った。それで、高橋版ドックの冒頭が、こうなっているのだと思います。(注)

 「マクロを作るならば、マクロをよく知っている人の作った Vz がいい」
http://mezala.la.coocan.jp/vz/env/win/win98.html#vzt03k2

 高橋版の前の榊原版も、ここは守った。Vzが1.5から1.6になったとき、c.mosさんが、
コードセグメントとデータセブメントの分離という大きな変更をしたにもかかわらず、
1.5マクロが1.6Vzで大混乱しないような配慮をした。これを、踏襲してのことだったと、
僕は理解しています。
 おかげで、セグメント変数って、わ、分からない、、、。

 前に、konno版に関して、konnoさんの「保守性」(安全第一主義)に関して、「アドレスが
1バイトずれただけで」と書きました。これのことを言っていたつもりです。僕の理解では、、、。



>あと、VTDOSにはEMSを禁止するオプションもあります。
>これはVZにもありますが、問題切り分けには使えます。
 「問題の切り分け」ですね。うん、うん、ちょっと分かるぞ、これ。サンクスです。m(__)m
 問題は、EMSのないVzを僕がうまく使えないことなんですが、これは僕の問題。ファイラ
などのワークというかバッファをどこまで縮めれば(制限を受け入れれば)、テストができるの
かさえ、うううう。ま、ゆっくりやります。
 お教え、ありがとうございます。


(注)ちゅーぱっちをどれくらいの人が使ったのかは分かりません。特定のマクロ、あるいは
もっと広く、ワークを参照するマクロを使わない人には害はなかったはずで、マクロ師、マクロイド、
マニアックなマクロ・ユーザ以外には、ありがたかったのではないかと思います。


      - No.8351 -    このTreeへ    コメント元:8350 へ [リストへもどる] soft

(8314) 8352Re^8: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/16(火) 21:14
    8351 番 文太 さんへのコメント    コメント数 2

僕はワークやバッファ類をどこに置くとかは全く把握してないのであれなんですけど、
なんならXMSを使えば大容量ファイルの置き場にはなったと思います。
(確かEMSに比べて制限は大きかった)
このあたりの、XMSを導入してむにゃむにゃしてる頃に、僕の環境は
EXTTPAのSW1になったようです。
僕文太さんに言われるまでcyupatch使ってましたよ。

絶対アドレスは絶対安全か?
それを盲目的に信じる前提はあるのかも知れませんが、
sort.defは絶対安全という前提があるが故にこれを読まなくて良いかというと、
読まないと切り分けは出来ませんですな。
マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは?

      - No.8352 -    このTreeへ    コメント元:8351 へ [リストへもどる] soft

(8314) 8355Re^9: SORT.DEF(高橋版)の問題はここ?  投稿者:文太   2018/10/16(火) 23:14
    8352 番 10♯ さんへのコメント

 うーん、まったく話がどこへ向かっているのか分かりません。
 が、分かる範囲で、回答させていただきますね。

>僕文太さんに言われるまでcyupatch使ってましたよ。
 すいません、vtdosの作者が、マクロを使われないとは想像していませんでした。
 それでも、マクロを積極的に使わなくても、製品版vz.defが標準だと思いますので、多くの
バグが取られているはずの高橋版の流れをくむkonno版が良いと思います。
 (余計なことですが、Vzマクロって、マシン語コードを含む含まない以前に、Vzの
一部だと思っています。^KDとか。当たり前すぎますかね。)

>sort.defは絶対安全という前提があるが故にこれを読まなくて良いかというと、
>読まないと切り分けは出来ませんですな。
 ここは、まったく分かりません。
 僕は、sort.defのユーザではないです。c:\wk\sort.defとどっかで書いたと思いますが、
konnoさんに請われて、DLしました。また絶対安全なマクロだとも思っていません。ただ、
すでにvtdos環境での、Vzの脆弱性を露呈させているのだと、思っています。

 それでも、僕が僕の環境で解決できなかった問題は、これとは別だろうと想像しています。
で、撤退しかなかった、という経緯ですが、これ、関係ありませんよね?

 この手のことは、多少遅くても、僕は個人的にpsort.exe, sortf.exe, ssort.exeに担当して
もらっています。パラグラフ・ソートは、まだ3回ぐらいしか使ったことがないのですが。

 ただ、konnoさんの狙いは、高橋版sort.defを機能するようにする、ということではないの
だろうと想像していました。Vzの弱いところを建て直す、これが狙い、そう思っていました。

>マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは?
 もうどっちも絶滅危惧種ではないのかと思います。
 ぼくは、誰にも頼らずにVzできると思ってます。仕事の道具なものですから、そうでない
と、それこそやばい、ということになります。そのためのWinMEなんです。

 それでも、こんなのプログラミングの論理世界とはなんの関係もないのかもしれませんが、
僕には、おそらく、めざらさん、konnoさん、としきさんが、友人として必要、なん、だろう、と、
思います。あはははは。嘘かほんとか。

 もし僕の勧めで、10#さんがcyupatachから高橋版(konno版)に移られたことが問題だったの
だとしたら、すいませんでした。今からでも、戻れば宜しいのではないでしょうか。そんな風に
思いました。

 意思疎通、できてないですよね、ここ、きっと。

 すいませんが、話の展開の方向がまったく見えておりません。

 僕は何も茶化していないし、不真面目でもないつもりなのですが。たんにスキルレベルが2018年の
Vzerとしては低すぎる、ということかと。しかし、これは、僕の人格の一部なので、した選択の
結果なので、本人も諦めております。ご迷惑をお掛けしております。m(__)m


      - No.8355 -    このTreeへ    コメント元:8352 へ [リストへもどる] soft

(8314) 8356Re^9: SORT.DEF(高橋版)の問題はここ?  投稿者:文太   2018/10/16(火) 23:32
    8352 番 10♯ さんへのコメント    コメント数 1

 しつこくて申し訳ありません。これは、僕の独り言です。
 コミュニケーションって難しいですね。

 全体に、10#さんの独り言だな、と思いました。ですから、この前の僕の投稿みたいに
色々書くことはなかったのだろうと。

>マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは?
 きっとここだけでしょう。
 僕個人に関していえば、あるいはsort.def(高橋版)に関していえば、純粋なユーザは
いないように思っております。

 レス不要ですよ。

      - No.8356 -    このTreeへ    コメント元:8352 へ [リストへもどる] soft

(8314) 8358Re^10: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/17(水) 00:16
    8356 番 文太 さんへのコメント

まあ最早誰もマクロ師を必要とはしていないでしょう。
僕はこのマクロを読むことが出来ないので、マクロ師がいればな、とは思います。

      - No.8358 -    このTreeへ    コメント元:8356 へ [リストへもどる] soft

(8314) 8360Re^7: SORT.DEF(高橋版)の問題はここ?  投稿者:konno   2018/10/17(水) 01:40
    8350 番 10♯ さんへのコメント    コメント数 2

> c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
> 僕のvzでは例えばpcは0111hになってたりとかします。

う、VZK だと1バイトずれていますね。何故だかわからないです。
VZEXもここは同じようにずれていますが、他のワークもずれているようで
動かないマクロがあるようです。

> こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
> マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか?

相対アドレスで参照するものは大丈夫ですが、私が私家版で使っていた版は
vp がずれてしまっていて、カレンダーマクロで誤動作して気が付いた次第です。

マシン語が直接参照するdsegのアドレスは、絶対アドレスなので、ポインタが
ずれたら即誤動作するので致命的な問題になります。

SORT.DEF もマシン語が直接参照しているようですね。ちょっと読めてないですが
どこかで壊れて、マクロのポップがトリガーになって落ちているように見えますね。
ポップで、sp のポインタが2ずれるんですが、どうもおかしい気がします。

> あと、VTDOSにはEMSを禁止するオプションもあります。
> これはVZにもありますが、問題切り分けには使えます。

ありがとうございます。必要に応じて使わせてもらいます。


      - No.8360 -    このTreeへ    コメント元:8350 へ [リストへもどる] soft

(8314) 8361Re^8: SORT.DEF(高橋版)の問題はここ?  投稿者:文太   2018/10/17(水) 08:29
    8360 番 konno さんへのコメント    コメント数 3

「めざら資源」セグマップ
スタックセグメント概略
絶対アドレス	相対アドレス	データ内容
0000		wseg
0110		pc

10#さんwrote:
> c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
> 僕のvzでは例えばpcは0111hになってたりとかします。

文太wrote:
>めざらさんのセグマップで「絶対アドレス」と書かれてますよね。pcが0111hなのは、
>10#さんのところでも僕のところでも、同じはずです。
 0110hと0111hの差について語られていたとは、気づいておりませんでした。
 konno版もc.mosオリジナルと同じです、と信じていて、そう伝えたつもりでおりました。
ここで、僕は、完全に間違えていました。m(__)m

konnoさんwrote:
>う、VZK だと1バイトずれていますね。何故だかわからないです。


 そ、そういうことか、、、。これで話が【少し】ずれたんだ、、、。

 手元には、7個くらいpcを使うマクロがありました。

c:\def\filter2.def      400:        &Sm(m,pc+292,46)	;push all double user vars
c:\def\popn.def      161::M	pc[=c,pd[=d,pg[=g,pn[=m,pq[=q,pu[=u,pv[=v,px[=h,pz[=e,pw[=w,pr=pa,
c:\def\sheriff.def      113:	&So(pm,"$$pc") (r)? p=pc, ? p=pm,
c:\def\sonota.def     1071:        &Sm(pq..149,pc+292,46)          ;push all double user vars
c:\def\stkhelp.def     1182:    } ?bx=pc,
c:\def\stkmenut.def       32:	(ks&1)??{ &b(5) >04 }			;pc..57 = ks
c:\def\tkdate.def       12:    &11 &Sc(pc,ps)          ;;  pc="1994年12月31日",

 もっとも別にこれに大きな問題はありませんよね、pcをpcとして使っている限り。
 マシン語の中で、直値としてみたら、いろいろやばいだろうな、とは思いますが。

 意見も何もありません。
 が、戻るなら戻ったほうが気持ちもいいし、「めざら資源」とも整合するのですが。(^^;
 過去の無用なくび木なのでしょうか? メリットは? (^^;
 sort.defのことは僕には実害がありません。が、こっちは、ちょっと、、、。実害は、今は、ない
はずですが、、、。作家の考え方次第なのでしょう。
 できたら、.docに入れて欲しいとは思います。

      - No.8361 -    このTreeへ    コメント元:8360 へ [リストへもどる] pre

(8314) 8363Re^9: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/17(水) 10:02
    8361 番 文太 さんへのコメント    コメント数 1

本来0110hから始まるpcが0111hにずれてる事に対して、
本来0120hから始まるワークはずれていませんね。
これはpc相対で16バイト目以降に問題があると思われます。
上のgrepではfilter2とsonotaが該当するようですが。

      - No.8363 -    このTreeへ    コメント元:8361 へ [リストへもどる] soft

(8314) 8364Re^10: SORT.DEF(高橋版)の問題はここ?  投稿者:文太   2018/10/17(水) 14:23
    8363 番 10♯ さんへのコメント    コメント数 1

 10#さん、本当にありがとうございます。m(__)m m(__)m
 顔面蒼白、これ以上になく僕の顔は今、まっ白でしょう。
 頭の中に色はつかないけど、まっ白だと感じています。
 冗談をいえば、脳梗塞で脳が死んだ人のように、まっ黒なのかもしれません。
 熊に出会ってしまった人のように、髪の毛は、逆立ってます。

 いい歳した大人が、この程度のことで人生がひっくり返ったみたいに、
動揺しても始まらないので、ちょっと落ち着いて考えます。
 現実的にはそういう訳にもいかないのですが、旅に出たほうがいいな、
と感じています。

 とはいえ、vtdosとは本質的に関係がありません。
 もっと大きいのかもしれない。
 いや、大したことではないはず、です。

      - No.8364 -    このTreeへ    コメント元:8363 へ [リストへもどる] soft

(8314) 8365Re^11: SORT.DEF(高橋版)の問題はここ?  投稿者:文太   2018/10/17(水) 16:24
    8364 番 文太 さんへのコメント    コメント数 1

 いちいち顔面蒼白とかしないように。いちいち逆毛とか立てないように。
 けっこう立ち直り、はやかった。
 たしかに、「pc+xx」はやばいようですね。

Ygrep -w "pc" c:\def
c:\def\chgenv.def      200:;	&Sm(pc+60,cp+2,20) &Sm(pc+174,cp+22,176)
c:\def\lxclnd.def      107:	&Sm(pc+292,pq..149,46)		;pop all double user vars
				;こっちはイディオムですからねぇ。これは書き戻しの場面でしょうね。

 もう一般ユーザが存在しない(konnoさんにとってはいるのかな)ご時勢ですし、、、。
 誰も気がつかないんですよね、、、。

konno, 
0110h: 00 56 5A 00 00 00 00 00-00 00 25 00 00 00 00 00  ・VZ・・・・・・・%・・・・・ 
0120h: 00 00 00 00 00 00 40 00-00 80 00 01 00 10 50 00  ・・・・・・@・・・・・・・P・ 

takahasi,
0110h: 56 5A 54 00 00 00 00 00-00 25 00 00 00 00 00 00  VZT・・・・・・%・・・・・・ 
0120h: 00 00 00 00 00 00 40 00-00 80 00 01 00 10 50 00  ・・・・・・@・・・・・・・P・ 

 しばらく高橋版にします。マシンの台数が多いので、入れ替えが終わるのがいつに
なるのか分かりませんが。この大混乱は、もっとも苦手とするところなのです。
 このマシンは入れ替えた、って、一覧表をつくるの、、、。
 それでも、紆余曲折ありながらも、前進ですよ。

 10#さん、ありがとうございました。

      - No.8365 -    このTreeへ    コメント元:8364 へ [リストへもどる] pre

(8314) 8366基点ポインタ(?)の絶対アドレス  投稿者:文太   2018/10/17(水) 17:20
    8365 番 文太 さんへのコメント

  他は問題ないようです。これぐらいはできるな、と。

		konno
0000	wseg
0110	pc	0111h *
028E	pq	028Eh
	dseg
03EC	pn	03ECh
0442	fg	0442h
04D2	mg	04D2h
05B9	pv	05B9h
062A	vp	062Ah


      - No.8366 -    このTreeへ    コメント元:8365 へ [リストへもどる] pre

(8314) 8367Re^9: SORT.DEF(高橋版)の問題はここ?  投稿者:konno   2018/10/17(水) 18:49
    8361 番 文太 さんへのコメント    コメント数 1

>  手元には、7個くらいpcを使うマクロがありました。
> 
> c:\def\filter2.def      400:        &Sm(m,pc+292,46)	;push all double user vars
> c:\def\popn.def      161::M	pc[=c,pd[=d,pg[=g,pn[=m,pq[=q,pu[=u,pv[=v,px[=h,pz[=e,pw[=w,pr=pa,
> c:\def\sheriff.def      113:	&So(pm,"$$pc") (r)? p=pc, ? p=pm,
> c:\def\sonota.def     1071:        &Sm(pq..149,pc+292,46)          ;push all double user vars
> c:\def\stkhelp.def     1182:    } ?bx=pc,
> c:\def\stkmenut.def       32:	(ks&1)??{ &b(5) >04 }			;pc..57 = ks
> c:\def\tkdate.def       12:    &11 &Sc(pc,ps)          ;;  pc="1994年12月31日",

う、結構あるもんですね。
早急に対処したいと思います。ご迷惑おかけしました。


      - No.8367 -    このTreeへ    コメント元:8361 へ [リストへもどる] pre

(8314) 8370Re^10: pc ズレ、やばいかも  投稿者:konno   2018/10/17(水) 20:37
    8367 番 konno さんへのコメント

> う、結構あるもんですね。
> 早急に対処したいと思います。ご迷惑おかけしました。

コード領域の内部ワーク pc の1バイトずれで、値を比較してみました。

	VZo	VZk修正	VZk旧
pc	110h	110h	111h
pc+292	234h	234h	235h
pc..57	0	0	B900h

修正版は問題ないようですが、旧版は、変な値になっていますね。

> > c:\def\filter2.def      400:        &Sm(m,pc+292,46)	;push all double user vars
pc+292 は、ここですかね。
246	sysvar		dw	VARCNT dup(0)	; A,B,C ... system variables

> > c:\def\stkmenut.def       32:	(ks&1)??{ &b(5) >04 }			;pc..57 = ks
pc..57 は、これですね。
114	sftkey		dw	0		; ks key shift status

うう、結構やばいかも。


      - No.8370 -    このTreeへ    コメント元:8367 へ [リストへもどる] pre

(8314) 8372Re^9: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/18(木) 06:04
    8361 番 文太 さんへのコメント    コメント数 1

余談ですけど、近頃僕は「信じる」という行為は控えるようにしてます。
これは、思い込みに繋がり、そこから仮に「正義」などに繋がれば、
酷い結果になる原因にもなります。
歴史からの教訓ですかね。
      - No.8372 -    このTreeへ    コメント元:8361 へ [リストへもどる] soft

(8314) 8373Vz文化  投稿者:文太   2018/10/18(木) 13:15
    8372 番 10♯ さんへのコメント    コメント数 1

 人生にはみっつの坂がある。のぼりざか。くだりざか。まさか。


 口承文化と活字文化の落差を、またしても感じさせてくれました。
 活字は先読みできる。口承では完全に話者のペースになれる。それで、
うまくやると洗脳できる。
 理解したからといって、実践できるわけでもないですが。


 信念をもたないのが僕の信念だ。「外」はないようですね。


 Vz文化にはこんな言い伝えもあります。
 「ニーモニックが読めるからといってc.mosさんのソースを読めるわけでは
ないのと同様、Vzマクロのシンボルその他を暗記したからって、m.gannさん
のマクロが読めるわけではない」
 高橋さんのマクロでは、(きっと)プロのプログラマ的に正統だろうと思いますが、
それでも、m.gannさんが目標だったのも(きっと)あって、Vzの癖をとことん
知り尽くした上でのプログラミング・スタイルなのでしょう。
 Vzの「内部ワーク」の利用は当然ですが。
 知ったかぶりではなく想像です。

 sort.defでは、「癖」でも「裏技」でもないでしょうが、テクニックが駆使
されているようです。かなりのスキルレベルで、読解の行為に深いコミットメント
のあるマクロ師でなければ、読めないか、読もうとしないか、かと思いました。
 僕レベルだと、おお、とほんの一部分で、テクニックを学ばせてもらえる程度
でした。sort.exeではいけませんか? と思うような奴には無理ですね。
 (いつかME環境で使ってみようとは思っていますが。フィールドでなくカラム
でソートは、、、。sortfはオプション指定がいつも難しくて、、、。)

 「内部ワーク」。めざらさんがあのように素晴らしく纏めてくださってますが、
あれが明らかになるのに、10年くらいに及ぶ、多くのVzerたちの苦闘が
ありました。文字どおりの血と汗と涙の結晶。
 最終的に発表したのは高橋さん。でも、高橋版Vzも「セグマップ」も、
高橋さんがきっと50人くらいのマクロ師、マクロイド、マニアック・ユーザに囲まれ
ていて、その価値を理解してくれる人たちがいたからこそ、生まれたのだろうと思います。
 あんなこと、誰も、一人ではやれないと思う。
 めざら資源で、一人であれを纏め直した、めざらさん。僕はあの作品に感動します。


      - No.8373 -    このTreeへ    コメント元:8372 へ [リストへもどる] soft

(8314) 8374Re: Vz文化  投稿者:10♯   2018/10/18(木) 14:42
    8373 番 文太 さんへのコメント

ネットワークの世界に「口承文化」ってないですよねw
      - No.8374 -    このTreeへ    コメント元:8373 へ [リストへもどる] soft

(8314) 8362Re^8: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/17(水) 09:46
    8360 番 konno さんへのコメント    コメント数 1

>         org 100h
> entry:      jmps    entry1          ; -16
> vzversion:  db  "VZ1.60t ",0,EOF    ; -14       ;##k07
> entry1:     jmp init            ; -5
>         dw  0           ; -2

オリジナルは entry1 の jmp init がショートジャンプのようですが、
kVZではニアジャンプになってますね。
sort.defはpc相対を使っていないのでこれはシロだと思いますけど。

      - No.8362 -    このTreeへ    コメント元:8360 へ [リストへもどる] pre

(8314) 8368VZk の pc ズレ問題  投稿者:konno   2018/10/17(水) 19:10
    8362 番 10♯ さんへのコメント

> >         org 100h
> > entry:      jmps    entry1          ; -16
> > vzversion:  db  "VZ1.60t ",0,EOF    ; -14       ;##k07
> > entry1:     jmp init            ; -5
> >         dw  0           ; -2
> 
> オリジナルは entry1 の jmp init がショートジャンプのようですが、
> kVZではニアジャンプになってますね。
> sort.defはpc相対を使っていないのでこれはシロだと思いますけど。


そうか、すっかり忘れていましたが、これで思い出しました。

		org	100h
entry:		jmps	entry1
;vzversion:	db	"VZ1.60t ",0,EOF	;##k07
vzversion:	db	"VZ1.60t",0,EOF		;##k07t1-2 pc=110h
entry1:		jmp	init

こう修正して、pc が一致しました。ここの長さを変えたら駄目だったんですね。
VZEX もこうなっていて、以前、ダニー版ベースの VZk8 を弄っている時に
一度これをやってしまって、直したんですが、その後 VZk7 に戻った時に
ここを修正するのを忘れていたようです。

取りあえず、公開しているものは、修正版をアップします。


      - No.8368 -    このTreeへ    コメント元:8362 へ [リストへもどる] pre

(8314) 8353Re^5: SORT.DEF(高橋版)の問題はここ?  投稿者:konno   2018/10/16(火) 22:22
    8347 番 10♯ さんへのコメント    コメント数 1

> マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか?

私もよくわかっていないのですが、MAC16.DOC には

■ セグメントの変更
-----------------------------
 コードセグメントとデータセグメントを分離したため、マクロでアクセスするワークエリアは、全てスタックセグメントに移動しました。このため、

	dz=gz, p=wa+$92, .. dz=cz,

のように、セグメントを変更する必要はありません。
 また、このように「dz=cz,」でセグメントを復帰しているマクロとの互換性を考慮して、「cz,dz.gz」はすべてスタックセグメントを指しています。真のコードセグメントの値は、セグメント変数「vz」が示します。


こうあるので、VZのコードはCSEGで、その他はほとんど、SSEG なのだと思います。
今の私の環境では、SORT.DEF のエラーで

2018-10-16 11:38:29 VZIBMJ(17EA) 17EA:14A1 'REPNE SCASB 命令ラップアラウンド'

AX=000A BX=CCDA CX=FFF7 DX=0100 SI=0001 DI=0001 BP=CCDA DS=3E51 ES=3E51 FLAGS=0646

CS:IP=17EA:14A1
17EA:1491 C3 FC 51 57 06 1E 07 8B FE B9 FF FF B0 0A F2 AE 
17EA:14A1 8B F7 07 5F 59 C3 B2 00 EB 1F E8 F9 FF 73 03 FF 
 0000:1492       ENDLIN

SS:SP=274A:CACE
274A:CABE 46 02 4A 27 80 16 EE CB DE 00 FF FF 89 D2 51 3E 
274A:CACE 4A 27 9A 7B 7E 1F 8E 14 3D 19 02 00 26 19 ED 16 


mg 274a:04d2	マクロエリア
mg 274a:11cf	vz.def
mg 274a:6252	sort.def
pu 274a:b0f2		マクロ配列エリア
sp 274a:b1f0	マクロスタック

51F7:06E3	テキストスタック


数値は多少違うものがあるかもですが、マクロのワークは全て SS のセグメント
だと思います。
マクロ内のマシン語も当然そのマクロのアドレスにあるので、その中で動きます。

このマクロでは常に endlin  でエラーになっているようですが
ソースでは、

------------------ CORE.ASM
CORE.ASM 258:	public	toplin,endlin,prelin
CORE.ASM 269:;	call	endlin
CORE.ASM 277:endlin	proc
CORE.ASM 270:	call	endlin
CORE.ASM 289:endlin	endp
CORE.ASM 1149:	call	endlin
------------------ MEMO.ASM
MEMO.ASM 48:	extrn	endlin		:near
MEMO.ASM 558:	call	endlin
------------------ TEXT.ASM
TEXT.ASM 75:	extrn	endlin		:near
TEXT.ASM 1033:		call	endlin
TEXT.ASM 1635:	call	endlin
TEXT.ASM 2053:	call	endlin
TEXT.ASM 2079:	call	endlin
------------------ VIEW.ASM
VIEW.ASM 27:	extrn	endlin		:near
VIEW.ASM 808:	call	endlin
VIEW.ASM 956:	call	endlin

でも、マクロのトレースでは、常に

:z	ek],&06 &d

この終了処理の、ek], のポッブ実行直後にVTDOSがエラー表示します。


wa..13 は、VZ.INC の中ですが、DSEG.MAP がわかりやすいですね。

;--- Text record ---		;wa,wb,wo,wm,wf
26	tmax		dw	?	; text buffer end ptr

これかな。


      - No.8353 -    このTreeへ    コメント元:8347 へ [リストへもどる] pre

(8314) 8359Re^6: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/17(水) 00:21
    8353 番 konno さんへのコメント

なるほど。
僕もちょっと見てみた限りではそれらワークのアドレスに問題が無さそうだってことは理解出来ました。
あと、バックアップ部分のマシン語の挙動も大体は把握出来ました。
となると、バックアップのマクロのどこかにトリガーがあるということまでは推測できますね。
      - No.8359 -    このTreeへ    コメント元:8353 へ [リストへもどる] soft

(8314) 8345Re^2: SORT.DEF(高橋版)の問題はここ?  投稿者:konno   2018/10/16(火) 01:19
    8343 番 としき さんへのコメント    コメント数 1

> sortで自分自身の呼出しと言ったら、普通、再帰だと思います。
> 高橋さんなら、当然、quick sortを使っていそうだし。

ソートルーチンならそうでしょうが、これはバックアップのルーチンなんですよ。
バックアップのルーチンには2か所マシン語ルーチンがあり、これは後半のものです。
省略したサブルーチンの上の部分をアップします。マシン語では一繋がりです。

0100		start:
0100  8B 36 01AC	mov	si,ds:data_2e	; (7810:01AC=0)
0104  8E 1E 01AA	mov	ds,ds:data_1e	; (7810:01AA=0)
0108  33 ED		xor	bp,bp		; Zero register
010A  32 C0		xor	al,al		; Zero register
010C		loc_1:				;  xref 7810:0119
010C  4E		dec	si
010D  4E		dec	si
010E  8B 0C		mov	cx,[si]
0110  03 E9		add	bp,cx
0112  4E		dec	si
0113  88 04		mov	[si],al
0115  2B F1		sub	si,cx
0117  3B F2		cmp	si,dx
0119  75 F1		jne	loc_1		; Jump if not equal
011B		loc_2:				;  xref 7810:0138
011B  8B D6		mov	dx,si
011D		loc_3:				;  xref 7810:0120
011D  AC		lodsb			; String [si] to al
011E  0A C0		or	al,al		; Zero ?
0120  75 FB		jnz	loc_3		; Jump if not zero
0122  C6 44 FF 01	mov	byte ptr [si-1],1
0126  8B CE		mov	cx,si
0128  49		dec	cx
0129  2B CA		sub	cx,dx
012B  B4 40		mov	ah,40h		; '@'
012D  CD 21		int	21h		; DOS Services  ah=function 40h
						;  write file cx=bytes, to ds:dx
012F  72 1C		jc	loc_ret_4	; Jump if carry Set
0131  46		inc	si
0132  46		inc	si
0133  36: 3B 36 01AC	cmp	si,ss:data_2e	; (7810:01AC=0)
0138  75 E1		jne	loc_2		; Jump if not equal
013A  16		push	ss
013B  1F		pop	ds
013C  55		push	bp
013D  B4 01		mov	ah,1
013F  50		push	ax
0140  8B D4		mov	dx,sp
0142  42		inc	dx
0143  33 C9		xor	cx,cx		; Zero register
0145  B1 03		mov	cl,3
0147  B4 40		mov	ah,40h		; '@'
0149  CD 21		int	21h		; DOS Services  ah=function 40h
						;  write file cx=bytes, to ds:dx
014B  58		pop	ax
014C  58		pop	ax
014D		loc_ret_4:			;  xref 7810:012F
014D  C3		retn

バックアップファイルの書き込みルーチンのようですが、くだんの
サブルーチンへは飛んでいませんね。 あれぇ???

もしかしてあのサブルーチンはデコイか盲腸か?
バルタン星人はトラップ大統領だった・・・


> あと、cxもdxもdiも変えずにsiだけを変えているように見えますから、
> いつかどこかで止まるような気はします。

なるほど、止まるまでに64K回ループしてしまうんですね。(違うと思う)


      - No.8345 -    このTreeへ    コメント元:8343 へ [リストへもどる] pre

(8314) 8348Re^3: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/16(火) 09:33
    8345 番 konno さんへのコメント    コメント数 1

<1行目の内容><01h>
<2行目の内容><01h>
...
<最終行の内容><01h>
<各行の合計バイトサイズ>

      - No.8348 -    このTreeへ    コメント元:8345 へ [リストへもどる] soft

(8314) 8354Re^4: SORT.DEF(高橋版)の問題はここ?  投稿者:konno   2018/10/16(火) 23:13
    8348 番 10♯ さんへのコメント    コメント数 1

> <1行目の内容><01h>
> <2行目の内容><01h>
> ...
> <最終行の内容><01h>
> <各行の合計バイトサイズ>

すみません、わからないです。
debug のデータですか?

      - No.8354 -    このTreeへ    コメント元:8348 へ [リストへもどる] soft

(8314) 8357Re^5: SORT.DEF(高橋版)の問題はここ?  投稿者:10♯   2018/10/16(火) 23:43
    8354 番 konno さんへのコメント

> すみません、わからないです。
> debug のデータですか?

バックアップの二番目のマシン語の部分のファイル出力がこの形式で出力してるようです、
という覚え書きです。


      - No.8357 -    このTreeへ    コメント元:8354 へ [リストへもどる] soft

(8314) 8410VTDOSでSORT.DEF(高橋版)の bl が変?  投稿者:konno   2018/10/22(月) 00:27
    8314 番 konno さんへのコメント    コメント数 1

ツリーが伸びすぎたので、ここにコメントしますが

VTDOSでSORT.DEF(高橋版)の、ラインバッファが変?

04:	; back up
&t	(o&512)??. (u)?.
	(wf..0)??>f
	i=id,pf[=pr,
	&m("%d %d %d",bl,kp,k)		;★ bl=8192   kp=-7072 k=-25387
	bl[=kp-k,
	&m("%d %d %d",bl,kp,k)		;★ bl=18315  kp=-7072 k=-25387
	#N #P #m (r<0||wa..13+v<bl+v) bl],pf],?{

このように、bl を表示させてみると、コメントに書いたように
 bl=18315 に拡大していますが、bl の最大は確か 8192 バイトだったかと。

この数字だと、バッファが溢れて暴走しませんか?
ソート対象データは、DSEG.MAP です。

      - No.8410 -    このTreeへ    コメント元:8314 へ [リストへもどる] pre

(8314) 8411Re: VTDOSでSORT.DEF(高橋版)の bl が変?  投稿者:10♯   2018/10/22(月) 06:01
    8410 番 konno さんへのコメント

k=09cd5h ;blk top
kp=0e460h

マクロ中で kpに対する繰作は無いのでマシン語中でこれに対して
繰作してるのでしょう。

kp-k=478bh=18315

この部分を見る限りは問題無いですね。

      - No.8411 -    このTreeへ    コメント元:8410 へ [リストへもどる] soft