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

一括表示


  BASM - 文太 22/11/11-12:35 No.10387
 ┣ TSR!!! - 文太 22/11/11-13:19 No.10389
 ┣ アセンブラ&コンパイラ、きっと NOT (neg?) - 文太 22/11/11-16:12 No.10390
 ┃┃┣ 追記 - 文太 22/11/11-16:29 No.10391
 ┃ ┗ Re: アセンブラ&コンパイラ、きっと NOT (neg?) - としき 22/11/11-22:58 No.10392
 ┃ ┗ Re^2: アセンブラ&コンパイラ、きっと NOT (neg?) - 文太 22/11/12-00:46 No.10393
 ┃  ┣ PrintStrプロシージャ(asm) - 文太 22/11/12-01:12 No.10394
 ┃  ┗ Re^3: アセンブラ&コンパイラ、きっと NOT (neg?) - としき 22/11/12-16:13 No.10395
 ┃   ┗ Re^4: アセンブラ&コンパイラ、きっと NOT (neg?) - 文太 22/11/12-21:53 No.10396
 ┃   ┃ ┗ Re^5: アセンブラ&コンパイラ、きっと NOT (neg?) - としき 22/11/12-23:09 No.10398
 ┃   ┃ ┣ Re^6: アセンブラ&コンパイラ、きっと NOT (neg?) - 文太 22/11/13-00:17 No.10401
 ┃   ┃ ┃ ┗ Re^7: アセンブラ&コンパイラ、きっと NOT (neg?) - としき 22/11/13-01:30 No.10405
 ┃   ┃ ┃ ┗ ゲーム&ビジネス - 文太 22/11/13-14:06 No.10408
 ┃   ┃ ┃  ┗ Re: ゲーム&ビジネス - としき 22/11/14-01:36 No.10416
 ┃   ┃ ┃  ┃ ┗ Programming Style - 文太 22/11/14-21:21 No.10422
 ┃   ┃ ┃  ┃ ┗ Re: Programming Style - としき 22/12/25-00:13 No.10442
 ┃   ┃ ┗ Re^6: アセンブラ&コンパイラ、きっと NOT (neg?) - 文太 22/11/13-00:31 No.10402
 ┃   ┃  ┗ Re^7: アセンブラ&コンパイラ、きっと NOT (neg?) - としき 22/11/13-01:01 No.10404
 ┃   ┃   ┗ 構造化 - 文太 22/11/13-13:49 No.10407
 ┃   ┃    ┣ Re: 構造化 - 文太 22/11/13-23:36 No.10410
 ┃   ┃    ┗ Re: 構造化 - としき 22/11/14-01:36 No.10417
 ┃   ┃     ┣ Index of _Software Tools_ (1976) by Kernighan & Plauger - 文太 22/11/14-20:56 No.10420
 ┃   ┃     ┗ 18650 - 文太 22/11/14-21:05 No.10421
 ┣ JVM - 文太 22/11/12-21:54 No.10397
 ┃ ┗ Re: JVM - としき 22/11/12-23:23 No.10399
 ┃ ┗ Re^2: JVM - 文太 22/11/13-00:16 No.10400
 ┃  ┗ Re^3: JVM - としき 22/11/13-00:53 No.10403
 ┃   ┗ 大門未知子 - 文太 22/11/13-13:03 No.10406
 ┗ 古典 - 文太 22/11/13-23:38 No.10411
  ┗ _ST in Pascal_ (1981) - 文太 22/11/18-13:07 No.10424
   ┗ Re: _ST in Pascal_ (1981) - としき 22/11/18-16:31 No.10425
    ┗ Re^2: _ST in Pascal_ (1981) - 文太 22/11/18-20:28 No.10427
     ┣ Re^3: _ST in Pascal_ (1981) - としき 22/11/18-22:11 No.10428
     ┗ Re^3: _ST in Pascal_ (1981) - 文太 22/11/28-21:22 No.10436
      ┗ Re^4: _ST in Pascal_ (1981) - としき 22/11/30-01:49 No.10439
       ┗ Re^5: _ST in Pascal_ (1981) - 文太 22/12/01-16:15 No.10441

(10387) 10387BASM  投稿者:文太   2022/11/11(金) 12:35
   コメント数 4


https://www.bcxbasiccoders.com/

 このページの一番下に
Download BASM286 Here!
 というのがあります。僕はさっき落として、

------- demo01.bas -------
cls
input "What is your name? ",a$
cls
do
print "Hello there ";a$
incr a
if a=23 then
exit loop
end if
loop
-------------------------

 というのをdemo01.asmに変換したつもりなのだけど、
としきさんの質問にさらさら答えられるほど、basmにもbasicにも
asmにも通じていないことが(予想どおり)判明したので、リンク
だけ貼っておきます。

 そんなに長く話が続くような気はしていませんが、壮大な
スレッド(ツリー)が得意でないので、いちおう新規ツリーを
立てておきます。

 "Hello, world"より少し複雑だけど、"Hello there Bunta"と
23回 print してくれるプログラムですよね。
 (ここにはアセンブラもqbasicもない。そうだ、vtdosでusモード
ってどうやるのかも知らないんだ。コードページをいじるの?)

basm.$$$ 6,868 2022-11-11 10:05
demo01.asm 4,235 2022-11-11 10:05

 これらの関係は何?
 あの見栄えでは、そのままアセンブルできないような……。
 簡略化なんとか、なのかな?



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

(10387) 10389TSR!!!  投稿者:文太   2022/11/11(金) 13:19
    10387 番 文太 さんへのコメント


 興味のある方は、
c:\basm\tsr\tsr.1
 とか見てみてください。たぶん、TSRの骨格部分。InDOS flagとか見てる……。
 ver check もちゃんとしてる。dos2 も dos3 も、それぞれに特殊なところがあるのね。
 いつの日か!

 なんかちょっと少し真面目に勉強する価値があるような気がしてきた、basic。
 続かないだろうけど。

 SideKickとかね、興味はあるのです。Norton Guidesとかも。1kbuf.comもね。
 忘れちゃいません。いつか使ってやろう。その前にEMSなんだけど。
 壊されないバッファは今でも欲しいのです。


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

(10387) 10390アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:文太   2022/11/11(金) 16:12
    10387 番 文太 さんへのコメント    コメント数 2


#10386 から、ここに繋がります。

>ここだけ、ちょっと長くなるけど、解説。
 ありがとうございます。分かってない点が少し明確になったと思います。

>とはいえ、今日はもう寝る。
 いっぱい寝てください。いろいろあって、僕も職場の部屋で1時間ほど寝ました。
 少しはすっきりしたのかな?

>ということで、BASMの入力と出力がどうなっているか、ということに興味津々。
 どんどん興味が高まってきましたか。いいのか、悪いのか。
 ま、TSRまで作れるらしいので。
 で、コンパイラ兼トランスレータ(.bas -> .asm)なのかな?
 たしかにどっかに"compiler/compile"という単語があったみたいで、あれ?
 ま、BASM286.zipをDLしてください。

C:\BASM>tree
C:.
├─Help
├─Library
├─Sample1
├─Sample2
├─Sample3
└─Tsr

 全部英語ですが、大丈夫ですよ。demo01.basは、\Sample1から取りました。
 \basm に、basm.txtがあります。DeepLなんか使わなくても、キーワードだけ
拾っても読めると思う。

 さてさて。

>まず機械語というのはビットの羅列。
 了解。ま、16進数で表記すれば、少し省スペース。人間がふつう読めないのは同じ。

>すると次に、それをそのまま機械語に変換できるとうれしい。
 です。

>ということで、ニーモニックを機械語に変換するのがアセンブラ。
 了解。まだ大丈夫。

>とはいえ、基本的にニーモニックと機械語は1対1。
 です。

>そうではなく、変数に定数を代入する、というようなロジックでプログラムを書く
>のが高級言語。
 変数への代入? どういうことでしょう? アセンブラソースだって、変数への
代入はするでしょう? 何かロジックが根本において違う、ということだろうと
想像。

>そして、そのプログラムを複数の機械語に変換する、というのがコンパイラ。
 なぜ、としきさんはここで「複数の」と書いたのでしょう?
 想像が追いつきません。m(__)m

>また、コンパイラも、ターゲットのマシンの機械語にコンパイルする、いわゆる
>普通のコンパイラのほかにも、仮想的なマシンの機械語にコンパイルするという
>種類のものが昔からありました。

 ここからは、もうまったく。CPUにそもそもvirtualizationの仕組みが入っている
というのは、「分からん」「いつかね」とCPU本でスキップした箇所。
 いつの日にか、理解できるようになりたいと思います。

 こういう見た瞬間、「分からん」というものは、ただ10回読みます。
 だんだん分かってきます、といいな。
 10回、ゆっくり読みます。大事です。
 ありがとうございます。

>最初にBASMの話を聞いたとき、私はこれだと思ったんですよ。
 いちおう、これのはずなのですが。

>マクロを使いまくったアセンブラのソースに変換するのであれば、それはコンパイラ
>でもアセンブラでもないよね、ということ。
 ほぼこれのはずです。


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

(10387) 10391追記  投稿者:文太   2022/11/11(金) 16:29
    10390 番 文太 さんへのコメント


>マクロを使いまくったアセンブラのソースに変換するのであれば、それはコンパイラ
>でもアセンブラでもないよね、ということ。

; from demo01.asm

;**********************************************************************
;cls
;**********************************************************************
Call Cls
;**********************************************************************
;input "What is your name? " a$
;**********************************************************************
Mov SI,Offset $tring_01
Call PrintStr
Call KBInput
Mov SI,Offset $_0_
Mov DI,Offset A$
Call MoveStr
;**********************************************************************

 call先は探さないけど(libraryに入っているのかな?)、これは、
.bas -> .asm のトランスレータの仕事ですよね。


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

(10387) 10392Re: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:としき   2022/11/11(金) 22:58
参照先:http://toshiki.la.coocan.jp/
    10390 番 文太 さんへのコメント    コメント数 1

#10387で紹介されたリンクからダウンロードしました。
まだ中を覗いてもいません。
が、#10391を見る限りでは、明らかに素のアセンブラ。
なぜここでアセンブラのソースにとどめて一気にマシン語にまで落とさなかったん
だろうという疑問はありますが、私にはわからない何らかのメリットはあるんで
しょう。FAQとかあれば、きちんと書いてありそうな疑問ではあります。

> >そうではなく、変数に定数を代入する、というようなロジックでプログラムを書く
> >のが高級言語。
>  変数への代入? どういうことでしょう? アセンブラソースだって、変数への
> 代入はするでしょう? 何かロジックが根本において違う、ということだろうと
> 想像。

眠くて端折ったところ、やっぱりわかりにくくなっていますね。
多くの場合、高級言語では、1つのコマンドまたはステートメントは複数の機械語
に変換されるのです。例えば、変数の代入の場合なら、変数はメモリ上のどこかの
領域に確保されているわけで、そのアドレスを計算してから、そこへの代入、と
いうコードに変換されるわけです。
この前提があるものですから、かつて、LSI-C86が、可能な限り変数をレジスタに
割り付けると知って、多くのプログラマが驚いたのです。レジスタなら、変数の
アドレスを計算するルーチンが丸々省略できて、場合によっては、高級言語の1つ
の代入が機械語の1つのコードに変換できるわけですから。
私の個人的な話をすると、昔、8ビットマシンでBASICのコードを機械語にハンド
アセンブルしていたとき。当時のZ80では、レジスタを使った値の受け渡しよりも
スタックを介した値の受け渡しのほうが早い場合が多かったのです。今のCPUが
どうなっているかは知りませんがね。なので、私のコードでは、スタックを使い
まくり。

ということで、

> >そして、そのプログラムを複数の機械語に変換する、というのがコンパイラ。
>  なぜ、としきさんはここで「複数の」と書いたのでしょう?

高級言語の1つのコードは、多くの場合、複数の機械語に変換されることが非常に
多いという現実があるわけです。もちろん、場合によっては、一つの機械語に変換
されるかもしれません。そして、仮に一つの機械語であっても、それは単なるcall
文に変換されて、変換先で複数のコードが実行される、ということになっている
かもしれません。

> >また、コンパイラも、ターゲットのマシンの機械語にコンパイルする、いわゆる
> >普通のコンパイラのほかにも、仮想的なマシンの機械語にコンパイルするという
> >種類のものが昔からありました。
>  ここからは、もうまったく。CPUにそもそもvirtualizationの仕組みが入っている
> というのは、「分からん」「いつかね」とCPU本でスキップした箇所。

CPUのvirtualizationとは、おそらく直接は関係ない。
まずは、クロスコンパイラ、という技術を知っていただくのがいいのかな。
多くの場合、コンパイラは、自分の動いているマシンのCPU用のコードを出力します。
これに対してクロスコンパイラは、別のマシン用のコードを出力します。
普通、このクロスコンパイラというやつは、現実に存在するマシンのコードを出力
します。でも、その気になれば、全く世の中に存在しないマシン用のコードを出力
するように設計することも可能なわけですよ。
自然言語で考えればわかりやすいかもしれません。
翻訳ソフトで、普通なら出力が英語。これが普通のコンパイラ。
クロスコンパイラなら、出力がフランス語。
でも、例えば、エスペラントを出力させることも可能。
あるいはそれこそ、仮想言語であるヴォイニッチ語を出力させる、とか。
この辺、私の説明がつたないので、自然言語との類推が難しいかもしれない。
疑問点があればおっしゃってください。
もうちょっと具体的に説明できるかもしれません。

> >最初にBASMの話を聞いたとき、私はこれだと思ったんですよ。
>  いちおう、これのはずなのですが。
>
> >マクロを使いまくったアセンブラのソースに変換するのであれば、それはコンパイラ
> >でもアセンブラでもないよね、ということ。
>  ほぼこれのはずです。

そうですね、なんとなくそんな感じです。
なかなか面白そうではあります。
      - No.10392 -    このTreeへ    コメント元:10390 へ [リストへもどる] soft

(10387) 10393Re^2: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:文太   2022/11/12(土) 00:46
    10392 番 としき さんへのコメント    コメント数 2

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

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をコンパイルするより、〈一般に〉速いものが
できあがる。
 しかし、これは「最適化」できるかによりけりで、〈一般に〉にそうとは限らない。
たぶん、大して変わらない。
 こんな風に理解しています。

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

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

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

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

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


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

 あった!

c:\>tosfind /nbasm*.* ; 時間かかった! 5分
; でも使い方や環境によりけりですが、僕は、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 が直接比較できるファイル群が、ここにはありました。


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

(10387) 10394PrintStrプロシージャ(asm)  投稿者:文太   2022/11/12(土) 01:12
    10393 番 文太 さんへのコメント

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


 ほぼ意味がないし、これ、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してるから、
