アカウント名:
パスワード:
x64版Windowsで64bitコード←→32bitコード間の呼び出しができない(thunkがない)のは、Itanium版Windowsの仕様に合わせたから。そのせいで64bitコードと32bitコードをシームレスに実行できるAMD64のメリットがWindowsにおいては全く生かされていない。
言わばItaniumの負の遺産。後方互換性にこだわるMicrosoftのことだから、128bit版Windowsが出るまでこの仕様に悩まされそうorz
Windows NTでセグメントが使えない(少なくともユーザーモードのCプログラムから隠蔽されている)のがRISCプロセッサの負の遺産だとは思わないけどなあ。それは今だから言えることかもしれないけど、128bit版Windowsが出る頃になったらWOW64の仕様についてもやっぱり同じような感想を持つんじゃないかな。
いや, UNIXはセグメントありますよ. 例えば初期のVAX-11 [roguelife.org]のころからセグメンテーション機構を利用していますし, セグメンテーションバイオレーションなんてエラーはセグメント機構を使ったメモリ保護が無ければ出ようがないでしょう.
それに, セグメントの評判を落としたことにインテルの責が無いとは言えないでしょう. 386登場以前は1セグメントで取り扱えるアドレス空間が64k(16bit)に限られていて, ちょっとプログラムの規模が大きくなるとプロセス内でセグメントを動的に設定しなおすというアクロバティックなことをしなければならなかったのですから. これが, セグメント単位がハード的なアドレス幅と同じ20bitとか, あるいはせめて18bit程度だったら評価は全く違っていたと思います. まあ, 当時のハードウェアの性能とかコストとかの兼ね合いで16bit幅のセグメントにしたんだろうことは理解はできますが. 言い方は悪いですが, こうしたハード側の手抜きをソフト側でカバーさせようとするのは, IA64でも同じだったのかと思います.
80286は?それこそ80286でせめてセグメントサイズ1MBにできればよかったんですが。別にハイエンドでもない68000は16MBリニアアクセスできましたし。
少々極論が過ぎるんじゃないかな。Itaniumが企画された当時、ハードウェアによる命令実行の並列性の向上はいずれ限界が来るだろうという予測はまあまあ妥当で、それを打開するためにVLIW、その改良であるEPICの採用に踏み切ったのは技術的にチャレンジだったと言えるでしょう。コストや8ビットのハード&ソフト互換性などの制約から、やむなく64k/セグメントを採用した8086とは質的にかなり違う。互換性をかなぐり捨てて、あまり例のないアーキテクチャを採用したわけですしね。残念ながら成功したとはいえないものの、それは結果論で、チャレンジがなければEPICやそれに類するアーキテクチャの限界も見えてこなかったわけだからその点だけでも意味無しとは言えんと思いますが。
> i8086が作られた当時の64KBのセグメントの大きさは、いまの感覚でいえば4GBに相当します。
それは無いよ!!
ツッコムなら>マイクロコードの厚化粧の8800や68000とは対照的です。こっちだろう
#その後ゴテゴテとモードや命令を上塗りせざるを得なかった86を棚に上げて元々素地の良い68kを厚化粧とは聞き捨てならん
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
64bit版Windowsのタコな仕様はItaniumのせい (スコア:2, 興味深い)
x64版Windowsで64bitコード←→32bitコード間の呼び出しができない(thunkがない)のは、Itanium版Windowsの仕様に合わせたから。
そのせいで64bitコードと32bitコードをシームレスに実行できるAMD64のメリットがWindowsにおいては全く生かされていない。
言わばItaniumの負の遺産。
後方互換性にこだわるMicrosoftのことだから、128bit版Windowsが出るまでこの仕様に悩まされそうorz
Re: (スコア:0)
Windows NTでセグメントが使えない(少なくともユーザーモードのCプログラムから隠蔽されている)のがRISCプロセッサの負の遺産だとは思わないけどなあ。
それは今だから言えることかもしれないけど、128bit版Windowsが出る頃になったらWOW64の仕様についてもやっぱり同じような感想を持つんじゃないかな。
Re: (スコア:0)
現在でもグーグルのNaClなどで活用されていますから、RISCプロセッサというよりもセグメントのないOSつまりUNIXの負の遺産ですね。
8086で、セグメントについての無知ゆえの勘違い思い込みからトラウマになった人が影響力を持ったからかもしれない。MSは一役買ってるな。DRとインテルは無罪。
Re:64bit版Windowsのタコな仕様はItaniumのせい (スコア:3, 興味深い)
いや, UNIXはセグメントありますよ. 例えば初期のVAX-11 [roguelife.org]のころからセグメンテーション機構を利用していますし, セグメンテーションバイオレーションなんてエラーはセグメント機構を使ったメモリ保護が無ければ出ようがないでしょう.
それに, セグメントの評判を落としたことにインテルの責が無いとは言えないでしょう. 386登場以前は1セグメントで取り扱えるアドレス空間が64k(16bit)に限られていて, ちょっとプログラムの規模が大きくなるとプロセス内でセグメントを動的に設定しなおすというアクロバティックなことをしなければならなかったのですから. これが, セグメント単位がハード的なアドレス幅と同じ20bitとか, あるいはせめて18bit程度だったら評価は全く違っていたと思います. まあ, 当時のハードウェアの性能とかコストとかの兼ね合いで16bit幅のセグメントにしたんだろうことは理解はできますが. 言い方は悪いですが, こうしたハード側の手抜きをソフト側でカバーさせようとするのは, IA64でも同じだったのかと思います.
Re: (スコア:0)
VAXなどでページング機構が導入されるとそちらを使いセグメンテーションは捨てていますね。
8086は最初からミッドレンジのアプリケーションプロセッサでマニュアルにも明記されていました。ハイエンドではないですね。
あなたも軽トラに10t載せたがるタイプですか?やっぱりトラウマで目が曇っているとしか。
Re: (スコア:0)
80286は?
それこそ80286でせめてセグメントサイズ1MBにできればよかったんですが。
別にハイエンドでもない68000は16MBリニアアクセスできましたし。
Re: (スコア:0)
68000はハイエンドですね。6809がミッドレンジです。
Re: (スコア:0)
現在は「無理だった」と考えています。
まず、セグメント内のアドレッシングが16bitで足りなくなります。
となると、命令セットを作り直しですね。
分岐命令やデータアクセス関係のアドレス指定はビット数の拡張が必要。
インデックスレジスタの幅も拡張しないといけないし、その拡張した17bit以上の
幅を持つレジスタに一発で値をセットできる命令も必要でしょう。
(8086のMOV命令は16bitデータまでしか転送できない)
もともと286はリング保護のプロテクトモードを拡張するためだけに作られたような
CPUですから、基本の命令に手を入れるのはやっぱり386を待つ必要があったでしょう。
Re: (スコア:0)
少々極論が過ぎるんじゃないかな。Itaniumが企画された当時、ハードウェアによる
命令実行の並列性の向上はいずれ限界が来るだろうという予測はまあまあ妥当で、
それを打開するためにVLIW、その改良であるEPICの採用に踏み切ったのは技術的に
チャレンジだったと言えるでしょう。
コストや8ビットのハード&ソフト互換性などの制約から、やむなく64k/セグメントを
採用した8086とは質的にかなり違う。互換性をかなぐり捨てて、あまり例のない
アーキテクチャを採用したわけですしね。
残念ながら成功したとはいえないものの、それは結果論で、チャレンジがなければ
EPICやそれに類するアーキテクチャの限界も見えてこなかったわけだから
その点だけでも意味無しとは言えんと思いますが。
Re: (スコア:0)
i8080の全メモリ空間が64KBだったんですよ。64KBもあれば十分な余裕があると考えられていたし、128KBもメモリを積めば複数のプログラムを同時にメモリ上に置いて擬似マルチタスク可能という、そういう時代。
Re:64bit版Windowsのタコな仕様はItaniumのせい (スコア:2)
> i8086が作られた当時の64KBのセグメントの大きさは、いまの感覚でいえば4GBに相当します。
それは無いよ!!
Re: (スコア:0)
> それは無いよ!!
いや、まさにそんな感じ。
当時は16bitCPUといえば16bitアドレスが当たり前だった時代です。ミニコン含めてね。
今は64bitになかなか以降せず、ネットブックが出るくらいだし、言い得て妙なたとえです。
Re: (スコア:0)
ツッコムなら
>マイクロコードの厚化粧の8800や68000とは対照的です。
こっちだろう
#その後ゴテゴテとモードや命令を上塗りせざるを得なかった86を棚に上げて元々素地の良い68kを厚化粧とは聞き捨てならん
Re: (スコア:0)
8086 → タイムリーなスペックで16bitのCPUを、8080を拡張する形で作ろう (1978年、29000トランジスタ)
68000 → 本当は32bitのCPUを作りたいんだけど今は無理なので、16bit+マイクロコードでエミュレーションしとこう (1980年、70000トランジスタ)
ですよ。
マイクロコードで32bitのCPUのフリをしていたという点で「厚化粧」と言ったのでしょう。
Re: (スコア:0)
68000を素地がよいと思う人はISAだけでマイクロアーキテクチャには興味がないのではないでしょうか。
アーキテクトが素直なマシンというと6502を挙げることが多いです。
Re: (スコア:0)
マイクロコードは17bit命令が544個、ナノコードは68bit命令が336個でトータルは32kビットになります。総トランジスタ数が70k個ですから如何ほどか想像がつくというものです。
ナノコードの幅に注目すべきです。これは制御信号が多いことを意味し、つまるところデータパスにテンポラリレジスタが山のようにあるということにほかなりません。
プログラマには見えないテンポラリレジスタがやたらとあるのはあまり優れた設計ではないということは言を待たないでしょう。
Re: (スコア:0)
8086はそのリリーフですからね。開発期間はごく短かったようですが、それが逆にミニマリスト的美しさを与えているのかもしれません。
マイクロコードの厚化粧の8800や68000とは対照的です。