アカウント名:
パスワード:
前作まではSPARCベースの独自CPUだったけど、今回はARMベースだそうな。開発環境はちゃんとしてるんだろうか。
「開発環境」が何を意味するかによりますけど、プログラムの命令はARMでも今どきのCPUはそれをマイクロコードに変換して処理してる。だから命令セットと内部の回路の関連性は少なくて、SPARCと全く違うわけではないらしいですよ。（だから逆に、富岳のARMはスマホのARMと内部はかなり違う）そういう背景からすると、最適化ツールやプロファイラといったCPUの構造と関係が深いプログラムは過去の遺産が応用できるのではないかと思う。
まあARMやコンパイラの出力とかを考慮してマイクロコードレベルでも最適化もしてるので、全くSPARC時代と同じってわけではないだろうけど、京を作ったときと比べれば作業量は少ないのでは？
あとARMだけに関するところなら、llvmとかBSDライセンスでありますし、SPARCよりオープンソースのツールで色々揃えられるのではないかと。（というかARMに乗り換えたのは、ユーザ数が多いことで情報とツールが多いことが関係してるんじゃないのかな？）
JITアセンブラのXbyakは、永らくx86のみサポートしていたけど、富士通がaarch64用のフォークを作った。こういう成果の還元は素晴らしいと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
ARMベース (スコア:0)
前作まではSPARCベースの独自CPUだったけど、今回はARMベースだそうな。
開発環境はちゃんとしてるんだろうか。
Re:ARMベース (スコア:0)
「開発環境」が何を意味するかによりますけど、プログラムの命令はARMでも今どきのCPUはそれをマイクロコードに変換して処理してる。だから命令セットと内部の回路の関連性は少なくて、SPARCと全く違うわけではないらしいですよ。（だから逆に、富岳のARMはスマホのARMと内部はかなり違う）
そういう背景からすると、最適化ツールやプロファイラといったCPUの構造と関係が深いプログラムは過去の遺産が応用できるのではないかと思う。
まあARMやコンパイラの出力とかを考慮してマイクロコードレベルでも最適化もしてるので、全くSPARC時代と同じってわけではないだろうけど、京を作ったときと比べれば作業量は少ないのでは？
あとARMだけに関するところなら、llvmとかBSDライセンスでありますし、SPARCよりオープンソースのツールで色々揃えられるのではないかと。
（というかARMに乗り換えたのは、ユーザ数が多いことで情報とツールが多いことが関係してるんじゃないのかな？）
Re:ARMベース (スコア:1)
JITアセンブラのXbyakは、永らくx86のみサポートしていたけど、
富士通がaarch64用のフォークを作った。
こういう成果の還元は素晴らしいと思う。