すいません、とりあえずの最初の一歩の問題への解答は以下のとおり。

BASM converts a BASIC-like language to 80286 Assembly Language Source Code   
which easily compiles using such widely available public domain tools as the 
Arrowsoft Assembler and the Freelink linker. 

Basic-like language（BASM言語＝一般に出回ったBasicの弱力化版だろう）を
Asm Source Codeにコンバート。

BASM is a powerful 80286 assembly code generator.  Use it to create stand
alone programs using your assembler and linker. Or use the code to help
optimize routines in your favorite high level programming language.

"80286 assembly code generator"

　なぜ、アセンブルしてしまわないのか？　そこまで持っていかないのか？
　optimizeできるから、なのでしょうかね？　あるいは、高級言語のインライン・アセンブラ
の部分をBasicで書けるよ、なのかな。

　コンパイルとアセンブルの違い（と僕が思っていたこと）。
　.asmにしてアセンブルすると、.basをコンパイルするより、〈一般に〉速いものが
できあがる。
　しかし、これは「最適化」できるかによりけりで、〈一般に〉にそうとは限らない。
たぶん、大して変わらない。
　こんな風に理解しています。

　僕にとっては、どんなアセンブラ・ソースになるのか見えて楽しい、ぐらいですかね。

　ＴＳＲの骨組みは、全部アサム・コードです。あれに必要部分（？）をBasic言語で
つけ加えれば、常駐ソフトができてしまう！　のかな？　といったところです。
　どんなＴＳＲが欲しいのか、あったら嬉しいのか、分かってませんが。
　ただ僕には、（ぜんぜん原理が違うのは分かってますが）stkhelpがほとんどそんな風に
見えています。原理的に常駐ソフトに似てるものがあるとすれば、それはＶｚモード型マクロ
なのでしょうが、たぶん。

　あと１点。としきさん、割とマクロ、マクロ（アセンブラの）と書かれていて、そう翻訳
されると想像するのが「順当」なのかな、と思っていましたが、プロシージャです。もっと単位が
上というか大きい？　たぶん、そのほうが、BASM作者にとって楽なのかな？
　はい、関数は、ルーチンは、当然、多くの、複数のマシン語命令群に翻訳されているようでした。

CLS
　だって、マシン語で書けばvideo関係のbiosコールかな、などなど、大変です。

　エスペラントなどなど（仮想化）は、うーん、深いですねぇ。
　ただこのラインは本筋から大きくずれたかな、という気はしています。


　じつを言うと、僕が最初にみたBASMと、最終版は違うので、もうちょい地道に自分の辿ってきた道
と道具を再検証したいと思っています。あのbasm.exe + α（シェア1ウェア時代）が、見つからない
のです。

　あった！

c:\>tosfind /nbasm*.*		; 時間かかった！　５分
				; でも使い方や環境によりけりですが、僕は、tosfindの
				; バグに一度も出会ってないです。多謝。

from basm.doc

------------------------------------------------------------------------------------
BASM!  The BASIC to 80286 Assembly Language Compiler ShareWare
BASM translates a BASIC-like language to 80286 assembly language source.    
  The assembly language that BASM produces was designed and tested to compile 
  without modification using Borland's Turbo Assembler versions 1.01 & 3.2    
  and Microsoft's Macro Assembler version 4.00.                               
                        Try BASM free for 30 days...                          
      If you like it, please send $25.00 cash, check or money order to:       
------------------------------------------------------------------------------------

　そうなの？　あれで、tasmで通るんだ。
　作者作成の .bas と .asm が直接比較できるファイル群が、ここにはありました。

としきさん、無理してお付き合いする必要なんて、まったくありませんからね。


　ほぼ意味がないし、これ、ish部屋に貼るのか？　と思ったのは以下。
　断片です。
　意味なく長いのを貼って、ごめんなさい　＞konnoさん

---------------------------------------------
     Call Cls
;
;input "What is your name? " a$ 
;
     Mov  SI,Offset $tring_01
     Call PrintStr

<cut>
---------------------------------------------


---------------------------------------------
     PrintStr Proc Near
     Call Len
     Push AX
     Mov  CX,AX
     Cmp  CX,0
     Jle  PS_3
     Mov  BX,$Attr
     Mov  AX,$Ycur
     Mov  DI,$Xcur
     Push DS
     Push ES
     Dec  AX
     Dec  DI
     Cmp  DI,0
     Jg   PS_1
     Xor  DI,DI
