「Microsoft が Itanium 向け開発終了を宣言」記事へのコメント

64bit版Windowsのタコな仕様はItaniumのせい

[Anonymous Coward]

x64版Windowsで64bitコード←→32bitコード間の呼び出しができない（thunkがない）のは、Itanium版Windowsの仕様に合わせたから。
そのせいで64bitコードと32bitコードをシームレスに実行できるAMD64のメリットがWindowsにおいては全く生かされていない。

言わばItaniumの負の遺産。
後方互換性にこだわるMicrosoftのことだから、128bit版Windowsが出るまでこの仕様に悩まされそうorz

Re:64bit版Windowsのタコな仕様はItaniumのせい

[Anonymous Coward]

デタラメを言ってるように見えます。

もう少し具体的に説明してくれませんか? あるいは、外部のソースを。

Re:

[Anonymous Coward]

なんで誰でも分かってる様な調べりゃすぐ出てくる既出なことを説明せにゃならんのだね
それをすることで我々にどんなメリットがありますか？

＃しかも、あなたは多分説明しても分からないレベルでしょうに

Re:64bit版Windowsのタコな仕様はItaniumのせい

[Anonymous Coward]

デタラメを言う人ほど説明を嫌がって逃げますね。

AMD64なら32bitと64bitのコードがシームレスに実行できるといっても、現実的には64bitModeとCompatibilityModeの切り換えは必要なので、同一OSインスタンス上で32bitのプロセスと64bitのプロセスが同居できるという意味です。
(64bitModeのまま従来の32bitのコードを実行できるといっても、CPUが命令をデコードして実行できるだけであって、プログラマが望むような動作をするわけではありません。)

64bitのEXEから32bitのDLLを呼び出せない、32bitのEXEから64bitのDLLを呼び出せないという仕様は当然です。Win32APIのDLLならExportしているプロシージャの引数の仕様が明らかですからthunkを作ることができてWOW64がそうしていますが、しかし、サードパーティのDLLのためのthunkはマイクロソフトには作れません。サードパーティがthunkを提供するなら64bit版のDLLをビルドして提供したほうがいいでしょう。

Re:

[Anonymous Coward]

微妙に間違っているゾ

AMD64のモード切り換えはセグメントで自動的に行われるので「シームレス」。これはIA64のようにモード遷移のための命令が必要ないことを指している。

Win32ではプロセスにフラットなメモリ空間が提供されるが、仮想アドレスが重複しないように複数のセグメントが配置されている。ユーザーのコードがセグメント切り換えを意識しないだけで、CPUが自動的にセグメントを切り換えている。したがって、AMD64では同一プロセス内に64bit Modeで走らせるコードセグメントとCompatibility Modeで走らせるコードセグメントを混在させることが可能。

しかし、そ

Re:64bit版Windowsのタコな仕様はItaniumのせい

[baronet (18986)]

なんか詳しい方がいらしているようなので、教えていただけるとありがたいです。
このあたりずっと疑問に思っていたので。

32bitのEXEから64bitのDLLを呼び出せないのは分かる(気がする)のですが、64bit
のEXEから32bitのDLLを呼び出せないのが解せないです。64bitのコードを4GB未満
のアドレス空間を使わないように配置するだけではダメなんでしょうか？

プラグインなどの32bit資産が64bitから自由に使えれば64bitへの移行は少しは楽
になるので、この方向だけサポートしてくれれば良かったのにと思ってしまいます。

Re:

[Anonymous Coward]

64bitのEXEから32bitのDLLを呼び出すためには、32bitのDLLが触るもの全てを4GB未満のアドレス空間に配置しなくてはなりませんが、これが大変なんです。

まず、DLLのExport関数の引数で渡すポインタ。
DLLに渡す可能性のあるものを区別し最初から4GB未満の空間に配置するか、Export関数の呼び出し前後で4GB未満の空間との間でコピーする必要がある。コピーは、ただの文字列なら簡単だけど、ポインタを含んだ構造体へのポインタともなると、厄介だ。そして、32bitのポインタと64bitのポインタの混在はバグの温床になる。

次に、スタック。
DLLを呼び出す可能性のあるスレッドのスタックは4GB

Re:64bit版Windowsのタコな仕様はItaniumのせい

[baronet (18986)]

解説ありがとうございます。
十分に理解できていませんが、とりあえずスタックの問題は大変難しそうだと想像できました。
ポイントを教えていただけたのでもうちょっと勉強してみます。

