【CISC】CPUアーキテクチャと論理合成方法【RISC】

x86という圧縮された命令 （記事後半）
http://www.ne.jp/asahi/comp/tarusan/main124.htm
x86命令セットは解凍(可変長命令デコード)の手間が増える反面、
圧縮された命令で記憶されているためキャッシュの利用効率は高い

RISCはCISCの５倍の性能

皆様
ご回答・ご見解ありがとうございます。

もともとは、RISCという響きがなんかかっこいいので、てごろに実装できるSHを触ってみました。
ところが自分なり深く勉強するうち明確な境界が判らなくなり、おもわず聞いてみた次第です。

世間知らずで恐縮ですが、１０年前の感覚、ということは結構あたりまえに議論されていることのようですね。
その議論されている状態を認識した上で各メーカは製品郡を分けているのでしょうか？
私は言葉に弱いので、すぐ食いついちゃいますね。RISCはなんか新しくていいんだろうと。

では、失礼します。

>>274
SHは…いつぞやのHotchipで発表された時、パターソンだかヘネシーだか忘れたが大御所に
「それRISCじゃないだろ?」と突っ込まれた経歴があるのだ(w
もっとも、命令密度の低さ、コードサイズの肥大化は当時は誰もが気にしていた訳で
その後、ARM ThumbやMIPS16等、組み込み向けが16bit化コードを取り込んだ訳だが。

>私は言葉に弱いので、すぐ食いついちゃいますね。

歴史的意義は大きいけれど、既にイメージ狙いのマーケティングトーク化してる。
なんとか2.0と言う奴と一緒で、言った物勝ちって事だな。

国がが軍隊ではない！といえばそれは軍隊ではないのだ。
そして集団的自衛権の定義はトートロジ的に拡大していくのだ。

MIPSやPowerPCなどが出てきて広く注目されただけで、非武装憲法と
自衛隊の違憲問題と同様、RISC/CISC論争は、それ以前からあった。

> 歴史的意義は大きいけれど、既にイメージ狙いのマーケティングトーク化してる。
> なんとか2.0と言う奴と一緒で、言った物勝ちって事だな。

ファジー制御とか、遠赤外線とか、マイナスイオンとか、トルマリン
なんかと似たようなモンだな。

SPARCを忘れんでください。

まんまな名前のPA-RISCは、忘れてください。

Alphaも思い出してあげてください。

つ　FRV400

>>272
それ、たるさんが考えたように書いてあるけれど、嶋正利氏によると
命令セットの設計で当然考慮することらしいよ。

ところで、なんでRISC風の命令セットを圧縮したものを直接実行する
プロセッサがないんだろう。ハフマン圧縮一族なんて所詮テーブル参照だから
x86のデコードよりもずっと展開しやすいはずだし内部コードが
既知である分コンパイラの最適化が直接効きやすいと思うんだけど。

テーブル参照に時間がかかるからだろ。

>>281
RISCとCISCの本質を理解していたら、RISC風の命令セットを圧縮したもの
なんて馬鹿な発想は出てこないはずだ。

>>281 の言う「RISC風の命令セット」って具体的にどんな命令セットだ？

RISCの特徴として、パイプライン処理の効率化とバスアクセスの単純化の
ため、固定命令長を採用している場合が多く、また関数を呼び出しの際に、
コンパイラが多くの引数をレジスタを渡しにできるよう、汎用レジスタを
多くしているため、命令コード中に占めるレジスタを指定するビットフィ
ールドが多くなり、CISCに比べ命令長が長くなる傾向がある。

それに比べ、x86は頻繁に登場するMOV系の命令を中心に、多くは2バイト
命令で、1バイトや3バイトといった奇数バイトの命令もある。

レジスタの少なさと、汎用性のなさ(特定の命令は特定のレジスタを使う)
が欠点と言われてきたが、一次キャッシュの大容量化と、レジスタリマップ
など内部の改良でこれらの欠点は克服されてきた。

CISCの代表である、Z80のブロック転送命令やx86系のストリング系の命令
を採用せず、それらは複数の単純な命令として実行するという発想が本来の
RISCの考え方で、 >>272 は、RISCなら複数命令に展開されるこれらのCISC
固有の命令を「圧縮された命令」と称している。

RISCには存在しないのだから、圧縮のしようがない。

ハフマン圧縮は「圧縮された命令」の比喩であり、ハフマン圧縮それ自体
の処理速度や速度比較ではない点をまったく理解していない、 >>281 の
理解力のなさだけが、とても痛い。

いいこと言った

今日一番感動した

パイプライン２５段

それくらい深ければクロックは5GHzくらいいけるかのう。

　x86 に限らず最近のプロセッサでは内部でより小さな(RISC風)命令に
変換されて実行されていることを>>283 は知らないようだが大丈夫
だろうか。>>272 の引用先に詳しく書いてあるので参照しておくれ。

　>>281 は、仮に x86 内部で使用されているμOPをコンパイラで直接
合成してしまい、それを例えばハフマン圧縮したものを直接プロセッサに
食わせたらどうだろうかという話なんだよね。もちろんそのまんまだと
ジャンプ命令などで問題が出て来るけれど、その辺はおいとくとして、
メモリ上のバイナリが x86 デコーダを経由してμOPに変換されるのと、
ハフマンデコーダを経由してμOPに変換されるのとではどっちが効率が
いいだろう。

　試したわけではないので単なる推定だけれど、ロジックの規模は
「所詮テーブル参照」であるハフマンデコーダの方が小さいだろう。
最適化はどうかというと、最終行に書いたようにハードで動的に最適化
するよりもソフトで最適化した方が一般的には効率がいいだろう。
メモリの使用効率はというと、「圧縮された命令セット」とはいっても
専用の圧縮アルゴリズムにはかなわないだろう。

　にもかかわらずそんなプロセッサが実験的にも存在しないということは
これらのメリットを全く帳消しにしてしまうような大きなデメリットが
あるからで、それは何だろうというお話なんだよね。分かってもらえた?

>>288
RISC的にしろなんにしろ、高速に実行可能な命令セットを下手に人の手等でx86の様に纏めず、
何らかの数学的圧縮するというアイデア自体は悪くないと思うのだが…

一つだけ。
そこでx86を持ち出すのは意味が無い。
x86のメリットは、x86である事、その事実に尽きるから。

どうでもいいが、レジスタリネーミングは
x86の恥ずかしい部分だと思ってるぞ。
論理レジスタがたくさんあれば、そもそも必要ないという意味でね。

別に恥ずかしくなんかないじゃん。
過去の資産を活かす現実的な解でしょ。
もちろんRISC系の命令セットだったら
もっと有意義なことにリソース使えるのにというもったいない感はあるが。

>>291
いや、それは分かっているんだが、
これのせいでトランジスタとある程度のクロック数
(レジスタリネーミングそのものを行うクロック数ね）
が犠牲になることを考えると、
なんだかなぁ、という感じ。

命令セットの関係で論理レジスタが増やせないとか、
過去の負債を引きずってるだけだろ。
もちろん、それが現実的な解決策だってことは十分分かっているんだが
「命令セットのせいで、それくらいしか解決方法が無いんだろ」
と、いつも思ってしまう。

CPUとプログラムまとめて論理合成しちゃってFPGAに食わせる

普通にCPUとプログラム入りメモリが合成される悪寒

>>290-292
　確かに x86 の場合は設計の悪さをカバーするためのテクニックという印象が
強いけれど、レジスタが腐るほどたくさんある IA-64 みたいなプロセッサでも
レジスタリネーミングは有効な場合があるよ。例えばレジスタ r1 を使用する
場所に複数の所からジャンプしてくる場合において、ジャンプ元で r1 を使って
いる可能性がある、
　　move r1,address1・・・*1
　　jump L1
〜〜〜〜
　　move r2,address2・・・*2
　　jump L1
〜〜〜〜
L1: move address3,r1・・・*3
　　move r1,address4
というようなコードがあった場合、*2 と *3 は並列実行が可能だが、*1 と *3 は
レジスタリネーミングがないと並列実行は出来ない。*3 の直前に実行されるのが
*1 か *2 かは実行時にならないと分からないのでコンパイラでの最適化はあまり
期待できない。(jump は遅延分機命令で *1,2 と *3 はパイプライン上で隣接して
いると思ってください)

P.S.
>>282 テーブル参照にかかる時間は一時キャッシュの読み書きにかかる時間と
同程度だからデコードと参照にそれぞれ 1〜2 クロックぐらいのレイテンシが
つくぐらいだと思うんだけどどうだろう。

>>289 確かに x86 のメリットは x86 だから、ということに尽きるんだけど、
>>272 の参照先で x86 の圧縮された云々という解説をしていたもので…。

>>281
そういったコードで、本当にレジスタが腐るほどあるなら、
最近のコンパイラではほぼ間違いなく
L1: move address3,r1・・・*3
　　move r3, address4
というふうにコンパイルされるから、
あまり問題にはならないはず。
(８つの論理レジスタを適切にレジスタ割付すようような
コンパイラがこんなコードを生成するはずがない)

もちろん、インラインアセンブラで書いてるとかなら別だけど、
その効果はほんとにわずかなものだと思う。
その証拠にIA-64では実際にレジスタリネーミングをしない。

>>281
あと、デコードのテーブル参照にそれぞれ１〜２クロックのペナルティがつくのは
addのレイテンシが１〜２、movが1〜３だということを考えると
全然話にならないと数字だと思う。

>>296
一度にコンパイルするならそうだろうけれど、分割コンパイルやライブラリ化されてると無理なんじゃ?
リンクする時に入れ替える手もあるけど、それじゃ静的な物に留まる訳で…
OSがロードする時にレジスタ再割付でもしてくれるなら…

>>295の言うテーブルって例えばコンテキストごとに異なる動的なテーブル？
だとしたらコンテキストスイッチ遅そうだね。
静的なテーブルだったらマイクロプログラムみたいなもんだし。

魔法、それ即ちレジスタリネーミング
http://www.geocities.co.jp/SiliconValley-Bay/9439/negoto/ngt036.htm
http://www.geocities.co.jp/SiliconValley-Bay/9439/negoto/ngt037.htm

>>298
IA-64だとレジスタスタックなるものを用意して、
関数の呼び出し元と関数本体で
レジスタ名がバッティングしないような工夫がされているらしいです。

>>300
> レジスタリネーミングを行うCPUは物理レジスタを、
> プログラミングモデルが提供する論理レジスタよりたくさん用意することによって、
> 積極的なレジスタ名の変更を可能にします。
x86の場合、この比が 8 : 128 とかだよ。
ちょっと積極的すぎやしないかい？

>>296-298
　自分で書いといてなんだけど、
>その効果はほんとにわずかなものだと思う。
これはそう思う。静的に解析できるものは可能な限りコンパイラで
やるべきだと思うけれど静的解析が出来ない一例ということで。
>>297
　デコードはパイプラインハザードを発生しないのでレイテンシは
キャッシュミスと分岐予測ミス時にしか見えないと思う。
>>299
　圧縮率を上げようとするとキャッシュのラインごととか、もっと
細かい単位になると思う。コンテキストスイッチに限らず遠くへ
分岐した際にテーブルのリフィルにはコストがかかる(>>288 で
置いといた問題)。これをどの程度まで低減できるかはよく分から
ないが、合計したコードサイズが減るのなら収支は黒字のはず?(怪)。
　もっとも期待はコードサイズ削減よりもスケジューリングを
コンパイラでやることによるパイプラインの簡素化なんだけどね。

>>301
　リネーミングのロジックにかかる負担をレジスタの多さでカバー
しているのかも(根拠なし)。
　RISC のレジスタ数はコストのかかるメモリアクセスを避けるために
ローカル変数をほぼ十分割り付けられる数が根拠になっているので
レジスタを無駄なく使うと余りまくると思う。

MIPSの32個程度じゃローカル変数全部入れるには足りないと思うが。
規約で実質半分ぐらいしか汎用に使えないし。

>>302
論旨をあまり理解していないのでこれは的外れかもしれないが、
>>288でいっているような、
> μOPをコンパイラで直接合成してしまい、
> それを例えばハフマン圧縮したものを直接プロセッサに
> 食わせたらどうだろうかという話なんだよね。
という話だったら、それは間違いなく愚か。
μOPの仕様はIntelのプロセッサによっても違うし、
当然AMDやTransmetaのCPUとは互換性はない。
すべてのCPUを識別して、適切な命令を合成するの？

>>303
演算に使えるのは実質4〜5程度なので、
それ以上の値を同時に扱おうとするとL1様に登場して頂くしか無くなる。
これはレジスタリネーミングが無力化するいい例だと思う。
レジスタは、足りないよりは余った方がいいに決まっている。

ムダに論理レジスタ数が多いRISCアーキテクチャは、命令コードに占める
レジスタ指定のビットフィールドが広くなり、固定命令長にこだわるため
CISCなら1バイトや2バイトで済む命令コードが4バイトになる。

CISCもRISCも一時キャッシュや二次キャッシュの容量は、大差ないので、
命令長が短いCISCの方が、より多くの命令数(プログラムステップ数)を
キャッシュに格納でき、その分ヒット率も上がり、RISCに比べてキャッ
シュの利用効率が高い。

外部バスへのアクセスで比較しても、バスの転送レートはRISC/CISCに関係
なく、メモリアーキテクチャに依存し、同じメモリならRISCもCISCも、バス
の転送レートは同等なので、命令長が短いCISCの方が、少ないバスアクセス
で、効率よく命令を取り込むことができる。

どこまで将来のことを考えていたかは不明だが、x86はよくできたCPUだよ。

>>305
途中が欠損したLZHファイルから、欠損ブロック以降のデータを復元でき
ないのと同様、任意の場所から復元可能な効率の良い圧縮方法など存在し
ない。

それに、出現度の高い命令のコードが短くなるようにOPコードマップを設計
するのはごく当たり前。だから、最適化されたOPコードをハフマンごときで
圧縮する効果はない。

それは、複数の圧縮方法を組み合わせるLZHやZIPを使ってさえも、EXEファ
イルは圧縮後のサイズが小さくならないことからも明らか。

>>306
今のx86は内部でCISCなコードをRISCなコードに展開して（例外的に展開しない場合もありますが^^）
つまり固定長バイトの命令として実行＆キャッシュに保存しています。
これはいいですよね？

RISCのレジスタがなぜ多いかというと、アウトオブオーダー実行や
並列実行させやすくなるためというのが主な理由だと思うのですが、
当然x86も内部ではそれと同じことをしているわけです。
つまり、「RISC＝レジスタ数が多い方がいい」という説を信じるのであれば
今のx86でも論理レジスタ数は多い方が自然だと考えるのでは無いでしょうか？
命令のバイト数が少し増えてもデコーダの拡張により将来的な速度アップが期待できますが
命令フォーマットの関係でレジスタ数が制限されてしまうと、どうしようもありません。
また、物理レジスタの数がいかに多くても、
論理レジスタ：物理レジスタが8:128のようないびつな環境では
>>305のようにレジスタリネーミングだけでは対応できない場面というのが当然出てきます。

また、x86も内部では固定長バイトとして命令をキャッシュしているため
特に命令１次キャッシュの効率は他のRISCプロセッサと大して変わりません。

あと、ちょっと気になったのですが、
lzhやzipは圧縮方法としてはかなり効率が悪い方です。
実際にupxなどを使えば実行ファイルでもある程度は圧縮できますよ。

>>306
>EXEファイルは圧縮後のサイズが小さくならないことからも明らか。

UPXとか既に使われてるんじゃ?
DOS時代だとDIETとかLZEXEとかそれなりに使われていたし
x86でも一定の効果はあるよ?

それはともかく、今利用されているARMとかは、レジスタ数とか命令セットの制限をした上で圧縮してる訳だから
利用可能なレジスタ数等を制限せずに圧縮できるのなら意味はあるんじゃないかな?

>>307
>つまり固定長バイトの命令として実行＆キャッシュに保存しています。

x86だと展開した命令をキャッシュに保存してるのは、トランスメタを除けば
トレースキャッシュを公言していたネットバースト系アーキテクチャだけじゃないかな。

RISC優位論者が、あくまでRISC優位という方向に論点を持っていきたい
だけの気がするなぁ。

「古臭い」「時代遅れ」「いびつ」などというx86アーキテクチャを超える
RISCプロセッサが出現しないことが、RISCこそが「古臭い」「時代遅れ」
の考え方だということを証明している。

RISCのレジスタが多いのは、今ほどコンパイラの最適化が進んでいなかった
時代に、てんこもりの汎用レジスタを用意すれば、コンパイラによる最適化
なしでも高速化できるだろうという安易な発想が原点にある。

論理レジスタ数は、CPUアーキテクチャに依存する。32bitモードの導入で
レジスタ自体の汎用化は進んだが、バイナリ互換のx86は、論理レジスタ数
は今も昔も変わっていない。

x86で固定長なのは命令デコーダを通った実行ユニットのパイプラインの
中だけ。命令キャッシュや二次キャッシュは、x86のコードのままのはずだ。
そうでなければ、キャッシュのヒット率や利用効率が大幅に下がる。

FPU命令を除外しても、x86の命令は最小で1バイト、プリフィックスを含め
れば最大で10バイト以上になるんだが、命令キャッシュに固定長で記憶され
ていると言うなら、何バイトだと？

整数系の命令だと、たぶん32bitのイミディエイト値を、オフセット付きで
レジスタ間接参照されるメモリに書き込んだり、演算したりする命令あたり
が一番長くなるはず。

308
> DOS時代だとDIETとかLZEXEとかそれなりに使われていたし

DIETや、LZEXEが効くのは ...

static int buf[3000];

のように、スタティックに大量のデータ領域を宣言した場合、昔のリンカ
は、0x00で埋めつくされたデータ領域を含むEXEファイルを吐いていたので、
そうした領域が多いプログラムが圧縮できただけ。

純粋な実行コードに対しては、ほとんど圧縮は効きません。

初期化してない変数にアクセスしても、初期値は0x00と保証されていると
勘違いしているプログラマもいたな。今でも居そうだが。

>>309
x86アーキが生き残って、のさばっているのはx86アーキがすばらしいからじゃない。
IBM-PCからのソフト資産の問題でしょ。

RISCの数を揃えた汎用レジスタって、まるで社員数ばかり多けど能無し
揃いで、上から指示された単純命令しかこなせない、日本の大企業みたい。

社員あたりの生産性の低さを数でカバー？

エミュの技術も進歩した現在、x86を超えるアーキテクチャのRISCが出現
しないのはなぜ？　それに、IBM-PCのハードに依存するようなソフト
なんて、今じゃほとんど使われていないでしょ。

>>312
　まあ、落ち着けって。

　まず、x86 のファイルをさらに圧縮して実行なんて話はしていないぞ。
μOP を持ち出したから混乱したのかなあ。じゃあ例えば SPARC のコードを
L2 cache までは圧縮して格納し、L1 からは元の SPARC コードに展開して
実行するといったら分かるかな。NetBurst と同じ構造だ。SPARC の
コードは x86 よりも圧縮が効くということに同意していただければ
キャッシュに圧縮したまま格納することによるキャッシュやバスの有効
利用にも同意してもらえると思う。

　それから、>>306 の任意の場所から復元できる圧縮方法なら存在するぞ。
完全に任意ではないが。例えば 100 個のファイルを tar してから gzip
すると任意のファイルをそのまま復元することは出来ないが、100 個の
ファイルを圧縮してから tar でまとめると任意のファイルを復元できる。
圧縮率は悪くなるが分割単位を大きく取ればとてつもなく悪くなるわけ
ではない。簡単に実験できるので色々試してみればよい。だから >>302 で
キャッシュのラインごととか、と書いたわけ。

　あと、>>309
>RISCのレジスタが多いのは、今ほどコンパイラの最適化が進んでいなかった
　　　　:
>なしでも高速化できるだろうという安易な発想が原点にある。
ちがいます。

なんかx86マンセーなのが多いな（あるいは声がでかいだけか）
先祖の遺産があったから巨額の投資ができてまだ生き残ってるってだけでしょ
たぶんまだかなり生き続けると思うけど

>>309
自分には、x86優位論者がx86は他のRISCプロセッサよりもすばらしいという
結論に持って行きたいだけのように見えます。

> RISC優位論者が、あくまでRISC優位という方向に論点を持っていきたい
> だけの気がするなぁ。
そもそも、今のx86が内部で命令をμOP単位で実行していることから見ても
多くの技術者がRISCの優位性をある程度認めているということでは？
少なくともx86自体は、決してすばらしいといえるものではないと思うのですが。

> 「古臭い」「時代遅れ」「いびつ」などというx86アーキテクチャを超える
> RISCプロセッサが出現しないことが、RISCこそが「古臭い」「時代遅れ」
> の考え方だということを証明している。
二つ言いたいことがあります。
まず一つ目は、今のx86はほぼRISCみたいなものなので、
言っていることが微妙に的外れということです。
IntelやAMDがRISC的なものを取り入れたことから考えても、
RISCにはある程度の優位性があるのでは無いでしょうか？
またもう一つは、例えば最近作られたCELLはRISC型プロセッサですし
IBMが作っているPower6もクロック数4〜5GHzで動くRISC型アーキテクチャです。
これらが完全にx86系CPU（x86が動くどのCPUでも構いません）に
劣っているという根拠はいったいどこから出てくるのでしょうか？
x86の場合だって過去のソフトウェア資産があったからこそ今があるようなものですし、
一般PC市場を席捲しなければその実力が認められない、と言った見方はあまりにも狭量です。

> RISCのレジスタが多いのは、今ほどコンパイラの最適化が進んでいなかった
> 時代に、てんこもりの汎用レジスタを用意すれば、コンパイラによる最適化
> なしでも高速化できるだろうという安易な発想が原点にある。
Intel自身でさえも、これから新規アーキテクチャを作る場合は
レジスタ数を８などにはしないでしょう。
実際、IA-６４のレジスタ数は１２８です。
ＣＥＬＬのレジスタ数も同じです。
それはいったい何故なのでしょうか？
コンパイラ技術のせいなのでしょうか？

> x86で固定長なのは命令デコーダを通った実行ユニットのパイプラインの
> 中だけ。命令キャッシュや二次キャッシュは、x86のコードのままのはずだ。
> そうでなければ、キャッシュのヒット率や利用効率が大幅に下がる。
ネットバースト系のアーキテクチャを調べてみてください。
「トレースキャッシュ」という単語が出てくるはずです。
キャッシュ効率が下がるのは事実ですが、
２回目以降の実行ではデコードの必要が無くなります。

> FPU命令を除外しても、x86の命令は最小で1バイト、プリフィックスを含め
> れば最大で10バイト以上になるんだが、命令キャッシュに固定長で記憶され
> ていると言うなら、何バイトだと？
それ、自分も書こうと思ったのですが１０バイト以上の命令はかなり稀なものなので
例外的に扱って構わないと思います。
というか、Intelの次期CPU,Penrynでもフェッチ帯域は１６バイト/クロックなので
そんな命令が頻発されたら、キャッシュ能力の如何にかかわらずほとんど性能が出ません。
（Pentium4のμＯＰのサイズは、調べたのですが分かりませんでした。すいません）

IA-64とかCELLとかのゴミを例に出さんも

CELLはともかく、IA-64って駄目CPUなんですか？
なんかRadeonHD 2900もVLIW採用でイマイチらしいので、
VLIW技術自体が無謀なんでしょうか？

>>317
IA64自体はダメって訳じゃ無い。
最初のモデルはIA32代替としては期待外れな性能だったがFPU性能は強力。
数値演算目的だったら強力なCPUだ。

古いIA32ソフトが高速に動くCPUでは無いから、
単純なIA32の置き換え、という目的には意味無いけど…。

VLIWだからダメ、というのは意味が薄い議論だ。

まだ周辺技術がこなれてないというのはあるんでないかい。

命令詰め込むための静的解析とか。

>>317
　おそらく >>319 が正しい。ハードが楽するのならその分ソフトが
苦労しなければなりません。VLIW は RISC よりもハードの負担を
減らした方式だからコンパイラの最適化が極めて重要だが数値計算の
ようなある程度決まりきったパターンの命令列ではない一般アプリの
場合まだ十分な最適化技術が確立していないと聞いています。その点
GPU などの用途では比較的性能を出しやすいでしょう。
　またコンパイラの最適化がしやすい命令セットというのもありますから、
将来最適化の技術が進んだ場合 IA-64 の命令セットに不満が出てくる
可能性は十分あります。

論理合成前のシミュレーションでは正常に動作したのですが
その後のはまともに動かないんじゃあ
誰かﾎﾞｽｹﾃ
あ

あるある。

>>321
　クロック周波数を落としても大丈夫な回路なら(DRAM などはクロックを
落とすとリフレッシュ間隔がのびて×)ぎりぎりまでクロックを落として
みたら? それで動くならタイミングシミュレーションで何か見落としが
あるか、バスが重すぎてシミュレートした仮定条件を満たしていないなどを
疑う。クロックを落としても動かないならそもそもボードにバグや配線
ミスなどがあるとか。

さんくす
がんばってみます

やっとMIPS I命令真似た自作CPUがFPGAで動かせたよ
このスレのレベルからしたら低レベルだけど
嬉しかったので記念ｶｷｺw

いまならV８５０が２００円

タダでもいらね

>>326
kwsk

ハードウェアシミュレータをハード化すると現物より速いのか？

最適化次第

>>329
そいつは用途次第じゃないかな。
ソフト書き直しじゃ不味いって用途向けに実装する場合は、
速度だけじゃなくて実行タイミングなんかも現物と一緒じゃないと不味いって場合も多いだろう。

名前が思い出せないのでソースが提示できませんが、算術的に圧縮された
命令ストリームを読み取って、内部的に元の命令ストリームに展開しつつ実行する
MPUは過去に存在しました。

すごいな

遅延分岐がパイプライン処理にとってどういう利益があるのかよくわからないのですが
どなたか解説お願いします。

JUMP a
LOAD b,x

こんな場合、JUMPを実行する前にLOADを実行しちゃうんでしょうか？

無条件分岐なら遅延分岐はしない。
条件付JUMPなら、分岐するって解ったらLOAD命令の実行を途中で中止する。

ともかく実行しちゃうタイプのCPUもあるよねぇ。

>>334
JUMP命令のデコードをした時点で、既にLOAD命令が実行にとりかかっている
んで、待った！をかけるよりも
「やりかけた仕事は最後までやってしまえ」というほうが設計上楽ができるわけ

>>334
利益???それは思考の順序が違う。

パイプライン動作を導入すると遅延分岐動作になる実装設計があり、
その場合、遅延分岐にならないようするには追加の回路が必要になるので
回路規模が大きくなって、ついでに速度が落ちるかもね、という事。

(遅延分岐にならないようにする回路を用意せず)遅延分岐をそのままにしておいても、
遅延分岐動作そのものは不都合にならないケースが多いので
追加回路を入れるか入れないかはトレードオフであり心情の問題でもある。

>追加回路を入れるか入れないかはトレードオフ

つまり、何らかの不利益と引き換えに何らかの利益があるわけだな。

皆さんどうもです
ソフトから入ってきてるんで順序が逆だったみたいですね
有益＜回路が楽
と考えると自ずと答えが出るわけですかｗ

要するに遅延分岐はパイプラインバブルの有益な解決方法じゃなく設計が楽になるだけで
エレガントに実行したい場合は分岐予測なんかと組み合わせなさい　ってことなんでしょうか

そもそも、そのあたりはコンパイラとセットであって、アセンブラで書く
ことは二の次なんよ。
ハードウェアは単純化して性能／コスト（ロジックの量）がなるべく
大きくなるようにして、その単純なハードウェアをうまく動かすように
コード生成する（遅延分岐もそうだし、実行順序の入れ替えなんかも）
というのがコンパイラのお仕事。

そもそも分岐なんかいらんわ

>>339
>つまり、何らかの不利益と引き換えに何らかの利益があるわけだな。

遅延分岐動作をさせない、最大のメリットはアセンブラソースが見やすくなる事でしょう。
大抵の人は普通の動作に慣れてる訳だから。

ソースっか

ソースねえ
ttp://www.vdec.u-tokyo.ac.jp/

ソースっと？

しょうゆうこと。
ttp://www.opensparc.net/

CPUは、分岐時、分岐先の命令がCPUに到着するまで、
パイプラインが停止（ストール）しちゃうのね。
このCPUストールの無駄時間がもったいないから、
この間、なにか命令を実行しちゃえってのが遅延分岐の考え。

でも昨今のCPUは優柔な分岐予測を備えてるから、
遅延分岐はもはやアーキテクチャ的な盲腸ともいえる。

遅延分岐なしのCPU
(1)分岐命令を実行
(2)CPUストール
(3)分岐ターゲット命令を実行

遅延分岐ありのCPU
(1)分岐命令を実行
(2)遅延分岐スロットの命令を実行
(3)分岐ターゲット命令を実行

ninja

nanja

monjya

× monjya
○ monja

monja-yaki

おまえらopensparcのソース読んだりするの??

役目を終えたCPUに用は無い

Oh, is the CPU it in your brain?

学習の為に16bit固定長命令（OPコード5bitオペランド11bit）のCPU作ってみようと思うんだけど、
普通のCPUの命令セットってどの辺揃えておけばいいのかな？
x86みたいにごっちゃごちゃにはしたくないし。

レジスタ間コピー、加減算、AND、OR、XOR、NOT、
左右論理シフト、左右算術シフト、即値格納、メモリ読み書き、
レジスタ間比較、条件ジャンプ（A>B,A<B,ZFlag=1,ZFlag=0）、無条件ジャンプ、停止

あと何か必要？
それと、符号付演算って必要だと思う？

現段階の案では正確に言うと左右算術シフトじゃなくてキャリー付き左右論理シフト
だった

call return は？

PCが汎用レジスタ扱いなのかどうか、
スタックポインタやリンクレジスタがあるのかどうか、など
プログラミングモデルの構想も聞きたい。
分岐命令やメモりアクセス命令は
プログラミングモデルと合わせて考える必要があると思う。

割り込み

命令体系を単純化してオペコードを縮小するには、
PCとSPも汎用レジスタにするのが良いんじゃないの。

レジスタ間コピーとかロード命令でジャンプできる。

もっとも、条件分岐命令に関しては逆に深刻な制限になってしまうから
むしろ薦めにくいのかも。

数ビットの小さなオフセットだけ対応の近距離条件分岐しか条件分岐を装備しないなら良いが。

って、PICの条件分岐命令がこんな感じだっけ?

SPが汎用レジスタ、ってのは結構いろいろあった気はする。68kもそれに近い。

条件成立したら次の命令をスキップする命令てのがあって
無条件分岐と組み合わせると条件分岐できます

てのがどこかにあったな。

>362
H8もそーだお

いっそ、みんな条件付実行にしちゃえ、っていうARMみたいなのもある。

16ビットじゃきついだろｗ

脱線スマソｗ

条件付き実行するかしないか指定するだけなら
１ビットで足りるから、命令長１６ビットでも実現可能。

>365-366
それ、ARMの基本命令セットが32ビット固定だったから可能になったんだよな。
16ビットに縮小したThumb命令セットでは条件分岐命令以外の命令は条件判断しないよ。

>368
どういうフラグの組み合わせで実行するかどうかを決める関係上、条件フィールドは4ビットぐらい使うのが普通だし。

>>369
SHみたく比較の方にフラグ立てる条件をいれてしまえば、
判断する方は1ビットですむべ。

>>369
＞>368
＞どういうフラグの組み合わせで実行するかどうかを決める関係上、条件フィールドは4ビット
＞ぐらい使うのが普通だし。

コンディションコードがＮＺＣＶあるＡＲＭだからそうなのであって
１ビットコンディションフラグで済ませれば条件フィールドは不要。

>370-371
俺が知ってる限られた数のCPUアーキテクチャでは、
どれも4〜5ビットぐらいのフラグがあったから、それが普通だと思ってたよ。

だが確かに、370の考え方なら1ビットのフラグでも足りそうだな。

今までは俺の世界が狭く、頭が固かったってことか、�dｸｽ

>>357はどこに行ったんだろう。

じゃあほっといて、学習用16bitアーキテクチャ作ってみないか

40ピンにこだわる？

今日日の学習用なら多少リッチなほうがいいんじゃないか
>>360みたいなのは最適化の第一歩くらい

>>357から半月近くも経っているし
RTLが既に完成していてもおかしくないわけだが

このスレ、初めて来たんだが、誰か実際に作った人はいるの？
シミュレーションだけでも良いから。

>>378
RTLシミュレーションとFPGAで動作検証して
チップもかれこれ５種類くらい作りましたよ
180nと90nで。

CPU作ること自体は大したことではないです。
どちらかというとソフト開発環境を整備する方が手間。

勉強になる。

>>379
GNU のアセンブラー・デバッガー (gas, gdb) なんかは、
カスタム CPU 対応が可能です。「GNU gas custom CPU」とかで Web 検索。
そこまで進めたら gcc も、もう一息かな？
一人で全部やるのはスゲたいへんそう。何人かのグループでやれば可能だろうね。

アセンブラーだけならゼロから作ってもいいし、
awk なんかの力も借りて、それでは困難な部分は pre-process, post-process
する方法もアリかなぁ。

まっ，>381ががんばることに期待しておく

>>381
もちろんGNUの開発ツール群をカスタマイズして使っています。
eclipseにも対応させました。

>>383
じゃあ、さしあたって、なにが困っているの？　それを聞きたい。

もしか「し」 (shi) て「早く動かない」のかなー。
バカすぎて、とてもごめん。でもいちおうは、一応はレスしておく。

>>384
383=379 は困っているとは一言も書いていないのだが。
378 の呼びかけに答えただけで。

CPU造ってみたい。
どうやるのかな。
リスクはレジスタたくさん作るの？

実用性考えないなら、レジスタ4個ぐらいでも動くんじゃない？

レジスタ無しでも制御系には十分使える。

金銭登録機無しでも商売はできる。ホンと、だじゃれが多いな。

なぜレジスターを一本二本とか数えるのだろうか。その起源を知ってる人、ぜひ教えて下さい。

長いからじゃね？

>>389
387はRISCって言ってるからな。レジスタ無しはちょっと

＞393
レジスターはメモリー割り付ける。何が困るの。

その昔、N 社の次期 CPU の概念図を見せられたことがあった。
当人はすげー革新的だと思ったんだろうが、
この板的には、異論がごうごうだろな。

>>394
なんとなくわかるような。命令デコーダーをどうするか。
多段パイプラインを使えば、どーでもよくなるような。もっとぶってね。

>>レジスターはメモリー割り付ける。何が困るの。

それをRISCと呼ぶと苦情が殺到して困るんだろう。
多分だけどな。

>>391
そろばんのイメージかね

もっと単純に、マニュアルに棒で描かれてたからか

>394
レジスタをメモリとして実装する。

古く懐かしい、「縮小命令コンピュータ」(と呼ぶのかね? 命令体系ではなく。)たる、
初期の組み込み用CPUの典型じゃないの。

たとえば、256バイトぐらいのオンチップメモリを積んで、その先頭もしくは末尾の数バイトがレジスタ。
アーキテクチャによっては、裏レジスタを実装してる例もあった。

もちろん、あくまでもローカルメモリであるから、インデックスレジスタを用いた間接アドレシングでのアクセスもできる。

今でも、小規模向けのマイコンの中には、そういうローカルメモリが付いてるヤツが残ってるかも。

　現役バリバリの AVRは 基本CPI=1 の RISCで、汎用レジスタ32本が
データメモリ先頭 0x0000-0x001F にも割り付けられてるから、
LD/ST命令で間接アクセスできるよ

>>399
それもうEDSAC/Manchester Mark Iあたりからのデザイン

>>399
>今でも、小規模向けのマイコンの中には、そういうローカルメモリが付いてるヤツが残ってるかも。

8051は未だに改良品が作られ新規採用される現役です。

誰かデータフローマシンについて詳しい奴はいないか？
原理的に最高の並列性が出せるらしいが、古い研究なのであまり資料がない。
特に欠点について知りたい。

>>399
> レジスタをメモリとして実装する。

そもそも、ミニコンのPDP-11あたりとか、データゼネラルとか、そうでは
なかったかと。　マイコンの世界でもTIの初期のTMS9900だったかの16bit
なんかも。　あと、昔AMDが得意だったビットスライスとか。

>>402
> 8051は未だに改良品が作られ新規採用される現役です。

昔は12MHzそこらで、1命令実行するのに、最低でも4クロックくらい掛かっ
ていたのが、今じゃ100MHzで1クロックだもんな。　あくまでバイナリ互換
ってだけで中身はまったく別物。

所詮、最新マイクロプロセッサに実装される技術の多くは、大型やミニコン
で実用化されていた技術をシリコン上に取り込んでいるだけでそ。

>>404
当たっているのは、TIだけですねｗ

>>403
弓場敏嗣　山口喜教　「データ駆動型並列計算機」

説明すんのメンドクサイから↑でも読め。
それで足りなきゃ、巻末のリファレンスから文献拾え。

>>405
これだけ外しているのも珍しいよな

>>403
>>406の人たちの作ったものでいうと
演算ユニット→ネットワーク→演算ユニットとデータが回るわけだが、ネットワークの遅延が大きい
マッチングストアというレジスタと命令キューを兼ねたようなユニットがあるんだが、高コストにつく
基本的に副作用のない関数型言語を動かすことしか考えていなくて、
Cのように自由にメモリに書き込みを出来る言語では制御トークンを用いて逐次化しないといけない。これならPCで制御したほうがいいじゃんとなる
使用済みのリソースを解放するのにやっぱり制御トークンを用いて逐次化する。これならPCで以下略
基本的に例外処理ができない

そのままでは欠点だらけで到底実用的ではないけど、今のスーパースカラプロセッサはデータフローマシンにとても近いよ

> 所詮、最新マイクロプロセッサに実装される技術の多くは、大型やミニコン
> で実用化されていた技術をシリコン上に取り込んでいるだけでそ。

大型機由来の技術はいろいろあるが、ミニコン由来のってなんかあったかな
貧弱なバスくらいか

なんにしろ「取り込んでいるだけ」ってこたぁない

>>406
サンクス。
でもちょっと古い本だな。

だが、データフローマシンに関してまとまった内容の日本語の成書は多分それしかない。
基本的に著者が関わった機械についての簡単な解説なんだが、DFMとしてそんなに癖の
あるアーキテクチャじゃないから理解するのにそれほど苦労しないと思うし、（NECの画像
処理用LSIは酷かったｗ）、自分たちの機械に関連してDF全体についても触れてるから、
最初に読むには今のところそれが一番いいと思う。で、興味を持ったら巻末の書誌からCiNii
ででも論文をあさればいいと思う。

つか、多分この本が出て以降DFについてはあまり進展が無いと思う。まあ、アマチュアだし
サーベイをちゃんとしてるわけじゃないから確約は出来ないが。

だって(狭義の)データフローなんて80年代で滅びたんだもん
マルチスレッドに移行してこれも滅びた

>>410
馬場先生のがある
洋書はGaoとGaudiotのくらい

俺にアンカーつけられても困る。
つか、>>403にその本紹介してやれよ。

その昔、タイトルに"データフロー"と付いた本を読んだ記憶があるが、
ざっと検索するにたぶん
曽和将容『データフローマシンと言語』
かな。 >406より古い本だ。

>>412
お、何か気に障ったか？ww

>>413
東大の坂井先生に、その著者は癖があるので気をつけろと
言われたことがある。過去に何かあったんだろうか？

曽和先生は変人という話だが、実物は見たことない(←小ネタ)のでわからない

【質問１】

　RTL compiler で論理合成をしています。
　クロックラインへのバッファー挿入ケアが全くされず
　に困っています。クロックラインへファンアウト調整
　用のバッファーを挿入させたネットリストを生成する
　にはどのようにすればよいでしょうか？

　勝手にset_dont_touck_network clock がかかっていて
　どうしても解除できません。

　不可能であるなら、design compiler へ移行いたします。

　
【質問２】

　RTL compiler で論理合成をしています。
　データラインへのホールド調整を行うにはどのように
　すればよいでしょうか。

　set_fix_hold ができません。

　不可能であるなら、design compiler へ移行いたします。

なぜサポート窓口に質問しないのか不思議だ。
そのために馬鹿高い保守料払ってるのに。

何か不自由な人の可能性が高い

【質問１】

　RTL compiler で論理合成をしています。
　クロックラインへのバッファー挿入ケアが全くされず
　に困っています。クロックラインへファンアウト調整
　用のバッファーを挿入させたネットリストを生成する
　にはどのようにすればよいでしょうか？

　勝手にset_dont_touck_network clock がかかっていて
　どうしても解除できません。

　不可能であるなら、design compiler へ移行いたします。

　
【質問２】

　RTL compiler で論理合成をしています。
　データラインへのホールド調整を行うにはどのように
　すればよいでしょうか。

　set_fix_hold ができません。

　不可能であるなら、design compiler へ移行いたします。

【質問１】

　RTL compiler で論理合成をしています。
　クロックラインへのバッファー挿入ケアが全くされず
　に困っています。クロックラインへファンアウト調整
　用のバッファーを挿入させたネットリストを生成する
　にはどのようにすればよいでしょうか？

　勝手にset_dont_touck_network clock がかかっていて
　どうしても解除できません。

　不可能であるなら、design compiler へ移行いたします。

　
【質問２】

　RTL compiler で論理合成をしています。
　データラインへのホールド調整を行うにはどのように
　すればよいでしょうか。

　set_fix_hold ができません。

　不可能であるなら、design compiler へ移行いたします。

【質問１】

　RTL compiler で論理合成をしています。
　クロックラインへのバッファー挿入ケアが全くされず
　に困っています。クロックラインへファンアウト調整
　用のバッファーを挿入させたネットリストを生成する
　にはどのようにすればよいでしょうか？

　勝手にset_dont_touck_network clock がかかっていて
　どうしても解除できません。

　不可能であるなら、design compiler へ移行いたします。

　
【質問２】

　RTL compiler で論理合成をしています。
　データラインへのホールド調整を行うにはどのように
　すればよいでしょうか。

　set_fix_hold ができません。

　不可能であるなら、design compiler へ移行いたします。

【質問１】

　RTL compiler で論理合成をしています。
　クロックラインへのバッファー挿入ケアが全くされず
　に困っています。クロックラインへファンアウト調整
　用のバッファーを挿入させたネットリストを生成する
　にはどのようにすればよいでしょうか？

　勝手にset_dont_touck_network clock がかかっていて
　どうしても解除できません。

　不可能であるなら、design compiler へ移行いたします。

　
【質問２】

　RTL compiler で論理合成をしています。
　データラインへのホールド調整を行うにはどのように
　すればよいでしょうか。

　set_fix_hold ができません。

　不可能であるなら、design compiler へ移行いたします。

【質問１】

　RTL compiler で論理合成をしています。
　クロックラインへのバッファー挿入ケアが全くされず
　に困っています。クロックラインへファンアウト調整
　用のバッファーを挿入させたネットリストを生成する
　にはどのようにすればよいでしょうか？

　勝手にset_dont_touck_network clock がかかっていて
　どうしても解除できません。

　不可能であるなら、design compiler へ移行いたします。

　
【質問２】

　RTL compiler で論理合成をしています。
　データラインへのホールド調整を行うにはどのように
　すればよいでしょうか。

　set_fix_hold ができません。

　不可能であるなら、design compiler へ移行いたします。

【質問１】

　RTL compiler で論理合成をしています。
　クロックラインへのバッファー挿入ケアが全くされず
　に困っています。クロックラインへファンアウト調整
　用のバッファーを挿入させたネットリストを生成する
　にはどのようにすればよいでしょうか？

　勝手にset_dont_touck_network clock がかかっていて
　どうしても解除できません。

　不可能であるなら、design compiler へ移行いたします。

　
【質問２】

　RTL compiler で論理合成をしています。
　データラインへのホールド調整を行うにはどのように
　すればよいでしょうか。

　set_fix_hold ができません。

　不可能であるなら、design compiler へ移行いたします。

貼ると幸せになるコピペか？
おれも貼ってみよ

【質問１】

　RTL compiler で論理合成をしています。
　クロックラインへのバッファー挿入ケアが全くされず
　に困っています。クロックラインへファンアウト調整
　用のバッファーを挿入させたネットリストを生成する
　にはどのようにすればよいでしょうか？

　勝手にset_dont_touck_network clock がかかっていて
　どうしても解除できません。

　不可能であるなら、design compiler へ移行いたします。

　
【質問２】

　RTL compiler で論理合成をしています。
　データラインへのホールド調整を行うにはどのように
　すればよいでしょうか。

　set_fix_hold ができません。

　不可能であるなら、design compiler へ移行いたします。

コピペしてたくさんレスすれば、声がデカイと思っている人がいるようだ。
同じ２ｃｈでも、ある種の板ではそんな気もする。さあね。

>>417
質問１へのコメント
うろ覚えで恐縮だけど、
Cadenceはバッファー挿入は配置配線段階でケアする思想とか営業ゆーてた希ガス。
配置配線の状況次第で決まってくるし、合成段階で精度追求してもという考えからだろう。
まあ、微細化傾向では妥当性のある考えではある。

質問２へのコメント
質問１と同様だった希ガス。

（やっとアク禁解除なってコメント遅くなった）

でんす　でんす　けいでんす
これじゃベリ・ベリ・ドント・ケア

最近はマグマばっかだな

けいでんすマンボ、自信作だったのにしくしく

ビルドゲイツは好きだったよ、
おやじギャグっぽいネーミングにはひいたが。

Jobs　が　仕事　をする。
Bill gates　は　金を取る。

機械翻訳するとbill gatesは請求門になるから。

>>433
遅レスだが、おもしろい！

ビルドベースを思い出すやつはおっさん確定保守