Intelの次世代CPUについて語ろう 20
>＞Netbustの特徴といえば長いパイプラインよか分厚いマイクロコード層って気がするけどね。
>だな。
俺も一票入れとく。
コレは今後にも生かされると思われ。
>だな。
俺も一票入れとく。
コレは今後にも生かされると思われ。
聴いてみたら、更新された第14回の内容が、第11回と全く同じなのですけれど・・・・・・。
mini_pod051216.mp3・・・3.68 MB (3,865,913 バイト)
mini_pod060106.mp3・・・3.68 MB (3,865,913 バイト)
mini_pod051216.mp3・・・3.68 MB (3,865,913 バイト)
mini_pod060106.mp3・・・3.68 MB (3,865,913 バイト)
誤爆ｽﾏｿ
mp3も貼らずに誤爆とな！
946 ：MACオタ＞945 さん：2006/01/08(日) 20:03:56 ID:10CtVYlC
>>945
---------------------
ﾌﾟでﾊﾟｲﾌﾟﾗｲﾝ30段にしてくれちゃってｗ
---------------------
伊達にパイプライン段数を増やした訳じゃなくて、HTT, XD, EM64T, EIST, iAMT, VT等の新機能を
NetBurst流に実装するための選択す。>>926さんの感想
=====================
Netbustの特徴といえば長いパイプラインよか分厚いマイクロコード層って気がするけどね。
=====================
わ、そういう意味合いなんすよ。
---------------------
ﾌﾟでﾊﾟｲﾌﾟﾗｲﾝ30段にしてくれちゃってｗ
---------------------
伊達にパイプライン段数を増やした訳じゃなくて、HTT, XD, EM64T, EIST, iAMT, VT等の新機能を
NetBurst流に実装するための選択す。>>926さんの感想
=====================
Netbustの特徴といえば長いパイプラインよか分厚いマイクロコード層って気がするけどね。
=====================
わ、そういう意味合いなんすよ。
ヨナたんを買おうとおもうんだけど、VTに対応してる？
分厚いマイクロコード層か…。
また、後藤氏のホラが…。
また、後藤氏のホラが…。
952 ：MACオタ＞951 さん：2006/01/09(月) 01:52:42 ID:GaC5e/pI
>>951
例によって後藤氏わ自分の書いている内容を理解している訳じゃ無いすけど、読み聞きした話をそのまま
書いているという点で、大きな間違いわ無いかと思うす。NetBurstわトレースキャッシュのフェッチから実行に
至るまでuopで完結するという意味でx86 ISAに対する独立度わ比較的高くて、マイクロコード群によって
x86との互換性を保つという形を取っているというのわ、間違ってないかと思うす。
CPUアーキテクチャスレッドにも書いたすけど、こういう点で分解後の命令自体も元のRISC ISAである
PowerPCのcracking/millicodingなんかとわ、大きく違うということになるす。
例によって後藤氏わ自分の書いている内容を理解している訳じゃ無いすけど、読み聞きした話をそのまま
書いているという点で、大きな間違いわ無いかと思うす。NetBurstわトレースキャッシュのフェッチから実行に
至るまでuopで完結するという意味でx86 ISAに対する独立度わ比較的高くて、マイクロコード群によって
x86との互換性を保つという形を取っているというのわ、間違ってないかと思うす。
CPUアーキテクチャスレッドにも書いたすけど、こういう点で分解後の命令自体も元のRISC ISAである
PowerPCのcracking/millicodingなんかとわ、大きく違うということになるす。
どんな命令セットでも、マイクロアーキテクチャに大幅な革新があるたびに、命令セットは陳腐化する。
x86は、命令セットがRISCと比べて圧倒的に古いため、真っ先にトランスレーション路線に向かった。
それが逆にRISCに対するアドバンテージとなり、
P5→P6→NetBurstのような非常にアグレッシブなパイプラインの拡張をすることができた。
RISCプロセッサでもこのようなトランスレーション機構は拡張されていき、
やがてハイエンドプロセッサでは当たり前の機能になる。
x86は、命令セットがRISCと比べて圧倒的に古いため、真っ先にトランスレーション路線に向かった。
それが逆にRISCに対するアドバンテージとなり、
P5→P6→NetBurstのような非常にアグレッシブなパイプラインの拡張をすることができた。
RISCプロセッサでもこのようなトランスレーション機構は拡張されていき、
やがてハイエンドプロセッサでは当たり前の機能になる。
954 ：MACオタ＞953 さん：2006/01/09(月) 02:09:20 ID:GaC5e/pI
>>953
-------------------
それが逆にRISCに対するアドバンテージとなり、
-------------------
論理レジスタが少ないとかわ、どう考えてもカバーできそうに無いすけど。。。
-------------------
それが逆にRISCに対するアドバンテージとなり、
-------------------
論理レジスタが少ないとかわ、どう考えてもカバーできそうに無いすけど。。。
かといって増やすと互換性に支障がある。それ以外の部分を頑張ることで対抗とするしかないだろう。
実際、長らくそれで対抗してきた。
64bit対応の時、「どうせ互換性に支障があるなら汎用レジスタも増やしちゃえ」で16個になったが。
実際、長らくそれで対抗してきた。
64bit対応の時、「どうせ互換性に支障があるなら汎用レジスタも増やしちゃえ」で16個になったが。
Microsoftにx86-64はAMD64と互換にしろと言われて
すぐ対応できたのもNetBurstの構造ならではなのかもね。
すぐ対応できたのもNetBurstの構造ならではなのかもね。
>>954
CISCにせよRISCにせよ、どのみち（ソフトウェア）スタックにアクセスせざるを
得ない時点で、レジスタ数ってのはそれほど決定的な因子ではないけどね。
むしろキャッシュ設計とかレイテンシ隠蔽の方が効いてくる。
OSなしで、かつアセンブラでごりごり書くような時代・分野ならまた別だけど。
CISCにせよRISCにせよ、どのみち（ソフトウェア）スタックにアクセスせざるを
得ない時点で、レジスタ数ってのはそれほど決定的な因子ではないけどね。
むしろキャッシュ設計とかレイテンシ隠蔽の方が効いてくる。
OSなしで、かつアセンブラでごりごり書くような時代・分野ならまた別だけど。
958 ：MACオタ＞957 さん：2006/01/09(月) 15:36:40 ID:GaC5e/pI
>>957
--------------------
CISCにせよRISCにせよ、どのみち（ソフトウェア）スタックにアクセスせざるを得ない
--------------------
プロセッサごとにコードのバイナリフォーマットとか、ABI (Appllication Binary Interface)とかが異なることわ
ご存知すか？RISCわレジスタを有効利用するために、レジスタ渡しを多用するす。
--------------------
CISCにせよRISCにせよ、どのみち（ソフトウェア）スタックにアクセスせざるを得ない
--------------------
プロセッサごとにコードのバイナリフォーマットとか、ABI (Appllication Binary Interface)とかが異なることわ
ご存知すか？RISCわレジスタを有効利用するために、レジスタ渡しを多用するす。
>>958
ABI知ってれば、なおさらスタックアクセスが重要なのも分かるでしょ。
関数コールがレジスタだけで済むのはあくまで相手が関数を呼ばない（リーフ関数）
場合だけで、2段以上にネストする場合は引数用のレジスタを使い回すために
値をスタックに保存する必要がある。もちろんローカル変数用のレジスタもね。
現実的なプログラムでは2段どころかそれ以上のネスティングするんだから、
「レジスタ渡しを多用」してもたかがしれてる。局所的には効くことはあるけどね。
もちろん、ABIを無視してフルアセンブラで手書きできる場合は、
レジスタやりくりして極力スタックを使わないようにすることもできるけど、
RISCってそういう分野目指した設計だったっけ？
ABI知ってれば、なおさらスタックアクセスが重要なのも分かるでしょ。
関数コールがレジスタだけで済むのはあくまで相手が関数を呼ばない（リーフ関数）
場合だけで、2段以上にネストする場合は引数用のレジスタを使い回すために
値をスタックに保存する必要がある。もちろんローカル変数用のレジスタもね。
現実的なプログラムでは2段どころかそれ以上のネスティングするんだから、
「レジスタ渡しを多用」してもたかがしれてる。局所的には効くことはあるけどね。
もちろん、ABIを無視してフルアセンブラで手書きできる場合は、
レジスタやりくりして極力スタックを使わないようにすることもできるけど、
RISCってそういう分野目指した設計だったっけ？
960 ：Socket774：2006/01/09(月) 16:25:03 ID:ghGtqUI4
なんでMACｵﾀ
ってキモい書き方するの？
ってキモい書き方するの？
キャラ立てジャマイカ？
>Microsoftにx86-64はAMD64と互換にしろと言われて
>すぐ対応できたのもNetBurstの構造ならではなのかもね。
だよなぁ。
実例見せられてから、分厚いマイクロコード層がどうのっていう話なのに
それを信じられない方がどうかしてる。
確実にNetBurstの特徴、そして長所だと思われ。
>すぐ対応できたのもNetBurstの構造ならではなのかもね。
だよなぁ。
実例見せられてから、分厚いマイクロコード層がどうのっていう話なのに
それを信じられない方がどうかしてる。
確実にNetBurstの特徴、そして長所だと思われ。
963 ：MACオタ＞959 さん：2006/01/09(月) 17:23:45 ID:GaC5e/pI
>>959
-------------------
2段以上にネストする場合は引数用のレジスタを使い回すために値をスタックに保存する必要がある。
-------------------
実装依存す。レジスタホイール等、関数呼び出しのオーバーヘッド軽減のための工夫わ初期RISCの特徴
の一つす。
-------------------
2段以上にネストする場合は引数用のレジスタを使い回すために値をスタックに保存する必要がある。
-------------------
実装依存す。レジスタホイール等、関数呼び出しのオーバーヘッド軽減のための工夫わ初期RISCの特徴
の一つす。
決定的な因子じゃないっていうのが何を言いたいのかよく分からんけど、
レジスタ数を8→16に増やしたことによる大域的効果って、キャッシュ
サイズを512k→1Mに増やすのと同じか、むしろ大きいぐらいじゃなかっ
たっけ。
局所的な速度向上にはさらに確実に効くし、どっちも大事だと思うけど。
>>963
初期RISCって言い方は違うでしょ。
初期RISCという言い方で当てはまるのはSPARCくらいしかない。
ところが最近でもIA64はレジスタウィンドウがある。
レジスタ数を8→16に増やしたことによる大域的効果って、キャッシュ
サイズを512k→1Mに増やすのと同じか、むしろ大きいぐらいじゃなかっ
たっけ。
局所的な速度向上にはさらに確実に効くし、どっちも大事だと思うけど。
>>963
初期RISCって言い方は違うでしょ。
初期RISCという言い方で当てはまるのはSPARCくらいしかない。
ところが最近でもIA64はレジスタウィンドウがある。
965 ：MACオタ＞964 さん：2006/01/09(月) 17:53:56 ID:GaC5e/pI
>>962
変換機構が強力なのは、NetBustの特徴と言うよりは
当たり前のトレンドといった方がよいでしょ。
P6に対してNetBurstやMeromの方が進んでいるのは当たり前。
NetBurstといえども、主要なALU演算はマイクロコードROMは使用していない。
分厚いマイクロコード層という表現はどっからきたんでしょう。
変換機構が強力なのは、NetBustの特徴と言うよりは
当たり前のトレンドといった方がよいでしょ。
P6に対してNetBurstやMeromの方が進んでいるのは当たり前。
NetBurstといえども、主要なALU演算はマイクロコードROMは使用していない。
分厚いマイクロコード層という表現はどっからきたんでしょう。
Meromに期待大！
レジスターホイールに該当するページが見つかりませんでした。
もしかして: register file
もしかして: register file
969 ：MACオタ＞966 さん：2006/01/09(月) 18:16:34 ID:GaC5e/pI
>>966
---------------------------
分厚いマイクロコード層という表現はどっからきたんでしょう。
---------------------------
例えば、http://www.intel.co.jp/jp/developer/technology/itj/2004/volume08issue01/art01_microarchitecture/p04_new.htm
===========================
命令に含まれるμop の中にトレース・キャッシュ上でエンコードできないものがあると、その命令に含まれる
すべてのμop をマイクロコード ROM から取り出す必要があります。今回の拡張によりマイクロコード ROM
への実行時のアクセスが少なくなり、フロントエンドから実行コアへ送り込むμop の平均流量が拡大しました。
今回、トレース・キャッシュ上でエンコードするようにした命令の中で典型的なものは、オペランドがレジスタの
インダイレクト・コール命令とソフトウェア・プリフェッチ命令でしょう。
===========================
つまりハードウェアでの実装に先立って自由にuopレベルの命令追加ができることを示しているす。
---------------------------
分厚いマイクロコード層という表現はどっからきたんでしょう。
---------------------------
例えば、http://www.intel.co.jp/jp/developer/technology/itj/2004/volume08issue01/art01_microarchitecture/p04_new.htm
===========================
命令に含まれるμop の中にトレース・キャッシュ上でエンコードできないものがあると、その命令に含まれる
すべてのμop をマイクロコード ROM から取り出す必要があります。今回の拡張によりマイクロコード ROM
への実行時のアクセスが少なくなり、フロントエンドから実行コアへ送り込むμop の平均流量が拡大しました。
今回、トレース・キャッシュ上でエンコードするようにした命令の中で典型的なものは、オペランドがレジスタの
インダイレクト・コール命令とソフトウェア・プリフェッチ命令でしょう。
===========================
つまりハードウェアでの実装に先立って自由にuopレベルの命令追加ができることを示しているす。
>>963
register file じゃないでしょ。
register file ならどんな CPU でもあるわけだし。
おそらく register window のことだと思うので、そのつもりで返事した。
溢れるとぐるぐる回るので、wheel って言い方も分からなくはないけど、
register window って言うのが普通。
register file じゃないでしょ。
register file ならどんな CPU でもあるわけだし。
おそらく register window のことだと思うので、そのつもりで返事した。
溢れるとぐるぐる回るので、wheel って言い方も分からなくはないけど、
register window って言うのが普通。
971 ：MACオタ＞968 さん：2006/01/09(月) 18:25:27 ID:GaC5e/pI
>>968
register fileわ、8本なり128本なりのレジスタ全体のことを指す用語す。
レジスタホイールについてわ、http://www.cs.umd.edu/~hollings/papers/mdl.pdfとか。。。
ただ検索結果を見ると、明らかに「レジスタウィンドウ」の方が一般的な用語だったす。
http://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%B8%E3%82%B9%E3%82%BF%E3%83%BB%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6
register fileわ、8本なり128本なりのレジスタ全体のことを指す用語す。
レジスタホイールについてわ、http://www.cs.umd.edu/~hollings/papers/mdl.pdfとか。。。
ただ検索結果を見ると、明らかに「レジスタウィンドウ」の方が一般的な用語だったす。
http://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%B8%E3%82%B9%E3%82%BF%E3%83%BB%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6
SPARCの特徴は、レジスタが環状に構成された「リングレジスター」アーキテクチャだが‥
関数呼び出しやシステムコールなどたいていのことをリングレジスター頼みにしようとするから、
すぐへばるんだよねえ。プロセスや、スレッドの切り替えになると役に立たなくなるし。
ぶっちゃけ、アイデア倒れ。
関数呼び出しやシステムコールなどたいていのことをリングレジスター頼みにしようとするから、
すぐへばるんだよねえ。プロセスや、スレッドの切り替えになると役に立たなくなるし。
ぶっちゃけ、アイデア倒れ。
へー、AMD 29000 や i960 もレジスタウィンドウを持ってたのか。
知りませんでした。
> すぐへばるんだよねえ。
まあ溢れるとカーネルモードへのコンテキストスイッチが入るので
悲惨ですな。
> ぶっちゃけ、アイデア倒れ。
Itanium の立場は…
知りませんでした。
> すぐへばるんだよねえ。
まあ溢れるとカーネルモードへのコンテキストスイッチが入るので
悲惨ですな。
> ぶっちゃけ、アイデア倒れ。
Itanium の立場は…
Itaniumはコンパイラで頑張るのが前提だからまだいいじゃないか。
>>974
レジスタウィンドウの有無と、EPICは、あまり関係ないと思われ。
大域的最適化なんかは、レジスタウィンドウの節約に効く可能性が
あるけど、これは別にItaniumに限った話じゃなくてSPARCでも同じ
だし。
レジスタウィンドウの有無と、EPICは、あまり関係ないと思われ。
大域的最適化なんかは、レジスタウィンドウの節約に効く可能性が
あるけど、これは別にItaniumに限った話じゃなくてSPARCでも同じ
だし。
とりあえず
,,―‐． r-、 ＿,--,、
,―-、 .| ./''i､│ r-,,,,,,,,,,,,,,,,,,,,,,,,―ｰ． ﾞl, ｀"ﾞﾞﾞﾞﾞ￣＾ ＼
／ ＼ ヽ,ﾞ'ﾞ_,/ .ﾞl、 `i､ ＼ _,,―ｰ'''/ .,ｒ'"
.,,,、.,,i´ .,/＾'i､ ｀'i､｀｀ ｀--‐'''''''''''''''"'''''''''''ﾞ ｀゛ .丿 .,/
｛ "" ,/｀ ヽ、 ｀'i､ 丿 .,/｀
.ヽ、 丿 ＼ .＼ ,/′ 、ヽ,,、
ﾞ'ｰ'" ﾞ'i､ ‘i､.r-、 ＿_,,,,,,,,--、 ／ .,／＼ `'-,、
ヽ .]ﾞl ｀ﾞﾞﾞﾞ"ﾞﾞﾞﾞ￣￣ ｀'i､ ,／ .,,／ .ヽ ＼
ﾞヽ_/ .ヽ_.,,,,--―――――ｰ-ノ_,／ﾞ,,／′ ﾞl ,"
｀ ﾞ‐''"｀ ﾞ'ｰ'"
,,―‐． r-、 ＿,--,、
,―-、 .| ./''i､│ r-,,,,,,,,,,,,,,,,,,,,,,,,―ｰ． ﾞl, ｀"ﾞﾞﾞﾞﾞ￣＾ ＼
／ ＼ ヽ,ﾞ'ﾞ_,/ .ﾞl、 `i､ ＼ _,,―ｰ'''/ .,ｒ'"
.,,,、.,,i´ .,/＾'i､ ｀'i､｀｀ ｀--‐'''''''''''''''"'''''''''''ﾞ ｀゛ .丿 .,/
｛ "" ,/｀ ヽ、 ｀'i､ 丿 .,/｀
.ヽ、 丿 ＼ .＼ ,/′ 、ヽ,,、
ﾞ'ｰ'" ﾞ'i､ ‘i､.r-、 ＿_,,,,,,,,--、 ／ .,／＼ `'-,、
ヽ .]ﾞl ｀ﾞﾞﾞﾞ"ﾞﾞﾞﾞ￣￣ ｀'i､ ,／ .,,／ .ヽ ＼
ﾞヽ_/ .ヽ_.,,,,--―――――ｰ-ノ_,／ﾞ,,／′ ﾞl ,"
｀ ﾞ‐''"｀ ﾞ'ｰ'"
>>977
マイクロコードでAMD64に容易対応できたというのは半分以上は正しいだろう。
しかし、Northwood→Prescottではそれ以前に整数周辺の設計は見直されているし、
NetBurstでなけば不可能というほどのものでもないでしょう(マイクロコードROMはP6からあるわけで)。
マイクロコードで対応して、後続のスケジューラ、実行コアにハード的な手を加えないのは
ただの手抜き実装でしかないし。
Merom/Conroeは、PenMとは異なるマイクロアーキテクチャに基づいている、
全くの新設計のコアなので、64bitにどう対応するのかはPenMの実装とは関係ありません。
(トレースキャッシュはないだろうから、フロントエンドと後続のパイプラインとの分離度は
NetBurstよりも低くなるのではないか。しかし、マイクロコードROMはなくすことはできないでしょう。)
マイクロコードでAMD64に容易対応できたというのは半分以上は正しいだろう。
しかし、Northwood→Prescottではそれ以前に整数周辺の設計は見直されているし、
NetBurstでなけば不可能というほどのものでもないでしょう(マイクロコードROMはP6からあるわけで)。
マイクロコードで対応して、後続のスケジューラ、実行コアにハード的な手を加えないのは
ただの手抜き実装でしかないし。
Merom/Conroeは、PenMとは異なるマイクロアーキテクチャに基づいている、
全くの新設計のコアなので、64bitにどう対応するのかはPenMの実装とは関係ありません。
(トレースキャッシュはないだろうから、フロントエンドと後続のパイプラインとの分離度は
NetBurstよりも低くなるのではないか。しかし、マイクロコードROMはなくすことはできないでしょう。)
979 ：MACオタ＞977 さん：2006/01/09(月) 21:05:27 ID:GaC5e/pI
>>977
------------------
IntelはPenM系のCoreでどうやってx64を使うつもりなんでしょうか？
------------------
普通に64-bit ALUを用意すると伝えられているす。例えば、
http://pcweb.mycom.co.jp/articles/2005/08/31/idf1/002.html
==================
Q: この4 issueというのは、たとえば倍速のExecution Unitが2つという意味ですか? それとも等速
(Regular Speed)のExecution Unitが2つという意味でしょうか?
A: 等速のものが4つだ。
==================
このために必要な開発期間の差がNetBurstによるEM64Tの実装とMerom/Conroeの登場までの時間差
ということになるす。
------------------
IntelはPenM系のCoreでどうやってx64を使うつもりなんでしょうか？
------------------
普通に64-bit ALUを用意すると伝えられているす。例えば、
http://pcweb.mycom.co.jp/articles/2005/08/31/idf1/002.html
==================
Q: この4 issueというのは、たとえば倍速のExecution Unitが2つという意味ですか? それとも等速
(Regular Speed)のExecution Unitが2つという意味でしょうか?
A: 等速のものが4つだ。
==================
このために必要な開発期間の差がNetBurstによるEM64Tの実装とMerom/Conroeの登場までの時間差
ということになるす。
ちなみに、Merom/Conroeは単なる64bit版のPenMではないので、
NetBurstにEM64Tを実装するのにかかる時間と、Merom/Conroeが登場するまでの時間を比較するのは
全くナンセンスです。
NetBurstにEM64Tを実装するのにかかる時間と、Merom/Conroeが登場するまでの時間を比較するのは
全くナンセンスです。
981 ：MACオタ＞980 さん：2006/01/09(月) 21:17:15 ID:GaC5e/pI
>>980
"Wider"の件とか、言いたいことわ判らないでもないすけど、Intelのプロセッサアーキテクトわ、こう言っているす。
http://www.itmedia.co.jp/news/articles/0508/29/news008_2.html
-----------------------
エデン氏 「ははは（笑）それは言えない。言えないよ。ただ、プロセッサの進化という面では、
YonahからMeromよりもDothanからYonahの方が大きなものになります」
-----------------------
"Wider"の件とか、言いたいことわ判らないでもないすけど、Intelのプロセッサアーキテクトわ、こう言っているす。
http://www.itmedia.co.jp/news/articles/0508/29/news008_2.html
-----------------------
エデン氏 「ははは（笑）それは言えない。言えないよ。ただ、プロセッサの進化という面では、
YonahからMeromよりもDothanからYonahの方が大きなものになります」
-----------------------
>>981
そのソースはとっくによんでいるけど、私は苦しい解釈をしました。
確かにwiderになった以外に目新しい要素がなさそうなMerom/Conroeより、
DualCore化、L2の共有化などのマルチコア時代への布石ともいえる機能をそなえたYonahの方が、
"プロセッサの進化という面では"新しいといえる。
そのソースはとっくによんでいるけど、私は苦しい解釈をしました。
確かにwiderになった以外に目新しい要素がなさそうなMerom/Conroeより、
DualCore化、L2の共有化などのマルチコア時代への布石ともいえる機能をそなえたYonahの方が、
"プロセッサの進化という面では"新しいといえる。
今日はMacオタが正しいことを言いまくってるな
ようなmeromも、64ビット化以外はP6アーキティクチャを踏襲してる
ってことでいいのかな?
デザインを流用してるんじゃないか?とか
フルスクラッチの設計じゃないか?って
細かいことはいい･･･
ってことでいいのかな?
デザインを流用してるんじゃないか?とか
フルスクラッチの設計じゃないか?って
細かいことはいい･･･