アカウント名:
パスワード:
MSの発表を見る限り、中身はほぼAMDのMantleにしか聞こえないのだけどMantleのAPIは未定義 [impress.co.jp]で開発任せな現状らしいのでAMDは始めからMSにDX12を作らせる目的でMantleを発表したのではないか、と思ってしまう。DX12の後ろにいるのはAMDのようだし。
リンク先には
Mantleはやっかいで、何も定義されてない。ゲーム機のAPIと似てはいるけど互換じゃない。
とは書いてありますが、APIが未定義とは書いてないように思いますが…。実際、Wikipediaには
Mantle is a graphics API specification developed by AMD as an alternative to Direct3D and OpenGL, primarily for use on the PC platform.
とあります。
「Mantleはやっかいで、何も定義されてない」という記載は意味不明です。というか、専門家気取りの半可通がいいかげんなことを言ってる記事で、ARM 32-bitの箇所とか、読んでてこっちが気恥ずかしくなってきますね。
MantleはGPUへのアクセスを提供するだけで、その結果は保証されない。GPUの実装に依存する。という意味でないの。
ふむ。どのように間違ってるんでしょ?>ARM32bitの箇所
自分は半可通どころか努素人なので、ほほーと思って読んでたけど、いいかげんな話だったのか…。割り算命令無いとか、前世紀のリレー式計算機かよって思ったもんな。
でも、32bitのARMv7Aではハードウェア整数除算器が標準でないのは確かよ。Cortex-A9まではハードウェア整数除算器がないのが普通。この辺が参考になりそう。http://blog.kmckk.com/archives/4164432.html [kmckk.com]http://blog.kmckk.com/archives/4170081.html [kmckk.com]
元記事の表現が、いいおじさんがしゃべってると思うと恥ずかしくなっちゃうのは確かだけど、書いてある内容自体はまともなことです。ARMv8は64bit化というよりも、ARMv7までの継ぎ足し変態仕様が解消されるのを喜ぶ人は多いと思う。
いやー、RISCってそういうものじゃないの?ハードウェア除算器とかそういう複雑な回路は排除して、単純な命令の組み合わせでそういう処理を行わせるのとあわせて個々の単純な命令の処理サイクルは最低にとどめて全体の実行速度の向上を図るという方向性。
なのに「ハードウェア除算器がない」とか言われても。
RISCの思想を分かってないから、半可通ってことですか?そりゃ古のRISCはそういう思想だったけど、ここ5年~10年のCPUでRISCだから単純になんて考えてるCPUはない。ハードウェア除算器が回路が大きいって言われたのは昔の話で、Out-of-Order実行のA9でそんな話を振られても意味が分からないよ。
ARM自身にしたって、より規模が小さい組み込み向けのMシリーズにはハードウェア除算器載ってるし、AシリーズでもA15からは採用してる。
あれかなあ、プロセスルールの進化でトレードオフの評価が変化したのかなあ
ARM自身にしたって、より規模が小さい組み込み向けのMシリーズにはハードウェア除算器載ってるし、
Cortex-M0 は除算命令なかった気がしたし AVR もそうじゃなかったかな?
規模的には除算機を組み込めても、組み込み用途では割り込みのレスポンスが悪くなるので敢えて採用しない、みたいなケースもあるんじゃないかと思いますね。
プロセスルールが変化しても除算が1サイクルでできることはないのでRISCの思想に合わないことに変わりはないが?
今時、原理主義でRISCの思想に合わんから使わないなんて設計しないでしょ。
それって MIPS の思想?
ほほーと思ったんと違うんかい
【山田】つまり今のARMの32bitはひどいと。【後藤】ひどい。だって、僕の知り合いでネイティブARM 32bitに触れた人は皆「変態命令セット」って言ってるし(笑)。
【山田】つまり今のARMの32bitはひどいと。
【後藤】ひどい。だって、僕の知り合いでネイティブARM 32bitに触れた人は皆「変態命令セット」って言ってるし(笑)。
自分でプログラム組んだことない素人でしょ
後藤さんがプログラム組めるかどうかは知らないけど、彼の記事、いつもは結構参考になるんだけどな。あとARMの命令セットが変わってるのは事実でしょう。自分は結構好きだけど、あれコンパイラは最適化しにくいんじゃないかと思う。
あとARMの命令セットが変わってるのは事実でしょう。
条件実行や3オペランドはARM以前のプロセッサと比べては変わってると思うけど、レジスタの数については騒ぐようなものではないと思う。
コンピュータを使うと言うことがそのままプログラムを組むと言う事だった時代からこの界隈でライターやってる二人を捕まえて素人とは恐れ入った
だったら自分の言葉で語れって話だよなあ、直接 ARM 使った経験なかったとしても、他のアーキテクチャ習熟してれば「RISCなのに汎用レジスタが16本しかない」なんて馬鹿発言はそうそう出ない筈。
何がひどいか? RISCなのに汎用レジスタが16本しかない、その内の3本はプログラム関連で使っちゃうので、汎用に使えるのはたった13本。これで、ロード/ストアアーキテクチャのハンドリングをしなきゃならない。そうするとコンパイラが効率的なコードを吐けない。ので、コードステップが非常に長くなる。
確かにこれはひどいね。素人以下。
ので、コードステップが非常に長くなる。
なるほどわからん。レジスタ不足だから、主記憶に退避でもしているのだろうか。
レジスタに割り付けられないローカル変数はスタックフレーム(主記憶)に割り付けられる、が、ARM の仕様でそれほと問題になることは実際大してない。thumb ならまた別だが。
確かに生成されたコードを見ると、レジスタが足りなくてロード、ストアが頻出するってことは少ない気はする。ただ、x86-64の例を見ると、汎用レジスタが増えるのはやっぱり効いてくるんではないかと思う。Apple A7の性能向上も64-bit化自体が効いてるとは考え難いし。
ただ、x86-64の例を見ると、汎用レジスタが増えるのはやっぱり効いてくるんではないかと思う。
IA-32 → x86-64 で汎用レジスタが何個から何個になったかご存知?
知ってるけど、それが何か?もともとCISCの設計思想、かつスタックベースの命令が多いx86と、RISCの流れのARMとのレジスタの絶対数を比較してもあんまり意味が無いんじゃない?PPCやMIPSは32本のGPRを持ってるよね?あとA7については憶測だけど、レジスタの増加がパフォーマンスに全く効いてないとは考え難い。コンパイラで使うレジスタの数を制限するフラグでもあれば比較できて面白いかも。
もともとCISCの設計思想、かつスタックベースの命令が多いx86と、RISCの流れのARMとのレジスタの絶対数を比較してもあんまり意味が無いんじゃない?
汎用レジスタはいくつくらいあればまあ不足はないかというのを判断するのにRISCもCISCもあんま関係ないのでは?
「スタックベースの命令が多いx86」ということだけど、汎用レジスタ上にデータ置くのとスタックフレーム上に置くのとで違いがないのであれば(あり得ないが)、x86-64 で汎用レジスタの数を増やしたメリットはないですね。
x86のシステムレベルのアセンブリコード書いたことある?オフトピだからこれで最後にするけど、x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。レジスタリネーミングはご存じ?実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。
それでもレジスタアクセスより遅いしコードも長くなりますね。何が言いたいんでしょうか?
レジスタリネーミングはご存じ?実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
あなたがレジスタリネーミングについて理解されてないことは分かりました。
x86のシステムレベルのアセンブリコード書いたことある?
話題の流れとして何か関係のある話ですか?
どうとでもとれる中途半端な書き方をして、明言を避ける。質問で返して、相手の揚げ足をとろうとする。知ったかぶり同士の会話は微笑ましいね。
実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
自分も上のACと同じ理解してるけど間違ってるの?
まあ、これでも読んでくれhttp://yarchive.net/comp/linux/x86.html [yarchive.net]
レジスタに割り当てられるデータの数に影響する技術じゃないよ
OoOで、同時に使われるレジスタは実質的には増えますが?
コード上でのレジスタに割り当てられるデータの数は増えないよ
なんだ、トロールか。真面目に聞いて損した。
RISCとCISCで(見かけ上)必要となるレジスタの数が違ってくるのは常識でしょ。
いまどきRISCだCISCだなんて話しないでしょ。
いや、内部的にやってることが似通ってきても、x86のISAがCISCなのに変わりは無い。メモリ上の値を(見かけ上は)直接変更できる命令セットと、レジスタ上にロードしないと何もできないRISCで必要となるレジスタ数が同じと考える方がおかしい。
何個から何個かは知らないけれど。IA-32/x86-64 でのレジスタ増加の効果に対し、ARMで同様に考えようとするのが方向違いなのは分かる。IA-32のレジスタが少なすぎに対し、ARMはもともとそれなりにある。ARM が倍になっても、効果がある機会は限られる。ARMではレジスタ不足のためのロード/ストアがあっても、(IA-32に比すれば)影響が十分小さいんじゃないかな。
CISC/RISCに関係なく IA-32のレジスタ本数は足りてない。スタックベース命令も多く使われる命令はRISCにも同一機能は用意されているような。CISC的スタックベース命令って遅い命令が多かったような。今は違うの?32本のGPRがあってフル活用しても 16本の時と劇的に違うって場合はあまりなさそう(たまにありそう)。
A7は・・・レジスタが 64bit長になったことがうれしいときもあるし、レジスタが増えたことがうれしいときもあると思うよ?
アセンブリコードとか言いながらレジスタリネーミングとか片腹痛いレジスタリネーミングでマシン語プログラミングが楽になったら驚きだ。
あなたの行っている「x86のシステムレベルのアセンブリコード」が プロセッサの実装で、レジスタリネーミングのついでに命令発行をバイパスしてやったぜ!とか言うなら脱帽ですが。
そうじゃないならレジスタ退避で命令発行ポートストールされてろ
x86でも実行効率とメモリ効率の両方を重視すればデータはレジスタ上に置くしかないし、結局は他のアーキテクチャと事情は変わらん。
アセンブリコードの件は、x86の作法で書けばそんなにレジスタが要らない理由が分かるはずと思ったんだけどね。まあ、それでもレジスタリネーミングで楽にはなるよ。適当に書いてもそれなりのパフォーマンスが出るからね。
ああ、馬鹿丸出し
議論する気が無いならもういいけど、反論も出来ないの?
だから、これ読めって。http://yarchive.net/comp/linux/x86.html [yarchive.net]
別ACだけど横から失礼。
コンパイラって、汎用レジスタが多い方が性能が出るんじゃないの?最適化の過程でメモリアクセスのコストが一番小さくなるように汎用レジスタを使い回すコードを吐き出すようになっていても。
そもそもレジスタリネーミング用のレジスタを大量に持っていても、汎用レジスタと違ってプログラムからは直接指定できないから、プログラム中の命令はデータアクセスを伴うものが多くなり、汎用レジスタを多く持つCPUと同等とは言えないのでは?
データアドレスを比較して物理レジスタに割り当てるようなことまで行っても、プログラムの各ステップで生じたテンポラリのデータは、プログラム的に指示されたアドレスに書き戻さないと、プログラムとメモリ内容の整合が取れなくなりますから。
RISCでもSPARCは汎用レジスタは実質7本扱いじゃなかったっけ?あとはコールスタックとかレジスタウィンドウとかの絡みで色々と面倒な数え方だったかと。
ARMより後発のSuperHでも16個
汎用レジスタが多いと、割込みやプロセススイッチのときにメモリに退避するデータ量も増えて時間が掛かるしね。
そういうのが効率に影響するような用途では汎用レジスタをバンク化して切り替えの効率化図ったりしてるの普通にあるけどね、SuperHも勿論。
SuperHのレジスタ数は
という経緯を経て決まった、みたいな話を20年位前の日エレかなんかで読んだ気がするな。
これのことじゃないかな? (Wikipediaより):> As of March 2014, the Mantle specification and development materials remain unavailable to the general public.
仕様が一般には公開されてないってことだけど、実はまだいろいろ決めてる段階なんじゃないの?
だとしても現にそれで動作してるゲームがある状況で「何も定義されてない」はないよねえ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
Mantleは当て馬? (スコア:0)
MSの発表を見る限り、中身はほぼAMDのMantleにしか聞こえないのだけど
MantleのAPIは未定義 [impress.co.jp]で開発任せな現状らしいので
AMDは始めからMSにDX12を作らせる目的でMantleを発表したのではないか、と思ってしまう。
DX12の後ろにいるのはAMDのようだし。
Re:Mantleは当て馬? (スコア:0)
リンク先には
Mantleはやっかいで、何も定義されてない。ゲーム機のAPIと似てはいるけど互換じゃない。
とは書いてありますが、APIが未定義とは書いてないように思いますが…。
実際、Wikipediaには
Mantle is a graphics API specification developed by AMD as an alternative to Direct3D and OpenGL, primarily for use on the PC platform.
とあります。
「Mantleはやっかいで、何も定義されてない」という記載は意味不明です。
というか、専門家気取りの半可通がいいかげんなことを言ってる記事で、ARM 32-bitの箇所とか、読んでてこっちが気恥ずかしくなってきますね。
Re:Mantleは当て馬? (スコア:1)
MantleはGPUへのアクセスを提供するだけで、その結果は保証されない。GPUの実装に依存する。という意味でないの。
Re: (スコア:0)
ふむ。どのように間違ってるんでしょ?>ARM32bitの箇所
自分は半可通どころか努素人なので、ほほーと思って読んでたけど、いいかげんな話だったのか…。
割り算命令無いとか、前世紀のリレー式計算機かよって思ったもんな。
Re:Mantleは当て馬? (スコア:1)
でも、32bitのARMv7Aではハードウェア整数除算器が標準でないのは確かよ。
Cortex-A9まではハードウェア整数除算器がないのが普通。
この辺が参考になりそう。
http://blog.kmckk.com/archives/4164432.html [kmckk.com]
http://blog.kmckk.com/archives/4170081.html [kmckk.com]
元記事の表現が、いいおじさんがしゃべってると思うと恥ずかしくなっちゃうのは確かだけど、
書いてある内容自体はまともなことです。
ARMv8は64bit化というよりも、ARMv7までの継ぎ足し変態仕様が解消されるのを喜ぶ人は多いと思う。
Re: (スコア:0)
いやー、RISCってそういうものじゃないの?
ハードウェア除算器とかそういう複雑な回路は排除して、単純な命令の組み合わせでそういう処理を行わせるのとあわせて
個々の単純な命令の処理サイクルは最低にとどめて全体の実行速度の向上を図るという方向性。
なのに「ハードウェア除算器がない」とか言われても。
Re: (スコア:0)
RISCの思想を分かってないから、半可通ってことですか?
そりゃ古のRISCはそういう思想だったけど、ここ5年~10年のCPUでRISCだから単純になんて考えてるCPUはない。
ハードウェア除算器が回路が大きいって言われたのは昔の話で、Out-of-Order実行のA9でそんな話を振られても意味が分からないよ。
ARM自身にしたって、より規模が小さい組み込み向けのMシリーズにはハードウェア除算器載ってるし、
AシリーズでもA15からは採用してる。
Re: (スコア:0)
あれかなあ、プロセスルールの進化で
トレードオフの評価が変化したのかなあ
Re: (スコア:0)
ARM自身にしたって、より規模が小さい組み込み向けのMシリーズにはハードウェア除算器載ってるし、
Cortex-M0 は除算命令なかった気がしたし AVR もそうじゃなかったかな?
規模的には除算機を組み込めても、組み込み用途では割り込みのレスポンスが悪くなるので敢えて採用しない、みたいなケースもあるんじゃないかと思いますね。
Re: (スコア:0)
プロセスルールが変化しても除算が1サイクルでできることはないのでRISCの思想に合わないことに変わりはないが?
Re: (スコア:0)
今時、原理主義でRISCの思想に合わんから使わないなんて設計しないでしょ。
Re: (スコア:0)
それって MIPS の思想?
Re: (スコア:0)
ほほーと思ったんと違うんかい
Re: (スコア:0)
自分でプログラム組んだことない素人でしょ
Re: (スコア:0)
後藤さんがプログラム組めるかどうかは知らないけど、彼の記事、いつもは結構参考になるんだけどな。
あとARMの命令セットが変わってるのは事実でしょう。
自分は結構好きだけど、あれコンパイラは最適化しにくいんじゃないかと思う。
Re: (スコア:0)
あとARMの命令セットが変わってるのは事実でしょう。
条件実行や3オペランドはARM以前のプロセッサと比べては変わってると思うけど、レジスタの数については騒ぐようなものではないと思う。
Re: (スコア:0)
コンピュータを使うと言うことがそのままプログラムを組むと言う事だった時代から
この界隈でライターやってる二人を捕まえて素人とは恐れ入った
Re: (スコア:0)
だったら自分の言葉で語れって話だよなあ、直接 ARM 使った経験なかったとしても、他のアーキテクチャ習熟してれば「RISCなのに汎用レジスタが16本しかない」なんて馬鹿発言はそうそう出ない筈。
Re: (スコア:0)
確かにこれはひどいね。素人以下。
Re:Mantleは当て馬? (スコア:2)
なるほどわからん。
レジスタ不足だから、主記憶に退避でもしているのだろうか。
Re: (スコア:0)
レジスタに割り付けられないローカル変数はスタックフレーム(主記憶)に割り付けられる、が、ARM の仕様でそれほと問題になることは実際大してない。thumb ならまた別だが。
Re: (スコア:0)
確かに生成されたコードを見ると、レジスタが足りなくてロード、ストアが頻出するってことは少ない気はする。
ただ、x86-64の例を見ると、汎用レジスタが増えるのはやっぱり効いてくるんではないかと思う。
Apple A7の性能向上も64-bit化自体が効いてるとは考え難いし。
Re: (スコア:0)
ただ、x86-64の例を見ると、汎用レジスタが増えるのはやっぱり効いてくるんではないかと思う。
IA-32 → x86-64 で汎用レジスタが何個から何個になったかご存知?
Re: (スコア:0)
知ってるけど、それが何か?
もともとCISCの設計思想、かつスタックベースの命令が多いx86と、
RISCの流れのARMとのレジスタの絶対数を比較してもあんまり意味が無いんじゃない?
PPCやMIPSは32本のGPRを持ってるよね?
あとA7については憶測だけど、レジスタの増加がパフォーマンスに全く効いてないとは考え難い。
コンパイラで使うレジスタの数を制限するフラグでもあれば比較できて面白いかも。
Re: (スコア:0)
もともとCISCの設計思想、かつスタックベースの命令が多いx86と、
RISCの流れのARMとのレジスタの絶対数を比較してもあんまり意味が無いんじゃない?
汎用レジスタはいくつくらいあればまあ不足はないかというのを判断するのにRISCもCISCもあんま関係ないのでは?
「スタックベースの命令が多いx86」ということだけど、汎用レジスタ上にデータ置くのとスタックフレーム上に置くのとで違いがないのであれば(あり得ないが)、x86-64 で汎用レジスタの数を増やしたメリットはないですね。
Re: (スコア:0)
x86のシステムレベルのアセンブリコード書いたことある?
オフトピだからこれで最後にするけど、x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。
レジスタリネーミングはご存じ?
実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
Re: (スコア:0)
x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。
それでもレジスタアクセスより遅いしコードも長くなりますね。何が言いたいんでしょうか?
レジスタリネーミングはご存じ?
実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
あなたがレジスタリネーミングについて理解されてないことは分かりました。
x86のシステムレベルのアセンブリコード書いたことある?
話題の流れとして何か関係のある話ですか?
Re: (スコア:0)
どうとでもとれる中途半端な書き方をして、明言を避ける。
質問で返して、相手の揚げ足をとろうとする。
知ったかぶり同士の会話は微笑ましいね。
Re: (スコア:0)
実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
あなたがレジスタリネーミングについて理解されてないことは分かりました。
自分も上のACと同じ理解してるけど間違ってるの?
Re: (スコア:0)
x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。
それでもレジスタアクセスより遅いしコードも長くなりますね。何が言いたいんでしょうか?
まあ、これでも読んでくれ
http://yarchive.net/comp/linux/x86.html [yarchive.net]
Re: (スコア:0)
レジスタに割り当てられるデータの数に影響する技術じゃないよ
Re: (スコア:0)
OoOで、同時に使われるレジスタは実質的には増えますが?
Re: (スコア:0)
コード上でのレジスタに割り当てられるデータの数は増えないよ
Re: (スコア:0)
コード上でのレジスタに割り当てられるデータの数は増えないよ
なんだ、トロールか。真面目に聞いて損した。
Re: (スコア:0)
汎用レジスタはいくつくらいあればまあ不足はないかというのを判断するのにRISCもCISCもあんま関係ないのでは?
RISCとCISCで(見かけ上)必要となるレジスタの数が違ってくるのは常識でしょ。
Re: (スコア:0)
いまどきRISCだCISCだなんて話しないでしょ。
Re: (スコア:0)
いまどきRISCだCISCだなんて話しないでしょ。
いや、内部的にやってることが似通ってきても、x86のISAがCISCなのに変わりは無い。
メモリ上の値を(見かけ上は)直接変更できる命令セットと、
レジスタ上にロードしないと何もできないRISCで必要となるレジスタ数が同じと考える方がおかしい。
Re: (スコア:0)
何個から何個かは知らないけれど。
IA-32/x86-64 でのレジスタ増加の効果に対し、ARMで同様に考えようとするのが方向違いなのは分かる。
IA-32のレジスタが少なすぎに対し、ARMはもともとそれなりにある。
ARM が倍になっても、効果がある機会は限られる。
ARMではレジスタ不足のためのロード/ストアがあっても、(IA-32に比すれば)影響が十分小さいんじゃないかな。
CISC/RISCに関係なく IA-32のレジスタ本数は足りてない。
スタックベース命令も多く使われる命令はRISCにも同一機能は用意されているような。
CISC的スタックベース命令って遅い命令が多かったような。今は違うの?
32本のGPRがあってフル活用しても 16本の時と劇的に違うって場合はあまりなさそう(たまにありそう)。
A7は・・・レジスタが 64bit長になったことがうれしいときもあるし、レジスタが増えたことがうれしいときもあると思うよ?
Re: (スコア:0)
アセンブリコードとか言いながらレジスタリネーミングとか片腹痛い
レジスタリネーミングでマシン語プログラミングが楽になったら驚きだ。
あなたの行っている「x86のシステムレベルのアセンブリコード」が プロセッサの実装で、
レジスタリネーミングのついでに命令発行をバイパスしてやったぜ!とか言うなら脱帽ですが。
そうじゃないならレジスタ退避で命令発行ポートストールされてろ
Re: (スコア:0)
x86でも実行効率とメモリ効率の両方を重視すればデータはレジスタ上に置くしかないし、結局は他のアーキテクチャと事情は変わらん。
Re: (スコア:0)
アセンブリコードとか言いながらレジスタリネーミングとか片腹痛い
レジスタリネーミングでマシン語プログラミングが楽になったら驚きだ。
アセンブリコードの件は、x86の作法で書けばそんなにレジスタが要らない理由が分かるはずと思ったんだけどね。
まあ、それでもレジスタリネーミングで楽にはなるよ。適当に書いてもそれなりのパフォーマンスが出るからね。
Re: (スコア:0)
ああ、馬鹿丸出し
Re: (スコア:0)
ああ、馬鹿丸出し
議論する気が無いならもういいけど、反論も出来ないの?
Re: (スコア:0)
x86でも実行効率とメモリ効率の両方を重視すればデータはレジスタ上に置くしかないし、結局は他のアーキテクチャと事情は変わらん。
だから、これ読めって。
http://yarchive.net/comp/linux/x86.html [yarchive.net]
Re: (スコア:0)
別ACだけど横から失礼。
コンパイラって、汎用レジスタが多い方が性能が出るんじゃないの?
最適化の過程でメモリアクセスのコストが一番小さくなるように
汎用レジスタを使い回すコードを吐き出すようになっていても。
そもそもレジスタリネーミング用のレジスタを大量に持っていても、
汎用レジスタと違ってプログラムからは直接指定できないから、
プログラム中の命令はデータアクセスを伴うものが多くなり、
汎用レジスタを多く持つCPUと同等とは言えないのでは?
データアドレスを比較して物理レジスタに割り当てるような
ことまで行っても、プログラムの各ステップで生じたテンポラリの
データは、プログラム的に指示されたアドレスに書き戻さないと、
プログラムとメモリ内容の整合が取れなくなりますから。
Re: (スコア:0)
RISCでもSPARCは汎用レジスタは実質7本扱いじゃなかったっけ?あとはコールスタックとかレジスタウィンドウとかの絡みで色々と面倒な数え方だったかと。
Re: (スコア:0)
ARMより後発のSuperHでも16個
Re: (スコア:0)
汎用レジスタが多いと、割込みやプロセススイッチのときにメモリに退避するデータ量も増えて時間が掛かるしね。
Re: (スコア:0)
そういうのが効率に影響するような用途では汎用レジスタをバンク化して切り替えの効率化図ったりしてるの普通にあるけどね、SuperHも勿論。
SuperHのレジスタ数は
という経緯を経て決まった、みたいな話を20年位前の日エレかなんかで読んだ気がするな。
Re: (スコア:0)
これのことじゃないかな? (Wikipediaより):
> As of March 2014, the Mantle specification and development materials remain unavailable to the general public.
仕様が一般には公開されてないってことだけど、実はまだいろいろ決めてる段階なんじゃないの?
Re: (スコア:0)
だとしても現にそれで動作してるゲームがある状況で「何も定義されてない」はないよねえ。