【IT】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/ 昔 クルーソーっていうのがあったな。
リナックス作った奴が考えたやつ
あれ けっこう 良さそうだったんだけど
今 どうなっているのだろうか? 逆に言えばプロセッサのノウハウを持つNECや富士通が全面参入すれば出来る。
ソニーもやろうと思えば出来る 特殊な構造のプロセッサだから難しい
みたいな話かと思ったら
開発態勢がオープンソースだから難しい
って話か もう一つの問題はハードを作ってもファームやドライバやOSなどの
ソフト環境が整っていないためにユーザーまでなかなか届かない。
日本政府が教育を含め全面導入して多額の懸賞金と数十万台買い取り約束
するとかすれば可能だと思う。そうすればPCを2万円くらいで買える世になる
ソフトは蓄積の問題だから何とかなるとは思うが草の根のフリーでは無理 作れる作れないでいえば
それに類するものを作ることができる企業はそれなりにあるんだろうけど
ある命令セットを実行できるCPUを作り
マルチコア化とか分岐予測とかそういう高速化のための仕組みをいろいろ組み込み
そういう開発をし
それを売りだして、大量に売って開発費を回収する
それをできる会社はほとんどいないだろうな
PC用のintel と AMD、 スマホ用の Arm の実装をする各企業
それ以外は大量に売りさばくことが難しいだろうし そりゃマトモなハードマクロがないと敷居は永遠に下がらんよ
ARMでマイクロアーキテクチャを独自設計にしてるところがほとんど無いのと同じ フリーが売りなのにフリーのせいで金が集まらんのかい NOP命令も無い(疑似命令はある)
フラグレジスタも無い
キャリーもオーバーフローも無い
ローテ―トも無い
レジスタクリアも無い(疑似命令はある)
とにかくシンプルなISAだった 顧客がお金出してるのに
アップルの端末をどう動かすかをアップルに決められてしまう
みたいな不条理感
まあマイクロソフトやグーグルも一緒かもしれないが
ここらで、そういう部分は公共財産みたいになった方がいいような気もする
ただ、そうなるとIT系企業のやる気をそぐ面もあるのかも RISCだとマイクロコードの処理が効率悪いから何やってもダメだろ だいたい設計が良くても
EMS企業に生産発注だし数少な過ぎて超高価になるだろうし
普通のハイエンドCPUと真逆で
最先端のプロセス使わせてくれないし
古いプロセスだから発熱の問題でクロック上げられず消費電力も多い
普通のハイエンドの方がコスパ良いよね >>4
もう研究部門縮小して人材散り散り
残ってるのは穀潰しだけ 現在では、「RISC対CISC」という単純な優劣論争は、技術的にはもはや意味を持たない。x86などの代表的なCISCプロセッサは内部的にRISCのアーキテクチャを段階的に取り入れ、逆に代表的なRISCプロセッサは命令数の追加を続けているためである。
RISC-VのポイントはCISCかRISCかではなくてオープンってところ 特定企業に集中して、その重要ポストが限られてるからこそ、高い報酬と待遇が得られる
だからこそ、最先端・高性能なプロセッサを作り出す人材が確保できる
これがオープンになってサバイバル化してみろ
ノウハウの叩き売り、知識の道草化
天才もやる気をなくす、夢の無い世界になるだけ
そうなったら、誰もプロセッサなんか作ろうと思わない
今みたいに、ウソみたいな高性能プロセッサが激安で簡単に手に入る世界で十分じゃないか
その世界を支える天才たちをみんなで支えていけば、それでいい >>12
触れ込みが素晴らしい割には結構クソな面がありますね 日本エレクトロニクスの苦難はクソユダヤのインテルが協力者のはずだった
日本勢を互換アーキから締め出した所から始まったからな
何とかオープンアーキの世界をうまく作らないと 実際に出来上がるCPUで語るのなら
プロセス含めて検討しなければ意味ないわな
古いプロセスでしか作ってくれないんだから
敢えて今これに大金投資するメリット無いんじゃね
利権しか残らんと思うわ >>7
それをOSでやろうとしたのTRONだな。
NECや富士通が政府に金を出させて利益を上げようとしたという面もある。
アメリカと孫に潰されたという人もいるが,発注されたら開発しますという
製品と,既にあって動いていますという製品(PC/MS−DOS)を入札
で競わせるには政治家も官僚が相当腹をくくらなければいけないハードルの
高いものだった。内情を言えばNもFもそれほど熱心じゃなかったから,そ
れと心中なんて人はいなかった。 上の無能ボケ老害が出来ない出来ないと喚きすぎるのが問題なんだよな
殆どキャッチアップしている技術でさえ日本には無理というクソジジイさえいた >>3
Crusoeを作ったのはトーバルズじゃねーぞ >>13
言うほどの低電力じゃなかった上に、性能がクソ悪かった。
単なる自爆。 Crusoe対抗のために、Intelがなりふり構わず急遽投入したP3アーキテクチャベースのPentiumMが、現在の主力CPU、Coreアーキテクチャの原形になったんだから、技術史とは皮肉なものだ。 >>4
富士通はHPC用にコアは同じで
命令セットを変えてやってるから
riscvもやれるかもしれなきけど
一般人買えないからなあ 巨大企業が多額の開発費を注ぎ込まないとまともにCPU開発できない時代になってしまった訳で
intelだって小さい方(Atomとかcurieとか)は失敗したし、ARMだってでかい方は(サーバ分野)なかなか普及してない RISC-VはRISC的な命令コードをUTF-8エンコーデングみたいなやり方で圧縮して外部メモリーとの帯域を圧縮するという発想なので
あるいみx86と同じで後出しなので効率がいい。 巨大企業以外の3番手や4番手が徒党を組んだら、わからんよ TRONは参照実装をソースで配布しなかったことが、
UnixやLinuxと違って普及しなかった最大要因だと思うね。
そうしてサイドビジネスのパーソナルメディアとかいう名前の
会社が商売をしていてなんだかなぁと思った。周辺機器の
サポートがさっぱりだったし、GUIもWindows3.1みたい
だったし。
浮動小数点演算を馬鹿にするような発言をしていたことも
印象に残った。要するにいろいろと実用性を無視している
ところがあった。
コンパイラなどの開発キットが無料であったのかどうか。
松下が最初最大の支援者だったような気がするけれど、
教育用途をアメリカに潰されて、それでうまく行かなかった
んだね。 >>34
参照実装がなかったのではなくて仕様バクがあって実装できなかったというのが正しいよ。
ちょっと読めばすぐに解るようなバグがあった。十数年前に読んだきりなのでどこなのか忘れたけど、
プロセスに対する何かのフラグが足りずにしかも8ビットとか限定してあるので拡張も出来ない感じだった覚えがある。
外圧でつぶされたとか言っているけどそれはフェイクで本当は未完成だったというのが事実だとおもうよ。 でもいちおう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てやつで初自作だったな。
あれも速攻で消えたメーカーだった。
互換の市場でサイリックスがブイブイいわせてた頃だったな。
ナツカシ こう言うのって開発者に確実に選択、不選択理由を聞いとかないと
カレーにスルーされてしまって先細りして消えるのみなんだよな。 ARMを買ってしまったハゲがRISC−Vにビビってギガジンに書かせた記事だろ 32ビットのx86って結局最後に追加された拡張命令セットって何だろう?
MMX?ペンティアム3あたりでも32ビット拡張命令なかったっけ? 要するにちょっと優れてる命令セットアーキテクチャ程度じゃ金かけても儲からんってことな x86ベースでUNIX系のフリーソフトが一通りそろう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の実装を無料公開したら、それなりに使われるって 命令セットに著作権とか特許とかは無いかもしれないが、あったとしても
x86のはもう権利が切れてたりしないか? ■ このスレッドは過去ログ倉庫に格納されています