アカウント名:
パスワード:
……既存のソフトウェア資産どーすんだよ
iOS の元となった OS である Mac OS X でいえば、そもそも少し前のだって、x86 と PowerPC の混成バイナリだったし、今は 32bit と 64bit の2種類のバイナリがワンパッケージ化されていたりしますので。そういうユニバーサルなのは Apple の十八番です。
無論、ユニバーサルでないバイナリそのものを動かそうとしたらエミュがいるけど。そんな環境を用意しなくても、普通はあっという間に対応ソフトがそろう。
なぜならば、ほとんど、開発環境だけで吸収できる。ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
全くなんの問題もなく、過去の資産を使えますよ。そういう事態が起きても心配無用。
全くなんの問題もなく、過去の資産を使えますよ。
ビルドが通れば問題なくアプリは動作すると思ってる方? おめでたいですね。
もしビルドが通ったのにもかかわらず動かないんだったら、それは XCODEがまともなバイナリを吐いて無いってことだ。もしくは元々バグってたかのどっちかだ。バグがあったのならちょうどいい機会だから直せば良い。
アセンブラでも使って無い限りCPUの違いなんざ微々たるもんだ。そのためのライブラリやAPIだろ。
XCODEがまともなバイナリを吐いて無い場合はどうすんですか? それ以前の話として、ビルドが通ったアプリの動作確認もせずに動くか動かないか判るんですか?
アセンブラでも使って無い限りCPUの違いなんざ微々たるもんだ。
コンパイラの、ARMかx86用にコード吐く部分て結構違うと思いますが。
もしXCODEのx86コードが使い物にならない代物なら、すでにおおさわぎになってるはずだよね。
もしXCODEのx86コードが使い物にならない代物なら、
誰かそんなこと言ってますか?
親コメントで言ってるよね
XCODEがまともなバイナリを吐いて無い場合はどうすんですか?
特定のソースの書き方や最適化の設定なんかでコンパイラがおかしなコード吐くのってそんな珍しいもんでないし、ソース書き換えたりコンパイルオプション変えて回避するなんてのは常套手段でしょ。そんな程度のことでコンパイラのことを「使い物にならない代物」とはそうそう言わないと思いますが。
今時のコンパイラがおかしなコードを吐くような書き方って凡人がそう簡単に出来るようなもんじゃないと思うんだけど、そんな珍しくないものなの?もちろん規格違反のコードもしくは意図するコードを書けないでおきながらおかしなコードを吐く!とほざくアホは論外として。
#もちろんVC++は今時のコンパイラーじゃないです
Xcode bugsでぐぐるだけ [google.co.jp]で何十万件だか出てくる程度には珍しくないですな。
いくつかコンパイラ関連のバグの内容を見てみましたが、アーキテクチャ依存のバグは見当たりませんね。
x86のコード品質に問題があるという話は成り立ちません。
LLVM の Bugzilla [llvm.org]でARMとかthumbとかx86とかで検索するだけでアーキテクチャ依存の不具合なんて沢山報告されてるの分かると思うけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
Intel「今後のiPhoneもiPadも全部Atom採用にするなら作ってやるよ(ホジホジ」 (スコア:0)
……既存のソフトウェア資産どーすんだよ
Re: (スコア:1)
iOS の元となった OS である Mac OS X でいえば、そもそも少し前のだって、x86 と PowerPC の混成バイナリだったし、今は 32bit と 64bit の2種類のバイナリがワンパッケージ化されていたりしますので。そういうユニバーサルなのは Apple の十八番です。
無論、ユニバーサルでないバイナリそのものを動かそうとしたらエミュがいるけど。
そんな環境を用意しなくても、普通はあっという間に対応ソフトがそろう。
なぜならば、ほとんど、開発環境だけで吸収できる。
ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。
そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
全くなんの問題もなく、過去の資産を使えますよ。
そういう事態が起きても心配無用。
Re: (スコア:0)
なぜならば、ほとんど、開発環境だけで吸収できる。
ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。
そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
全くなんの問題もなく、過去の資産を使えますよ。
ビルドが通れば問題なくアプリは動作すると思ってる方? おめでたいですね。
Re: (スコア:0)
もしビルドが通ったのにもかかわらず動かないんだったら、
それは XCODEがまともなバイナリを吐いて無いってことだ。
もしくは元々バグってたかのどっちかだ。
バグがあったのならちょうどいい機会だから直せば良い。
アセンブラでも使って無い限りCPUの違いなんざ微々たるもんだ。
そのためのライブラリやAPIだろ。
Re: (スコア:0)
もしビルドが通ったのにもかかわらず動かないんだったら、
それは XCODEがまともなバイナリを吐いて無いってことだ。
もしくは元々バグってたかのどっちかだ。
バグがあったのならちょうどいい機会だから直せば良い。
XCODEがまともなバイナリを吐いて無い場合はどうすんですか? それ以前の話として、ビルドが通ったアプリの動作確認もせずに動くか動かないか判るんですか?
アセンブラでも使って無い限りCPUの違いなんざ微々たるもんだ。
コンパイラの、ARMかx86用にコード吐く部分て結構違うと思いますが。
Re: (スコア:0)
もしXCODEのx86コードが使い物にならない代物なら、
すでにおおさわぎになってるはずだよね。
Re: (スコア:0)
もしXCODEのx86コードが使い物にならない代物なら、
誰かそんなこと言ってますか?
Re: (スコア:0)
親コメントで言ってるよね
XCODEがまともなバイナリを吐いて無い場合はどうすんですか?
Re: (スコア:0)
特定のソースの書き方や最適化の設定なんかでコンパイラがおかしなコード吐くのってそんな珍しいもんでないし、ソース書き換えたりコンパイルオプション変えて回避するなんてのは常套手段でしょ。そんな程度のことでコンパイラのことを「使い物にならない代物」とはそうそう言わないと思いますが。
Re: (スコア:0)
今時のコンパイラがおかしなコードを吐くような書き方って凡人がそう簡単に出来るようなもんじゃないと思うんだけど、そんな珍しくないものなの?
もちろん規格違反のコードもしくは意図するコードを書けないでおきながらおかしなコードを吐く!とほざくアホは論外として。
#もちろんVC++は今時のコンパイラーじゃないです
Re: (スコア:0)
Xcode bugsでぐぐるだけ [google.co.jp]で何十万件だか出てくる程度には珍しくないですな。
Re: (スコア:0)
いくつかコンパイラ関連のバグの内容を見てみましたが、アーキテクチャ依存のバグは見当たりませんね。
x86のコード品質に問題があるという話は成り立ちません。
Re:Intel「今後のiPhoneもiPadも全部Atom採用にするなら作ってやるよ(ホジホジ」 (スコア:0)
いくつかコンパイラ関連のバグの内容を見てみましたが、アーキテクチャ依存のバグは見当たりませんね。
LLVM の Bugzilla [llvm.org]でARMとかthumbとかx86とかで検索するだけでアーキテクチャ依存の不具合なんて沢山報告されてるの分かると思うけどね。