レンタルカート。 藤野。5 回分で最初に 10 分走行の 4 回乗ってベストタイムは 39.242 秒ぐらい。
バイクはまた FI エラーが発生。 そこでキーの差し込み口をマスキングテープで隠した上で KURE CRC 5-56 をキーシリンダーの周囲に吹きかけてみた。 その後再発せず。 そんなに高い頻度で動かしていないから、変にエラーが発生するとバッテリーが心配になる。
中央道のバス停付近で赤色灯をつけて待機する覆面パトカーを見かけた。 その後赤色灯をつけたまま追い越し車線をスーッと走ってきて、前のフィットのスピード計測かと思いきや、ブレーキ踏んで走行車線に移ったフィットはそのまま走行を続け、覆面パトカーは赤色灯を消して隠して IC を下りていった。 自分も下りたんだが、あの覆面パトカー、赤色灯を消していたのにランプの制限速度は完全に超えていたように見えた。 さすが警察、コンプライアンス何それおいしいのって感じかな。
cmp で、+EA を変えて実験。MOV CS:
実行時間:
こうして見ると明らかに [3T4] のケースだけ矛盾がある。MOV CS のほうで 3a09 (+EA=8) の場合に 3 が出てしまっているところから説明できない。 これを説明するには 3T4 の次のアイドルが 3 クロック分ではなく 2 クロック分としないといけない。 しかし、そうすると先日の満タン時の挙動調査結果との矛盾が生ずる。 そのためちょっとやり直してみる。[3T4] のところ、8d10 2 個相当を今回の方法で試す。/ の後ろがキューとバスサイクルの推測、| は MOV CS のところ。
1 バイト 2 クロック命令としてプリフィックスを使ったのが悪いわけじゃないことを下半分で確認した。 さてこれの 3T4 の次のアイドルをひとつ縮めてみるとすると、最初のふたつは変わらないが、残りのふたつがおかしくなる。 ちょっと 3 クロック命令も試そうか。
これもやっぱり 3 クロック分のアイドルがないとつじつまが合わない。 ハァ? こうなったら実行時間も見てやる。 どれもキューは枯渇していないから、MOV CS の代わりに aad 命令を持ってくる。 ふたつ使ってかけ算の時間で全体の時間を一致させる。
気持ち悪いくらいぴったり。 ということで命令の実行時間を間違えたわけでもない。 あとは... 2 バイト命令だと違うのか?
はぁ、違った。 最初の lea 命令は結果を見る限り 3T4 の次のアイドルは 2 クロックだ。 それに対して即値の add 命令だとアイドルが 3 クロックだ。 つまり 2 バイト命令だからではなくて、2 バイト目がすぐに取り込まれるかどうかだ。 先月の実験により、aad 命令の即値の取り込みが 3 クロック目らしいことを把握していた。 これは aad 命令は実行時間が長いために確認できたわけで、実行時間の短い add 命令では確認できないなと思っていたんだけど、今回の発見により、やはり Mod-R/M バイトのない命令の即値は 2 クロック目には取り込まれないことが確認できた。 一応これも実行時間も確認しておこう。
569C が出る場合もあったが誤差と言える。 やっときのうまでのメモリー読み取り時の謎が解けた。
これでおとといのメモリー書き込みの件も説明できるか? [3T4] については今日の結果から見ると 3T4, 3--, 2--, 2T1, 2T2, 2T3, 2T4, 3T1, 3T2, 3T3, 3T4, 書き込み 1... となるので追加無し、で説明できそう。[3T3] は... 3T3, 2T4, 2T1, 2T2, 2T3, 2T4, 3T1, 3T2, 3T3, 3T4, 4--, 4--, 書き込み 1... で、書き込みの手前にひとつ追加ありってことかなぁ。 キューがいっぱいになったらそもそもプリフェッチは始まりもしないので中止の必要はない。 アイドルサイクルが入るのはプリフェッチの中止とは別の理由なのか。T4 の時点で次のプリフェッチかメモリーアクセスの準備ができていれば待ち無し、できていないと次の 2 サイクルが必ずアイドルになる?
おまけ: [1T1] スタートで 99 を並べた時の MOV CS の結果:
上の内容を振り返っていてこれが試せることに気づいた。[3T4] のところに 1 バイト 2 クロック命令を入れるとその 2 クロック目から 3 クロック分アイドルになるので、その直後に 2 バイト 2 クロック命令を入れれば 4 クロックで 3 バイト消費できて、キューが残り 1 バイトでプリフェッチが動き出したところからスタートできる。 あっ、同じことは即値の読み取りが 2 クロック目に行われないことを使えば 3 バイト 4 クロックの命令 b80000 でもできるな。99 の次に b80000 を入れれば結果は同じ。
1 のビットの数を数えるプログラムをどう実装すれば速いか。 テーブル参照はぱっと思いつくけど、キャッシュがきかないとかえって遅くなりそう。 今時のプロセッサなら、並列に演算を開始できるように考えてゴリッと力業を使ったほうが速いのでは?
というわけでテストプログラムはふたつのソースコードにわけて書いた。 わけたのはコンパイラーが変にインライン展開するのを避けるため。 それで、32 ビットの値を対象として、内容は以下:
実行結果 (Ryzen 7 2700, gcc 8.3.0, taskset 16):
-O: 0.171872008(201326592) 1.443574720(201326592) 0.111342125(201326592) 1.443538042(201326592) 0.168950192(201326592) 1.443555185(201326592) 0.127162359(201326592) 1.443558381(201326592) 0.28712172(201326592) 3.153227359(201326592) 0.44871870(201326592) 3.495349924(201326592) 0.264607494(201326592) 1.443543646(201326592) 0.110752566(201326592) 1.443546311(201326592) 0.36917886(201326592) 1.443557733(201326592) -O3: 0.174949853(201326592) 1.443437555(201326592) 0.113951287(201326592) 1.443436793(201326592) 0.171209191(201326592) 1.443452774(201326592) 0.127166406(201326592) 1.443441353(201326592) 0.24609756(201326592) 3.117030505(201326592) 0.42470234(201326592) 3.499085332(201326592) 0.228806809(201326592) 1.443456774(201326592) 0.110759067(201326592) 1.443423402(201326592) 0.31331545(201326592) 1.443462776(201326592) -march=native -O3: 0.184675865(201326592) 1.443803763(201326592) 0.112326115(201326592) 1.443834360(201326592) 0.198460806(201326592) 1.443790259(201326592) 0.127170050(201326592) 1.443758110(201326592) 0.24610608(201326592) 3.145536662(201326592) 0.42469231(201326592) 3.499107884(201326592) 0.220397180(201326592) 1.443717026(201326592) 0.114854077(201326592) 1.443807235(201326592) 0.31125829(201326592) 1.443724441(201326592)
上から下へ test1 から test9 まで、左は単に一定回数試行した時間、右はテーブルのキャッシュクリアをしながら一定回数試行した時間。 キャッシュがきいている場合 test2 と test8 が明らかに速く、キャッシュクリアをはさむとテーブル参照のふたつ以外が横並びになる。 はっきりしたのはキャッシュ関係なくテーブル参照は遅いってことだw あとコンパイラーの -O3 最適化によるループ展開は案外期待できないということか。 キャッシュクリアすると分岐予測か何かにまで影響が出るっぽいのもわかった。C で書くなら test8 のように安直に展開して書くのはあり。 下手に演算回数を減らそうとすると、演算結果が出るまで待つのに時間を食って、test9 のように遅くなってしまうので、結果を待たずに演算を開始できる部分をうまく活用するのがポイント。 並列にできるところがわかるように書いておけば、あとはコンパイラーががんばってくれる。
バスのステートまわりの話、わかったことをまとめて整理したいんだが、簡単なプログラムで表現しようとして少し書いてみたところ、行き当たりばったりのクソみたいなソースコードができそうになったので、その前にステートマシンとして整理したい。
┌─────────────┬─┐ │ ┌───────┐ │ │ │ ↓ │ ↓ │ └→T1→T2→T3┬─→T4→Ti→Ti─┘ ┌┘┌┐↑ │ ↓││ └→TW┴┘
超簡単な話としてはこれなんだけど、これだけだとプリフェッチ絡みの話が見えないので、そこを含めていきたい。 と思っているんだけどきれいにまとめるのはなかなか難しそうだ。
バイク用品店に寄ったのでグローブの試着。 冬用グローブがだいぶ痛んできたので、そろそろ買い換えてもいいかなと思っていたところだし。 しかし...... 3XL/3L の少ないこと少ないこと... おまけに、一部存在した 3XL/3L も冬物は小さすぎる... 今使っているものより小さい... これは厳しい...
小さいパターンとして、短すぎるやつと、細すぎるやつがある。 特に親指が厳しくて、バイクの運転操作に支障が出るようなものばかりだ。 インナーグローブや夏物だと柔軟性があってまだ何とかなるものもあるんだけど、冬物はもう、試着した瞬間に、あっ無理だな、みたいな感じだ。 もう海外通販サイトしかないのかな。 それも最大サイズを選んでそれで入るかどうかは運だけど。
2 月になっても最高気温が 15 度など冬にしては暖かい日が続く。 ランチの時間帯、コートを着なくてもフリースだけで大丈夫な気温である。 天気予報では木曜日以降最低気温が氷点下になっている。 いよいよ冬本番か!? (2 月だけど)
リングフィットアドベンチャーのワールド 9 のボスを倒したんだけど、軽い気持ちでセットしてみたモモアゲコンボ、左ひざあげて右ひざあげてスクワットで、なかなかきつかった。
これよりも立木のポーズのほうが攻撃力高いってどういうことだよ...
バスステートの話の何が難しいって、T1→T2→T3→T4 の変化はふつうにクロックの立ち下がりなんだけど、次に何をやるか決めるところはクロックの立ち上がりなんだな。 何をやるか、というのはマキシマムモードで S2, S1, S0 に出る信号の話で、100 ならコードフェッチ、101 はメモリーの読み取りで 110 はメモリーの書き込み、などとなっている。 これは T1 になるよりも手前、立ち上がり時点で出て、T2 の終わりまで出続けるらしい。
まぁ、どこからどこまで出るか、というよりも、例えばプリフェッチキューにすでに 3 バイトあって、4 バイト目をプリフェッチしている時、T3 で次の命令を取り込むと、T4 の時には 3 バイトになっているから、プリフェッチは続行されるが、T4 で次の命令を取り込むと、プリフェッチはいったん休止される、という動作を考えたときに、T3 の時点では次のプリフェッチを続けるかどうかの決定はできないことになる。 いや、厳密には取り込むと言っているのは QS1, QS0 に 01 (最初のバイト) とか 11 (最初以外のバイト) とか出るクロックサイクルのことを指していて、そのひとつ手前のクロックサイクルで見てはいるんだと思う。 しかし、それだけじゃなくて、T3 の次には READY 信号により TW が入る可能性もあるので、やっぱり T3 の時点で次の動作は決められないわけだ。T4 の間の立ち上がりの時点で決定されるんだと思う。
ってことを考えれば状態遷移図は立ち下がりで動く部分と立ち上がりで動く部分は分けて考えないといけなさそう。
それから、BIU にある IP はプリフェッチのアドレスなのか、EU から見たアドレスなのか、不思議に思っていたけど、答えは資料に書かれていた。 フェッチのアドレスらしい。 ジャンプ命令など相対番地を使う命令や、コール命令や割り込みなど戻り番地をスタックに書き込む命令では、どうやらそこから元のアドレスを計算するんだな。1 や 2 の足し算引き算は BIU 側で行えそうなので、プリフェッチを停止して IP を求めるのも BIU 側の仕事かな。
象印の加湿器 EE-QA30 のクエン酸洗浄を行った。 8 年前に買ったスチーム式の加湿器で、冬場の特に湿度が低い時に寝室で使っているが、やっぱり 1〜2 か月使うと音が大きくなってくるみたいなので、クエン酸洗浄したほうがいいようだ。 この、電気ポットにそっくりな作りの加湿器、そんなに使用頻度も高くないので寿命は結構長いのかも知れない。
TVer で見ているテレビドラマ、『ゆるキャン△』のほかに、『女子高生の無駄づかい』というドラマを見つけて見てみたらまったくもって意味不明なギャグドラマだったがなんとなく 2 話まで見た。 これも原作は漫画らしい。
『フルーツ宅配便』のテレビドラマ版もまた再放送か何かをやっているみたいで TVer で 1 話ずつやっている。 去年 1 話を見損ねたと書いているが、今年も見損ねたな。 まさかやっているとは思っていなかったしな。
朝から泌尿器科へ行く。 最近ちょっと夜中トイレに行く回数が明らかに多いので。 最初の診察の後、超音波検査をするので水分を取りながら 15 分くらい待っていてと言われるも (膀胱に溜まった状態で見るらしい)、すでにトイレに行きたいくらいになっていることを伝え (1 時間前にトイレに行ったのに... って、原付で移動した時に冷えたせいかな)、5 分後ぐらいに超音波検査。 健康診断であるやつと同じ、でも腎臓と膀胱まわりしか見ないのですぐに済む。 腎臓は問題ないらしく、膀胱のほうは、前立腺が年齢の割に少し大きく見えるそうで、腫れているのかもと。 あとは尿検査、それから超音波で残尿の量をチェック、これは映像ではなく、量をチェックするだけの電池駆動の小さな装置で行われ、30cc 程度? 残っているという。 ほーん。 尿検査結果は尿が少し濃いそうで、昼間はじゅうぶんに水分を取るように、ということと、冷えないように暖かくして過ごせ、ということと、食べ物は、刺激物、辛い物などを避けるように、とのこと。 そんな感じでとりあえず薬が処方されたので様子を見る。
バイクで秋葉原まで行って、昼食後、上野にあるバイク用品店とやらを見てみた。 上野は昔はバイクショップが多数あった場所らしい。 今も少し残っているので行ってみたが、聞いてみると手袋の取り扱いは 2XL が最大サイズだと言う。 それじゃあ買えないな。 こっちは 3XL より上がほしいんだ。
しかし上野駅もなんかずいぶん変わった気がする。 茨城県に住んでいた頃でも常磐線はほとんど使わなかったが、高速バスの降車場所としては何度か使ったはず。 駅前にペデストリアンデッキがあるという記憶はそうなんだけど、なんか前はもっと違ったような... いや、高速バスの降り口は、あれあのまま秋葉原方面に進んで東京駅まで行くんだから、東側か。 そっち側から見ると案外変わっていないのかな。 でも上野駅って、昔は栄えていたんだろうけど、上野東京ラインができてしまった今、東北方面への玄関口としての役目は終わって、寂れていく方向なのかな。 鹿児島で言うところの鹿児島駅みたいな... いやいや、あそこまで寂れてしまうとアレだが...
そしてアメ横を通った。 アメ横は観光スポットでもあり、外国人観光客らしき人も多い。 明らかに外国人の店員さんがやっている店もあるし、すごく独特な雰囲気のあるところである。 なお、輸入手袋を売っているような店は見当たらなかった。
っていうか、buying large gloves in tokyo みたいなキーワードで Google 検索しても、ろくな情報は見つからないのである。 これが shoes なら多数見つかる。 ということはだな、外国人でも、靴のサイズが合わなくて困っている人は多数いるけど、手袋のサイズが合わなくて困っている人はいないということでは。 やっぱり、外国人のほうが足が大きい人が多いのは事実としても、手が大きいというのは幻想なんだな。
さて、そんな感じで歩いて秋葉原に戻り、Raspberry Pi 4 を買って、スーパーポテトなど見てから帰った。 ゲームコーナーに『ダイナマイト刑事』があって... これだよ、去年遊んだのはこれのアメリカ合衆国版の Die Hard Arcade だよ。 帰りは甲州街道を走っていたが面倒になったので、首都高を高井戸までの 2 区間くらいだけ使った。ETC カードをセットしておいていなかったので、一般利用にしたが、高井戸まで乗るので距離別にはなるし、まぁいいか、と。 後で調べたら ETC 利用時より 20 円高かったらしい... まぁいいか。 どうせ首都高はマイレージポイントつかないしな。 なお、首都高の一般料金所を使うのは久しぶりだったが、なんと有人ゲートではなくなっていた。 車種識別中などと表示されて、ちゃんと識別されたけど、どうやっているんだろう。 ナンバープレート読み取りだろうか?
秋葉原何度か行っているのにいつも道がわからなくなるんだけど、アレか、万世橋に向かおうなどと考えるからいけないのか。 皇居のまわりを抜けるにしても、南側をまわるといつも時間が掛かる気がする。 御茶ノ水駅あたりを経由するのが正解なのかな。 東京医科歯科大学から気象庁前まで、まっすぐ抜ければ、ああ、右折できないじゃん、気象庁前... 結局ギザギザ通るしかないのか... そうすると靖国通りもアリだな。
いままで 1T2 スタートと書いていたやつを、1T1 スタートとかんがえてみよう。 でもキューが減るのは 1T2 の終わりのままとする。 実際 QS1,QS0 に 01 が出るのが 1T2 の時なら、その前のサイクルで見ているはず。 そうすると、MOV CS で数数える実験で、満タンになった直後は 2 が出ると書いていたのが、3T4 では 2 が出るとなるし、ステートマシンを書くのがやりやすくなるのではないか。
しかし、気になってくるのは、メモリー書き込みを行う命令で書き込みの最後の T4 の時点で次の命令が始まっているというやつ。 ひとつ前と考えるなら T3 の時点で始まっていることになる。 まぁ、EU と BIU の独立性を考えれば、書き込みアドレスとデータを渡した時点で終わりというのは不自然ではないんだけど、READY 信号により待ちが追加される場合にどうなるかだ。Atari Portfolio は RAM はスタティック RAM で待ちは入らないようだけど、ROM か、あるいは I/O ポートで待ちが追加されるところがあれば、実験できるなぁ。 でも、I/O ポートも PC とは構成が全然違うみたいなので、Portfolio Technical Reference Guide に載っている I/O ポート以外は、わからんなぁ。
そんなわけで... とりあえず I/O ポートの読み取りで時間が掛かるものがないかを探してみよう。 読み取りで時間が掛かるなら書き込みも時間が掛かるだろう。 一定時間当たりの実行回数を調べるやつで。
ウーン、これじゃ日が暮れてしまうな。 もうちょっと工夫を。
ウーン、手当たり次第じゃだめか? TF の実験プログラムを使おう。
よーし。EA100000E0, つまり ljmp $0xe000, $0x10 である。 そのあたりにリセット時の処理があるんだな。 そうするとだな、そのあたりに何かあるはず?
ほう、ba0080 が見えるところを見ると、やっぱり 0x8000 のあたりなのか。 ウーン。 じゃあ READY 信号は使われていないということか。 いや、諦めるのはまだ早い。ROM を見てみよう。RAM と比べて遅いことはないだろうか?
なかった... これは Portfolio で試すのは拡張デバイスを自作でもしない限り無理か...
きのうの夜からやたら冷えていたが、今日は昼間もめちゃくちゃ寒かった。 冬だ。
8088 の READY 信号の時の挙動、そういえば資料に載っていた例では、通常 55 クロックサイクルのところ、10 回あるメモリーアクセスが 5 クロックずつ掛かるなら、65 クロック... ではなく、64 クロックになるという説明があった。 詳細はない。 なるほどと試しに紙に書いて追ってみたところ、62 クロックになってしまった。 あれ? そこで気になったのは、15 クロックとされる 2 バイト jmp 命令においてどこでプリフェッチが中止されるのか、である。
資料の図では、1 クロック目 (QS1, QS0 に 01 が出た時) から、プリフェッチの T1 サイクルが始まっている図で、4 つのアイドルを挟み、9 クロック目に QS1, QS0 に 10 (queue emptied), 11 クロック目から次のプリフェッチの T1 が始まり、15 クロック目にはもうひとつ次のプリフェッチの T1 で、その次の T2 から実行が始まるという流れ。 スタート地点を変えてみることはできるので、さっそく試してみた。 秒当たり実行回数計測。 ジャンプ後に時間の長い命令を入れてキューが埋まるようにし、さらにかけ算で時間調整した。
こんな感じで、1 クロックずつずらしているのに結果は 4 クロック単位、みたいなことになった。 これを見ると、資料と同じようにプリフェッチの T1 から始めた時が最速の 15 クロック。1 クロックずらして T2 からになると、一番遅い 18 クロック。18, 17, 16, 15 クロックの 4 種類あることが読み取れる。[3T4] はあとで考えることにして、ひとまずこの 4 種類を理解する。T1 は資料と同じなので手っ取り早い。
シンプルにこういうことなのかな。3 クロック目が 2 バイト目 (QS1, QS0 が 11) になっているので、4 クロック目に T4 なら間に合って、それ以外はよけいにフェッチしてしまうんだろう。 確かに、IP 計算のためにプリフェッチが終わるまで待つ必要があるというのはありそうな話。 そうすると、その 62 クロックだったやつも、計算し直すと 66 クロックに... あれ? まだだめか。 もうちょっと見直してみないとだな。
最後に [3T4] のケースを考えておく。3T4 3-- 3-- 2-- と来れば T1 と同じでプリフェッチは始まらなさそう。 とすれば 15 クロック。 その前の [3T3] が 17 クロックで、[2T4] などのように 16 クロックかかるなら d500 で結果が一致したところ、15 クロックで済んでしまうので d501 で一致することになった。
テレビでやってた映画『名探偵コナン 瞳の中の暗殺者』。2000 年のアニメーション邦画。 記憶喪失もの。 コナンは「新一兄ちゃん」に頼ることなく、かつ、銃を持って殺しに来る犯人の目の前という極度のプレッシャーの中で、難事件の謎をやすやすと解いてみせてしまったが、その途中経過を覚えている蘭はコナンの正体に疑問を持たないのかw
おととい、上野を歩いていた時に見かけた大学、「第一工業大学 上野キャンパス」。 どこかで聞いたような大学だなー、と思っていたが、検索してみたら、霧島市にある私立大学の名前だ。 そうだ、あそこか。 なんで上野に... しかも、ちゃんと上野キャンパスだけで授業をしているようだ。 私立大学はすごいなぁ。 名前も「第一」だもんな。
おととい、上野を歩いていた時、一時的に鼻に痛みを感じた時があった。 花粉の季節によく感じるアレだ。 花粉が飛ぶにはまだ早... くもないらしい...
暖冬で花粉の飛散が早まる 東京など関東は2月中旬からピークへ - ウェザーニュース
なお、たまたま買っておいたマスクが 150 枚あるのでマスクの準備は万全である。 自分は花粉症ではないけど、マスクの入手が難しいとなると、花粉症の人は大変だろうな。
資料の 5 クロックメモリーアクセスのパターン、見直してみたら 63 クロックになってしまって、まだ 1 クロック足りない。63 クロックになったのは、最後のほうの 4 バイト 4 クロック命令の 2 クロック目、全体の 52 クロック目に、キューが 3 バイトの状態でプリフェッチの T4 になっているので、その次はアイドルになるところを見落としていたことによる。 次々にフェッチが進むので、ここは 2 クロックだけアイドルでプリフェッチが再開するものと考えた。 そうすると 55 クロック目には再開、59 クロック目に T4 で、60〜63 クロック目がアイドル (きのうの調査より) となって、次が queue emptied かなと。
でもよく考えてみると、80C88 で確かめた時にアイドル 2 クロックだったパターンは、3T4 で 1 バイト目、その +1 が 2 バイト目で、+2 時点でふたつの空きがある状態で +3 から再開だったというやつ。 同じようにこの 8086 のを見ると、4T4 で 2 バイト目、その +1 が 3 バイト目で、+2 時点で残り 3 バイト。2 バイト単位のフェッチになる 8086 では、まだひとつ (1 回分) しか空きはないと言える。 そういうふうに見れば、3 クロックアイドルになるので確かに 64 クロックになる。 ま、8086 が手元にあるわけでもないし、そういうことにしておこう。
ふたつ空きがあるかどうか、というのは、プリフェッチの T4 時点で次のプリフェッチを準備するかどうかの条件と考えられる。T4 が終わればひとつ埋まってしまうので、ふたつ以上の空きがなければ次のプリフェッチは連続して入れられない。 それで T4 からアイドルに移ると、別の実験で明らかになったとおり、最低 2 クロックのアイドルがある。 その 2 クロック目のアイドルの時点では、まだ条件が変わっておらず、ふたつ空きがあるかどうかが条件になっているのかも。 ふたつ空きがあれば 3 クロック目で再開だけど、そうでなければ 3 クロック目まで来て初めて、ひとつ空きがあるかどうかに条件が変わり、その次からプリフェッチが再開されるという仕組みと考えると、上の 8086 の挙動の推測も含めて、説明できそう。
なお、もともとこの資料の説明を検討してみようと考えたきっかけの、肝心のメモリー書き込みの部分は、次の命令が TW からでも T4 からでも、結局次の命令の後はキューが枯渇してしまい、プリフェッチ待ちになってしまうので差が見えないことがわかった。 ふーん。
コストコまでスクーターで向かう途中、だんだんアイドリングの回転数が低くなってきたなぁ、と思っていると、そのうち回転数の低いところの吹け上がりが悪くなってきて、これはまたオートチョークの配線の接触不良だな、と思って、途中の信号待ちでコネクターを付け直して、しばらく走ると復活。 まぁそれはいいとして、めっちゃトイレに行きたくなっていて、途中のガソリンスタンドのトイレに駆け込んだw 声をかけてとあったので声をかけたが、その後給油をしていたら、お客さんだったら声かけてもらわなくてよかったのに、という店員さん。 なにやら、近くに駅があり、通勤時間帯などに徒歩の人がトイレだけ使っているケースがあってそんな表示をしているらしい。 せっぱ詰まった状態でそんな背景まで推測する余裕はなかったw
スクーターのあの配線はやり直したいんだけど、長さがギリギリなので延長が必要なのと、作業のためにはおそらくカウルを外さないといけなくて手間が掛かりすぎるのがなぁ。 カウルを外さずに済む範囲でもう一度見てみるかなぁ。
映画『翔んで埼玉』、テレビでやってたらしい。
Mod-R/M バイトと即値の両方があって、メモリーを読み取る命令では、即値の取り込みはどのタイミングで行われるのか? 予想では、メモリーの読み取りが先に行われるのではないかと。+EA の計算のために ALU を使うので、先に ALU の入力側テンポラリーレジスターに取り込んでしまっては都合が悪い。 確認には cmp 命令、10+EA を使う。
この予想が当たっているなら、3 バイト命令でメモリー読み取りの後 4 クロックあって、メモリー読み取りの前にもプリフェッチ 1 回分の時間はあるから、その次は 2T1 か 3T1 開始ってことになりそう。MOV CS の実験プログラムで試す。
@(xy) = c7064101ebbd c7043x3y 31c0 8006800002 7902 cd20
あちゃ、予想が外れたかな。(%bx,%si) と (%bx,%di) は (%si) と比べて純粋に +EA 分の差が出ているだけでシンプルだけど、次の命令が T2 から始まるとは。 この予想ではメモリーアクセスは +EA 計算の直後と考えているので、メモリーアクセスを 1 クロック手前にすることはできない。 そうするとメモリーアクセスがさらに 3 クロック遅れ、メモリーアクセス後が 1 クロックしかない流れになる。 いや、待った。[3T1] 開始で {3T2} になるとはいったいどういうことだ? どこに 3 バイト目をフェッチする時間があるんだ? こうなると実行時間のチェックもするしかないか...
ふむ。803c00 は 15 クロックのはずだった。999999 は 15 クロックだが結果が一致しない。 最初の実験で最低でも {2T2} だったことから、803c00 の次の d5ff でプリフェッチ待ちは発生していないはずだし、27 をひとつ 99 に置き換えると一致するところを見ると、16 クロックであれば矛盾がない。 また資料が間違っているのか!? なお、cmp 命令と比べるのにちょうどよい test 命令は、メモリーと即値オペランドの場合 11+EA となっているので、同じオペランドを使えば 16 クロックになる。 これも見てみようか。
cmp 命令と test 命令の実行時間が完全に同じじゃないか... おいおい... 10+EA は嘘だったのかよ... そうすると 803c00 は 2+5+4(Read)+5 と見るといいのか?
ふむ。 即値を取り出すタイミングは多少違うかも知れないけど、それを除けば基本的にはあってそう。[1T2] と [1T3] の時間を確認すれば確定できるか。
え? と思ったけど、そうだ、cmp 命令の前が 1 クロックずつ減るのと同時に、cmp 命令が 1 クロックずつ増えて、合計は同じになるわけだ。
これらも合っていた。 なるほど解決!
Raspberry Pi 4 Model B の動作確認をしようと思い、ドンキホーテで Micro HDMI の変換アダプターを購入。 それから microSDXC カードを準備し、配線をつないで電源を入れたが、起動する気配なし。 ウーン。 調べると EEPROM が飛んでいると動かないそうで、確かめるには microSD カードを外して電源を入れろとある。 試してみるとまったく LED が点滅する気配がなく、EEPROM がだめか?
それで、microSDXC カードを Recovery 用に書き換えるため、アダプターを介して PC に入れたところ、認識されなくなっていた!! 何度も試したし、アダプターのいらない別の PC にも入れてみたがまったく認識される気配がない。 試しに別の microSD カードを同じアダプターに入れてみたところ認識されたため、どうもカードが死んでしまったようだ。 初期不良か?
購入店に電話して聞いてみたところ、microSDXC カードはともかく、Raspberry Pi 4 のほうは別のメモリーカードで確認してみてくれとのこと。 一応試してみたけどだめそうだ。 初期不良交換は持ち込みか。 秋葉原かぁ、こういうとき近所じゃないのは面倒だけど、幸いあさってが祝日なので持っていくことはできそうだな。
いろいろとわかったことをエミュレーターに反映したいのだが、どう書くか。 もともと書いていたのは以下のような switch-case 文だ。
opcode = get1 ();
switch (opcode) {
case 0x00: getmodrm (); E_ADD (rmc, rc, 1); br;
この E_ADD がまぁ変なマクロでわらわらと展開されて、クロック数を求めつつ実行するんだけど、なんと、Mod-R/M バイトのオペランドアクセスのタイミングで、足していっている。 一応 BIU の部分を分けて実装はしていたんだけど、プリフェッチキューから取り出すタイミングではクロック数を特に足しておらず、オペランドアクセスのタイミングで足すので、オペランドの順番によってメモリーアクセスのタイミングが変わるし、実際の挙動と見比べると、明らかに間違いである。
じゃあどうするか、というと、まずプリフェッチキューから取り出すところで 1 クロック足すのは当然として、ちゃんと処理の順番を意識して、1 バイト目取り出し、2 バイト目取り出し、EA 計算、メモリー読み取り要求、みたいな形にしないといけない。 しかし、別にマイクロコードレベルで考える必要はない。 例えば add (%si),%al を実行するとして、2 バイトの取り出しに 2 クロック、ここはキューに入っているとすれば単に足すだけ。 それから、EA の計算で 5 クロック足す。 するとその次にメモリーアクセスなのだが、このタイミングで足されていた 5 クロックを見て、プリフェッチを進める。 次がメモリーアクセスなのはわかっているので、残り 2 クロックになったらアイドルに落とす、的な処理をここですればいい。 今までも BIU 側を独立させてプリフェッチかメモリーアクセスを進めるかというふうにはしていたが、メモリーアクセスの要求があったらプリフェッチを終えてすぐにメモリーアクセスを処理するようにしていたので、EA の計算で 5 クロック足しても、その 5 クロックの間にメモリーアクセスが始まってしまうという謎な動きになっていたんじゃないかと思う。
注意が必要なのはプリフェッチに使う %cs だな。 ふつうに書いたら T1 に移る時点での %cs を使ってしまうが、ひとつ前の時点での %cs を使わないといけない。 まぁ、MOV CS と POP CS を気をつけて書くことにして、EA 分はまとめて処理してしまうのがよさそう。
スクーターのオートチョークの配線、Google 検索するとカウルついたままで作業できているっぽい写真も見つかるので、見てみたけどやっぱりそんな長さはない。 もしかして、前のオーナーの時点で不良が発生してやり直したんだろうか。 とにかく面倒だけどカウルを外すしかなさそう。 いや、検索で出てきた写真を見ると、カバーを外せばいいのか? カバーだけ外せるのか? 反対側だけど点火プラグ交換の作業写真を見るとサイドカバーだけ外しているなぁ。
無段変速のスクーターの運転に対する違和感はすっかり無くなった気がする。 一定スピードを保つのは勾配の変化の具合によっては難しいけど、ある程度は慣れてきた。 アクセル操作には思っていたより高い精度が求められる。 クラッチが完全につながるスピードがけっこう速いので、超低速のノロノロ渋滞はある意味 MT バイクより苦手で、クラッチをいたわるため、クラッチが滑り続けないように意識している。
自賠責保険を 1 年にしたので、切れるのは今年、令和 2 年の 5 月である。250cc 以下のバイクはナンバープレートのステッカーにこの年月まで示される。 これって、令和 1 年の 5 月に入ったからそうなわけで、もしその 1 か月前だったら平成 31 年の 4 月だから、表示は平成 32 年の 4 月になっていたところだ。 つまり令和 2 年のステッカーは令和 1 年 5 月以降の 8 か月間に自賠責保険 1 年で入った人だけで、それの 5 月は令和で一番最初のもの、かなりレアかも。 そういえばスーパーカブ 90 まだ探してないなー。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU