【骨髄反射】INTEL厨 vs AMD厨 Part21【ｴｸﾞｾﾞｸﾃﾌﾞ】

>>746
それのどこにメモリオペランドが存在するのかと小一時間...

あ、逃げられるのを防ぐ為に、より単純な方向に進もうとしたのか、スマソ。

x86のニモニックには疎いんだけど、それは64bit即値が示すアドレスの中身を
64bit単位でレジスタにロードするって意味？即値が単なるデータなら趣旨から
外れるし、アドレス情報なら少し馬鹿っぽいけどある程度合理的な逃げ道がある
のよね…出来れば、録音の目の届かないとこで話し合いたいな。

>744,>745

珍しくまともな書き方で話とる・・・。とうとうスクリプトが壊れたか・・・。
つーか、そんな書き方出来るなら最初からヤレ。このとんちんかん。

>>741,742
相変わらず他人の考えを横取りするのだけはうまいね。
年収4500万とやらもそうやって稼いでるんだろうね。

>752

確かにコイツって他人が見解を出した後にしか出さないよなぁ・・・。
やっぱりスクリプトなので、ベースになるモノが必要なんだろうな。

>>752
前半部は、T.Aさんの示したソースを自分なりに解釈して書いたんだろうね。
後半部で、俺たちが思ってる疑問、解釈をまったく理解できていないことは明白になっているわけだが。

SunとMSが和解

SunとMSは10年来の係争を和解で終結させ、技術協力協定を結んだ。
MSはSunに、アンチ・トラスト訴訟に関して$700百万、パテント訴訟に関して$900百万、
サーバ製品に関するパテント使用料の前払い金として$350百万、合計約$20億支払う。
SunとMSは、今後、相手のテクノロジーの使用料を払う。