Re:

[Anonymous Coward]

そもそも64bitだというだけで、AMD64版がItanium版の系譜だと思いこんでる人が異常なんじゃないかと。
#全然別のアーキテクチャだし64bit版WindowsはむしろIA32ベースじゃないのかと言いたい

Re:

[Anonymous Coward]

OS内部はともかくとして、ユーザーに見せている部分はIA64版とAMD64版は(ほぼ)同じです。
IA64版で整備したものがAMD64版でも踏襲されています。

Re:

[Anonymous Coward]

巷に出回る多くの説明が間違っていると言うことを認識出来ないかわいそうな人だな
ほとんどの人がわかっちゃいない

Re:

[Anonymous Coward]

Windows NTでセグメントが使えない(少なくともユーザーモードのCプログラムから隠蔽されている)のがRISCプロセッサの負の遺産だとは思わないけどなあ。
それは今だから言えることかもしれないけど、128bit版Windowsが出る頃になったらWOW64の仕様についてもやっぱり同じような感想を持つんじゃないかな。

Re:

[Anonymous Coward]

セグメントの有用性は昔から明らかで、ItaniumにもPOWERにもあります。
現在でもグーグルのNaClなどで活用されていますから、RISCプロセッサというよりもセグメントのないOSつまりUNIXの負の遺産ですね。
8086で、セグメントについての無知ゆえの勘違い思い込みからトラウマになった人が影響力を持ったからかもしれない。MSは一役買ってるな。DRとインテルは無罪。

Re:64bit版Windowsのタコな仕様はItaniumのせい

[SteppingWind (2654)]

いや, UNIXはセグメントありますよ. 例えば初期のVAX-11 [roguelife.org]のころからセグメンテーション機構を利用していますし, セグメンテーションバイオレーションなんてエラーはセグメント機構を使ったメモリ保護が無ければ出ようがないでしょう.

それに, セグメントの評判を落としたことにインテルの責が無いとは言えないでしょう. 386登場以前は1セグメントで取り扱えるアドレス空間が64k(16bit)に限られていて, ちょっとプログラムの規模が大きくなるとプロセス内でセグメントを動的に設定しなおすというアクロバティックなことをしなければならなかったのですから. これが, セグメント単位がハード的なアドレス幅と同じ20bitとか, あるいはせめて18bit程度だったら評価は全く違っていたと思います. まあ, 当時のハードウェアの性能とかコストとかの兼ね合いで16bit幅のセグメントにしたんだろうことは理解はできますが. 言い方は悪いですが, こうしたハード側の手抜きをソフト側でカバーさせようとするのは, IA64でも同じだったのかと思います.

Re:

[Anonymous Coward]

PDP11ハードウェアはセグメンテーション機構を備えておりUNIX 7もそれを利用した仮想記憶を実装していましたが(スワップ)、
VAXなどでページング機構が導入されるとそちらを使いセグメンテーションは捨てていますね。

8086は最初からミッドレンジのアプリケーションプロセッサでマニュアルにも明記されていました。ハイエンドではないですね。
あなたも軽トラに10t載せたがるタイプですか？やっぱりトラウマで目が曇っているとしか。

Re:

[Anonymous Coward]

80286は?
それこそ80286でせめてセグメントサイズ1MBにできればよかったんですが。
別にハイエンドでもない68000は16MBリニアアクセスできましたし。

Re:

[Anonymous Coward]

80286はハイエンドではありません。iAPX432がハイエンドです。
68000はハイエンドですね。6809がミッドレンジです。

Re:

[Anonymous Coward]

私も以前は286でセグメントサイズを大きく出来ていればと考えたこともありますが、
現在は「無理だった」と考えています。

まず、セグメント内のアドレッシングが16bitで足りなくなります。
となると、命令セットを作り直しですね。
分岐命令やデータアクセス関係のアドレス指定はビット数の拡張が必要。
インデックスレジスタの幅も拡張しないといけないし、その拡張した17bit以上の
幅を持つレジスタに一発で値をセットできる命令も必要でしょう。
（8086のMOV命令は16bitデータまでしか転送できない）

もともと286はリング保護のプロテクトモードを拡張するためだけに作られたような
CPUですから、基本の命令に手を入れるのはやっぱり386を待つ必要があったでしょう。

Re:

[Anonymous Coward]

