アカウント名:
パスワード:
Microsoftが新しい命令のサポートに失敗しただけじゃないの?
CPUか、それともOSか、どちらのバグだ?
OSのバグにしておいたほうが対応が楽で良いと思う。CPUにバグがあったとして昔のPenguinみたいに交換対応はしてくれないだろうしノートだと交換すら出来ないのだから。
今はマイクロコード書き換えるだけだよ。今のCPUはインタプリタだよ。
後付けのマイクロコードによる更新はデコーダーに対して対象命令のフックを仕掛け、フックの実行内容としてマイクロコードで定義した新しい処理に置き換えるもので、「今のCPUはインタプリタだよ。」というのは誤りです。直接内部命令に変換できるものはマイクロコードの助けなく実行されます。命令の実行を完全にマイクロコードに頼っていたのは80386までで、それ以降はできる限りハードウェア実行をしています。そうでなければ現在の速度は出せません。よくマイクロコードと内部命令を混同している方もいらっしゃいますが、これらは別のものです。この点の理解は重要です。
また、仕組み上デコーダーを経由するものに後から手を入れることができるパッチ機構なので、それ以外の付随ユニットに問題が生じているケースは対応不可です。 例えば#4304847 [srad.jp]が挙げているIntel TSXとAMD TLBの件はどちらもキャッシュに関する部分であり、デコーダーに手を入れるマイクロコードの更新では修正しえなかったわけです。このため不具合の回避のためには該当機能を無効にする必要がありました。
過去にはIntelのTSX命令とかAMDのTLBのようなケースもあるので、何でもかんでも後から直せるわけではねぇべ。
もしマイクロコードでOSとかアプリを書いたら、めちゃくちゃ速いのができるんだろうか?
ペンギンがどうしたんだっけ?
DelphiはPentium FDIVバグ対応のコンパイラスイッチとシステム変数あった記憶が
・FDIV命令を使う・FDIV命令を使わない(ライブラリで代替する=パフォーマンスは落ちる)・FDIV命令をテストして正常なら使う、異常なら使わない
で、システム変数は 正常(バグなし)・バグあり・未テスト のいずれかの値を取る
そんな根回しや何やら必要で、後でバレて(というかほぼバレる)炎上するリスクを背負ってまでやらねーよ。素直に事実に基づいた発表と対応したほうが後々まで楽だしコストもかからない。
で、話をつけたつもりになってたらLinux方面から刺されると
それそれ。組み込みとかでハードウェア系の不具合をソフトウェアでカバーするというパターン。 元々歴史のあるハードウェア系の方が政治力が強いし、ハードウェア系は改修に時間やコストがかかるという口実もある。
あと、
古くは8080の時から。NECはデッドコピーのついでに命令のデバッグしたんだけど、それじゃソフトの互換性の問題が出たんで、後からフルコンパチのFバージョン(FULL COMPATI.)を出した。
つーか、早く出して先に普及したほうが勝ちなんだよね。よほどひどくない限り。
NECはインテルのセカンドソーサーでデッドコピーではない。デバッグではなく、減算命令の後でもDAA命令が使えるようにフラグを追加した。オリジナルでは0に固定されていたフィールドだが、PUSH AFでスタックに書き出せるので、非互換が生じる。
別ACですが、「【大河原克行の「パソコン業界、東奔西走」】ビル・ゲイツとの密会、サードパーティ戦略。いま振り返る「PC-8001」成功物語 - PC Watch [impress.co.jp]」という記事を読む限り、Intel 8080互換製品(いわゆる相当品)についてはセカンド ソーサーとして出したものではなさそうです。
かつてNECは、Intel 8080を徹底的に解析して、CPUを開発していた。当時は、知的財産権についてもおおらかで、NECもIntel互換CPUを開発していたのである。
NECが「〇〇相当品」として出しているのは全部のこの手のものなのかもしれません。Z80もセカンド ソースじゃないとこのサイトで以前に指摘が上がっていましたし。
そうですね。だからμPD780なんてぱっと見Z80互換品とわかりにくい型番でしたし。 因みに正式にセカンドソースだったシャープは、シャープの型番(LH0080)とZ80CPUが併記されてました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
ただのバグでは (スコア:0)
Microsoftが新しい命令のサポートに失敗しただけじゃないの?
Re: (スコア:0)
CPUか、それともOSか、どちらのバグだ?
Re:ただのバグでは (スコア:0)
OSのバグにしておいたほうが対応が楽で良いと思う。
CPUにバグがあったとして昔のPenguinみたいに交換対応はしてくれないだろうしノートだと交換すら出来ないのだから。
Re: (スコア:0)
今はマイクロコード書き換えるだけだよ。今のCPUはインタプリタだよ。
Re: Re:ただのバグでは (スコア:1)
後付けのマイクロコードによる更新はデコーダーに対して対象命令のフックを仕掛け、フックの実行内容としてマイクロコードで定義した新しい処理に置き換えるもので、「今のCPUはインタプリタだよ。」というのは誤りです。直接内部命令に変換できるものはマイクロコードの助けなく実行されます。命令の実行を完全にマイクロコードに頼っていたのは80386までで、それ以降はできる限りハードウェア実行をしています。そうでなければ現在の速度は出せません。よくマイクロコードと内部命令を混同している方もいらっしゃいますが、これらは別のものです。この点の理解は重要です。
また、仕組み上デコーダーを経由するものに後から手を入れることができるパッチ機構なので、それ以外の付随ユニットに問題が生じているケースは対応不可です。 例えば#4304847 [srad.jp]が挙げているIntel TSXとAMD TLBの件はどちらもキャッシュに関する部分であり、デコーダーに手を入れるマイクロコードの更新では修正しえなかったわけです。このため不具合の回避のためには該当機能を無効にする必要がありました。
Re: (スコア:0)
過去にはIntelのTSX命令とかAMDのTLBのようなケースもあるので、何でもかんでも後から直せるわけではねぇべ。
Re: (スコア:0)
もしマイクロコードでOSとかアプリを書いたら、めちゃくちゃ速いのができるんだろうか?
Re: (スコア:0)
ペンギンがどうしたんだっけ?
Re: (スコア:0)
DelphiはPentium FDIVバグ対応のコンパイラスイッチとシステム変数あった記憶が
・FDIV命令を使う
・FDIV命令を使わない(ライブラリで代替する=パフォーマンスは落ちる)
・FDIV命令をテストして正常なら使う、異常なら使わない
で、システム変数は 正常(バグなし)・バグあり・未テスト のいずれかの値を取る
Re: (スコア:0)
そんな根回しや何やら必要で、後でバレて(というかほぼバレる)炎上するリスクを背負ってまでやらねーよ。
素直に事実に基づいた発表と対応したほうが後々まで楽だしコストもかからない。
Re: (スコア:0)
で、話をつけたつもりになってたらLinux方面から刺されると
Re: (スコア:0)
それそれ。組み込みとかでハードウェア系の不具合をソフトウェアでカバーするというパターン。 元々歴史のあるハードウェア系の方が政治力が強いし、ハードウェア系は改修に時間やコストがかかるという口実もある。
あと、
Re: (スコア:0)
古くは8080の時から。
NECはデッドコピーのついでに命令のデバッグしたんだけど、
それじゃソフトの互換性の問題が出たんで、
後からフルコンパチのFバージョン(FULL COMPATI.)を出した。
つーか、早く出して先に普及したほうが
勝ちなんだよね。よほどひどくない限り。
Re: (スコア:0)
NECはインテルのセカンドソーサーでデッドコピーではない。
デバッグではなく、減算命令の後でもDAA命令が使えるようにフラグを追加した。オリジナルでは0に固定されていたフィールドだが、PUSH AFでスタックに書き出せるので、非互換が生じる。
Re: (スコア:0)
別ACですが、「【大河原克行の「パソコン業界、東奔西走」】ビル・ゲイツとの密会、サードパーティ戦略。いま振り返る「PC-8001」成功物語 - PC Watch [impress.co.jp]」という記事を読む限り、Intel 8080互換製品(いわゆる相当品)についてはセカンド ソーサーとして出したものではなさそうです。
NECが「〇〇相当品」として出しているのは全部のこの手のものなのかもしれません。Z80もセカンド ソースじゃないとこのサイトで以前に指摘が上がっていましたし。
Re: (スコア:0)
そうですね。だからμPD780なんてぱっと見Z80互換品とわかりにくい型番でしたし。 因みに正式にセカンドソースだったシャープは、シャープの型番(LH0080)とZ80CPUが併記されてました。