68Kは、割り込みの際に特権スタックに書かれるデータが世代毎に異なり、スーパーバイザを含めたソフトウェア互換性は維持できていません。これは単純に設計思想で、スーパーバイザは世代毎に移植して、ユーザプログラムは互換、ということで考えていたのだと思います。一方、80386ではリアルモードで8086と全く同じシステムソフトウェアを使うことが可能です。 同じように、キャッシュについても、68030では命令キャッシュに乗っているデータを書き換えた場合、当然キャッシュに乗っているデータを実行してしまい、一部の自己書き換えを用いるプログラムではキャッシュを利用できません。i486もキャッシュを実装していますが、こちらは自己書き換えコードをサポートする設計になっています (Shoemaker, Ken: The i486 microprocessor integrated cache and bus interface [doi.org])。
> Fourth internal data bus is placed inside of ALU to be used for not only the 8bit operation, > but also digit operation, bit operation, rotate operation, and the shift operation with very small number of transistor.
そりゃあれですよ (スコア:2)
直接的には、それだけバイナリ互換が重要だったからなんだけれども
386のアーキテクチャ設計が非常に優秀だったからってのがあるでしょう。
で、ARMがx86を殺すかどうかなんとも言えないと思うけどな。
Re:そりゃあれですよ (スコア:3, すばらしい洞察)
AMD64をx86に含むのであれば、
の少なくとも一つは成立しないと無理なのではないでしょうか？
一番ありそうなのは最後ですが、少なくとも現状のタブレットは見る側ならともかく何かを作るにはいろいろ足りなくて、
それを補うためにキーボードなどを追加していくと、ソフトウェア資産が乏しく自由度の低い、ただの一体型PC(タッチパネル付き)に過ぎなくなってしまう、という……。
ジョブズ無き今、アップル含めてタブレットの概念をもう一段昇華させ、PCを駆逐できるレベルにできる会社が存在しない気がします。
このままだと、Thinkpad Tablet2 [ascii.jp]みたいな、タブレットになるノートPC、という感じに吸収されてしまうのがオチじゃないかな？消費者は全部載せが好きですし。
Re: (スコア:0)
＞このままだと、Thinkpad Tablet2 [ascii.jp]みたいな、タブレットになるノートPC、という感じに吸収されてしまうのがオチじゃないかな？消費者は全部載せが好きですし。
そこまで行けば立派な変遷では？
自分的には自宅使用型の大型タブレットはこんな [juggly.cn]感じの飽く迄PCの便利アイテム化しちゃう気がしてならないんだけど。
Re: (スコア:0)
元コメでの本題は、x86を殺せるか、です。
タブレットの行く末については元コメで言いたかった内容としては、ほぼあなたと同じです。
ので、実際Thinkpad Tablet2がATOMを用いているように、PCとして見なされる限り、x86の系譜は生き続けるんじゃないかな？と。
元コメの日本語が酷くて伝わらなかったのなら申し訳ない。
Re: (スコア:0)
むしろx86非互換の方が出ては衰退したのが歴史ですからねえ。
前はMacを非互換CPUに切り替えても平気だったAppleですら、
今はx86互換CPUでMac作ってるのが現実。
遠い将来のことは知らんけど、少なくともARMではx86のニーズ全部を殺すことなんで無理。
Re: (スコア:0)
そこはアーキテクトの選択の結果でなくて
Power系はもう速くなんないから仕方なくIntelに乗り換えたと思ってたけど。
Re: (スコア:0)
>前はMacを非互換CPUに切り替えても平気だったApple
Appleがx86互換からx86非互換CPUに切り替えたことなんてないでしょ？
Apple ][ = 6502系
Macintosh = 680x0→PowerPC
MacOS X = PowerPC→PowerPC G5→x86→x64
Re: (スコア:0)
386が優秀ではないとは言わないが、i686で採用した内部RISCによって延命できたと思うよ。
別の見方をすると、ＣＰＵシリーズで異なるuOPを吸収しているのがx86じゃないかな。
生物界でも、優秀な種が生き残っているというわけでもなく、柔軟性があったからという例は多い。
私はi386より68Kの方が優秀だったと思う。
Re:そりゃあれですよ (スコア:2)
> 私はi386より68Kの方が優秀だったと思う。
i386比でなら68kは善戦していますが、最短命令が１ワード(2バイト)と言うのは、i386の最短命令長１バイトと比べてメモリ貧乏だった当時はコード密度の点で厳しかったです。
また、i386は自力で仮想記憶をサポートしていますが、68kは68010に外部MMUを追加しなければ仮想記憶をサポートできなかったり、命令セットが32bit化けを最初から想定しているなど掲げた理想は高かったのに比べて実装が追いついていない面もありました。
アーキレベルの残念な点は
・CLR命令でRMWバスサイクル発生させる（ MOVEQ #0, DST で十分）
・相対ジャンプのオフセットが何故バイト？奇数だとアドレスエラーになるのでワードで指定すれば倍の範囲にジャンプできた
・直交性のあるアーキを標榜する割にデータレジスタとアドレスレジスタが別
などなど、それほど良いプロセッサかどうかは疑問。
結局、i386と競ったというのが伝説の原因？
Re:そりゃあれですよ (スコア:2)
68Kは、割り込みの際に特権スタックに書かれるデータが世代毎に異なり、スーパーバイザを含めたソフトウェア互換性は維持できていません。これは単純に設計思想で、スーパーバイザは世代毎に移植して、ユーザプログラムは互換、ということで考えていたのだと思います。一方、80386ではリアルモードで8086と全く同じシステムソフトウェアを使うことが可能です。
同じように、キャッシュについても、68030では命令キャッシュに乗っているデータを書き換えた場合、当然キャッシュに乗っているデータを実行してしまい、一部の自己書き換えを用いるプログラムではキャッシュを利用できません。i486もキャッシュを実装していますが、こちらは自己書き換えコードをサポートする設計になっています (Shoemaker, Ken: The i486 microprocessor integrated cache and bus interface [doi.org])。
このように、偏執的なまでの互換性へのこだわりがPC市場で受け入れられている・要求されているのだと私は理解しています。
Re:そりゃあれですよ (スコア:2)
例外の時にスタックに積まれるデータは内部マイクロコードのダンプと言うべきもので、むき出しの内部アーキが出てしまうのですが、x86は特権レベル移行と連動してスタックポインタを自動的に切り替える事でうまくそれを隠していますね。
x86が特権モードのない8086からスタートしたのが、結果的にいい方向に作用したようにも見えます。
80386が単に速い8086として振る舞うことが容易、というのは市場戦略上の成功要因の一つですね。
Re: (スコア:0)
486でもキャッシュをパージしないとうごかないっすよ。
Re:そりゃあれですよ (スコア:1)
486の場合、「プリフェチキューが長くなった」「命令コードがプリフェッチキューに入ったあとでメモリを書き換えても、キュー内の命令コードには反映されない」ということで、自己書き換え系のコードが結構動かなくなりましたね。
Re: (スコア:0)
よっぽど不評だったのかPentiumで勝手にフラッシュしてくれるようになったね。やっぱり互換性大事。
Re: (スコア:0)
> ・相対ジャンプのオフセットが何故バイト？奇数だとアドレスエラーになるのでワードで指定すれば倍の範囲にジャンプできた
PC相対アドレッシングもバイト単位でしょ
同じ加算器を使ってんのよ
> ・直交性のあるアーキを標榜する割にデータレジスタとアドレスレジスタが別
単一の大きなレジスタファイルは遅い、アドレッシングに4ビット必要になり命令のレジスタ指定フィールドが足りなくなる、分割するとバンド幅倍増->データとアドレス計算を並行に実行可能
とちゃんと考慮した上での設計になっている
x86も同じくよく練られた設計だし、教条主義的でぼくのかんがえたさいきょうのマイコンみたいなところのある68kよりもx86のほうが美しいとさえ言えるね
Re:そりゃあれですよ (スコア:2)
> PC相対アドレッシングもバイト単位でしょ
> 同じ加算器を使ってんのよ
LEAも同じ加算器使ってますよね
> 単一の大きなレジスタファイルは遅い、アドレッシングに4ビット必要になり命令のレジスタ指定フィールドが足りなくなる、分割するとバンド幅倍増->データとアドレス計算を並行に実行可能とちゃんと考慮した上での設計になっている
それこそLEAを駆使したり、この特徴を活かすのが高速化の肝でした。
> x86も同じくよく練られた設計だし、教条主義的でぼくのかんがえたさいきょうのマイコンみたいなところのある68kよりもx86のほうが美しいとさえ言えるね
全面的に同意見です。
同時代のZ8000あたりと比べてもx86は、いろいろな意味で現実的な選択の積み重ねで出来てると思います（レジスタごとに性格付けがあるのは意外とコード書きやすいし）。
Re:そりゃあれですよ (スコア:3)
>（レジスタごとに性格付けがあるのは意外とコード書きやすいし）。
これ本当にそうなんですよねえ。
私も6809 -> 68000（x68k）と来て68のアセンブラが好きなんですけど
何やら制約があったほうがコードが書きやすいってのは実感したことがあります。
脱サラした後、仕事があまりなかったので、暇に任せてDOS上で86のアセンブラで
短いコードを書いて遊んでたんだけど（いわゆる常駐プログラム（死語）とかそういったもの）
意外に楽しいしサクサク書けるんで、なるほどなあと思ったですね。
レジスタが少なく性格付けされている利点ってあるんですよね。
なんで書いたこと無いけどRISCみたいに汎用レジスタが大量にあるCPUは
多分きっと書きづらいと思う。
Re:そりゃあれですよ (スコア:2)
レジスタに性格付けがあるほうが、誰が書いても同じコードを書くことになりますね。
レジスタ番長なプロセッサは、コンパイラが書きやすいってのはあると思います。
68kもSPやFPまでアドレスレジスタなので必要以上にアドレッシングモード増やす必要があったり
（スタックポインタ相対が欲しいだけなのにアドレスレジスタ相対を用意することになるとか）
Re:そりゃあれですよ (スコア:2)
説明が要りますね
SP=A7 なんですよ
A7でけで有効なアドレッシングモードというのはなくて
アドレスレジスタ間接
アドレスレジスタ間接ディスプレスメント付き
アドレスレジスタ間接インデックス付きディスプレスメント付き
などスタックフレームを操作していのに
SP間接etcでなく、すべからくアドレスレジスタ間接etcを用意してんですよ
（用意したはのはモトローラのプロセッサアーキテクト）
これが直行的なレジスタ・アドレッシングモードが目的化しているといわれる所以です。
Re: (スコア:0)
286で完成しちゃって386以降はやや無理目な拡張という印象もあります
32ビットセグメントでセグメントサイズが64KB単位になったのは、メモリマップドファイルがやりにくくなったなどの弊害があったし
当初の予定では32ビットは432の担当とはいえ、ちょっとギチギチすぎたかな
Re:そりゃあれですよ (スコア:2)
16bitセレクタ・32bitオフセットですよね。
メモリマップドファイルは妨げていなかったと思います（結局フラットモデルに落ちつくんですが）。
そうそう、セグメントレジスタをテンポラリレジスタに使っていたコードが激遅になった記憶があります。
Re: (スコア:0)
386になってセグメントのリミット値が20ビットに拡張され、リミット値の単位を1バイトまたは4Kバイトに指定できるようになりました
16MB越えのセグメントが必要であれば4KB単位にするしかないので、L4の人たちがぼやいていました
64KBというのは間違いです
すみません
Re:そりゃあれですよ (スコア:2)
Re: (スコア:0)
ここでいうメモリマップドファイルとはmmapのようにサイズを指定するものではなくて、
ディスクリプタ経由で書き込むと勝手にファイル(セグメント)が伸びるようなものです
なので厳密に1バイト単位でセグメントサイズが欲しいのですが
68020のPMMUにもそのために1バイトページがあったりしたんですがねえ…
Re: (スコア:0)
当時、32bitも使ってバイトアドレッシングするなら、ビットアドレッシングで下位4bitは0固定が基本ってすりゃ綺麗なのにと思ったもんだな。
まあそういうのも実際あったし。
Re:そりゃあれですよ (スコア:2)
実際010までは上位８ビットはアドレスバスにでませんでしたしね。
そこでポインタの上位バイトに参照先のオブジェクトを表すコードを埋め込む（貧乏）テクニックがありました。
初期のMacintoshはまさにこれで、お陰で32bitクリーンなポインタかが32bit化で問題になったり。
Re: (スコア:0)
その反省からか、AMD64ではアドレスバスに信号が出ていないビットもすべて1で埋めておかないと例外が出るようになりましたね。
Z80あたりにはIXやIYの上半分や下半分だけにアクセスできる怪しい命令とかあったけど最近のプロセッサでは定義されていない命令は全部例外投げるようになったとか。
Re:そりゃあれですよ (スコア:2)
Z80でCレジを使ってIO命令を実行すると上位バイトにAレジの値が出るとか
286でHIMEMにアクセスできてしまうパターンが有るとか
プロセッサのERRATAなんだろうけど、後に仕様に昇格する大事な機能もあったりすますね。
Z80で正規の命令にも(8080にない)ニブル(４ビット)単位でローテートする命令があったりするのは、内部のALUが４ビット幅であったからだと聞いたことがあります(命令が増えているのに回路規模が変わらないのはマイクロコードをつかたからとも)。
Re: (スコア:0)
Z80でCレジを使ってIO命令を実行すると上位バイトにAレジの値が出るとか
アドレス上位にBレジスタの値が出ることはマニュアルにも記述があった筈。
Z80で正規の命令にも(8080にない)ニブル(４ビット)単位でローテートする命令があったりするのは、内部のALUが４ビット幅であったからだと聞いたことがあります
Z80のRRD/RLD命令って、ALU関係ないんじゃね?
Re:そりゃあれですよ (スコア:2)
>> Z80でCレジを使ってIO命令を実行すると上位バイトにAレジの値が出るとか
> アドレス上位にBレジスタの値が出ることはマニュアルにも記述があった筈。
Cレジ間接では上位アドレスにBレジで、IOポート直接指定ではAレジでした。
（「なんで両方Bレジュじゃねーんだ」と思ったおぼろげな記憶が）
> Z80のRRD/RLD命令って、ALU関係ないんじゃね?
外部から見えるALUでなく、マイクロコードで使用される内部のALUが４ビット幅だって話です。
これを２回廻して１バイトの演算をしているので、４ビット単位のシフトが少ないクロックで実行できる仕組みがあったということ。
Re: (スコア:0)
外部から見えるALUでなく、
外部からALUなんて見えんよ。
Re: (スコア:0)
http://archive.computerhistory.org/resources/text/Oral_History/Zilog_Z... [computerhistory.org]
10ページあたりをどうぞ
Re:そりゃあれですよ (スコア:2)
Re:そりゃあれですよ (スコア:2)
> differentiate Z80 logic from 8080 logic. At first I introduced the pipeline 4-bit ALU.
のあたりですね。
Re: (スコア:0)
ALUがシフト操作をするわけではない
> Fourth internal data bus is placed inside of ALU to be used for not only the 8bit operation,
> but also digit operation, bit operation, rotate operation, and the shift operation with very small number of transistor.
internal data busのほう
Re:そりゃあれですよ (スコア:2)
まさにそうです。
4bitのALUで4bitシフトしたら溢れちゃいますし;-p
Re: (スコア:0)
> Z80でCレジを使ってIO命令を実行すると上位バイトにAレジの値が出るとか
Cレジスタ間接の場合出るのはBレジスタです。
イミディエイトの場合にはAレジスタが出ます。
IX/IYレジスタの上下8bitのレジスタ2本に分けて使える機能はHD64180で正規の命令になりましたね。
Re: (スコア:0)
>i386は自力で仮想記憶をサポートしていますが、68kは68010に外部MMUを追加
386 が出た時って既に 020 リリースされてなかったけ?
Re: (スコア:0)
x86のuopはどんどん高機能化、CISC化しているわけで、RISCに比べ抽象度の高いCISCが優位性を発揮しつつあります
RISCではデータがエフェメラルかどうかわかりませんしね
コード密度の高いCISCはリオーダバッファへの圧力が低いという利点もあります
私見では68kはダメですね
あれは(結果的に)間違った方向に一般性を追求してしまった
Re: (スコア:0)
何をもって優秀とするの？って話が。
この辺の話であーきてくちゃ！って唱えるとろくまんはっせん！って帰ってくるんじゃないかな。
バイナリ互換が重要なのは、ユーザ/ハードベンダーがソースからコンパイルできないからで、それはMSが権利を離さなかったPC-DOSだからで、それは8086ファミリだからで、それはIBMがライセンシーだったからで、それはCP/Mが流行ってたからで、という時代の流れなんじゃないかな？
Re: (スコア:0)
ペケロッパ！ペケロッパ！
アバーッ！
Re: (スコア:0)
no offenceですけど、バイナリ互換が比較的もとめられないビデオゲームコンソール（Wii、プレイステーション3、Xbox 360）ではPowerPC隆盛（だった？）なことから、アーキテクチャの優位性は考えにくいです。
http://ja.wikipedia.org/wiki/PowerPC#.E6.A6.82.E8.A6.81 [wikipedia.org]
# 要はバイナリ互換とセールスの仕方と体力の問題じゃないかな
Re:そりゃあれですよ (スコア:3)
誤解されたようだけど他と比較して優れている優位であるという意味ではないです。
30年近い間にさまざまな改良改変が行われましたが、それでも基礎になったi386は
少なくとも30年は耐えるアーキテクチャとして設計されていたことが実証できているので
そういう意味で優れていたんだな、ということですね。
もし改良してもどうにもならないようなカスなアーキテクチャだったら、いずれかに時点で
より優れたアーキテクチャに置き換わっただろうと思うのですよ。
実際、1985年当時に豪華なMMUが統合されていてRing-0からRing-4までの特権モードを
持ち……という具合に絢爛豪華な仕様を持つCPUだったのは確かで、その豪華さ
が30年の風雪に耐えたってことでしょう。i386のアーキテクトは讃えられていいと思います。
Re:そりゃあれですよ (スコア:2)
おっと訂正Ring-3までですね（4レベルと覚えていたので4と書いてしまった）
Re:そりゃあれですよ (スコア:2)
OSASKのかわいさんならこの辺り熱く語ってくれそう！（今は何やってるんだろ？）
Re: (スコア:0)
30年近い間にさまざまな改良改変が行われましたが、それでも基礎になったi386は少なくとも30年は耐えるアーキテクチャとして設計されていたことが実証できているのでそういう意味で優れていたんだな、ということですね。
ベースデザインがよかったという意味合いにとらえましたけど、よいですかね。
386が長年の魔改造に耐えうる素養を持っていたという事実に関しては100%同意です。
特権モードについて、当時、386のringプロテクションはオーバースペックなんじゃ、、、つか誰が使いこなせるんやろかとかいうのは個人の主観です（念押しですがno offenceです。あんまりよくしらない、というのも本音です。）
私の気持ちの中ではCrusoeみたいなのが派手でカッコいい！！とか思ってますけど、それも別の話ですね。
# 魔改造で思い出したけど、名列車列伝のUp主さまはまだお戻りになられないのだろうか。。。サイコロ途中やし。
Re: (スコア:0)
設計当時はOSというとそういう豪勢な保護機構を持っているもんだったのでそういう作りになっているのです。
今のOSで使い出がない。無駄。というのは後付けの理屈ではあります。
＃UNIXが流行る前の話ですし。
それは異論があるな (スコア:0)
結局こういうのはマシンパワーと値段で決まるコストパフォーマンスの問題。
バイナリ互換はマシンパワーでどうにでもなる事は DEC が Alpha 版 NT の fx!32 で示してくれたけど、Alpha とか Itanium とかのように x86 代替目指してサーバーや HPC 分野では一定の成功を収めつつも代替に失敗してるやつらは、コンシューマより上の価格帯(ここはコストパフォーマンスなんて二の次の分野)先に取りに行ってるのがそもそもの間違いだと思うね。
これは、マシンパワーは十分でもコストが論外だから普及しないってパターン。
バイナリ互換があり価格が安くてもマシンパワーが不足し
Re: (スコア:0)
「バイナリ互換考えないくて良い用途で市場が開けたところに…」という出来事は
科学計算用途でAlphaが勢力を伸ばしたときにも起こりました。
残念ながらAlphaはこけて性能向上がとまってしまったので、その空白地に他のRISCプロセッサ、その後にx86プロセッサがはいってくることになりましたが。
Re: (スコア:0)
残念ながらAlphaはこけて
AlphaがっつーよりDECがな。