ＴＴＬでＣＰＵを作ろう！

~~標準ＴＴＬ~~だけ（！）でCPUをつくろう！（組立てキットです！）
(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第５７３回］

●やっぱり納得できません

画面表示の速度について、前回は一旦は納得したつもりだったのですが。
いや、だめだ。
やっぱり、まだ、納得ができません。

そりゃあ、Ｚ８０ＢＡＳＩＣはＣＰＵクロック６ＭＨｚ、８ビットＣＰＵのＺ８０ですから、それなりに時間がかかるのは仕方がありません。
しかし、それにしても、このＰＲＩＮＴ文は余りに遅すぎます。

たとえば、下のＢＡＳＩＣプログラム。

10 A%=0
20 PRINT "a"
30 A%=A%+1
40 IF A%<1000 goto 20

これを実行しますと、なんと１５秒から２０秒もかかってしまいます。
いくらなんでも時間がかかりすぎでしょう。
しかも実行時間が毎回違うってのは、一体どういうこと？

ええ。もちろん今はｃｐｒｉｎｔｆ（）は使っておりません。
基本的に置き換えるべきところはすべてｐｕｔｃ（）に置き換えてしまいました。

それでいてこの始末。
一体全体、なんなのでしょーね。

こうなってきますと、やっぱり、納得がいくまで追求したくなってきてしまいます。

●どうも改行があやしい

実はあれこれやっているうちに気が付いたことがあります。
さきほどのプログラム、それを下のように変更しますと。

10 A%=0
20 PRINT "a";
30 A%=A%+1
40 IF A%<1000 goto 20

途端に実行速度が一気に上がって、２秒ほどで終了してしまいます。
さきほどのプログラムではａを１文字表示するごとに改行が行われるのですが、あとのプログラムでは改行されることなく、間も空けないで、びっしりベタに表示されます。
こんなぐあいです。

あ。
さきほどの最初のプログラムは文字ａだけではなくて、実際には改行コードも送っています。
文字ａのＡＳＣＩＩコードは６１です。
ですから、６１・０Ｄ・０Ａの３バイトがＺ８０ＣＰＵ→ＰＩＣ１８Ｆ１４Ｋ５０→ＵＳＢ（ＨＩＤ）→Ｗｉｎｄｏｗｓパソコンというように送られます。

そこで条件を合わせるために、この画面のプログラムでは改行コードを送る代わりに、３文字ａｂｃを連続して送っています。
3文字×１０００＝３０００文字の送信、画面表示に約２秒程度ですから、まあそんなものか、と思います。
すると、改行コードが加わることで実行速度が１／１０に落ちてしまう、というのは、どういうわけなのでしょう？

その追求の前に、もう少し、基礎を固めておきたいと思います。
まずはＺ８０ＢＡＳＩＣの実行速度を確認しておきたいと思います。
Ｚ８０ＢＡＳＩＣはインタプリタですから、ちょいと実行に時間がかかってしまいます。
それでは一体どのくらい、時間がかかっているのでしょうか？
それは、どうすれば、測定できるのでしょう？

まあ、それを測定するにはいろいろな方法があると思います。
でも、たまたま、Ｚ８０ＣＰＵとＰＩＣ１８Ｆ１４Ｋ５０の間でデータを受け渡しするときの、ＳＴＲＯＢＥ信号とＲＥＡＤＹ／ＢＵＳＹ信号をオシロスコープで観測する、ということをしましたから、それを利用することにいたしましょう。

上（ＣＨ１）はＺ８０ＣＰＵからＰＩＣ１８Ｆ１４Ｋ５０にデータを送るときのＳＴＲＯＢＥ信号です。
ＰＩＣ１８Ｆ１４Ｋ５０からのＲＥＡＤＹ信号は応答が速いせいなのか、ちょっとよく見えません。
ＳＴＲＯＢＥ信号は３文字分が固まっていて、その間隔はだいたい２ｍｓｅｃ程度です。
これが今回のＢＡＳＩＣプログラムの実行速度です。

さきほどのプログラムをもう一度お見せします。

10 A%=0
20 PRINT "abc";
30 A%=A%+1
40 IF A%<1000 goto 20

行番号２０のＰＲＩＮＴ文、３０の計算式、４０のＩＦ～ＧＯＴＯ文までを１回実行するのに約２ｍｓｅｃかかっています。
その１回の実行でＰＩＣ１８Ｆ１４Ｋ５０には３バイトのデータが渡されます。
ＰＩＣ１８Ｆ１４Ｋ５０がホストにＵＳＢ（ＨＩＤ）でデータを送信するのは１ｍｓｅｃ間隔ですが、一度に約６０バイトのデータを送ることができます。

もっとも［第５７０回］で説明しましたように、ホストへのデータの送信は単純ではなくて、ホストからの返信と組にして行われますから、１ｍｓｅｃで約６０バイトを送る、というわけではありません。
しかしそのことを考慮しても、２ｍｓｅｃに３バイトというデータ転送速度はＨＩＤの通信速度に比較して十分ゆっくりした速度ですから、その間にＨＩＤでのデータ送出は済ませてしまうことができます。
ですからＺ８０ＢＡＳＩＣの側の実行時間は、３バイトの送信に約２ｍｓｅｃかかる、と考えることができます。
すると３０００文字の送信には約２秒かかります。

前回Ｃ＋＋で書いた簡単なｐｕｔｃ（）のテストプログラムの実行結果は、０～９９９までの数値の表示に約１００ｍｓｅｃかかりました。
３０００文字には少し足りませんが、まあ大体のところではそんなものだと考えてよいでしょう。

結局、ＢＡＳＩＣの実行時間に約２秒かかって、実際の画面表示のためのｐｕｔｃ（）の実行時間はそれに比べると、ほんのわずかな時間で、ほとんど無視してもよいほどしかかからない、と考えることができますから、あとで実行したほうのＢＡＳＩＣプログラム（改行無し表示）の実行時間が約２秒だった、ということとぴったり一致します。

すると問題は、改行コードの処理、ということになります。

Ｃ＋＋で書いたプログラムｚｂ２ｘは、画面に文字を表示すると同時に、ページモード表示のためのバッファと、ログファイルにもデータを書き込む処理を行います。
上の結果から考えて、その処理時間も無視できるほどのものにしかならない、と考えてよい、と思います。

実は、改行コードがある場合には、そのほかにページモードの処理とスクリーンエディタのためのデータ処理のために、ｐｕｔｃ（）で７９文字分の空白（スペースコード）を、画面に表示する、という処理が行われます。

改行コードがあるときと無いときとで、Ｃ＋＋プログラムでの違いは、そこのところだけです。
それなら、その部分だけを抜き出して、実行してみたら、何かがわかるのでは？

そこで、下のプログラムを作って、実行してみました。

//putc test
//10/8/3 8/4
#include <stdio.h>
#include <conio.h>
#include <time.h>
#include <string.h>
//
void main()
{
	int c,i;
	char wkbf[81];
	clock_t start,end;
	for(i=0;i<79;i++)wkbf[i]=0x20;
	wkbf[i]='\0';
  	start = clock();
	for(c=0;c<1000;c++)
		{
		for(i=0;i<79;i++)putc(wkbf[i],stdout);
		}
	end = clock();
  	printf("%dmsec\n",end-start);
}

さきほどの改行有りのＰＲＩＮＴ文のプログラムでは改行コードの表示を１０００回行っています。
そのうち画面の一番下まで表示が進んで、スクロールされるようになると、１回の改行ごとに、７９文字分のスペースが画面に表示されます。
上のプログラムは、そのスペースを７９文字分表示するところだけを、１０００回実行して、その間の実行時間を表示させるものです。
実行させてみた結果、実行時間は約１３００ｍｓｅｃほどでした。

あれ？
おかしいじゃないの？

普通の文字表示と改行を含む文字表示とでは、この部分があるかないかの違いしかない、はずなのです。
どう考えたって、この部分で１５秒ほどもかかっているはずなのですが…。

んでも、それもおかしい話で、なんたってこのテスト作業に使っているパソコンは、Ｃｅｌｅｒｏｎ１．７ＧＨｚなんですから、この程度のプログラムの実行に１５秒もかかるってのは、そっちの方が信じがたい話になってきてしまいます。

むむ。
こうなったら、もう少し、徹底して追及してみなくては。

/// CR/LF
void vcr()
        {int i,j,x,y;
         char wkbf[81];
         i=cursor/80;cursor=(i+1)*80;
         if(cursor==winend||cursor==Vsize&&winend==0)
                {for(i=0;i<79;i++){vram[i+winend]='\0';wkbf[i]=0x20;}
                 wkbf[i]='\0';cursor=winend;wintop=wintop+80;winend=winend+80;
                 x=wherex();y=wherey();
                 //printf("%s",wkbf);gotoxy(x,y);//need for win2k
                        start=clock();//test
                for(i=0;i<79;i++)putc(wkbf[i],stdout);
                        end=clock();//test
                        total=total+(end-start);//test
                        crcntr=crcntr+1;
                gotoxy(x,y);
                }

実際にＺ８０ＢＡＳＩＣの受けとして使っているｚｂ２ｘプログラムの改行処理の一部です。
そのｐｕｔｃ（）の部分の実行時間を測定するためにｃｌｏｃｋ（）関数を埋め込みました。
そのように準備をしてから、ＢＡＳＩＣプログラムを実行させてみましたところ、下のようになりました。
（ａばかりが１０００個並んでいても仕方がありませんから、途中はカットしてあります）

>time=0msec,crcntr=0
.
    10 PRINT "start"
    20 A%=0:A=0
    30 PRINT "a"
    40 A%=A%+1
    50 IF A%<1000 GOTO 30
    60 PRINT "end"
>time=0msec,crcntr=0
r.
start
a
a
a
a
a
a
a
a
a
a



a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
end

>time=15920msec,crcntr=992

おお。
出た。出ました。
確かに、７９個のスペースを出力しているだけのｐｕｔｃ（）の部分の実行時間がトータルすると約１６秒かかっています。
しかも一緒に実行したカウンタの値は９９２ですから、そのｐｕｔｃ（）がその回数（約１０００回）繰り返し実行されたことに間違いはありません。

でも、でも、でもっ。
それって、どこかおかしくはありません？
だって、同じパソコンで、同じＣ＋＋のプログラムで、同じ処理ルーチンを実行させているのに、一方は１秒ちょっとの実行時間なのに、もう一方は１６秒もかかる、だなんて…。

両者は同じ条件なのに…。

お。お。お。
違いがありました。
わかった。わかりましたよっ。

その部分だけを抜き出して実行したときと、Ｚ８０ＢＡＳＩＣの「受け」として実行したときの違いが！
ほら。
あるじゃありませんか！

そうなのでした。
それしか考えられません。
Ｚ８０ＢＡＳＩＣの実行とともにｐｕｔｃ（）が実行されているために、おそらくＵＳＢ（ＨＩＤ）の受信が影響しているのではないか、と思われます。
ｐｕｔｃ（）の構造がどうなっているのかはわかりませんが、［Ｃｔｒｌ］［Ｃ］を受けて強制終了しますから、キーボードからの［Ｃｔｒｌ］［Ｃ］の入力を見ていることは間違いありません。
私のパソコンのキーボードはＵＳＢではありませんが、それでもおそらくキーボードの入力チェックとＵＳＢ（ＨＩＤ）の信号入力との間になんらかの関係ができてしまうのではないでしょうか。

その証拠に、上のＢＡＳＩＣプログラムを実行中に［Ｃｔｒｌ］キーを押し続けていると、その時のｔｉｍｅは９００ｍｓｅｃほどになってしまうのです！
このときの（［Ｃｔｒｌ］キーを押し続けているときの）、ＢＡＳＩＣプログラムの実行は、２～３秒ほどで終了してしまいます。

う。む。む。
つうことは、ＨＩＤが原因ではあるけれど、いわば、それはぬれぎぬみたいなものであって、ＨＩＤそのものに原因があるのではなくて、ｐｕｔｃ（）やｐｒｉｎｔｆ（）やｃｐｒｉｎｔｆ（）がおそらく［Ｃｔｒｌ］［Ｃ］をチェックするときにキーボードとは関係のないＨＩＤの影響を受けてしまうところに、本当の原因があるのではないか、と思います。

だとすると、これはもう、不可抗力みたいなもので、もうどうしようもないようです。
ともかく、そういう次第で、改行を含むＰＲＩＮＴ文はちょいとばかり時間がかかってしまいます。
まあ、裏ワザ的な対策としまして、大量データの表示などの場合には、［Ｃｔｒｌ］キーを押しっぱなしにしておく、ということに致しましょう。
２０１０．８．４ｕｐｌｏａｄ

前へ
 次へ
 ホームページトップへ戻る