アカウント名:
パスワード:
前に読んだ記事だとWindowsのDLLがARM系命令に変換（？）してるだけでx86エミュレートはしてないって書いてあったような気が…
MS自身の大本営発表で実際には開発は遅れに遅れ当初のスケジュールも守れていない、現時点では汎用x86バイナリを試用者に自由にインストールさせ動かしてみせることも禁止しなければならないWindowsRTと何ら変わらないような状況と前置きした上で
MS自身がエミュレーションと明確に説明してるhttps://news.mynavi.jp/article/20170522-windows10report/ [mynavi.jp]
間違っててもいいのでもっと詳しく。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変換のオーバーヘッドが少ないので、もしかしたらそっちは前者の方向で実現するかもしれません。
> WindowsのDLLがARM系命令に変換（？）してるだけで
それだとそもそもx86バイナリが走らないので意味ないのでは。それともARM命令セット向けのバイナリを起こすコンパイラでコンパイルする事を前提に考えてます？だとすると既存のx86バイナリは動かないのでうたってる内容と合わない。よってエミュレータが(バイナリ読んで)走ってるで間違いないと思います。
命令変換してディスク上にキャッシュするとも言ってるよエミュレートしてないとは言ってないし、両者は排他ではないhttps://channel9.msdn.com/Events/Build/2017/P4171 [msdn.com]6:25付近
ｘ86Win32エミュかーそう言われると納得できる
Microsoft製のライブラリはエミュレーションしないと思うよ。多分Windowsというかマイクロソフトが提供するライブラリ関係はWOW64と同様の手法になってるとおもう。要するにwin32のABIで呼び出せるが実際に呼び出されるのはARMのライブラリ。ライブラリから戻ってくるデータはwin32のABI。
しかしなんでこのタイミングでwin32なんだろうね。64ビットの方は特許がらみで何かあるとか？
> しかしなんでこのタイミングでwin32なんだろうね。> 64ビットの方は特許がらみで何かあるとか？
それもMS公式の情報が出てて、単純に開発が間に合わないからx64は後回しにしてるってだけの話一般ユーザの使うバイナリのうちx64バイナリは19%くらいしかないから、そんなの使えなくてもなんとかなるだろうという主張当たり前だけどそんなわけねーだろ、必要なアプリが一つでも使えなかったらもう駄目なんだから最初からカワネーヨというツッコミの嵐
https://pc.watch.impress.co.jp/docs/column/ubiq/1095498.html [impress.co.jp]
…atomってx64バージョンあったっけ…？32ビットの方でもそれなりには売れてた気が…。
> …atomってx64バージョンあったっけ…？
普通に64bit版Winを採用したAtomPCなんていくらでもあるが何を言っているんだ
ARM信者の無知っぷりは底なしか
ネットでも市場でもAtom機で32bit搭載型探す方が大変苦労すると思いますよ
ごめん。最初は32bit版Connected Standbyのみの対応だったせいかすっかり間違って記憶してた…。手持ちのatomタブレット(今も現役)が丁度その頃の製品だったし…。
https://ja.wikipedia.org/wiki/Intel_Atom [wikipedia.org]こいつを見てくれ、どう思う?
64ビットバイナリ走るようになったら結構魅力的だと思うけどな。あとはドライバか。一年くらいは様子見ってとこかな。
> 64ビットバイナリ走るようになったら結構魅力的だと思うけどな。
64bit向けのエミュレーション実装をまた別に書かなきゃいけないので、32bit向け実装を作ったのと同じくらいのコストがかかるけどなしかもその後のメンテコストも32bitと64bitでそれぞれかかり続ける
はっきり言って商売として成立するとも思えない
> あとはドライバか。
なおさら無理
> 一年くらいは様子見ってとこかな。
64bitエミュレーション実装を実用レベルにするのは1年じゃ無理かといって2年たつとRISC-Vのほうが花開いているだろうし、行くも地獄戻るも地獄だな
なんでそんなにRISC-Vが好きなのか理解できんな。万が一うまくいっても今のARMを巡る状況とほとんど変わらんぞ。
x86・x64からARMへ移行しようとすると各種互換性問題でそれだけ大変になるのなら、あと2年程度の期間でRISC-Vへの移行がそんなに進むものなの…？
RISC-Vは命令セットを好きに拡張・改変できるのでスパコン業界からの熱視線を浴びているのが事実ARMのスパコン進出の強敵になりそうだコンシューマーへの影響はわからない
> x86・x64からARMへ移行しようとすると各種互換性問題でそれだけ大変になるのなら、> あと2年程度の期間でRISC-Vへの移行がそんなに進むものなの…？
方向性は2つあって、ほぼ確実に前者になるだろう
・x86/x64バイナリはやはり強く、それを軽量モバイル端末上でエミュレーション実行するのは開発面でも負荷の面でも無理 -> 今のARM版Winは死亡確定、大きく機能を縮退したWindowsRTに毛の生えた程度の内容に変更して細々と生き残る -> そのくらいしかやらない前提にするなら、ARMなんて捨ててRISC-Vでいいね
・UWPアプリが花開き、一般市場でx86/x64バイナリの需要がなくなる。それによりARM版Winが市場で受け入れられる -> じゃあARMなんて捨ててRISC-Vでいいね
どっちにせよARMからRISC-Vに変化していくのは避けられない
後者は知らんが、前者なら細々と生き残っているものにわざわざRISC-V版を開発するコストをかけられないんでないかい？
一応将来のアップデート(ちょっと先のアップデート)で対応するとは言っている。スケジュールどおりに進むかは不明。X64版オンリーのソフトは大容量メモリを活用するヘビーなソフトが多いのでこのての端末には不向き。故に後回しでも問題ない。というのは戦略上多分正しい。
まあビジネス向けなら未だに32ビット版OSを指名買いするような所も多いからね。当然その手のユーザーはそれで困って居ないって事だし。
そしてそんな保守的なビジネス層がARM版Windowsなんて絶対に選ぶわけ無いからね
それがいきなりiPadガーとか言い出したりするんだけどね。保守的だろうが革新的だろうが判断の閾値が異なるだけで、基本的には仕様機器なんぞ経年で変化するって事位は知って居るものだよ。でもって、「世の中Linuxでデスクトップを」ってのが通る如く、この手のも閾値を超える事はままあるんだわ。
なるほど、馬鹿な奴がまともな考えもなしにARM版Windowsに飛びついて大失敗するってことだねほんとそのとおりだ
WOW64をARMにそのまま乗っけたような形ではないでしょうか。だから32bitアプリ限定と。
電池の持ちもCPU性能もAtomよりちょっとよいくらい、MMCよりUFSでアプリ起動は多少期待できそう、その分価格は出始めの頃のAtomのタブレットよりやや高め（最初は6，7万してましたよね）と、まあAtomタブレットの後継機としては悪くないのかもしれません。
ただ問題は最近64bit専用アプリも結構増えてるということですが･･
これで8-9インチくらいの2in1に仕立ててくれればT90Chiの後継機としてちょっと興味が出てくるのですが。
#GPD Pocketだとちょっと微妙
> その分価格は出始めの頃のAtomのタブレットよりやや高め（最初は6，7万してましたよね）と、
ベイトレAtomタブレット普及の際に話題になったMiix2は当時ですでに4万円程度だったので、あなたの記憶は相当間違っていますね
ARM版Win製品がまともに市場で受けられるようにするには、日本国内での新品価格、当然回線抱き合わせなどなしで3万円～4万円が限界でしょう
599ドルスタート（日本価格では7万円やそれ以上）では話になりません
通常のDLL形式ならユーザーが要れるのも有るのだけど、その場合どうすんだ？それにMS提供のDLLならARM対応だろ。APIさえ互換を取れれば中身はなんでも良いのだから。
ARMとX86はABIが違うんじゃないかなー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
86エミュレート？ (スコア:0)
前に読んだ記事だとWindowsのDLLがARM系命令に変換（？）してるだけで
x86エミュレートはしてないって書いてあったような気が…
Re: (スコア:0)
MS自身の大本営発表で
実際には開発は遅れに遅れ当初のスケジュールも守れていない、
現時点では汎用x86バイナリを試用者に自由にインストールさせ動かしてみせることも禁止しなければならないWindowsRTと何ら変わらないような状況と前置きした上で
MS自身がエミュレーションと明確に説明してる
https://news.mynavi.jp/article/20170522-windows10report/ [mynavi.jp]
Re: (スコア:0)
間違っててもいいのでもっと詳しく。
DLL、変換、エミュレートを同列に並べておまけに三点リーダで濁すとかイライラする
Re: (スコア: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変換のオーバーヘッドが少ないので、もしかしたらそっちは前者の方向で実現するかもしれません。
Re: (スコア:0)
> WindowsのDLLがARM系命令に変換（？）してるだけで
それだとそもそもx86バイナリが走らないので意味ないのでは。
それともARM命令セット向けのバイナリを起こすコンパイラでコンパイルする事を前提に考えてます？だとすると既存のx86バイナリは動かないのでうたってる内容と合わない。
よってエミュレータが(バイナリ読んで)走ってるで間違いないと思います。
Re: (スコア:0)
命令変換してディスク上にキャッシュするとも言ってるよ
エミュレートしてないとは言ってないし、両者は排他ではない
https://channel9.msdn.com/Events/Build/2017/P4171 [msdn.com]
6:25付近
Re: (スコア:0)
ｘ86Win32エミュかー
そう言われると納得できる
Re: (スコア:0)
Microsoft製のライブラリはエミュレーションしないと思うよ。多分Windowsというかマイクロソフトが提供するライブラリ関係はWOW64と同様の手法になってるとおもう。要するにwin32のABIで呼び出せるが実際に呼び出されるのはARMのライブラリ。ライブラリから戻ってくるデータはwin32のABI。
Re: (スコア:0)
しかしなんでこのタイミングでwin32なんだろうね。
64ビットの方は特許がらみで何かあるとか？
Re:86エミュレート？ (スコア:1)
> しかしなんでこのタイミングでwin32なんだろうね。
> 64ビットの方は特許がらみで何かあるとか？
それもMS公式の情報が出てて、単純に開発が間に合わないからx64は後回しにしてるってだけの話
一般ユーザの使うバイナリのうちx64バイナリは19%くらいしかないから、
そんなの使えなくてもなんとかなるだろうという主張
当たり前だけどそんなわけねーだろ、必要なアプリが一つでも使えなかったらもう駄目なんだから最初からカワネーヨというツッコミの嵐
https://pc.watch.impress.co.jp/docs/column/ubiq/1095498.html [impress.co.jp]
Re: (スコア:0)
…atomってx64バージョンあったっけ…？
32ビットの方でもそれなりには売れてた気が…。
Re:86エミュレート？ (スコア:1)
> …atomってx64バージョンあったっけ…？
普通に64bit版Winを採用したAtomPCなんていくらでもあるが何を言っているんだ
ARM信者の無知っぷりは底なしか
Re: (スコア:0)
ネットでも市場でもAtom機で32bit搭載型探す方が大変苦労すると思いますよ
Re: (スコア:0)
ごめん。最初は32bit版Connected Standbyのみの対応だったせいかすっかり間違って記憶してた…。手持ちのatomタブレット(今も現役)が丁度その頃の製品だったし…。
Re: (スコア:0)
https://ja.wikipedia.org/wiki/Intel_Atom [wikipedia.org]
こいつを見てくれ、どう思う?
Re: (スコア:0)
64ビットバイナリ走るようになったら結構魅力的だと思うけどな。
あとはドライバか。
一年くらいは様子見ってとこかな。
Re: (スコア:0)
> 64ビットバイナリ走るようになったら結構魅力的だと思うけどな。
64bit向けのエミュレーション実装をまた別に書かなきゃいけないので、
32bit向け実装を作ったのと同じくらいのコストがかかるけどな
しかもその後のメンテコストも32bitと64bitでそれぞれかかり続ける
はっきり言って商売として成立するとも思えない
> あとはドライバか。
なおさら無理
> 一年くらいは様子見ってとこかな。
64bitエミュレーション実装を実用レベルにするのは1年じゃ無理
かといって2年たつとRISC-Vのほうが花開いているだろうし、行くも地獄戻るも地獄だな
Re: (スコア:0)
なんでそんなにRISC-Vが好きなのか理解できんな。
万が一うまくいっても今のARMを巡る状況とほとんど変わらんぞ。
Re: (スコア:0)
x86・x64からARMへ移行しようとすると各種互換性問題でそれだけ大変になるのなら、あと2年程度の期間でRISC-Vへの移行がそんなに進むものなの…？
Re:86エミュレート？ (スコア:1)
RISC-Vは命令セットを好きに拡張・改変できるのでスパコン業界からの熱視線を浴びているのが事実
ARMのスパコン進出の強敵になりそうだ
コンシューマーへの影響はわからない
Re: (スコア:0)
> x86・x64からARMへ移行しようとすると各種互換性問題でそれだけ大変になるのなら、
> あと2年程度の期間でRISC-Vへの移行がそんなに進むものなの…？
方向性は2つあって、ほぼ確実に前者になるだろう
・x86/x64バイナリはやはり強く、それを軽量モバイル端末上でエミュレーション実行するのは開発面でも負荷の面でも無理
-> 今のARM版Winは死亡確定、大きく機能を縮退したWindowsRTに毛の生えた程度の内容に変更して細々と生き残る
-> そのくらいしかやらない前提にするなら、ARMなんて捨ててRISC-Vでいいね
・UWPアプリが花開き、一般市場でx86/x64バイナリの需要がなくなる。それによりARM版Winが市場で受け入れられる
-> じゃあARMなんて捨ててRISC-Vでいいね
どっちにせよARMからRISC-Vに変化していくのは避けられない
Re: (スコア:0)
後者は知らんが、前者なら細々と生き残っているものにわざわざRISC-V版を開発するコストをかけられないんでないかい？
Re: (スコア:0)
一応将来のアップデート(ちょっと先のアップデート)で対応するとは言っている。スケジュールどおりに進むかは不明。X64版オンリーのソフトは大容量メモリを活用するヘビーなソフトが多いのでこのての端末には不向き。故に後回しでも問題ない。というのは戦略上多分正しい。
Re: (スコア:0)
まあビジネス向けなら未だに32ビット版OSを指名買いするような所も多いからね。
当然その手のユーザーはそれで困って居ないって事だし。
Re: (スコア:0)
そしてそんな保守的なビジネス層がARM版Windowsなんて絶対に選ぶわけ無いからね
Re: (スコア:0)
それがいきなりiPadガーとか言い出したりするんだけどね。
保守的だろうが革新的だろうが判断の閾値が異なるだけで、基本的には仕様機器なんぞ経年で変化するって事位は知って居るものだよ。
でもって、「世の中Linuxでデスクトップを」ってのが通る如く、この手のも閾値を超える事はままあるんだわ。
Re: (スコア:0)
なるほど、馬鹿な奴がまともな考えもなしにARM版Windowsに飛びついて大失敗するってことだね
ほんとそのとおりだ
Re: (スコア:0)
WOW64をARMにそのまま乗っけたような形ではないでしょうか。
だから32bitアプリ限定と。
電池の持ちもCPU性能もAtomよりちょっとよいくらい、MMCよりUFSでアプリ起動は多少期待できそう、
その分価格は出始めの頃のAtomのタブレットよりやや高め（最初は6，7万してましたよね）と、
まあAtomタブレットの後継機としては悪くないのかもしれません。
ただ問題は最近64bit専用アプリも結構増えてるということですが･･
これで8-9インチくらいの2in1に仕立ててくれればT90Chiの後継機としてちょっと興味が出てくるのですが。
#GPD Pocketだとちょっと微妙
Re: (スコア:0)
> その分価格は出始めの頃のAtomのタブレットよりやや高め（最初は6，7万してましたよね）と、
ベイトレAtomタブレット普及の際に話題になったMiix2は当時ですでに4万円程度だったので、
あなたの記憶は相当間違っていますね
ARM版Win製品がまともに市場で受けられるようにするには、
日本国内での新品価格、当然回線抱き合わせなどなしで3万円～4万円が限界でしょう
599ドルスタート（日本価格では7万円やそれ以上）では話になりません
Re: (スコア:0)
通常のDLL形式ならユーザーが要れるのも有るのだけど、その場合どうすんだ？
それにMS提供のDLLならARM対応だろ。
APIさえ互換を取れれば中身はなんでも良いのだから。
Re: (スコア:0)
ARMとX86はABIが違うんじゃないかなー