1対1対応でアセンブルされる、本物のソースはもっと長くなりますね。


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

(10387) 10395Re^3: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:としき   2022/11/12(土) 16:13
参照先:http://toshiki.la.coocan.jp/
    10393 番 文太 さんへのコメント    コメント数 1

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

> from basm.doc

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

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

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

これは大きいかもしれない。
例えば、私の手がけたポケ3用のEMSドライバ、関谷さんの作られた200LX用の古い
バージョンの移植です。そしてこのドライバは、使用頻度の高いファンクション
しかサポートしていない。そこで、歯抜けの部分のファンクションを自力で作りたい
という思いはあって。そしてポケ3の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の使用頻度が低いせいもあるのでしょう、私も
一度もバグに出会っていません。
ただ、ソースも公開されていますから、その気になればバグ取りできる人も多いと
思います。こういうところもオープンソースのいいところ。つまり、作者は逃げて
しまえるのですから。
      - No.10395 -    このTreeへ    コメント元:10393 へ [リストへもどる] pre

(10387) 10396Re^4: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:文太   2022/11/12(土) 21:53
    10395 番 としき さんへのコメント    コメント数 1

としきさん

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

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

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

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

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

DoLoop_01:
;
;print "Hello there " a$ ;これだけの命令が
;
Mov SI,Offset $tring_03 ;ループなしでも
Call PrintStr ;これだけのプロシージャ
Call SetCursor ;を必要とする

Mov SI,Offset A$ ;やるなら、高級言語だろう
Call PrintStr ;あるいは
Call SetCursor ;Vzマクロ。
;この感慨が面白くて
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さんに教わって(@過去ログ)
最初にあれを考えた人(注)は何て頭がいいのだろう、と思いました。
 Cみたいな顔してるくせして、実はラベルを中で自動生成していた。

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

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

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


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

(10387) 10398Re^5: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:としき   2022/11/12(土) 23:09
参照先:http://toshiki.la.coocan.jp/
    10396 番 文太 さんへのコメント    コメント数 2

タネンバウム先生は、高名な学者だということは存じております。
でも、和訳された先生の著作をまじめに読んだことは、たぶんない。

> >最近のアセンブラならマクロで構築するじゃないですか。
>  僕は、最近のことはまったく知らないのですが、そうなのですか?

最近の話ではないかもしれない。
もう20世紀のうちから、アセンブラではマクロがビシバシ使われていたと思う。
optasmとかtasmとか、MASMとは互換性がないよ、といわれていた部分はおそらく
ほとんどマクロの部分だと思う。それらを使ったことがないので自信はないけど。

で、まぁ、そういった部分のほとんどはおそらく、いわゆる構造化という考え方
に繋がってくる部分だと思う。つまり、分岐とかループ、ということ。ところで、
先日、書名を出した「ソフトウェア作法」とか「プログラム書法」といった、今
では古典とされる書物がどんなことを書いていたかというと、言語仕様が構造化
されていないFORTRANでも構造化に気を配ったプログラムを書くことができますよ、
ということ。そして、それをさらに敷衍して、当時の(マクロのない)アセンブラ
でも構造化することは可能、ということでした。
ただ、正直、小さいプログラムを力任せに書くのなら、構造化だのなんだのって
はっきり言って不要。だけど、ちょっと大きいプログラムを書こうと思ったら、
構造化は必須。これがあるのとないのとで、開発効率は全く違う。
さて、80年代前半、8ビットパソコンの全盛期。BASICユーザ花盛り。
このころ、マシンはどんどん強力になり、大きいプログラムを書けるようになった。
だけど、それこそ、ソフトウェア工学なんて言葉も知らない小中学生がゲームを
つくる時代。例えば、面白いゲーム、すなわち大きなプログラムをバグを少なく、
かつ早く完成させるにはどうすればよいか、という問題がじわじわと出てきました。
また、いろいろな職場にも、とりあえず導入されたパソコンをどう使うか、という
問題も発生。
ここで求められたのが、BASICでの構造化。
そんな中で登場したのが、ソフトバンク刊「Oh!PC」に掲載された林晴比古氏の記事。
その後、単行本にまとめられて「BASICによるプログラミングスタイルブック」と
して出版されました。私も持っています。
ちょっと癖がある文体で、それに拒否反応を示す人もいます。
ただ、内容については、反論した人がおおむね玉砕するくらいの王道。
おそらく、この本または雑誌の記事で初めて構造化ということを知ったという人も、
当時のパソコン少年では多いかもしれません。

あぁ、また昔話で終わってしまった。
これだけはっきり症状が出ているということは、老化が進んでいるのでしょう。
ま、いいか。
#いいのか?
      - No.10398 -    このTreeへ    コメント元:10396 へ [リストへもどる] soft

(10387) 10401Re^6: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:文太   2022/11/13(日) 00:17
    10398 番 としき さんへのコメント    コメント数 1

>あぁ、また昔話で終わってしまった。
 面白かったですよ。
 昔話以外の何かを伝えたかったのですか?

 僕が理解したのは、Basic のリファレンスのたぐいで、「構造化」って連呼
されてたのは、そういう背景なのか、ということ。
 Vzマクロから入門しそれしか知らない人は、&00 とかなかったら、jimae buffer
はどうするんですか? ぐらいなんですよね。

 たぶん一生わからないんだろうな、と思うのは、そのゲームへの熱中。
 ギャラクシアンで少し興奮したのかなぁ?

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

(10387) 10405Re^7: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:としき   2022/11/13(日) 01:30
参照先:http://toshiki.la.coocan.jp/
    10401 番 文太 さんへのコメント    コメント数 1

>  昔話以外の何かを伝えたかったのですか?

そうか、そういわれれば、それ以外の何者でもない。
あのコメントを書き出すときは、構造化の由来、みたいなことを考えていたのだと
思うのですが、そもそもそれは昔話でしかないわけで。
なんてこった。

>  たぶん一生わからないんだろうな、と思うのは、そのゲームへの熱中。

ゲームで遊ぶほうもそうですが。
ゲームを作るほうの熱気もすごかった。
そもそも、ゲーム以外(ビジネス用途)にまともに使えるマシンは、シャープの
MZシリーズとNECのPC-80/88/98シリーズの他は、日立のベーシックマスター
と、あとは富士通のFM−8ぐらいだったような記憶がある。その他、沖のif800
はビジネス向けがメインだったけど。
パソコン雑誌のほうもそう。
ベーマガはゲームのプログラムリストがメイン。4大誌も毎月ゲームのプログラム
が大量に掲載されていた。ゲーム以外の記事も一応は載っていたけど、I/Oなんかは
特に、ゲームとゲーム用ツールの記事ばかりだったような記憶がある。RAMは
ほとんど読んでいなかったから知らないけど、アスキーとマイコンは一応、ゲーム
以外の記事もそれなりに掲載されていた。とはいえ、ビジネス向けの記事というと、
やはりソフトバンクのOh!シリーズのほうが多かったような気がする。

ま、でも、それが当時のその界隈での現実ですからねぇ。
      - No.10405 -    このTreeへ    コメント元:10401 へ [リストへもどる] soft

(10387) 10408ゲーム&ビジネス  投稿者:文太   2022/11/13(日) 14:06
    10405 番 としき さんへのコメント    コメント数 1


>>昔話以外の何かを伝えたかったのですか?
>そうか、そういわれれば、それ以外の何者でもない。
 すいません、僕が現在、昔を生きているのが異常なわけですが、でも、だからこそ
昔話こそが(Javaはよろし)面白いのです。

>構造化の由来、みたいなことを考えていたのだと
 是非、是非、是非!!!

>ゲームで遊ぶほうもそうですが。
>ゲームを作るほうの熱気もすごかった。
 これなら、僕にも想像がつく。僕にとっては機械相手に遊んでる、みたいな
感覚だった。そうそう。このゲーム、どう出来上がってるか、どういう仕組みで
動いているのか? と気にすることができる人たちがいるんだ、と考えたことが
ありました。
 僕的語彙には、作者との共鳴みたいなものですね。

>そもそも、ゲーム以外(ビジネス用途)にまともに使えるマシンは、シャープの
>MZシリーズとNECのPC-80/88/98シリーズの他は、日立のベーシックマスター
>と、あとは富士通のFM−8ぐらいだったような記憶がある。その他、沖のif800
>はビジネス向けがメインだったけど。
 ゲームとエロビデオがある種のITを商業的に後押しした、とは聞きます。
 ただIBM機がPCブームを巻き起こしたのは(個人の)ビジネスを射程に
収めたから、というより、そっちがメインターゲットだったから、とも聞きます。
 へぇ、というだけなのだけど、上の商標名(固有名詞)3回ぐらい眺めておきます。
 「日立のベーシックマスター」、c.mosさんが所有されていました。
 日立はなぜPC市場を早期撤退したのだろう? もっと大きいのが儲かった?

>パソコン雑誌のほうもそう。
>ベーマガはゲームのプログラムリストがメイン。
 手で打ち込んでいたんですよね。根性あるなぁ。でも、経典の写経のように
聖的体験だったんだろうなぁ。

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

(10387) 10416Re: ゲーム&ビジネス  投稿者:としき   2022/11/14(月) 01:36
参照先:http://toshiki.la.coocan.jp/
    10408 番 文太 さんへのコメント    コメント数 1

> >構造化の由来、みたいなことを考えていたのだと
>  是非、是非、是非!!!

ここ、まじめに書こうとすると、私の生まれる前まで遡ることになるわけです。
それでいて、きちんとした参考文献はあまり持ってない。
記憶で書くと、ソフトウェアの生産性が全然上がっていないね、というのが出発点。
そして、ソフトウェア工学なる学問が出来上がってきた。
これの中身もいろいろあって、例えば、コンパイラの最適化をどうするか、なんて
いうのも論点の一つ。そして、いかにバグの少ないソースコードを書くか、という
ことも論じられるようになった。
この当時、プログラムは「順次」「反復」「分岐」 *だけ* で書ける、という説が
出てきたのだけど、当初、その主張があまりにも強すぎて、当時の感覚では過激派
と思われるくらいだったらしい。
そして実際、その3つで大抵のロジックは書けるわけだけど、やっぱりエラー処理
とかまでその3つだけで書こうとするとえらく冗長になるわけで、まぁそんなに
理屈どおりにはいかないわけですよ。ただ、それらの反論は例外的な事象にばかり
焦点を当てたものがほとんど。普通のプログラムであれば、その3つだけで書ける
よね、というところに収束し、今ではソフトウェア初級レベル。今ではもしかすると
普通科高校でやってる「情報」のカリキュラムにも入っているかもしれない。
あとは、トップダウンアプローチとか段階的詳細化とか、用語はいろいろあるけど、
難しいことは解きほぐして解決しましょう、というのは現実世界も同じ。

あ、そうだ、もうひとつ。
ソフトウェア工学って、どうやればバグの少ないプログラムを書けるか、という
ことも扱っています。これって、航空機工学で、どうやればパイロットが操縦の
ミスを少なくできるか、というのと同じようなもの。例えば、あるメーターとか
スイッチとか、操縦士と副操縦士の両方に1つずつ設けるのか、それとも真ん中に
1個だけにするのか、というのを考えるのは立派な考察対象。
ソフトウェア工学にも似たようなことがあります。
たとえば、ループの範囲は直感的にわかったほうがいい、という出発点に立った
とします。まずその前提の当否が議論されて、うんそうだね、と概ねのコンセンサス
が取れた。すると次に、ではどうやってループ範囲を強調するか、という話になる。
プログラムリストをぱっと見てわかるためには、そうだ、字下げを使おう、となる。
ここでまた、部外者からみるとつまらないとしか思えない議論が始まる。すなわち、
字下げは何文字がいいのか、という話。字下げが1文字だけだとループ範囲はよく
わからない、10文字も下げたら多重ループの場合にどうなる、みたいな話を昔の
人は大真面目にやっていたらしい。ただ、これってきっと、心理学とか認知科学の
領域の話ですよね。

余談。航空機工学の話。
昔、80年ぐらい前の話かなぁ、米軍機で事故が多かった。これはコックピットが
狭すぎる、もしくは広すぎて手が届かないせいでパイロットが素早い動作ができない
ためではないかと考えた人がいた。そこで何をやったかというと、数千人だかの
パイロットの身体測定を行い、平均値の身体寸法の人に適したコックピットのサイズ
にしよう、という話になった。ところが、実際に測定を行い平均値を求めた結果、
数千人の中にその平均値ぴたりの人が一人もいなかったとか。あらまぁ。

>  日立はなぜPC市場を早期撤退したのだろう? もっと大きいのが儲かった?

ん〜、単に儲からなかったから、なんでしょうね。
ベーシックマスターはそれなりに売れていたけど、後継のS1は、売れたという話
を聞いたことがない。
とはいえ、プリウスって言ったっけ、ノートパソコンは出していましたよね。
      - No.10416 -    このTreeへ    コメント元:10408 へ [リストへもどる] soft

(10387) 10422Programming Style  投稿者:文太   2022/11/14(月) 21:21
    10416 番 としき さんへのコメント    コメント数 1

>10文字も下げたら多重ループの場合にどうなる、みたいな話を昔の
>人は大真面目にやっていたらしい。
 けっきょく趣味と慣れの問題ではないかと思いますが……。
 たしかに、c.mos流に慣れると(読んでません、眺めてます)、もぐらさんも
BASM出力ソースも小文字変換したくなりますが、「慣れよ、いろんな書き方がある」
となってます。
 Basic, Pascalも、case-insensitiveだけど、あるパスカル本は、これが規範じゃ
と言ってましたね。WriteLnとか。ま、これでいく? とか。

 Priusって、日立だっけ? このXPノートPCがどうしても見つからないん
ですよねぇ。EMSが取れるマシンだったので、さんざん迷ったうえで立川で買った
のに。どこ行ったんだろう? cmos電池があがってるよ、ぜったい。としきさんが
知るわけないだろ!

 数学の中間テスト。平均点は53.5点でした。53.5点だった人はいるわけないですよね。


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

(10387) 10442Re: Programming Style  投稿者:としき   2022/12/25(日) 00:13
参照先:http://toshiki.la.coocan.jp/
    10422 番 文太 さんへのコメント

>  数学の中間テスト。平均点は53.5点でした。53.5点だった人はいるわけないですよね。

私のいいたいことが微妙に伝わっていないっぽい。
例えば、大学入試。
共通一次とかセンター試験とか、100万人が受験したとします。
科目は5教科。
各科目の平均点を四捨五入して1点刻みにして、全教科が平均点だった人がいったい
何人いるか、という問題です。
これ、おそらく、確率統計の理論を使って、理論的な値は求まるはず。
そんな理論を使わなくても、受験者が増えれば全科目が平均点になる人数は増えるで
あろう事は直感的に分かります。逆に、科目の数が増えれば、全科目が平均点に一致
する人は減っていくだろうということも想像できます。

