レンタルカート。 藤野。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 まだ探してないなー。
今日もやや寒い感じ、でも今週後半には暖かい日々がやってくる予報だ。 まぁ寒さはともかく乾燥がやばい。 寝室の湿度が 22% あたり、ここまで乾燥した部屋にいると何も無くてものどに違和感が出てくるような気がする。
すでに花粉が飛んでいるらしいので時々マスクの着用を始めた。
そういえば、メモリーの読み書きを一度に行う命令の調査を忘れていた。 例えば add %al,(%si) 的なやつ。16+EA となっている。 今までの推測結果から言えば、add 命令でオペランドが反対の場合の 2+EA+4(Read)+3 と、mov 命令でメモリー書き込みを行った場合の最後の 4+3(Write) を組み合わせて、2+EA+4(Read)+3+4+3(Write) みたいな感じだろうか。add %al,(%si) なら EA は 5、つまり以下のパターンになるはずだ:
キュー満タンで T4 開始の場合、MOV CS 実験をすれば、-T4 3-- 2-- 1T1 的な感じで 2 が出るはずだ。 一応確認しよう。
だな。 わざと後ろに命令を足してプリフェッチを再開させたほうが、良い実験になりそうだ。-T4 3-- 3-- 3T1 3T2 の 5 クロック、つまり 99 を足せば 3 が見られるはず。
よし。 あとは実行時間を確認すればいいだろう。 さっき書いたパターンの長さを数えれば、[1T2] から順に、26, 25, 24, 23, 22, 23, 22, 22, 21, 22, 21, 21, 22 となる。 ということは...
うむ、ここまで予想が見事にきれいにはまるとは。 今まで書いたやつは、少し試行錯誤して微調整して書いたものが多かったんだけど、今回は予想して書いたものを試したら、見事に全部一致した。16+EA の通りの 21 クロックになったのは、[3T2], [3T4] と [4+1] 開始の 3 種類だけか。 キューの空きが多いと、書き込みの前の 7 クロックのところが 1 クロック分伸びて、そこで 2 バイト分のプリフェッチが走ってしまうんだな。 まぁ、これは外部バス 8 ビットの 8088 だからこんな厳しい条件になっているわけで、8086 だったらもっと最速のケースが多くなるのだろう。
バイクで秋葉原まで行って、店頭に microSDXC カードと Raspberry Pi 4 Model B を持ち込んだところ、店頭のデモ機と交換して動作確認してくれて、Raspberry Pi 4 は大丈夫とのことで、microSDXC カードだけ交換になった。 ついでに店頭で動作しているのと同型の microSDXC カードを購入してきた。
さて、何が悪いのかわからないので近くのインターネットカフェに寄って、試してみることにした。 なんと今時は完全個室があるんだな。 上から下まで壁で仕切られ鍵まで付いている。 カプセルホテルよりセキュアじゃないか。 すげぇ。 ま、それはいいとして。 幸いパソコンに HDMI ケーブルがささっていたので引っこ抜き、パソコンに無線キーボードとマウスの USB デバイスがささっていたのでそれも引っこ抜いて、Raspberry Pi 4 につなぐ。 あとは自宅で書き込んできた microSDXC カードを差し込んで電源オン。...起動した。 マジか。 この microSDXC カードは自宅でも試したはずなんだけどな。 マジか。 それでログインして、OpenSSH サーバーが起動するようにだけ設定しておいた。
今日は四ツ谷駅の近くの対面通行の道を通って市ヶ谷駅近くに出て九段下方面を経由するルートを往復とも使った。 悪くはないかも? 調布でバイク駐車場が空いていたので、とめて台北飯店という店でランチ。 醤油系のラーメンだったけど案外美味かった。
で、帰って Raspberry Pi 4 を試すわけだが、ディスプレイは映らないものの起動はした。SSH でログインできる。 キーボードは Caps Lock は押しても光らないが Scroll Lock と Num Lock は光るし、イメージセンサーマウスも光る。 おかしいな、こないだもつないでいたけど反応がなかったのにな... ま、いいや。 なんか知らないけどそのうちなぜかディスプレイが映った。 映るようになった。 ハァ? たまにだめなことがあったけどその時でも再起動したら映った。 何もわからない。tvservice -o コマンドで電源オフにできるみたいなので便利。 なお tvservice -p すると電源はオンになるけど真っ黒画面、というときは chvt 2; chvt 1 などとすれば復活するみたい。
で、Raspberry Pi 4 で Mozilla Firefox を試したら、動いた。Tinker Board だと動かなかったから、自宅サーバーの置き換え候補にするのはやめたんだよな。 動くのなら置き換え候補にしてもいいな。 まぁ ARM で ATOK for Linux をどうするかは未解決なんだけど。 あとヒートシンクを調達したほうがいいという話がある。
バイクはまた FI エラーが発生した。 またしても給油後に。 それで何度か ON OFF をゆっくりと繰り返したがだめで、OFF とハンドルロックの間かな、ON にならない部分でぐりぐりぐりと何度も往復させてから ON にしたら大丈夫だった。 やはり接触不良なんだ。 何とか内部に 5-56 が到達してくれれば、このぐりぐり作戦で接点復活の効果があると思うんだが...
Displacement を含む +EA の確認と、LEA にレジスターオペランドを指定すると 2 クロックかどうかの確認。 メモリーアクセスを伴わないので実行時間だけ見ればよかろう。
完璧だ。(99 は 5 クロック命令なので、37 のほうがよかったかなと後から思ったが、5 クロックでも、4 バイト 8 クロック命令後の 1T3 が 99 で 1T4 に進み、d53f は 2 バイト目が 3 クロック目取り込みなのでギリギリ待ち無しである。) わざとデフォルトセグメントが違う (%bp) も入れてみたが大丈夫だ。 このへんは資料も間違えていないんだな。 あ、そうだ、あと displacement が何クロック目で取り込まれるかもポイントか。 たぶん 3 クロック目、2 バイトなら 3〜4 クロック目だと思うんだけど、境目だけチェックすればいいか。1 バイトなら [2T4] 2T1 1T2 がギリギリ、[2T3] 1T4 1T1 1T2 だと 1 クロック伸びる。2 バイトなら [3T3] 2T4 2T1 1T2 がギリギリ、[3T2] 2T3 1T4 1T1 1T2 だと 1 クロック伸びる。 どうかな?
一番シンプルそうなパターンですでに違った... ギリギリが [3T2] 2T3 2T4 2T1 1T2 かな (2 バイトが連続して取り込まれると仮定)、とすると displacement only の場合は 4〜5 クロック目か。 ふーん。 続けて 2 バイトの displacement から先に見てみよう。
1 回の足し算のケース。 ギリギリが [2T4] 2T1 1T2 1T3 1T4 2T1 1T2 になるので 6〜7 クロック目ということに。
2 回の足し算のケース。 ギリギリは [2T2] 1T3 0T4 1T1 1T2 1T3 1T4 2T1 1T2 になり、8〜9 クロック目ということになった。 きれいに 2 クロックずつずれている。
これも 2 回の足し算のケースで、+EA が 12 クロックかかる最悪パターンなのだが、なんと [2T1] 開始でもこの様子なので差を確認することができない。 これがギリギリだとすれば [2T1] 1T2 0T3 0T4 1T1 1T2 1T3 1T4 2T1 1T2 で 9〜10 クロック目だと見るのが素直だが、これより前にずらすと 2 バイト目がキューに載らなくなってしまうので試せない。 まぁいいか。 じゃあ 1 バイトの displacement で見てみよう... と思ったんだけど、2 バイトのケースを参考にすると 6 クロック目か 7 クロック目が怪しいわけだよな。 でも 2 バイト目があるので [2T1] より前にはできないから、このやり方では調べられないじゃないか。 うーむ。
いや、手はある。 例によって [3T4] で 2 バイト 2 クロックの mov 命令などを使い、続けて lea 命令を入れれば、[3T4] 3-- 2-- 1T1 0T2 というふうに、lea 命令の 2 クロック目に 1T1 を当てることまではできるはずだ。 さっきの 2 バイト displacement で試そう。
これだ。 手前にある 5 クロックを消して、代わりに後ろに 6 クロック入れてバランスが取れたということは、待ちが入ったということ。 やはり [2T1] がギリギリで正解だった。 さてそれで 1 バイトの displacement も試すしかなさそう。 時間が長いやつは無理だな。 足し算 1 回の 11 クロックのやつしか試せない気がする。
きた。 やはり 6 クロック目なのか。2 回の足し算になれば 8 クロック目あたりになるだろうから、それはもはやソフトウェアでは確認できないだろう。
最近調子が悪いので一か月半ぶりに整形外科に行ったら、診察からだった。 あぁそうか。 でも初診料は取られなかった。 ふうん... またちょっと集中的にリハビリテーション (電気治療と牽引) 受けて、よくなったらまた間をあけてみるか。
そういえば Ethernet の通信速度は旧モデルよりマシになったのかな、と試してみたら、600Mbps/900Mbps くらい出た... いやこれ、相手が悪い。Atom Z530 に Realtek の GbE だとそもそもあまりいい性能出ないんだった。 それで Ryzen PC を相手に iperf を実行した:
Raspberry Pi 4 が送信側の場合: [ 3] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec [ 4] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec Raspberry Pi 4 が受信側の場合: [ 3] 0.0-10.0 sec 1.02 GBytes 877 Mbits/sec [ 4] 0.0-10.0 sec 1.02 GBytes 876 Mbits/sec ([3] が送信側、[4] が受信側での結果)
ふーん。 送信は良いがやや受信性能が足りないようだ。 まぁ、以前の計測結果を見ると Realtek GbE は通信相手との相性がありそうなので、必ずしも Raspberry Pi 4 のせいとは限らないけど。
命令の実行時間を調べて 8088 っぽいかを確認するプログラム、作れそうだなと思った。 最初は aad 命令あたりから始めて、それとシフト命令で実行時間が一致するかのチェック、そこから aad 命令のオペランドを変えて 4 クロック増やして、同じく 4 クロック増やしたシフト命令と実行時間が一致するかのチェック、そして cwtd が 5 クロックまたは 6 クロックになるかのチェックなんかをしたら、プリフェッチキューの長さとバスサイクルを調整しながらタイミングが合うかを調べる。 みたいな。 メモリーアクセスのウエイトがあると狂うのでそれはそれで確認が必要だな。
こないだの cmp/test 命令の実験、これも 2 バイト目が 1T1 になるようにして即値 2 バイトで試せばおもしろいのではないか。
1T2 か。 これ cmp 命令のメモリーアクセスの次が 1T1 になるので、そこから先が 1T1 0T2 0T3 0T4 1T1 1T2 0T3 0T4 1T1 みたいな感じになったっぽい? いや... 待ちにはなったが、結局どの時点で即値を取り込んだかはわからないんだな。1T1 じゃ次の 1 バイトが使えるようになるまで 5 クロックあるし、メモリーアクセスを伴うのでそれを 1T4 にすることはできないしな。 最後の 5 クロックのどこかで取り込んだということしかわからないわけか。
昔のカーステレオで、カセットテープよりも前の時代にもっとでっかいのがあったよと聞いたことがあって、調べてみると 8 トラックというらしい。
説明を読んで、写真を見て、さてどんなカーステレオだったのかと想像しても、カセットテープみたいに、このでかいカートリッジがガチャリと飲み込まれて再生が始まる... と考えてしまうのだが、今は YouTube のおかげで動画で知ることができる。
BELTEK 8トラック カーステレオ プレーヤー デッドストック - YouTube
なるほど、全体は飲み込まれず、出っ張った状態のままで再生されるのだな。 そしてチャネル切り替えはセンシングテープ検出による切り替えの他に、切り替えスイッチも付いているのだな。 曲の途中で切り替わるのがラジオのチャネルを変えているみたいに見えておもしろい。 ふむふむ。 で、取り出しはどうするのか? と思って別の動画を見つけて衝撃的だった。
30 秒過ぎのところから、8 トラックの再生はほんの少しなんだけど、まず、取り出しは単にカートリッジをつかんで引っこ抜くということと、カセットテープと 8 トラックの両方に対応したものが存在したという事実。 しかも、カセットテープも同じところに押し込んで再生できるのが本当におもしろい。 ヘッドは共用でいいとしても、ロード機構はどうなってるんだこれは。
カセットテープの場合、VHS テープほどではないけど、スロットローディングの場合はある程度のロード機構が必要。 フロッピーディスクドライブ程度でいいんだろうけど、巻き取りの軸とキャプスタンをカセットテープの穴に通し、さらに再生時にはキャプスタンにピンチローラーを押しつける仕掛けが必ずある。 ヘッドの部分はそういえばカセットテープ側にバネ状の簡単な部品が付いていたっけ。 子供の頃からカセットテープは身近にあったので、カーステレオの機構はそういうものだという認識があったが、8 トラックの場合は巻き取り機構が不要で、ピンチローラーがカートリッジ内にあるため、キャプスタンに相当する回転部分とヘッドがちゃんと当たるだけでよくて、ロードは人力でいい。 しかし共用となると...
メルカリで買ったハコスカの8トラカーステレオと8トラテープを分解してみた - YouTube
これは 8 トラック専用っぽいけど、さすが昔のデバイス、部品がいっぱいだなw カセットテープと共用のやつの中を覗いてみたいな。
風呂場の換気扇 (浴室暖房兼用) の掃除をしようと思った。 見てみるとフィルター式だ。 説明書を見ると毎月掃除しろとある。 ふうん。 まだ 2 年くらいだしそんなに遅くないだろう。
そんなわけで外してみるとなかなかな汚れ具合だ。 掃除機で吸い取ってもびくともしない。 説明書を見ると汚れがひどいときは中性洗剤で洗えとあるので、洗うことにした。
で、ふつうこういうのはよく乾かしてから戻すもんだよな、と思って説明書を見直したが、洗剤をちゃんと落とせとは書かれているけど、乾かせとはどこにも書かれていない。 ほー。 よく考えたら風呂場用の換気扇なんだから、湯気もうもう浴びるのは当たり前だし、高さの低いユニットバスだと場合によってはシャワーの水しぶきが飛んできても不思議じゃない。 それに加えて 24 時間換気機能もあるので、ふつうに運転していればフィルターなんか乾く。 なのでフィルターを乾かさなくてもいいんだな。
テレビドラマ『ゆるキャン△』、『新米姉妹のふたりごはん』ほどではないが割と飯テロ番組である。 毎回必ず何らかのキャンプ飯を美味そうに食べるシーンが登場している気がする。 まぁ TVer で見ているから、腹が減った状態で深夜の放送を見ている人とは違って気が楽である。 タイトルの響きは緩くキャンプっぽい感じだけど、キャンプ場のシーンに人が少ないのは冬だからで、冷静に考えると全然緩くないんだよな。
テレビドラマ『女子高生の無駄づかい』、ほんとなんか雑なギャグドラマというか、読み切りじゃない 4 コマ漫画が原作かなみたいな流れ。 実際にはふつうの漫画が原作らしいんだけど、登場人物は皆キャラが濃くてわかりやすいので深く考えずに楽しむのがよさそう。 感情が死んでいる子が休み時間にまじめな顔して読んでいた本のタイトルが「脱税の手引き」というのも笑った。 フライングガーデンなど実在する店が出てくるシーンもある。
原付のメーター照明が点灯していないことに気づいたのがきのう。 整備不良になってしまうと思うが、帰宅途中だったので、とりあえずそのまま帰宅し、今朝、状況を調べた。 以前も点灯していなかった時が一時的にあって、その時は接触不良だったのか、走行中にいつの間にか復活してしまっていたほど、復活が早かった。 今回はまったく復活する気配がないが、ついに球切れか、それとも接触不良か?
とりあえずヘッドライトを外したが、どれがメーターの電球なのかわからない。 ヘッドライトが邪魔なのでコネクターを外し、中の配線を観察すること数分。 わからない。Google 検索してみる。 わからない。 ジョルカブのメーター電球の情報なんてほとんど出てこない。 右側の丸いやつには方向指示器のリレーが入っているらしいことはわかった。 姉妹車種のジョルノの情報を探すと、どうやら何かを引っこ抜くらしいことがわかった。 ジョルノは 2 個ついていたモデルがあるらしいのだが、ジョルカブはどうやら真ん中に 1 個なのかな。2 個あるのかも知れないけど、わからないのでとりあえず 1 個外して確認しよう。
ジョルノと明らかに違うのは配線がごちゃごちゃしていることで、その理由は、ジョルカブにはニュートラルと 4 速のインジケーターが付いているからだろう。 邪魔な配線のコネクターをふたつほど外して、ゴムみたいな素材のソケットを引きずり出し、電球そのものはねじる必要もなく、引っこ抜いたら外れた。 マルチメーターで抵抗値を計測、無限大。 電球自体すさまじく黒ずんでいるし、中を覗いてみても明らかに切れているように見える。 さて、代わりの品を買ってこなければ。
そんなわけで電球を持ってバイク用品店へ。 見た感じ同じっぽい形の 12V のものには 1.7W, 3.4W, 5W など種類があり、どれだかわからない。 ジョルノは 3.4W という情報が知恵袋にあった。 信じていいのかはわからない。 店員さんに聞いてみたところ、ヘッドライトや方向指示器とは違って、メーターの電球については資料が無く、車体番号がわかればホンダのデータを調べられますが... とのことだった。 外国人っぽい店員さんががんばって表面の文字を読んでくださって、158 と読める、と。Web で出てきたのではジョルノで KOITO の 158 というのは見かけたのがあった。 ウーン。 ええい、面倒だ、ここは 3.4W を信じて 3.4W を買うことにしよう。 たぶん間違っていてもヒューズが飛ぶ程度だろう。M&H の 1PWB12 にした。220 円。
そんなわけで交換して、点灯確認 (ジョルカブの場合メーター照明はキーを ON にするだけでバッテリー電源で点灯する)、元に戻して、ヘッドライトの固定... の前に、一応ヘッドライトも含めて点灯確認をしよう、と思ってエンジンを始動してみると、ヘッドライトがつかない。 減光側だけつかない。 へっ? 球切れか? と思っているとついた。 接触不良か。 というわけでまた外し、コネクターまわりをパーツクリーナーで掃除し、ついでにヘッドライト裏に溜まっていた汚れもある程度は落として、あと配線が変に折れ曲がらないように少し通し方を変えて、それで元に戻して、エンジン始動して点灯確認、ヘッドライトの向き調整、その他尾灯、ブレーキランプ、方向指示器の点灯確認と警笛の確認までして完了。
しかし、メーター照明の球切れを経験するなんて、だいぶ長く乗ったなーって感じがする。 なお尾灯、ブレーキランプと方向指示器は一度も切れておらず、不思議なことに中古で 8 年使ったバッテリーも未だにエンジン始動可能。
高校の同窓会の新年会が渋谷であるというので渋谷へ。COVID-19 の心配もあるのでスクーターで行った。 甲州街道を初台まで、そこから山手通り、東大裏を過ぎて渋谷方向へ。 本当に人が多いな、渋谷は。
超早く着いたので、まずメガドンキホーテへ。 でかい手袋がないかなとうろうろしたが、無かった。
次に東急ハンズへ。 たぶん初めてだな、渋谷の東京ハンズに来たのは。3 つの細長い建物を微妙に高さをずらして階段で結んだみたいな、すごく不思議な構造の建物である。 ぐるぐる回りながらおりていくと全部回れるようだ。 東急ハンズも手袋はろくな物がなかった。 作業用手袋だってそのへんのホームセンターで売られているものと変わらん。 それより、一番上の 7 階にあった、歯車で動くおもちゃ? 飾り? みたいなのがおもしろいなーと思ったのと、何階だったか、サイフなんかが売られているフロアで、前から探していた、Qrio Key を入れるのにちょうどいいキーケースを見つけてしまったので、買った。 キーケースなのにファスナーがついて、それでいて軽く、中に入れた Qrio Key のボタンを外から押せる感じのやつ。 小銭入れも付いているけどそれはおまけだな。 去年、山形屋なんかでも探したんだけど、ちょうどよさそうなのは見つけられなかったんだよな。 こんなところで手に入るとは。
それだけのんびり買い物なんぞしていても、新年会の 15 分前に店に着いたw ので、待つ間、買ったばかりのキーケースを開けて鍵を移すなどしていた。 そして、いつものゆるい感じの新年会。 店の注文方法が、QR コードをスマートフォンで読み取り、web から注文するというもので、なるほど便利かも、と思ったが、途中注文していないドリンクが何個か来たのはなんでだったかな。 ビール複数など、まるで配った後のドリンクがもう一度注文扱いにでもなっていたかのようだったが、履歴をみるとひとつしかなかった。 まぁ飲み放題だったので別にいいんだろうけど...
帰りも適当に初台に出て甲州街道。 アドレス V100 は、甲州街道なんかは本当に走りやすいスクーターだ。50〜60km/h あたりがちょうどいい。 怖さを感じることがあるとすれば、小さすぎることかな。 タイヤが小さいことによる操縦性の不安よりも、車体が小さいために周囲の車にどこまで自分が認識されているか気になることがある。50cc と大差ない大きさなのに、まともに加速するし。 排気量の割に大柄な GSR250S だと気にならないところだ。
そうそう、渋谷おはら祭りの頃に COVID-19 の心配がなくなっていればいいけどねぇ。 自分達は 1987 年開校の高校の同窓会なので、1 期生でもまだ 40 代なんだけど、渋谷おはら祭りに参加している他の連の人達の中には、70 代、80 代など、お年を召した方々が多くいらっしゃるので、万が一の場合のリスクが高い。
何度か昼寝した。
雨。
車のバッテリー、キー ON の時点で 12.01V あたり。(ライトオフ、ラジオ ON。) エンジン始動がやや重そうな感じだが問題なく始動でき、キーを戻した時に出る電圧計は 11.5V あたり。 走行後エンジン停止前に、ライトをオフにし送風を止めても、充電制御が働いていない。 バッテリーの状態判定がどういうふうに行われているのかはよくわからないけど、今後も充電制御が働かないようだと、車のコンピューターもバッテリー寿命が近いと判定していると推測できる。
新型ウイルスの話、一般にコロナウイルスといえば普通の風邪のウイルスも含まれるらしい。 だから例えば自分が去年引いた風邪なんかもコロナウイルスの一種だった可能性はあるということになる。 そういう普通の風邪のコロナウイルスと、今回のような新型との間に関連性はないのか。 いや、あるからコロナウイルスなんだけど、免疫的に関連があれば、症状の程度の差が説明できるのだろうか。 でもコロナウイルスは終生免疫は得られないとする説明も見つかるなぁ。
2 度目の今回は超音波検査はなし。 尿検査あり。 残尿の量チェックあり。 残尿の量は今回は半分くらいになってだいぶマシに。 尿検査結果は比重が前回以上に濃く、>= 1.030 という表示は要するに測定限界を突破しているのか。 それに加えて菌が検出されたとのことで、それは培養して調べてみるとのこと。 比重も菌もいずれも、改善のために昼間は水分をたくさん取るようにとのこと。 ほーん。
未明にトイレに起きた時に尿の出が悪いのはそういうものらしい。 あとは薬のおかげかそのときの量も減っているように感じているが、なぜか尿意があるんだな。
薬局に行ってみるとやはりマスクはない。 聞いてみると入荷すらないみたいな状態らしい。 先月コストコで偶然買ったんですよーどうせ使うだろうと思ってと言ったら、薬剤師さんも、コストコ行ったんですけど跡形もありませんでしたとおっしゃる。 やはりタイミングか。1 月 4 日だったから、あれから 2 週間遅かったら無理だったかもな。
予定より 10 分ぐらい遅れて自宅を出て、スクーターでブーンと行ったのだけどやたら道が混雑している。 それを避けるように、転回したり、裏道に回ったりして行ったのだが、例によって駅間を歩く人々を見かけて、これは JR 線がやらかしたな... って感じだった。 案の定、駅では人身事故がどうのこうのとアナウンスが流れていて、なるほど。 それで泌尿器科には開院時間の 15 分弱前くらいに着いたんだけど、1 人目だった。 こないだは確かもっと早く着いたはずなのに 2 人目だったんだよな。 やはり JR 線と道路の混雑の影響か?
しんおちゃ新御茶ノ水さんはTwitterを使っています 「国分寺駅滅多に人身事故なんてないのにスタンプラリーでコナンと新一が駅に置かれた途端発生しやがった」 / Twitter
それだ!!
また気温下がった。
うっかりノート PC の電源アダプターをつないである電源タップのスイッチを切ってしまった上に衝撃か何かでバッテリーが一瞬切り離されたらしくて、ちゃんと電源が切れてしまったのだが、不意にやらかしてしまった半年以上ぶりの再起動は、crypttab のボリュームのパスフレーズ入力プロンプトが出るはずのところで出ず、別の項目に進んでしまってどうやら入力を受け付けすらしない状況で止まってしまい、Ctrl-Alt-Delete を押したらそれも固まってしまったので電源を切る羽目に。 さてそこで fstab に noauto を書いてみたのだが、crypttab に noauto を書いていないとふつうにマウントしやがる。 ほー。 それで crypttab に noauto を書くと、今度は mount mountpoint ができなくなる。 ほー。 クソ不便だな。 仕方がないので元に戻したけど、プロンプトがたまに流れちゃうくらいでたいていはちゃんと動いている。 だめだったときは、その前の電源ぶっちのせいで rootfs の fsck か何か、reiserfs の journal replay のメッセージがずらりと出ていたのでその影響だったかな、それにしても systemd は困りものである。 はー。
さて、バッテリーが一瞬切り離されたというのは、充電 threshold の設定が飛ぶのでわかった。 最初は単に電源供給が絶えて電池切れになったかと考えたが、通電して起動後にバッテリー残量が 90% を超えていたため、どうやら放電はしていなかったことを把握した。 しかし threshold を再設定する前に、リフレッシュをすることにした。 互換バッテリーの説明書で、本当は毎月リフレッシュしろとなっていたが、最後にやってからもう 1 年以上経ったかも知れない。 強制放電開始後、何分も経たないうちに残量は 10% を切る値に飛び、20 分ほどで充電が始まった。 そういえば 3% まで減ったら充電しろという説明のことはすっかり忘れていた。 まぁいいけど。 まだサイクルカウントは 6 である。
WITH ME カートレに参加。
車の外気導入切り替えダイヤルが何か引っ掛かる感じがして、変だなと力を入れたらぺちっと音がしてダイヤルの手応えがスカスカになったw こりゃワイヤーが切れたか外れたかしたなw 外気導入側になっているもよう。 修理してもらわねば。
カートレの帰りに幕張のコストコに寄ってみた。 多摩境より大きく、2 フロアにわかれている。 レジはどこだと迷っていたらレジは 1 階だった。 しかしこんなに大きくても作業用手袋は S と M しかないのである。 その点は役に立たない。
給油。133 円/l。 燃費計算 19.3km/l。 燃費表示 20.1km/l。
例によって潮来で KT。 今日はタイムアタック後に簡単な模擬レース的なものも開催された。
ベストタイムは 37.42 秒。 体が疲れるので、アタックラップと休憩ラップを交互に繰り返す作戦を実行した。 アタックラップ前の最終コーナーは大回りで、アタックラップの最終コーナーは小回りで、ちょっとタイムが稼げていたらいいな的な... 休憩ラップというのはコーナー手前でリフトアンドコーストして、ブレーキングもガツンとやってコーナリングスピードを落としてという感じで体への負担を抑える自己流なやり方。37 秒台は何度も出せていて、体が大丈夫ならもっと出せていたわけだけど、休憩ラップは 38〜39 秒台になるのでさすがに。
模擬レースが 4 台中 3 番手スタートで、2 番手の速い人がごちゃっとやった結果その人とバトルになったので楽しかったもののやりあっているうちに抜かれて結局 4 番手になったんだけど、まそれはいいとして、速い人がインフィールドの右コーナーに割とイン側からけっこうな勢いで入っていったなというのが印象に残った。 あれで曲がれるのかな。 何かラインがあるのか。 そこにうまく乗っけられればもうちょっとベストタイムを更新できるかも知れない。
例によって朝の到着時から肩がわずかに変だったが、前よりは大丈夫。 今日も薬を持って行ったが、夜はやっぱり神経痛だった。 カロナールを帰る前に 1 錠、コストコに着いたときにもう 1 錠服用して、まぁなんとか...
原因は上下の振動じゃないかなぁ... なんか首都高を東関東道方面に抜けていくとき結構道路のつなぎ目なんかでガタガタする。 朝現地到着時点でなんかおかしくなっているのはそれのせいな気がする。 サーキットもところどころガタガタする路面があり、それに加えてハイグリップタイヤとカート特有のインリフトもあって結構上下にも動く。 まぁ横 G も強いので特定の何かが原因ではないのかも知れないけど、横 G だけなら APG のスポーツカートも似たようなものだからな...
あと肩も体力も含めてタイムアタック時は体をかばっていたのに、模擬レースとなるとついつい力が入ってしまったのはよくなかった気がする。
例によって首やら腕やら筋肉痛。 ヘッドで起きあがろうとした時には本当に痛いなと思ったが、起きあがってみると意外と楽で日常生活に支障はない。 筋肉痛になると猫背が悪化する感じはするw
足を怪我してから 4 週間。 先週頃はもう日常生活ではほぼ気にならない状態になっていた。 今も指の向きなどによって痛みが出るところはあるけど、直後の頃とは違い、普通に歩いたり、踏ん張ったりしても大丈夫になっている。 1 週間だと「普通に歩けるぐらい」と書いているが、普通に歩けるけど少し痛みがあるというか、違和感があるというか、靴が少し当たるから痛いというか、そんな感じだったのが、今は気にならない感じ。
PHSからスマホへおトクに機種変更｜Y!mobile - 格安SIM・スマホはワイモバイルで
もたもたしていたらついに端末代まで 0 円になったらしい。 なんか総務省の値引き禁止のアレは関係ないのかな。 まぁ巻き取りだしな。 でも結局 Simply かな...
テレビでやってた映画『リメンバー・ミー』(原題: Coco)。2017 年のアメリカ映画。 日本語音声。 去年飛行機で見た時は英語音声に英語字幕だ。 そのときに自分の英語力不足により理解できていない部分が少々あったはずなのだが、半年の時間によってそんなことは気にならないくらいに記憶は曖昧になっていたw それでカットされている気配がないなと思ったら本編ノーカットか。 なるほど。
バックアップに用いている Debian GNU/Linux を起動してバックアップを開始しようとしたら、止まった。 何事かと思えばカーネル内でトラブルのようだ。2 回しか試していないけど百発百中。NILFS の書き込み後に発生する。 仕方がないので古いカーネルにしたら動いた。 しかしこれは困るぞ。 自宅サーバー PC では nilfs2 をまじめに使用していて、まだ再起動していなくて 4.19.0-6-686-pae だから動いているけど、再起動すると 4.19.0-8-686-pae になってもれなく起動しなくなるパターンだ。 間違いない。 とりあえず自宅サーバー PC からこのカーネルは消しておく必要があるな。 依存関係もあり linux-image-2.6-686 linux-image-4.19.0-8-686-pae linux-image-686-pae の 3 つのパッケージが消えることになったけど、仕方がない。 バックアップ用 PC で出たエラーはこれ:
[ 79.694233] NILFS version 2 loaded [ 79.829212] NILFS (dm-3): segctord starting. Construction interval = 5 second s, CP frequency < 30 seconds [ 84.217746] BUG: unable to handle kernel NULL pointer dereference at 00000000 000000a8 [ 84.217933] PGD 0 P4D 0 [ 84.218000] Oops: 0000 [#1] SMP NOPTI [ 84.218086] CPU: 0 PID: 1698 Comm: segctord Tainted: G OE 4.19. 0-8-amd64 #1 Debian 4.19.98-1 [ 84.218278] Hardware name: System manufacturer System Product Name/C60M1-I, B IOS 0305 08/07/2012 [ 84.218466] RIP: 0010:percpu_counter_add_batch+0x4/0x60 [ 84.218578] Code: 89 e6 89 c7 e8 9d 38 32 00 3b 05 cb 6d d4 00 72 d8 4c 89 ee 48 89 ef e8 6a 49 34 00 48 89 d8 5b 5d 41 5c 41 5d c3 41 54 55 53 <48> 8b 47 20 65 44 8b 20 49 63 ec 48 63 ca 48 01 f5 48 39 e9 7e 0a [ 84.218940] RSP: 0018:ffffb1f5408bbd20 EFLAGS: 00010006 [ 84.219049] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000018 [ 84.219192] RDX: 0000000000000010 RSI: 0000000000000001 RDI: 0000000000000088 [ 84.219334] RBP: ffff9f44331515d0 R08: 0000000000000000 R09: ffff9f4433101d90 [ 84.219476] R10: 0000000000000230 R11: 0000000000000000 R12: 0000000000000000 [ 84.219618] R13: ffff9f4433151458 R14: ffff9f44331515c8 R15: fffffa2684b86f40 [ 84.219763] FS: 0000000000000000(0000) GS:ffff9f443b000000(0000) knlGS:00000 00000000000 [ 84.219925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 84.220042] CR2: 00000000000000a8 CR3: 0000000138e6e000 CR4: 00000000000006f0 [ 84.220185] Call Trace: [ 84.220258] __test_set_page_writeback+0x37c/0x3f0 [ 84.220396] nilfs_segctor_do_construct+0x196b/0x2100 [nilfs2] [ 84.220547] nilfs_segctor_construct+0x1f5/0x2e0 [nilfs2] [ 84.220684] nilfs_segctor_thread+0x127/0x370 [nilfs2] [ 84.220819] ? nilfs_segctor_construct+0x2e0/0x2e0 [nilfs2] [ 84.220937] kthread+0x112/0x130 [ 84.221012] ? kthread_bind+0x30/0x30 [ 84.221097] ret_from_fork+0x22/0x40 [ 84.221178] Modules linked in: nilfs2 nls_ascii nls_cp437 vfat fat ext4 crc16 mbcache jbd2 fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 radeon snd_ hda_codec_via snd_hda_codec_generic snd_hda_intel snd_hda_codec ttm kvm_amd snd_ hda_core ccp rng_core drm_kms_helper snd_hwdep kvm snd_pcm drm snd_timer snd sou ndcore irqbypass eeepc_wmi efi_pstore asus_wmi sparse_keymap rfkill i2c_algo_bit evdev pcspkr k10temp efivars video wmi_bmof sp5100_tco sg pcc_cpufreq wmi acpi_ cpufreq button xfs libcrc32c crc32c_generic dm_mod sd_mod ohci_pci ohci_hcd ehci _pci ehci_hcd ahci usbcore libahci libata r8168(OE) i2c_piix4 scsi_mod usb_commo n [ 84.233463] CR2: 00000000000000a8 [ 84.237258] ---[ end trace 83dc72c5fb05231e ]--- [ 84.766344] RIP: 0010:percpu_counter_add_batch+0x4/0x60 [ 84.770151] Code: 89 e6 89 c7 e8 9d 38 32 00 3b 05 cb 6d d4 00 72 d8 4c 89 ee 48 89 ef e8 6a 49 34 00 48 89 d8 5b 5d 41 5c 41 5d c3 41 54 55 53 <48> 8b 47 20 65 44 8b 20 49 63 ec 48 63 ca 48 01 f5 48 39 e9 7e 0a [ 84.781894] RSP: 0018:ffffb1f5408bbd20 EFLAGS: 00010006 [ 84.785752] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000018 [ 84.789598] RDX: 0000000000000010 RSI: 0000000000000001 RDI: 0000000000000088 [ 84.793346] RBP: ffff9f44331515d0 R08: 0000000000000000 R09: ffff9f4433101d90 [ 84.797015] R10: 0000000000000230 R11: 0000000000000000 R12: 0000000000000000 [ 84.800623] R13: ffff9f4433151458 R14: ffff9f44331515c8 R15: fffffa2684b86f40 [ 84.804238] FS: 0000000000000000(0000) GS:ffff9f443b000000(0000) knlGS:00000 00000000000 [ 84.807902] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 84.811601] CR2: 00000000000000a8 CR3: 0000000138e6e000 CR4: 00000000000006f0
さて... 何を調べればいいのやら。 とりあえず Ryzen PC で upstream kernel の 4.19 系列の最新版 4.19.105 をビルドして試してみた。 ら、だめだ。 ちょ。 マジか。 どうやら Debian のせいではないらしい。sync も umount もできなくなるので、遠隔では reboot -n -f で再起動するぐらいしか手がないのがつらいところ。
linux/kernel/git/stable/linux.git を git clone して試す。v4.19.68 は OK。v4.19.78 も OK。v4.19.88 はだめ。 ふーん、と検索していると一応 NILFS 関係者には報告されている問題らしいことがわかった。
これを信じると 4.19.83 まで OK で 4.19.84 はだめ、問題のコミットは d3b3c0a14615c495118acc4bdca23d53eea46ed2 でその一行目は "mm/filemap.c: don't initiate writeback if mapping has no dirty pages" である。 あんまり害がなさそうなコミットなんだけどコイツが原因らしい。 はーん。mm/filemap.c ってもしかしてカーネルモジュールじゃないのか。 それじゃあ一部のカーネルモジュールだけ別のバージョンから引っこ抜いて突っ込んで回避もできないのか。 ウーン。
整形外科→耳鼻科→薬局→弁当屋→自宅→弁当屋→自宅な一日。 朝晴れていたが乾いていなかったのでスクーターで出発。 耳鼻科はやや混雑気味。 花粉か。 春一番が吹き荒れる中、弁当屋に寄ってから帰宅した。
きのうの夜から腰が痛かったが一日経ってちょっとは良くなったかなという感じ。 たぶん筋肉痛が原因だ。 あと... 睡眠不足もあるかも知れない。 睡眠不足で筋肉痛の回復も遅れるのではないか。 まぁ合計睡眠時間はある程度確保しているつもりだが、夜中にトイレに起きてしまうのはやはり良くない。 やたらと夢を見るのも眠りが浅い証拠。
テレビドラマ『ゆるキャン△』、キャンプ慣れしてそうな主人公が備長炭着火に失敗するシーン。 まぁ確かに今までガスだったから初めてだったわけか。 大学の学園祭やらバーベキューやらで炭に火を付けるのは見たことがあるけど、空気送りまくって結構時間が掛かっていた気がする。 あれも備長炭だったかな、たぶん。
Raspberry Pi 用に公開されている Raspbian ディストリビューション、とても印象が悪い。 とりあえず動かしたのは一番容量の小さなイメージだが、何が嫌って、bash のプロンプトがカラーなのである。 こんなの Debian じゃない。
Debian との差異は Raspberry Pi 用の一部プロプライエタリソフトウェアの有無やら何やらのようだが、明らかに bash のプロンプトが違うではないか。 しかも新規ユーザー作っても違うんだからこれは /etc/skel/.bashrc が違っているわけで、つまり bash パッケージが別物ってことだ。 本当に?
a@raspberrypi:/tmp/hoge $ apt download bash
Get:1 http://ftp.jaist.ac.jp/pub/Linux/raspbian-archive/raspbian buster/main armhf bash armhf 5.0-4 [1,265 kB]
Fetched 1,265 kB in 1s (1,188 kB/s)
a@raspberrypi:/tmp/hoge $ ar x bash_5.0-4_armhf.deb
a@raspberrypi:/tmp/hoge $ tar xf data.tar.xz
a@raspberrypi:/tmp/hoge $ diff -r ./etc/skel/ /etc/skel/
diff -r ./etc/skel/.bashrc /etc/skel/.bashrc
46c46
< #force_color_prompt=yes
---
> force_color_prompt=yes
60c60
< PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
---
> PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w \$\[\033[00m\] '
82,84c82,84
< #alias grep='grep --color=auto'
< #alias fgrep='fgrep --color=auto'
< #alias egrep='egrep --color=auto'
---
> alias grep='grep --color=auto'
> alias fgrep='fgrep --color=auto'
> alias egrep='egrep --color=auto'
なるほど、bash パッケージは変更されていなかった。 ただ単に誰かの気持ち悪い趣味の設定変更が元のイメージに入っているだけか。Raspbian でもいいけど、デフォルト設定がクソだから debootstrap からやり直したイメージを作りたいね。
よく寝た日。(何度も寝た日。)
スクーター、アドレス V100 の右後ろ下側のカウルを外してみた。 ねじ 2 本、ナンバーの近くのと、パッセンジャー用ステップの前のほうのねじをゆるめ、ナンバーの近くは手前に引っ張り、後は全体を後ろにずらしてから下に引く。 これを外すと、例のオートチョークヒーターの配線へのアクセスが多少良くなる。 しかし、この配線、オートチョーク側は多少余裕があるのだけど、電源側はまるで余裕がなく、切ったらやはり配線を延長しないことには仕方がなさそう。 それじゃあ接点掃除だけしておくか、と、KURE CRC 5-56 をぶっかけておいた。
さて、それで試運転をかねて少し走らせたのだが、チョーク (スターター) が戻っていない! 2 回ぐらい停まってコネクターまわりをいじった。 コネクターじゃない部分の接触不良、あるいは断線なのかな? 確かにオートチョークヒーターから生えている配線がぐいっと曲げられている感じなのはあまり良くはないよな...
大きなサイズの取り扱いがあると表に書かれているサカゼンという服屋さん。 ふらっと寄って大きい手袋ありますかと聞いてみたところ、「ゆったり目の手袋をお探しですか?」ってw ゆったり目の手袋に出会ってみたいよねw まぁなんかわざわざいくつかピックアップして頂いたけど、4L の毛糸の手袋がちょうどぴったりくらいのサイズだったのでそれだけ買った。 ミズノか何か、有名メーカー製のも出して頂いたが、それは指が細すぎて入らなかったw 大きいサイズが売りの店でもこの有様。 やはり本当に大きな手袋は製造すらされていないのだ...
図書館に行った。8086 の本を自動書庫から出してもらって、見てみた。 「8086 マイクロコンピュータ」田辺皓正 編著。 昭和 58 年 4 月、自分が 1 か月の頃の本。 活字活版印刷って感じの本。 命令のクロック数の一覧は、「PC-9801 マシン語ゲームグラフィックス」日高 徹 (著), 青山 学 (著) に近い。+EA で 7 or 8 みたいに微妙に省略されているし、AAA が間違って 4 クロックになっているのも同じ。 未定義命令や予約ビット等の詳細は明記されていない。 最後に具体的な搭載機が写真付きで紹介されていて胸が熱くなる。
もうひとつ、「8086 の使い方 (図解 16 ビットマイクロコンピュータ)」井出裕巳。 こちらは 1982 年 10 月、上の半年前の本。 フォントが「ザ・プロテクト II プログラム解読法入門」と同じような感じだ。 あんまり活字活版印刷っぽさはない。 本文中に「22kΩのプルアップ抵抗を挿入しなければならない」とか、「シンク電流 2mA および負荷容量 100pF までと規定」とか、なんか具体的な数字がちらほら登場するのが、ハードウェア屋さんには頼もしい感じかも知れない。 最後のほうに未来の話として、iAPX 286 やら iAPX 432 やら載っていて胸が熱くなる。 いや、まじめな話、80286 は 1982 年に発表はされていたようだが、搭載機が登場したのは 1984 年だそうで、この本が出た時には未来の話だったわけである。iAPX 432 も、1982 年当時はまだ現行製品だったわけで、失敗とは言えなかったのだろう。
前に借りたこともある「80x86/80x87 ファミリー・テクニカルハンドブック」Robert L. Hummel (著), 槌田 浩一 (訳)。 やはり未定義命令なんかも多少説明が載っているという点ではこの本が一番だ。 それでも間違いが多いのはいけてない。SETALC (SALC) が 80286 以降だとか、8086 のフラグレジスターの初期状態が F000h だとか、PUSH SP の挙動の説明の 8086 と 80286 以降が逆だとか、そういう間違いがちょろちょろある。REP の割り込みバグの対策方法も、この本以外に WWW でも見たけど皆間違っているんだよな。 アレはまず LOCK プリフィックスとセグメントオーバーライドプリフィックスを同時に使っちゃだめだ。 そして抜けた後にすることは JCXZ で正常時のスキップをし、次に LOOP で戻ることだ。
1: rep movsb %cs:(%si),%es:(%di) jcxz 2f loop 1b 2:
こうである... なぜなら割り込み発生後に MOVS 命令の 1 バイト手前に戻ってしまうので、この例では 1 回分の MOVS 命令を実行してしまい、その分の回数は減っていないので LOOP 命令で減らす必要がある。 ...あれ? ちょっと待った。8086/8088 だと REP のシングルステップ実行は残り 1 回で実行した後でもいったん REP に戻ってくるんだったな。 あれ? そうすると残り 1 回で実行後に割り込み発生するとこれだと REP なしで MOVS 命令を実行してしまうのでは? だめじゃん! 回避は不可能か!
寝間着に使っているジャージ (下)、ポケットに指一本入るくらいの穴が空いていたのだが、いや、もうちょっと大きくなっていたかな、いい加減補修するかと、見てみると、穴が空くというよりは、ポケットのふちを縫っている糸がほつれて取れてしまった感じだな。 なので単に縫えば OK。 手縫いの技術はないのでミシンにまかせるw
ついでにジーンズの穴があきかけている部分も適当に補修して、あとカードいれに使っている革の名刺入れみたいなやつも適当に補修した。 本当は返し縫いなんかちゃんとやったほうがいいんだけど、間隔狭い三重縫いにしたから別にいいかと...
花粉症じゃないけど、なんかいかにも花粉がたくさん飛んでいそうな感じがした日。 マスクをしていても、鼻の中がかゆいような気さえした。
バイクのキーシリンダーまわりに KURE CRC 5-56 をぶっかけつつぐりぐり回してみる作戦。 しかしこれ、鍵穴には入れないようにしているから、奥の接点まで 5-56 がたどり着けている気がしないな。 それよりも、ぐりぐり回すことで接点の汚れが多少取れる効果がありそうな気はする。
車の外気導入・内気循環切り替えダイヤルの修理。 ディーラーで見てもらったところ、ワイヤーが外れていたらしくて、それを付けなおしたら使えるようになったと。 ふーん、予想の範囲内w しかしこないだは何かが引っ掛かっていた感じで切り替えられなかったわけで、その原因は判明していない。 ワイヤーの先はエアコンユニットに隠蔽されているようで、そこを開けるのはエアコン業者 (って言ったかな...) じゃないとできないみたい。 まぁ、とりあえず使えるようになったので様子見。
自動車保険に日常生活賠償特約を追加してもらった。 東京都も 4 月から自転車保険加入を義務化するという話を最近になって知り、めったに乗らないけど追加しておこうかと。 自分の怪我は対象外、相手の怪我や物損は無制限。 自転車賠償特約ではないので自転車以外も対象。 つまり、例えばランニング中にうっかり電柱にぶつかって電柱を倒してしまったとしても、その電柱の修復費用は補償されるというわけだ!
暖かくなったおかげか、車のバッテリーは 5 日くらい置いたのに 12.4V 程度あり、エンジン始動直後も 11.8V くらいあって、充電制御も働いた。7 年目のバッテリーだけどまだまだいけるな!
Markdown から HTML に変換する cmark コマンド。 単に markdown のテキストファイルを指定すると HTML が出てくる。 それも <html> などのよけいなタグはいっさい含まれず、markdown の部分だけがシンプルに変換されて出てくる。 なるほど。
テーブル (表) は cmark では扱えないみたい。cmark-gfm コマンドに -e table オプションを付けるとテーブルが使えるようになる。 文字コードは UTF-8 なのかなと思うが EUC-JP を渡しても普通に動いているように見える... いや、link の title にひらがなを入れると急に link として認識されなくなるなぁ。 テーブルもか。 ふうん。
泌尿器科にかかっている件、あれだな、今朝は連続 4 時間くらい眠れたわけなんだけれども、トイレに起きて、そこで排尿がきっちりできていない、いわゆる残尿感があると、それでトイレに行きたい感じが出てしまって、そこからちょっと寝てはトイレに起きる羽目になっているのかもなー。
あと、あれだな、寝室の室温ももしかしたら関係あるかな。 今年は布団乾燥機のおかげもあって 15 度ぐらいあればまぁいいかと暖房を入れないで就寝している日も多いんだけど、もっと暖かくしてみるべきか。 昼間は職場は暖かいしな。
最近、整形外科に向かう途中、9 時開店のサンドラッグの前に 10〜15 人ぐらいの行列ができているのを 8 時 15 分頃でも見るんだけど、今朝は、店の目の前のバス停にとまっているバスを追い越した時にチラッと視界の隅に見えた行列が、いつもの倍ぐらいの長さに見えた。 花粉の飛散もピークだというし、マスクがほしくて並んでいるんだろうけど、たぶんあの人数いると全員は買えないんだろうし、毎日のように小一時間も外に並んでいたら花粉症じゃない人も花粉でおかしくなりそう。
朝は霧雨。 久しぶりに整形外科まで一駅分歩いた。 歩いている人が何となく普段より少し多いような気がした。 鉄道は平常通りだったのに。 やっぱり複々線区間まで歩いて混雑を避けたい人達かな。
夜は曇り。 久しぶりに一駅分歩いた。
なんか、いろいろ発見がありすぎて忘れかけてきたが、プリフェッチキューとクロックの話は結果としては割とわかりやすくできそうで、2+EA+4(Read)+5 みたいな形で整理していけそうなことがわかっているので、調べたいことは多々残っているものの難しくはなさそう。 それに対してフラグレジスターの話はうまくまとめられていないのがあるんだった。 TF, IF と POPF, IRET との関係のところ、その続きとさらに続き、我ながらいろいろとトリッキーなパターンを試していて、いろいろとわかったのだけどなかなかきれいにまとめるのが難しい。
ここ数日でダントツに寒い日。
今朝のサンドラッグ行列はさらに長かった。
健保組合の web サービスでポイントが溜まっていたのがあって、有効期限はいつだったかなと調べると来月で切れるのがあったので、交換することにした。Amazon ギフト券は Amazon を使っていないので役に立たず、前はマスクがあったような気もするがマスクはなく、まぁたいして高い品でもないものがずらずらと並んでいるのだが、体温計にしてみた。 体温計、オムロンのやつを持ってはいるんだけど、液晶が漏れているっぽいので。 交換を選んで進めていくと、翌月以降に発送みたいな表示が出て、おいおい... あと数日経っていたら 4 月以降だったのか...
話題の新型ウイルスについて、どうも我が国の政府はこれから 2 週間ほどが超重要と考えたみたいで、大規模イベントは控えてくれとか、学校を休みにしてくれとか、そういう話に加え、この季節恒例の確定申告でさえも期限を延長ということで、まぁ、確かに 2 週間、わからないでもないんだけど、学校が休みになって子供達はどうするか、どうだろうねぇ。 家でおとなしくしているだろうか? そもそも、子供を一人にしておけないという家だと、親戚の家にでも連れて行くのか、あるいは職場に連れて行くのか? 満員電車に乗って? えっ? そっちのほうが問題じゃね? みたいな... まぁでもここに来て気温が下がって乾燥しているのは、通常のウイルスも含めて、人間にとって良い話ではないとは思う。 今の状況で震災でも起きたらなんかどうにもならない気がするので、そうはならないように祈ろう。
何の変哲もないプレミアムフライデー。(早くも死語になりつつある。)
今朝のサンドラッグ行列、チラチラ見ながら雑に数えた感じでは 60 人ぐらい並んでいそうだった。 なおマツモトキヨシには行列はなく、扉は開いていたが営業時間前、ひょっとするとマスク入荷はありません的な張り紙でもあったかな。 あっ、そういえば最近はなんかトイレットペーパーの売り切れが発生しているらしくて、オイルショックの時と同じで供給に問題はないにもかかわらずということで、時代は繰り返すのね。 マスクは中国製も多いので (実際手元にあるやつは中国製だし) 供給が減って需要が増えると足りなくなるのは仕方がないところがあるが、トイレットペーパーは国内産だし単に需要が唐突に増えただけっぽくて、待ってりゃ近いうちに買えそう。
テレビでやってた映画『トイ・ストーリー』(原題: Toy Story)。1995 年のアメリカ映画。 おなじみのピクサーアニメーションだけどなんとなく人の絵などに古さを感じるような気がしないでもない。 続編の 3 のほうを先に見たので、人にバレないようにおもちゃがわいわいがやがややっている物語、という印象があったが、この最初の話は実は結構アグレッシブなニアミスが多数あり、さらには (子供とはいえ) 目の前で動くシーンまである。 まぁただちょっとアクシデント多すぎだな。
古すぎて Perl の警告がもりもり出るようになっている Tomsoft Diary System を独自のものに置き換えようと思って少しゴリゴリしていた。 本文を CommonMark で書く感じで雑に作ろうとしていて、出力を適当に GNU Awk やら sed やらで加工する感じで、一日分の処理ならすぐできたんだけど、更新チェックがあるのでそれは Makefile でやりたいなと思って GNU Make のマニュアルとにらめっこをしている。
2 月 29 日の土曜日は 1992 年以来だ。 どうでもいいけど。
PHS の家族割の主回線と副回線の入れ替えができないか、ワイモバイルショップに行って聞いてみたんだけど、調布はだめだな、小さすぎて混雑しすぎ。 多摩センターはほどよい感じ、で、PHS の主回線と副回線の入れ替えは今はもうできないとのこと。 即答だった。 はー。PHS の副回線は基本料金が 0 円なので、副回線を LTE に移行してしまうと、支払額が上がってしまうのだ。 そういうことなら暗証番号を再設定してもらった時に入れ替えてもらっておくんだった。
バイク点検予約のついでで売り場を眺めたのだけど、スズキはネイキッドはあんまりなくて、スポーツ系かツアラー系かスクーターか、そんな感じなのか。 大型二輪だとネイキッドは SV という V 型 2 気筒エンジンの車種くらいだと。 へー。 並列 (直列) 2 気筒でトルク重視のまったりバイクはスズキには 250cc クラスしかないのかな。
そしてバイクの FI エラーは今日も頻発。 点検に出している間も発生しそうだな。 ディーラーでは鍵の分解まではできないそうで、メインキー交換だと 1 万円くらいだと。(部品代か?) シートキーも合わせたければ両方交換で 2 万円。 ふうん。
define〜endef で複数行の変数を定義できる。 でも、それを関数として $(call 変数名) で呼ぶと改行が消えてしまう。 これを $(eval $(call 変数名)) とすると改行までうまく展開されるらしい。 それと、関数だと $(1) などで引数を得ることができるため、$ そのものを展開させたければ $$ とする必要がある。 なんだか独特な文法だけど、このへんを駆使すれば、ファイルを探索してそれを元に target と prerequisite を実行時に決めることができる。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU