Itaniumで64ビットLinuxだぁ！

IntelのItanium（Mackinlay）でLinuxして64ビット
コンピューティングしましょう。AMDの64ビットCPUも
いいかもしれん。PowerPC64ビットとかSparc、DecAlphaも
あり。

Opteron楽しみだね。年内出たらそっこう買だね。

hammerが今のところ一番身近っぽいな。
まだ出てないけど。

でも個人で持てる64bit機、はぁはぁ…

盛り上がりそうにないから、64bitLinux統合すれに変更してくれ。

2038年までには乗り換えるぞ・・・

ゲーム機ですら128ビットだといっているのに、OSは何をやっているのだ
と問いたい。

そりゃ、根本的に違うだろ。

OSの場合互換性が必要だからね。
Windowsだって、3.1から10年も経とうとしてるってのに、
互換性を重視していまだに内部で16ビットのコードが残ってたりする。

じゃあ、実際にアプリで６４ビットバージョンが普及するのは１０年後か・・・

AMDﾏﾝｾｰ！
インテルの独占だったら、
64bitPCなんて5年以上先の話だったと思う。

という訳で来年の頭に発売予定の
Hammerは楽しみ。

あげるよー

超初心者に突っ込みをくらう>>6をage

>>3
＞でも個人で持てる64bit機、はぁはぁ…
Sun の Bladex00 とかだったら、１台￥15万くらいじゃなかったッケ？
純正増設 DIMM とかは、ボッタ栗値段がついてたけど
アキバで売ってるの使えたりして。

その代わり、Itanium, Itanium2 は、ダメだね。
1000個ロット単位で、1CPU ￥15万だから。

そういえば McKinley の正式名称が Itanium2 になったそうだが。
Pentium -> Pentium2 -> Pentium!!! -> Pentium4 って
Pentium の数が売れてブランド名とかの販売戦略で Pentium を
残したんだよね？
Itanium なんて、でんでん売れてなくて（<- 和歌山弁）
性能も同クロックの P!!! の 2/7 しか出ないダメダメ CPU なのに
2 付けて、どーすんだよ。

>>13
>Itanium なんて、でんでん売れてなくて（<- 和歌山弁）
>性能も同クロックの P!!! の 2/7 しか出ないダメダメ CPU なのに
>2 付けて、どーすんだよ。

設問1
MPEG2は8Mbpsですが、一時間の動画を32ビットアドレスで
かつオンメモリで扱うことは可能ですか？

設問2
ページサイズを4Mにするといかなる影響がありますか？

設問3
セグメントレジスタを切り替えた場合、見た目は１命令
ですが、メモリーの転送がどれだけ発生するでしょうか?
キャッシュはどうなりますか?

>6
＞ゲーム機ですら128ビットだといっているのに、OSは何をやっているのだ
犬コロだって動いてるじゃん。
http://pc.2ch.net/test/read.cgi/linux/995559975/103

てか、商用 UNIX 機に関しちゃ、金さえ出せば、いくらでも 64bit CPU はあるんよ。
わざわざ犬コロ使いたい自虐的なヤツが、他の商用 UNIX 機みたいな
１台 2WAY, 5〜600万出すわけ無いじゃん。
（まぁ、今朝の日経産業新聞に載ってたケド、IA32 x 32 で w2k で
２台￥10億も出すような物好きな、ミノルタっちゅー所があったみたいだけど。）

Intel の OEM で、HP が売ってる Itanium 733MHz x 1, cache 2MB の最低ヤツで
$8,000 (<- OS 無し。OS は、更に +$8,000)
大体￥100万出して、ftp で拾ってきた犬コロか？おめでてーな。

>>14
設問1)
残念ながら処理系によっては2GB越えは可能です。

以下、うんこ

>>14
全部あてずっぽうで、すまんけど。
俺、キャプチャーとか、エンコとか好きだから。

A1.
8Mbps で 1h って約 4.7GB片面 の DVD 一枚だよね。
（正確な値は、計算めんどっちい。）
4GB 以上扱えるのが魅力なんで、メモリでブン廻せたらハエーだろうな。

A2. すまん、逆に問い
＞ページサイズ
TLB で扱えるサイズの事？
最大いくつダッケ？Intel のデベロッパーサイトから
Software Developer's Manual Vol.2 拾ってくりゃ判るんだが
生憎手元に無い。

影響は、１プロセスで使える範囲が広くなって良いよな。

A3.
わりぃ、セブメントレジスタの概念って持ってるか知らん。
（IA32 の環境に飛び込む事は出きるらしいが）
ネイティブでやりゃぁ良いじゃん。

と、ここまで書いて、性能が悪いのを IA32 環境だからだろ？
と言い訳したかったのか？
2/7 って、IA64 ネイティブの環境と、IA32(P!!!) 比べた値じゃなかったか？
自作板で拾い読みしたから、覚えてないが。

これも自作板だった気がするが、i386 って、はえー i286 つって売れたじゃん？
Itanium って完全失敗作で、おせー(足元にも及ばん) P!!!。P2 400くらい。
だもんで、Opteron （なんちゃらハマー）が本命。
なんていってるヤツも居たが、どーだろね？

>>14 に書いてある不備を全部引き継ぐわけだろ。あと３年は、ダメだよな。

あー、省略されちった。

Itanium って完全失敗作で、おせー(足元にも及ばん) P!!!。P2 400くらい。
だもんで、Opteron （なんちゃらハマー）が本命。

で省略されるように狙えば良かった。

4KBってSCSIの転送単位の最小量に由来するって
インターフェースにあった。
つまり仮想記憶のディスクIOをできるだけ小刻みにするって趣旨。
この前提が崩れた場合、従来のOSとデザインがマッチしなくなるだろう。
386以降はセグメントレジスタを入れ替えると、マイクロコードが
セグメント情報を読みに行ってメモリー管理ユニットの
アドレス変換テーブルを切り替えるようになってる。
CPU内部で何十ステップかのプログラムが動作して、何度も
メモリーをアクセスするんでパイプラインもぐちゃぐちゃになる。

>>19
＞パイプラインもぐちゃぐちゃになる。
Pen4 がダメだ！とか発売当時言ってたヤツの理屈が、
そのパイプラインが深過ぎて、、、分岐予測がどーのこーの
って言ってたんだよな。
でも実際は、パイプライン深くした事によって、クロック上げやすくなって
コンパイラの開発も従来資産で、どんどん進んで。
メモリレイテンシも、じゃんじゃか上がって。
P4 売れないと、IA64の開発費出ないんで必死だよな。
ダメダメ言われて「いや、バックアッププランも用意してる」
なんて言ってるけど。

>>19
最初、何書いてんだかチンプンカンプンでよ。
誤爆レスか？
って思ったら、おめー >>14の ffyzbFVu じゃねーか。
んっで、何が言いたいんだよ。

話は反れるけど、ちょっと聞いくれよ >>14 よ。
＞4KBってSCSIの転送単位の最小量に由来するって
その SCSI ボードでも、4GB 越えのアドレスに DMA 出来なくって
困ってるヤツがあるんだよ。
そこんとこ、どーなんよ？

>>20
っていうか、クロックをバカみたいに上げるために手っ取り早く
パイプラインの段数増やしただけだと思うが。論理が逆だよ。

>>14
はーやーくーしーろーよー
＞おめー、何が言いたいんだよ。

よーし、パパ寝ちゃうぞー。

>>23
精髄反射レスだ。
＞論理が逆だよ。
どっちが先なんか知らん。その通りだったら、その通りだ。
んで、おめーの Itanium Linux 関する意見っちゅーのは
宜しければ書いて頂けませんか？

>>14
Q3. セグメントに関しちゃ、昔からサッパリ君でよ。
Z80 より 6809 の方が、スッキリしてて好きでな。
PA-RISC は、入りやすかったんよ。
んで、今でもコメットさんですら判んねぇ。（情報処理のヤツな）

Q2. のページサイズが 4KB ってのも、PA-RISC もそーなんだよ。
１ページ 4KB ってのは。
PPN(Pysical Page Number) とか VPN (Virtual) とか。
でもよ？もう10年近くなる古い話で申し訳ないんだが、
最大 256KB(うろ覚え) 扱える BTLB(Block ...) っての持ってて、
IA64 で言う所の VPHT だっけか？何個かまとめて扱えるてよ
更にリプレイス出来ん様にロックが掛けられて、
たかだか 10MB 弱のカーネルなんか、リプレイス無しでブン廻せてたんよ。
IDE なんか無かったぞ。SCSI2 1GB の HDD 有難がって使ってたもんだ。
でも、SCSI の転送単位のなんとかやらで、破綻してたか？
使い方によって、使い分けるべ？ふつー。

Q1. MPEG2 8Mbps って決まってねーぞ？
予談だが、>>17 で書いた通り、1h って約 4.7GB片面 の DVD 一枚だよね。
DVD-Video の企画からすると平均 8Mbps って良い線だけどな。

規格な。

あー、ついでに Q3 のキャッシュがどーのこーのって、
128B ラインサイズで、カポカポ拾うんだから
VLIW のバンドルってかんけーねぇんじゃねーの？
つか、キャッシュなんてソフトウェアが意識しなきゃいけねーの
サイテーのアーキテクチャだと思うが。
これ最強に面白れーよ。
http://pc.2ch.net/test/read.cgi/linux/1010895550/86

http://pc.2ch.net/test/read.cgi/unix/1013653220/22-
http://pc.2ch.net/test/read.cgi/unix/984486488/78-96
も面白いよな。

古典的なこれとか
http://piza.2ch.net/log/unix/0008251/945060590.html
後続かなかった、これとか
http://piza.2ch.net/log/unix/0008251/956023488.html
も笑える。

で、Itanium(tm) は、ダメって事でおけ？

誰かItaniumのクロックがなかなか上がらない理由を説明してよ。

64bitのアドレスを16進表記するとさ、
一目で数値が分らないんだけど、これも慣れるもんかね。

64ビットマシンに限った話ではないけども、例えばインテルのPentium系は
ハードウェアのページサイズが普通のサイズ以外に１MBぐらいのものが
ハード的には設定できるよね。でも普通のLinuxやUnixでそのような
異なる大きさの仮想記憶のページは使えるようにはなっていない。
これはせっかくある機能を生かして使えないので損している。
例えば、mallocのようにメモリーをアロケートする場合に、その
割り当てをページ単位でしかもそのページのサイズを指定して
割り当てることができるようにならないものだろうか？

>32
4MBにするとAthlonとNvidiaでほげほげではなかったかな？

>>32
↓は？

http://www.osdl.org/cgi-bin/eidetic.cgi?command=display&modulename=projects&on=1061

x86-64のカーネルも相変わらず4kなんだよなぁ。。。

chip set 460GX　で使えるSDRAMメモリーの種類は？
Registered、Unbuffered、ECC付き、ECC無し、PC100、PC133
のどれだ？　700MHzのItaniumと800MHzのItaniumだとメモリの
種類を変えないとだめ？

＞SDRAMメモリーの種類は？
Registered、ECC付き、PC133
＞700MHzの
そんなの無い。733MHz
＞種類を変えないとだめ？
良い。

460GXを使っているばあい、ECCが必須で、しかもUnbuffered
（非Registered）でないとだめ。
（チップセットのドキュメントはインテルサイトに行けば読める）
CL2、CL3はどうなのかは判らない。PC100でもPC133でも動きそう
ではあるが、ひょっとするとCPUのクロック（と内部倍率）と
関係があるかな。

一応 TurboとRedhatからItanium用は出てる。
買う？
http://www.jp.redhat.com/products/Itanium/
http://www.turbolinux.com/products/tls7i/index.html

FTPで入手すれば十分では？

ポインターが64ビットならば､CやFortranのプログラミング
モデルも、整数も64ビットを標準にするべきである。
そうしないと、ソフトウェア的には一種のセグメントもどき
の処理をしないといけない。バグも入りやすくなる。

>>41
新たなソフトを作る分には問題無いだろ。リニアな空間なら
ｘ８６のセグメントとは全然違って楽勝だろ。

問題はint=pointerを前提としたK&R時代のスタイルを持った
プログラマーだよ。こういった連中を淘汰するのにちょうど
いいんじゃないのか（ｗ）

>>42
int=32bitと思っている連中を淘汰するためにint=long=64bitきぼん。

　a[k] の形で配列をアクセスする場合に、
　a は６４ビットポインターなのに、添え字式の型は32ビットの整数
だとすると、あたかもaがセグメントレジスターで、添え字式がセグメント
内のオフセットだということをいいたいのだ。つまりセグメントサイズが
4GB であるが、セグメントは６４ビット空間の任意の位置をベースに
できる。それから相対で＋−２GBのアクセスができる。。と。
フルに６４ビットのアドレス空間を使えるようにするのには、
配列の添え字の式を６４ビットであるとしてくれなければ、困る。

ぽいんた＋32ビット整数の演算結果は64ビット。
で、size_tとか使ってる式の結果は64ビット。
memset(pos + 1, 0, (size_t)1000);とか。
だからANSI−CとC++の場合はmake一発で通る確立は低くない。
定数を置く時にちょっと問題あるかな。

>>44
ちなみに、offset_t k;
a[k]が正解だろ。

Fortran だって、整数が６４ビットでなければ、配列の添え字式が３２ビット
整数では、非常に困るよ。確かに８バイト整数を宣言して使えば可能なの
かもしれないが、、、
　コンパイラのオプションで整数を８バイトを標準とするという設定が
できるものもあるが、そういうことをした場合に、異なるモデルの
オブジェクトをリンクできてしまうと、ややこしいことになる。
リンク時にエラーとするか、あるいはせめて指定すれば検査して
ワーニングをリンカーが出してほしいね。

http://www.zdnet.co.jp/enterprise/0205/29/02052908.html
ロイターさん、タイトルのつけ方がヤバイです。

あのようにでかいパッケージで、電源供給にすごいサイズのユニットを
必要とし、熱をがんがん出すCPUあるいはシステムがノートコンピュータ
に搭載されようになるにはずいぶん時間がかかるだろうし、デスクトップ
としても、とてもPentium４並のシステムには価格的にもなり難いだろう。
　ところがもしもAMDあたりが、内部レジスターの６４ビット拡張により
あっけなくPentium４とそれほど違わない物量のマシンを作ってしまえば、
大量にでまわるシステムのためにならソフトを書く動機が生じやすいので、
結果的にItanium系は普及せずに終わる可能性が相当あると思う。
せめてかつてのSlot-1程度のパッケージングと消費電力に抑えてくれなきゃ。

>49
わけわかめー。
Itaniumの事について言ってるの？

このスレ板に有無の話をしているのではないのか、すれちがいかな？

誰も板に有無なんて期待していないというワナ。
まぁ5年後ぐらいにはみんな使っているでしょうけど。

C言語のプロトタイプ宣言には次のような機能を追加すべし、


int f(int, long long, int [long long]);

すなわち、配列の引数の型の情報をも宣言に含めるのだ。

関数の仮引数の宣言における配列の添え字の型の宣言だけではなくて、
変数としての配列の宣言においても、配列のサイズを与えるためだけ
ではなくて添字式の型を宣言できるように拡張するとよいだろうね。
現在のC言語では添字式は整数値であると決められている為に、なにかと
不便だ。

たとえば現在なら
static a[];
と書くところを

static int a[(long)]; とかくことで配列ａの添字式はlong として
計算されてポインタ値ａに加算されるとしたらよい。

static int b[(unsigned long)];は添字式が値が符号なしロングとして
static int c[(signed short)];は添え字式が値が符号付のSHORTとして、
static int d[(unsigned char)];は添え字式の値が符号なしCHARとして、
static int e[(long long)];は添え字式の値がlong longとして計算される。
という意味にすればよい。
配列のサイズも含めて宣言する場合でも同様に、
static int g[(long long)1234567890123];
などと書けるようにするとよい。

>>54
ハァ？
b[(char)offset] とかすればいいじゃん。

配列の添字が符号付だと、何がしあわせなのでしょうか？
バグの温床になるだけのような気がしますが...

vector使えば良いのでは？

int が３２ビットというのは良くない。６４ビットマシンでは
６４ビットになるべきだ。さもなくば、配列の添え字式は
ロング（６４ビット整数）として計算されてポインターと
加えられることにC言語の規格を変えて欲しい。それも無理なら、
上のようなプロトタイプ宣言で明示的に指定したときには
添え字式をそのような式として評価するようにして欲しいな。

offset_tを定義すれば無問題

>>60
けど、やっぱILP64(っていうんだっけ?)が良いとは思う。
long longが128とかあるのかね。

実メモリーが１００GB程度つめるマシンが欲しい。