先般、私が例に挙げた航空工学の問題の場合、対象となる人数はたしか数千人という
レベルだったはず。一方で測定項目のほうは百項目以上あったのではなかったかな。
ということから、全項目が平均値の人はいなかった、という結論であったはず。
項目を絞り、平均値のプラスマイナスである程度の範囲をとっても、全てがその範囲
に納まる人はごく少数、という結論だったような。
え〜と、どこで読んだんだっけかな。
こういうネタだと「乗り物ニュース」(trafficnews.jp)のサイトにありそうだけど、
ざっくり探した範囲で見つからない。
あった、gigazineのサイトだった。
https://gigazine.net/news/20200505-us-air-force-average-pilot-problem/
概略。
4000人以上の140項目を測定し、そのうちの航空事故に関係しそうな10項目を選んで
平均値を算出し、その平均値の前後30%に全ての項目が収まる人数を数えたらゼロ。
3項目にまで絞っても、その3項目全てが平均値の前後30%に納まる人は全体のたった
3.5%だったとのこと。

人間の体のサイズというのも、一種の自然現象ですからねぇ。
自然を相手にする、というのと似たようなものなのでしょう。
      - No.10442 -    このTreeへ    コメント元:10422 へ [リストへもどる] soft

(10387) 10402Re^6: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:文太   2022/11/13(日) 00:31
    10398 番 としき さんへのコメント    コメント数 1

>先日、書名を出した「ソフトウェア作法」とか「プログラム書法」といった、今
>では古典とされる書物がどんなことを書いていたかというと、言語仕様が構造化
>されていないFORTRANでも構造化に気を配ったプログラムを書くことができますよ、
>ということ。そして、それをさらに敷衍して、当時の(マクロのない)アセンブラ
>でも構造化することは可能、ということでした。

 ありがとうございます。そして、五月雨でごめんなさい。
 なるほど! いいことを聞きました。では『ソフトウェア作法』は捨てることに
いたしましょう。コロナ渦の2年で、蔵書10分の1は捨てました。財産を捨てなさい
運動、実行中。
 『ソフトウェア作法』の原書のpdf、どっかで見ました。
 要らない。
 焦点をしぼろう。


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

(10387) 10404Re^7: アセンブラ&コンパイラ、きっと NOT (neg?)  投稿者:としき   2022/11/13(日) 01:01
参照先:http://toshiki.la.coocan.jp/
    10402 番 文太 さんへのコメント    コメント数 1

>  なるほど! いいことを聞きました。では『ソフトウェア作法』は捨てることに
> いたしましょう。コロナ渦の2年で、蔵書10分の1は捨てました。

ターゲットとしている言語がFORTRANだから、という理由で捨てるのなら大いに賛同
できます。ただ、この本で取り上げている内容って、文字列処理が多いのですよ。
もちろん、全てではありませんけどね。そういう理由もあって、私、この本の和訳本
を持っていますが、古典だから、という理由を除外しても、なかなか捨てる度胸は
ありません。
      - No.10404 -    このTreeへ    コメント元:10402 へ [リストへもどる] soft

(10387) 10407構造化  投稿者:文太   2022/11/13(日) 13:49
    10404 番 としき さんへのコメント    コメント数 2



>ただ、この本で取り上げている内容って、文字列処理が多いのですよ。
 いいこと聞いた、ふたたび。ありがとうございます!
 そうなんだ、じゃあ、念のため、取っておくかぁ。この本は、本棚の
どこにあるか分からないなぁ、1冊すてるのに、探し回るのは嫌だな、とも
思ってました。(注)

 それより、(『作法』は捨てないほうが良い理由になる? )、「構造化」で
としきさんは、フロー制御−−ループと分岐−−がその代表みたいに書かれて
きましたよね。loopとif ... else。前者をラベルジャンプで、後者をelseなしの
if ... then の羅列で作ったとき、それは「構造的」でないのですかね?
 loop & if_elseがより高度に構造的だとは言えると思うけれど。

 僕は、ちゃんと勉強したことがまったくないわけですが、サブルーチンcallが
構造化の代表格(もっとも分かりやすいサンプル)なんじゃないかと思ってる
のですが。

 行番号ジャンプ(basicにしろsedにしろVzにしろ)は、究極のGOTOみたいで
繰り返し使えばやがてスパゲになる、とは思うのだけど、ループと分岐(case文
も含む)が、、、それほど、、、な気持ちもなくはなく、、、、。
 もはや大きなプログラムを書くことはなかろう(blogjump.defが最長)という
感覚もあるから、こんな風に考えるのだろうとも思うのですが。

 ごくごく簡単な回答で構いません。一言、一語、一発でお願いできませんでしょうか。
 『作法』を読め。え?


(注)−−(注)にならないと思うけど。「文字列処理」の考え方がけっこう
一般性が高そうな事実と、問題解決思考っぽいのと、プログラミング計算が実生活
に役立ったサンプルを超手短に披露−−疲労とか出ます、当然−−。

 充電したリチウムが15本ありました。この中から容量が一番多いもの1本だけ
選べ(アルコールが入って眠れず疲れ切った昨晩の状態でのタスク)。手は2本で、
15本のリチウムを同時には持てず、中腰の姿勢。十分な作業空間なく床に並べること
すらできない。頭と目で計算してタスクをこなすしかない。でも、はやくこの仕事を
片付けたい!
 ソート! 全体を2つのグループに分けよ。1つのグループに最大容量のリチウム
1本だけを残す。1本グループには指を載せておくだけ。総当り戦。

 オチは、今日、空間のじゅうぶんある隣の部屋の机の上で、14本も全部容量順に
並べたこと。最初からこのタスクも頭にあったから、即座問題解決のソート戦略が
嬉しかった。
 はやく寝ればいいんだよ。


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

(10387) 10410Re: 構造化  投稿者:文太   2022/11/13(日) 23:36
    10407 番 文太 さんへのコメント

としきさん、

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

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

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

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

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

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

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 .

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

(10387) 10417Re: 構造化  投稿者:としき   2022/11/14(月) 01:36
参照先:http://toshiki.la.coocan.jp/
    10407 番 文太 さんへのコメント    コメント数 2

「書法」のほうは、サンプルがPL/Iだったりするので、さすがに古すぎるという
判断で、私は図書館で借りて読むだけで終わらせました。「作法」のほうは購入
しましたが、買っただけの価値はあったと思っています。

>  そうなんだ、じゃあ、念のため、取っておくかぁ。この本は、本棚の
> どこにあるか分からないなぁ、1冊すてるのに、探し回るのは嫌だな、とも

本棚に隠れているのって、英語の原書ですか?それとも和訳?
手元の和訳本をチラッと読み返してみたのですが、古典といわれるだけあって、
使われている用語の選択がかなり古いというか、現在から見ると、違和感バリバリ。
私が読んだのは訳されてから10年たっていない時代でしたが、既に軽く違和感を
感じるくらいでしたから、この業界、新しい概念とか用語とかの変化のスピードの
ほどが知れる、という感じ。
ただ、用語の選択以外はなかなかこなれた訳で、私には読みやすかった。