その他、MSのJavaサポートの件や、Javaと.Netの件、SunはXeon (さらにOpteron）製品
にWindowsを搭載できるようになるらしいことも書かれています。

http://mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html

#Intel包囲網ですな。

まあまあ、ﾏﾀｰﾘとできるのならいいではないですかヽ(´▽｀)ノ

>742
結局のところIA-32eを出すきっかけが欲しかったのでしょうね。
AMD64が発表された当時、パーソナルユースではIA-64よりも歓迎されておりましたし、
Itaniumの価格もなかなか落ちてくる気配が感じられなかったのでYamhillを開発したのだと思います。
今までのIntelの戦略を考えると、恐らくYamhillはAMD64以上の機能を持った命令群だったのでしょうね。
その内容には非常に興味が有るのですが・・・ もう知る由も無いんですよね。少々残念です(^^;

>744
そういう場合は下位DW，上位DWと分割してトレースキャッシュに格納しているのではないでしょうか？

>>756
RISCの命令は固定長が基本だから並べるのはナシでは。
64bit即値のロードは、デコーダで
16bitのロード命令４つとかに分割されるものかと思われ。多分。
μOPのサイズが32bit程度なら。

つかIA32eとかの64bit拡張のじゃなくて、現状の32bitデータのロードも
16bitのロード命令２つに分割されてるかと。きっと。

>>757
並べるのはナシだったらアドレッシングに厳しい制約がつかない？

>757
μOPレベルでそれをやってしまうとクロックが余計にかかってしまいますから（その例だと4クロックですかね）、恐らく違うのではないかと。
この辺りはimm32とimm64のクロック数を比較してみれば想像できるのですが、まだ公表されていないみたいですしね(^^;;

私は32bit境界から外れなければOKだと考えていたのですが・・・ 他の64bitRISCプロセッサはどのように処理しているのでしょうね？

>>759
>>380のリンクの資料のP292みて。

>>757
μOPの幅は、32bitよりもはるかに大きいよ。
x86命令を効率的に実行する事を考えると、32bitの即値オペランドを最低でも
1つは運べないといけない。

>>760
AMD側はALUやレジスタファイル自体を64bit化してるから、プレスコの参考に
はならないんじゃ？

>760
Athlon64/Opteronはimm8〜imm64までクロック数は変わらないみたいですね。
もしPrescottも同じならば、imm64時においても一括してデータを処理できるようにならなくてはいけませんよね。
そうなるとμOPのサイズを64bit以上にするか、L2キャッシュからデータを取得するアドレッシング・モードを設けているのかもしれません。

>>757
現状の32bitPen4の場合は、32bit即値は2つに分割されてトレースキャッシュに格納されます。
ただし、32bit命令が2つの16bit命令に分割される訳ではないです。
32bit即値を伴う命令は、即値データを分割して、前後の隣接する命令の空いている即値データ領域に格納します。
つまりトレースキャッシュ上のμOPは厳密な意味では固定長ではありません。
32bit即値を伴う命令が連続すると、即値データを格納する領域が不足してしまうので、
ダミーのμOPが追加されます(その分遅くなります)。

参考文献↓ ページ2-72「Assembly/Compiler Coding Rule 48.」
ttp://developer.intel.com/design/pentium4/manuals/24896610.pdf

>>744
uOPに変換が基本ですぜ。
64bit即値オペランドは3つに分解すればそれでＯＫ

>>763
> その分遅くなります
騒ぐ必要は何処にも無いぜ。

>>763
日本語版の最適化マニュアル

アセンブリ/ コンパイラ・コーディング規則48 ( 影響ML、一般性M)。( 符号拡張された
16 ビット即値としてコード化できない)32 ビット即値を使用する命令同士を、近くに配
置しないようにする。32 ビット即値を使用するマイクロオペレーション(μOP) の直前ま
たは直後には、即値を持たないマイクロオペレーション(μOP) をスケジューリングする
(2-58 ページ)。

よく考えたらμOPのサイズまで64bit幅に揃える必要は無いですね＿|￣|○
よって>762の下2行は無視してください(^^;;;;

>>764
3つに分解って・・・？？？？？？？？？？

>768
恐らく実行OP，上位DW，下位DWに分けるという事だと思います。
でもμOPが64bitサイズのデータを一括で処理できるとしたら、64bit即値を1クロックで処理できるのですが・・・

>>763
なるほどー、カコイイ格納方法してるねぇ・・・

>>770
あの文章はコーディングの最適化について説明してるのであって
別にトレースキャッシュの構造を説明しているわけじゃありません。

>>771
それはわかるけど、最適化が必要な理由として >>763 は説得力あると思う。
トレースキャッシュの容量をケチる手段としても、よさげだしね。
トレースキャッシュ上ではμOPペア毎に合計32bitの即値を保持できて、スケ
ジューラに渡すときに正しい即値データを持つμOPが作られる。
再構成用に余分な1bitが必要になるが16bit減らせるので、15bitの省エネ。
12KμOPSの容量が各15bit少なくなると22Kバイトも少なくてすむ。

まぁ、どっちにしてもIA-32eになったからと言って容量が倍要るなんて
戯言を言い出すのはT.A君だけだろうね。

私がWillametteで試した範囲では、
　add reg32,ebp
を連続配置（reg32はeax,ebx,ecx,...等、同じレジスタが連続しないようにいろいろ変える）
して実行した場合、IPC=3

　add reg32,0x00007777
を連続配置して実行した場合も、IPC=3

　add reg32,0x77777777
を連続配置して実行した場合は、IPC=1.5

　add reg32,ebp
　add reg32,0x77777777
　add reg32,ebp
　add reg32,0x77777777
　　:
と交互に連続配置して実行した場合は、IPC=3

　add reg32,0x00007777
　add reg32,0x77777777
　add reg32,0x00007777
　add reg32,0x77777777
　　:
と交互に連続配置して実行した場合は、IPC=2

結局今イニシチアブを持ってるのはAMDっと。
Intelはいまいち冴えがなく後手後手。

LGA775はピン曲げでマザーを使い捨てにさせる陰謀だと予想

コア欠けならぬピン曲げが登場するわけか･･･

でも、ピン折れで死亡するCPUも無くなる訳か。

変わりにピン曲がりするマザーの誕生

　　　　　　＿＿＿＿＿＿
　　　　　／::::::::::::::::::::::::::＼
　　　　 /::::::::::::::::::::::::::::::::::＼
　　　　|:::::::::::::::::|＿|録音|＿|
　　　　 |;;;;;;;;;;ノ　　　＼,, ,,／ ヽ 　　　　　
　　　　 |::（ 6　　ー─◎─◎　）　　　　　　　　　　
　　　　 |ノ　　（∵∴　（ o o）∴）　　　　　　　　　　
　　　／|　　　<　　∵　　 ３　∵>　　ん？uOPに変換が基本ですぜ♪
　　　::::::＼　　ヽ　　　　　　　 ノ＼　　　
　　　:::::::::::::＼＿＿＿＿＿ノ:::::::::::＼

>780

先生はμｏｐって書かないでuＯＰってかくんだよなぁ・・・。
バカっぽいよ。

>773
まあ、どっちにしても年収4500万なんて世迷い言言い出すのは先生だけだろうね。

>>776
クレームを避けるためと予想。
ピンはマザボ側だから、簡単に曲がってもインテルは悪くないぞと。

録音の年収
2000万→3000万→4500万
大体一月毎に1．5倍になります。

4500万　・・で、どこの貨幣単位で？

リラ

>>781
μの読み方を知らないので変換できないのです。

ﾐｭ

>>785
ｳｫﾝ
冗談じゃなくウォンだとホントっぽくなるウォン計算だと年収400万円くらいになるんだよね
金持ちって自分で言ってもなかなか買い換えないとか見てるとちょーどそのくらいになるんだよねぇ

>>789
漏れは年収150万円の貧乏フリーターでつが何か？

日本語も不自由だしね、彼

>>773
>まぁ、どっちにしてもIA-32eになったからと言って容量が倍要るなんて
>戯言を言い出すのはT.A君だけだろうね。
まあ、戯言なのは今更言われるまでもなく自分自身よく判ってるからね。
何しろ真相はIntel(それも設計陣のトップレベルの連中)しか知らないんだから
どれほど真実味があっても、所詮、推測に過ぎないし。

ただ、夕べからのやり取りは「議論」のやり方としてはいい勉強になっただろう？

議論の結末には3種類あるんだが、

1)発散：複数の意見が単に衝突を繰り返すのみで、問題解決に至る結論が出ない状態。
　議論の結末としては最悪。更に最悪の場合は問題自体が摩り替わってしまい、本来の
　問題以外に別の問題を派生させてしまう。
2)妥協：複数の意見の利害関係の中間点を結論とすることで、取り敢えず問題解決を
　優先する。これでも充分に問題が解決する場合もあるが、多くの場合は根本的解決
　にはならず、後々に最終的な解決を必要とする。
3)昇華：複数の意見を元に短所を改め、長所をより高めた意見を作り上げる。
　議論の結末としては最も理想的。

録音先生が議論に参加した場合、必ず1)の結末に向かっているんだよねぇ・・・
(参加しなかった場合については、夕べからのμOP関連の議論を見れば判るだろうから
改めて書く必要はないよな？)


ちなみに、あくまで「議論の方法」についての話なので、出てきた「結論」について
は考えてないからね。

744 ：Socket774 ：04/04/03 07:42 ID:FkN9EIqi
>>741
オペランドにメモリを指定している場合はどうなるんだ？
64bitモードの場合、64bitのアドレス値が必要になるんじゃないか？

764 ： ◆Rb.XJ8VXow ：04/04/03 12:03 ID:j1o0NWBg
>>744
uOPに変換が基本ですぜ。
64bit即値オペランドは3つに分解すればそれでＯＫ

なんかやけにスレ進んでると思ったら…
やっぱり予想通りでしたか…

>>792
非常に残念だが結論が分かりきってるものを議論する必要は無い。
単に戯言を否定するだけで良いのだよ♪

議論の結末とか、詭弁とか、そんなの気にしてるのは
録音に良い様に弄ばれてる厨だけだろ。
いい加減相手にするのは止めにしてみてはどうか。
奴を論破することによって、自らの精神の平安を得ていると言うのなら
俺が言い過ぎた、ごめんね。
月曜にでも医者に行け。

ついでに言っとくが「真実味」はこれっぽっちも無いぞ。
ってか、「寝ぼけるなボケ！」としか言い様が無い。