少々極論が過ぎるんじゃないかな。Itaniumが企画された当時、ハードウェアによる
命令実行の並列性の向上はいずれ限界が来るだろうという予測はまあまあ妥当で、
それを打開するためにVLIW、その改良であるEPICの採用に踏み切ったのは技術的に
チャレンジだったと言えるでしょう。
コストや8ビットのハード＆ソフト互換性などの制約から、やむなく64k/セグメントを
採用した8086とは質的にかなり違う。互換性をかなぐり捨てて、あまり例のない
アーキテクチャを採用したわけですしね。
残念ながら成功したとはいえないものの、それは結果論で、チャレンジがなければ
EPICやそれに類するアーキテクチャの限界も見えてこなかったわけだから
その点だけでも意味無しとは言えんと思いますが。

Re:

[Anonymous Coward]

i8086が作られた当時の64KBのセグメントの大きさは、いまの感覚でいえば4GBに相当します。
i8080の全メモリ空間が64KBだったんですよ。64KBもあれば十分な余裕があると考えられていたし、128KBもメモリを積めば複数のプログラムを同時にメモリ上に置いて擬似マルチタスク可能という、そういう時代。

Re:64bit版Windowsのタコな仕様はItaniumのせい

[tensu (34456)]

> i8086が作られた当時の64KBのセグメントの大きさは、いまの感覚でいえば4GBに相当します。

それは無いよ!!

Re:

[Anonymous Coward]

> > i8086が作られた当時の64KBのセグメントの大きさは、いまの感覚でいえば4GBに相当します。
> それは無いよ!!

いや、まさにそんな感じ。
当時は16bitCPUといえば16bitアドレスが当たり前だった時代です。ミニコン含めてね。
今は64bitになかなか以降せず、ネットブックが出るくらいだし、言い得て妙なたとえです。

Re:

[Anonymous Coward]

ツッコムなら
＞マイクロコードの厚化粧の8800や68000とは対照的です。
こっちだろう

#その後ゴテゴテとモードや命令を上塗りせざるを得なかった86を棚に上げて元々素地の良い68kを厚化粧とは聞き捨てならん

Re:

[Anonymous Coward]

おいおい
8086 → タイムリーなスペックで16bitのCPUを、8080を拡張する形で作ろう (1978年、29000トランジスタ)
68000 → 本当は32bitのCPUを作りたいんだけど今は無理なので、16bit+マイクロコードでエミュレーションしとこう (1980年、70000トランジスタ)
ですよ。

マイクロコードで32bitのCPUのフリをしていたという点で「厚化粧」と言ったのでしょう。

Re:

[Anonymous Coward]

比較的詳細な資料で68000の内部データパスを検討したことがありますが、おっしゃる通り素直なものではなく、巨大なマイクロコードで無理矢理ISAを実装していたようです。
68000を素地がよいと思う人はISAだけでマイクロアーキテクチャには興味がないのではないでしょうか。

アーキテクトが素直なマシンというと6502を挙げることが多いです。

Re:

[Anonymous Coward]

68000は有名な二段階マイクロコードを持ちます。
マイクロコードは17bit命令が544個、ナノコードは68bit命令が336個でトータルは32kビットになります。総トランジスタ数が70k個ですから如何ほどか想像がつくというものです。

ナノコードの幅に注目すべきです。これは制御信号が多いことを意味し、つまるところデータパスにテンポラリレジスタが山のようにあるということにほかなりません。
プログラマには見えないテンポラリレジスタがやたらとあるのはあまり優れた設計ではないということは言を待たないでしょう。

Re:

[Anonymous Coward]

8080の次のプロセッサの8800は32ビットアーキテクチャですが物理アドレス空間は16MBでセグメントは最大64KBです。
8086はそのリリーフですからね。開発期間はごく短かったようですが、それが逆にミニマリスト的美しさを与えているのかもしれません。
マイクロコードの厚化粧の8800や68000とは対照的です。

Re:

[Anonymous Coward]

64bit云々より
Intel IA64 と Intel x64(EM64) では根本的にアーキテクチャが違いますよね?

AMD64 と互換性がある(というか渋々真似した)のは Intel x64(EM64)な訳で、
今回のIA64のItaniumとは関係ない話の様な気がするのですが…。
IA64が駄目だからx64用も駄目で行くよー、という話だったんですか?

そもそもIA64(Itanium)用のWindowsってリリースされてたんですね。

まあ、何にしてもいいかげんWindowsには完全64bit環境に移行して欲しい…。