【ＩＴ】RISC-Vによる新しいプロセッサの開発が難しいのはなぜなのか？
■ このスレッドは過去ログ倉庫に格納されています
プロセッサが解釈し、実行できる命令を体系化した命令セットアーキテクチャにはいくつか種類があり、代表的なものとしてはx86やARMが存在します。そうしたアーキテクチャのひとつであり、オープンソースで開発されるRISC-Vは、x86やARMに並ぶ可能性があるとして注目を集めており、RISC-Vを採用した独自プロセッサの開発に乗り出す企業もあります。半導体に関するニュースを扱うSemiconductor Engineeringが、新しいプロセッサの独自開発についての半導体企業役員の意見をまとめています。
Why It's So Hard To Create New Processors
https://semiengineering.com/why-its-so-hard-to-create-new-risc-v-processors/
RISC-Vはカリフォルニア大学バークレー校により2010年に始められ、現在はGoogleやHPなどの大手IT企業も参加するプロジェクトです。RISC-Vについては、下記の記事を読むとよくわかります。
新しいプロセッサの開発において大きな障壁となるのが「プロセッサの検証」であるとのこと。アメリカの半導体開発用ソフトウェア企業であるケイデンス・デザイン・システムズのバイスプレジデントであるポール・カニンガム氏は「真の意味でプロセッサの検証を完了するには、そのプロセッサ上で動作する可能性のあるすべてのソフトウェアを実行する必要があり、それは事実上不可能です。プロセッサの検証は非常に難しいのです」と語っています。
エッジデバイスなどに、主に組み込み機器に搭載されるローエンドなプロセッサにおいては、構造の柔軟性や開発コスト、価格の低さが求められるため構造がシンプルであり、プロセッサの検証が比較的容易とのこと。オープンソースのRISC-Vは最小限の構成を実装するための柔軟さを持っており、組み込み領域では強みがあると語られています。
しかし、一般のPCに搭載されるようなハイエンドなCPUでは話が別。マルチコアや投機的実行といった複雑な機能が必要になり、時にはその複雑さが脆弱性につながることもあります。セキュリティにも配慮しながら、マルチコアや投機的実行、さらには仮想化機能やFPUなどを実装し、なおかつそれを検証するのは非常に難しいと、Valtrix Systemsの共同創設者であるShubhodeep Roy Choudhury氏は指摘。
検証にかかる費用も新しいプロセッサを開発する上での障壁のひとつ。大手のプロセッサベンダーは巨大な研究所をかまえ、豊富な専門知識を有しているとCunningham氏は指摘。RISC-Vはオープンソースで誰でも利用できるとはいえ、命令セットのみ規定したアーキテクチャなので、ハードウェアの実装も検証しなければなりません。ハードウェアの検証も、プロセッサに複雑な機能を追加すればするほど高コストになっていくと、Imagination Technologiesのバイスプレジデントを務めるコリン・マッケラー氏は述べています。
また、検証には専門的なノウハウも必要とのこと。20年ほど前はプロセッサを開発する企業が現在よりも多数存在していましたが、その多くが買収合併された結果、ノウハウが特定の企業に集中してしまっているとのこと。半導体検証ソフトを開発するVtoolのCEOであるHagai Arbel氏も「非常に小さく、シンプルなプロセッサでも、設計の検証には専門的な知識が必要であり、他の設計とは異なるアプローチが必要なのは間違いありません」とコメント。さらに、ノウハウが集中している企業は論文やツールの公開に消極的な傾向があり、ノウハウを外部から得るのは非常に難しいとマッケラー氏は語っています。
こうした障壁を乗り越えるには「人を雇う」ことが一番だとカニンガム氏。その上で「必要な機能を絞り込み、オープンソース精神を忘れず、新しいものに時間と努力を費やすべきです」とのこと。また、 ImperasのCEOであるSimon Davidmann氏は、「独自のプロセッサを開発せずとも優れたプロセッサが手に入る状況において、『なぜ独自プロセッサを開発する必要があるのか』を自問自答することが大切であり、興味深い構造やカスタム命令の追加が目的なのであれば、RISC-Vによるプロセッサの開発は正しいでしょう」と指摘しています。
RISC-Vのコミュニティはこうした障壁を解決するために努力していますが、大手プロセッサベンダーでさえ、長年の経験にもかかわらず、予想外のバグや脆弱性を残していることを考えると、プロセッサの開発全体がオープンソースに置き換わる可能性は低いと結論づけられています。
https://gigazine.net/news/20200419-so-hard-to-create-new-risc-v-processors/ >>34
参照実装がなかったのではなくて仕様バクがあって実装できなかったというのが正しいよ。
ちょっと読めばすぐに解るようなバグがあった。十数年前に読んだきりなのでどこなのか忘れたけど、
プロセスに対する何かのフラグが足りずにしかも８ビットとか限定してあるので拡張も出来ない感じだった覚えがある。
外圧でつぶされたとか言っているけどそれはフェイクで本当は未完成だったというのが事実だとおもうよ。 でもいちおうTRONですというものを高い値段で売ってたし、
どこぞやの自動車の組み込み制御に使われていた時期もあったはずだが？ TRONと言ってもどの話だかわかるように話せよ
言ってる方も理解できてない可能性高いけど プログラム バグ
ロジック バグ
仕様 不備
異論は認める >>32
圧縮命令セットなんてArm Thumbとかmicro MIPSとかあるがな
>>30
AmazonがGraviton2で本気 下部アーキテクチャと乖離して命令セットは通信符号と化すのでしょう
最善最悪平均どういうバランスで最適化するかだけの問題になる
みんなIntel支配から脱したいが
IntelサーバCPU並の性能のデザインを
そんな簡単にできるなら
ARMがとっくに造っていたはず スパコンはarm系が多いらしいじゃん。
でもあの業界は通常のビジネス業界とは違うよね。
結局CPU自体の技術云々だけじゃなく、周辺のビジネス環境の影響が大きい。 Tronはコケてくれて良かったわ
あんなのが日本で力を持ってたら
今みたいに海外のソフトを自由に使えないからな なんにしてもトロンの想定した使用年代はすでに過ぎている。
未来を語ってたがすでに過去の話なんだぞ。 ISAだけオープンにされてもコアの設計技術は各社持ちだから(>>1要約） インテルはIA64という新しいアーキテクチャを出したが
いわゆるx86を拡張したAMDの
EM64に負けた。
インテルでさえx86には勝てなかった。 HPがIA64に乗っかったせいでHP-PAの系譜が途絶えたのはもったいなかったな ARMはコアあたり性能はインテル、
AMDの1/10程度しかない。
ただし、それ以上にチップ面積と
消費電力が小さい。 >>54
Graviton2(Neoverse N1)のBenchmarkでも漁れ。特にSpecFP2016とか遜色ないぞ 結局今ARMで作ってる連中に「ARMからRISC-Vに移った時に命令セット
足りなくて動かない可能性ある／動くかどうか保証されていないから
移れないよ」って言われたって事だよな、これ
現状まだ普及するための足場はグズグズって感じだわ
>>42
ARM ベースのサーバは富士通以外も各社販売開始してて
大規模シミュレータ系のアプリ会社がベンチマーク出し始めてる
富士通のスパコンの ARM チップも CRAY が採用するって話もあって
富士通のスパコンでは一番の成果だと思う CRAYは客に対してA64FXも選べますよ、と提示することは既に決めてる。
CRAY自体が他を見限ってA64FXに一点張りするという話ではない オープンソースで商売っ気がないところが逆に足かせになっている気がする >>50
逆に質問するが何か国産のソフトウェア使ってる？ オープンソースで標準のテストコード定めて通ればとりあえずOKでいいんじゃない
テスト専用のlinux 50じゃないけど、PCで使ってる国産ソフト
タイマー、メールクライアント、辞書辞典（EPWING）、
自炊書籍リーダー、ファイル横断文字列検索、2chブラウザ
過去も含めると動画プレーヤー、ターミナルエミュレータ SHA1やCRCを算出、斜めも測れる画面上の物差し、青空文庫対応テキストリーダー RISC-Vにビット操作ないの？
ネット関係では8bitで操作できて8bitを1byteにしbyte列の操作ができないと困るんだけど。 >>24
どうせ続けてもMRJと似たような結末だったんじゃねえの。
やれるんだ、やれたはず、俺たちはすごかった。
そんなのばっか。中国、韓国とほんと兄弟国だなぁって思う。 むかしプレイステーション用にソニーと東芝が共通開発した奴。
CELLって、この仲間？
東芝はTVのレグザに搭載してたな。 >>3
俺は互換CPU界でも弱小マイナーだったWinChipてやつで初自作だったな。
あれも速攻で消えたメーカーだった。
互換の市場でサイリックスがブイブイいわせてた頃だったな。
ナツカシ こう言うのって開発者に確実に選択、不選択理由を聞いとかないと
カレーにスルーされてしまって先細りして消えるのみなんだよな。 ＡＲＭを買ってしまったハゲがＲＩＳＣ−Ｖにビビってギガジンに書かせた記事だろ 32ビットのx86って結局最後に追加された拡張命令セットって何だろう？
MMX？ペンティアム3あたりでも32ビット拡張命令なかったっけ？ 要するにちょっと優れてる命令セットアーキテクチャ程度じゃ金かけても儲からんってことな x86ベースでＵＮＩＸ系のフリーソフトが一通りそろうGNUプロジェクトって凄いな・・・。
その他にもTgiffとか開発環境まで揃っちまう。
ただ、Gnuコンパイラでコンパイルするとソースレベルで互換性があるから
よほどハードアーキテクチャが優れていないと乗り換える気が起きない。 Wave Computing Chapter 11申請 Wave ComputingってMIPSアーキテクチャーの陣営だったかな？ 4ビットや8ビットや12ビットや16ビットのCPUをコアとして、
沢山の面積の小さいコアを1つのチップに詰め込むという
アプローチはないのだろうか？ 今のマルチバイトの文字コードはUTFー8のように可変長だったりする。
固定長のSJISやEUCやJISコードの場合にも、ASCIIコードと混在させる
ために、文字列等の処理ではいろいろと条件判断によって文字の処理を
行わなければならないが、それはつまり普通のCPUの命令で行うと
条件分岐が生じてパイプライン処理が混乱したりするだろう。
また、CPUのレジスタが32ビット（4バイト）や64ビット（8バイト）
であったりしても、1バイトあるいは2バイト、3バイトなどのような
ワードの境界を無視した位置にメモリ上で置かれていたり、また
レジスタの内部でバイト単位でシフトしたりマスクしたりして、
必要な文字のデータを取り出して来ないといけないと思う。
（たしかに、今日多くのマイクロプロセッサのアーキテクチャーは
バイトアドレスになっているけれども）。
文字列処理の性能を出すためには、そういった異なる長さの文字コード
とか、文字種の変更のコードだとか、可変長の文字コードの体系に
対応する機械語命令を設けることが望ましいのではないかと思う。
それにより、パイプラインの乱れなどを避けられたらいいと思う。
本当は、もうそろそろいい加減に文字は4バイト固定長にして
バイト単位であれこれ面倒な処理をするのは辞めたらどうかと思うのだ。
そうはいってもファイルに文字列をストアしたり、通信をするときには
どうしても容量をケチりたいだろうから、そういうときには専用の
圧縮機能を持つ回路を（画像の処理がGPUであるように）附加しておけば
良いだけじゃ無いかな？もちろんちまちまとソフトで出入り口のところだけ
は処理しても良いかもしれないが。
今はASCIIコード以外の文字を扱う場合のプログラムは面倒でバグが入り
安いと思う。文字がすべて32ビットで種類も1種類しかなければ、
物事は極めて簡単になるのに。 新しいプロセッサの開発が難しいのにISAなんてほとんど関係ないから、わざわざRISC-Vなんて使
わんってだけの話じゃねーか
インテル最新鋭のCPUと遜色ないRISC-Vの実装を無料公開したら、それなりに使われるって 命令セットに著作権とか特許とかは無いかもしれないが、あったとしても
ｘ86のはもう権利が切れてたりしないか？ ■ このスレッドは過去ログ倉庫に格納されています
