なぜ Intel は x86 を止めることができないのか? 172
ストーリー by reo
そう思われていた時期もありました 部門より
そう思われていた時期もありました 部門より
ある Anonymous Coward 曰く、
タブレットや携帯電話は日常生活に欠かせないものとなりつつある。しかし、Intel の x86 アーキテクチャはタブレットや携帯電話市場では成功を収められなかった。現在では PC 業界の最前線でチップの性能を維持するのに苦労している状態にある。なぜ Intel は 30 年間も x86 アーキテクチャから離れることができなかったのか。実のところ (お年を召した方には常識かもしれないけれども) インテルは少なくとも 3 回は x86 アーキテクチャから離れようとたことがある (ITworld の記事、本家 /. 記事より) 。
1 回目は「Intel iAPX 432」だ。初の 32 ビットプロセッサであり、オブジェクト指向プログラミングをサポートする。インテル自身がマイクロメインフレームと呼ぶほどの先進的なデザインだった。しかし、i286 と同じクロック周波数の場合、iAPX 432 は 4 分の 1 の速度しか出ないほど遅かった。2 回目の挑戦は 1992 年に登場した「i860」。i860 は RISC プロセッサで非常に高速ではあったが、x86 とのソフトウェア互換性がないことから敗退した。3 回目の挑戦が「Itanium アーキテクチャ (IA-64)」。登場時にはほかのチップよりも性能が劣っていた上、AMD が設計した 64 ビット版 x86 アーキテクチャ AMD64 にとどめを刺された。
ITworld の記事ではこうした x86 を引退させる数々の試みは失敗したが、ARM がその終了を手助けするかもしれないとまとめている。
私は4回説を唱えたい!? (スコア:5, 参考になる)
カウントの仕方?は考え方がいろいろあると思いますが、
・Intel iAPX 432
・i860
・IA-64
私的にはこの3つに、もう一つ「XScale」を入れたいところですね。
まぁ~XScaleは、もともとはDECからもらってきたStrongARMなわけですが、
“XScale”という名称にして携帯機器向けに売り込もとした時期が確かにあったわけで…
>ARM がその終了を手助けするかもしれないとまとめている。
実際、いまのARMの勢いを見て、Intelの上層部は何を思っているんでしょうかね。
「XScale、手放さなきゃよかった!」
って、実は内心思ってる??
(AtomでARMを蹴散らせる!と思ったから手放したんでしょうが…)
Re:私は4回説を唱えたい!? (スコア:1)
今 Intel が本気で ARM の CPU 作ったらどのぐらいの物作れるのか見てみたい気が。
それを言うなら80960だって (スコア:1)
大原雄介の「CPU黒歴史」の本にはXScaleも出てきますが、買ってきたXScaleより自社開発した80960 (i960)の方が脱x86の動きとしては大きかったことがその本から読み取れます。この本は買わなくてもWeb連載で大半が読めるんですけどね。
あと、iAPX432は正確にはx86以前、8080の正統な後継という位置づけだったはずです。
Jubilee
そりゃ主犯は Intel 自身でしょ (スコア:5, 興味深い)
最初の iAPX 432 は別にしても、 Itanium に関しては社内抗争、とくにイスラエル部隊の暗躍でぽしゃったわけだし。
当時中の人だったので AC で。
モサドがきたらどうしよう。
x86アーキテクチャから離れる必要がないから (スコア:3)
昔は貧弱なリソースのせいで、命令セットによる性能差は確かに存在してました。
ただ、今日では命令セットによる差なんて微々たるもので、ARMじゃないと性能でないなんてことはありません。
Intel自身にしたって、小面積低消費電力のAtom系とPC向けのCore系で命令セットにはほとんど差がありません。
外から見える命令セットではなく、より下位のマイクロアーキテクチャによっていくらでも作り変えられるので、
x86から離れる必要は全くないでしょう。
それより、Intelのプロセス技術とか回路技術がすごすぎて、アーキテクチャなんて関係なくIntelの覇権が続くんじゃないかと予想しています。
Re:x86アーキテクチャから離れる必要がないから (スコア:2)
Intelがモバイル向けプロセッサで出遅れたのは事実ですが、今年の32nmのZ2500シリーズですでに28nmのARM陣営のプロセッサに消費電力とパフォーマンスで追いついています。
Intelのx86の消費電力が大きいというのは、PC向けのCPUをタブレットに入れようとしていた過渡期の問題であって、すでに過去の話になりつつあります。
Intelの次世代の22nmモバイルプロセッサでは、パフォーマンス/消費電力が大幅に改善すると予測されています。
22nmではFinFETを採用していて、これは低電圧時の動作が大きく改善するからです。
Intelの22nmはすでにPC向けで量産実績も十分にあり、製造上の不安はありません。
対するARM陣営では、28nmの量産化に成功しているのが現状TSMCしかなく、製造キャパを確保するのすら困難な状況。
次の20nmが順調に立ち上がるかどうかも未知数です。
その上、20nmが立ち上がったとしても、FinFETを採用していないためモバイル用途で不利。
現状ではQualcomm一人勝ち状態なモバイルプロセッサですが、Intelが今後シェアを増やすことは確実でしょう。
Re:x86アーキテクチャから離れる必要がないから (スコア:1)
x86は命令が可変長で、命令の区切りは先頭からデコードしてみないとわからないという特徴があります
複数命令同時デコードというのはつまるところ総当たりでデコードしてみて正しい結果だけ利用するということになります
(実際はデコードに複数サイクルかけたり、並列にデコードできる組み合わせを制限したりしていますが)
命令デコーダーは非常にビジーなユニットで、かつ結果をほとんど捨ててしまうので、電力的に大きな損失になります
また、同時デコード数を増やすと回路規模は組み合わせ論的に増えていきます
そりゃあれですよ (スコア:2)
直接的には、それだけバイナリ互換が重要だったからなんだけれども
386のアーキテクチャ設計が非常に優秀だったからってのがあるでしょう。
で、ARMがx86を殺すかどうかなんとも言えないと思うけどな。
Re:そりゃあれですよ (スコア:3, すばらしい洞察)
AMD64をx86に含むのであれば、
の少なくとも一つは成立しないと無理なのではないでしょうか?
一番ありそうなのは最後ですが、少なくとも現状のタブレットは見る側ならともかく何かを作るにはいろいろ足りなくて、
それを補うためにキーボードなどを追加していくと、ソフトウェア資産が乏しく自由度の低い、ただの一体型PC(タッチパネル付き)に過ぎなくなってしまう、という……。
ジョブズ無き今、アップル含めてタブレットの概念をもう一段昇華させ、PCを駆逐できるレベルにできる会社が存在しない気がします。
このままだと、Thinkpad Tablet2 [ascii.jp]みたいな、タブレットになるノートPC、という感じに吸収されてしまうのがオチじゃないかな?消費者は全部載せが好きですし。
Re:そりゃあれですよ (スコア:3)
誤解されたようだけど他と比較して優れている優位であるという意味ではないです。
30年近い間にさまざまな改良改変が行われましたが、それでも基礎になったi386は
少なくとも30年は耐えるアーキテクチャとして設計されていたことが実証できているので
そういう意味で優れていたんだな、ということですね。
もし改良してもどうにもならないようなカスなアーキテクチャだったら、いずれかに時点で
より優れたアーキテクチャに置き換わっただろうと思うのですよ。
実際、1985年当時に豪華なMMUが統合されていてRing-0からRing-4までの特権モードを
持ち……という具合に絢爛豪華な仕様を持つCPUだったのは確かで、その豪華さ
が30年の風雪に耐えたってことでしょう。i386のアーキテクトは讃えられていいと思います。
Re:そりゃあれですよ (スコア:2)
おっと訂正Ring-3までですね(4レベルと覚えていたので4と書いてしまった)
Re:そりゃあれですよ (スコア:2)
OSASKのかわいさんならこの辺り熱く語ってくれそう!(今は何やってるんだろ?)
Re:そりゃあれですよ (スコア:2)
> 私はi386より68Kの方が優秀だったと思う。
i386比でなら68kは善戦していますが、最短命令が1ワード(2バイト)と言うのは、i386の最短命令長1バイトと比べてメモリ貧乏だった当時はコード密度の点で厳しかったです。
また、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:そりゃあれですよ (スコア:1)
486の場合、「プリフェチキューが長くなった」「命令コードがプリフェッチキューに入ったあとでメモリを書き換えても、キュー内の命令コードには反映されない」ということで、自己書き換え系のコードが結構動かなくなりましたね。
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:そりゃあれですよ (スコア:2)
16bitセレクタ・32bitオフセットですよね。
メモリマップドファイルは妨げていなかったと思います(結局フラットモデルに落ちつくんですが)。
そうそう、セグメントレジスタをテンポラリレジスタに使っていたコードが激遅になった記憶があります。
Re:そりゃあれですよ (スコア:2)
Re:そりゃあれですよ (スコア:2)
実際010までは上位8ビットはアドレスバスにでませんでしたしね。
そこでポインタの上位バイトに参照先のオブジェクトを表すコードを埋め込む(貧乏)テクニックがありました。
初期のMacintoshはまさにこれで、お陰で32bitクリーンなポインタかが32bit化で問題になったり。
Re:そりゃあれですよ (スコア:2)
Z80でCレジを使ってIO命令を実行すると上位バイトにAレジの値が出るとか
286でHIMEMにアクセスできてしまうパターンが有るとか
プロセッサのERRATAなんだろうけど、後に仕様に昇格する大事な機能もあったりすますね。
Z80で正規の命令にも(8080にない)ニブル(4ビット)単位でローテートする命令があったりするのは、内部のALUが4ビット幅であったからだと聞いたことがあります(命令が増えているのに回路規模が変わらないのはマイクロコードをつかたからとも)。
Re:そりゃあれですよ (スコア:2)
>> Z80でCレジを使ってIO命令を実行すると上位バイトにAレジの値が出るとか
> アドレス上位にBレジスタの値が出ることはマニュアルにも記述があった筈。
Cレジ間接では上位アドレスにBレジで、IOポート直接指定ではAレジでした。
(「なんで両方Bレジュじゃねーんだ」と思ったおぼろげな記憶が)
> Z80のRRD/RLD命令って、ALU関係ないんじゃね?
外部から見えるALUでなく、マイクロコードで使用される内部のALUが4ビット幅だって話です。
これを2回廻して1バイトの演算をしているので、4ビット単位のシフトが少ないクロックで実行できる仕組みがあったということ。
Re:そりゃあれですよ (スコア:2)
Re:そりゃあれですよ (スコア:2)
> differentiate Z80 logic from 8080 logic. At first I introduced the pipeline 4-bit ALU.
のあたりですね。
Re:そりゃあれですよ (スコア:2)
まさにそうです。
4bitのALUで4bitシフトしたら溢れちゃいますし;-p
市場が決めただけだから (スコア:2)
これの出来具合と,普及具合ではx86アーキテクチャを引退させることができるかもね,というところ。
いまのARMのままじゃ世迷い言ですわな。
Re:市場が決めただけだから (スコア:3)
> ARM64自体が従来のARMとの互換性に足を引っ張られているアーキテクチャなわけで、x86と同じ運命を辿っているだけかと……。
ARMv8はARMv7互換のAArch32と全く新規にデザインされたAArch64の2つのモードを持っています(V30が8080互換モード持ってているのと似ていますね)。
シリコンのフットプリント的にはARMv7互換に割かれている部分を以って「互換性に足を引っ張られている」と言えなくもないですが、命令セットはAArch64は命令フォーマットもレジスタセットもAArch32と非互換、ARMのアイデンティティとも言える「全命令がコンディションコードで実行/非実行を制御できる」と言う特徴まで捨てています(悪い言い方をすれば平凡な64bitプロセッサ)。
現物を見るまでは判りませんが、少なくともx86に対するx64よりは数段いい作りに見えます。
Re:市場が決めただけだから (スコア:2)
他のレスにもあるけど、ARMといえば条件付き命令なので、それがなくなると
「こんなのARMじゃないやい」って感じしますよね
やめられないとまらない (スコア:2)
> i860 は RISC プロセッサで非常に高速ではあったが、x86 とのソフトウェア互換性がないことから敗退した。
結局のところはこれ。いいCPUを作っても互換性がないと普及しない。
Intelは新しいアーキテクチャに生きたいんだろうけど、それを市場が許さないんだよね。
しかも今x86やめてもAMDがそのままシェア奪ってくだけ。
ARMが取って代わるかどうかもソフト次第で、実際のところはMS次第じゃないかな。
スルースキル:Lv2
Keep It Simple, Stupid!
主要だからじゃないよ。 (スコア:1)
他のプレイヤーは他のCPUに乗り換えられるでしょ。
Intelが簡単に切り捨てられなさそうで、最後まで残りそうなのがMSって事。
例えば、Linuxその他はとうの昔に他のCPUに対応してるし、AppleなんかPowerPCの時にやったようにやれるでしょ。
MSも今後そうなってくるとは思うけど、現状ではWin8とRTを分けてる事から、まだ時間かかりそう。
あと、Intelも現行ほとんどのOSに対応しているのに何を方向転換するん?
Midori Linux作ってMS牽制してみたり、なんて昔からしてるけど。
お互い他社にべったり依存するのがビジネス上危険だと言うことは十分理解してると思う。
スルースキル:Lv2
Keep It Simple, Stupid!
Re:主要だからじゃないよ。 (スコア:1)
ごめん足りなかった。
PCがメインストリームでなくなるのはその通りだけど、だからといって無くなったりもしない。
一定の規模を保って残るだろうから、x86もなくせない。
最終的にそれが得になるかどうかはべつだけど、だからIntelが「やめられない」んだと思う。
Intel自体は何度もトライしてることから解るように変えたがってるとは思うけどね。
# 逆に言えばPC分野だけだと思う。「やめられない」事の理由になるのは。
# モバイルなんかシェアとれてないし既存資産ないんだから別に新しいの投入してもいいわけで。
スルースキル:Lv2
Keep It Simple, Stupid!
Re:主要だからじゃないよ。 (スコア:1)
WindowsNTが、x86 MIPS PowerPC Alpha それぞれで動いていたことを知らない若者が増えてきたということかなぁ
Re:主要だからじゃないよ。 (スコア:1)
そうでした。ごめんなさい。
CPUメーカーのLinuxということでマスコットキャラと名前のインパクトで塗り替えられてました。
危うくLinusがIntelに一時期雇われてたと脳内で書き換えるところでした。
Moblinだっけ?
スルースキル:Lv2
Keep It Simple, Stupid!
Re:やめられないとまらない (スコア:1)
いや、その路線はすでにXScaleなんかでやってたでしょ。
むしろARMなXScale捨てて1から作り直して出てきたモノがx86って時点で
x86に回帰しちゃってますが。このあたりがやめられないと言うことなんでしょうね。
スルースキル:Lv2
Keep It Simple, Stupid!
Re:やめられないとまらない (スコア:1)
同意。
元々書いてて削ったんだけど、ネイティブアプリがネックになると思う。
でもこれも十分な開発環境を用意すれば何とかなるかなという気もする。
スルースキル:Lv2
Keep It Simple, Stupid!
Re:やめられないとまらない (スコア:1)
良いか悪いか、とか不満があるかどうかなんて言ってないですよ。
「Intel(自身)がx86から(何度かアーキテクチャを変えようとしているのに)変えられないのはなぜか」
という問いに「市場が望んでないから」と返しただけ。
市場がなぜ望まないかと言えば、まさにおっしゃるとおりだと思います。
ただ、個人的にはItaniumに期待してたんですよねぇ。
コンパイル時に解決できるアウトオブオーダーとかオペランドの組み合わせとかはコンパイラに任せて、
実行時に必要なことだけをやるシンプルで機能的なCPU、未来がありそうで良さそうに聞こえるじゃないですか。
最初はダメダメだったけど、古いアーキテクチャで培ったノウハウを反映した最新アーキテクチャでどんどん
良くなるかと思ってたのに。。。のに。
# まぁ、でもコンパイラ依存するのにアーキテクチャ変える必要も無いですね。
まさに「コンパイラの成長でプロセッサの見た目や中身なんてユーザーがいちいち気にすることではなくなった」ので、
インテルが優秀なコンパイラを用意して、x86からIA64に移行できる予定だったんですけどね。
新しもの好きとしてはガッカリした思い出が。
ただ、補足させてもらうならItaniumが出てきた頃はPen4の多段パイプラインで稼いだ動作周波数が
極限まできて消費電力や動作周波数のこれ以上の向上が望めない状況だったので、アーキテクチャ
の変更が必須で、ついでにいろいろ新しくするタイミングではあったんでしょう。
ま、その後Coreがやってきて打破してってくれるわけですが。
スルースキル:Lv2
Keep It Simple, Stupid!
Re:やめられないとまらない (スコア:2)
それをハードウェアでやったのがトランスメタのクルーソーですね。
低消費電力にかけてはピカイチでしたが、実効速度が遅かったのと、
x86の低電圧モデルに蹴落とされフェードアウトしてしまいました。
ソフトウェア的にはConnectixのVPC(PPC Mac用のx86エミュ)とかBochsとかでしょうか。
実行速度的にエミュレーションを実行するハードは元ハードの数倍の性能が必要になりますが、
x86の数倍の性能を持ち開発者が集まるほど普及が進んだアーキテクチャが存在しないだけでしょう。
ARMで作業したことあるかい? (スコア:1)
ARMのマシンでソフト開発とかやったことある人はどれだけいるかな。
ディストロのセルフコンパイルとかやってみるといい。普段使ってるx86のプロセッサと現在のARMの差がわかるよ。
性能を上げていくためにはx86と同じ道を歩むことになると思うな。
Re:どっちかというと (スコア:2)
Windows NT は SPARC 版とか Power PC 版とかもありましたよね
Re:どっちかというと (スコア:3, 興味深い)
> Windows NT は SPARC 版とか Power PC 版とかもありましたよね
OSは動いても、その上で動くアプリが無い、という問題がありましたね。
その点では、そこはDECのAlpha版を挙げとかないとダメでしょう。
Alpha版NTには、FX!32 というWin32エミュレータ(というかJITトランスレータ)がありました。
Allphaネイティブで動かすよりは遅くなりますが、それでもPentium(200MHzぐらい)上でWin32をネイティブで動かすよりも、Alpha(500MHz)のFX!32上で動かした方が高速に動作するものも結構あったという…
結局、「アプリが多いので、x86/Windowsが流行る」→「x86/Windowsが流行ってるので、アプリが増える」→「アプリが多いので、x86/Windowsが流行る」というループに入っているのが大きくて、x86以外のWindows NT は廃れちゃった。
Windowsが別のCPU上で動いたってあんまり意味がないというのは、そのうちもう一度 Windows RT が証明してくれるんじゃないかなぁ…
Re:どっちかというと (スコア:1)
Alpha版NTには、FX!32 というWin32エミュレータ(というかJITトランスレータ)がありました。
NTなんでWin32はネイティブであるでしょ…
FX!32はたしか「バイナリトランスレータ」と言っていました。SymantecあたりがJavaのJITコンパイラを出しはじめたころだと思います。
AppleのRosetta(開発元はなぜかIBMに買収された)も同種の技術でしたっけ?
Re:どっちかというと (スコア:1)
Re:どっちかというと (スコア:1)
TIMI [wikipedia.org]はそれだけ先進的だったと云う事なんでしょう。
最初のWindowsNT(3.1)が出たのが1993年で、その頃はVisual C++ 1.0が出る前あたりですから、マイクロソフト社内にも、TIMIの様なものを支える技術的蓄積は無かったのかも
(マイクロソフト版TIMIと云えなくもない.NET Frameworkのpre-betaは2000年だそうですね)。
Re:どっちかというと (スコア:1)
互換性を捨てると誰もついてこないというへぼさなので、信者とかよばれている人のたくさんいるMacはへぼくなかったんでしょう
Re:ガワと中身 (スコア:1)
市場での優位性という意味では、Appleがあっさり乗り換えに成功したように、何が何でも維持しないとダメという話でもなかった。けど、x86からの乗り換える理由も特になかった。
性能向上という点では、内部アーキテクチャを切り離すという技が出てきたのが大きい。 互換性の維持はいくらかの足枷になってただろうとはいえ、最大市場向けの開発リソースの前では誤差の範囲になっちゃった。
だれか説明してやって! (スコア:3)
>0xF4
↑8086のCPU停止命令(いわゆるHALT)の16進数コード
ちなみにニモニック表記は“HLT”
Re:x86なら俺が止めてやる (スコア:3)
ちょっと割り込みますよ。