PS_1:
     Mov  DX,80
     Mul  DX
     Add  DI,AX
     Shl  DI,1
     Mov  AX,0B000H
     Mov  ES,AX
     Mov  AH,0FH
     Int  10H
     Cmp  AL,07H
     Je   PS_2
     Mov  AX,0B800H
     Mov  ES,AX
PS_2:
     Cld
     Movsb
     Mov  ES:[DI],BL
     Inc  DI
     Loop PS_2
     Pop  ES
     Pop  DS
PS_3:
     Pop  AX
     Add  $Xcur,AX
     Ret
     PrintStr Endp
---------------------------------------------

　こんくらい長くなるし、このプロシージャ、別のプロシージャをcallしてるから、
１対１対応でアセンブルされる、本物のソースはもっと長くなりますね。

だんだんわかってきました。
私の知りたかった一番の核心は

> from basm.doc

> BASM translates a BASIC-like language to 80286 assembly language source.    

ということで、やはり作者的には、コンパイラというよりトランスレータという扱い
のようですね。これで私の頭の中はかなりすっきり。した気がする。してないかも。
もしかすると、スッキリしていない頭でいろいろとあげつらった文章のせいで、逆に
文太さんを困惑させているような。

> 　あるいは、高級言語のインライン・アセンブラ
> の部分をBasicで書けるよ、なのかな。

これは大きいかもしれない。
例えば、私の手がけたポケ３用のEMSドライバ、関谷さんの作られた200LX用の古い
バージョンの移植です。そしてこのドライバは、使用頻度の高いファンクション
しかサポートしていない。そこで、歯抜けの部分のファンクションを自力で作りたい
という思いはあって。そしてポケ３のCPUは80286。

> 　コンパイルとアセンブルの違い（と僕が思っていたこと）。
> 　.asmにしてアセンブルすると、.basをコンパイルするより、〈一般に〉速いものが
> できあがる。
> 　しかし、これは「最適化」できるかによりけりで、〈一般に〉にそうとは限らない。
> たぶん、大して変わらない。
> 　こんな風に理解しています。

理論的には「大して変わらない」かもしれない。
でも、世の中のコンパイラで、そんなにきちんと最適化できるものは少ない、という
現実もあって。
例えば、DOS3とかDOS5の時代、Turbo CとかQuick Cに比べるとLSI C-86は圧倒的に
最適化レベルが高かった、といわれています。それでも、LSI Cの出力を、手作業で
さらに最適化するような人々もいたらしい。ただ、その時代の職人の手仕事なんて
ほとんど伝説の域に達しているわけで、はたしてどこまで本当なのやら。

一応、多くのコンパイラは、その最終出力は実行ファイルです。
ただ、中間段階として、アセンブラソースをつくるものもあります。
LSI C-86はアセンブラソースを作ります。Delphiは作らないような気がする。
また、LSI C-86は同梱の専用アセンブラ用のソースを経由しますので、いろいろな
記述が、一般的なMASMやTASMと異なり、かなり癖がありました。当然、それらとの
互換性は皆無。とはいえ、ニーモニックは同一ですから、その部分だけを手作業で
MASMで移植、なんてことはよくやられていたようです。

> 　としきさん、割とマクロ、マクロ（アセンブラの）と書かれていて、そう翻訳
> されると想像するのが「順当」なのかな、と思っていましたが、プロシージャです。

なるほど、ここも私がわかっていなくて想像していた部分でした。
例えば、分岐やループの構文。
最近のアセンブラならマクロで構築するじゃないですか。
なので、BASICをアセンブラに変換する場合、変換結果はマクロかな、と思っていた
のです。

> 　エスペラントなどなど（仮想化）は、うーん、深いですねぇ。
> 　ただこのラインは本筋から大きくずれたかな、という気はしています。

ずれまくりましたね。私のほうに誤解がありました。
ということで、以下、余談。
現在、一般に、CPUのvirtualizationというと、CPUで実行するソフトウェアの話。
ご存知だと思いますが、世の中にはシミュレーションゲームってありますよね。
アレって、仮想の世界で遊ぶソフトウェア。
同様に、CPUで、自分自身とか、全く別のCPUをソフトウェアとして動かす、という
ある意味で大技なのが、CPUのvirtualization。
ここで、「全く別のCPU」と言っていますが、たとえばこれ、現実には存在しない
架空のCPUであってもかまわない。その場合、当然、そのCPUで動く機械語は架空の
機械語になるわけです。つまり、現実とは距離を置いた言語。この意味で、まるで
人間の会話における自然言語に対する人工言語であるエスペラントのようだ、と
私は考えたわけです。

> 			; でも使い方や環境によりけりですが、僕は、tosfindの
> 			; バグに一度も出会ってないです。多謝。

私のほうが文太さんよりもtosfindの使用頻度が低いせいもあるのでしょう、私も
一度もバグに出会っていません。
ただ、ソースも公開されていますから、その気になればバグ取りできる人も多いと
思います。こういうところもオープンソースのいいところ。つまり、作者は逃げて
しまえるのですから。

としきさん

　今日は、ここだけで失礼します。

>> 　としきさん、割とマクロ、マクロ（アセンブラの）と書かれていて、
>なるほど、ここも私がわかっていなくて想像していた部分でした。
>例えば、分岐やループの構文。

　なるほどぉ。いえ、としきさんが正解です、というか半々。マクロでは
ないが、プロシージャでもない。

　制御フローのことがすぐに頭に浮かぶんですね。この前の変数の話（メモリの
アドレス）とも似て、やはりとしきさんのほうが僕より、なんだろう、プログラミング
上、あるいはＣＰＵとプログラムの関係上、正しい想像力をお持ちです、たぶん。
当たり前だけど。
　その方向で考えているのだろう、と僕には想像ができなかった、ということです。
　文脈を想像力で埋めることができなかった、という意味。

　で、マクロでなくプロシージャでもなく（後者でフローを作れるのか？）　
ベタなラベルジャンプ（最終的にはこれしかないから）が正解でした。

DoLoop_01:
;
;print "Hello there " a$ 		;これだけの命令が
;
     Mov  SI,Offset $tring_03		;ループなしでも
     Call PrintStr			;これだけのプロシージャ
     Call SetCursor			;を必要とする
     
     Mov  SI,Offset A$			;やるなら、高級言語だろう
     Call PrintStr			;あるいは
     Call SetCursor			;Ｖｚマクロ。
     					;この感慨が面白くて
     Call DoCrLf			;BASMに興味を持ちました
;
;incr a 
;
     Inc  A
;
;if a = 23 then 
;
     Cmp  A,23
     Je   $+5
     Jmp  _EndIf_01
;
;exit loop 
;
     Jmp DoLoop_01A
;
;end if 
;
_EndIf_01:
;
;loop 
;
     Jmp DoLoop_01

DoLoop_01A:


>最近のアセンブラならマクロで構築するじゃないですか。
　僕は、最近のことはまったく知らないのですが、そうなのですか？
　c.mos流のあれをみて、そしてその原理をEmmettさんに教わって（＠過去ログ）
最初にあれを考えた人（注）は何て頭がいいのだろう、と思いました。
　Ｃみたいな顔してるくせして、実はラベルを中で自動生成していた。

　ちなみに、上のようなプロシージャだらけの書き方を（この例はあまりよくない
かもしれないけど。たぶん他のやり方は醜すぎるから）、Jeff先生は強く強く
推奨していて（構造化）、「どうだ、アセンブラがパスカルみたいだろう」と
書かれていて、笑いました。
　まあね、と。
　で、僕は、よし、パスカルをやろう、と決心したという次第。その後、
１ミリも前進していないけど。

　JVM、たまたま出会いました。別発言で。

（注）とはいっても、〈マクロ〉アセンブラに内蔵されてると言ってもいいような
仕組みだから、アセンブラ作者自身でしょうね。MASMのドキュメントとかに書かれてる
のかなぁ？　「こんな使い方をすると賢いですよ」とか。

としきさん、

　深く悩んではいないと思うけど、「こいつに何を言って意味があるんだ？」とか
悩まないでくださいね。
　以下で解決しました。

「最初に学ぶべき構造化プログラミング、大きな問題を分割して解決」
https://active.nikkeibp.co.jp/atclact/active/17/060100293/060800002/

　パスカルはやるけど、そんなに大きなプログラムを書く予定はないので、Ｖｚマクロの
経験の延長でやれるところまでやる。
　完全にスパゲったら、「やり直しだぁ、２６回目」みたいにやります。

　アセンブラは、やっぱり、どれだけcallばっかりで効率悪くても（気にしません）、
短く刻んでプロシージャにする（もぐらさんからの教訓）＝アセンブラをパスカルにせよ
の家訓のもと、がんばります。

　何をやっていたかは明かしませんが、以下のような「集中すれば１０分だよ」なマクロを
書いていて、ふと考えました。「構造化」をググれ、と。
　そして、この程度なら「順次」でよろし、という結論を得ました。

　「古典」。別発言であげますね。

i-,

#k #i			; duplicate line
#> #d			; next line

(cd=='\')? #g  ? >z		; delete regex header
(cd=='x')? #g  ? >z
(cd==' ')? #g  ? >z

:a
(-1){ (cd=='\') #d ?{} } 
(cd=='(')?  { i++, #h#g "\1" } ? >a


:b

:z	.

としきさん

　おそらく、捨てたくても持ってないものは捨てられない、という現実。
　しかし、台湾の出版社から出たと思しい _Software Tools_ が
見つかりました。（謎）

    CONTENTS

Preface
Introduction 				1
1. Getting Started 			7
2. Filters 				35
3. Files 				67
4. Sorting 				105
5. Text Patterns 			135
6. Editing 				163
7. Formatting 				219
8. Macro Processing 			251
9. A Ratfor-Fortran Translator 		285

　おお、そう、いい感じ。読めるか分からない、というか、読めない！　
難しすぎ！　つまんないからたまにはギャグぐらい入れて、という罰当たり
なことになりそうな気もしますが、そのうちに、とりあえず字を追ってみます。
多謝。m(__)m


>訳書の場合、まえがき、目次、序論、１章、という順番で並んでいます。
　たぶん同じです。こういう「偉い」本のばあい、チャラチャラした商業出版と
違い、訳者も出版社も、怖くてそういじれません。翻訳権取得時につくられる
契約書にその旨書いてあるばあいも多いです。「改変しないこと。原著のまま
訳出のこと」と。
　１章は「はじめに」ぐらい？　僕でも「さあ、始めてみよう」とは訳せないと
思う。格式みたいなものの演出。

#10417
>訳書で言うところの序論（"Introduction"）の
>最初の５パラグラフほどを読んでいただくと、その先を読みすすめるべきか判断
>できると思います。

　構造化、という文脈で、この本が出てきたのでしたっけ？　たぶん、もう５パラグラフ
読んだと思うけど（最後までできるものなら読み通したいとの判断）、僕との会話で
としきさんが何に引っかかったのか（思い出したか）知りたいので、もう一度読んで
みます。
「序論」後半は、先の各章の簡単な紹介ですよね。
　ただ、元がｐｄｆで上下さかさま（ＯＣＲで化け化け化け化け）のページが「序論」
に入っていたみたいなので、ちょっと１ページごとのe-text作りになりそう。

　具象的個々別々の問題への抽象的解法を見出す。

　僕が日常的にやっている作業より高度なテキスト処理の話だと思うけど、プログラミング
環境を整えるプログラムの作成について、が全体のテーマですよね。
　grep使って、statementだけ取り出す、とか。
　grepの作り方、という話でしょうけど。


冒頭５パラグラフ。
------------------------------------------------------------------------------
	INTRODUCTION

We are going to discuss two things in this book -- how to write programs 
that make good tools, and how to program well in the process. 

What do we mean by a tool? Suppose you have a 5000-line Pascal program 
and you need to find all references to the variable time, to make sure it can 
safely be changed from type integer to type real. How would you do it? 

One possibility is to get a listing and mark it up with a red pencil. But it 
doesn't take much imagination to see what's wrong with red-penciling a hundred 
pages of computer paper. It's mindless and boring busy-work, with lots of 
opportunities for error. And even after you've found all instances of time, you 
still can't do much, because the red marks aren't machine readable. 

Another approach is to write a simple program to find lines containing the 
identifier time. This is an improvement, for such a program is faster and more 
accurate than doing the job by hand. The trouble is that the program is so specialized 
that it will be used once by its author, then tucked away and forgotten. 
No one else will benefit from the effort that went into writing it, and something 
very much like it will have to be reinvented for each new application. 

Finding time's in a Pascal program is a special case of a general problem, 
finding patterns in text. Whoever wanted references to time today will want 
references to some other variable tomorrow, readln and writeln calls the 
day after, and next week an entirely different pattern in some unrelated text. 
Red penciling never ends. The way to cope with the general problem is to provide 
a general purpose pattern finder that will look for a specified pattern and 
print all the lines where it occurs. Then anyone can say 

	find pattern 

and the job is done. find is a tool: it uses the machine; it solves a general 
problem, not a special case; and it's so easy to use that people will use it instead 
of building their own. 
------------------------------------------------------------------------------

　おお、ちゃんとパスカル用になっている。が、内容は同じと言ってよいでしょう。
　ただ、ここまで一般的（抽象的）な問題を解決するツールを僕が開発するとは思えない
ですけどね。grep/sed/awkの使い方を十分マスターすれば良いような気がする。
まだまだ十分でないから。
　逆に、

2022/11/06  18:58    369 srch_do1.def
2022/10/29  11:23    220 srch_do2.def
2022/10/31  22:44    199 srch_do3.def
2022/10/31  23:06    209 srch_do4.def
2022/11/01  01:59    199 srch_do5.def
2022/11/01  02:13    131 srch_do6.def
2022/11/18  11:42    176 srch_do7.def
2022/11/06  18:25    321 srch_do8.def
2022/11/14  01:08    126 srch_do9.def
2022/11/16  00:15    298 srch_doa.def
2022/11/17  17:25    321 srch_dob.def
2022/11/18  11:48    240 srch_doc.def

　これらにちゃんと名前をつけて、管理せい！　という感じですかね。
　あ、これ、もぐら流。中身の変更箇所がちょっとずつ違うだけ。
　これらに一般解はないです。問題のほうが"special case"だから。個別だから
偉いツール群。

　それでも、いい本っぽいと思っています。何かが得られるよう精進したいです。
　ありがとうございます。
　なお、パスカル版の翻訳はないみたいでした。


　蛇足。Pascal版 Intro pp.1-2。ページまたぎ部分。


All of them have been run without change on a variety of machines and Pascal 
compilers. 
				;A
---------------------[End of Page 1]---------------------
				;B
The second concern of this book is how to write good programs.

　このページ区切りフッタあたりに色々なノイズが入ります。Aの箇所にページとか
Bの箇所に"Introduction", "CHAPTER 1", "INSIDE THE IBM PC" (see #10359) とか。
それも壊れて化けたりもして。スペースや改行が入ったりもする。それらをＶｚマクロ
やsedで掃除しています。

　点検は、
>cgrep -A2 -B2 "End of "	;After & Before

　find pattern に同じ。

> オリジナルのvz.defにBlだけ8192に変更したものを読んで起動し、0007.cgiを開いた
> ところで0007.cgを挿入して、無事に正常挿入。うれしい！

テストデータを対象にバグを回避しているだけなので他で問題が出ると思います。
テスト版はマクロの読み込み関連でバグがあるようですのでご注意ください。

> ということで、これから確認したい項目。
> 80桁未満で桁折しても状況が発生しそう、ということから、例えば、以前、文太さん
> に提供していただいたニフティのログを使って、ファイルサイズを0007.*と同じに
> したものを作って状況がどうなるか。

検証はよろしくお願いします。m(__)m

> Blとかのバッファの開始ポイントのアドレスをVzのマクロで取得するには、どう
> すればよろしいのでしょうか？
> あまり関係はないとは思いますが、今回のテスト版で、もし以前の版と大幅に変化
> しているかどうか確認できれば、と思いまして。

BLの相対アドレス情報などは、めざらさんが出してくれたので（ありがとうございます）
VTDOS環境での絶対アドレスは

vzk07t01 　vzk07t02 test
D192	pq..148		lbuf		8192
F192	pq..149		tmpbuf4		256

スタック領域なので、コードの修正分サイズが増えても変わりませんね。
常駐／非常駐とも同じです。
同じマクロ環境で、高橋版は
vzt 
CFFE	pq..148		lbuf		8192
EFFE	pq..149		tmpbuf4		256

この差は、#if 文でマクロの構成が違うからかなぁ。
オリジナルVZとマクロでは

vzo
777C	pq..148		lbuf		2048
7F7C	pq..149		tmpbuf4		256

BLは変えてるかもですが、だいぶ余裕がありますね。
このラインバッファのサイズで挙動が変わるのは、メモリ転送ルーチンで
ラインバッファを一時バッファとして使っているのが関係しているのかなぁ？

　地獄の仕事場から息継ぎのため、一瞬だけ、浮上してみます。
　すいません、疲れてます。完全なる雑巾状態。そういうときは、こういう無意味な
読書をするにかぎるのです。

    Readers who are sensitive to questions of efficiency may wonder if it is 
economical to use two programs when one would serve. The answer depends 
on the true costs involved, which are often not properly estimated. Most people 
who talk about "efficiency" are concerned primarily with how much machine 
resources are used in the final run or in hands-off production, not with how 
much "people" and machine time is consumed in all the compilations, debugging 
and other false starts that prepare for the final run. Throughout this book 
we consistently take the view that people cost a great deal more than machines,
and that the disparity will increase in the future. Therefore the most important 
consideration is that people get their jobs done with a minimum of fuss and 
bother. 

---------------------[End of Page 82]---------------------

　効率の問題に敏感な読者は、1 つのプログラムで事足りるのに、2 つのプログラム
を使うのは経済的なのだろうかと思うかもしれない。その答えは、しばしば正しく
見積もられていない真のコストに依存する。「効率」について語る人の多くは、
最終的な実行やハンズオフ生産でどれだけの機械資源が使われるかに主眼を置いて
おり、最終実行の準備のためのコンパイル、デバッグ、その他の誤ったスタートで
どれだけの「人」と機械時間が消費されるかには関心がない。本書では、一貫して
「人は機械よりもコストが高い」「その格差は今後ますます広がる」という見解を
とっている。したがって、最も重要なことは、人が最小限の手間で仕事を成し遂げる
ことである。（DeepL による翻訳。立派！　トーンだけ改変）

　（ハンズオフ生産だけでしょう、意味不明なのは。消費も変か。最後のところは
　　やるね、と思いました。しかし手を入れたくもなる、が、「人」はコストが高い
　　のです）

　さすがです、カーニハン先生。ごもっとも！

C:\C>dir /L /B |sort
2repl.def	
2repl2.def	
2strsrch.def	
999.def		
addzspc.def	
alpha.def	
altkey_t.def	
arr_srch.def	
array2.def	
array3.def	
blk0.def	
bothmov.def	
catg_fix.def	
cnd_sch1.def	
com_box.def	
 (以下50行略。うひょひょひょひょ。下品な笑い)

　さすがにこれだけパスカルのコードを読むと、けっこう単語を覚えるものですが、
やっぱりＶｚマクロが僕にとって最高の高級言語だ、という確信も強くなりますね。
　仕事するするＶｚマクロ。いえ、本業じゃありません。

> 常用環境の場合は、なにかがFFFFhを超えてしまいそうだし

pq..149 は、tmpbuf4 で、ソースでは使われていないようです。
緩衝領域として２５６バイト設定しているのは、プッシュポップのスタックが後ろから積まれるからかも。
そうだとすれば、この領域を使うのは危険ですね。
pq..149 が、FF00h を超えていたらバッファを減らさないと危険ということでしょうか。

げげ、私知らないで私家常用版で使ってしまっていました。(>_<)
見直さなくては。(^^;;

> test版の時は8000hをまたいでいるし。
あ、そうか、ラインバッファが8000hをまたぐバグってこれを言っていたんですね。

うちのオリジナルVZとマクロでは
vzo
777C	pq..148		lbuf		2048
7F7C	pq..149		tmpbuf4		256

テスト版vzとオリジナルマクロでは
7822	pq..148		lbuf		2048
8022	pq..149		tmpbuf4		256

この環境で、8000h をまたぐバグが出るかどうか確認すればいいのか。
ん？ 高橋版で直っていたかしらん？ ちょっと過去ログの海に潜ってみます。