アカウント名:
パスワード:
> 同日発表されたXcode 12を使用すれば多くの場合はコードを変更することなく、Apple製プロセッサーを搭載する新しいMacでネイティブ動作しつつ、IntelベースMacもサポート可能なUniversal 2アプリが作成できるという。
こういうハードウェアの差異を吸収するのも、OSのお仕事なんじゃないのって思うんだが…考え方が古い?
単に、Intel用のネイティブコードとApple製プロセッサ用のネイティブコード両方を含むバイナリ(パッケージ)を生成するものと理解したんだけど、違うのかしら。記憶に間違いがなければ、前回の移行もこうやったはず。
ハードウェア刷新とOS更新を同時にするなんて。しかもAppleのソフトウェア品質管理能力で。
# 「夜郎自大」とも呼ぶ。
Intel版バイナリを Arm で動かすためには Rosetta 2 が用意されているだろあなたが引用したのは Arm版バイナリを生成したい人向けの機能だよ
昔そうやってハードウェアが変わっても同じバイナリが動くよ!ってやって、遅いとか不具合でバイナリ移行するしかなかった。
今は特別重いアプリ以外、問題ないはずだな。
FX!32のことは忘れないであげたいよね。
あれは書籍記事とかでは十分な性能が出たようなことが書いてあったが本当のところどうだったのだろう。
FX!32環境は、Alphaネイティブバイナリはで3DCADツールを使うのが主用途+細々としたx86バイナリの実行程度であれば十分実用に耐えました。ただPhotoshopとかそういうのを使うため用には別PCを用意した方がよかったですな。
80ビットの拡張精度浮動小数は使えなかった筈。# FX!32の記事(DECの技報的なやつ)には、拡張精度が必要なやつは少ないとか載ってた様な。
あった。
Very few applications rely on the full precision provided by the x86 floatingpoint unit's (FPU's) 80-bit registers. DIGITAL FX!32: Combining Emulation and Binary Translation [hp.com]
Tru64 UNIX機にWindowsNTをインストールしてIA32版Office一通り動かしましたが、実用可能な速度でしたよ。
hpuxとか?ACOSとか?
ん…当時もバイナリ移行が目的で、ユニバーサルバイナリは移行中の措置だったんだけどね。
Write once, trouble anywhere.
AS/400が独自CISCからPOWERプロセッサに変わった時は、バイナリだけコピってくれば普通に動いてたな。
AS/400はJITキャッシュをバイナリに保持したインタプリタみたいなもんだからな。ネイティブコードといっても、.NETやJavaのバイトコードにちかい。
OSの仕事かどうかよりはアプリケーションを配布する側がコンパイルするか実行する側がコンパイルするかの違いでしょ。配布する側がコンパイルしておけばコンパイルが一回で済む。実行する側で変換するなりコンパイルすると電気代の無駄。実行する側でコンパイルというか最適化すれば古いソフトを新しいハードでより高速に動かせるかもみたいなのはあるけど。むしろこういうハードウェアの差異を吸収するのはクルーソーみたいなハードウェアとかJava VM,QUEMUみたいなミドルウェアの仕事だと思ってました。
カーネルだけがOSだって思想だと駄目だけど、XcodeもOSの提供物の一部と捉えたらOSの仕事と言えるんじゃない?昔からUnixだってCコンパイラや標準ライブラリはOSの一部だし、WindowsだってC#コンパイラも.NETランタイムもOSの一部で、最初から入ってるもの。
PC用OS以外も含めると開発環境が付いてくる方が少数派だしOSの仕事としてはAPIの定義とランタイムの提供くらいまでなイメージ
昔のパソコンには何にでもBASICがついてた。BASICが付いてるのが当たり前だった。
8~16bit機に付いて来たBASICってOS(或いはBIOS)でわ?
確かにあれは、OSでしたね。無いとパソコンはただの箱でした。当時のパソコンは、自分でプログラムを書くもの、という認識でした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
OSのお仕事? (スコア:0)
> 同日発表されたXcode 12を使用すれば多くの場合はコードを変更することなく、Apple製プロセッサーを搭載する新しいMacでネイティブ動作しつつ、IntelベースMacもサポート可能なUniversal 2アプリが作成できるという。
こういうハードウェアの差異を吸収するのも、OSのお仕事なんじゃないのって思うんだが…考え方が古い?
Re:OSのお仕事? (スコア:1)
単に、Intel用のネイティブコードとApple製プロセッサ用のネイティブコード両方を含むバイナリ(パッケージ)を生成するものと理解したんだけど、違うのかしら。記憶に間違いがなければ、前回の移行もこうやったはず。
Appleバカだろう (スコア:0, 興味深い)
ハードウェア刷新とOS更新を同時にするなんて。
しかもAppleのソフトウェア品質管理能力で。
# 「夜郎自大」とも呼ぶ。
Re: (スコア:0)
Intel版バイナリを Arm で動かすためには Rosetta 2 が用意されているだろ
あなたが引用したのは Arm版バイナリを生成したい人向けの機能だよ
Re: (スコア:0)
昔そうやってハードウェアが変わっても同じバイナリが動くよ!ってやって、
遅いとか不具合でバイナリ移行するしかなかった。
今は特別重いアプリ以外、問題ないはずだな。
Re:OSのお仕事? (スコア:1)
FX!32のことは忘れないであげたいよね。
Re: (スコア:0)
あれは書籍記事とかでは十分な性能が出たようなことが書いてあったが本当のところどうだったのだろう。
Re: (スコア:0)
FX!32環境は、Alphaネイティブバイナリはで3DCADツールを使うのが主用途+細々としたx86バイナリの実行
程度であれば十分実用に耐えました。
ただPhotoshopとかそういうのを使うため用には別PCを用意した方がよかったですな。
Re: (スコア:0)
80ビットの拡張精度浮動小数は使えなかった筈。
# FX!32の記事(DECの技報的なやつ)には、拡張精度が必要なやつは少ないとか載ってた様な。
Re: (スコア:0)
あった。
Re: (スコア:0)
Tru64 UNIX機にWindowsNTをインストールしてIA32版Office一通り動かしましたが、実用可能な速度でしたよ。
Re: (スコア:0)
hpuxとか?
ACOSとか?
Re: (スコア:0)
ん…当時もバイナリ移行が目的で、ユニバーサルバイナリは移行中の措置だったんだけどね。
Re: (スコア:0)
Write once, trouble anywhere.
Re: (スコア:0)
AS/400が独自CISCからPOWERプロセッサに変わった時は、バイナリだけコピってくれば普通に動いてたな。
Re: (スコア:0)
AS/400はJITキャッシュをバイナリに保持したインタプリタみたいなもんだからな。
ネイティブコードといっても、.NETやJavaのバイトコードにちかい。
Re: (スコア:0)
OSの仕事かどうかよりはアプリケーションを配布する側がコンパイルするか実行する側がコンパイルするかの違いでしょ。
配布する側がコンパイルしておけばコンパイルが一回で済む。実行する側で変換するなりコンパイルすると電気代の無駄。
実行する側でコンパイルというか最適化すれば古いソフトを新しいハードでより高速に動かせるかもみたいなのはあるけど。
むしろこういうハードウェアの差異を吸収するのはクルーソーみたいなハードウェアとかJava VM,QUEMUみたいなミドルウェアの仕事だと思ってました。
Re: (スコア:0)
カーネルだけがOSだって思想だと駄目だけど、XcodeもOSの提供物の一部と捉えたらOSの仕事と言えるんじゃない?
昔からUnixだってCコンパイラや標準ライブラリはOSの一部だし、WindowsだってC#コンパイラも.NETランタイムもOSの一部で、最初から入ってるもの。
Re: (スコア:0)
PC用OS以外も含めると開発環境が付いてくる方が少数派だし
OSの仕事としてはAPIの定義とランタイムの提供くらいまでなイメージ
Re:OSのお仕事? (スコア:2)
昔のパソコンには何にでもBASICがついてた。
BASICが付いてるのが当たり前だった。
# てれっててれっててー --- macohime(#cpdz)
Re: (スコア:0)
8~16bit機に付いて来たBASICってOS(或いはBIOS)でわ?
Re:OSのお仕事? (スコア:2)
確かにあれは、OSでしたね。
無いとパソコンはただの箱でした。
当時のパソコンは、自分でプログラムを書くもの、という認識でした。
# てれっててれっててー --- macohime(#cpdz)