|
明日は4月1日なので今日、書くことにしました。
「超軽量8bit CPUで公開鍵暗号を高速化する専用命令」を思いつきました。
8bit 加算器1個、8bitのレジスタ2個のような超軽量なCPUのための専用命令です。
性能を見積もっていませんが、この専用命令があれば、8bit CPU WZetaで、
機器認証のような用途や、公開鍵暗号を使った通信など用途が拡大するように思っています。
この専用命令に必要なトランジスタ数は、ほんのわずかで演算器を追加する
ということでは、ありません。
非常にコスパのいいCPUになりそうです。
amazonのVPSはSSHでログインするために公開鍵暗号を使っています。(多分、今も)
ICカードに秘密鍵を入れることで安全になるのですがICカードが安全なのかという問題があります。
ICカードが勝手に部屋の中にある家電と無線通信を行って秘密鍵を漏洩することもあるかもしれない。
そんなことが問題でamazonのVPSが使えなくて困っている。そういうことはあるかもしれない。
そこでTTL CPUを使えば安全が確保できないだろうか？ということを考えた。
ところがTTLで作られたCPUは演算能力が非常に貧弱で、まともな時間で演算できないこともある。
RSA暗号の高速化について世界一詳しい僕が、プロセッサ技術にも詳しい結果、
乗算器のない非常に貧弱なCPUでも、高速に演算できる「命令セット」というのが設計できそう。
ということなのである。数学ではなくてプロセッサ技術による高速化。
もちろんプロセッサ技術だけ異様に詳しくても、RSAの高速化の方法は、わからないだろう。
ちなみに楕円暗号も高速に演算できる「命令セット」です。
1台、10万円くらいなら年間500台くらい売れて、売上5000万円くらいになれば、考えられるのだろうか。
TTL CPUを作ったことないから製造原価は詳しくないけど。
TTL CPUをネットで調べると74181というCPUのALUに相当する部品が入手しにくいみたい。
74181がないから、他の部品も売れないということになっていなければいいのですけど。
WZetaは強力なデバッグ機能を実装できるのではないかと思っています。
どうして強力なデバッグ機能を実装できるのか、
それは16bit固定長の命令コードの最上位bitを、デバッグ専用機能として使えるからです。
WZetaでデバッグする場合、命令コードの最上位bitに直接、ブレークポイントを埋め込めるということです。
ブレークポイントではソフト割込みやDEBUGOUT信号を1にするだけの実装なので、
非常に少ないトランジスタ数で強力なデバッグ機能が実装できる。
こんな感じ
(1) 無条件にソフト割込みをする
(2) CF=1ならソフト割込みをする
(3) ZF=1ならソフト割込みをする
(4) INポートの最下位bitが１の状態なら、ソフト割込みをする
(5) デバッグ用の割込みフラグが1なら、ソフト割込みをする
(6) 無条件にDEBUGOUT信号を1サイクルの間、1にする。
(7) CF=1ならDEBUGOUT信号を1サイクルの間、1にする。
(8) ZF=1ならDEBUGOUT信号を1サイクルの間、1にする。
(9) INポートの最下位bitが１の状態ならDEBUGOUT信号を1サイクルの間、1にする。
(10) デバッグ用の割込みフラグが1なら、DEBUGOUT信号を1サイクルの間、1にする。
デバッグモードではOUTPUT出力はOUTPUT命令以外ではAレジスタの状態を示す。
デバッグ用の出力ポートには前の命令で読み込んだデータがあるので、それを出力。
DEBUGOUTによる出力は割込みではデバッグできない場合に使う。
ネットを検索すると京大の教育用CPU、SIMPLEというものが見つかった。
一般的な5段のパイプラインのCPUのようです。
F(フェッチ)
D(デコード)
E(実行)
MA(メモリアクセス)
WB(ライトバック)
WZetaは6段のパイプラインです。パイプラインといっても1命令は4サイクルの固定ピッチで処理されます。
分岐命令を含めて4サイクル。固定ピッチですが制御用としては使い易いのではないかと。
F(フェッチ) 1バイトのオペランドのフェッチ
(空)
F(フェッチ) 1バイト(7bit)の命令のフェッチ
MA(メモリアクセス) リード
e(実行) 分岐命令の実行。オペランドのデータだけで分岐先が決まるので。
EとMA(実行) MAでリードしたデータを使って演算、結果の書き込み
つまり1命令で2回のメモリアクセスをしています。
WZetaは8bitレジスタ2個しかないので、メモリの0番～126番までをレジスタのように使うのです。
このためメモリアクセスに最適化したアーキテクチャになっています。高周波数で動作します。
4サイクル固定ピッチですがSIMPLE換算で2.5～3サイクルピッチになる予想。
命令の実行論理を設計しています。7bitの命令コードのうち、最上位ビットは
自分で定義できる命令に割り当てているので、命令に使えるのは6bit、すなわち64命令になります。
WZetaの命令のうち約半数が、MAで読み込んだデータを加算器の入力の左側に
データを入れるだけなので、オペコード6bitの最上位bitを制御信号として、そのまま使います。
そのまま使うと演算結果が狂う命令がいくつかありますが、演算結果を使わない命令を装填すれば問題なし。
というような感じで共通項をうまく利用してマイクロコードがなくても美しく実行制御できる。
美しい命令コードの処理フロー、美しい命令実行制御論理、わずかなトランジスタの追加で
利用者定義命令ができて、ICF3-Zの仮想マシンで恐らく動作する。
スタックの代わりにブランチ＆リンクを使います。
制御用の小さいCPUではブランチ＆リンクで十分なのでトランジスタ数の削減に役立っています。
それでいてスタックをソフト実装するのに便利な命令があるので、スタックがないと困る場合でも、
どうにかなる。つまりメモリ上に16bitポインタを置くのが便利な命令なので
30年以上前の初期の8bit CPUと比べるなら、プログラミングしやすい。
そういった良くできたCPUに、なりそうなのです。
作業中の仕様です。CPUアーキテクチャを見たくない人は、この日記はスキップしてください。
図をマウスでクリックすると拡大されます
暗号プロセッサSnakeCube
を急ぎたいのですが、普通の人がすぐ使って便利というものではない。
そこで誰でも興味を持てば遊べる8bit CPU WZetaの完成を急いでいます。
elchikaで審査を通過したのに新型WZetaを作り始めてしまったので、
あまり長い時間、音信不通であることも問題かと思っているので
状況報告を兼ねたCPU比較です。
新型WZetaですが命令セットの仕様みたいなものは、出来上がってきて、
これから設計図を作るところです。まだ仕様通り完成する保証はありませんが、
だいたい、できるのではないか、というところまできています。
ということで仕様書の公開は、まだできませんが、
ファミコンのCPU 6502と比較してみた感想を書いてみたいと思います。
僕は6502について、これまであまり調べたことがなくて知らないのですが、
Z80のように有名な8bit CPUなんだと思っています。
ネットで調べても、いろいろ情報が手に入るみたいです。
僕の新型WZetaの設計方針は16bit固定長の命令セットで、
プログラムを8bit単位で転送することができて、トランジスタ数を少なくすることです。
特に6502やZ80を意識したつもりはありません。
仕様作成が終わってから6502を見てみると、ちょっと似ているところがあって、
新型WZetaが、どんな感じなのかを説明するのに、いいかもと思ったのです。
6502は8bitレジスタ、A,X,Y,Sの4本でA以外は主にアドレッシングで使うレジスタのようです。
新型WZetaは8bit レジスタ、A,Bの2本でAは主に演算、Bは主にアドレッシングで使うレジスタ。
6502はX,Y,Sなどのインデックスレジスタを用いた豊富なアドレッシングによって
性能が出ているような感じです。
新型WZetaはインデックスレジスタがない代わりに0～126番地のメモリをすべて
インデックスレジスタのように使うようなプログラミングになります。
専用のレジスタよりは性能が落ちるのですが、いちいちインデックスレジスタに
コピーしたり、書き戻す手間がないので、思っているよりは高速です。
そして16bitポインタとして機能するところが新型WZetaが便利な点かなと思っています。
6502の高速化の役に立つインデックスレジスタは、すべて8bitだというところが、
6502のデメリットかなと思ったのです。僕の知らないプログラミングテクニックによって
これを補うことが可能ということは、あるでしょうけれども。
最も大きく違うのは6502がマイクロコードを持っていて豊富な命令を
サポートしているのに対して、新型WZetaは、すべてハードワイヤードで作られている。
すべての命令は分岐も含めて6ステージ、4サイクルピッチで動作することです。
ノイマン型アーキテクチャの非常に美しい構造になってしまったので、
ここ数日、ニヤニヤしているという状況です。
そして少ない命令を補うためのハードマクロ命令を、少しのトランジスタ数で
実装出来そうだという点。自分で命令を作れます。性能はともかく、
メモリ効率は大幅に改善されると思っています。
ノイマン型アーキテクチャだと、メモリは1個でいいので、原価低減に役に立つと思います。
ロジック混在のメモリとか、MRAMとか1個でいいことになる。
1個のSRAMに起動時にフラッシュからロードするとか。あれこれ。
新型WZetaは16bit固定長の命令セットアーキテクチャです。
現在のところは15bitですが15bitの安価なメモリは存在しないので16bit固定長といっても問題はない。
この日記を読んでいる人には16bit固定長の命令セットアーキテクチャに強く反応した人は、
いるのではないかと思います。そうです、あの日立(現ルネサス)のSHマイコンが
16bit固定長の命令セットアーキテクチャをキーワードに宣伝されていました。
1996年ごろだったろうか日経エレクトロニクスをたまたま年間購読していたので、
リアルタイムにSHの開発秘話というのを読んでいました。
しかしながら良く考えてみるとSHマイコンを調べたことなどあまりなく、
どんなCPUなのかあまり知らないということに気が付いた。
そこで昔買ったインターフェース増刊の「SuperHプロセッサ」1999年CQ出版
を読んでみた。典型的な5段のパイプラインのアーキテクチャのようです。
F(フェッチ)、D(デコード)、E(実行)、MA(メモリアクセス)、WB(ライトバック)
マイコンだと2段、3段のパイプラインのものもあるので高周波数なのかも。
F(フェッチ)で16ビットの命令コードを1サイクルで読み込む。5段1サイクルピッチです。
命令によってはパイプラインはストールします。
新型WZetaの話に戻ります。6段で4サイクルピッチです。
F1-空-F2-D-e-E
1度に8bitしか扱えないのでフェッチを2回行います。
(空)には前命令のEが入ります。
ここで気づくのはSHのF(フェッチ)は1サイクルで命令コードを取得しているということ。
1サイクルでメモリまで往復している。
僕の超軽量CPUは1往復するまでの間にメモリリクエストをもう一つ出している。
メモリアクセスには時間がかかる場合が多いので、
超軽量なWZetaのほうが2倍近い周波数が出るのかな？
僕の新型WZetaは高周波数な5段のパイプラインよりも
高速な周波数で動作？？？
パイプラインが無いのに、思ったより高速なのかも。
パイプラインが無いので、構造が簡易でトランジスタ数が少ない。
割込みの実装が容易というメリットが。
オペランドだけで投機的なメモリアクセスが可能な命令セット
アーキテクチャというものが有効かもしれない。構造の単純化に役立ちそう。
1バイトのオペランドは0～126なら、メモリの0～126をアクセスする。
127の場合は8bitレジスタA,Bを連結した16bitのアドレスをアクセスする。
128～255の場合は[n-128:B]のアドレスアクセスするというようにすれば
1バイトでアドレッシングモードを変更しつつ16bitのデータを扱えるのです。
これで新型WZetaがSHマイコンとは似ても似つかないということが、わかってもらえたかも。
まだ仕様作成中だから最後までできるのかわからない
けどSHの話は、急いだほうがいいと思ったので。
日記を読んでいる人の中には軽量なCPUが何の
役に立つの知らない人もあるのかと思いました。
街や農地にセンサーデバイスが大量に配置される世界が到来すると
メディアでは報じられています。センサーで何ができるのか、僕も詳しくはわかりません。
センサーデバイスからの情報は信頼性が必要です。
例えば環境調査でデータを改竄して税金が必要であると結論づける人はあると思います。
得られたデータをセンサーデバイス内で暗号化をすれば、そういったことを防ぐことが可能になるのです。
もしLinux搭載のIoTを経由する場合、
Linux搭載のIoTを安全だと思えるようにするにはLinuxのソースコードを
隅々読んで自分でコンパイルしなければならない。
悪意のあるコードを見抜くことは国家予算クラスのお金が必要な気がしています。
つまりLinux搭載のIoTデバイスは信頼できずセンサーデバイスで暗号化しなければならない。
ここに大きなCPUの市場があるのかと思ったのです。
アセンブラでコードを書ける規模で暗号化ができます。
AES暗号ができる超軽量なCPUを選択する人があるかもしれない。
無駄に高価なCPUを使いたい人はいないでしょうから。
AVRなどの8bit CPUが実際に採用された実績もあるようです。
そして2019年に製造コストを下げるための命令セットアーキテクチャを思いつきました。
2年後の今、再びそのアイディアを使った新しい8bit CPUを設計しています。
今のところ、次のような感じ。
命令コードは2バイト固定。メモリから8bit単位で受け取るのに効率的な
命令セットアーキテクチャ。一般的なCPUとは逆順で命令コードをメモリから
受け取ります。何の命令なのかわからないままアドレスのデータだけで
投機的にメモリリードを行います。従来の8bit CPUには見当たらない、
面白いものができそう。
よくよく考えてみると、わざわざ価値を小さくする
トランジスタ数の少ない8bit CPUを設計をすることなど、
これまであまり、やった人は、なかったのではないかと。
バージョンアップと言いながら全く別のCPUに置き換えるのと
同じになりそうなのですが、ちょっと面白いものができるかも。
まだうまくいくのか、わからないですけど。
従来の命令セットアーキテクチャは1命令毎に独立していますが、
新型WZetaは前の命令の状態を引き継いで、そして次の命令に渡すということを
積極的にする命令セットにします。
話を単純化するならアキュムレータ(演算結果を累積させるレジスタ)に対して加算、
論理演算をしていくような感じ。
2つの内部レジスタに対して、操作を累積させて処理をする。
命令コードを連結させれば人間やコンパイラにとってわかりやすい
１つの命令になる。
ついでにICF3-Zのようなユーザー定義命令で15bitの1命令にしてしまう。
トランジスタ数の少ないCPUを作ると1つの命令では十分な機能の命令にならない。
複数の命令を使うとメモリ効率が悪くなる。これを対策する。
そして対策にかかるトランジスタ数が少ない。
スタックポインタを完全に無くして部品を減らす。というようなアイディアを検討中。
明日、アイディアが破綻しているかもしれないけど。
WZetaの命令セットをICF3-Zの仮想マシンの命令セットの形式に
適合する命令セットにできればWZetaのプログラムがICF3-Zでも動作する。
完全互換になるのか保証できないが、効果が期待できるかもと思っているところ。
プログラムのコードをバイト転送させる特長を残せるか検討中。
現在は4バイトで1命令。検討しているのは2バイトで1命令。例えば
ADD Rx , Ry , Rz
だったのが
LOAD Rx
ADD Ry
STORE Rz
6バイトになる。迷うところかもしれないがICF3-Zの仮想マシンで動作するほうがいいから、
2バイト1命令になるかも。
僕にとって暗号プロセッサSnakeCube
の発明は青色LEDのような大きな発明のように思えています。
昨年の8月に既にRSA 2048bitをXilinxのFPGAに実装して
性能を実測して、
その実力を示すことには成功していますが、これをXilinx Alveoに実装して、
本格的に僕の発明が、すごいということを確保したいというのが、僕の気持ちなのです。
産業スパイによる妨害で1年半くらいは無駄になっていると思います。
このままでは、このまま妨害が続き、僕の頭も本格的に壊れそうなので、
少しの時間を使って8bit CPU WZetaのバージョンアップをしようと考えています。
WZetaはメーカ依存のないverilogになっています。かつ論理ゲートに近いものなので
TTLで作れるものになるかもしれません。僕は目を、やられてしまったので、
半田ごてを握るのが大変になっているのでTTLを自分でやるのは難しいかもと思っています。
不可能ではないと思います。要するにTTLできる人は秋葉原の電子パーツをいっぱい買いましょう。(笑)
WZetaは
XilinxのローエンドのFPGAで200MHzくらいで動作するのですが
TTLで20MHzくらいで動作すればAES 256bitの暗号化が20[KB/Sec]程度の性能が出そうです。
復号化は14[KB/Sec]です。ダウンロードできるファイルに、このAESのプログラムが入っています。
TTLのCPUで何か面白い使い方があるといいのですけど。
割込みがないCPUというのも厳しいかなと思ったので、
時間があれば割込みも実装してみようかと思ってます。
以下はWZetaのサイトのトップページにある文章の転記
WZetaは一般的なCPUの命令セットを持ち、かつ、AES 128/192/256bitが動作するので LoRaWANのデバイスのMCU(CPU)として使うことができるかもしれません。 WZetaは4命令しかない東工大のSubRISC+の 10分の一のトランジスタ数なので、LoRaWANデバイスのコスト削減や、 トランジスタの製造で豊富にある地球資源の材料を選択することが期待できるかもしれません。 LoRaWANデバイスは一度に大量に購入するので、温度センサーのような性能のあまり要らない用途では、 最も安価なCPUのLoRaWANデバイスを購入者は選択するでしょう。 そして将来に渡って安価なCPUは使われ続けることになる。そういうCPUにWZetaは、なるかもしれない。 大きなメリットではないかもしれないが、やれるなら、やっておこうくらいの感じです。
CPUの専門家でなくても、わかる範囲だと思うような内容の日記です。
CPUの分類にCISCとRISCがある。ここではRISCは関係なくCISCの実装についてです。
IBMの大型コンピュータやIntelのx86、AMDのAMD64がCISCに分類されます。
CISCではプログラムの命令コードをマイクロコードを使って実装する傾向にあります。
その仕組みが仮想マシンでも使えるだろうという話。
そして、それをICF3-Zの仮想マシン機構に似せる説明を作っている場合がありそうなのです。
僕はIntelやAMDの実装については知らないのですがIBMのCISCの実装の表面は知っています。
25年くらい前のIBMについてですけれども。
CISCなので1命令でZIP圧縮するような命令が複数存在します。
これを全てマイクロコードで実装するのは、新しいCPUを作る度に大変になる。
そこでマイクロコードではなく一般命令で実装する仕組みになっている。
正しくは一般命令を拡張したミリコードと呼ばれていた。
前回の日記の論文の概要しか読んでいませんが、予想できる範囲内には、
拡張命令の中に浮動小数点用のレジスタを普通のレジスタにロードしたり、
アドレスレジスタに使えるような命令があるようなものも、あるのかもしれない。
ミリコードはICF3-Zの仮想マシン機構とアイディアは似ている。
ただICF3-Zの仮想マシン機構はCISCの命令を実装する仕組みよりは、非常に簡単な作りになっている。
簡単な作りでできることしかしないのです。
つまり実際のハード実装は大きく異なるだろうということです。
論文の日付から僕のほうが先です。「酷似」ではなく「類似」です。
ICF3-Z
のCOPR命令を参考にして論文を作ったのではないかと思われます。
ICF3-Zの命令セットアーキテクチャは普通のCPUとは全く違うので、
それを知らずに説明することはできないのですが、
ICF3-ZのCOPR命令は仮想マシンのオペランドを実マシンのオペランドとしてマッピングする命令。
いちいち仮想マシンのオペランドをメモリから読み込まずに直接、
実マシンの命令コードのオペランドになるようなハードを実装しています。
このハードで仮想マシンの命令を高速化します。
2020年度（令和2年度）山下記念研究賞を受賞した東大の論文
「動的スクリプト言語の高効率実行を目的としたプロセッサアーキテクチャの拡張」
既存のCPUで浮動小数点用のレジスタの空きを利用して、そこに仮想マシンのオペランドを入れるということらしいです。
(多分、できるなら実マシンの命令コードのオペランドにマッピングしたほうが効率的)
概要だけで内容が理解できたので概要しか読んでいないですけれども。
以前にも似たような事件がありました。
高専卒が東大や、京大に編入して、僕がやっているプロジェクトと類似する研究をするケース。
今回、ネットで調べた限りでは、地方の国立大学から東大というケースのようです。
30年前、独自のスーパースカラを「ハイパースカラ」と呼称していた先生と、
お仲間の先生が教員であったようです。ちゃんとした背景は、あるのかも。
「ハイパースカラ」の本、学生の僕には高かったですが、購入しました。
日立に入ってCPU撤退になったので、読むことなく本は行方不明になっていますけど。
僕が作っているCPUは一般的なCPUアーキテクチャから外れているので、参考になっている
研究というのは無いです。
念のために書いておきたいことは、僕のSNSのタイムライン上に「山下賞」が見えるように仕掛けて、
僕がインターネットを調べるように誘導しているので、僕のパソコンのIPアドレスからのアクセスは、
改竄されている可能性がある。以前、この攻撃を喰らってパニックしました。
参考URL
仮想マシンの加速支援機構つきの新型8bit CPU
3月13日の日記で僕の
超軽量のCPU WZeta
の作品がelchikaのハードウェア作品投稿キャンペーン
の審査を通過しました。そこで近日中にgithubで公開するための準備作業をしています。
最初からXilinx依存はしていませんが、Xilinx環境のための記述が残っていたので整理をしています。
頭痛を堪えながらの作業は、良いものが作れないので、辛い思いをしています。
スラド記事
「ピピンアットマークの失敗をテーマにした番組、NHKで放送予定」
バンダイの世界一売れなかったゲーム機「ピピンアットマーク」についてらしいです。
並列8bitパソコン Vattles
のコンセプトを考えてパソコン売れないだろうかと思っていたりするので、
「ピピンアットマーク」の失敗が気にならないわけではない。
スラドに寄せられたコメントも、参考になるかもしれない。
Vattlesはゲーム機ではなくて、電気自動車向け高信頼化部品になるマイコンを
生み出すためのホビー(hobby)向けパソコン。
CPUの動作原理を学びながら、最先端の技術になるかもしれない
低周波数化並列処理技術を習得したい人がターゲットかも。
低周波数化並列処理技術の電磁波対策効果は、どのくらいなのかわかりにくいが、
とにかく普遍性があって、学んだものが陳腐化しにくいという点がいいところ。
また１つの仕事を１つのCPUに割り当てることで信頼性が向上することもあるので、
そういった技術をパソコンを囲みながら磨けるような環境ができれば、この国の将来に役立つかもと。
低周波数化並列処理技術が電磁波対策として成功するのかは、蜜結合MIMD型のマルチプロセッサの特性を
活かしたデータ圧縮技術かなと考えています。アプリの前提を取り込んだ圧縮アルゴリズムの開発で、
劇的な性能向上が見込めることです。つまり大企業の技術独占より、
パソコンを作って多くの人に考えてもらえるよにすればメリットがあるということ。
技術を売れる先は、考える必要があると思います。
社会が冷たいことを僕は知っています。
税金を使うことなく開拓をした人を支えることも考える必要があると思っています。
トランジスタの技術2021年3月号のFPGA特集
で取り上げられたDigilent社 BASYS3(ザイリンクス社 Aritx-7搭載)があれば、
時間さえあればVattlesを1人で作れると思っています。
ここ最近、産業スパイによって失われた1年半があれば、僕1人で販売までできたでしょう。
激安な開発費の結果、価格を抑えることができて爆発的なヒット商品になったかもしれない。
要するに、この国が傾くのは産業スパイの問題であって、僕に喰らいついている産業スパイを、
どうにかしないと、日本の産業が発展しないということが言いたい。
またCPUの動作原理を学ぶハード教材は、最近増えていますが、簡単すぎるものが多く、
Vattlesを構成するICF3-Zは、
現実を見ることができるので、僕はいいかなと思っています。
ICF3-Zは8bitなのでCPU開発の弾圧を逃げ切ります。
そして仮想マシン機能で32bit CPUっぽく動作します。
ICF3-ZのCPUアーキテクチャは僕による独自のアーキテクチャなので、海外CPUによる
技術差し止めを喰らうことがない、ということに魅力を感じている人もあるようです。
命令セットがハード依存しているので高性能化ができない問題がありますが、
これは弾圧されにくいことに役立つので、むしろメリットとなっています。
ただ僕が最重要だと思っているのは暗号プロセッサSnakeCubeです。
あまりVattlesに時間をさけないのが、辛い。
超軽量のCPU WZetaの作品を応募。
elchikaのハードウェア作品投稿キャンペーンの
審査が通過しました。8bit CPU ICF3-Zの投稿も
あったのですが、応募していませんでした。
応募していませんがWZetaと同じ制限の緩いライセンスなので、よろしくお願いいたします。
ICF3-Zを使った8bit並列パソコン
に興味を持たれた方もあるように思っています。こちらもお気軽にご連絡ください。
僕はまだ産業スパイに喰いつかれた状態なので、まだ難しいことが多いようには思っています。
そういう状態のため審査に通るとは考えていなくて、感激していて、
審査通過のプレゼント、どうしようかと困惑しました。
結局、プレゼントは貰わないことにします。
WZetaはサイトでダウンロードできるverilogなどのソースコードを近日中にgithubで公開予定です。
審査をしていただいた秋葉原の店舗の皆様、elchika運営事務局の方々、
ありがとうございました。
昨日、「RSA暗号が破壊された」というツイートが世間を騒がせたようです。
量子コンピュータによる解読ではなく通常のコンピュータで
高速な解読方法の論文が公開されたようです。
まだ確認はできていないようです。
現在、最も使われているRSA 2048bitです。
仮に、このニュースがRSA 2048bitの解読にかかる時間が100年だったのが
1年くらいになったから、かなり危険な状況になりましたというニュースだとします。
SnakeCube
が間に合っていれば鍵長を大きくすることで、少しの間を
凌ぐことができたのにと、後悔していたに違いありません。
もし、これが現実のものとなれば世界が大きく混乱し、
その対応に、より大きな金額を投入することになったのではないでしょうか？
その責任は産業スパイや、SnakeCube開発を妨害する人々にあると考えます。
今回は、まだRSA暗号が破壊できていなかったとしても、半年後、改良型あるいは、
新しい解読法によって、世界が混乱に陥る可能性があるかもしれない。
これ以上、産業スパイにSnakeCube開発の妨害をさせてはいけないと思います。
WZeta
はトランジスタ数が非常に少ないというだけでなく32bitの命令コードを8bit単位に
送信できるところも良さそうだと気づいた人があったのかも。
１チップに入れる場合は、目立たないのですが、基板上で配線する場合は32本より8本のほうが配線しやすいはずです。
さらに1本で8bit分を転送する実装にすれば基板の配線実装が、ぐっと楽になって
コスト低減になると思うのです。
複数の配線でデータを送信するとビット間スキューの問題で手間がかかるのです。
１本ではビット間スキューがないので基板上での配線が楽になるというもの。
実は僕は大型コンピュータの基板実装のビット間スキューを最小にする設計で、
大きな成果を上げて給料をもらっています。僕が担当したのは
IBMのCPUを採用した大型コンピュータなのですが、IBMのCPUとつなぐ日立のCMOSデバイスの性能が悪かったのです。
僕のビット間スキューを小さくする設計などにより、IBMとほぼ同等の性能になったことが大きい。
(東大卒が多いハード開発部にいた人間でプログラムが自在に作れたのは僕くらいだから)
つまり、1本でシリアル転送できることは、普通の人が思っているよりも
コスト低減になるだろうということなのです。、、、多分。
|
