今年もよろしくお願い致します。
のんびり起きてのんびり。
バイクを動かしておこうと思ってちょっとランド坂へ。 新ランドにワゴンのパトカーがいて、そのうしろに乗用車がいて、何? 取り締まり? そして旧ランドから工事中のトンネルが見えているのを発見。 なんと、ここにトンネルができるのか。 知らなかった。 ここから神奈川側に抜けるのかと思いきや、中でカーブして、稲城駅のほうに抜けるのとよみうりランド方面に抜けるのに分岐するらしい。 はぁ。 稲城大橋ユーザーとしては若干微妙な感じが... しかし開通したら旧ランドが本当の意味で旧道になるかもな。 いや、計画では盛土されて廃止されるんだと。 ほう。 なお、よみうりランドは観覧車が動いていたので普通に営業していたようだった。
まぁそれはともかくとして、バイクは今日は FI エラーが発生した。 給油後に 2 回、ドラッグストアで買い物後にも 2 回。 燃料ポンプが動く音はしていた。 いずれもその後は問題なく起動した。 それで、何かのトラブルかと思って調べてみたら、キーシリンダーの接触不良で FI エラーが出る場合があるらしい。 ははーん。 キーシリンダーの接触不良ならとっくに起きている。FI エラーも同じ原因ってことか。 スズキ店に持っていっても芳しくない返事が得られた人がけっこういる模様で、キーシリンダーの交換で有償修理になった人や、交換後も 2 年ほどで再発した人もいそうな感じ。 自分で分解清掃をした人もいるようだが、キーシリンダーには特殊なねじが使われていて分解がやや難しいようだ。 そこで、とりあえず、合わせ目の部分をめがけて KURE CRC 5-56 を吹きかけ、何度か動かしておいた。 これで改善するといいのだが、しないようなら上の隙間のほうからやってみよう。 どうせ交換になるのなら、5-56 で壊してしまっても同じだし、延命できるなら安いものである。
ALU のキャリーフラグはともかく、オーバーフローフラグの出し方がよくわかっていなかったが、何となく考えていたら、わかってきた。 よく言うオーバーフローのチェック方法は、正の数同士を足して負になったか、あるいは、負の数同士を足して正になったか、というやり方だが、それを 16 ビットの演算器でどうするのか? という疑問、実は加算器の最上位ビットの入力 3 つ (足される数、足す数、キャリー) を見ればわかるんだな。
2 の補数表現で 1 ビットの値を、0 か -1 と解釈するとする。 そうすると最上位ビットの足し算は (0 or -1)+(0 or -1)+(0 or 1) となる。 引き算はこれの + が - になる。 答えが 0 か -1 ならオーバーフローしていないということ。 こんなことを思いついたきっかけは、CS:APP という本に出てきた問題で、引数 x が 2 の補数表現の整数の場合に n ビットで表現できるかをチェックする関数を大小比較を使わずに書け、的なものがあって、これを数か月前に解いた時に、x を右シフトして、0 か -1 と一致するか比較する関数として書くとシンプルに書けることに気づいたことだった。
実験コードはこれ。 フラグレジスターの最下位ビット (キャリーフラグ) とオーバーフローフラグの結果をビット 8 とビット 0 に返す関数で、実際の命令の実行結果と比較する。 足し算や引き算の答えに関しては C の普通の演算結果とどうせ一致するので捨ててある。 このプログラムでは上の理屈を元にテーブルを作ったが、これなら論理回路の組み合わせでも簡単に実現できる。
ところで... 減算は 2 の補数を使って加算器で実現できるのはそうなんだが、8088 は加算も減算も同じ時間で行えるので、減算用の回路が入っているのは間違いない。 で、2 の補数は 1 の補数に 1 を加えたものなので、引く数のビットを否定でひっくり返し、さらに 1 を加えて足せばいい。1 を加えるところは、ADC 命令があるように、0 ビット目にキャリーを足せる仕組みになっているので、そこに 1 を入れればいい。 じゃあキャリーを含めた引き算の SBB 命令は? というと、キャリーがあったらさらに 1 を引くという話なので、1 足さなきゃいい、すなわち、入力のキャリーも反転すればいい。 なんと、答えを得る部分についてはそれだけなのだった。
じゃあ減算結果のフラグは、というと、キャリーは 2 の補数の加算結果の否定か。 そしてオーバーフローは 2 の補数の加算と一致するんだな。
と、書いたところで... Overflow flag - Wikipedia を眺めていたら、References のところに詳細な説明テキストへのリンクを発見。 The CARRY flag and OVERFLOW flag in binary arithmetic というテキストの後半 "How the ALU calculates the Overflow Flag" のところにある。 これによれば、別にキャリーを使わずに普通に入力と答えを比較してもいいし (これも 3 入力で求めることになり、結局組み合わせは同じ)、あるいは、最上位ビットに入っていくキャリー (上のプログラムで求めた msb_c) と、最上位ビットから出ていくキャリー (上のプログラムでビット 8 に出した値) の排他的論理和でもいい、と。 ほほー。 言われてみればそうだな... わかったことをまとめて、上のプログラムの 2 関数を書き直せば、以下のようにテーブルすらなくなる:
uint16_t myadc(uint16_t a,uint16_t b,uint16_t c){
uint16_t msb_a=a>>15,msb_b=b>>15,msb_c=(((a&0x7fff)+(b&0x7fff)+c)>>15)&1;
return ((msb_a+msb_b+msb_c)&2?257:0)^msb_c;
}
uint16_t mysbb(uint16_t a,uint16_t b,uint16_t c){
return myadc(a,~b,!c)^256;
}
なお、補助キャリーフラグはビット 3 から出てくるキャリーというだけで、減算を 2 の補数の加算で行った場合に、出てくるキャリーが否定になる点も含めて、全く同じ。
あと、NOT 命令はフラグが変化しないのでちょっとわからないけど、NEG 命令は 0 からの減算と等しいことを以前発見しているので、3 クロックかかる正体はここにありそう。 つまり普通の SUB 命令と同じように 2 入力 ALU に突っ込んで実行していると思う。
そうそう、そうやって NEG 命令が暗黙の 0 を使うわけだけど、おそらく INC 命令と DEC 命令もそれを使っている。 キャリーに 1 を入れた上で、0 を入れた ADC 命令あるいは SBB 命令相当の動作をするのではないか。 その関係で、キャリーフラグが更新されないんじゃないか。 そういう風に考えると、ADD 命令と SUB 命令の時にはキャリーに 0 を入れた上で計算を始めているかも。 キャリーフラグは更新されちゃうから、そんな内部のこと、知りようもないけどな。
さらに言えば、たぶん NOT 命令は減算用に 1 の補数を求める回路から取り出しているのだろうと思う。 それならフラグに関わるような演算はそもそも何もしていないことになるから、フラグが変わらないのも納得だし、まぁそれを言ったら排他的論理和なんかも加算器の一部を流用しているのかも知れないけど。 そうそう、テンポラリーレジスターに残っている値を JMP FAR AX で取り出した時に、残っているのがなぜ第 2 オペランドなのか不思議に思っていたが、減算用に 1 の補数を求める回路は当然第 2 オペランド側に付けることになるし、ひょっとすると ALU 的にはこっちが第 1 なのかもという気もしてきた。
そうだ、他に未定義のフラグはシフト命令にもあるんだった。AF が常に未定義、OF は複数ビットシフトで未定義。 調べてみないとだな。 なおシフト命令のオーバーフローフラグは最上位ビットが変化したかどうかを表す。 つまり... 左シフトに関しては、同じ値の足し算と同じ結果ということになる。 実行時間が短いから、足し算はしていないはずだけど。
似たような数字がいっぱいで書き間違いがあるかもw とりあえず見た感じ、AF がセットされるのは左シフトのみっぽい。 ビット 3 がセットされていた場合の左シフトで AF がセットされている。 左シフトについては回路規模削減か何かの理由で加算回路の一部を流用しているのかも知れない。 なおローテートはどういうわけか AF SF ZF PF を変更しない。
複数ビットシフト、ここでは CL=4 である。 とにかく何をやっても一定なのが未定義の全ビットがセットされるシフト (?) で、例によって AF がセットされるのは左シフトのみのようだ。 で、OF のほうはというと、順当に 1 ビットシフトを繰り返した時と同じ結果のように見える... よね? 単に最後のシフトあるいはローテートで最上位ビットが変化したかどうか、が反映されているだけに見える。 さぁて... もうひとつ、CL=0 を試しておく必要があった。
これは単にフラグは全く変化しないと見てよさそう。
久しぶりに関東にいる三が日、暇なので、兄者と「ツインリンクもてぎ "New Year Celebration" 花火と音の祭典」を見に行った。 もてぎの正月花火は 2007 年以来の 2 回目。 水戸北スマート IC が復活しており、適当に記憶を頼りに到着。 事前に電話で確認したところ株主優待は使えるらしいとのことだったので、使うにはちょうどいい機会だとは思いつつ、本当に使えるのか半信半疑で持っていったら本当に使えた。 当日観覧券 2800 円×2 人分と当日駐車券 2100 円がなんと無料! レースやイベントがない普段の日の入場料金は 1 人 1200 円、駐車料金は 1000 円なので、ずいぶん得をした気分になれる。 ただし、そんな優待の代わりに配当金を増やしてくれればいいじゃんという説には触れないでおくものとする。
2007 年に行った時のことなんかすっかり忘れてしまっていた。 あの時はこんなににぎやかだったかな、と思うくらい、人が多い。 露店も結構来ている感じで、レースの時よりエリアが狭いせいかレース開催日のような人混みである。(なおこの前は予選日だったので、レース開催日のもてぎに来たことはない。) 花火の観覧席は打ち上げ場所に近いほうが自由席。 なんでかと言えば、近すぎて見上げる形になってしまうから。 近さ的には多摩川競艇場の花火に近い感じだが、障害物が全くない上にけっこう大きな玉も上がるので迫力は抜群。 並んで上がるとカメラのレンズにおさまりきらないほど。 当然粉も降ってくるw
帰りはつくばに寄って久しぶりにとん Q、本店は相変わらず待ち時間が長かったのでイーアスのほうで食べた。 帰りは谷田部からスーッと。
花火の写真は撮ってみたが、後日確認することにする。
142 円/l。 燃費計算 21.4km/l。 燃費表示 19.4km/l。
ちょっと、満タンをいい加減にしたので燃料少なめだと思う。 高そうな気がしたせいでもあるが、つくばも神奈川もみんなもっと高かった。
今日も良い天気。
レンタルカート。 飯能。3 回乗ってベストタイムは 33.823 秒。7 コーナーの走り方を矯正するために、6 コーナー付近からアクセルオフにしてみたところ、意外とタイムが落ちない。 ふんふん。 こうしてみると今までだいぶ突っ込みすぎていたかなという気がする。
なお、まだ三が日だというのに、飯能は結構人が多くて、待ち時間が長くて、やや遅い人達と一緒のグループの時もあって、自分より 0.5 秒前後遅そうな人に追いついた時には、抜けなかった。 登り勾配でスピードが足りない... 9 コーナーでイン側取れたらよかったけど、後ろ見ないで切り込んでくる感じだったのでギリギリで引いて、接触は避けた。
バイクで飯能まで行ったので、早めに帰ろうと思っていたけど人が多かったので、結局 17 時前ぐらいになってしまった。 寒いだけでなく、凍結が心配なので帰宅は早いに越したことはない。 まぁ、結果としては大丈夫だった。
バイクのキーシリンダー接触不良トラブルはとりあえず再発せず。5-56 がきいたか、キーを何度も動かしたのがきいたかはわからない。
8086 ファミリ・ハンドブックに載っている命令実行シーケンスの例では、eb の無条件ジャンプでプリフェッチした後、次のプリフェッチの T2 のタイミングで最初の命令がキューから取り出されている。...T1〜T4 のバスのステートがあり、T4 の終わりのタイミング、クロックの立ち下がりのところで最初のワードがキューに入り、その次の T2 の終わりのタイミングで最初のバイトがキューから取り出される形。 その後キューが空になってフェッチ待ちになるところも、同様に、T4 で入ってからその次の T2 の終わりで取り出されている。 フーン。
で、最初の疑問は MOV AX,即値の 3 バイト命令で、なぜか最初のバイトを取り出してから、次のバイトを取り出すまでに 1 クロックあいていることだった。 だけど冷静に考えたらこれ 4 クロックの命令だ。 だから実は 1 クロックあいてから 2 バイト取り出すと考えるとそこまで変ではないのかも知れない。 例においても最後のバイトを取り出したところまでで MOV 命令は完了していることになっている。 ま、実際には最後のレジスターへの転送は次の命令のところに重なっているのかも知れないけど、その辺の詳細まではわからない。
あと、PUSH 命令でメモリーに書き込むところが、T3 までで PUSH 命令は終わっていて、メモリー書き込みの T4 では次の命令を取り込んでいる。 これもまぁ、そういうものなんだと言われればまぁ、そうなのかな。
それと、ADD SI,即値の 4 バイト命令 4 クロックの謎。4 バイト目をキューから取り出すのと同時に計算が済んでレジスターに反映されるなどというミラクルがあるわけがない。4 バイト目を取り出してテンポラリーレジスターに入れるくらいが関の山。ALU は設定済みだろうから、入力が入れば適切な計算結果が得られ、次のクロックでレジスターに反映できるだろう。 アレ? そうすると 5 クロック目があるのかな? 次の命令の 1 バイト目を取り出す時に実は前の命令の結果を反映している?
さてさて。 これに沿って考えて cwtd を MOV CS 実験でちょっと試していた。
この実験プログラムは実験コードへのジャンプは CALL 命令で行っている。eb00 (jmp .+2) を入れるか入れないかで、後ろに cwtd を 4 個並べるか 3 個並べるかの違いが現れている。 上の例から言えば CALL 命令は T2 とは違ったところから始まっていると考えればいいのか。eb00 は例と同じジャンプ命令なので、そっちは T2 から始まると見ていいと思う。 しかし、cwtd が 5 クロックだと 3 命令では 15 クロックにしかならない。2 が出るためには、MOV CS の完了前時点でその次の 1 バイトまではフェッチが終わっていないと変とすると、どう考えても、そうはならないんだよなぁ... まさか cwtd が 6 クロックなのだろうか... いやいや...
8 クロック (であろう) 命令を使用してのこの実験。T2 から始まっているなら、いい具合に次も T2 から始まるわけ。 計算上は 3737 が終わったところでキューには 3 バイトで次の 1 バイトのフェッチが T2 ってところ。 そこで MOV CS (2 バイト 2 クロック) をやれば、キューが 1 バイトになり、いい感じかな?
そうだ、キューが満タンになったケースも本の例に載っているが、キューが減り始めてからだいぶ経ってからプリフェッチが再開されるのも気になる。 バスはアイドル状態 Ti になるとされているが、キューが 2 バイトあいた次に Ti が 1 回あって、さらにその次の Ti で命令フェッチのシグナルが出て、その次に T1 から始まる感じ。8088 だとキューはバイト単位の 4 つだが、満タン状態で次の命令に移ると、その次のサイクルであいたな、って気づいて、さらにその次のサイクルで準備段階、さらにその次で T1 ってことだから、例えば、もし MOV CS 実験で満タン状態で MOV CS を実行した場合、2 バイト 2 クロックで MOV CS が完了し、その間に次のフェッチはまだ開始すらしておらず、いや待って。 それだと 2 が出そうだが、MUL 命令あたりで実験すれば 3 って出るぞ? あれ?
やっぱりミラクルがあるのだろうか。MOV CS にしたって、2 バイト 2 クロックだけど、反映が実は 3 クロック目に行われているみたいな。 それで、プリフェッチのアドレスが、T1 よりもさらにひとつ前のクロックで確定するのであれば... そうであれば、確かに MUL 命令の実験で 3 が出るのも説明できそうだけど、3737 が 2 になるのが変か? わからん。
またチーズを調達しにコストコへ。 バイクで行ったが例の接触不良も再発せず順調だった。
2005 年のテレビドラマ『女王の教室』、TVer で続きの 9 話が出ていた。 当時の MacBook, いや、PowerBook だな、2005 年だもん。 当時の iBook じゃなくて、PowerBook G4 のほうだな。 まぁ、そこだけなら見た目は今でもちょっと分厚いくらいでそんなに違和感ない。Mac OS X の画面に少し懐かしさはあるが、今の若者が見てもそんなに古さは感じないのではないか。 それより、光学メディアだ。 バックアップ (と言ってはいないが、実際バックアップだろう) はここにあると言って見せたのが、CD-R か DVD-R かはわからないけど光学メディアなのだ。 あぁ。 フロッピーディスクや光磁気ディスクじゃないだけマシだけど、なんか急に時代を感じるシーンになってしまう。2005 年はまだ、PowerBook に光学ドライブがついていたし、USB メモリーはそこまで普及していなかったかな。
Hg-Git という Mercurial のプラグインを使ってみたんだけど、とりあえず枝分かれのないシンプルな Mercurial repository を Git 化するのは、これを使うと簡単にできることがわかった。 説明を読んだ時は Git repository を Mercurial で扱うというのが主な使い方だと思ったけど、push もできるので、空の Git repository に push してしまえば、Git 化もできるというわけ。 つまり mq どっぷりの自分のある意味古くさい使い方もそのままに、いつの間にか push 先は Git なんてことも可能に... いや、待った、アレだ。 自分の mq の使い方はひどくて、作業途中のバックアップ用に時々 push -f しているのがあるんだった。 それは Mercurial が無名の複数 heads を扱えるからで、push -f するたびに送信先で head が増えていく。Git ではこの技は使えない、いちいち名前をつけなければならない。 まぁ、公開用としてはそういうことはしないからいいと思う。 でも、コピーやリネームの情報は消える。Git には残しようがないのだから仕方がない話だけど。
MOV CS 実験で POP CS 実験をしてみた。
53 c745de0f43 eb00
これを頭に付ければ POP CS になるという仕掛け、いろいろ試したけど 2〜4 しか出なかった。 フーン。 ま、いいや。MOV CS で 2 バイト命令を試そう。
ウーン。8d00 は 9 クロックのはずで 8d01 は 10 クロックのはず。 確かに 8d01 のほうが早くプリフェッチキューが伸びることははっきり見えている。 問題は 8d00 の繰り返しで 2 と 3 が交互になる件と、8d01 の繰り返しで一度は 3 になるものの、その後 2 に減ってそのまま伸びない件。 何かがハマる感じ、たぶんキューが満タンになるところが関係していると考えられる。
例の本の図を信じて、eb00 の後はプリフェッチが T2 から始まっているとする。 最初から 2 バイト命令なので、最初は足りない。 そうすると T4 が済むまで 2 バイト目はキューに入っていなくて、さらに、図を信じれば次の T2 のタイミングでやっと 2 バイト目が処理されると考えられる。 そうすると 8d00 の次の命令の時にはキューにはもう 2 バイト入っていて、バスサイクルはそのさらに次のバイトの T2 になっている。8d01 と見比べると、MOV CS の時に 2 バイト入って T2 だと 1 が出て、2 バイト入って T3 だと 2 が出るということか? 8d00 8d00 の場合 2 つ目はプリフェッチ待ちなしに 9 クロックになるはず。T2 から始まって 2 バイト入って T3 になり、2 と出る。 確かに整合性はあるかな? そう考えて見ていくと、3 バイト入って T2 までは 2 と出る。8d01 の場合だと最初の 8d01 完了時点で 2 バイト入って T3 になり、8d01 8d01 では 3 バイト入って T1, 8d01 8d01 8d01 で 3 バイト入って T3 で、それで 3 と出るからやはり整合性はありそう。
MOV CS が 2 バイト 2 クロックのはずというところは大丈夫か。3 バイト入って T3 で MOV CS を開始した場合、MOV CS と INC がひとつキューにあって、すぐ次の T4 でもうひとつの INC はキューに入る。T3 で命令取り込みで 1 バイト削るからおそらく T4 で続けて次のフェッチが開始されて、それが %cs の変更前、まぁ、なるほど、変ではなさそう。
さて繰り返しの件は何なのか。3 バイト入って T3 から 8d00 を実行すると、次は 3 バイト入って T4 か。 その時に 2 が出るというのか。 そして、さらに続けて 8d00 を実行した場合、その 1 クロック目、T4 で一度満タンになったキューが、2 クロック目では空いていることが発覚し、例の図を信じれば、4 クロック目にまた T1 からスタートすることになる。 とすると次の命令で 3 バイト入って T3 になるから、また 3 になる。 おや? これなら整合性は保てているか。
8d01 のほうはどうだろう。3 バイト入って T3 から 8d01 を実行すると、ちょうどキューが満タンになる T4 の次のサイクルが次の命令、それだと 2 が出る? 本当か? んで続けて 8d01 だと、やはり 4 クロック目に T1 からスタートし、次の命令で 3 バイト入って T4 だろうな。 さっきの 8d00 の件から言えばそれで 2 は出るのかもな。 そこからはさっきの 8d00 の件と同様のサイクルで毎回 3 バイト入って T4 になってしまい、伸びないということか。
問題は満タンになった直後が次の命令だと 2 になるのかどうか。MUL 命令では 3 になるのだから、なんかおかしい気もする。
と疑問は残りつつまぁまぁいい感じかと満足していたのに変なのを見つけてしまった。
なぜだ... なぜなんだ... なんもわからん...
この前の。
こんな感じで広角レンズ無しのカメラにはなかなか厳しい近さであったw
8086/8088 絡みの資料を見ていると、HOLD 信号と HLDA 信号というのがあって、DMA が使うものらしい。 外部から HOLD 信号を入れることで、CPU にバスを明け渡せと指示する。CPU はちょうどいいところでバスを明け渡し HLDA 信号で acknowledge する。
で、疑問に思ったのは、CPU の入出力アクセスに時間が掛かる場合は READY 信号を使って CPU を待たせることができるのだから、HOLD 信号なんて必要ないのでは、と。 そもそも、アドレスとデータでピンを共有しているので、それを分離するための回路が別に必要で、アドレスとデータはラッチされているはずだし、メモリーやデバイスが応答するまで READY 信号で引き延ばせるのだから、DMA 転送の間はそれで引き延ばせばいいのでは、と。 なんなら DMA と CPU で違うメモリーモジュールやデバイスへのアクセスをするなら、待たせなくてもいいんだから、性能も稼げる。
というふうに思っていたら、それをバスマスターって言うんだな。 ははーん。 どうやっても、アドレスをデコードしてメモリーに入力して、というような回路は最低でも必要になるが、読み書きの方向を示す信号やらクロックやらは共通でもいい。 だから、シンプルに 1 本のバスにすべてのメモリーやデバイスをぶら下げておいて、基本的に CPU が使うが DMA 転送したい時だけ HOLD 信号で CPU に手放させる、というのが、昔の PC でフロッピーディスクなどのアクセスに使われていた DMA 転送だったんだ。 やつは確か 1 バイトか 2 バイト単位の転送だったので、ちょろっとバスを借りて転送してすぐ返す、というのの繰り返しだったのだろう。 フロッピーディスクは確か、32KiB/s ぐらいの転送スピードだったかな。1 バイト単位でも 1 秒あたり 3 万回ほどバスを借りればいいだけだから、ほんの 5MHz 程度で動く昔の PC でも、CPU が動くにはじゅうぶん余裕があったのだろう。 いや、でも確か、フロッピーディスクの I/O って CPU で (PIO で) やると全力で読み取りとか書き込みとかだったような気がするぞ? アレってコントローラーが READY 信号で待たせていた? DMA の場合はどうなっていたんだっけな。
なんでそんな簡単なことを知らないかと言えば JX には DMA がついていなかったからさ... (言い訳)
POP CS で、どうせ 2〜4 しか出ないなら INC 入れる意味ないかなと以下のようにした。
53 c745de0f90 eb00
これを省略して [] としておくことにして、MOV CS の場合と比べてみる。
MOV CS の時とまったく傾向が違って、変な繰り返しも起きない。
うん。 やっぱりわからん。
きのうの、8d00 37 が 3 になる件がどうしても引っ掛かる。37 は 1 だし、3737 は 2 だし、373737 で 3 なのに、8d00 37 で 3 というのはどういうわけなのか。 いろいろ、タイミングがズレているのかもと考えてみたけど、ズレじゃ説明できないんだよな。 確かに、8d00 の時にプリフェッチが間に合っていなくて待ちが入るのはそうだけど、8d00 で 1 なのに 8d00 37 で 3 だもんな。 訳がわからない。
特に何もしないうちに冬休み最終日。 こんなに何もしなかったの、2010 年以来じゃないかな。 その 2010 年は Wii を買って、ゲームを買ってとお金を使ったようだが、この年末年始はレンタルカートくらいしか使っていない。
ホンダドリーム店に行って、大型二輪のレンタルバイクと試乗車について話を聞いてみた。 試乗車はアフリカツイン、でけぇなおい。 足つきはそんなに悪くないんですよというので、試しにまたがらせてもらったところ、確かにそんなに悪くはないが、やはりシートは低いとは言えない。 ちょっと細身に作ってあるせいみたい。 レンタルでは VFR だか何とか言うのと NC と、CB があって、どれが人気というよりはまんべんなく来るという。 確かに大型二輪はあんまりレンタルできる店ないからな。 このへんだとハーレー系の店とホンダと、あとは 2 りんかんだが (近隣にこれだけそろっているのは割と恵まれているほう)、そっちにはホンダの大型二輪はないみたいで。VFR は見た感じ結構前傾姿勢なので、レンタル 4 時間はつらそうな気がする。NC はオートマチック (DCT) で風防付きのモデルで、まずこれは乗ってみたい気がする。 車重も教習車と大きくは変わらないし、エンジンは CB400SF よりも最高出力が低いが、最高出力・最大トルクともに低めの回転数で出るようになっていて、個人的には公道で乗っても自分の好みに近いはずと思っている。 あと、CB1300? はだいぶ重そうだし気が引けるが、CB1100 は少し小柄で、乗れそうな感じがした。 スペック見ると CB1300 のほうが全幅は小さいな。 でも車重はやはり CB1100 のほうが軽い。 なお、レンタルは事前に予約をしてくれとのこと。 その日までにきちんと整備をしてお貸ししますと。 ほう。2 りんかんで普通二輪は何度か借りたけど、一度も予約したこと無かったなw
テレビドラマ『女王の教室』、最終回。 最終回でもエンディングはいつも通りのダンスと EXILE の EXIT。 久しぶりに見たけど、この「鬼教師」は、口は悪いが児童の自主的な発言を遮らないんだよな。 一通り最後まで聞き、その上できついことを言う。 まぁ、罰として掃除しろとか立っとけとか、問題の多い指導法ではあった。 反対に笑顔で言っていることも穏やかなのになぜだか厳しい教師というのもいるというのは、大学で知ったこと。
テレビドラマ『弁護士のくず』、9 話。 これも久しぶりに見たけど、原作と設定違うのに割とよくできているんだよな。 追憶の映画のパンフレットのところ、ぼかし入っていたな。1973 年の映画の本物だったか? この前の『結婚できない男』も、金田裕之の顔写真がきれいに消されていたようだが、こっちはその役を演じていた高知東生が薬物所持で執行猶予になったのがきっかけらしい。
99 (cwtd) の繰り返しを試す。 面倒なので x 数で省略しているがテストプログラムはそんな形式に対応していないので展開して実行した。
これもやはり 2 と 3 を行き来するんだな。LEA 命令の 2 バイト 9 クロックと似ているのでやっぱり 5 クロックなんだな、きっと。 そして最初のところはジャンプか CALL かで何かがひとつ分違う感じだな。 ふーん。
仕事始め。
松屋のビーフシチュー定食、ちとしょっぱい気もするが肉は軟らかくておいしかった。
テレビドラマ『弁護士のくず』、「またやるからみてね〜」なんつって、2 も作りたそうな最終回だったけど、これ作者の裁判沙汰もあってか続編なかったんだよな。 まぁ裁判のほうは結局は作者勝訴なので別にやってもよかったんだろうけど、時期的には裁判以外にリーマンショックその他の影響もあったのかも知れない。 あとこうして再放送 (っていうのかな) を見るとドコモダケが山盛り登場しているのはちょっと違和感あるな。 間違いなく当時のスポンサーが NTT ドコモだったんだろうけど、13 年も前のスポンサーなんてわかんないもんな。 まぁ何も知らなければかわいいぬいぐるみ程度でいいのかも知れないけど。 それと、パロディも時事ネタになってしまうな。 最終回だけでも、「逃げる場所はありませんよ!」(もろ時期も曜日も同じで他局でやっていたテレビドラマ『7 人の女弁護士』のネタらしい)、みのもんたの「ズバッ」(『みのもんたの朝ズバッ!』)、など、他番組のパロディが入っているが、どちらも知らなければわからないやつ、というか前者は知らなかった。
プリフェッチキューの動きがあまりにもわからないので、5 クロックのはずの 99 と 3 クロックのはずの 90 を並べると MOV CS 後の実行命令数がどういうふうに変化するかを見てみようと思った。 まずは簡単なテスト。
90 だけで見るのはちょっと 99x5 や 99x4 のところを見ると難しさがありそう。99 を基本に見るのがよさそうだな。
8d00 99... のパターンで 4 つまで 2 が続くのが気になるが、CALL 命令で入った時に 1 が 3 つ続くのと似た話だろうか? それ以外はうまい具合に 1 ずつズレていっていて悪くない。 さて...
待って! まさかの 24 個で 1 周! ここまで手入力で試していたけど、絶対ミスる! 自動化しよう。
c7064101ebbd c7043939 8006800002 7902 cd20
先月末のテストプログラムの入力の頭にこれを付ければ、99 の繰り返しを自動的に試せる。 これを [] として、例えばだな...
あれ? 8d00 37 のケースが上と違うじゃないか。 どうなっているんだ? と思っていろいろ試したのが下のやつで、eb00 (JMP 命令) を挟んでも何かがリセットされていない感じだな。 プリフェッチキューのせいじゃないのか? でも MUL 命令を挟むと戻るわけか。8d00 37 はこれでも 24 個で 1 周する繰り返しのようだ。8d01 37 は 1 周がわからん。
こっちは素直だな。 そういえば先月も別のクロック数推定で変なのあったから試してみる。
ウーン。 予想に反してこれも素直だな。 しかし何かなこれ、まるで循環小数を見ているかのようで。
暖かくなるという予報もあったが寒い日。
ランチのカレー (激辛) がいつもより辛い気がした。 いつもと言っても前回行ったのが 11 月だけど。
カルロスゴーンの会見、自分のやったことを正当化するのはまぁそうだろうなと思ったけど、罪はともかくとして、日本の人質司法の批判についてはまったくもってその通りで、先月逮捕された国会議員もまったく同じ流れで意味不明な長期勾留だし、漏れてはならない情報の捜査機関からの漏洩もされて世論の印象操作がされているし、おまけにカルロスゴーンは釈放時に家族にすら会えない謎な制約を課されたままきていて、そればかりは日本の司法がクソという他ない。2007 年の映画『それでもボクはやってない』でもそういう部分が描かれていたが、未だに取り調べの可視化も義務化されていないし、取り調べに弁護士の同席もないし、取り調べる側が創造したストーリーに基づいて自白を迫られるという、クソな部分はそのままなんだなということを再確認することになった。 なぜか日本の捜査機関は間違いを絶対に認めないまま突き進む。 あの記憶に新しい、ミュージシャンのお茶から薬物だってそうだった。 間違いだと気づいたらさっさと釈放すりゃいいのに、めいっぱい勾留するわけだ。 その部分は間違いなく見直されなければならないし、他の先進国の人々から見れば、朝鮮民主主義人民共和国で逮捕された人が隙を見て逃げ出したというのとたいして変わらない見方になりそうだと思う。
5 クロック命令 99 の代わりに 4 クロック命令 27 を並べる実験。
c7064101ebbd c7043237 8006800002 7902 cd20
1 バイト読み取りも 4 クロックだとすれば、普通なら MOV CS 後に実行される INC 命令の数は変わらないのだが...
繰り返しが長くても 16 個になったか? きのうの 24 個に比べればまだ納得できそうな数字である。 とにかく LEA 命令と AAA 命令の組み合わせがポイントのよう。 やはりジャンプ直後でも影響が残っている様子で、MUL 命令を使えば影響は残らない様子も確認できる。
さて、このへんで少し入力をミスって、フリーズしたので Portfolio をリセットしたら、フルリセットになってすべて初期化されてしまったw ドライブの中身まで普通にアクセスできる RAM に置かれている時点で、いつでも壊すおそれはあったのだが、ついにやらかした。 11 月に書いたプログラムを com2txt で変換したテキストを入力するところからやり直しだ (ノ∀`)
プログラムを打ち直したところで... 同じ 4 クロックの、9e SAHF 命令にしてみよう。
c7064101ebbd c7043945 8006800002 7902 cd20
これに上の組み合わせでは結果は変わらなかった。 もうひとつ、9f LAHF 命令も試したところ、結果が違った。
c7064101ebbd c7043946 8006800002 7902 cd20
あれ...? LAHF 命令も 4 クロックのはずだけど...?
違うのか?
こうして見比べた感じでは 2 クロックか。 ふうん。 ...じゃねぇよ、どの資料にも 4 クロックって載っていたよ!
日本の都市部の鉄道はダイヤが正確で、みたいな話はよくあるけど、その正確さには間違いなく差がある。 路線によっては 2, 3 分の遅れでも遅れていますと案内が入るらしい。 らしいというか、つくばエクスプレスなんかほんの 1 分くらいの遅れをアナウンスしていた記憶がある。 が、JR 東日本の中央線快速なんかは毎日のように遅れている。5 分くらいの遅れはいつものことで、自動放送で「ただいま約○○分遅れになっております」と流れていても駅員や車掌のアナウンスは何もないというのも珍しくはない。 なお 5 分未満の遅れだとその自動放送すらない。 逆にめちゃくちゃ遅れてしまった時には「大幅に遅れております」みたいな謎な自動放送が流れることもある。
と、感覚で言っても伝わらないが、具体的なデータがある:
東京圏「遅れが多い路線」ワースト10 通勤ダイヤを乱す“あの理由” | 文春オンライン
2016 年度のデータだが、トップが中央総武緩行線、3 位が中央線快速となっている。 やっぱりね。
そんな感じで年明け早々毎日列車が遅れているw 今日はダイヤが乱れていたせいか、珍しく押し込み係も見かけた。 そうそう、「少しでもすいているドアからご乗車ください」などという駅員や車掌のアナウンスが聞こえる時というのは、都会の列車に慣れていないと、どうみてもどのドアも入れそうにない感じにしか見えない。 それが、少し慣れてくると、ドア付近の車内の床がどのくらい見えているかを見て、あっ、まだここなら入れるな、みたいになってくる。 慣れまくっている風な人は車内に片足突っ込んでそれで発車を待ち、ドアが閉まる時にぐいっと車内に吸い込まれる。 あれはまねできない...
きのうの続き。
c7064101ebbd c7043237 8006800002 7902 cd20
ウーン。
あっ、あれ? ジャンプの前が AAD 命令だと起きないの? えぇ? もう少し確認。
あぁ、そうか。37 AAA 命令は 8 クロックとされていて、資料によっては 4 クロックなんだけど、これ、もしかしてアキュームレーターの中身によって実行時間が違うのか! LEA 命令の足し算は {BX,BP}+{SI,DI} の組み合わせなので、このテストコードではどうしてもコード列の長さの影響が現れてしまうんだ。 自動的に伸ばす実験で、自動的に長さが伸びて値が変化していたんだ。 ははー。 これは見落としていた。 っていうか、だから、またしても資料がおかしいという話でもあるんだけど、無駄に難しく考えてしまっていた。
いやいや、それなら d50a eb00 8d00 37 はどう説明できるか?
! で長さを合わせることで %si の内容を一致させ、ジャンプ命令も入れているのに、こんなに差が付く。AAD 命令の前に XOR 命令を入れることで、こ、ああー、フラグ、AF か!?
どうやらそういうことっぽいな! AAA 命令は、AL の下位 4 ビットが 9 を超えているか AF がセットされている時に、AL と AH に足し算をして (80286 以降は AX に足し算をして)、そうでなければ足し算をしない命令なので、確かに実行時間が違っていても不思議はないけれども、なるほどね。AAD 命令の AF が undefined なのもあって余計に混乱した。AF がセットされちゃえば、AAA 命令は常に足し算をすることになるので、それで遅いってことね。
あれ? いやむしろ足したほうが速い? これ足すと AF セットされるので続けてやるとずっと足し続けることになる。 ということはシフト命令でキュー埋めてからやればいいか。
ウーン。4 クロックより速いわけではないのか?
そうだな、4 クロックより遅そう。
うん、訳がわからなくなってきた。 まぁでも、そういうことみたいなので、土曜日の疑問のひとつはとにかく、アキュームレーターの中身で説明ができそうなので、それを頭に入れつつ次に進めよう。
晴天。
高田馬場駅の地下鉄と JR 線の乗り換えって、けっこう遠いんだな。 初めて知った。
きのうの 37 AAA 命令、足した場合が 8 クロックで足さない場合が 9 クロックか? 先日の LEA 命令の推定を使って検証しよう。
2400 は and $0,%al で、AF をクリアするとともに %al の下位 4 ビットを 9 以下にする。040f は add $0xf,%al で AF をセットするか %al の下位 4 ビットを 9 より大きくする。 やっぱり、2400 のほうが 1 クロック長いように見える。 合っている気がする。 ただし LEA 命令 7 つ並べた場合についてはちょっと違うかも。 たぶんその場合は AAA 命令の実行を始めた時点で一時的にキューがいっぱいになって、その後の取り込みが遅れていると思われる。 もう少し検証できることがありそう。
のんびり寝た日。
AAA 命令が 8086/8088 でなんで 8 クロック (9 クロック?) なんだろうと考えていたら、むしろ DAA 命令が 4 クロックなのなんでだろうという方向に進んでしまった。 そして DAA 命令のオペレーションをインテルのマニュアルで確認していたら、新旧での違いを見つけた。 というか、新しいほう、書き直しをミスったみたいで、無意味な行が残っている。 無意味な行を消して新しいほうを雑に JavaScript 風に書くとこんな感じだ:
function daa(old_AL,old_CF,old_AF){
var AL=old_AL,CF,AF;
if((AL&0xf)>9||old_AF){AL+=6;AF=1;}else{AF=0;}
if((old_AL&0xff)>0x99||old_CF){AL+=0x60;CF=1;}else{CF=0;}
return [AL,CF,AF];
}
で、古いやつ... 2001 年の日本語版のソフトウェア・デベロッパーズ・マニュアルのを書くと、以下のような感じ:
function daa(AL,CF,AF){
if((AL&0xf)>9||AF){if((AL&0xff)>0xf9)CF=1;AL+=6;AF=1;}else{AF=0;}
if((AL&0xf0)>0x90||CF){AL+=0x60;CF=1;}else{CF=0;}
return [AL,CF,AF];
}
さて、両者は同じなのか? 考えてみた。 自分は頭がよくないので、なんとなく同じような気がするがうまく説明できない。 そこで、上のプログラムを変形させていくのがよさそうだ。 新しいものを古いほうに近づけていく。 まず、old_* がいらなくなるように一度 if 文を展開する。
function daa(AL,CF,AF){
if((AL&0xf)>9||AF){
if((AL&0xff)>0x99||CF){
AL+=6;AF=1;
AL+=0x60;CF=1;
}else{
AL+=6;AF=1;
CF=0;
}
}else{
AF=0;
if((AL&0xff)>0x99||CF){AL+=0x60;CF=1;}else{CF=0;}
}
return [AL,CF,AF];
}
で、if((AL&0xf)>9||AF) の {} の中を整理していく。
//AL+=6;AF=1;を外に出す
AL+=6;AF=1;
if(((AL-6)&0xff)>0x99||CF){AL+=0x60;CF=1;}else{CF=0;}
//AL-6の-6を右辺に出す。桁あふれに注意する。
AL+=6;AF=1;
if((AL&0xff)>0x9f||(AL&0xff)<6||CF){AL+=0x60;CF=1;}else{CF=0;}
//(AL&0xff)>0x9fは(AL&0xf0)>0x90と等しい
//CFを先に書き換えることで(AL&0xff)<6をなくす
if((AL&0xff)>0xf9)CF=1;AL+=6;AF=1;
if((AL&0xf0)>0x90||CF){AL+=0x60;CF=1;}else{CF=0;}
これで半分は同じになった。 あとは if((AL&0xf)>9||AF) の else のほうだが、こっちは (AL&0xf)<=9 であることが確定しているため、(AL&0xff)>0x99 は (AL&0xff)>0x9f と読み替えることができる。 すると上と同じように (AL&0xf0)>0x90 に読み替えられるので、CF を扱う部分が同じなり、それを外に出してまとめれば、同じ内容を導くことができた。
おそらくこれは本当にプロセッサ内で行われているオペレーションが変更されたんだと思う。 まぁ誰も DAA 命令なんて今時使っていないだろうから放置でもよかったんじゃないかと思うんだけど、まじめにマニュアルを書き換えて、ミスって変な CF の代入文が残っちゃったんだろうな。
ちなみに、直接関係はないけど、AAA 命令のオペレーションは、古いマニュアルでは AL と AH を別々に足すようになっている。 これは 8086/8088 は確かにそういう動作をしていたのだが、80286 以降は AX に対して足し算するようになった、ということが「80x86/80x87 ファミリー・テクニカルハンドブック」に書かれている。 まぁ、この本もしれっと間違ったことが書かれているところもあるので (SETALC 命令についてもこの本は 80286 以降としていたが実際はもっと前からあった)、80286 以降が正しいのかどうかはわからないけど、少なくとも 1993 年出版のこの本より遙かに新しい 2001 年のソフトウェア・デベロッパーズ・マニュアルには、新しいオペレーションが載っているべきだったとは思う。
で、DAA 命令が 4 クロックで済む謎は未解決。AAA 命令が長いのは、AL の論理積を取るためか、あるいは、AH の変更を伴うためか、だと思う。 そのへんは、undefined になるフラグや、例の JMP FAR AL で ALU の手前のテンポラリーレジスターの値を取り出せば推測できるかも? DAA 命令は undefined になるフラグは OF しかないし、実際 4 クロックでできることは限られていると思う。9 との比較でなく、6 を足して AF を見ているのかなとも考えたが、そうすると DAS は足した後引き算しなきゃいけないのでさらに面倒になる。 もしかしたら 8080 あるいはもしかしたら 4004 の名残の回路が作ってあったのかも知れないな。
DAA 命令で複数桁の 10 進数の足し算を処理する場合、下の 2 桁から順番に進めて、ADC 命令で CF を含む足し算をしつつ DAA 命令で補正していけばいいようになっている。 次の 2 桁に進む時点で AF はどうでもいい。1 桁ずつの場合は ADC 命令と AAA 命令で進めて、同じように AF は無視して CF だけ見ればよく、AH に 1 を足されるのも無視することになると思う。
go4004/docs at master - asicerik/go4004 - GitHub
読んで楽しいドキュメント。4004 (MCS-4) にも DAA 命令はあったらしい。4004 のアキュームレーターは 4 ビットだから今とは意味が違うけど、でも 9 を超えているかキャリーがセットされていたら 6 を足して、それでキャリーはクリアしないよというのは、まさに x86 の古いマニュアルのほうに載っていた挙動に通ずるものがある。
引き算については、4004 は引き算のキャリーの意味が反対だったみたいだし、足し算の補正 DAA はあっても引き算用はなくて、代わりにキャリーを見てアキュームレーターを 10 か 9 かにする TCS というのがあったらしい。
ちょっと感心したのはインデックスレジスターのインクリメント命令がキャリーを壊さない点。8086/8088 になってもその仕様は汎用レジスターのインクリメント命令に受け継がれているが、アキュームレーターが 4 ビットしかなかった 4004 では、いわゆる多倍長演算はほとんど必須みたいなもので、隣のアドレスに進めながら演算を進めるのに、インデックスレジスターのインクリメント命令がキャリーを壊さないのが大事だったんだ。8086/8088 はアドレッシングが豊富になって、インクリメント命令を使わなくともアドレスを進めることができるようになっていたが、それでも CF を壊さない仕様は残したんだな。 後になってこの仕様が高速化に影響するとは思いもしなかっただろうな。
レンタルカート。 藤野。6 回券で 4 回 (うち 2 回は 10 分走行) 乗って、ベストタイムは 39.35 秒あたり。
3 連休中日、しかも天気が怪しい、ということで、その午前中にさっと行ってさっと乗って、昼には帰る方向。 朝の気温の低さから安全を考えて車で、八王子から向こう側だけ高速使用。 狙い通り、道はめちゃくちゃ空いていたし、雨が降る前に帰り着けた。
なんだかんだ言ってやっぱり山間部は高速のほうが時間短縮度合いが大きいな。 国立府中 IC から八王子 IC までは一般道でも 30 分弱程度か? 今日は特に午前中は空いていたこともあって、結構流れが良かった。 全部一般道で行くと、八王子市内に入るまではそう遠い感じでもないけど、高尾のあたりまでたどり着くのにだいぶ時間が掛かって、大垂水峠越えでさらに 30 分近く掛かるイメージだもんな。
道中で見かけた教習車。 トヨタドライビングスクール、未だにコンフォート教習車を使っているのか。 そういえばトヨタの教習車、今はカローラベースか? 見かけたコンフォートは MT 仕様で、比較的加速は元気がいいのでガソリン仕様かな? 信号待ちでミラーに映った運転手をよく見たら、40〜50 代ぐらいの雰囲気の人だった。 仮免許練習中でも、MT に手こずっている様子はなく、制限速度まで一気に加速するし、進路変更も危なげない感じで、これは免許取り直しの人かな。 そうだとすると横に乗っている教官も暇だろうな。(完全に想像だけど。)
4004 の説明を斜め読みした後、電卓のソフトウェアを実装してみたくなった。 ここは 4004 用のプログラムを書いた人達の気持ちを想像しつつ、8086/8088 向けの実装を作ってみるか。DOS 用でアセンブリ言語で書けばいいだろう。 演算だけでも、10 進数ベースで小数に対応した四則演算に平方根まで実装するのは地味に大変。 おまけに、実際の電卓の UI って独特な操作法あったよな? とよけいなことを考え始める。123*456= で答えだした後に、0+= と押すと元の数 123 が出るみたいなのがあったんだよな。 あれどういう仕様だっけ...
10 進数での足し算引き算は、4004 でもあったように補正命令を使えばそう難しいものではない。 かけ算は、各桁同士のかけ算をして足していくことになると思うが、8086/8088 では MUL 命令と AAM 命令を使えということだろうか? そうするととても実行時間が長くなるので、実用性が怪しくなりそうだが...
4004 あるいは 8080 など、かけ算命令がない CPU ではどうしていたのだろうか? 電卓となるとテーブル参照するほどメモリーも余裕ないだろうし、やはり足し算か。 うまくやるなら 2 のべき乗単位で処理するんだろうとは思うけど、それはそれでレジスター足りるのかな。 まぁ最悪 9 回足し算してもそう時間はかからないだろうけどね。
割り算は割り算で計算量がやばいし、平方根はそれらの組み合わせで、4004 で実用的な速度で動かすのって相当難しいのでは... みたいな気分になる。 あと負の数をどう表現するか、2 の補数ならぬ 10 の補数という手はあるけど、表示が手間だからやっぱり符号は別管理かな。
ハッピーマンデー (死語)。
電卓と電池を買いに調布のビックカメラに行くつもりが、バイク駐車場が満車。 周辺にあった調布市のバイク (or 原付) 駐車場がことごとく廃止されてしまったため、せっかくできたショッピングセンターのバイク駐車場は明らかに不足してしまっている。 ほんの 30 分でいいから無料で駐められるところがあれば、使うのにねぇ。 で、どうするかって? 三鷹市に行くわけですよ... こんなで調布市は本当にいいんだろうか?
結局コジマ×ビックカメラで電卓も電池も買った。 ビックカメラのポイントカードも使えるし、そんなに店は広すぎず、そんなに混雑もしていなくて、こっちのほうが便利なこともありそう。 ビックカメラの取り置きサービスがこっちでも使えたらいいのにね。
今日もバイクを動かしてみたが、キーの接触不良は起きなかった。 まぁいいか。
車がだいぶ汚いことに気づき、適当に軽く洗車した。 排水のためにやや傾斜のついている駐車場で、車を手で押して後退させるのは、まぁ、やってみるとできないこともないな。
シャープの安い電卓を買ってきた。 店頭にあったものではキヤノンが一番安かったが、平方根のキーがなさそうだったので避けた。 カシオは高いので買わなかったけど、触ってみたところ相変わらず百分率キーの動作が違う。100+8% と押した時に 108 にならないやつ。108 にしたければ、100×8%+ とする。 そこまでは昔説明書で読んで覚えていたが、100+8% で出てくる数字が何の意味だったかは忘れた...
ま、いいや。 あとは適当に遊んでみる。 まず小さいほうの桁あふれはどうなるかというと、8 桁電卓なので 10+0.00000001=10 となった。 他の数字も入れてみたが、下は切り捨てのようだ。 実にシンプル。 上はあふれればエラーになる。99999999+1=1.0000000E である。 よくある電卓らしい挙動。
さて、クリアした状態で、次に数を省略して演算を実行した時の結果。 表示を {} で囲んで示す。 末尾の小数点は省略。
先に演算子キーを押した場合は素直に 0 を対象として計算されているのに対し、後で演算子キーを押した場合は +- と×÷で挙動が違うことがわかる。+- は先に押した場合と同じ挙動になっているが、×は同じ数同士のかけ算として扱われ、÷は 1 を割っている。(×= と÷= は説明書にも載っている。) ほー。 で、その後でただ = を押せば、最後の演算を繰り返す感じ... だが、ここで、数字だけを入れて = を押すという技が存在する。 以下の 4 パターンは (例の数字は違うが) すべて説明書にも載っている。
このように、かけ算だけ左側の数が残り、他は右側の数が残っている。 さて、演算子キーを押して = を押すのは、説明書には×と÷のケースしかない。 他はどうなるのか?
このように、+ でも - でも結果は同じで、元の右側の数との演算になり、しかし残る数は新たに入力した数である。 いや、この右側というのは正確ではなくて、さっきの、数字だけ入れて = を押した場合に残る数を表す。 それを確かめる。
これで、記憶にあった 0+= の挙動も説明できる。 で、数字を入れずに演算子だけを入れて = を押すのも OK で、画面に表示されている数に対して上の法則が適用される。 四則演算のすべての組み合わせでやってみるとこんな感じになる:
ところで、= の代わりに演算子のキーを押しても計算結果が求まるようになっている。 その場合に数を省略するとどうなるのか?
ほー。 これはつまり、クリアーした状態から数を入れて演算子と = を押した時と同じ状態だ。 内部の状態は飛んで、表に見えている数だけが残るのか。
さて、パソコンや携帯電話で動く電卓アプリ・機能というのは、十中八九、このような挙動にはなっていない。 大は小を兼ねると言わんばかりに、演算子の優先度まで考慮する関数電卓的な動作のものが多い。Windows の標準の電卓はそうではないのだけど、Windows XP までさかのぼっても、演算後の 0+= は 0 になる。 この電卓の通りの挙動になるようにプログラムを作れと言われたら、作れるだろうか。 プログラムでなくとも、設計書でもいい。 ひとつひとつは説明できる挙動なので、理屈の上では作れることはわかっているんだけど、結構時間が掛かる自信がある (笑)。
というわけで雑にまとめるとこうだ:
┌────┬──────┬───┬──────┬───────────┐ │ 入力 │演算子の左側│演算子│演算子の右側│見えない部分に残るもの│ ├────┼──────┼───┼──────┼───────────┤ │＋数＝ │見えていた数│ ＋ │入力された数│演算子とその右側の数 │ │−数＝ │見えていた数│ − │入力された数│演算子とその右側の数 │ │×数＝ │入力された数│ × │見えていた数│演算子とその右側の数 │ │÷数＝ │見えていた数│ ÷ │入力された数│演算子とその右側の数 │ │＋＝ │ 残 │ ＋ │見えていた数│演算子とその右側の数 │ │−＝ │ 残 │ − │見えていた数│演算子とその右側の数 │ │×＝ │見えていた数│ × │見えていた数│演算子とその右側の数 │ │÷＝ │ １ │ ÷ │見えていた数│演算子とその右側の数 │ │＝ │見えていた数│ 残 │ 残 │更新されない │ ├────┼──────┴───┴──────┴───────────┤ │＝後の数│見えている数を入力された数に置き換える │ └────┴─────────────────────────────┘
こんな簡単な仕様すら知らないで電卓を使っていたなんて... かけ算と割り算が独特なのは、べき乗計算とか 1/n 計算とかに便利なようにだとは思うけど、かけ算だけ残される数が反対なのは何が要因なんだろうな。3 かける 2 の n 乗、みたいなことをやるのに 2×3===... と入れるのはやや違和感があるようにも思うが、でもこれは自分の記憶からして昔からこういう仕様だったと思う。
あとはクリアーやメモリーの挙動も興味深い。 昔は AC だったが、今はなぜか CA という表記が使われている。 メモリーのほうも、MC ではなく CM となっている。 上のように 1+2===... とやっていて、C/CE を押して = を押すと 0 になる。 しかし、その前に 0 でも何でもいいので何か押してから C/CE を押して = を押すと、0 を対象に +2 の演算が繰り返せる。C/CE を 2 度押せば 0 になるが、C/CE と 0 を交互に押していれば +2 の情報は残り続ける。MR に相当する RM キーはこの電卓にはなく、R/CM キーになっているが、これは見えている数を置き換える効果があるし、数を入れれば追加ではなく新たな数の入力が始まるが、1+2===... の時の +2 は残り続ける。
さて、ごちゃごちゃと細かい話を書いたが、最近はまっている CPU の挙動調査も、これと似たようなものである。CPU のほうが見えない部分が多くて調べるのが大変だけど、手探りで内部の実装を推測するという意味では、やっていることは大差ない。
ZenFone Max Pro (M1) は、ピュア Android と言われる、ほとんどメーカーのカスタマイズが入っていない Android スマートフォンだが、Android 8.1.0 でセキュリティパッチは去年の 2 月で音沙汰が無くなっていた。 まぁ所詮 ASUS、前の ZenFone Max もほとんどセキュリティパッチは出なかったのでそんなもんだろうなと思っていたのだが、きのう、どういうわけだか Android 9.0 へのアップデートが降ってきた。 それで検索してみるとどうやら先月のうちにニュースリリースがあったようである:
「ZenFone Max Pro (M1) (ZB602KL)」に、Android 9.0への FOTAアップデート開始
今更感が半端ないが更新があるのは悪い話ではないので、サクッとアップデートした。1 日使った印象は以下のような感じ:
ま、いいか。(だめだと思ったとしてももはや戻す手段はない。)
きのう考えたあの動きをどう実装できるのかを考えていたけど、やはり状態管理が必要か。 整理していくと状態はどうやら 4 つだな。S0〜S3 としよう。 数字の保存場所は表裏の 2 つあって画面には表が表示されており、フリップできるとする。 全クリア後は裏は 0 を保持していて演算子は + (あるいは表示機能がある場合は + に相当する演算子無し) で S0 からスタートと思えばいいかな。
×÷特別処理はきのう書いたアレで、×は同じ数同士のかけ算、÷は 1/n を計算する。
演算実行は今の表を演算子の左に、裏を右に置いて演算をする。 わかりにくいが引き算で考えるとはっきりする。6-2= を計算させると裏に 2 が残るので、そのまま 8= と打てば当然 6 が出る。 ここで、7-= と打つと... = のタイミングでフリップし表裏が入れ替わる、すなわち、表に 2, 裏に 7 が来る。 この状態で表を演算子の左に置いて演算をするので、-5 が出る。
やや長くなっている部分もあるが、状態としてはこれ以上は削れないと思う。 えっ、メモリーはどうなるかって? 試してみたんだけど、M+ と M- は、押した時点で = で確定して S3 に移り、その時の表がメモリーに転送されて、裏は 0 保持で演算子もリセット状態っぽいんだな。CA, ÷2, M+ などといじわるなことをしても、その後 3= などと入れても 0 になるので、メモリーができようができまいが (メモリーは 0 になると消える)、消されている感じ、いや違う。= で確定してから M+ 押せば裏は消えないな。 だから S2 の演算子入力に近い挙動だ。 数字を入れても飛ばないので、S1・S2 からのメモリーが、裏が消える条件だ。
きのうの夜は暖房無しで寝られた。 室温 13 度ぐらいあるとまぁ、何とかなるもんだな。
未明に降っていた雨は昼前にとっくにやむ予報かと思っていたが、昼ご飯の頃はまだ降っていて、食べ終わって店を出てきたら日が差し始めていた。 そんな天気。
F1 はシーズンオフであまりニュースがないと思って読む頻度が下がっているが、フジテレビの F1 解説で有名な今宮純氏が、今年初めに亡くなっていたという、10 日のニュースを今頃知った。 あらら。 有料放送になってからフジテレビの F1 中継は見ていないため、あの声は懐かしい感じだが、F1 ニュース記事ではまだ名前を見かけていた。 虚血性心疾患とニュースに出ているので突然のことだったみたい。RIP。
なんか急に冷えてきたというか、週末の天気予報に雪マークが付いている。 その割には気温は低くない予報。 来週は最低気温が低そうだが、それでも氷点下行くか行かないかぐらい。 暖冬か。
足し算引き算で符号の扱いはどうしているのだろうか、と考えてみたんだけど、単純に、人がやるのと同じように、符号を見て、符号を除いて足し算をするパターンと、符号を除いて大小比較をして、どっちかの向きで引き算をするパターンに分ければいいのか。 コンピューターちっくに 10 の補数なんて手も考えてみたけど、電卓の作りには合わない気がする。
買った電卓には +/- キーが付いている。1+ と押してから、+/- キーを押して、それから 2= とすると、1 と出る。+/- キーはその時の状態にかかわらず、画面に出ている内容の符号を反転するというわけである。
なお、もしパソコンで動く 8 桁電卓のシミュレーターを作りたいだけなら、今時なら 32bit 整数値を使って作ってしまったほうが楽だと思う。 いや、10 桁や 12 桁だとしても 64bit 整数値を使えばいい。 小数については、2 進数の浮動小数点で扱うと誤差が出てしまって、電卓らしい挙動にならないので、32bit や 64bit の整数値に 10 のべき乗 (0 以下) を掛けた数として扱うことになると思う。 その形式なら入力中に 0.000 などとなっているところも表現ができる。 符号については、入力時は -0 があり得るので別扱いがいいが、計算後は -0 はあり得ないので 2 の補数で扱ってもいいのかな。
と、まぁ、考えていると、小型化された電卓というのは日本ではそろばんを置き換えるものとして登場して普及したんだな、という気がしてきた。 そろばんは雑に言えば数の記憶装置であり、それこそ家計簿を付けるだとか、買い物をする時の合計金額を出すだとか、そういう時に計算を間違えにくいように使われていたわけである。(自分が子供の頃にはすでに電卓やレジが普及していたけど、どこかの小さな商店でそろばんが使われているのを見たことがある気がする。) 電卓も数の記憶装置だけど、計算もしてくれる。 コンピューターらしい 2 進数による計算ではなく、10 進数で計算してくれるので、まさにそろばんをはじくのと同じ結果が得られる。
その後、より多くのデータを計算する目的では、パソコンの表計算ソフトも普及したんだけど、それは 2 進数による計算が一般的なので、小数を扱う場合は注意が必要である。IT 業界ではよく知られている話だけど、例えば 10 進数の 0.1 は 2 進数では循環小数になる。 軽い気持ちで +0.1 とか +0.2 とかした数を扱うと、引き算などで簡単に誤差に遭遇してしまう。 例えば 0.1 の桁までしか使わないことがわかっているなら、あえて 10 倍した整数値を使うといった工夫が必要になることもあり得る。 電卓を使うのにもしそういう知識が必要だったとしたら、そろばんがもっと生き残っていたかもね?
職場のビルの停電案内、突入電流のおそれがあるから機器の電源は外しておいてくれというのはいつもの案内だけど、機器の例としてペンタブというのがあって、ペンタブって省略形は一般的なのかなと思いつつ、それってあのスタジオ会社以外にあるんだろうかと...
DAA 命令。 TF テストプログラム使用。JMP FAR AL により ALU の手前のテンポラリーレジスターに残っている値を調べた。
上位 8 ビットは 0xff、8 ビットのメモリー読み取り時と同様の挙動で、下位 8 ビットには足した数が残っているっぽい。 ...えっ? DAA 命令って 2 回に分けて足すんじゃなかったの? そうか。 結果は同じだから、ALU の使用回数を減らすために、まとめて足していたのか。 ということは、どちらかと言えば現行の Intel SDM に載っているオペレーションに近いのでは? 9 との比較で AF と CF を必要に応じてセットして、AF と CF に基づいて足す数を作って、加算実行、みたいな。 そしてたぶん、9 との比較は ALU 使わないでできるようにしてあって、それで 4 クロックで済んでいるのかも。0x99 との比較は下の 9 との比較結果と上が 9 と等しいか大きいか、そのへんの組み合わせだろうな。 この前みたいに JavaScript 風に書けばこんな感じ:
function daa(AL,CF,AF){
if((AL&0xf)>9)AF=1;
if((AL&0xff)>0x99)CF=1;
AL+=(CF?0x60:0)+(AF?6:0);
return [AL,CF,AF];
}
この様子で行くと DAS 命令も同じノリだろうから、DAS 命令は一部の組み合わせだけ試そう。
やはり同じだな。 フラグは OF が未定義だが、見た感じ普通に演算結果が反映されているかな。DAA 命令のほうもオーバーフローになる値を試してみよう。
それっぽい。AAA 命令については先月少し試したが、その前半の処理、AL に対して足し算を行う部分は DAA 命令の半分と同じだと思う。SF 何これって書いているけど、もしかして足し算の時に出た SF が残っているのかな。0 でも足しているってことかな。AND はどうやっているのかよくわからないけど、ハードウェア的に下位 4 ビットだけを取り出す仕組みを作ってあるのだろうか、あるいは、AH に 1 を足すだけに 4 クロックもは掛からず、ALU で AND までやっているのかも知れない。
しかし... クロック数のチェックでは AAA 命令はどうやら足さない場合に 1 クロック長いっぽいことが判明している。 なんでだろうな? フラグレジスターの関係だろうか? DAA 命令の感じで行くと、AF も CF もセットだけでクリアはしない。AAA 命令も AF はセットだけで良いけど、CF については AF と同じ値にセットするなりクリアするなりしなければならない。 例えば AAA 命令は DAA 命令の半分だけでいいので、CF も AF と同じようにセットするような仕掛けがあるのか? それで CF のクリアが必要だと 1 クロック追加になるのか? いや、もしかして半分じゃなくて、全部、完全に DAA 命令と同じことを一度やっているかも? どうせ 0xf でマスクしちゃうから、途中で何やっていても結果はわからないんだよね。
その AAA 命令をもうちょっと試すか。
フラグの様子を見る限り、未定義の OF, SF, ZF, PF はすべて、AND を取る前の AL の足し算の結果と見てよさそう。 そして、0x9f を超える値を AL にセットしていても、SF がセットされている、つまり、0x66 を足した結果にはなっていないので、DAA 命令と全部同じことをやってはいないらしいことが把握できた。
しかしそうすると、やっぱり 1 クロックは不思議だな。 素直にフラグを反映しながら 0 を足せば AF も CF もクリアできるんだから、何も難しいことはなさそうなものだけどな。 まぁそれを言ったら AH だってそもそも AL に変更がないなら足す必要もないので、マイクロコードってそこまで制御の自由度はないものなのかも。 かけ算割り算はだいぶクロック数に幅があるから自由度高そうに見えるんだけどな。AAA 命令も、AH の足し算は CF と一緒に 0 を加える ADC 命令相当のことをやっていそうな気が。
寒い日。 雪が降った。
JavaScript は、計算のアルゴリズムを試すくらいなら非常に便利だなとあらためて思った。HTML に適当に JavaScript を書いて web ブラウザーで開いて確認するだけでなく、web ブラウザーに付いている Web Console 機能を使えばその場で変数の中身の確認や各関数の呼び出しもできるし、console.log() を使って途中経過を Web Console に出力させることもできる。Web Console には地味にコマンドヒストリー機能も付いているし、複数行の入力も可能だし、関数の中身を差し替えることも可能である。
こうして遊んでいると、やっぱり、昔のパソコンの BASIC にあたるものは JavaScript じゃないかと思うのである。 ややとっつきにくさがあるかも知れないが、今時のオペレーティングシステムが普通にインストールされているパソコンさえあれば、他のソフトウェアの購入やインストールが一切不要で、すぐに実行結果が確認でき、簡単な計算から、興味があるならアクションゲームみたいなものまで作れる。 問題はとっつきにくさかな、コンピューターで計算がしたいというならまだ触りやすいと思うが、インタラクティブなアプリケーションを作ろうと思うと HTML の知識が必要になるのでわかりにくいかも。 そういう人向けの情報がまとまっている本があればいいんだろう。(ないわけがないけど。)
足し算引き算の場合、小数点の位置を合わせて計算することになるが、この位置あわせは最初に行われ、はみ出す桁はそこで捨てられる。 例えば 8 桁の電卓で 99+0.000001 はもちろん 99.000001 で 8 桁に収まっており何も問題はなく、99.999999 もキャリーが処理されて正しく 100 になるが、さらに足しても 100 より増えない。 足し算ではおそらく、どういうアルゴリズムで処理しても、数字 8 桁分で切り捨てるならそうなると思う。 しかし、反対に 100-0.000001 を計算しても 100 が出てくる。 同じ 8 桁処理であっても、アルゴリズムによっては以下のような流れで別の数になるのではないかと考えたが、そうではなかったということだ。
0.0000000 (0 に 1 桁ずつ答えを入れていく形でスタート) 0.0000009 (0.000001 の 1 を引く時に対応する桁がないため 0 と見なして計算) 0.0000099 (以下ボローを処理) 0.0000999 0.0009999 0.0099999 0.0999999 0.9999999 9.9999999 99.999999 (100 は百の位まであるため、ここで一番下の桁を捨ててボローを処理) 099.99999 (もうひとつ桁を捨ててボローを処理し 0 が出る) -> 99.99999
なお、桁数が多い 10 進数の演算の確認には bc -l コマンドを使用している。 これはデフォルトで小数点以下 20 桁の演算ができる便利なコマンドである。
電卓内部にはもう少し多い桁数のバッファーがあるのではないか、と想像していたがちょっと違うかも知れない。 かけ算、どうしているんだろうな。 ひとまず桁あふれを簡単に調べたところ、2.1111113×9 みたいな計算をしても 19.000001 と出ており (一番下の 7 が切り捨てられている)、下の桁から計算していそうな雰囲気はある。(上からやれば 2×9 の時点で 18 が出てしまい、一番下の桁にたどり着かないと見た。)
平方根は、ずいぶん昔に開平法のやり方を教えてもらって、BASIC でその方法で 10 進数演算のプログラムを書いたことがあるが、開平法のやり方は忘れてしまった。 しかし、ぼけっと数学的に考えていたら、うまくやれば足し算引き算だけでもできそうだなと思った。(x+1)^2-x^2=2*x+1、というシンプルな関係があるので、各桁を 1 ずつ増やして大小比較をして確定させていくのはそう難しい話ではないんだ。 足し算引き算だけにするのは置いておくとして、頭の中で考えていた方法をもとに、試しに 200000000 の平方根の整数部分 14142 を整数演算で求める簡単なプログラムを書いてみると以下のようになった:
(function(x){
var a=0,c=1,c2=1;
while(x>=c2)c*=10,c2*=100;
while(c>=10){
c/=10,c2/=100;
var d=c2+2*c*a,dd=c2+c2;
while(x>=d)a+=c,x-=d,d+=dd;
}
return a;
})(2*100000000);
これもやっていることは実は開平法と同じかも知れない。2*100000000 の 2 を 1 から 9 まで変えて試すと結果は以下のようになった:
10000, 14142, 17320, 20000, 22360, 24494, 26457, 28284, 30000
よさそう。
そういえば、きのう・今日とセンター試験の日だったな。 たまたま通りがかった国立大の最寄り駅の前や、私立大の入口前に、センター試験関連の誘導担当っぽい人や、センター試験会場の看板を見かけた。 センター試験って今年が最後らしいけど、始まったのは 1990 年らしい。 へぇー。 なんとなく昭和から続いていたのかと思っていた。 その前は大学共通第 1 次学力試験という似たようなのがあったものの私立大は別だったらしい。
東村山のほうのハードオフまでバイクで行ってみた。 ふんふん。 それから東大和のほうに向かおうとしたら、なぜか新青梅街道の案内がなくて久米川駅のロータリーを抜ける羽目になってしまった。 なんで案内がないんだよw ひでぇなw
噂の Microsoft Edge の新しい Chromium ベースのバージョンを自宅 Windows PC にインストールしてみた。 この PC では前から Microsoft Edge を主に動画再生に使っていて、それは動画再生の調子が良いのが理由。 それと、Mozilla Firefox はプライベートブラウジングの設定にしてあるので、有料動画配信サービス DAZN にログインしっぱなしにしておくのに便利というのもある。 別の格安ノート PC でも有料動画配信サービス DAZN の動画再生がなめらかという事例もあって、結構大事なポイントなのである。
で、インストールしてさっそく DAZN を開いてみると、ログインされていない。 クッキーは飛ぶのか。 なんてやつだ。 移行してくれよ。 まぁいいや。 ログインして、適当に動画を再生しようとしたら、エラー 11_012_012。 おいおい、なんだよそれ、困るよ。 アニメが増えていてタッチがあったので選んでみたけどやっぱりエラー。 何かエラーなく再生できる動画はないか、探したら、サッカーの見逃し配信が再生できた。 しかし... ちょろっと 2, 3 秒再生しては、10 秒ほどくるくる表示で止まる、のを繰り返している。 タスク マネージャーで CPU 使用率を見るとめちゃくちゃ高い。 タブはひとつしか開いていないのに Microsoft Edge がいくつもあって、しかもそれらがめちゃくちゃ CPU リソースを消費している。 えー。
動画サイト全般がだめなのかと、YouTube を開いてみたら、YouTube は問題なく再生できる。 画質を 1080p にしても問題なさそう。 つまり DAZN 側の問題はあるのかも知れないが、しかし今までの Microsoft Edge ではむしろスムーズに再生できていたのである。 まぁ何か DAZN 側が変わったのかも知れないので、新しい Microsoft Edge をアンインストールして、今までの Microsoft Edge で DAZN を開いてみると、エラー 11_012_012 も出ないし、サッカーの試合も引っかかりなく再生できた。 ウーン。
アンインストールするとなんでアンインストールしたのか理由を教えてみたいなページが開いた。 なぜか英語だったので、クソみたいな英語で DAZN 見られないから消した的なことを書いておいた。4 月になったら勝手にアップデートされちゃうんだっけ? どうすりゃいいんだよ...
特に問題がないという人もいると思うけど、たぶん低スペック PC での動画再生がやばいのではないか。 自宅 Windows PC は Athlon 5350 をクロック周波数を落として 1.1GHz で使っているし、格安ノート PC は Atom x5-Z8350 だから、試していないけどおそらくさらに厳しいやつだ。(昨今の CPU の脆弱性対策のため同程度のスペックでも Intel CPU のほうがより厳しい状況になる。) GPU の動画再生支援が働かないのか? でもそれなら YouTube が問題ないのは説明ができない。 単に Chromium の実装がタコなのでは...
そんなわけで Chromium を試してみたらどれもエラー 11_064_011 で再生できなかった。Mozilla Firefox では再生はできるんだけど、やや重そうな感じ。
138 円/l。 燃費計算 17.8km/l。 燃費表示 20.5km/l。
前回の給油が雑だったのでこれである程度補正される。 前回分と合わせて計算すると 19.7km/l になる。
かけ算のやり方を考えていた。 きのうの 2.1111113×9 のように、下の桁からやっていそう、しかし出力が 8 桁なのでどこかで切り捨てをしなければならない、じゃあ下の桁から確定していく方法かな、などと考えていたのだけど、下の桁から確定していくのはそれはそれで面倒な上にありがたみが少ない。 一番下の桁同士を掛けたら一番下の桁が確定し、2 番目の桁と 1 番目の桁の組み合わせ (2 個) をそれぞれ掛けて足せば 2 番目の桁が確定し、というふうな計算は理論的には可能だけど、一番下の桁が確定した時に 2 番目の桁へ繰り上がるというか、2 桁目の数があってそれを残しておかなければならず、しかも被乗数と乗数を最後までとっておかなければならないので、メモリーに制約がある場合はなかなか厳しそう。
で、そういえば 4004 には乗算命令はない。1 桁同士のかけ算結果を小さな ROM に載せておくことは不可能ではないだろうが、1 桁同士のかけ算結果の 2 桁を足していくにしても、キャリーを処理しなければならないので、毎回何桁もの足し算を行う羽目になる。 それだったら... 普通に全桁の足し算をしてもよくないか? 少なくとも計算用に 8 桁のメモリーが追加で必要なのは間違いなさそうだし、一番下の桁からやるなら 0 にして桁あふれのキャリーをそこに足すようにすれば、例えば 2.1111113 を 9 回足して、9.0000017 と、桁あふれの 1 が 9 のところに代わりに入る的な感じで... (あまり深く考えてはいないので何か間違っているかも知れない。)
テレビドラマ『新米姉妹のふたりごはん』も、テレビドラマ『孤独のグルメ Season8』も、テレビドラマ『まだ結婚できない男』も終わってしまって、見るものが減ってしまったが、テレビアニメ『歌舞伎町シャーロック』は 12 話を超えて続いていて、その他にテレビドラマ『ゆるキャン△』というのが始まったのを見つけたので、ゆるく見ている。2 話まで見て、女子高生が主人公で『新米姉妹のふたりごはん』に近い印象あるなぁと思って調べてみたら、『新米姉妹のふたりごはん』のメディアの宣伝も出てきて、あれっと思ったらなんと同じ時間の同じ『木ドラ 25』という深夜ドラマ枠らしいのだった。TVer で放送後に見ているとあまり放送時間を意識しないので、今まで気づかなかった。 なお、今のところ前の番組のような飯テロ要素はない。
AAA 命令の謎を... の前に、先日試したやつで eb00 の代わりに e90000 を使うと出だしのステートが変わるかをチェックしておく。
同じだな。 よし。
それで、やりたいのはこれをクロック数測定用の例の、1 秒あたり何回実行できるかを調べるプログラムで測定してみたいわけである。 あれが e9 を使ってジャンプしているので、これが等しいなら同条件でテストができると思った... ただ、あれか、回数カウント用の inc で AF が変化してしまうので、結局ジャンプ入れないと測れないかな。 ウーン。 じゃあまぁそれでいいか。 あと例によって補正用のかけ算命令を入れておく。
さて... ジャンプの後に 2 バイト命令を入れてしまったのでそこで時間を食っているとは思うが、比較用のローテート d2c0 も 2 バイト命令なのでいいことにしよう。 値が一致したのはひとつは 8076 のところ。 ローテートは 7 回なので 8+4*7=36 クロック。8d10 は 9 クロックで 3 つ、その後ろの 37 (AAA) もどうやら 9 クロックらしいので、9*4=36 クロックで一致する。 どちらもジャンプ後 2 バイト命令でスタートなので、フェッチ待ちも同一条件であり、割とうまく結果に現れたと思う。
あと 8BB7 は 9+7+8=24 と、8+4*4=24 で一致するし、もうひとつ 79EB も、9*4+8=44 と、8+4*9=44 で一致する。 やっぱり AAA の実行時間は足した時のほうが短いのである。
それで、プリフェッチキューの様子を確認したい。 上はかけ算に d500 を入れたが、これは 2 バイトで、この前の考察からすれば 2 バイト分はキューに入っているから待ちは発生しない。 ここに 2 クロックの prefix を加えて、フェッチ待ちの時間が見えるか?
なんか、間に合っているっぽいな? と思ったが、そうだ、そもそもこの前の考察では 3 バイトはキューに載っている計算だし、prefix じゃ 2 バイトで 4 クロックになってしまうから、その 4 クロックで 1 バイトフェッチできてしまって都合が悪い。2 バイトで 2 クロックの命令を入れよう。MOV 命令がちょうどいい。
来た!! この前の考察が正しければ上が 3T2 (キューに 3 バイトあって 4 バイト目のフェッチのバスサイクルが T2), 下が 3T1 で 88c0 に突入する。 そこで 2 バイトを消化し 2 クロック経過すると 1T4 と 1T3 という計算になる。 そのため、次の 2 バイト命令の 2 バイト目をフェッチするのに、1T4 はすぐにフェッチが終わるので良いが、1T3 だと 1 クロック待ちが必要になる。 なるほど良い感じに見えるが、そういえば、元の資料では T4 の次のサイクルですぐに再開しないんだっけな? あれ? いや、そうだ。AAD 命令が 2 バイト目を即取り込むかどうか問題というのがある。 資料では mov $imm,%ax 命令で即値の取り込み開始までに 1 クロックあいている。AAD 命令の 2 バイト目も即値だし、そこに 1 クロック空きがあるとすれば、説明はできる。
ウーン、あれだな、これは AAA 命令なしで調べたほうがいいな。 キューが満タンになるほうの微調整は AAA 命令を使わないと厳しそうだけど、ここまで LEA 命令の動きは予想した感じで来ているから、キューが足りないほうは LEA 命令で調べるのがいいかも。
最近風呂に入るとちょっと鼻血が出るんですよと言ったら、確かに鼻の中の粘膜が荒れているねぇ、と言われて、点鼻薬が久しぶりにカプセルのやつになった。 2017 年以来かな。 荒れている時はモメタゾン点鼻液よりも粉のやつのほうがいいだろうとのこと。 それで特に深く考えずに処方してもらったが、そういえば、液体のやつは医師と相談の上、通常の半分だけ使っているんだった。 なので 2 週間分で 1 か月持つ。 同じようにエリザスカプセル外用 400μgも 2 週間分処方されたけど、カプセル方式なので穴開けたらすぐに使うしかないだろう。 フーン。 まぁいいか、だんだんズレてきた結果ちょうどモメタゾン点鼻液が 1 本余ったところなので、2 週間だけは普通にエリザスカプセルを使うことにしよう。
きのうはどうやら AAD 命令の 1 バイト目の取り込みと 2 バイト目の即値取り込みの間に 1 クロック空いているのではないかという推測だった。 上の最初の 3 つはそれの確認である。 それで、今回はいきなり AAD 命令を実行するのではなく、その前に回数指定のローテート命令を入れることにした。CL は設定していないので 8 から 1 まで変化する。 ローテート命令は 2 バイト目が Mod-R/M バイトなので、1 クロック空かないと見た。LEA 命令もそうだけど。 こうして見ると推測が当たっていた感じ。1T3, 1T4 でローテート命令に行くと 2 バイト目が間に合わず、待ちが出る。 そのため 2T1 の場合と同じ結果になる。 ここが AAD 命令との違い。 残りは単に他の計算に狂いがないかの確認で、同じ値が横にズレた位置にあるのがいくつか確認できる。
こうして観察していくと、ジャンプ命令直後となる最初の 2 バイト命令の待ち時間も推測できそうである。8d00 は 9 クロックだが、1T2 から始まると 2 バイト目のフェッチまでの待ちが 3 クロックになり、合計 12 クロックになっているという見込みである。 これを他の命令に変えてみる。
ん? そうか、99 は時間長かったよな、と思ったけど 5 クロックじゃ足りないか。 そうだな。1T2 スタートだもんな。AAA は使いづらいから 2 バイトじゃ試せないな。 もっと増やすか。d2c0 のところでのキューの長さとステートの推測も書いておく。
やはり、1T4 では 2 バイト目に 1 クロックの待ちが入るようだな。 さらに、最初のものは 958A〜がさっきの 8d00 d2c0 d500 のところと一致している。 これはどう説明がつくかと言うと、8d00 は待ちを入れて 12 クロック、キューに余裕ができて d2c0 は待ち無しで開始、8 回は 40 クロックなので、ここまでの合計が 52 クロック。 これに対して、99 は 5 クロック、待ちなしで 4 つ分を実行でき 20 クロック、これで d2c0 も待ち無し、6 回は 32 クロックで合計 52 クロック。 完璧だ...!
後は 2 バイト目が即値の命令で 1 クロック空くのかどうかを調べたい、と思ったんだけどアレだ。AAD 命令は演算時間が長いのでわかったが、4 クロックくらいの 2 バイト命令ではキューが枯渇してしまって、結局待ち時間ができるので調べられないのか。 フーン。
さて、なんかジャンプ命令で飛ぶと 1T2 から始まるのに CALL 命令だと 1T1 からな気がしていた。 しかし考えれば考えるほど 1T1 で始まるのはおかしいわけだ。0T4 の終わりでキューに入っても、それが使われるのは 1T2 からなんだ。 で、そんな気がしていた原因をたどると、MOV CS での cwtd の実験の時だ。 ウーン。LEA で試すとジャンプを入れようが入れまいが差はないみたいなのに、cwtd だと明らかな差が出る。AAA 命令みたいな変なクロック数の差でもあるんだろうか。 そんな難しい命令じゃないんだけどな... 連続で何回実行しても結果は変わらないし... まぁ一応 MOV CS 実験してみるか...
あああ。 またしてもそうなのか。 最上位ビットがセットされているケースが明らかに実行時間が長い。 たぶん 1 クロック長い。 上の実験でそこそこきれいに出たのは AAD 命令で AX をクリアしたからだ。MOV CS 実験プログラムでは AX の最上位ビットがセットされた状態からスタートするので、実行時間が長いほうを基準に考えないといけなかったようだ。6 クロックなのか? と書いていたのはある意味では正解だったわけだ。
で、CALL とジャンプの差を説明できることがあるとすれば、もしかして、CALL 先の命令のプリフェッチ後にスタックへの書き込みが行われているのか? 資料の説明にある PUSH 命令だと、スタックに書き込む時のバスサイクル T4 の終わりで、次の命令の最初の 1 バイトがキューから消えるのである。 その理屈を CALL に適用すれば、スタック書き込みの T4 から、6 クロック... T4, 0T1, 0T2, 0T3, 0T4, 1T1 となって、その次が 1T2 開始になる。 書いていて自分でもびっくりな理屈だが、これより時間が短い命令ではフェッチ待ちができてしまうので、これを確かめるにはもっと長い時間が掛かる 1 バイト命令で試す必要がある。AAA だな。 テストプログラムで開始時の %al は 0xcb になっているので、うまい具合に 8 クロックで始められる。
うーむ、矛盾はない! いいぞ! 謎が解けてきた! 次はキューが満タンのほうの詳細だな。
JA のお歳暮のお買い物券を消費した。 朝行ったらなんかショップが混雑していたので、選ぶのがめんどくさくなって、適当に地元産蜂蜜の大きめの瓶のやつを買った。
さむい。
朝出かける前に Android の Twitter アプリを何も考えずに更新し、起動したらすぐに落ちる事象。 やりやがったな。Web から Twitter を検索すると、同事象が多数報告され、諦めてデータを消したり再インストールしたりして復活した人もちらほら。 公式アカウントでも investgating などと書かれていたのに加え、adb logcat で観察した人の、どうやら SQLite のテーブルの更新でやらかしたっぽいという話も見つかり、いやいやまったく全然テストしていないんだろうか開発者は... なお、昼休みに見たら早くも修正版が出ていた。
80C88 のプリフェッチキューが満タンになった後どういう風にプリフェッチが再開されるのかを調べる。 MOV CS の実験プログラムを使用。
d500 (AAD) でのんびり演算後のキューの動きチェック。36 が 2 クロックで、99 はここでは (AAD 命令で AH が 0 クリアされるため) 5 クロックである。 ふたつめの 36 の開始時点で 3T1 か。 ということは、最初の 36 の 2 クロック目には準備をしている感じ。 思っていたより立ち上がりが速いかな? こんなもんかな。 ふーん。d500 だけで 3 になるのは、MOV CS が 2 バイト 2 クロックで、その 2 クロック目に準備をしているので、変わる前の CS で次の 3T1 に進んでいくと考えられる。
さて。LEA で微調整して観察。 最初の 8d10 4 個は、37 の最後のサイクルが、キューが満タンになった 1 クロック目と想定。 次の 36 開始時点で満タンになってから 2 クロック目。 その次には準備をしているものと思われ、結果は最初ののんびり版と同じに見える。
次の 8d10 3 個は、37 の最後のサイクルが 3T4 のつもり、つまり次の 36 の 1 クロック目はキューが満タン直後。 すると最初の 36 の 2 クロックの間にはプリフェッチがスタートせず、その次の 36 の 1 クロック目で準備、2 クロック目で 2T1 とすると、99 の開始が 2T2 になるので計算が合う。37 の次を MOV CS としても、MOV CS の次の命令の 1 クロック目で準備になるから、プリフェッチに使う CS は変更後となり、2 が出ると考えられる。
最後の 8d10 2 個は、37 の次の 36 の 1 クロック目に 3T4 のつもり。2 クロック目はバスはお休み、さらに次の 36 の 1 クロック目もお休み、2 クロック目まで来て準備、それで次の 99 が 2T1 で開始すれば、計算が合う。37 の次を MOV CS とした場合でも、MOV CS の次の INC の 2 クロック目まで来て初めて準備なら、2 が出ることは説明が付く。
まとめると、満タンになった直後の 2 クロックは準備に入らない。3 クロック目でキューが空いていればプリフェッチ準備 (これもバスとしてはアイドル状態)、4 クロック目が T1 の流れ。 満タン直後でなければ、キューに空きができた時にはプリフェッチ準備、その次が T1 の流れ。 プリフェッチ準備のタイミングの CS が使われる。 資料に載っていたのは 8086 におけるものなので、2 バイト空かないとプリフェッチが始まらない、という意味で違いがあってわかりにくいが、そっちは 4T4 が次の命令の 1 バイト目、2 バイト目はまだキューが 5 バイトで満タン扱い、3 バイト目まで来てキューが 4 バイトで空きができ、4 バイト目でやっと準備という流れでバスのアイドルは 3 クロック分。 満タンにする T4 のひとつ次のサイクルの終わりでキューが空くパターンなので、一応、自分の推測の通りでこれも整合性は保てる。 なるほどなぁ。 そんなのあの資料だけじゃ読み取れなかったよ。
これで、先月試したクロック数推定のやつが変だった理由が理解できるかな? AAA 命令が条件によっては 9 クロックになるというのを知らなかったために、11 クロック以降ズレが発生した。 で、あっ、そうか、メモリーアクセスを伴う命令はまだ詳しく見ていないな。EA 計算の間にプリフェッチは進むだろうけど、そのせいでメモリーアクセスが 1 クロック待たされることがあるという話なので、下のほうはその影響が出ていないか調べないとだな。
外は雨。 2 年前は雪だった。
朝から怪我をした。 家の中で靴下を滑らせ親指と人差し指が下向きになったまま体重がドカンと。 いってぇ。 動かさなければ痛みはほとんどないが、少し腫れている。
なんとなくモノレールを使ったが、神田でエレベーターは南端、その近くの車両に乗ると浜松町でめっちゃ遠くなる。 おまけにモノレールの浜松町も改札階に上がるためのエレベーターが遠く、不便だった。 京急のほうが歩く距離が短いか? でも京急は空港のところが深い印象あるんだよな。
今日はスカイマークの方向を間違えなかった。 ちゃんと 1 時間くらい前には空港にいたし、お腹を満たして、30 分ちょっと前には保安検査場の列に並んだ... が、保安検査場のスタッフの手際が信じられないほど悪かった。 かごにものを出してと説明が貼ってあるが、肝心のかごがない。 ないので出しておくことができない。 自分の前の人の時点で足りなくなっており、自分の後ろの人達も何人もかご無しのまま並んでいたので、検査直前に出すことになって、よけいに時間がかかったに違いない。 保安検査場通過に 10 分以上を要し、足をかばうため動く歩道に頼ったら、15 分前には間に合わなかった。 でも空席は数えるほどしかないほどで搭乗口に人が並んでおり、通路側座席は最後の案内なのでセーフ。
例によってスカイマークコラボのキットカットが配られた。 コーヒーは断った。 悪天候で揺れるとアナウンスされていたがたいしたことはなかった。 去年のアメリカ行きの飛行機が、上空 12000m あたりでめちゃくちゃ揺れたのに比べたら、離着陸の時だけなんて何でもないレベルだ。 そして着陸したら晴れていたw
鹿児島暑い。1 月に 20 度って... 奄美大島じゃないんだぞ! 爆発的噴火で地震みたいに扉などがガタガタ揺れる事象、桜島は元気だな。
曇り。
きのうの怪我のあとは指を下向きにすると痛い感じ。 親指の内出血は治りつつある。
先月のやつ、11 クロック以上のところがおかしいわけだが、わかったことを当てはめて考えてみる。add (%si),%al の 2 クロック目がフェッチ準備、3 クロック目が 2T1 となる。+EA が 5 クロック、2 バイトの直後にその計算が行われるとすれば 3〜7 クロック目がその計算。 どうやら 1 クロックの待ちが入っていると思われるので、プリフェッチは待たされていないはず。 そうすると 7 クロック目で 3T1 のはずで、9 クロック目の 3T3 まではそのまま。10 クロック目がメモリーアクセスの待ちで、11〜14 クロック目に T1〜T4 をやって、15 クロック目が終わり、かな?
add (%bx,%si),%al は +EA が 7 クロック。 それなら 3〜9 クロック目が +EA の計算、10〜11 クロックはそのまま... あれ? そうすると 10 クロック目でフェッチが終わってしまって、待ちが発生する要素がなくなってしまう。 おかしいな。 てっきり、これが 1 クロック待ちで、次の add (%bx,%di),%al が待ち無しで説明ができると思っていたのに、どうなっているんだろう。
と、あらためて資料を見ると push %ax の例が 11 クロックになっている。 説明としては BIU はプリフェッチを中止して、その結果 4 クロック伸びる代わりに 1 クロックだけで済んだ、的な説明だ。 で、肝心のメモリー書き込みの手前には 2 回のアイドルサイクルがあるわけだ。 ということは、本当は書き込みが 1 サイクル手前からのはずが、プリフェッチの中止の結果ズレてしまっているのか? 他にも別のところには、メモリー読み取りは書き込みと違ってアイドルステートが不要的な説明もあって、何がなんだか。 もうちょっと実機での調査が必要。
どたばたした日から 1 年、一周忌。 会場のお寺を間違えるというハプニングはあったが、例によって 30 分ほどで終わり。 大変大勢の合同法事だった。
その後は親戚一同で食事。 いとこの子供が大きくなっている (ように感じる)。 自分が子供の頃、親戚に会いに行くたびに「大きくなったねぇ」と言われるアレを、まさに自分がやっていると思うとおもしろい。 そして一人は店内の水槽に興味を持ち、観察をしては叔母や祖母に何かを伝えたくてしょうがなさそうな様子で、子供の頃は時間が長く感じられるんだよなぁというのを思い出した。 大人達が食事を終えるのを待つ時間が、長いのだろう。
最近のダイハツ車 (ダイハツ製造の他社のものも含む) は方向指示器のレバーの仕様が変わっていて、動かしても中立位置に戻るようになっているらしい。 手応えとしては今まで通りだが、離すと元の位置に戻る。 キャンセルは反対向きに軽く倒すんだと。 ウーン。 ヨーロッパ車に似たような仕様のものがあるそうだけど、いまいち。 バイクだと、中立位置に戻るタイプは多いのだが (自分が今までに乗ったことがある二輪では原付以外はすべてそうだった)、あれはプッシュキャンセルで、しかも二輪ではハンドル操作によるキャンセルは一般的にはないので、毎回プッシュキャンセルする形。 車ではハンドル操作量が微妙だと解除されない場合があって、その場合に反対側に軽く倒すというのは気を遣いそう。 また、普通に合図を出すのに倒しきらなかった場合 (車線変更用ということになっている) に、ふつうのものはレバーの位置が元の位置に戻るのを指で感じて倒し直す感じだが、このダイハツ仕様は点滅が 3 回で終わってしまったのを見てから気づくことになる。 なお、ディーラーで設定変更を依頼すれば 3 回点滅機能はオフにできるそうで、オフだったら操作ミスにすぐに気づけるのでマシかな?
車の運転インターフェイスは時代とともにいろいろと変わってきているけど、オートマチックトランスミッションのゲート式のセレクトレバーなんかは最近はまた減ってきているような気がするし (あれは、D から N にするのに勢い余って R に入ることがあってあまり好きになれなかった)、足踏み式パーキングブレーキの解除が別のスイッチ式になっているのも見ないし (踏んで解除がいいのかどうかは正直よくわからない)、方向指示器も 5 年後に何が主流になっているかはわからないな。
車を運転して市内へ。 忘れ物を取りに行った後、西洋亭ひろはまでランチ。 さすが日曜日だけあって、次々にお客さんが入ってくる。 のんびり待って少々雑談など。 灰は少々。 帰りは雨が降り出した。
鹿児島の国道に電光掲示板で出ている渋滞情報、「〜まで○○分」なのだが、これは混雑しているのかどうか、そのあたりの場所に詳しくないとよくわからないやつだ。 東京だと、「調布」みたいな地名の下に、「↑」を太くしてその中の渋滞箇所が塗りつぶされたものが表示されている。 甲州街道を都心方向に向かうと、環八通りの手前あたりには、その矢印が複雑になった絵が出ていて、首都高と一般道の様子がわかるようになっている。 東京でも高速道路については「〜まで○○分」方式が使われているが、別のところに「〜から○○ km 渋滞」というような情報が表示される。
国道 3 号線の一部など、鹿児島でも片側 3 車線なんて道はあって、ちょっと都会っぽさがある。 鹿児島育ちだけど、運転免許を取得したのは茨城だったので、広い道に車がいっぱい走っていて、左端の車線が混雑していると都会っぽく感じてしまうんだな。
天文館近くで駐車場待ちの車の列ができているのとか、アーケードを歩く人達とかを見ると、まだ鹿児島には街が残っているんだなとうれしくなるけど、実際のところどうなのかはたまに見るだけじゃわかんないな。 鹿児島中央駅近辺の成長っぷりはすごいんだけど、わらわらとビルを建てマンションを建てとしているのを見ると、つくばエクスプレスの研究学園駅とつくば駅のことを思い出さずにはいられない。(研究学園駅前には大型ショッピングモールやら市役所やらできて宅地もいっぱいで急成長、つくば駅前はイオンも西武百貨店も撤退して何が残っているのやら。)
ダイハツトールのトヨタ版。 クルーズコントロールがついていて高速道路は快適。 クルーズコントロールは、慣れない車で多少の勾配があっても 80km/h をほぼ維持することができるすばらしいデバイスである。 プリウスほどではないけど、そこそこの精度でコントロールしてくれた。 アメリカ合衆国で以前乗ったギャランとは、操作は同じでも精度は大違いである。
ブレーキペダルは踏み始めが柔らかく感じる。 なんか、ききはじめは早いがききの弱い区間が広い感じ。 スイフトのようなカックン (きき具合の段差) はないが、カッチリとした感じはなくやや頼りない感じ。 車重のせいか?
ステアリングはまぁ普通。 特に良いとか悪いとか思わなかったということは、スポーツ性が求められないこの手の車としては良いんだろう。 電動パワーステアリングも採用車種が増えて、以前より品質が上がっているんだと思う。 車体の背が高いのであんまり横 G をかける気にはなれなかった。
方向指示器はやっぱり操作性が気になる。 解除したつもりが逆方向、というのを目視で確認しなければならないのはいまいち。
車自体は高さを除けば小柄な部類。 幅は iQ よりも小さい。 ドアミラーも小柄なのでよけいに小さく感じられ、運転しやすい。 長さが iQ より長いのはそれは仕方がない。 オーバーハングが大きくないのは iQ 乗りとしてはありがたい。
自然吸気 1L エンジンは、前に代車で乗った 1L の 3 代目ヴィッツと同系統のエンジン。CVT も同じような設定か、あるいはそれをさらに加速重視にしたか、とにかく 1 人で乗る分にはそこそこ走りそうな感じになるようになっている。 急坂はさすがにべた踏みでも加速しない感じだったが、まぁ、通勤などで毎日通るというのでなければ許容範囲だと思う。 なお D レンジのままべた踏みしても 4000rpm 程度だった。 もうちょっと高回転を使えばもうちょっと力が出そうだが... そうそう、低速時の CVT がややギクシャクすることがある。 ロックアップクラッチのつながりかと思ったが、ロックアップ後に回転数が低すぎるとエンジンそのもののガクガクが伝わっているのかも知れない。 やや強め加速で発進したほうがギクシャクしなかった気がする。
アイドリングストップは 1.3L の 3 代目ヴィッツと同じようなものかと思っていたが全然違った。 停車前にエンジン停止するという点もそうだし、停車後 N レンジに入れても、ブレーキペダルをゆるめれば (車が動かなくても) エンジンが再始動する点も違う。 ヴィッツのは CVT なだけで、挙動としては MT の iQ に似ていると思ったが、あれはトヨタ系の開発であって、ダイハツはダイハツで独自の開発をしてきたということだろうな。 再始動は 1.3L の 1NR-FE と比べて気になるかどうか... 1NR-FE は、スターターモーターが、一部のバイクのように、ワンウェイクラッチを介して常時かみ合いとなっていて、それで再始動時間を縮めたみたいな宣伝文句だったが、MT だとそもそもクラッチを踏んだ時点で再始動するので何も気にならないからなぁ。CVT でどうだったか、そこまでよく覚えていない。
燃費はあんまりよくなさそう。 車重もあるけど、伝達効率の悪い CVT と、高回転を多用せざるを得ない低排気量自然吸気エンジンの組み合わせがつらいところだろうか。80km/h だと 3000rpm より低い回転数で走れていたが、もし 100km/h で走ればだいぶ厳しい燃費になりそう。 もうちょっと排気量の大きい自然吸気エンジンだったら、燃費も加速もいいだろうになぁ。 まぁ、4 気筒 1L の初代ヴィッツあたりと同程度 (かな?) の燃費を出せるのは、車重の差を考えればいいほうなのかも知れない。
鹿児島は未明から荒天。 嵐のようだ。 飛行機は飛ぶのか? 運行状況を調べると、午前中は多数の便が欠航になっていた。 台風のような風の音がしていたので仕方がないところ。 突風のような感じで強い風が吹いては、しばらく静かにしている、という感じで徐々に弱まっていったが、一時雷が鳴ったりあられかみぞれかみたいなものが降ったりした。
飛行機がだめ、フェリーがだめ、新幹線が鹿児島から熊本あたりまで強風の影響で運転見合わせ、肥薩おれんじ鉄道も川内で運転見合わせ、残るは日豊本線大回りと肥薩線だけか? みたいな、かなりひどい天気だったので午前中に鹿児島発着の予定があった人は結構困っただろうな。
で、スカイマークの情報を調べていたら、一便は鹿児島行きが長崎空港へ向かった模様。 それが、なんと着陸復行時に落雷を食らったそうで、もともと福岡空港に行くかもという情報があったのに、長崎空港に行ってしまったらしい。 こりゃトラブルあったかな? 普段、東京鹿児島間は 2 機で回しているっぽいので、1 機脱落して大丈夫かな? と気になっていたが、折り返しの 1 便が欠航しただけで、残りはちゃんと飛んだ。 きっと東京に予備機があるんだな。 なお、インターネットで見かけた情報によれば、長崎空港から鹿児島空港までバスで送ってくれるか、16000 円を上限として代わりの手段の運賃を後払いしてくれるか、選択できたらしい。
そんなわけで東京へ。 予約時には窓際の席を選んでいたんだけど、天気悪いんならどうでもいいなと思って、搭乗手続き時に通路側を探したら前から 3 番目の席が空いていたので、そっちに変更した。 やっぱり飛行機は前の席のほうがやや静かである。5 分早く到着と言っていたがゲートにたどり着いたのは定刻。 そしてのんびりと手荷物受け取りに向かうともう手荷物が出てきている。 スカイマークの手荷物出てくるの早くない!?
めし食って、バスに乗ろうとチケット売り場に行くと、お目当ての便はもう間に合わない時間だったらしくて、次の便の時間が出ていたので、それなら鉄道でいいやと思って京急。 ややダイヤが乱れていた。 そして山手線激込み、渋谷・明大前乗り換えで、最後はタクシー帰宅。 寒い雨。
帰ってすぐ買い物に行った。 寒いけどバッテリーは何とか耐えているようで、車のエンジンは始動できた。 雨で視界が悪いせいもあって、自分の車の車両感覚にとまどう数分間w やっぱり、ドアミラーがでかすぎるよね iQ ってw
第二種情報処理技術者試験を受けた時に試験会場に持ち込んだ電卓、兄者が使っていたものだが、メーカーはシチズンだった。 こないだ把握したシャープの電卓と同様の操作を試したところ、足し算と引き算を繰り返す操作には対応していないようだった。 かけ算と割り算は同じ繰り返し操作ができたし、その後の += も受け付けるが、足し算引き算はちょっと違うようだ。
電子辞書があったので、それに内蔵されている電卓も試してみたところ、シャープの電卓とまったく同じ挙動のように見えた。 ほー。
雪はわずかに降ったみたいでスクーターのシートや車の窓が白くなっているのを見かけたが、基本的には雨だった。
職場近くのスーパーが今月いっぱいで閉店するとのことで、久しぶりに弁当を買いに行ってみたら、弁当はさほど変わっていなかったが、その他の棚の縮小っぷりが半端無かった。 米やら調味料やら、いろいろな棚の 1 段分がまるまる空っぽになっているところがある。 スーパーの閉店前はこうなるんだな。 閉店後は何が入るのか? タワーマンションのテナントなので、何も入らないと住民も困りそうなものだが...
この前の考察の謎を解く。add (%bx,%si),%al だと都合が悪いと思って add (%bx,%si),%cl を使ったが、99 は %ax の最上位ビットを見ているだけなので add (%bx,%si),%al のままでもよかった。 まぁいいや。MOV CS 実験コードを使う。
c7064101ebbd c7043939 8006800002 b80000 7902 cd20
これを @ として省略して書いた。 また 99 を並べるところを x 個数として省略して書いた。 さらに [] 内にその次の命令開始時点でのプリフェッチキューの長さとバスサイクルを書いた。
さて... とりあえずパターンとして [1T2]〜[2T2] までが同じ、パターン A。 さらに [2T3]〜[3T2] と [3T4] が同じパターン B。[3T3] だけ特別なパターン C。
パターン A は何を示しているかというと、素直な想定としては add 命令の次で 2T4 になっている可能性がある。 パターン B は 3T1 か、3T4 か。 パターン C は 3T3 か、あるいは 4+2 か。 メモリー書き込みはしない命令だから、メモリーアクセスのバスサイクルが次の命令にまたがることはなく、次の命令の開始時点でプリフェッチは動いているのではないかと。
で... キューに 2 バイト以上あれば 2 バイトの add 命令は取り込み待ちが起きることはない。 それで 3〜9 クロック目が +EA の計算ということなので、パターン A の [2T1] 開始で考えれば、0T3, 0T4, 1T1, 1T2, 1T3, 1T4, 2T1 となるが、そうすると add 命令の次で 3 バイト入っていなければおかしい。 つまり 2T1 はメモリーアクセスに伴ってキャンセルされてアイドルになっているのだろうか。 そして 10〜13 クロック目がメモリーアクセスとしよう。 残るは 14〜16 クロック目、そこに 2T1, 2T2, 2T3 が埋まって、次が 2T4 から始まる。 おっ。 一応説明としては成り立つか? [2T2] 開始も結果が同じだとすれば、2 クロック分がアイドルになっているのかな。 キューに 1 バイトの場合 2 クロック目のところで待ちになり、1T2 で再開するのでやはりその次は 0T3 で矛盾はない。
パターン B の [2T3] 開始の場合、3〜9 クロック目は 1T1, 1T2, 1T3, 1T4, 2T1, 2T2, 2T3 だろうか。 それだと 10 クロック目にメモリーアクセスはできず、11〜14 クロック目がメモリーアクセスか。 そして 15〜17 クロック目に 3T1, 3T2, 3T3 で次は 3T4 か。 成り立ってはいるような気がする。 これが [2T4] 開始だと待ち無しで 16 クロック目が 3T3 か。 そして [3T1] 開始だと? 1T3, 1T4, 2T1, 2T2, 2T3, 2T4, 3T1、とはならないのはさっきのパターン A と同じ。 最後がメモリーアクセスに備えてアイドルになる。[3T2] 開始も同様に 2 クロックアイドルで説明はできそう。[3T4] 開始の場合、2〜4 クロック目でキューが休んでしまう。 つまり 3〜9 クロック目が 2, 2, 2T1, 2T2, 2T3, 2T4, 3 となることで説明ができる。
パターン C の [3T3] 開始の場合、プリフェッチがとぎれず続くため、3〜9 クロック目は 2T1, 2T2, 2T3, 2T4, 3T1, 3T2, 3T3 という最強パターン。 パターン B の推測の [2T3] 開始と同様にメモリーアクセスが 1 クロック待たされて、結果プリフェッチキューは満タンになり、さらに間が空くので次の命令の 2 バイト目で早くもプリフェッチ準備が走る。 なるほどー。
で、謎のパターンは最初からプリフェッチキューが満タンになって間が空いているケースだ。 ここでは試していないが、同様の推測でいけば、3 クロック目は 2T1 となり、パターン C と同様になる。 つまり、メモリーアクセスが 1 クロック待たされる。 やはり aad; add (%bx,%si),%al では add 命令は 17 クロックかかっていることになる。 また、aad; add (%bx,%di),%al では +EA の計算が 1 クロック長いことで、メモリーアクセスの待ちがなくなり、add 命令は 17 クロックとなる。
aad; add (%si),%al の場合、add 命令の 3〜7 クロック目が +EA の計算で、2T1, 2T2, 2T3, 2T4, 3T1 とはならず、最後がアイドルとなると考えられる。 そうすると、8〜11 クロック目で読み取りができ、12〜14 クロック目は次のプリフェッチを... アレ? それだと 14 クロックで収まってしまうぞ? アレ? 待てよ、14 クロックか。14 クロックねぇ... いろいろわかってきた今なら正確に出せるな。 ちょっと実行時間計測も試そうか。
やっぱり add (%si),%al は 15 クロックじゃん。 なんでだ。 あっ、あれか、プリフェッチキャンセル時に +1 クロックがあり得るのか? そういえば資料の説明もそんな感じがあったな。add (%bx,%si),%al はメモリーアクセスが待たされるケースだったし add (%bx,%di),%al は待ちがないケースだった。 上でいくつかキャンセルのあるケースを想定してはみたものの、キャンセルによる命令実行時間の延長は考えていなかった。 プリフェッチキューの状態をいろいろと変えてみての計測が必要そうだ。
Google の G Suite の仕様変更で、あと 1 年ちょっとすると OAuth を強制されるというような連絡が回ってきている。 先月に英語の連絡が来て、翻訳版は 1〜2 週間ほどお時間をいただく、となっていて、日本語で連絡が来たのはそれから 6 週間後であった。 ニュースサイトでも情報が出ている。
Google、安全性の低いアプリのG Suiteへのアクセスを制限へ - Engadget 日本版
自分所有のドメインで使っている分は、Android スマートフォンはいいんだろうけど、IMAP の認証は明らかにはじかれる対象だと思う。 しかし OAuth 対応というのはなかなか手間がかかりそうな話で、Mew をそれに対応させるというのも、(自分の Emacs Lisp の知識が足りないので) 気が遠くなりそうな話である。 職場でも Mew を使っているしどうしたものか... と思っていたがよくよく調べていたら話が違うぞ? Google の話は以下だ:
こんな感じの書き方だ。Access という単語の使われ方があやふやで日本語もよくわからなくなっているが、とにかく、OAuth に対応していないアプリケーションのことを LSA と言っていて、それが使えなくなっているという文章にしか読めない。
ところが... LSA の使用を禁止するオプションはすでにあって、それを強制的に有効化するよというのが今回の話だと思うんだけど、ここで 2-step-verification (2 段階認証, 2SV) というものが存在していて、2SV を使用した場合、IMAP 等を使うアプリケーションに設定するパスワードは、Google に app password というのを発行してもらってそれを使うことになっている。 それで、LSA の使用を禁止していても、この app password は使えるっぽいのだ。
そういう現状から考えれば、すでに 2SV と app password を使用している職場のアカウントについては、そのまま使い続けることができると解釈できる。 自分所有のドメインのほうは 2SV を使用していないため引っ掛かるが、なんのことはない、それなら 2SV を有効にしてしまえばいい。 しかし、Google からの連絡では 2SV の話は一文字も触れられておらず、OAuth が必須になるというふうにしか読めない。 本当に OAuth 必須にするのなら、2SV の app password も廃止しますと書かなければおかしいだろう。Google の説明で app password に触れていない点はとうてい納得できるものではないが、2SV 有効化で済むのならあんまり気にする必要はなさそうだ。
プリフェッチ中止の実行時間の違いを見る実験。 後ろの aad 命令の即値を変えることでバランスを取って、add (%bx,%si),%cl の実行時間の差を見る。 きのうの推測から、p の後ろの数字がプリフェッチ中止によるアイドルのクロック数、w の後ろの数字がメモリーアクセス時のプリフェッチ完了待ちのクロック数とする。
69C0 のところは 8 回の計測で 69C1 と交互になる感じだった。 メモリーアクセスのプリフェッチ完了待ちがある場合はもちろん、プリフェッチ中止によるアイドルのクロック数が 1 の場合も 1 クロックの待ちが発生しているように見える。 きのうの最後の add (%si),%al の謎は、7 クロック目がプリフェッチ中止によりアイドルになったために、1 クロックの待ちが発生したためということで説明が付く。 なるほどねぇ。
なお資料では push %ax の 10 クロックが 11 クロック掛かる様子が図示されていて、7〜8 クロック目がアイドルになり、9〜12 クロック目がメモリーへの書き込みである。 メモリーへの書き込みの T4 は次の命令の開始と重なるので 11 クロックである。
メモリーアクセスの要求に伴う中止がこのようにできることを考えると、メモリーアクセスの要求は、バスサイクル T1 のひとつ前は準備 (S0, S1, S2 に情報が出るサイクル) として、ふたつ前、いや、3 つ前には BIU に情報が伝わっていなければおかしいのかな。 プリフェッチも準備が必要だが、資料の図を信じれば、中止の際に S0, S1, S2 にプリフェッチの情報は出ていないので、いや、待った。 この図は結局 p1w0 のケースしか説明していなくて待ちが発生しているのだ。 えーっと? プリフェッチを p, メモリーアクセスを m、アイドルサイクルを pT0 と表すことにして...
あぁ、そうか。p2w0 のケースがあるから 3 つ前でわかっていないと中止が間に合わないのではないかという推測になる。S0, S1, S2 にプリフェッチの情報を出しつつ中止ができるというなら、ふたつ前でも間に合うことになるけど。 こういう形で、最悪でも 1 クロック待ちでメモリーアクセスができるという説明の意味が理解できることになった。 そして自分が実装したエミュレーターが間違いだらけであることもよくわかった。
あっ。 キューが満タンになる場合はどうなるんだ? add (%bx,%si),%cl の +EA は 7 クロックなので、[3T3] 開始でも 2T1 から 3T3 で終わってしまって p0w1 になるが、add (%bx,%di),%cl を使えば 3T4, いや、それだと待ち無しか。 もうひとつズレたらどうなるのか気になるが、試せないな... まぁ一応、見るだけ見てみるか。
やはり、これだと特におかしな点は見られない。add 命令以外で何か、試せる命令が見つかったら試したい。 キューが満タンになってプリフェッチが停止した時に、すぐにプリフェッチが再開しないことと何か関連のある事象が起きないかというところ。
先週の足の怪我から一週間。 かなり治ってきた。 動かすとまだ少し痛みが出るが、普通に歩けるぐらいになった。 今朝は寝ぼけてスタンドミラーの足に軽く指をぶつけたが、特に悪化しなかった。 親指は青あざができていたのが、今はほとんど治っているので、これは打撲的なやつだったか。 そして人差し指は腫れていたのがかなり引いてきたが、まだ付け根側の関節部分は少し腫れていて、これはねんざ的なやつだったかな。
add 命令で試していたが cmp 命令だとどうなるか? 基本的には同じはずなので一部だけ確認しよう。
同じっぽい。 オペランドの順番を入れ替えても同じっぽい。cmp 命令の場合結果はフラグ以外は捨てられるので順番は関係ない。ALU の入力に入れるのにも時間はいらないようだ。 それで、書き込みも試したいが add 命令だと読み取り後の書き込みになってわかりにくいかも。 その前に mov 命令を試す。 読み取りが 8+EA, 書き込みが 9+EA で、読み取りは add 命令より 1 クロック短いだけだ。 まずは mov (%di),%cl (8a0d) を試す。 予想としては add 命令の最後が 1 クロック短くなった形。 また一部だけ確認しよう。+EA が 5 クロックなので注意が必要だ。
良い感じ。 書き込みも見てみよう。 書き込みは、+EA 計算直後には書き込みは行われないのではないか? 例によって書き込みのバスサイクル T4 で次の命令が始まっているのではないか? という予想をしているが、それだと +EA 計算後に 4 クロック空くことになるなぁ。 どうかな。
@(xy) = c7064101ebbd c7043x3y 31c0 8006800002 7902 cd20
うーん、めちゃくちゃパターンが少ない。[2T4] までが 2T4, [3T1] 以降は 3T2 に見えるが、そんなのあり得るのか? あるいは 2T4 でなくて、3 バイトでメモリー書き込みの T4 でも、99 の 5 クロック後には 3T1 になるので、それはそうかも知れないのだが、これ 4 バイトだと成り立たないんじゃないかという気がするんだな。1 クロック目が T4, 2 クロック目はアイドル、3 クロック目が 3T1 となると、次の命令では 3T4 になってしまうので、99 ひとつ入れても出力は 2 のはず。 ここで 3 クロック目までアイドルなら 3 になるけど、そうなのか? 同じ想定で 90 のほうも見てみるか。3 バイト、メモリー書き込みの T4 から 90 で 3 クロックだと、2T3 になるので成り立つ。4 バイト、メモリー書き込みの T4 から、2 クロック分のアイドルがあるなら、次は 3T1 になり、やはり成り立つ。 ふむ...
つまり、1 バイト目、2 バイト目、EA1, EA2, EA3, EA4, EA5, 謎 1, 謎 2, 謎 3, 謎 4, 書き込み 1, 書き込み 2, 書き込み 3, で 9+EA ということか。
そういうことなら実行時間の計測のほうもやって検証しよう。
あれ? [3T3] と [3T4] が違うなぁ。 計測結果で見れば [3T3] は追加ありだし [3T4] は (補正をしそこねたが [3T3] と同じということは) 追加無しだ。[3T3] だけなら、キュー満タン時のアイドルの関係で何か追加が発生するのかもと考えられなくもないが、[3T4] はこれでは説明ができない。 んー? わからん...
きのうのもだ。 おとといの推測では [3T4] の時はキューの休みを挟んでさらにプリフェッチ中止があるので、[3T1] と同じにならないとおかしいのに、ならない。(同じに見えるのは、前を 1 クロック伸ばしたのに、後ろの aad 命令をこれ以上短くできないから。) 何かを間違えている気がする。 なんだろう。
ふと気づくと個人向け PHS サービス終了まで残り半年なのだった。2 回線は最後まで使うけど、1 回線は早く契約変更せねば。
今月は、無事にイギリスの EU 離脱が進んだのはいい話だが、新型ウイルスの拡大はよくない話だった。 しかし、新型ウイルスに対して取れる対策というのが、インフルエンザなどの既知のウイルスと同じ、ということで、手洗いとか、あんまり人混みに近づかないとか、睡眠時間を確保するとか、そういうことしかしていない。 麻疹、風疹のほうがよっぽどやばいという話もある。
新型コロナウイルス どれぐらい警戒したらいいの？ 感染症のスペシャリストに聞きました
マスクが品薄という話はまだ実感がないけど、たまたま 4 日にコストコで買った 150 枚入り (1498 円) があるので、とりあえず今年の花粉シーズンについてはこれで足りると思う。
謎解きのために lods %ds:(%si),%al も見る。1 バイト命令なので少し違った面が見られるかなと。12 クロックの命令。
@(xy) = c7064101ebbd c7043x3y 31c0 8006800002 7902 cd20
読み取りは変に次の命令の始まりに重なることがないので、推測結果も書いておいた。[1T2] 開始で次が {1T4} ということはメモリー読み取り後に 3 クロックあってプリフェッチが進んでいることが伺える。 それで [1T3]〜[2T2] まで同じ傾向ということは、きのうまでの考察からして 6 クロック目がメモリー読み取りの T1 で、[1T2] では 4〜5 クロックがアイドル、[1T3] では 1 クロック追加と考えられる。6〜9 クロック目が読み取り、10〜12 クロック目が残りの 3 クロックなら特に変なところはないかなと。 一応実行時間も見ておこう。
[2T1] から [3T3] まできれいに考察通り。[3T4] は長くなっているなぁ。 通常であれば 4 クロック目でプリフェッチの準備をするところ、それがメモリーアクセス要求があるために中止になって、それで 5 クロック目がアイドルになって、さらに 1 クロック追加になった、と見ればいいのだろうか。 確かにこれならそういうふうに見てもよさそうだし、あまりにシンプルで、きのうの謎にはつながりそうにない。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU