命令数を4種類に限定することでIoT向けに最適化したCPUアーキテクチャ「SubRISC+」 56
ストーリー by nagazou
最適化 部門より
最適化 部門より
東京工業大学（東工大）と科学技術振興機構（JST）は19日、IoTエッジコンピューティング向けの小型かつ省電力なプロセッサアーキテクチャ「SubRISC+」を設計し、1mm×1mm角のプロセッサとして構築したと発表した（東京工業大学、科学技術振興機構、論文、PC Watch、マイナビ）。
東工大のリリースによれば、古い製造プロセスである65nm CMOSを用いても1mm×1mm角を実現できたという。またARM Cortex-M0と比べた場合、1.4倍ほど高速でありながら電力効率は2.7倍、エネルギー効率は3.8倍を達成したとされる。
IoTの普及が増えるとデバイスやセンサー、サーバー間でのデータ通信量の増加が懸念される。そこでエッジとなる端末側での処理能力を高めることにより、遅延を減らしネットワークの負荷を軽減することなどが求められる。しかし既存の組み込みプロセッサは、IoT向けとしては過剰スペックであることから、SubRISC+では命令数を4種類に限定することにより、小型化と低消費電力化を図ったのだとしている。
あるAnonymous Coward 曰く、
東工大のリリースによれば、古い製造プロセスである65nm CMOSを用いても1mm×1mm角を実現できたという。またARM Cortex-M0と比べた場合、1.4倍ほど高速でありながら電力効率は2.7倍、エネルギー効率は3.8倍を達成したとされる。
IoTの普及が増えるとデバイスやセンサー、サーバー間でのデータ通信量の増加が懸念される。そこでエッジとなる端末側での処理能力を高めることにより、遅延を減らしネットワークの負荷を軽減することなどが求められる。しかし既存の組み込みプロセッサは、IoT向けとしては過剰スペックであることから、SubRISC+では命令数を4種類に限定することにより、小型化と低消費電力化を図ったのだとしている。
あるAnonymous Coward 曰く、
東京工業大学 工学院 情報通信系の原祐子准教授らは、IoTにて重要となる小型・省電力性を兼ね備えた新たなプロセッサを設計し、実機の開発に成功した。(ニュースリリース、PC Watchの記事)
既存の32bitプロセッサではARMのCortex-M0で60命令、RISC-Vで47命令の命令数があるが、開発した組み込みプロセッサは減算・シフト・論理演算・メモリアクセスの4種類の命令のみから成り、減算結果に応じて条件分岐するという特徴を持つ。なお、4命令のみでもチューリング完全であるため、適していない用途にも利用はできる模様。
実機は65nmCMOSプロセスを用いながら1mmx1mmと小型で、既存の32bitプロセッサでは最小となる物(明記されてはいないがおそらくRISC-Vベース)に対し2.7倍の電力効率、3.8倍のエネルギー効率を実現している。
適用の一例として、加速度データからてんかんの発作をリアルタイムに検出可能な軽量アルゴリズムを実装し実用性を実証したた結果、動作周波数を50 MHzと想定したシミュレーションではデータのサンプリング速度より高速に異常検出でき、かつ、電力は131.1 µWと極めて低い。
また、このプロセッサLSIを5 MHz(ヘルスケアの異常検出ではリアルタイム処理を十分確保できる周波数)で駆動した場合の消費電力はわずか77.0 µWであり、これはコンビニエンスストア等でも手に入るアルカリボタン電池LR44で約100日連続稼働できる試算である。
単一命令セットを拡張して使い勝手を良くした感じ？ (スコア:4, 興味深い)
チューリング完全で「減算結果に応じて条件分岐する」といえば、
OISC [wikipedia.org]（単一命令セット）の Subleq 命令が思い浮かびますが、
ここにシフト・論理演算・メモリアクセス命令を加えて使い勝手を良くした感じですかね。
ところでOISCは小型で省電力というだけでなく、命令が単一なのでどんなアルゴリズムを実行していても消費電力・ノイズの変動が少なく、サイドチャネル攻撃に強い特性もあるらしいですね。
このCPUも、そういう用途での要求があったんでしょうか。
8ビットマイコンとの比較 (スコア:1)
ARMやRISC-Vじゃなくて、Z80やPICと比べるべきじゃないかなあ。
# 新しいインストラクションセットにはわくわくしますが
Re:8ビットマイコンとの比較 (スコア:1)
IoT向けというのであれば、最近流行りのESP32と比較してほしいなー。
Xtensaのメインコアの方はともかく、ULP [espressif.com]の方は、uAオーダーで動くらしいし。
あと、CPUコア単体もいいけど、無線チップとかセンサチップとか含めたシステム全体でどれくらいの効果があるのかも検証してほしいな。
Re:8ビットマイコンとの比較 (スコア:1)
結構軽いコア単体ってだけでもニーズあるのよ
USB充電器作ろうとしてtype-cチップのデータシート見たらM0乗ってたとか、ブラシレスモータのベクトル制御コアにM0乗ってたとか、アプリケーションプログラマとは関係ないとこで頑張ってる
Re: (スコア:0)
> IoTエッジコンピューティング向けの小型かつ省電力なプロセッサアーキテクチャ
って書いてあるだろ。
USB充電器とかモータ制御にこんな超低消費電力重視の使いづらいプロセッサなんて使う意味ないし、使ってられないでしょ
Re: (スコア:0)
USB充電器ってそんなにマイコンの性能いるの？
せいぜい電力ネゴシエーション程度かと思ってたけど
Re: (スコア:0)
開発や実装コストでM0の方が調達しやすいのだろうね。
時間制限あるから、ある程度の性能は必要だし、
最近は端末側からの指示で電圧変更とかも必要。
Re: (スコア:0)
PICとCortex-M0の比較はARMとかがやってるんじゃないですかね
Re: (スコア:0)
機能やスレッドが増えるに応じてその分コアを増やしていくみたいな使い方なんですかね?
お値段安そうだし
Re: (スコア:0)
CASLよりも命令数が少ないって、本当に使い物になるか疑問
Re: (スコア:0)
メモリ込みで1平方ミリメートルのプロセッサに、32ビットものアドレス空間必要なの？
命令を減らしたリスクはどの程度 (スコア:1)
気になりますね。
Re: (スコア:0)
ハード的な面では、単純であればあるほど壊れにくくなるので、リスクは下がりますね
実行面では、ある命令の実行時間が想定と大きく乖離する可能性（4 種類の命令でエミュレートするようなケース）がありえますが、そういった複雑なことはこのアーキテクチャのスコープ外でしょう
ソフト的な面が一番難しく、元の命令をこのアーキテクチャに落とし込む変換を完璧にこなす必要がありますので、ここが一番のリスクかと
とはいえ、LLVM を使っているので入力言語の難しさは緩和されて、中間言語をこのアーキテクチャに落とし込めればいいので、その当たりも昔に比べればリスクは減っているのではないでしょうか
このハードを使ったシステムなら、多分電源（電池）と命令の格納先（ストレージ）の故障、あとは IF 部のトラブルの方が遙かにリスクが大きいかと
Re: (スコア:0)
リスクっていうかコストだな。
コストが見積もりにくいのはリスクかもしれんが。
Re: (スコア:0)
スーパーでプラスな程度です。
Re:命令を減らしたリスクはどの程度 (スコア:1)
チューリング完全 (スコア:0)
https://www.titech.ac.jp/news/img/news-26828-2-ju8kd24t.png [titech.ac.jp]
これ見ると実質1命令な気がする。
そういえばx86のmvもチューリング完全だからって言ってそれだけのコードを吐くコンパイラ作った人いたよね
Re:チューリング完全 (スコア:1)
https://twitter.com/a4lg/status/1364227793676996609 [twitter.com]
なるほど、基本sub命令だけだからsubRISCなのか
Re: (スコア:0)
https://github.com/xoreaxeaxeax/movfuscator [github.com]
あった
Re: (スコア:0)
move命令だけのCPUなら日本が誇るsayuriがあります。
ご連絡先
Re: (スコア:0)
でも、x86はmovでインストラクションポインタを操作できないので、チューリング完全となるためにはジャンプ系の命令が最低1つ必要。
Y2038 (スコア:0)
32bitプロセッサにおける〇〇年問題って解消されてたんでしたっけ？
# 情報元には特に何も記載がなかったけどとっくに問題ない状況なのかな
Re: (スコア:0)
そりゃISAの問題ではなくてどの型で表現するかって話では
Re: (スコア:0)
型もあんま関係ないのでは？
工夫したくないけど工夫すれば済むし。
Re: (スコア:0)
そもそもOSとか動かすようなプロセッサじゃないので、UNIX時間の制限は関係ないのでは？
Re: (スコア:0)
電源投入からの秒数だけ持ってるとか普通に有るしね。
Linuxは動くの？ (スコア:0)
いまどきのIoTは、LinuxやFreeBSDやOpenBSDが載ってる場合が多い
そういった汎用OS乗せる必要が無い単機能IoT(たとえば流量計・温度計・圧力計とか)なら汎用OS不要でも、
単機能じゃないIoTなら汎用OSが載るほうがいい
Re: (スコア:0)
> SubRISC+では、データからの異常検出やデータ探索をする軽量アルゴリズムをリアルタイムに処理し、警告などのかぎられたデータのみ送信する用途を想定
Re: (スコア:0)
載せれば載るだろう(載らない理由はない)けど、用途違うでしょ
Re: (スコア:0)
> 載せれば載るだろう(載らない理由はない)けど、用途違うでしょ
載らない理由はある。
ふつうの Linux や *BSD は MMU 必須なので載らない。
Linux の no-MMU カーネルなら頑張れば動く可能性はあるけど、RAMが足りないかも？
あと fork をはじめ、いくつかのシステムコールが使えないので
ふつうの Linux 向けアプリで動かないアプリはかなりある。
Re: (スコア:0)
MMUは外付けで行けるやん
Re:Linuxは動くの？ (スコア:1)
そもそも組み込み向けのワンチップマイコンで、バスが外に出てるものなんてほとんど存在しない(内蔵メモリのみが普通だ)し、メモリ量もたいして多くない。
MMUの外付けなんかは論外で無理で、Linuxなんて重いOSを動かすにはメモリが足りなすぎます。
比較対象にされてる ARM Cortex M0 も、基本アーキテクチャこそ一応ARMですが、組み込み向けで、
プログラムメモリ(フラッシュROM)がせいぜい32KBにデータメモリ(SRAM)がせいぜい16KBといった程度の量をチップ内蔵して、メモリ増設不可、といった想定の代物 [digikey.jp]です。
Re: (スコア:0)
チューリング完全
Re: (スコア:0)
とはいえ特権モードはほしいとかMMUはほしいとか太ってく未来が見える
Re: (スコア:0)
素直にx64エミュレータ書けばいいんだよw
Re: (スコア:0)
「載ったら面白い」なら分かる
「載った方がいい」はただ頭の悪い人
Re: (スコア:0)
IoTって言っても想定してる用途、価格、処理能力、消費電力が人によって違いすぎるから、その想定範囲を変えればいくらでも否定できてしまう。（それに想定範囲は自分では、それが当たり前なのでわざわざ書かないんですよね）
否定の話ばかり続きそう
できれば、このプロセッサに絞って、できそうなことをあげてもらえばうれしい。
4命令のみでも (スコア:0)
たった4個のインストラクションセットでどれだけ冗長なコードを書くのかと思ったら
開発環境は？ (スコア:0)
ハードがあっても、開発環境が無いのでフルスクラッチでアセンブラで書いてください・・・とかじゃなく、
やはりそれなりの開発環境があったほうがいい
C言語やらArduinoで開発できるとか、基本的なライブラリが揃ってるとか、そういったのがないと
Re: (スコア:0)
RISC-Vのバイナリをこの命令セット用に変換するという仕組みのようだけど
Re: (スコア:0)
https://www.jst.go.jp/kisoken/act-i/presentation2018/poster/2_10.pdf [jst.go.jp]
LLVMは使うみたいね
Re: (スコア:0)
Brainf*ckで開発ができるとか？
Re: (スコア:0)
tinyccとか、いまどきhackしやすいクロスコンパイラがあるから、そのへんで遊んでみたい。
そしてそのうち、clang/LLVMが追い付いてくる。こういうのは得意な人がいるので、楽観していいと思う。
割り込み待ち (スコア:0)
省電力を狙うなら、起こされるまで寝る命令は欲しい気がする。
CPUとしては面倒を見ないから、それができるペリフェラルを付けて叩けという思想なのかな。
もしくは、ポーリングでも大差ないほどカツカツの低クロックで動かすか。
Re: (スコア:0)
コイツはその「本命のCPU」を起こすためのセンサーに入るんじゃないか
Re: (スコア:0)
インターバルタイマに叩き起こされたら1サイクル分の処理を行い、
それを終えたら次に起こされるまでHALTで待機とかでしょ。
ゲームボーイがそんな感じだった。
Re: (スコア:0)
ヘルスケア製品の様に電源を入れたら切るまで常に入力があり、それを演算し続ける用途を想定しているので、寝ている暇などないのでは?
Re: (スコア:0)
ほとんどのセンサーには値を取り出せる周期の限界があるので
人間の感覚ではリアルタイムでも0.1秒刻みとかのインターバル動作だったりする。
引き算分岐命令を予想してみる (スコア:0)
引き算で分岐ということは、2オペランド命令で
引数が、比較される数を入れるレジスタと相対指定のジャンプ先で
2バイト目に相対ジャンプ先を書くんじゃないかなと予想。
引かれる数を入れるレジスタはZ80のAみたいに固定で、
引く数を入れるレジスタをどれにするかで、ZとかCとかの
どのフラグがたったときにジャンプするかが決まるんじゃないだろうか。
算術演算としてやりたい場合は、ジャンプ先を次の命令ににしておけば
結果に関わらず次に書いた命令が実行される。
逆に無条件ジャンプしたい場合は、0-0=0の演算でZフラク立てて
分岐をトリガーする感じか。
引き算のときだけ2バイト目(ジャンプ先)をフェッチするなら、
相対ジャンプオンリーにしてしまえば、リロケートが楽だし
IMEM側からPCに値をロードするための回路も省略できる。
構成図を見るとIMEMから直にPCに渡す回路がない
(必ずALU経由)か、おそらくジャンプは相対指定のみ。
リロケートも楽という利点もある。
という感じじゃないかなーと予想したけど、妄想のレベルだな。
減算+ブランチ命令、AND命令、シフト命令、メモリアクセス命令の四つ (スコア:0)
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9133073 [ieee.org]
Here we briefly explain the basics of SubRISC+ to the extent of highlighting our contributions in this paper.
SubRISC+ was developed on the basis of a one-instruction set computer (OISC) whose unique instruction is ‘‘subtraction and branch on negative’’ that is capable of realizing any operations and hence is Turing complete.
By extending the instruction set architecture (ISA) of this OISC, SubRISC+ handles four instructions (subtraction, bitwise AND, shift, and memory access) that can be flexibly expressed in either 16 bits (for compactness) or 32 bits (to support an immediate value or branch) to improve computing and power efficiency while retaining simplicity with a very limited circuit overhead.
bne a0, t1, .L2 →
sub a0, t1, t3, .L2 (two 32-bit instructios)
sub t1, a0, t3, .L2
not a0, a1 →
sub -1, a1, a0 (one 16-bit instruction)
subtract and branch if less than(sublt)命令です。subleqではありません。