コンパイラ言語をコンパイルして出来たマシン語の互換性について

Question

こんにちは。

アセンブラについて調べていたら、機械語はどのようなCPUを使っているか等に強く依存するので互換性が低いということを知ったのですがそれについて疑問な点があったので質問させてください。
###疑問点 1
コンパイルされ機械語になった時点でほかのCPUとの互換性が無くなるのか？

コンパイルされたC言語などの実行ファイルは機械語で出来ておりCPU等に依存するかと思いきや、EXEファイルであればどのCPUを積んだWindwosでも動くので互換性が無くなっているように感じないのですが、最初に書いたように機械語に互換性が無いのであれば動くはずがないということになります。

この質問の答えが「無くなる」だった場合次の質問にお答えください。

###疑問点 2
コンパイルされた"機械語"であれば、なぜEXE等の機械語で配布して動かすことができるんでしょうか？

たとえばSkypeの配布サイトではOSごとにリンクがあるのみで"Intel86はこちら"などのリンクがないのはなぜでしょうか？
ある程度の互換性の無さを超える方法があるのでしょうか？

まだよく機械語についてよくわかっておりませんのでわかりにくい文章になってしまい申し訳ありません。
ご回答お待ちしております。

皆さんとてもわかりやすいご回答ありがとうございました。
ベストアンサーを一人しか決められないのはとても心苦しいのですが、ベストアンサーを決めさせていただきました。

Answer 1

こんにちは。

コンパイルされたC言語などの実行ファイルは機械語で出来ておりCPU等に依存するかと思いきや、EXEファイルであればどのCPUを積んだWindwosでも動くので互換性が無くなっているように感じないのですが

おお、面白い着眼点ですね。

異なるCPUでもソフトウェア的に互換性のあるCPUも存在します。
それは、既存のソフトウェア資産を有効活用することが目的です。
Intelはそれを昔からずっと守り続けることでメジャーの座を維持することに成功したとも言えます。
AMDはインテル互換CPUで、Intelの牙城を一部乗っ取ることに成功しました。

しかし、IBM-PC互換機（今の一般的なPC）のCPUで走るコンパイル済のソフトは、AndroidやiPhoneのCPUでは走りません。そして、スマホは大抵ARM CPUなので、実は出荷数量で考えるとインテル非互換なCPUが大半です。
（スマホの方がPCの出荷台数よりはるかに多いですから。）

たとえばSkypeの配布サイトではOSごとにリンクがあるのみで"Intel86はこちら"などのリンクがないのはなぜでしょうか？

Windowsは事実上Intel86とその互換CPUでしか走ってないからと思います。なのでWindows 10等の表示で十分かと。
また、マシン語にコンパイルされるようなソフトは、一般にOSのAPIと密接に絡むのでOSの指定は必須です。

Androidは様々なCPU上で走っていますので、単にAndroidと言うだけではマシン語へコンパイルされたソフトは走りません。でも、マシン語までコンパイルされていなければ良いわけです。Android用は多くの部分をJavaで書いているだろうと思いますのでマシン語ではないです。マシン語のパワーが必要な部分はAndroidが提供している標準機能を使っているだろうと思います。（他の方法もありますが、そちらは詳しくないので割愛）

Comments

[Kelvin]

Windowsが動くのがIntelとその互換CPUだけだからOSの表記だけでいいんですね。

たしかにAndroidも気になってたんですよ。
各社いろいろ出してますものね。
JAVAを使えば解決、というわけですか。
それがAndroidだけコンパイル型言語を使わない理由なんですね。
納得です。

とても勉強になりました。
ありがとうございます！

[maisumakun]

Androidの場合も大半がARMなので、ARMネイティブコードを含んだアプリもあります。

時折あるx86のAndroidでは、ARMのバイナリが来たときにソフトウェアエミュレーションするものもあります（もちろん、速度は落ちます）。

[Kelvin]

シュミレータで動かすのですか・・・
すごい力技ですね。

[strike1217]

突然すいません。
"異なるCPUでもソフトウェア的に互換性のあるCPUも存在します。"
そうなんですか！
ハードウェアの差分はOSが吸収しているはずです・・・（多分）
exe(windows), elf(linux)は異なるCPUであってもちゃんと動いてますよね〜
で、あるのにセンブリ言語がCPUに強く依存しているというのは、確かに妙ですね・・・
C言語もアセンブリ言語に一旦変換していますし・・・・
Windowsの場合はサポートしているCPUが少ないということですね！
Linuxは20種類くらいのCPUをサポートしているようです

[maisumakun]

Linuxの場合、OS付属のパッケージマネージャで扱うものは別として、多くのソフトウェアが「ソースコードから入れる」形態になっているので、CPUの違いはコンパイル時に吸収できます。

パッケージマネージャでは、アーキテクチャ別にリポジトリがあります。

[Chironian]

> "異なるCPUでもソフトウェア的に互換性のあるCPUも存在します。"
> そうなんですか！

80386以来、iCore-Xの時代になっても互換性確保されてますよ。
AMDもインテル互換CPU作ってますし。

> ハードウェアの差分はOSが吸収しているはずです・・・（多分）

命令体系の異なるCPU相違の吸収はOSの役割ではないです。
Virtual Machineが担うことはあります。有名なところではJava VMでしょう。

> exe(windows), elf(linux)は異なるCPUであってもちゃんと動いてますよね〜

exeやelfは、CPUが異なる場合リビルドしないと通常は動かないですよ。

[scotti]

AndroidもNDKというコンパイル前提の開発環境がありますよ。
難しいので一般的にはJava上で動くアプリが主流ですけど。

昔のWindowsではDEC Alpha という64bit CPU専用のバージョンも出ていました。
OSが差分を吸収して16bit互換モードでも動きましたが、メーカー製ドライバ等ハードウェアを制御するようなものは動きませんでした。

Answer 2

質問1 その通りです。そもそもWindows自体が現在では「x86/x64」版と、ある程度制限のある「ARM版」しかありません。

質問2 Windowsの動くパソコンは、インテルのもAMDのも、x86やx64という同じ命令セットで動かしているから、問題が起きません。

(追記)

その昔は、Windowsもx86意外のプラットフォームで動くバージョンがありました。そして、

当時マイクロソフトはx86以外にItaniumをサポートしていたし、それ以前にはAlpha/MIPS/PowerPCといったさまざまなプロセッサーをサポートしていた。ところが、これらはいずれもバイナリー互換性がなく、折角Windowsプラットフォームを用意しても、ほかのCPUアーキテクチャー用のプログラムが動かないという状況にあった。

（ASCII.jpより引用）

ということで、「いろんなCPUで動くWindowsがあった頃」には、バイナリ非互換でマイクロソフト自身も困っていたとのことです。

Comments

[Kelvin]

質問２について
会社を超えて命令セットを決めているということでよろしいですか？

また、C言語などをコンパイルした時点でx86等の決められた命令セットに従っているのである程度の互換性があるということですか？

何度も聞いてすみません。

[maisumakun]

はい、x86の場合はIntelが作ったのと同じコード体系をAMDなどが採用して互換品を作っていました（その昔には、CPUのソケットまで同じ形で、差し替え可能、なんてこともありました）。

ところが、Intelは自社の思惑があって、64ビットのCPUはx86の拡張ではなく、互換CPUメーカーの振り切りも兼ねて別系統で行くつもりでした。

そんな背景の中でAMDが先に「AMD64」としてx86の64ビット化拡張を発表してしまったために、対抗上やマイクロソフトからの圧力もあって、後追いの形で「Intel 64」として同じ仕様を採用することとなりました（独自の64ビットCPUは生き残ってはいますが、主流にはなれませんでした）。

http://ascii.jp/elem/000/000/470/470600/index-2.html

[Kelvin]

Intelのｘ86をAMDが拡張したのですか！

驚きです。

[maisumakun]

インテル自身がx86の置き換えを狙って新アーキテクチャを3回導入しました（iAPX 432、i960、EPIC）が、どれもこれも置き換えるには至らず、インテル自身すら「互換性」という厚い壁の前に翻弄されている感もあります。