Nobuyoshi Sato (発信者情報開示本Booth) @[email protected]

ピピーッ！国産国産いうなら、まずちゃんとNTTが開発したファイルシステムとセキュリティシステムを使い、東大が開発した漢字入力システムを使いなさ〜い！

BTRON全然ブートしないけどね…

これは神聖な焼却炉

生活道路の法定速度、30キロを新設　中央線ない所、歩行者安全狙い：朝日新聞デジタル https://www.asahi.com/articles/ASS5Y4CM7S5YUTIL015M.html?ref=tw_asahi

なんかWin11で度々文字入力カーソルのフォーカスが勝手に外れる問題、謎の個人有能ブログさんが突き止めてくれていた。

https://jiyuukaitakusha.com/howto-deal-focus-loss/

> これまでのPC経験から、この原因は簡単にはわからないだろうという感じを受けていました。ウェブで検索してもなかなか真の原因がわからず困っていましたが、ようやく原因がわかり対策できました。うれしいので広めたいと思います。

いやまさに同じ感覚というか、広めてくれてありがとうという感想です。

プログラム側のステップ数の話ならナイーブな実装相当になるから削減幅は大きそうに見えるが、メリットが回路規模の削減なのに対してデメリットは計算時間 (所要サイクル数) の増加とプログラムサイズの増加の2つになるので、実は後者も整数の幅に対して線形なコスト増加ではなさそうな気がする。実物なしに考えてもたぶん結論でなそう

16ビット先のキャリーを低遅延で計算する回路コストと32ビット先のキャリーを低遅延で計算する回路コストは線形な増加はしていない気がするので。 (自分で書いたことはないが組み合わせの数の問題なので雑な推定はできる)

“ちゃんと設計された” 整数の加算回路は複数ビット先のキャリーを低遅延で出せることに価値があるので、全加算器を連ねただけのナイーブな加算回路を比較対象として想像すること自体が不適切で、そこから話を始めないといけない

ふと思ったけど、CPUに整数の加算命令が無くて、and,or,xor,シフトの組み合わせで代用すると、なんステップ分処理が増えるんだろう？＞＜
小規模なリレー計算機とか真空管計算機で回路の小型化のために(全)加算器を省くって戦略をしたハードウェアってあったのかな？＞＜；