なお、もし原書を読めるようなら、ざっと目次を眺めてみてください。
文太さんの興味を引きそうな項目が並んでいることと思います。
あと、訳書の場合、まえがき、目次、序論、1章、という順番で並んでいます。
原書でどういう並びになっているかわかりませんが、訳書で言うところの序論の
最初の5パラグラフほどを読んでいただくと、その先を読みすすめるべきか判断
できると思います。

>  ごくごく簡単な回答で構いません。一言、一語、一発でお願いできませんでしょうか。

残念ながら、私には一言で述べる言葉は持ち合わせておりません。
ただ、おそらく、そういうことを述べた一言って、わかっている人にはわかるけど、
わからない人には全くわからない一言になるような気がします。
「光あれ!」とか「悔い改めよ」とかって感じで。

>  充電したリチウムが15本ありました。この中から容量が一番多いもの1本だけ
> 選べ(アルコールが入って眠れず疲れ切った昨晩の状態でのタスク)。手は2本で、

職場の電池捨て場に捨てられていた謎のバッテリーパック。
パッケージに書かれていたメーカー名は聞いたこともない。
調べたところ、どうやら懐中電灯をメインに扱っているメーカーらしい。
殻割りしてみたところ、18650が2本。
私は要らないなぁ。差し上げましょうか?
それはさておき。
容量の一番多いものを特定する方法って、どうやっているのですか?
測定?パッケージの印字?

>  ソート! 全体を2つのグループに分けよ。1つのグループに最大容量のリチウム
> 1本だけを残す。1本グループには指を載せておくだけ。総当り戦。

なんか、クイックソートのアルゴリズムみたい。

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

(10387) 10420Index of _Software Tools_ (1976) by Kernighan & Plauger  投稿者:文太   2022/11/14(月) 20:56
    10417 番 としき さんへのコメント

としきさん

 おそらく、捨てたくても持ってないものは捨てられない、という現実。
 しかし、台湾の出版社から出たと思しい _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


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


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

(10387) 1042118650  投稿者:文太   2022/11/14(月) 21:05
    10417 番 としき さんへのコメント

>私は要らないなぁ。差し上げましょうか?
 ま、財産としてとっておき、遊ぼうとしてみてください。
 3.2V-4.2Vで、500mA以下ぐらいで充電。

>容量の一番多いものを特定する方法って、どうやっているのですか?
>測定?パッケージの印字?
 測定です。中古なので劣化していますから。Opus, BT-C3100というものを使っています。
全部測定、容量記入、ソート。
 1本(20本まで同じ)あたり、2時間(満充電まで)+4時間(完全放電)+2時間
(保管用充電)。計8時間ぐらいかかります。初回時のメンテ&健康チェックです。
 ものすごい本数を所有することになってしまっています。

 光あれ!(笑)


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

(10387) 10397JVM  投稿者:文太   2022/11/12(土) 21:54
    10387 番 文太 さんへのコメント    コメント数 1


 #10386 後半に薄く繋がってます。
 ここに貼っておきます。

(2) Andrew S. Tanenbaum. _Structured Computer Organization_, 4th Edition. 1999, Prentice Hall.
 前のパラグラフの一節に対する脚注です。あ、嫌な人の名前が出てきた。彼の本をいっぱい捨てました。
 基本的なアイディアはここから来てる、という注釈。

The Java programming language is based on the virtual machine concept. A program
written in the Java language is translated by a Java compiler into Java byte code. The latter is a
low-level language that is quickly executed at run time by a program known as a Java virtual
machine (JVM). The JVM has been implemented on many different computer systems, making
Java programs relatively system-independent.

 としきさんだって、(分からないけど)、じっと見つめてれば、キーワードから何を言ってるか
分かると思う。
 ま、としきさんは中身を知っているわけだから、読む必要がそもそもないのだけど。

 上の文脈を少しだけつけ加えると、マシン語にはportabilityがない。IntelとMotorolaでは、
instruction setsが違うから。ただし、Javaは、どこに行っても、かなりのportabilityがある。
 え!? どうして? と思って、少しだけ読みました。

Assembly Language For Intel Based Computers By Kip R. Irvine
 という本でした。読んでませんよ、ときどき、e-textを整理したり整形したりしてるだけ
です。今回の出会いは、ほんとうの偶然。あるいは10回よんだ功徳。


 ふーん。でも、これ、関係ないし、僕は興味ないなぁ。Javaって、最近の最有力言語の一つ
なのでしょう。でも、僕は要らない。saki...さんがやってた。やってる。
 (どうでもいいことだけど、うちの学校では1年生必修の「プログラミング演習」でCをやってる
って。伝統的なままでとても宜しい、という感想を持ちました。すごい偏見みたい)

 ま、だいたい話の方向性は見えました。でもでも、、、。
 Tanenbaum先生の思い出に通じる。

 アセンブラ、コンパイラ、トランスレータ、インタープリタ。大きな分類ですね。そして、それら
の関係。すごい抽象論。上の引用箇所の前には、VM0, VM1, VM2とか出てくる。Virtual Machine 0, 1, 2。
はあ、はあ、はあ、みたいな感じでした。


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

(10387) 10399Re: JVM  投稿者:としき   2022/11/12(土) 23:23
参照先:http://toshiki.la.coocan.jp/
    10397 番 文太 さんへのコメント    コメント数 1

>  ま、としきさんは中身を知っているわけだから、読む必要がそもそもないのだけど。

おおむね、知っている単語ばかりなので、だいだい読めました。
ま、ポータビリティは重要です。
例えば、自分でウェブサーバを立てているとか、あるいはレンタルでもいいので
ウェブサイトを持っているという人ならJavaScriptで何かをできるでしょう。
でも、そうではないけど何かアプリを作りたい、といった場合。
自分の手元だけで動くアプリなら、自分の手元の環境と言語でOK。
あるいは、Windows上なら、例えばExcelのVBAという選択肢もある。
でも、ターゲット環境がWindowsだけではない場合。
あるいは、WindowsだけどExcelがない場合。
そういう場合に現場の人間が次に検討する言語はJava。
実際、私、知りもしないJavaで何とかしようか、思案中。
業務システムなんですが、セキュリティの関係で、通常の車内網と独立しているん
ですよ。だからインターネットにも繋がらない。Excelが入っているかどうかも不明。
なにせ、メモ帳すらプロテクトがかかっていて、任意に起動できない。業務システム
からなら起動は可能なんで、存在は確認できるのですがね。
こういう環境でも、Javaは存在している。
となると、なんか遊ぼうと思ったら、必然的にJavaは必須。

ま、必要に迫られたら勉強しましょう。
      - No.10399 -    このTreeへ    コメント元:10397 へ [リストへもどる] soft

(10387) 10400Re^2: JVM  投稿者:文太   2022/11/13(日) 00:16
    10399 番 としき さんへのコメント    コメント数 1

車内網 → 社内網  ;あるいは術語?

ま、必要には迫られないでしょう。そのような人生は生きないと思います。

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

(10387) 10403Re^3: JVM  投稿者:としき   2022/11/13(日) 00:53
参照先:http://toshiki.la.coocan.jp/
    10400 番 文太 さんへのコメント    コメント数 1

> 車内網 → 社内網  ;あるいは術語?

述語ではありません。単なる誤字です。
いかん、アルコールが回っておる。
つ〜か、IMEがへんな学習をしている模様。
この上の2行も、第2順位の単語で確定したからいいものの、最初に候補に出てきた
単語は

術後ではありません。単なる護持です。
遺憾、アルコールが回っておる。

となっていた。一体どうなっているんだろう。
      - No.10403 -    このTreeへ    コメント元:10400 へ [リストへもどる] soft

(10387) 10406大門未知子  投稿者:文太   2022/11/13(日) 13:03
    10403 番 としき さんへのコメント

 かなり受けましたよ。アルコール、まだまだ足りなかったようです。
 頭が回ってる。

>つ〜か、IMEがへんな学習をしている模様。
 社内網 あ、ダメだ、正しくなってしまっている。昨晩は、車内が最初に
出ました。初期設定なのかな?

>術後ではありません。単なる護持です。
 複数候補をそなえた機械なので、その気になればやれるわけですが、なぜか、
これ、すごく受けた。別の候補では、ここまで笑えない。
 大門未知子が病室で憲法論議をしてるイメージがすぐ浮かんで、あう? あう? 
あう? くくくく、お腹が痛い、となりました。


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

(10387) 10411古典  投稿者:文太   2022/11/13(日) 23:38
    10387 番 文太 さんへのコメント    コメント数 1

ブライアン・カーニハン
https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%BB%E3%82%AB%E3%83%BC%E3%83%8B%E3%83%8F%E3%83%B3

『プログラム書法』(_The Elements of Programming Style_)1974
by Brian W. Kernighan and P. J. Plauger
https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style
----- Fortran etc .... ムリ。しかし「文字列処理」

『ソフトウェア作法』(_Software Tools_)1976
by Brian W. Kernighan, P. J. Plauger
----- Ratfor, Cobol, Fortran, Algol etc .... ムリ。しかし、、、。

『パスカル・ソフトウェア作法?』(_Software Tools in Pascal_)1981
by Brian W. Kernighan, P. J. Plauger
----- Pascal!!! 読めないと思うけど。「これらプログラムは実用的・
実践的なのじゃ」と序文にあった。

『プログラミング言語AWK?』(_The AWK Programing Language_)1988
----- これですら、世の中にはもっと分かりやすいtutorialがある、と思った。

『プログラミング作法』(_The Practice of Programming_)1999
by Brian W. Kernighan and Rob Pike
https://en.wikipedia.org/wiki/The_Practice_of_Programming
----- C, C++, C#, Java, Pascal etc .... たぶんムリ。新しすぎ!

 上記5点、すべてpdfで入手可能。ただし、原書=英語。


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

(10387) 10424_ST in Pascal_ (1981)  投稿者:文太   2022/11/18(金) 13:07
    10411 番 文太 さんへのコメント    コメント数 1

_Software Tools_ was originally published in 1976 with the programs written in
Ratfor, a language based on Fortran. Ratfor was implemented as a preprocessor;
it provided Fortran with modern control flow statements like if-else and
while, and some cosmetic improvements like symbolic constants and free-form
input. The approach and the tools have proved sufficiently useful that many
copies of them have been distributed, and there is a large, active user group.

Pascal is now the dominant teaching language for computer science courses,
and is becoming widely used outside of universities as well. We feel that the
lessons about the design and implementation of tools from the original book
carry over intact to Pascal. Thus _Software Tools in Pascal_ has a great deal of
overlap with the Ratfor original. The same programs are present, except that
there is no preprocessor chapter, since Pascal provides most of the sensible control
flow and cosmetic improvements that Ratfor adds to Fortran. On those systems
where Pascal needs augmentation, tools such as the macro and file inclusion
processors serve as language preprocessors.


 とりわけ誰も得しない話。
 でも、とても感慨が深かったので。

 _Software Tools_ 『ソフトウェア作法』は、1976年の発表。翻訳もされて、たぶん
世界中で教科書として、独学の際の参考書として読まれたのでしょう。20ページ
くらい読みました。(注1)やはり、プログラミング言語の翻訳の翻訳の要素を含んで
いるので−−Fortranは当然として, PL/I その他その他への言及も多し−−(その上、
日本語のasciiでは表現できないだろう記号が使われていたので、自分の頭の中に翻訳機
を入れなくてはいけない=e-textをVzで読んでます)、表面的には読めるけどすごく
苦労するわりには理解が浅いだろうな、という不安がありました。余計な苦労です(注2)。
 外国語は、単語知っててなんぼですからね。


 そして、_Software Tools in Pascal_。1981刊。翻訳は出てないのかな? 原著と
同じく変更不要な部分はそのまま、主に上のような部分とプログラムリストを書き換え
ればいいだけだろうけど、でも、読者は(パスカルに興味が少しでもあるなら、あるいは
Fortran以前を知らないなら)こっちのほうを絶対に歓迎すると思う。Fortranねぇ。
言語体系を調べられるようになっとく? と思い、いちおうネットでマニュアルを
見つけましたよ……。
 (アメリカで僕が前に住んでいた町にNASAの出先機関があり−−知らなかったよ、
田舎町ですよ−−、そこが開発していた! MS-DOSにも移植できそうだった=その時代の
もの)

 プリプロセッサのイメージが沸いてきましたけど……(RatforがFortranのプリプロセッサ。
この本のために開発された=書かれた。そしてこの著作でその言語を使ってプログラム開発
の奥義を語っている)。(注3)

 なお、上の引用部分は、だいたい13パラグラフ(段落)で構成されている「まえがき」
(Preface)の中の2段落。たぶん、残りは元の本とほぼ同じ。
 上のようなことを言ってる部分があるだろうと思って、探し出しました。STから
読み始めて(眺め始めて)しまって(e-text処理を始めてしまって)、ふと、思いついて、
_ST in Pascal_をさっき覗いて、のけぞりました。こっちのほうが、ぜんぜんいい
じゃないか!
 

 詳細は分からないけど、上に続く部分で、標準パスカルの弱点も指摘されているけど、
たぶん、Turbo Pascal, MS Pascal で、克服されているのじゃないかな。macroとか
file inclusionとかlibraryとか。パスカルのmacroって記憶にないけど。

 何しろVzマクロしか知らないものだから、いちいち新鮮です。
 Vzマクロのこの部分は、C的、アセンブラ的、一般の高級言語的、みたいなことが
分かって楽しいです。

 で、どれだけ読みこなせるか分からないけど、内容的には、テキスト処理オタクの僕に
ぴったり! としきさん、この本のこと思い出してくれて、ありがとう!

 あ、2書とも、目次はほぼ同一です。Ratfor開発・解説の章がなくなっている以外は。
 おお、ついにここでは、正規表現も出てくるのか。なくちゃね。Free Pascalには、それ用
ライブラリがあるのを確認ずみです。言語が何であれ、正規表現エンジンなんて書きたく
ないです。読みたくない、が正確。眺めてみたいか?


(注1)べつに誰にも勧めていませんが、翻訳があるということは、どっかの図書館には
あるということです。

(注2)かつて「吉本隆明が理解したければ、日本語を勉強しろ」とかありました。考えて
みれば、外国人の日本文化研究者や日本アニメおたくの方々は、まさしくそれをやっている
わけですが。僕もそうだったんだ。しかしそんなに色々やれないのは自明。

(注3)c.mosさんのソースには、if ... else, break, until, while, repeatがある。それを
vz.incのマクロが展開する。これがプリプロセッサ的作業ですね。マクロ、柔軟ですねぇ。
やはり、自分で自分を書き換えているイメージ。Virtual Machine? 自己書き換えマクロ!


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

(10387) 10425Re: _ST in Pascal_ (1981)  投稿者:としき   2022/11/18(金) 16:31
参照先:http://toshiki.la.coocan.jp/
    10424 番 文太 さんへのコメント    コメント数 1

