アカウント名:
パスワード:
前に読んだ記事だとWindowsのDLLがARM系命令に変換（？）してるだけでx86エミュレートはしてないって書いてあったような気が…
間違っててもいいのでもっと詳しく。DLL、変換、エミュレートを同列に並べておまけに三点リーダで濁すとかイライラする
ハード詳しくないので読んだ記事紹介でカ勘弁して下さい読んだのはこの記事でしたhttp://ascii.jp/elem/000/001/596/1596735/ [ascii.jp]
上の記事だとWindowsDLL使わないと動かないｘ86バイナリが動かないからエミュレートと言って良いのかなーと思った次第
解説有り難う御座います。
WindowsのDLL形式に縛られているように見えたのでエミュレートというよりwin32api実行環境じゃないかと思ったのですがエミュレートと言って差し支えないんですね
「WindowsのDLL形式に縛られている」ように見えるのは、Windows はエミュレーションも含めたOSのすべての機能がDLLで提供されているってだけの話です。
ARMとx86ではアーキテクチャがまったく異なるんですから、エミュレーション無しにはx86コードの実行はできません。エミュレートするのは大前提で、ARMコード実行と、x86コード実行の境目の問題として、
・ユーザーコードのみエミュレーションし、OS側のすべてのAPIをネイティブで動作させる方法→ネイティブで実行する割合が増えるのでコード実行速度は上がるが、APIのパラメータ変換のオーバーヘッドがある。
・APIを提供するOS側システムコードもエミュレーションし、その核にある部分だけネイティブで動作させる方法→エミュレーション実行の割合が増えるのでコード実行速度は落ちるが、パラメータ変換の頻度が下がるためそこのオーバーヘッドは減る
という二つの方向性のトレードオフの中で、ARM版WindowsのWin32プログラム実行は、後者の方法を選んでいる(32bit Windows の基本DLLもエミュレーション実行する)ってことです。
32bit環境と64bit環境では(メモリ空間そのものが異なるので)API変換はオーバーヘッドが大きい、Windows の「マイクロカーネル」という構造が、「核にある部分だけネイティブで動作させる」って方法をとりやすい、後者の方が互換性を高めやすい、など後者の方法が有利だったのでしょう。
x64コードのARM64エミュレーションだと、API変換のオーバーヘッドが少ないので、もしかしたらそっちは前者の方向で実現するかもしれません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
86エミュレート？ (スコア:0)
前に読んだ記事だとWindowsのDLLがARM系命令に変換（？）してるだけで
x86エミュレートはしてないって書いてあったような気が…
Re: (スコア:0)
間違っててもいいのでもっと詳しく。
DLL、変換、エミュレートを同列に並べておまけに三点リーダで濁すとかイライラする
Re:86エミュレート？ (スコア:0)
ハード詳しくないので読んだ記事紹介でカ勘弁して下さい
読んだのはこの記事でした
http://ascii.jp/elem/000/001/596/1596735/ [ascii.jp]
上の記事だとWindowsDLL使わないと動かない
ｘ86バイナリが動かないからエミュレートと言って良いのかなーと思った次第
Re:86エミュレート？ (スコア:1)
むしろ、DLLもx86バイナリのままで、エミュレーションによって実行する、但し一部はCHPE形式でx86とARMの両方のバイナリで提供される、というように読めます。
Re: (スコア:0)
解説有り難う御座います。
WindowsのDLL形式に縛られているように見えたので
エミュレートというよりwin32api実行環境じゃないかと思ったのですが
エミュレートと言って差し支えないんですね
Re:86エミュレート？ (スコア:1)
「WindowsのDLL形式に縛られている」ように見えるのは、Windows はエミュレーションも含めたOSのすべての機能がDLLで提供されているってだけの話です。
ARMとx86ではアーキテクチャがまったく異なるんですから、エミュレーション無しにはx86コードの実行はできません。エミュレートするのは大前提で、ARMコード実行と、x86コード実行の境目の問題として、
・ユーザーコードのみエミュレーションし、OS側のすべてのAPIをネイティブで動作させる方法
→ネイティブで実行する割合が増えるのでコード実行速度は上がるが、APIのパラメータ変換のオーバーヘッドがある。
・APIを提供するOS側システムコードもエミュレーションし、その核にある部分だけネイティブで動作させる方法
→エミュレーション実行の割合が増えるのでコード実行速度は落ちるが、パラメータ変換の頻度が下がるためそこのオーバーヘッドは減る
という二つの方向性のトレードオフの中で、ARM版WindowsのWin32プログラム実行は、後者の方法を選んでいる(32bit Windows の基本DLLもエミュレーション実行する)ってことです。
32bit環境と64bit環境では(メモリ空間そのものが異なるので)API変換はオーバーヘッドが大きい、
Windows の「マイクロカーネル」という構造が、「核にある部分だけネイティブで動作させる」って方法をとりやすい、
後者の方が互換性を高めやすい、など後者の方法が有利だったのでしょう。
x64コードのARM64エミュレーションだと、API変換のオーバーヘッドが少ないので、もしかしたらそっちは前者の方向で実現するかもしれません。