|
一般的にはメモリの高信頼化はECCが多い。しかし8bit CPUのような
小さいCPUではECCの実装が難しいこともある。そこで16bit固定長の
命令コードのうち2bitを高信頼化のために利用する案は、ある。
最上位ビット(高速モード)とハードマクロのビットの２ビットを
高信頼化のために使ってもWZetaは問題なく動作する。
同じ8bit CPUのPICには命令コードが14bit固定のCPUがありますが、
WZetaではモード変更によって高速モードにすることも可能。
自動車などでは、余裕があれば、いくらでも高信頼化しておきたい
ということもあるように思います。
自動車の製造について知らないので、全くわからないのですが、
電気自動車で需要があるかもしれない。
WZetaのコード密度を改善するために即値の加算命令の追加を検討。
命令セットの美しさの観点からINCX/DECX命令を高速モードへ移動させるかも。
基本的に高速モードがデフォルトだと考えているので、大きな影響は無いのですが
INCX、DECXのオペコードが変更される点だけ。
アセンブラをバージョンアップすれば自動的にオペコードが変わるので影響は無いはず。
INCX/DECXを高速モードへ移行した場合は、日記で連絡致します。
参考情報くらいの日記です。
現在、8bit CPU WZetaの開発しているため8bit CPU
ICF3-Zの開発が完全に停滞していますが、プロジェクトは存続しています。
ICF3-Zについて知りたい方は数年前にしたプレスリリースが、まとまっているので、
そちらをご覧ください。
「ICF3-Zプロジェクトが制限の緩いライセンスの オープンソースのCPUをGitHubに公開」
2020.06.12 11:00
https://www.atpress.ne.jp/news/214871
ICF3-Zは小規模な8bit CPUにしては16bit ÷ 8bitが高速です。
32bit CPUでも割り算の無いCPUも存在しているためICF3-Zが便利なケースがあります。
WZetaよりも、さらにコード密度が低い欠点がありますが、WZetaと同様に
ハードマクロ命令128個が使えます。昨日の日記でWZetaも
ハードマクロ命令128個拡張したので、この128個のハードマクロ命令で仮想的な
CPUを作れば、同じコードがICF3-ZとWZetaで動きます。
趣味的には面白いのですがICF3-Zの整備がまだ終わっていないので、すぐにはできない。
ICF3-Zは乗算命令というものはありませんが、その特殊なアーキテクチャで、
ソフトウェアによる乗算命令よりは、高速に演算可能です。
その仕様がWZetaのMULX命令と同じなのでWZetaと同様にモンゴメリ乗算が高速に
演算可能だと思われます。
A × C + B → BC
WZetaのアプリを開発していて除算の性能が足りない場合、ICF3-Zという選択が、
将来可能になるかもしれません。今はWZetaの開発を進めていきます。
各社の8bit CPUの乗算命令仕様について調べました。公開鍵暗号の性能を評価します。
結論を先にいえばハイエンド8bit CPUのAVRですら命令仕様レベルでWZetaの半分以下の性能。
IoTデバイスでサーバーと接続するマイコンのCPUはWZetaが良い。
Z80 乗算命令無し
8051 MUL AB ; A×B → BA
AVR MUL ; Rx × Ry → R1:R0
WZeta MUL ; A×C → CA
WZeta MULX ; A×C + [0] → [0]:A
AVRのMUL命令は繰返し同じ乗数を利用できるので多少、8051より高速。
8051は大容量メモリにアクセスする場合のメモリアクセスが非常に遅いので、
公開鍵暗号の性能を考えること自体が間違いではある。
WZetaのMULXの[0]はメモリ0番地の1バイトを表しています。
このMULXは命令仕様レベルでAVRの4倍、公開鍵暗号が高速に演算できます。
ただしAVRはWZetaと比較してトランジスタを大量に使用しているので実測値はAVRが
高速になることはあるかもしれませんが、トランジスタ当たりの性能ではWZetaが
圧倒的に勝ります。
WZetaは8bitレジスタ3個ですがAVRは32(16)個です。
AVRの5倍、10倍効率の良いWZetaを、ご検討ください。
補足
MULX命令は一見すると凡庸な仕様に見えますが、
公開鍵暗号は普通の乗算ではなくてモンゴメリ乗算を使います。
これが8bit×n bitのような細長な乗算でも可能なため専用演算器がなくても
キャリーが溢れるないという事実まで突っ込めないと、この仕様は出てこない。
WZetaは8bit CPUとしては、RSA暗号や楕円暗号などの公開鍵暗号が
非常に高速です。RSA検証は、最もお得な使い方です。
例えば気象観測用のIoTデバイスでは、サーバーからの制御コマンドをAES暗号による
メッセージ認証で行う場合、AESの鍵が漏洩するとIoTデバイスの制御を奪われて
遠隔操作されてしまいます。
RSA検証と併用すればAESの鍵が漏洩しても正しいサーバーからの制御コマンドかどうかを
判定できるので安全です。
WZetaが無ければ高性能なマイコンが必要になるアプリも、あると思います。
チップ製造に詳しくないのですが、WZetaはチップ内にメモリを内蔵する必要がないため、
他のCPUと比較して、かなり安価なチップ製造装置が利用できるのではと思っています。
このことは意外とポイントかも？
新規命令の動作検証をするつもりがハードマクロ命令の拡張を思いついたので
早速、verilogコードに実装してverilogシミュレーションをしてみました。
シミュレーションは、取り急ぎ、うまくいったみたい。
ハードマクロ命令で仮想マシン(仮想CPU)を作るためには64個では
不足かなと思ったので高速モードでは128個を使えるようにしました。
WZetaの命令コードは16bit固定長ですが最上位ビットはモードによって
命令コードのパリティビットにすることが可能です。
これはWZetaが世界に必要とされる機能のひとつになるように思っています。
他のCPUで、こんな機能は見たことがないし、他のCPUを参考にして作った
機能ではない。PICに命令コード長が14bitのものがあるので、もしかすると
実装によってはコードにパリティを追加したものができたのかもしれない。
全く知りませんけど。
命令コードにパリティビットを割り当てるとコード密度が下がり
他のCPUと比較して劣勢を強いられることにもなるので、
モードで切替える方式になっています。
しかし命令コードにパリティがあれば安価なパリティ無メモリで高信頼を得られます。
通常、パリティ有りメモリは8bit単位ですが、WZetaは15bit単位で、しかもデータには
パリティは付きません。パリティ有りメモリの信頼性に及びませんが、
信頼性の多少低い、安価な不揮発メモリを使える利点は、大きいと思います。
パリティが無いと不揮発メモリの経年劣化を見つけにくいので、
過剰品質な不揮発メモリを使わざるをえず地球環境的にも良くないと思われます。
僕はメモリメーカーを訪れたことはないので、メーカーが、どう考えているのか、わからないですけど。
WZetaのパリティモードは、一般家庭の室内に置かれるCO2メータなどの用途では便利だと
思います。自動車などの用途では、これまで通り、信頼性が必要ならば、パリティ有りメモリを
WZetaに付ければ良いのです。
参考情報の追加
AMD/XilinxのFPGAデバイス専用の8bit CPU PicoBlazeが、以前、存在していました。
扱えるデータ領域が1KB未満のCPUなのでWZetaと比較できるCPUではありませんが、
このPicoBlazeは18bit固定長の命令セットで通常のパリティビットも
命令コードに使っているCPUです。
余談ですが16bit固定長と18bit固定長を比較して、この2bit差が大きいという
感想を持った記憶があります。非常にトランジスタ数当たりの性能が高い。
ですがパリティビットをコードに利用しているために一般に普及させることは、
かなり難しいと思われます。
PicoBlazeの説明にはパリティビットが無い問題を対策するために
クローラーを推奨していました。FPGA上のSRAMはデュアルポートメモリなので、
PicoBlazeの実行中に、同時にクローラーでメモリエラーを検査可能です。
なので、この方法でも対策可能です。
ただしデュアルポートメモリでなければ、頻繁にクローラーでチェックすることは
難しくなります。
WZetaのほうが早期に発見できるので、WZetaのほうが信頼性が高いです。
そしてメモリのエラーの他、宇宙線などのエラーも拾えます。
ネット上の偽のAVRの性能情報を受けてWZetaの性能向上を推進してきました。
乗算命令(MUL/MULX)、16bit転送命令(MOV)、16bit加算命令(ADD AB)は、
思ったよりもうまく実装できたので、トランジスタ数当たりの性能向上、
コード密度の改善がされました。まだ見込みですが、うまくいく予想。
新規命令の動作検証作業の後、仕様公開をしますが、
verilogコードの公開には、産業スパイ(悪組織)の問題を、どうにかして
欲しいと考えています。
WZetaは今後、急増するセンサーデバイスで使われる通信プロセッサとして最適です。
新規命令を追加しても8bitバスのままで極小のマルチプロセッサが作れます。
IoTデバイスはマルチプロセッサのほうが向いている場合も多く、
そしてマルチプロセッサの欠点をWZetaのゼロ遅延マルチコアは対策できます。
この新規命令を追加したverilogコードがRISC-Vのようなオープンソースで
公開されれば、理系の先生はWZetaによる省資源技術を教えることで生徒に価値ある
授業が可能になるし、文系は8bit CPUの乱立を防ぎ無駄な税金を省ける利点を活かすことが可能になる。
ネット上はWZetaのマシン語情報でにぎわうし、雑誌も特集でビジネスが増える。
いいことが多い。verilog公開後のメンテナンスには費用が必要なので、
僕が8bitパソコンを作って利益が出るように考えたいのでご協力願います。
産業スパイ(悪組織)の問題を対策してください。よろしくお願いいたします。
[速報]
昨日の日記に書いた16bit加算、相対アドレス演算命令をverilogコードに
追加して論理合成してみました。バグが無い保証は無いので速報ということで。
WZetaのVivado2022.2による合成結果
133MHz、543 LUT、159 FF
28LUTの増加で16bit加算、相対アドレス演算命令を追加できたのは、
相対分岐用の16bit加算器を流用できたから。133MHzが達成できたものの133MHzに
成功するケースは、面積重視の合成結果から、ほぼ無くなったので、実質的なディレイは多少、
増加していると思われる。
これまで不得手だったアプリの性能が上がって、プログラミングしやすくなっているように感じます。
皆さんの、やる気が出てくれると良いのですけど。
まだ16bit転送命令の検証が十分に進んでないのですが、
コード密度の更なる改善のために16bit加算と相対アドレス演算(16bit)の命令の追加検討を始めました。
ADD AB,C ; AB + C → AB
続いてADD A,[m]の命令を実行すればAB + [m]C → AB の16bit加算が可能。
ADD AB,PC ; AB + PC/2 → AB
相対アドレス演算。リロケータブルな実行バイナリを作るのに便利。
これでオレオレ言語とか、作りやすくなると思う。
[速報]
一昨日の日記に書いた2バイト転送命令のMOV命令をWZetaの
verilogコードに追加して論理合成してみました。
昨年、CC0で公開した1024bitのべき乗剰余のコードに乗算命令とMOV命令の修正を加えて
verilogシミュレーションをした結果、正しい演算結果が出力されました。
まだ十分に検証できていないので、取り急ぎの速報ということで
WZetaのVivado2022.2による合成結果
133MHz、515 LUT、159 FF
軽量な8051互換のCPUの半分のトランジスタ数で２倍以上の性能、
なおかつコード密度の弱点が改善されました。
MOV命令の直後に配置できる命令は若干制限されますが影響はあまり無いと思われます。
MOV命令は次の命令にはみ出しますが正しく実行できます。
例えばサブルーチンからのリターンで良く使われるコード
MOV AB,[m:B]
JMP A:B
サブルーチンの先頭でリターンアドレスを格納するコード
MOV [m],AB
LD A,[x]
MOV命令によるAレジスタの書込みは、次のLD命令の4サイクル目
(最後のサイクル)で行われます。同時に[x]の値がAレジスタに設定される。
MOV命令のAのライトより先にLD命令のリードが行われている。
ポストストアと呼ばれる方法。日立の日本語では、置いてけぼりストア。
WZetaは動的に行うのではなくて静的にしています。全命令4サイクル固定のはみ出し実装などという実装は、
トランジスタ数を最小にすることが目標なCPUでしか無い実装ではないだろうか。
産業スパイに能力、時間を削られ３％くらいまで処理能力が低下しています。
低下した処理能力で開発運営をするためにドキュメントの整備が遅れています。
3月23日公開のシミュレータに付属するアセンブラのドキュメントも酷くて、
とりあえず、少し直したものを、この日記にアップロードします。
自分用のメモなので、参考程度に。次の機会に、この日記ごと削除すると思います。
WZetaアセンブラ仕様2023_03_25.pdf
それほど進捗は無いのですがMOV命令の実装がうまくいっていないと
思う人があるかもと思ったので。
MOV命令のオペコードに0x00を割り当てました。オペランドが0x00の場合は、
これまで通りNOP命令として解釈されるように作っています。
ところがシミュレーションがうまく動かなくなりました。
原因は、アセンブラが生成するコードの冒頭に置かれていた0x00 0x00が
初期値不定の状態のためにハザードの連鎖を起こしてシミュレータが動かなくなっていた。
そこでNOP命令(0x00 0x00)の代替として影響の無いLD B,0xC9(0xC9 0x03)にして対策。
なぜMOV命令以外だとハザードを起こさないのかと言えばMOV命令は、
次の命令にはみ出すので、はみ出し処理が0番地のコードでは不定の値を参照しているからだと思う。
昨日、LD AB命令の予告を書きましたが、これをMOV命令に差し替えました。
名称が変更されたことと2バイトロードの他に高速モードで2バイトストアを実装検討。
実装してみてMOV命令を追加します。
命令の追加のみなので昨日のシミュレータに影響はありません。
Z80には2バイト(16bit)転送命令が有ってWZetaには無かったのでWZetaの
コード密度は低いと感じた人があったかもしれない。
Z80はCISCでコード密度が高いことが特長です。
一方、WZetaはマイクロコードの無いRISCなので16bit転送命令の実装は厳しかったのです。
WZetaのコード密度が低い弱点は設計した時点から決まっていたことで、
これを補うためにハードマクロ命令というものを導入しています。
ただしハードマクロ命令はコード密度の欠点を十分に補う一方で性能低下が著しい。
そこで、どうにかして16bit転送命令を追加することを考えました。
MOV AB,[n] ; A←[n+1] , B←[n]
WZeta SDogコアでは1命令4サイクル固定なのでMOV(ロード)命令は次の命令に、はみ出します。
はみ出しても次の命令の実行に影響が無いようにしてMOV(ロード)を実装します。
そして任意のタイミングで割込みを受け付けることが可能なMOV(ロード)の実装にします。
はみ出しの影響でMOV(ロード)の後に続く命令がMUL/MULXや即値の代入、
即値の論理演算などの命令では正常に動作しなくなりますが、ほとんど影響は無いです。
即値命令が正常に動作しない問題は対策可能ですがトランジスタ数を節約するため。
MOV(ストア)命令は高速モードのみ実装される命令で、この命令の実行中は割込みができない他、
直後にメモリストアがある命令は正しく処理されません。BAL/BR系の命令も不可です。
ただ、大きな影響は無いと思います。
MOV命令によってレジスタ間接を使うアプリが高速化される他、
サブルーチンが高速化されます。そこそこ弱点が補強されたと思います。
この新規命令を実装していくうちに予告内容と変わってしまったので
改訂版の日記を書きました。
乗算命令やLDX命令を追加してWZetaのシミュレータを復活させました。
次のURLからダウンロードできます。自分用のドキュメントしか添付していないので、
わかる人しか、わからないかもしれません。
https://deadloop.icf3.net/wz660/WZetaSim2023_03_23.zip
SHA-1のハッシュ値 : e84c926a7cbf97490b54a8befe20f8a4e5c81605
Win10のアセンブラとシミュレータの実行ファイル(バイナリ)の他に
Windows2000以降向け、Win95以降向けのバイナリが入っています。
SHA-1を演算するサンプルのアセンブラ・コードがあるので、
まずそれで試してみることが可能です。
論合成で実際に使ったverilogをicarus verilogのシミュレータで動作する
icarusのバイナリも添付しています。WZeta SDogコアのverilogファイルが、
恐らく実際に作られていることが、わかると思います。
C言語シミュレータだけでなくverilogのシミュレータで
自作アセンブラコードを試せます。verilogのバイナリなのでicarusの
バージョンによって動作しない場合があります。
バージョン10とバージョン11で動作するものが含まれています。
Windows版のicarusはバージョン11でも内部がバージョン12になっていて、
動作しないことがあるようです。
8bit CPU WZetaは軽量な8051互換のCPUの
半分のトランジスタ数で２倍の性能が出でそうです
トランジスタ数当たりの性能４倍なのです(3月15日の日記)
このくらいあるとWZetaを期待できそうです。WZetaはプログラマのマシン語テクニック
によって性能が上がるのでマシン語テクニックを覚えて「トランジスタ数当たりの性能４倍」
のCPUで、ものづくりができる有利を活かすというのは、どうでしょうか？
WZeta公式サイトでWZetaの命令セット仕様、LDX命令を追加したものを
公開(3月19日版)しました。
先日、subnoteのサイトを閉鎖したためWZetaのシミュレータがダウンロードできなくなっています。
数日以内にMUL/MULX/LDX命令を追加してダウンロードできるようにする予定です。
8bitパソコンWZ-660のエミュレータが入っていいましたが、実際にハードウェアを作って
キーボードの動作を確認して、エミュレータと同様の動作になるように調整を
したほうがいいと思っているので、今回のダウンロードではWZ-660のエミュレータは入っていないです。
頭もちょっと辛い。自分の書いたプログラムが外国語に見える。
昨日、検討した新規命令のLDX命令を追加してAMD/Xilinxの論合成ツール
Vivado(2022.2)で合成してみました。
追加前
133MHz、487 LUT、151 FF
追加後
133MHz、503 LUT、151 FF
LUTが約3.3%増加しましたが、LDX命令の追加によってコード密度が上がり、
アドレス計算が高速化されるのでLDX命令の追加は効果的です。
WZetaの弱点であるコード密度が低い問題を改善するために新規にLDX命令の追加検討します。
これまで作られたコードに、ほぼ影響しないのですが念のため早めに日記に書いておくことにしました。
追加される命令は2つ
LDX A,n ; A=n, B=A
LDX A,[n] ; A=[n], B=A
オペコードは高速モードのビット(opmsb)を1にしたLD B,nとLD B,[n]です。
高速モードではopmsbを1にするとBレジスタのインクリメントを同時に実行しますが
Bレジスタにロードする命令では意味の無い命令となるため、新規命令を割り当てることができました。
16bitのメモリ空間から1バイトを取得するためには、16bitアドレスを計算してA,Bにストア
LD x,[A:B]
として取得します。演算機能はAレジスタにしかないので下位バイトをAレジスタで演算して、
LDX命令でAにロードしながらAの内容をBにコピーできます。
C言語のchar配列aから3番目のデータを取得するには
LD A,3
ADD A, %aL
LDX A, 0
ADDC A, %aH
LD A,[A:B]
char配列が256バイト境界をクロスしない場合
LD A,3
ADD A, %aL
LDX A, %aH
LD A,[A:B]
新規のLDX命令のおかげで1命令少なくなっている。
subnote閉鎖に伴なってサブサイトにWZ-660のサイトも閉鎖されています。
8051は1980年代に登場した8bitマイコン。
今更ながら8051の命令セットアーキテクチャを勉強しました。
オリジナルの命令セットでは内蔵RAM 256バイトをアクセスする方法は豊富ですが、
外付けRAMのアクセス方法が極めて貧弱なため扱うデータが200バイトを
越えるアプリでは使うのを避けたほうがいいくらい。
詳しくは命令セットを確認してください。
互換メーカーによって命令セットが拡張されていますが、
後付け増築ではトランジスタ数当たりの性能を追及するのは厳しいものとなったはず。
WZetaに勝ることは、無さそうです。
産業スパイが8051互換のトランジスタ数の評価が不当だと主張している。
8051の内蔵RAM256はCPUではなくてメモリとして扱うべきではないだろうか？
というものだ。
しかしながら基板上にメインのSRAMを配置する場合、8051の内蔵RAMはCPUと
同じチップ上に置かれる。CPUの一部が妥当ではないだろうか(SIP含む)。
またSoCの場合、チップ上にSRAMが配置されるためメモリ扱いに
できるかもしれない、しかし8051互換は通常のSRAMの他に256バイトの
SRAMを別に用意しなければならないため、他のマイコンのダイを共有できず、
製造コストが上がる要因になる。
恐らく現在でも、ダイ共有の話は同じだと思いますが、確認していません。
確かに1バイトを3LUT換算するのは、かなり適当かもしれない。
1バイトをフリップフロップで作った場合のLUT数は実装に大きく影響するけど、
8LUTを下回ることは無いと思う。
前述のような理由のためWZetaが8051互換の半分以下のトランジスタ数になるように
逆算して3 LUTになっています。
僕の人生の成果に対する正当な人生を得たいと考えています。
そのために多大な努力を今日までしてきました。
かなり違法な方法で僕の周囲をブロックしている人たちを、どうにかするためには、
SNS Misskeyのmisskey.ioサーバー寄付の値上げが必要なのかもしれないと思うようになりました。
しかし収入ゼロのままなので、寄付の増分には足りないのですが
subnoteを運営している
レンタルサーバーとActivityPub投稿リレーサーバへの寄付を無くしてmisskey.ioに集約することを
検討中です。
subnoteのレンタルサーバー費 150円/月
ActivityPub投稿リレーサーバ費 120円/月
misskey.ioの寄付増分 $3 ( $2→$5 )
効果は期待できるだろうか？
WZetaの命令セット仕様を更新しました。乗算命令(MUL/MULX)が追加されています。
まだ、これまでと同様のβ版です。
https://wzeta.idletime.tokyo/download.html
設計図に乗算器を追加しました。小型高性能なのはデコードする前から
乗算を開始しているため。
WZetaのコンパイラ開発に興味がある人もあると思います。
1980年代の8bitパソコン時代には趣味でコンパイラを作っている人が多数、
いました。
中学生だった僕も大好きで雑誌I/Oの広告を見てBAISCコンパイラ(WICS)
を大阪、日本橋まで買いに行くほどでした。
WZetaは税金を使わない方針なので、当面は趣味でコンパイラを作る人がメイン
なのかと思っています。ただし税金の例外があってWZetaを使うほうが
税金が少なく済むケース。これが無いとは言い切れないと思っています。
つまりCコンパイラを頑張って作っても、大手にCコンパイラを開発されてしまうと、
自分のコンパイラは、注目されなくなります。そのあたりを考えながらやってもらえると。
乗算命令などのオプションが多数あるとコンパイラの開発が
大変です、と言う人もあったので回答すると
乗算命令MUL、MULXの２つセットでオプションにすることを考えています。
乗算命令の有無でバイナリを２つ用意できるなら、コンパイラは無のバイナリでは
MUL/MULX命令のコードをソフトウェア割込みに置き換える方法があります。
ハードマクロ命令を利用する方法もあると思います。
同一のバイナリで両方動作させることは、ハードマクロ命令を使うことで
可能になりますがBIOSとかHALをしっかり定義してからのほうが良いかも
しれません。自身でHALを定義してしまう方法でも構わないのですが。
まだ命令セットの仕様を更新していません。数日中に更新する予定です。
乗算命令を追加したWZeta
をAMD/Xilinx Vivado2022.2(最新版)で論理合成できました。
ボードはDigilent Arty、256ケースの論理合成をして最も数字の良かったデータです
133MHz、487 LUT、151 FF
比較するのはlight52
Xilinx Zynq (-1)はArtyと同じArtix-7なので直接比較できる数字になります。
62MHz、811 LUT、SRAM 256バイト
かなりいい加減な換算になりますが1 FFを1 LUT、SRAM 1バイトを3 LUTにしてみます。
WZeta : 638 LUT
light52 : 1579 LUT
ざっとWZetaはlight52の半分のトランジスタ数と言えそうです。
WZetaは1命令4サイクル、light52は平均1命令5サイクル。周波数を考慮すると
light52が1命令を実行している間にWZetaは約2.6命令。
1命令当たりの処理量はWZetaのほうが低いことを考慮しても２倍程度の性能は出そうです。
CPUとSRAMが同じチップ上に無い場合は基板上のSRAMをアクセスすることになるため、
性能差が小さくなることはあるかもしれません。その場合はWZetaは、
もっと遅いトランジスタで良いはずなのでCPUチップの原価が下がるのかな。
参考までに言えばlight52はハーバードアーキテクチャ、WZetaはノイマンなので、
独立にアドレスバスが必要なlight52のほうが、ちょっと資源的に厳しい場合があるかな。
速報結論、WZetaはlight52の半分のトランジスタ数で２倍の性能が出そうです。
WZetaが得意な公開鍵暗号では5倍以上の性能が出そうなきがしていますけど。
地球環境に良いCPUとしてWZetaが全世界的に普及しそうな気がしませんか？
昨日作った設計図からverilogファイルを作成してWZetaのverilogに接続しました。
このverilogはシミュレーション専用ではなく論理合成が可能なverilogです。
乗算命令による高速化を行ったRSA(1024bitべき乗剰余)演算のコードを
verilogシミュレーションで動かしました。
verilogシミュレータが正しい答えを出力しました。
このverilogのコードをAMD/Xilinxの論理合成ツールVivadoで論理合成すれば
FPGAによる実機で動かせるものになります。
論理合成結果のLUT数やフリップ・フロップ数からトランジスタ数が、ある程度、見積もれます。
これを他のマイコンと比較すれば、WZetaの効率が見えてくると思います。
みなさん、WZetaの効率を知りたいですよね。
産業スパイがサイバー攻撃で、事実を隠ぺいしてくるかもしません。
サイバー攻撃をさせないように、よろしくお願いいたします。
長期的には、産業スパイを僕から剥がさないと開発は進まないので、剥がす方向でお願いいたします。
剥がしてもらえれば、この実験で使ったverilogをRISC-Vの実装で使われているようなオープンソース
のライセンスで早急に公開するようにします。
WZetaのアーキテクチャに馴染んだ軽量で高性能な乗算器の設計図が書けた。
僕の頭と体が元気なら20分くらいで描けるの規模なのだけど。
モンゴメリ乗算の方法について考える
例えば、A = A + B + Cを高速化する場合、A,B,Cをメモリからリードして
Aに書き込めばメモリアクセスは4回と加算2回。
一方、A=A+B,A=A+Cとして演算すると6回と加算2回。
高速化を考えるなら前者しか無いと思うだろう。
前者で高性能な演算器を作るのかもしれない。
あえて後者を選択してみると、キャリーフラグ１つで
足りるため専用の乗算回路が不要であることに気づく。
それでもRSA暗号が３倍高速になって、しかも非常に
小型の乗算器で乗算命令の追加ができたという話。
ツイッターで西さんが誰でも参加OKという投稿をしていたので
MSX0(IOT)のZOOMを見てみた。午後１時から２時くらいまで。
西さんいわく
「大企業の開発エンジニアが良くコメントしている『自分が欲しいものを作った。』
(MSXはそうじゃない。)」
MSXへの想いを語っていた。
僕も8bitパソコンWZ-660を開発中です。Z80の数倍、あるいはそれ以上の効率を持つ8bit CPU
WZetaが売りです。
一般の人がWZ-660を欲しいと思う理由は何か。
今後、世界のいたるところで使われることになりそうな？CPUを勉強してみたいだと、僕は思っています。
実際には8bit CPU WZetaの仕事で給料を貰える人の数は、決して多くない。
しかしWZetaは最小の資源で要求仕様を満たすという学問を作り出します。
IoT系アプリでは2コアが効率的なものも多いのですが、
2コアの欠点であるシングル性能が低い問題をWZetaは解決します。
WZetaは理系全員が学習するCPUになるわけなのです。
僕の希望ではないのですが、多くの人のことを考えるなら、
MSX0のCPUを早い段階でZ80からWZetaに切替えて、世界の生産性を上げ省資源CPU、
WZetaの普及を加速して地球環境対策にしていければと思いました。
Z00MではC言語とBASICを推奨していてアセンブラはお薦めしていないと発音していたので、
WZetaへの切替も、全く無理な話ではないのかも。
西さんは、みなさんの意見をききながらMSXを推進するということらしいので、
みなさんが、意見を出してみれば、実現するかもと思ったのですが、、、
僕の勝手な感想で、すいません。
乗算命令を追加したWZetaを搭載した8bitパソコンWZ-660は比較的高い優先順位で開発していく考えです。
乗算命令を追加したWZetaは産業スパイによる妨害でFPGAへの実装が出来ていませんが、
シミュレータでRSA暗号が３倍高速になりました。
基数2^8のモンゴメリ乗算を使って1024bitべき乗剰余を計算させるコード作り、確認しました。
恐らくFPGAでも３倍高速であることが検証できると思われます。
乗算命令の追加の他、DEC命令を修正しました。先日、INC/DEC系の命令、すべてを修正するかもしれないことを
日記に書きましたが、DEC命令だけ。メモリ124番地と125番地をデクリメントする場合はCFは変化しません。
産業スパイの妨害で高効率なWZetaの開発が遅れています。
SSH向けの認証ハードや暗号資産向けのハードウェアウォレットなど、安全に安価なものが作れるかも。
産業スパイによるサイバー攻撃でVivadoが動かない問題は、少し先送りにして、
乗算命令をアセンブラとシミュレータに追加しました。
基数2^8のモンゴメリ乗算のコードの開発に着手したところ。
CC0で公開した乗算命令無版のモンゴメリ乗算より数倍、
高速になるはず。コードをCC0で公開するのかは未定。
2021年7月25日の日記で一度、比較をしています。
大雑把な比較なので大きな誤差があると思いますが
WZetaは8051互換の半分のトランジスタ数で２倍の性能が出る予想になっています。
ただし、このときのWZetaには乗算器が無かったので乗算命令を使うプログラムでは
２倍の性能は出ませんでした。
今回、WZetaに軽量で性能の良い乗算器を追加する予定なので、もう一度、比較ができると思います。
現在の僕の予想では乗算命令を含めても、
8051互換より少ないトランジスタ数で２倍の性能。公開鍵暗号では、もっと差が開くのではと思っています。
現在でもIntel 8051互換のIPは市場に出回っている感じなので、
この予想通りならWZetaがオープンソースとなった場合の経済効果が期待できます。
WZeta開発が妨害されないように、よろしくお願いいたします。
昨日の日記に多倍長累積和のコードをWZetaとAVRで書きました。
WZetaはZ80のようにマイクロコードを持たないので複雑な命令を作れないのですが、
AVR、11命令に対してWZetaは3命令であることからも乗算命令の仕様が、うまくできたことがわかると思います。
ネット上に落ちていたAVRのRSA暗号の性能を見てWZetaの性能強化をすることにしました。
ところがAVRにあるはずの積和演算命令がAVRの命令セットの一覧に見当たらず、
またしても工作員に騙されたのかな？と思っているといころです。
騙されたのかは、ともかく性能強化をやり始めてしまったのでINC/DEC系の命令を
少し修正します。命令コードでレジスタ0-3を直接指定するケースではキャリーフラグを
変更しない仕様にします。乗算が高速化されます。
WZetaによる乗算のコアな命令列
LD A,[m:B]
MULX
!ADDC [n:B],A ; 高速モードB=B+1
-------------------
12cyc
AVRによる乗算のコアな命令列
AVRにとって最適なのか、わからないけどWZetaと同じ計算をさせた場合
R1=R10=0
-------------------
LD R2,R1 ; 2cyc
LD R4,X+ ; 2cyc
MUL R3,R4 ; 2cyc
ADD R0,R2 ; 1cyc
ADC R1,R10 ; 1cyc
LD R4,Y ; 2cyc
ADD R4,R0 ; 1cyc
ST R4,Y+ ; 2cyc
LD R4,Y ; 2cyc
ADDC R4,R10 ; 1cyc
ST R4,Y ; 2cyc
-------------------
2x7 + 1x4 = 18cyc
比較のためにWZetaとAVRの1cycを同じと仮定すると
AVRよりWZetaのほうが高速かもしれない。
この結果は、僕が公開鍵暗号の演算を高速化するために、
力を入れた結果だからだと思われ。まだ、このまま最後までいくのか、不明ですけど。
もしかするとAVRのシリーズには専用乗算器のあるものがあるのかもしれない。
普通のAVRの命令セットだと、あまり効率的なコードにならない感じ。
AVRの凄い人にコード考えてもらったほうがいいのかもしれないけど。
感覚的なことを言えばWZetaは、気合を入れた性能改善の結果、
AVRの10分の一のトランジスタ数でAVR以上のRSAの性能が出る。
根拠は無いので注意。
ARMと市場競合を避けるためWZetaの乗算命令の実装は先送りにしてきました。
ところが8bit CPUとしては重量級なのですがAVRの乗算性能が非常に高いので
AVRとの性能差を埋める必要があると考えるようになったため。
AVRアーキテクチャは32本の8bitレジスタがあって、それだけでも、
かなりトランジスタ数の多い8bit CPUです。
まだ検討中の案ですが高効率な乗算命令になりそうです。
だいたい次のような感じ。
MUL命令
A × C → CA
MULX命令
A × C + [0] → [0] A , B+1→B
LDST命令
[m:B] → A , A → [m:(B-1)]
ほんの少しトランジスタを追加しただけで使い勝手の良い乗算が可能になります。
思いのほか、素晴らしい乗算命令が出来て、ニンマリしているところ。
これから実際に検証していきます。
WZetaの売りであるトランジスタ数当たりの性能が、さらに向上した感じ。
PC Watch記事(2023年2月28日)
8bit MCUの夕暮れ --- (著)大原 雄介
8bit CPUの現在事情について、まとめてあるので、参考になるように思いました。
総じて8bit CPUの不利な面ばかりを集めているので、有利な面も合わせて
書かれていればなぁというのが感想です。
記事中の「8bit MCUの新製品」のところで紹介されていた台湾Holtek社の
独自8bit RISCコアについて命令セット・アーキテクチャについてHoltekの
サイトにあるPDFを詳しく読んでみました。
メモリ空間が狭くレジスタ間接によるメモリアクセスは無い？ようです。
非常に小さい8bit CPUなのでWZetaと比較できる規模では無さそうです。
「AVR DD」はAVRなので8bit CPUとしては非常に規模(トランジスタ数)の
大きいCPUなのでWZetaと比較して意味のある結果にならない。
「NoobsASIC」は教育向けの8bit CPUで、Holtek社の8bit CPUよりも、
さらにずっと小規模。教育用サンプルといった感じ。
僕の8bit CPU WZeta
と比較するのにIntel 8051が良さそうな気がしてきました。
SnakeCubeは僕が発明した暗号プロセッサで
大きな鍵長のRSA暗号でも非常に高速に演算ができる。
SnakeCubeは低コストなFPGAに実装しても高性能であることが2020年夏に実証されている。
FPGAのチップ上には、乗算などの演算が可能なDSPが多数、並べられており、SnakeCubeでは、
これらのDSPを簡易な配線でつないだだけで高性能が得られている。
2018年に僕が発明するまで、この配線法を発明できた人はなかった。
次世代ICカードでは、量子コンピュータによる解読に耐える新しい公開鍵暗号が実装されます。
一般的には多くのDSPを効率的に配線することで公開鍵暗号は高速化できる。
次世代ICカードに僕が参加すればSnakeCubeをベースとして新しい公開鍵暗号を高速に演算できる
実装のICカードを開発可能になります。RSAを高速化するために用意された多数のDSPによって、
鍵長の大きな新暗号を高速化できます。
もし新暗号に必要な鍵長が、案外、大きくなってしまった場合、世界各国で困ることが起きるかもしれません。
SnakeCubeベースのICカードは必要だと思われます。
SnakeCubeはRSA暗号が得意なアーキテクチャですが、楕円曲線も演算可能です。
楕円ではRSAより演算効率が下がりますが、楕円は演算量が少ないので問題はないのです。
SnakeCubeが得意な演算をより厳密に言えば
A×B mod P と A×A mod Pの同時演算 (A,B,Pは巨大整数)
この同時演算は実装上のメリットが非常に大きい
参考までICF3(1999年)
の実装もA×B mod P と A×A mod Pの同時演算が可能だった。
SnakeCubeはスレッドですがICF3は完全並列という違いはありますが。
RSA暗号は必要無いと言う人もあると思いますが新しい公開鍵暗号の安全性評価が
十分でない中、楕円１本で行くことを考えるよりもSnakeCubeベースのICカードが良いでしょう。
マイナンバーカードはRSA暗号を使っています。
このSnakeCubeベースのICカードならシステムによってRSAによる延命と
新暗号を使い分けることができるでしょう。
北海道に新工場を作ることになったRapidus株式会社の状況は、全く知りませんが、
最先端デバイスで安定性が不確実な半導体チップをマイナンバーカードで利用する可能性は
あるかもしれない。最先端チップと従来チップの２つをICカードに実装するのでコスト的に
高価になるかもしれませんが、マイナンバーカードの認証(署名も)ならば、
宇宙線によるソフトエラー程度なら、許容できるはずなので。
TSMCの熊本工場の半導体でも十分という可能性もあるかもですけど。
SnakeCubeのアーキテクチャはマルチチップでも性能が出るので、
もっと安価な半導体工場でもマルチチップが可能なICカード実装があれば、いけるかな。
まだ動作検証環境の構築をしています。Red Hatクローン以外のLinuxのことも考えて、
Red Hat標準の仮想マシンqemuではなくて自分でコンパイルしたqemuを使うことに。
使っているHDDがかなり老朽化しているのでバックアップ用のHDDを2世代用意。
初回のバックアップ１回で半日かかるので２世代分では、丸一日が消えました。
開発をする人は、大抵、両方を使っているのではないかと思いますが、
僕が両方を使うのは、好みの問題ではなくて、産業スパイによるサイバー攻撃を、
回避するため。嫌でも、僕は両方を使うことが決まっています。
雑談、昔、日立の認証局にいた日立の関連企業の若いエンジニアがWindowsしか
使えなかったことを思い出した。
若いエンジニアではLinuxを勉強する時間は、まだなくて、Windowsを勉強して、
アウトプットを出すことで、やっとだったのだろうと。
スラド記事
「総務省、セイコーら3社に時刻認証業務を初認定」
電子帳簿保存法についてご存知ない方はネットで調べていただけるといいのですが、
この時刻認証業務で使われるタイムスタンプサーバーで暗号プロセッサ
SnakeCube
を開発することは日本にとって重要だと思います。
量子コンピュータによる暗号解読のリスクをなるべく回避するにはRSA暗号の
鍵を大きくすることですが、鍵を大きくするとCPUではタイムスタンプサーバーで
要求される性能を満たさなくなります。暗号プロセッサSnakeCubeの性能が必要です。
SnakeCubeは性能の見積が非常に精密に出せる特殊なアーキテクチャです。
詳しくは僕のブログ
暗号半導体チップにおける『ナオキの法則』
をご参照ください。
国防予算が増える世情ですので、自国で暗号プロセッサを開発できる技術力の
重要性は高まっていることと思われます。暗号プロセッサを開発しなくても、
安全だと思えるCPUでも良いと考える人はあるかもしれない。
SnakeCubeは、鍵が大きくなればなるほど、CPUより高速になるので、
CPUでは得られない高いセキュリティを得られます。
量子コンピュータに耐性のある新しい暗号の安全性が安定するまでの間、
より高い安全を確保するためにタイムスタンプサーバーで暗号プロセッサ
SnakeCubeを開発することは重要です。
2007年～2012年ごろは、RSA 2010年問題や常時httpsの普及がありました。
このときRSA暗号の高速化の研究が盛んにされましたが、
2018年に僕が発明したSnakeCubeは、従来研究より3～10倍高速です。
鍵を無限に大きくしても効率を落とさずに性能を上げられる特長が優れています。
僕がいないとSnakeCubeは開発できません。
またタイムスタンプサーバーの開発の後、ICカードを開発すれば、
割安にICカードを開発できるような気がします。新しい暗号と大きな鍵の
RSAの双方を高速に演算できるICカードは、最も高い安全性となるため、
世界のICカードの最終防衛ラインとして、世界に需要があることも考えられます。
他ではできない大きな鍵のRSAを演算できます。RSAを高速に演算するための大量の演算器を、
新しい公開鍵暗号で流用させるので、最も高い安全性となるだろうと予想しています。
僕は2005年に日立にリストラされ酷い目にあってきていますが、
僕の処遇を考えていただければと思います。
かつて僕をリストラした日立と総務省が、このタイムスタンプサーバーを
担当しているのではと思っています。国民の皆さまは、
そのことをご承知おきくださって、日本の未来を作れるように
考えてもらえればと思います。
恐らく僕の生れから考えることになると思います。いったい僕は、誰の子供なんだろう。
実験施設で東大医学部卒の精子から作られた説が、最も安直な予想かな。
Red Hat Linux 9.1を使い始めましたが8.6では起きなかった現象が発生しているため、
これが産業スパイによる妨害か、否かの判定のために、
別のLinux 9.1で確認をすることを始めました。
そしてLinux 9.1を使ってみるのも産業スパイによる妨害なのかを、判定するためだ。
非常に無駄な時間を産業スパイに奪われている状況。
産業スパイに妨害され続けて進捗が無いので予定を書きます。
8bit CPU WZetaに8x8=16bitの乗算命令を、オプションで追加することを
一番最初にやろうと思っています。
MULCA命令(A × C → CA)
AMD/XilinxのVivadoで合成した結果も、日記に書くつもりですが、
Vivadoの最新版(2022.2)だと周波数の性能が落ちるみたいなので、
2022.1の結果になるかも。2023.1で改善されると良いのですけど。
これで、ますます8bit CPU WZetaを使いたいと思う人は、増えるように思っています。
Z80との比較でメインメモリの性能に対する性能がWZetaは低いということが見えてきました。
WZetaの勢いが落ちそうだったので、挽回させます。
暗号演算のことを考えていないことを除けば非常に良いオプション命令です。
WZetaに軽量な乗算器を搭載してオプションの乗算命令 MULCA(仮)を追加することを考えます。
軽量な乗算器なので追加してもZ80のトランジスタ数の
半分程度かなぁ？と思っていますが、確認はできていません。
1命令で8bitレジスタAとCを乗算して結果をレジスタCとAにストアします
A×C → CA
軽量であることを説明するために、乗算の仕組みを説明します。
わかりやすくするために以下の表記は正確ではないですが、
内部レジスタMを2ビットづつ右シフトさせがなら
最終的に16bitの結果を得ると思ってください。
WZetaの基本コア(SDogコア)は全命令が1命令4サイクルです。
第1サイクル A×C(bit1-0) → M
第2サイクル A×C(bit3-2) ＋ (M>>2) → M
第3サイクル A×C(bit5-4) ＋ (M>>2) → M
第4サイクル A×C(bit7-6) ＋ (M>>2) → CA
このオプション命令をハード実装することは非常に簡単で、
しかも1命令で簡潔するので割込みの心配が無い。
オペランドが無い命令なのでオペコード0x01の命令群に追加できるため
貴重な空いているオペコードを消費しない。
WZetaとZ80の比較でZ80のメモリアクセスがDRAMであることを忘れてました。
WZetaはSRAMを前提にした回路なのでリフレッシュ回路がついていません。
WZetaのリフレッシュ回路を考えると1命令4サイクルから5サイクルにすれば良いかも。
WZetaのサイクル数をZ80に換算するには2.5倍。
マイコンではSRAMが多いのでオリジナルのZ80をSRAM補正した場合を考えると、
オリジナルのZ80にあるM1のリフレッシュがSRAMになってもリフレッシュ以外の動作で
必要だとしたら、WZetaのサイクル数をZ80に換算するには2倍のままでも良いのかな。
8bit CPU WZetaとオリジナルのZ80と比較するためにはWZetaのサイクル数を2倍にして
Z80のT1サイクルとすれば良いことを昨日の日記に書きました。
ファミコン誕生物語 第4回にある
Z80の4分の一の面積の6502をファミコンのCPUとして決断した話は有名だと思います。
WZetaも多分、Z80の半分以下の面積だと思われます。
次のURLにZ80と6502でブロック転送の比較をやっているようです。
https://www.wizforest.com/tech/Z80vs6502/blockcopy.html
WZetaで同じ課題をやってみます。
400H から 200H byte を、600H にブロック転送する
------------------------------------------------
LD A,0x06
LD B,0x00
LD C,0x3F ; 0x3F(=64)回、ループ
block1:
STABP [0x04:B]
STABP [0x04:B]
STABP [0x04:B]
STAB [0x04:B]
LOOPINC ^block1
LD A,0x07
LD C,0x3F ; 0x3F(=64)回、ループ
block2:
STABP [0x05:B]
STABP [0x05:B]
STABP [0x05:B]
STAB [0x05:B]
LOOPINC ^block2
------------------------------------------------
645命令 = 2580サイクル
Z80 T1サイクルでは
2580×2 = 5160サイクル
上記URL(魔法使いの森)ではZ80が6502に勝ちました。
そのZ80でも9953サイクルなのでWZetaはブロック転送で2倍近く高速。
(WZetaのDRAM補正をすると2倍までいかない)
ただし、この高速な転送ができるのは、
転送元と転送先のアドレス下位バイトが同じ場合のみ。
プログラマは、この高速な転送が使えるようなデータ配置を考えます。
トランジスタ数で圧倒的に劣るWZetaがZ80に勝利するために、
皆さまのプログラミングテクニックを駆使してください。
そしてその素晴らしいテクニックを公開して、
皆で評価して楽しめる世界ができればと思います。
WZetaのシミュレータは昨年8月から全然、更新していませんがZ80と
比較するためのデータを得ることには使えると思います。
説明があまり無いので、わかる人しか、わからないものですが、次のサイトで
ダウンロードできます。まだお試し版ということで
8月22日 WZetaシミュレータ、お試し公開(13)
Z80にはマシンサイクルやT1サイクルの2種類のサイクル数が存在する。
このためWZetaのサイクル数と比較することが難しい。
メモリの性能を基準に考えるとわかりやすくなる。Z80のメモリタイミングは
Yamamoto's Laboratory 8ビット CPU Z80タイミングのサイトにあるものを勝手に参考にしました。
(M1サイクルのタイミングから)
WZetaの1サイクルはZ80ではT1で2サイクルと、ほぼ同じと考えられます。
(ただしZ80はDRAMなのでリフレッシュで遅くなっている)
WZetaにとってメモリの性能を基準にすることは不利です。
Z80はメモリ性能と比較して高い性能を得るためアーキテクチャなのです。
メモリ性能に対してトランジスタ数の効率を追及したWZetaと単純に比較するとWZetaは厳しいかもしれない。
ただしWZetaの半導体プロセスがZ80より楽になると思います。
またZ80が有利になるのはZ80の豊富なレジスタによる演算が主体でメモリアクセスが少ないアプリです。
メモリアクセスが多いアプリではWZetaとの差はあまりなくなるでしょう。
WZetaの命令セットには1命令でメモリをリード、演算、ライトする命令があります。Z80にはありません。
これが役に立つ多倍長演算などではWZetaのほうが、少ないトランジスタ数で高速ということになります。
マイコンではプログラムとデータの２つのメモリを使うことが多いため
WZetaは2コアにすれば2倍近い性能になることもあります。
同じメモリ性能のZ80よりも高速なアーキテクチャということもできる。
(ゼロ遅延なので2コアでシングルスレッドが可能)
WZeta SDogコアのデータメモリが1サイクル置きであることによって起きた魔法。
WZetaで8bit乗算するプログラムのサイクル数
ツイッターのTL上に乗算器の無い8bitで高速に乗算をする方法があったのでWZetaのコードを作ってみました。
テーブルを使わない省メモリ版の乗算コード
%R2 %R1 = %R0 × A
------------------------------------------------
ZERO %R1
ZERO %R2
; 下記の5命令を8回繰り返す
SHRC %R0
JRC0 2
ADD %R2,A
SHRC %R2 ;分岐してきた場合のCFを流用
SHRC %R1
------------------------------------------------
42命令(168サイクル)
512バイトのテーブルを使う高速版の乗算コード
原理 (x-y)^2 = x^2 -2xy + y^2
xy = {x^2 -(x-y)^2 + y^2}÷2
%R2 %R1 = %R0 × A
------------------------------------------------
LD B,%R0
SUB %R0,A
JRC1 4
SWAP
ST %R0,B
SUB %R0,A
ST %R3,A
LD A,[＆mulL:B]
ST %R1,A
LD A,[＆mulH:B]
ST %R2,A
LD B,%R0
LD A,[＆mulL:B]
SUB %R1,A
LD A,[＆mulH:B]
SUBC %R2,A
LD B,%R3
LD A,[＆mulL:B]
ADD %R1,A
LD A,[＆mulH:B]
ADDC %R2,A
SHRC %R2
SHRC %R1
------------------------------------------------
平均21.5命令(86サイクル)
先頭でx＜yだとxとyを入れ替えて必ずx-y≧0となるようにしている。
必ず x^2 ≧ (x-y)^2なので引き算でマイナスにならない。
Z80のT1サイクルにすると172サイクル。メモリ性能を基準にした性能では
Z80と同程度かな^^;
オリジナルのZ80よりも軽量なZ80互換CPUと比較するのがいいように思えてきた。
●参考URL
Z80版の乗算コード
https://piclabo.blog.ss-blog.jp/Z80Multiplication
このZ80版にはRET命令(10サイクル)がありますがWZetaではハードマクロ命令を使うことで0サイクルでリターンできます。
2022年1月1日より、改正電子帳簿保存法が施行され、国税関係の帳簿・
書類のデータ保存について抜本的な見直しが行われたようです。
タイムスタンプサーバーや民間などでもRSA暗号による電子署名で
大きな鍵を使いたいという需要はあると思います。
暗号プロセッサSnakeCubeが必要なのではないかと思うのですが、
いかがでしょうか。経済産業省の方や、電子署名を利用する民間企業の方とか。
お誘い合わせの上、僕に問い合わせてもらえると、検討できそうなのですけど。
大きな鍵が演算できるSnakeCubeはチップ面積が巨大になるのですが、
SnakeCubeのアーキテクチャは小さいチップを一列に並べても高速に
動作させることができます。
次のYouTube動画、AMDが小さいチップを組み合わせて歩留まりを
20%から50%に向上させて利益を上げたという話を聞いて少し感動しました。
「ムーアの法則は存続するのか?!超重要…後工程の材料最強企業登場!!」
https://youtu.be/-mxAWgm8r6A
つまり、かなり適当ですが暗号プロセッサSnakeCubeは非常に小さいチップに
分割しても高性能が出せるので非常に歩留まりが高いものが作れるのかなと。
SnakeCubeに耐量子暗号を追加するにしても、まずは１度、RSA/ECDSAのみで作って、
物理的な感覚を得て、耐量子暗号をどれにするのかを含めて、次世代SnakeCubeを
作っていくのだろうと。
他国の量子コンピュータによって領収書を改竄され脱税することもできるわけですし。
検討できるのか、わからないですが、とりあえず僕に連絡をいただけても、いいです。
僕の8bit CPU WZetaは他の8bit CPUの5倍高速みたいな感じだと
言ったからだと思う。同じ8bit CPU AVRのほうが高速と言いたい人が
あったので説明します。
AVRのRSA暗号の性能の分析結果のPDFがネット上に落ちていた。
素性がわからないので信憑性は不明だけどAVRが本当に高速に
演算できるということは理解できた。本当なのかは、わからない。
まずAVRは乗算器を持っているので比較対象外だと思っています。
AVRが高速なのはRSA暗号の演算に向いた乗算器であることと、
過剰なループアンローリングによるもの。
一般的には乗算器の回路規模は大きいので性能も向上しますが、
重量もそれなりに増加します。
問題は過剰なループアンローリングで、かなりコードが
大きくなっている。マイコンではコードのメモリ容量は
大きく取れるから、それほど大きな問題ではないけど。
同じくネットに落ちていた不信なPDFにIntel 8051の性能もあった。
8051は乗算器を持っているけどWZetaのほうが数倍高速みたいだった。
これが本当ならWZetaを使いたいと思う人が多いはず。
時は2000年、暗号プロセッサICF3(1999年)
を製品出荷した後、僕はICF3に楕円曲線(ECDSAのドラフト)が実装できないかを検討した。
IEEE P1363のプロジェクトがインターネットで公開していた
ECDSAのドラフトを個人的にダウンロードした。
先月、システムをRSAからECDSAに移行検討するように
「電子政府推奨暗号リスト」を掲げてアナウンスされた。
マイナンバーカードが絡むため日本中で大騒動になった。
世界でも実績のある公開鍵暗号が１つになることに問題を感じた人は少なくないはず。
そのECDSAですが、実は僕が2000年に個人で輸入していた。何故、個人だったのかといえば、
会社に僕ができることをアピールして、次の仕事を得るためだった。
この試みは、ある程度、成功した。
会社で１カ月くらいECDSAをICF3に実装する時間を得られた。
そして日立の研究所に事業部の僕がECDSAの実装を売りにいった。
もっとも僕は日立の中央研究所から事業部に転勤になっているから、
珍しいというほどでもない。
このときの楕円のパラメータと、テストベクタは日立のシステム開発研究所から入手したもの。
余談ですが、このときのパラメータがビットコインで使われているものと同じで、
このあたりにビットコインの発明は日本人ではないかという噂がたった原因なのかもしれない。
僕は全然関係無いですけど。
2000年ごろは、IEEE P1363のメーリングリストに登録するとドラフトが誰でもダウンロードできる
時代だった。このとき使ったメールアドレスは富士通が運営しているNIFTY SERVEの
メールアドレスだったけど富士通とは無関係です。
IEEE P1363にある楕円暗号の演算方法は、非常に高速で面白いです。日本の楕円暗号の
研究者の人が、今でも出し惜しみをしているほど。
参考までにSnakeCubeはモンゴメリ乗算の演算が非常に高速な発明。
IEEE P1363の楕円暗号の演算方法と併用できます。
僕は、楕円暗号の演算方法(IEEE P1363)を日本に輸入することに成功。
NTTなどの社外にも知られることになった。
日立の研究所に売りに行った資料は、既に公開されているものですが、次のURLです。
RSA演算器(暗号プロセッサ)で楕円暗号の試作実装
https://openicf3.idletime.tokyo/summary.html#ICF3EC
上記資料にありますがICF3はA*B mod PとA*A mod Pを並列に演算可能です。
SnakeCubeも同じです。暗号プロセッサ向けのソフトウェアを開発する上で、
参考になればと思います。
この資料を持って(同志社大卒の)上長といっしょに戸塚にある日立の事業部に行って
防衛省に売れないか、検討をしたが不調に終わった。
偉い人は楕円のスカラ倍が、あまりイメージできなかったようだという記憶が残っている。
実際、楕円暗号は一般的に難しいと言われるのは、このあたりの実装が、
その簡潔な表記からは、想像できないからだと思う。
日本にモンゴメリ乗算を最初に輸入した元東芝の川村信一氏がIEEEのFellowに選定されたようです。
『コスト効率が良く安全な暗号への貢献』
https://www.cpsec.aist.go.jp/achievements/award/IEEE_fellow2023/
2018年のSnakeCubeの発明に
日立も東芝も無関係です。僕１人による発明。IEEEは、それを認識しているのだろうか。
元早稲田の副総長の笠原先生はIEEEソサイエティの議長を数年前、日本人としては、
珍しくやっていたはずなのに、冷たいと言わざるを得ない。
これでは、なんとなくまた東大卒が僕の成果を泥棒したような状態です。
この状態が続けば国が荒れるのではないでしょうか。
RSA移行の話とか実際に大問題が起きている。正常な状態に戻すようにお願いします。
再確認しますが、僕は生れを調べると推測になるけど、日本の権力コアが、
数学の才能を持つ子供(僕)を、日大卒の僕の親にあづけて、
馬鹿っぽく見せていたということです。
SNSのTL上でモバイル向けのCPUを作ったほうが市場が大きいと言ってくる人があった。
モバイル向けのCPUの市場は大きいから言っていることは合っている。
問題はモバイル向けCPUを作ろうとすると妨害しようとする力が大きくなる。
力が一定、以上になると、僕の人生が潰れることが完成する。
自分がやっていることは小さいつもりかもしれない。
僕が何故、怒っているのか、わからないのなら、前述の理由。
8bitのWZetaを16bit化したTZetaを開発したいと思っていることは日記に書いています。
32bit化もあるのかと思う人は、あったかもしれない。16bit化が、うまくいくのは、
16bit固定長の命令セットに空きがあったから。
命令セットを拡張して32bit化しても、良いCPUにはならない。
新しい32bit CPUが必要ならWZetaを拡張するより１から作ったほうがいい。
RISC-Vが日本で流行り始めたころにICF3(1999年)を32bit化したICF3-Vの設計をしていた。
結局、圧力に負けて8bitのICF3-Zになっている。
周囲の後押しによってICF3-Vを復活させる可能性を否定はできないが、
ICF3-Vはアーキテクチャ的にモバイル向けの性能は出ないと考えている。
将来、1990年頃の16bitパソコン(NEC PC98)くらいは出来ないか、とは考えています。
世界中で戦争が起きれば民間で使える半導体が激減するかもしれない。
そういうところで活躍できればと思うことはあります。
この16bitパソコン向けのGPUの開発を計画すれば、既存のGPUメーカーが
黙っていないでしょう。
なのでゼロ遅延マルチコアを活かしてCPUでグラフィックを処理するのが良いと
思っています。
メモリ2GBしかないマシンでも動作するWindows11、Tiny11が公開されたので早速、
WZ-660のエミュレータを動かしてみました。(メモリ4GB搭載のPCで)普通に軽快に動作しました。
GIGAZINE記事「たった2GBのメモリで動く軽量版Windows 11の「Tiny11」登場」
https://gigazine.net/news/20230206-tiny11-windows-11/
Windows11のアクティベートが必要らしいですが、
完全オフライン・インストールでもWZ-660は普通に動作しました。
WZ-660のエミュレータはWindowsXPでも動作するので、アクティベートが必要だとするなら、
Tiny11で動作しても、あまり意味がなかったかもしれない。
Windowsのライセンスのない中古PCはWineか、SDL2でWZ-660のLinux版を開発するか、、、時間は無いか。
画像をマウスでクリックすると拡大されます
インターネット閲覧中に偶然発見。(YouTube)
いや驚きました。大企業トヨタの社長に僕の大学の同期がなるなんて！
全然面識はありませんが僕と同じ早稲田大学理工学部だから学生時代、
同じ教室で授業を受けていた可能性はあるかも。
昨年末の同窓会に参加していれば良かったかな。
佐藤恒治氏は機械科で僕は電気工学科だから同じ教室で授業を受けていた確率は低いと思いますが。
僕の勝手な予想ですが、この抜擢で考えられるのは、自動車で使われるマイコンを
マルチプロセッサに置き換えて電磁波ノイズ対策をしてトヨタの高信頼イメージアップ。
マルチプロセッサのコンパイラは、元早稲田の副総長、笠原先生のOSCARコンパイラ技術利用。
マルチプロセッサは、どこのメーカーでも良いのかもしれないですが、
僕のゼロ遅延マルチコアは非常に優れてます。ゼロ遅延マルチコアを活かした
専用コンパイラの開発が、トヨタなら可能かもしれない。
CPUの製品化には一般的には非常にコストがかかるのですがWZetaのハードは
非常にシンプルなので、一般的なCPUのイメージとは、かなり違う認識を持ってもらえるといいです。
あのイーロンマスク氏も関心がありそうな話。
ツイッターでイジメられたら、どうしようとか。WZetaはオープンソースだから大丈夫か。
でも社会インフラで使われる公開鍵暗号をRSAと楕円曲線の２つ維持することは重要。
暗号プロセッサSnakeCubeが優先で
8bit CPU WZetaも平行して開発していくのかも。
暗号民主化を考えた国内のSSLアクセラレータなら僕だけでもいいのですけど、
世界の人もRSAが必要だと考える人もあると思うから経済産業省の方の返事を待つのか。
経済産業省のウェブサイトに意見を投げ込んだけど、未だ返信は無いです。
日本国民はSnakeCubeを国内ではなくて全世界に発信できることに力を入れるべきだと、
僕は思います。
7:45AM 追記
次世代SnakeCubeでは量子コンピュータの解読に強い耐量子暗号をSnakeCubeに
実装していきます。従来暗号も新暗号も演算可能となるようにしていきます。
汎用的なSIMDプロセッサをRSA暗号に対応させたものでは十分に効率がでません。
SnakeCubeを耐量子暗号に対応させたほうが効率的だと思われます。
次世代SnakeCubeは世界最強となるかもしれない。
先週の1月31日にNATOのストルテンベルグ事務総長が僕の自宅から徒歩15分くらいの
入間基地に視察をしに来たらしい。
半分冗談で書きます。半分は本気だということ。
隠していても、わかる人にはわかると思ったので日記に書くことにしました。
世界最高性能の激安暗号鍵交換装置の設計図の発明者である僕に何の
連絡も無かった。戦争に巻き込まれたく無いから、それはそれで
良かったのかもしれないけど。
発明者の僕に断りもなく設計図を売られてないか心配になったのです。
NATO事務総長の関係者が僕のニセモノと交渉していたら大変。
公開鍵暗号はCPUでも高速に演算できます。下手な専用演算器を作っても
ハイエンドCPUに勝てない。しかしながら僕の暗号プロセッサSnakeCubeは、
非常に大きな鍵の場合、CPUよりずっと高速に演算できます。
僕は軍事には全く素人ですが、多数の国で構成される軍隊では、
世界最高性能の激安暗号鍵交換装置が便利ではないだろうかと思ったのです。
もっともRSA暗号を使いたいと思うのかは不明ですけど。
そういうわけで暗号プロセッサSnakeCube
の軍事利用には注意をしているのですけど、RSAの署名専用なら、世界の民間企業の間で
使えてビジネスになることは、あったかもしれないと。
まだ遅くはないかもしれません。経済産業省の人とか、どうでしょうか。
この日記を最後まで読めば、僕だけがSnakeCubeの発明をできた理由が、わかるかも。
前回の日記「RSA演算器コンテストが2008年に日本で開催されていた」
のSNS反応について。ツイッターで恐ろしく誤解している反応のツイートを見た。
ICF3(1999年)ではモンゴメリ乗算を
使った世界初の暗号チップを僕が作った。(各国で試作があったのかは不明)
その後、僕が開発から、はずされ追い出されたため僕以外の人が、
モンゴメリ乗算を使った暗号チップを作ってみたけど、僕に及ぶものを作れた人はいなかった。
僕が続けていやっていればICF3(1999年)からSnakeCubeへと直接、自力で進化した。
これができたのは僕の数学の才能のおかげだと思う。数学を勉強せずに数学がわかるから。
50年以上前の日本の支配者層の誰かが、数学の才能のある人を製造して、自分の配下とするため、
僕を密造していたのかもと、思うこともある。僕には真実を知らされていないけど。
今、真実を聞いても作り話しか聞けないと思っているから。
去年あたりは金持ちが後妻を取るために本妻の子供を抹殺。
抹殺された子供を医者が蘇生して僕になったとか想像をしていたりもするけど。
ICF3(1999年)のときもモンゴメリ乗算は東芝の研究者が先に日本に輸入していた。
僕は日立の研究所から英語の原文をもらってICF3を作っている。東芝が役に立ったということは無い。
次のURLは僕がICF3を開発していたころを2016年にブログにしたもの。
僕が新人の頃の出来事だから、あまりカッコいい話ではないけど、事実を正確に残したものとして。
自分のブログ「世界一のRSA暗号LSI ICF3のアルゴリズム」
https://icf.hatenablog.com/entry/2016/09/04/204806
暗号演算は前回の演算結果を使って演算する逐次演算が非常に多い。
高速化の定石はパイプラインだけど逐次演算ではパイプラインは逆効果。
暗号演算では設計者はFFを挿入することなく演算ゲートを連続させる演算器を作る。
ところがFPGAではパイプライン化された乗算器が作りこまれていて、
逆効果なパイプラインを強要される。
モンゴメリ乗算では、1サイクルで高速に動作する乗算ループにFFを挿入すると
前ループの演算結果が必要となるタイミングが後半サイクルになる。
ここにSnakeCubeの無限に鍵長を長くしても効率が落ちない秘密が作れる。
そうは言っても巨大整数の演算なので加算した結果は下位から上位へ伝搬する。
そしてモンゴメリ乗算の公式には右シフトがあって上位から下位への伝搬。
整数の真ん中の演算ブロックの開始タイミングを遅らせて、
正しい答えを維持できるのか？数学的な証明が必要なる。
ここに数学を勉強せずに数学ができる数学の才能が必要だと思う。
次のURLは僕が証明してみせたブログ
自分のブログ「モンゴメリ乗算の累積加算における分割加算の証明」
https://icf.hatenablog.com/entry/2018/09/26/122020
2008年にRSA演算器コンテストを開催していたのはCQ出版の「Design Wave Magazine」
という組み込みシステム技術者向けの雑誌です。
当時の僕はコンテスト開催のお知らせをネット上で見つけていた。
しかし賞金が沖縄旅行だったのでアマチュアのコンテストだと思ったので見送りました。
沖縄旅行では生活できないのです。
コンテストの結果は見た記憶があって国立高専のモンゴメリ・パイプラインが学術的には良かったと
思いましたが性能はあまり良く無さそうに僕には見えました。
その他にも性能の良さそうなものは、見当たりませんでした。
2018年に僕が発明したSnakeCube
と同じXilinxのFPGAチップを使って再現すれば、性能を比較できると思いますが、
僕の感覚ではSnakeCubeのほうが100倍高速ではないかと思っています。
SnakeCubeも同じモンゴメリ乗算を使っていますが。
SnakeCubeではアルゴリズムによって計算量が減っているのではなくて、
FPGAチップの搭載される多数の乗算器に有効なデータを高周波数で入力させることに
成功しているから。
この大発明を日本国が採用しマイナンバーカードなどで使われているRSAのシステムを
延命させれば、国家予算クラスの利益が生成されたはずだった。
この大発明を不採用にして、日本の科学推進を拒み、国民に無駄な税金を払わせることに
なったことを国民のみなさまは、おおいに考えて、急速にRSA 7680bitのICカード開発する
展開へと、動いたほうが良いような気がします。
時間がありません。前回の投票で僕が１票を入れた赤松健議員とか
ICF3(1999年)の文化保存の名目で調査、
RSA 7680bit ICカード開発にならないだろうか。赤松健議員のツイッターをみていると最近、
量子コンピュータの視察しているみたいだし、結構、関心があったりしないだろうか。
経済産業省の方へ。
僕は国家資格、情報処理技術者試験第１種に合格しているので直接、ご連絡いただいても
大丈夫のような気がしています。
ご存知の方も多いと思いますが、僕は政府認証基盤GPKIの件で、九段下にある合同庁舎に
何度か、総務省の打合せに参加したこともある。
参考になる日記
1月20日～1月30日の日記に、いろいろ書いています。是非。
1月20日の日記 RSAは終わらない - RSA 7680bit ICカードの実現可能性
|
