とりあえずは、JIS X 0213をすっとばして、ダイレクトにUnicodeに入れるしかない気がしてるんですけど、なかなか予断を許しません。よければ、私(安岡孝一)の2016年8月8日・2016年8月10日・2017年1月10日の日記もどうぞ。

まあ、「REVERSE SOLIDUS (rendered as Halfwidth Yen Sign)」の問題は、1996年時点で解決できなかった以上、今後もずっと残ると思うのです。よければ、私(安岡孝一)の2006年6月5日の日記もどうぞ。

分岐判定と投機実行は一応別の話だということがわかっていないようだが、Rizen は投機実行なアーキなので、投機と組み合わせた場合で話をしようか。

現代のアークテクチャは分岐多段で複数のストリームで投機実行をかけますが、ここでは話を簡単にするために一方向の分岐で考えましょう。
命令実行時、デコーダで分岐命令が検知された場合は、分岐先を登記実行するわけですけど、その際にそのストリームについているタグとして、普通は当該分岐命令で分岐したかしないかが必ず含まれます。
また、分岐先アドレスと分岐先フェッチに使うアドレスは別のゲートですから、同じであるという保証なんかどこにもないです。今そういうレベルの話をしている。
で、実際に分岐判定が下ったとき、どのストリームを選択するかの判定をしなければいけないわけですが、この際にストリームの判定をするのに使うのも、当該分岐命令で分岐したかしないかで、いまはその分岐命令の判定時のフラグ判定が化けたか、あるいは分岐先アドレスのフェッチが化けたか、っていっているわけですから、プロセッサ実行時にそれが検知できるわけがないし、実行結果も正しくない。

＞ACさんが言ってる"遅くなるだけ"というのは、投機実行やキャッシュ機構にバグがなければ、毒饅頭はそのまま捨てられてキャッシュメモリ帯域や容量が無駄になるだけ、全体的に遅くなるだけだということ。

これは間違い。分岐予測の誤動作ってのは、分岐予測ミスなら上記の通りですけど、分岐予測 Hit の場合、要するに判定として分岐方向を間違うということだから、全体に遅くなるだけなんて程度ですむ訳がない。

必ずしも投機実行ではない。分岐予測はその本来の目的からしてかならず分岐先の命令をプリフェッチするので、それが狂ったら投機実行などやっていなくても動作はめちゃめちゃになる。

＃但し、Rizen は投機実行するアーキなのは知られているので、そもそも遅くなるとか馬鹿じゃないかとしか思えないけど。

あきれた。CPU 知らないでしょ。分岐予測 Hit で違うストリーム教えられたらまともに動くわけもない。

違うと思います。再現するときは同じ顔で、同じアプリで再現するので。メモリが捕れないとしたらもう少し状況がばらけるはず。

私も分岐予測系だと思うけど、ロジックじゃなくて内部ノイズかクロストークで弱い FF がラッチできないか反転しているような顔つきかなと。

石によって頻度がばらつくようですし、リンク手繰るような分岐では出なくて、分岐で処理を大きく変える処理が多いようなアプリで出ているっぽい。