アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
もともとALUは (スコア:5, 興味深い)
…冷やしたり、あたり玉でなんとかなりそうですな。
(E64T対応になっている時点で64bitは当たり前でしょうし)
niagaraがシンプルなコアなのにクロックがあがらない部分については、やっぱりキャッシュコーヒーレントなのかなぁ。
そんな感じでちょこちょこ気になる部分はありますね。
kusanagi shin
Re:もともとALUは (スコア:4, 興味深い)
だから、32bitの演算では、
・下位16bitの演算(0.5サイクル)
・上位16bitの演算(0.5サイクル)
・フラグのセット(0.5サイクル?)
と完了まで1.5サイクルかかるわけで・・・。
http://www.intel.com/technology/itj/q12001/pdf/art_2.pdf [intel.com] (9ページ目参照)
まあ、下位16bitの演算結果を使って、
後続命令の演算(下位16bit)を開始することにより、
データ依存関係にある命令を0.5サイクル刻みで実行できますけど、
演算器間のラッチを抜けば、フラグのセットまで1サイクルでできそうですし、
その設計の方が性能が上がるプログ
Re:もともとALUは (スコア:2, 興味深い)
> ・下位16bitの演算(0.5サイクル)
> ・上位16bitの演算(0.5サイクル)
> ・フラグのセット(0.5サイクル?)
上位16bitの演算と同時にフラグの演算は終わってますよ。
んで、後続のJcc・SETcc・MOVccとかに特定bitだけ渡せればそれでいいわけで。
# だから何、って話もありますが。
Re:もともとALUは (スコア:1)
本当に実装してたかどうかちょっと自信なくなってきた。論文は斜め読みした。
Re:もともとALUは (スコア:1, おもしろおかしい)
Re:もともとALUは (スコア:1)
> 全部ROMにしちまえば、もっと早く<ぉぃぉぃ
ROMは資源を浪費するうえに、アクセス速度が遅いのであまり速い演算器にはなりませんよ。
16bit同士の加算でも17ビット×4Gアドレス=68Gビットのメモリが必要です。
掛け算だと結果は32ビットだから128Gビット。
8bit同士なら9ビット×64Kアドレス=576Kビットのメモリでできますが、
そんな演算器をマスクROMとかで用意するぐらいなら、
専用ロジックとして論理圧縮した方が小さくて高速です。
#昔、Z80時代にEPROMで掛け算器を作ったことがあるのでID
Re:もともとALUは (スコア:1)
使うテーブルの値が間違っていたというアレ。SRT Algorithm [intel.com]