テレビドラマ『新米姉妹のふたりごはん』も、テレビドラマ『孤独のグルメ 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