>  そして、_Software Tools in Pascal_。1981刊。翻訳は出てないのかな?

こっちは読んでいませんが、いまさらFortranでもない、という気持ちはよくわかる。
Fortranはなにがいいって、数学のライブラリが充実していること。もしかしたら、
最新のスパコンにもFortranのコンパイラはあるかもしれない、というくらい。

> (Preface)の中の2段落。たぶん、残りは元の本とほぼ同じ。

ちなみに、私が#10417で一読をお勧めしたのは、Ratfor版の、おそらくIntroduction
の最初の部分に該当しそうな気がしています。Pascal版でも、導入部はほぼ同じだと
思いますが、読み比べていないのでわかりません。
      - No.10425 -    このTreeへ    コメント元:10424 へ [リストへもどる] soft

(10387) 10427Re^2: _ST in Pascal_ (1981)  投稿者:文太   2022/11/18(金) 20:28
    10425 番 としき さんへのコメント    コメント数 2

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

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

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

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


冒頭5パラグラフ。
------------------------------------------------------------------------------
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) とか。
それも壊れて化けたりもして。スペースや改行が入ったりもする。それらをVzマクロ
やsedで掃除しています。

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

 find pattern に同じ。


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

(10387) 10428Re^3: _ST in Pascal_ (1981)  投稿者:としき   2022/11/18(金) 22:11
参照先:http://toshiki.la.coocan.jp/
    10427 番 文太 さんへのコメント

> 冒頭5パラグラフ。

おぉ、やっぱり「100ページのプリントアウト」だの「赤鉛筆でチェック」だの
といったことは書いてあるのですね。

>  ただ、ここまで一般的(抽象的)な問題を解決するツールを僕が開発するとは思えない
> ですけどね。grep/sed/awkの使い方を十分マスターすれば良いような気がする。

今ではそうなんですけどね。
当時、そういったツールがなかった時代に思いを馳せてください。
いわゆる、古典古代、というヤツかな。違うかもしれない。
あまり文系的な用語はわかりませんが。
この本で取り上げられているのは、そういったツールの作り方がメインではあるのです
が、ツールを作るにあたっての考え方を通して、構造化をはじめとするソフトウェアの
構築法というか理念というか哲学というか、トップダウンではなくボトムアップでその
ような考え方を身につける、ということのように、私は捉えました。もちろん、これは
著者側の考えとはずれているかもしれません。
      - No.10428 -    このTreeへ    コメント元:10427 へ [リストへもどる] soft

(10387) 10436Re^3: _ST in Pascal_ (1981)  投稿者:文太   2022/11/28(月) 21:22
    10427 番 文太 さんへのコメント    コメント数 1


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

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行略。うひょひょひょひょ。下品な笑い)

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


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

(10387) 10439Re^4: _ST in Pascal_ (1981)  投稿者:としき   2022/11/30(水) 01:49
参照先:http://toshiki.la.coocan.jp/
    10436 番 文太 さんへのコメント    コメント数 1

う〜む、この返信フォームの直上の関連一覧ツリー、なぜこんなに乱れているのか。
いいかげんkonnoさんには本腰を入れて修正していただきたいところ。

>  地獄の仕事場から息継ぎのため、一瞬だけ、浮上してみます。

私なんか、職場よりプライベートが多忙で。
職場でも、プライベートが気になって落ち着かなかったりして。

>  効率の問題に敏感な読者は、1 つのプログラムで事足りるのに、2 つのプログラム
(中略)
> ことである。(DeepL による翻訳。立派! トーンだけ改変)

ぅぉぉ、きちんと意味の通る訳になっていますね。さすが、最近のAI。
ちなみに、40年前に、ほぼ同様の原文を人間が訳した文章が以下。

 効率の問題に敏感な読者は、プログラムが一つですむところでわざわざ二つに
するのは経済的なのだろうか、と心配かも知れない。その答えは、何が真の費用
であるかによって違ってくる。そしてその真の費用なるものは正しく見積もられ
ていないことの多いものである。「効率」についてうんぬんする人々は、たいて
いの場合主として本番計算に計算機資源がどのくらい使われるか、という点にば
かり着目していて、コンパイルしたり、虫取りしたり、その他のさまざまなやり
そこないをしたりしながら本番計算にそなえるために消費される人間の時間と計
算機の時間を考えに入れていないものである。われわれはこの本では一貫して、
人間の方が機械よりずっと高くつくものであり、その差は将来ますます開くの
だ、という見かたをとっている。だから、一番大切な考慮点は、仕事をかたづけ
るまでに要する人間の側の気苦労を最小にすることだ、ということになる。

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

原文の差異がどうなっているかわかりませんが、業界では、消費というのはそれほど
不自然な言葉ではないと思う。私も、この文脈では、消費という言葉に違和感を感じ
ません。

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

こういう、ごもっとも、という内容がたくさん含まれているから古典なんだ、という
こともあるかもしれない。
私が最初に読んだ時は、どちらかというと、なるほど、という感想を抱いた部分が
多かったですけどね。だって、Fortranをマスターする前、BASICとアセンブラしか
知らなかった時代の私が、仮想言語(と私は捉えた)であるRATFORを使ってアルゴ
リズムを説明する本を読んで、それなりに勉強になったと思えたわけですから。
      - No.10439 -    このTreeへ    コメント元:10436 へ [リストへもどる] soft

(10387) 10441Re^5: _ST in Pascal_ (1981)  投稿者:文太   2022/12/01(木) 16:15
    10439 番 としき さんへのコメント


 原文は、まったく同じでした。

DeepL
「効率」について語る人の多くは、最終的な実行やハンズオフ生産でどれだけの
機械資源が使われるかに主眼を置いており、最終実行の準備のためのコンパイル、
デバッグ、その他の誤ったスタートで

 (「誤ったスタート」でだいたい通じますね。コンピュータって、コンピュータ
に対してやたら強いのですよね、きっと。
 が、"consideration"を訳出しないという判断は、もう人間並みかよ、と思いました)


邦訳書
「効率」についてうんぬんする人々は、たいていの場合主として本番計算に計算機資源が
どのくらい使われるか、という点にばかり着目していて、コンパイルしたり、虫取りしたり、
その他のさまざまなやりそこないをしたりしながら本番計算にそなえるために消費される
人間の時間と計算機の時間を考えに入れていないものである。

 (訳出がどうというより、意味がよく分かる文章だと思います。「ハンズオフ生産」の部分は
よく分からないし、そんなに重要とも思えないから、飛ばす! という判断でしょうか。
アリだと思います。本番計算!)



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.

#DeepL
本書では、一貫して
「人は機械よりもコストが高い」
「その格差は今後ますます広がる」
という見解をとっている。したがって、最も重要なことは、
人が最小限の手間で仕事を成し遂げることである。

#人間(40年前)
われわれはこの本では一貫して、
人間の方が機械よりずっと高くつくものであり、
その差は将来ますます開くのだ、
という見かたをとっている。だから、一番大切な考慮点は、
仕事をかたづけるまでに要する人間の側の気苦労を最小にすることだ、
ということになる。

 やっぱり、僕がいちばんに驚くのは、間接話法を直接話法にすることが、
機械にできた、ということかな。

 「人は機械より…」の部分。原文には、「 」とかないのです。
 しかし、「 」(直接話法)があったほうが、ずっと読みやすい、


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