|
災害用のモバイルバッテリーを使って小型のコンピュータを太陽光発電で
動作させるシステムを作った。これでverilogシミュレーションの電気代が節約できそう。
頭痛で辛い。頭痛作動装置を使うような大人には、ならないように。
公開鍵の鍵長を、とても長くすることになったとしたら、
モバイルなどのCPUの性能が低い端末では、厳しくなることはあるかもしれない。
SSDとかM.2にSSLアクセラレータを搭載すれば1スロットで済む。
18年前、日立、東芝、松下が開発したICチップ搭載のSDカードを思い出します。MOPASSと呼ばれていたやつです。
僕はMOPASSカードのデバイスドライバの試作を仕事でしていた。
MOPASSの試作カードのI/Fの構造上の問題でICチップの命令とSDカードの命令の混在ができない。
そこで、それぞれの命令を排他制御するドライバが必要になり、試作をすることになった。
この排他制御をフィルタドライバを使って試作をすることを日立のシステム開発研究所に薦められた。
結局、フィルタドライバでは排他制御をすることは出来ても、
OS側の管理がICカードとSDカードの2つのドライバがあるものだと勘違いするため
電源関係などの操作が２重に行われるなど製品レベルのものには、ならなかった。
当時のシステム研究所の所長に、使ってもらえる程度には、動作したのですが。
カードリーダはルネサス(RENESAS)が開発したもので、試作のときは、
アプリケーションとカードリーダーの通信を暗号化する仕様でした。
製品版ではMOPASSカードとアプリケーションの通信が暗号化されているため、暗号化はしていないかも。
僕が、ルネサスのドライバ(DLL)を逆アセンブルして暗号化のアルゴリズムを解読して、
排他制御のフィルタドライバで使った話は、システム開発研究所では有名かもしれない。
SSLアクセラレータつきSSDコントローラも、視野に入れることが可能なのかもと。
どちらのUSBメモリも購入して数年経過している。書き込み回数も、それほど多くはない。
しかし同時に壊れた。IoTデバイスのUSBが壊れて5Vを超えた電圧が出力されていないか、確認をしたが、問題はなかった。
たまたま同時に壊れたのだろうか。写真の下にあるUSBメモリはメーカー名が経年劣化で消えているがKINGMAX。
nVIDIA Jetson nano(ARM Cotex-A57 1.43GHz、GPU CUDAコア 128個)を購入した。
XilinxのFPGAを使ったSSLアクセラレータSnakeCube
を開発中なのですが、nVIDIA JetsonがSSLアクセラレータになるのか、将来、検討するために購入。
このブログ
「モンゴメリ乗算の累積加算における分割加算の証明」
のアルゴリズムはGPUでも実装できる。ただ、どのくらいの性能になるか、わからない。
JetsonはOpenCLに対応していないみたいでCUDAによるプログラミングになる。
CUDAのプログラミングも何度か、経験があるので、JetsonのCUDAプログラミングを始めれば数か月以内には、
詳細な検討結果を出せると思うが、XilinxのFPGAを急ぎたい。
とりあえずCPUだけのRSA性能を測定して以前の記事に追加しました。
RSA 8192bitの性能を測定するソースコード
秋葉原にあるOLIOSPECの通販店で売られているスチール製ケースに入れた写真。
上面にねじ止めしたダサい金具はスチール製ケースも冷却に使おうとして付けました。
(一応、このケース、MicroSDスロットは穴は開いていますが取り出しには対応してないので注意)
図をマウスでクリックすると拡大されます
FPGAのメリットにディスコン(EOL)対策があります。8bit CPU ICF3-Z
はトランジスタ数を少なくすることに特化しているためSRAMより論理ゲートが高価なFPGAに向いています。
ディスコン対策を考えたICF3-Zも、あるのかも。
実際、やってみたことはないので確実性のある話ではないですけれど。
日本で汎用のCPUを新規に作って最後までいける可能性があるのはICF3だけだと思っています。
僕が独自に設計したアーキテクチャなので海外の模倣扱いで潰されることはなく、
32bit CPUではできない領域を持っているからです。
乗除算一体型のALUと疑似パイプラインによって非常に少ないトランジスタ数で高性能がでます。
僕が大学時代の研究室は並列コンパイラなのでCPUの実装について知識を得ることはなく、
会社に入ってからもCPU撤退が始まっていたので、CPUの知識を得ることはありませんでした。
なのでICF3(1999年)は、
僕がステートマシンを知らずに作ったアーキテクチャです。
これが独自な高性能アーキテクチャ、8bit CPU ICF3-Zになって登場したという状況。
税金などの重たい成分がないため、国内の人が受け入れやすいのです。
ステートマシンについてのエピソードを話してみます。
1999年の開発現場は、基本的に勉強する時間など一切なく、仕事をしています。
AND、ORの設計図など、全く教科書を見なくても、読むことはできるからです。
このとき現場にあった設計図はデータ転送系のLSIのもので、
ステートマシンを知らなくても、仕事ができました。
ICF3(1999年)の暗号プロセッサの設計者は僕でしたがSHA-1、Multi2、DES演算器は別の設計者です。
SHA-1の原案は僕が自宅で作ったものなので、関連会社の人が設計者になっています。
ICF3(1999年)開発後、世界一になったICF3の設計者たちが、次の開発について、
社内の会議に出たときのことです。
議論のなかSHA-1の設計者が、ステートマシンを知らないことを露呈してしまった。
しかし僕とリーダー(東大卒)は、その場をしのぐことができたのです。
僕も、この時、ステートマシンは知らなかったのです。
頭のいい設計者なら、教科書を読んで体系的に説明されたステートマシンを知らなくても、
感覚的にステートマシンを知っている。
要するに頭のいい人が設計したほうがいい、ということが言いたかった。
ちなみにICF3(1999年)の暗号プロセッサは割込みは必要なくて、
8bit CPU ICF3-Zに改修したときに割込みを実装しています。
いろいろ考えたのですが、割り込み時、CPU内のすべての状態を保存して、
割込みから復帰するところで、復元すれば、
間違いないということを思いついて、ICF3-Z Zeviosに実装しました。
国内の人の受け入れやすさを優先したため、
ICF3-Zを使った開発を、したいという人がいなくなったように思います。
そこで考えているのは、コンパイラ、OS、仮想マシンの成果が、やった人に付けば、
好きな人は、やってもいいと思うのではないかということです。
自分のウェブサイトで公開してスキルをアピールすることができます。
それを皆が応援すれば、ICF3-Zが成功すると思います。
税金を使わない方針なので、コンパイラ、OS、仮想マシンが実際に使える範囲は、
ホビーなどの用途に限られてしまうと思います。
税金を使わずに産業で使えるようなものも、別途考えていく必要はあるのかもと思っています。
僕はCPUのハードの成果を守ります。アセンブラは簡単に作れるので僕ができると思います。
アセンブラがあれば、FPGAに実装するソフトプロセッサ(SoftCPU)として実用になります。
FPGAはSRAMより論理ゲートが高価なのでICF3-Zは有利です。
実際に役立つこともあると思います。ICF3-ZがASICのマイコンになることもあるでしょう。
このICF3-Zの計画を成功されば産業に貢献するように思っています。
次の僕のnoteに投稿した記事が参考になると思います。
「8bit CPUのオープンソース ICF3-Z」
後は無駄話です
僕が中学生の頃は8bitパソコンが全盛期でした。BASICマガジンにJR-100(Panasonic)用の
ICBMを撃墜するゲームが掲載されていたので、それをSHARP MZ-2000用に移植して、
BASICマガジンに投稿しました。中学生だったので、あまりできのいいものではなく、
没になってます。
Z80のマシン語に興味を持って遊んでいましたが、高校生になって勉強が忙しくなりMZ-2000を封印しました。
しかし何故か、父親がクリスマスの日に、僕が地元の電気店でSHARPのポケコンで遊んでいると、
そのポケコンを買ってやると言い出して、買ってもらったのです。
PC-1251です。MZ-2000は封印され、家族のいる部屋に置かれていたので、触ることができなかったのですが、
ポケコンは勉強しているふりをしながら、マシン語で遊ぶことができました。
CASIOはBASICのみでしたが、SHARPのポケコンはマシン語を触れたのです。
PC-1251は8bit CPUでRAM 4.2KBですが、月刊I/Oにコンパイラが投稿されていたので、
それを熱心に読みふけっていたのを覚えています。
もし大学に入ってコンピュータサークルに入っていれば、コンパイラを自作して
投稿していただろうと思っています。
僕の経験からすれば、ICF3-Zの計画は、無謀ではないと思っています。
そういう人を応援もせず、潰してしまうことがなければ。
第1回 自作CPUもくもく会には
慶應大学の天野先生がいらっしゃって、ご講演されるとか。
僕の方は8bit CPU ICF3-Zよりも
SSLアクセラレータが忙しく参加できないと思いますが、
10分発表して名刺を配ることをしてもいいなぁとは思いました。
ICF3-ZのZeviosのプログラムアドレスの指定には命令コードの下位16bitを使っています。
1ワードは4バイトなので256KBのプログラムメモリの空間をアクセスできます。
ICF3-ZでOSを動作させることを、あまり考えていないのですが、
動作するなら動作したほうがいいと思っています。
256KBのプログラムメモリではOSが十分に入らないかもしれないと考えています。
Zeviosのプログラムアドレスを18bitにするのは簡単にできます。
分岐命令のアドレス指定に命令コードの下位18bitを割り当てるだけです。
データメモリのアドレッシングモードの領域とコンフリクトしますが、問題ありません。
間接分岐は3FFFF番地に分岐した場合に処理されるようなハードを追加するだけです。
18bitアドレスでは1024KBバイトのプログラムメモリを使えますが
SRAMで1024KBは厳しいかもしれません。
ここからは、あまり自信はない話になります。
遅いメモリで動作するZeviosの別実装も考えたのですが、
Zeviosの割込みは任意のタイミングで入れることが可能です。
つまり、SRAMキャッシュ上にないアドレスを出力した瞬間に判定して割込みを入れます。
そして割込み処理内でI/O命令を使ってフラッシュメモリからSRAMに読み出します。
キャッシュ制御を割込みで実装。すると1024KBのフラッシュメモリにOSを入れられるのかもと。
現在、量子コンピュータの進歩により暗号解読のリスクを考える必要が出てきました。
僕の発明した高効率な暗号プロセッサが、とても役に立たつ状況です。
その暗号プロセッサを搭載したSSLアクセラレータを急いて開発して、僕の発明がすごいということを証明したいのです。
なのに何故、Chromium OSをビルドしているのか、不信に思う人がいるらしく、説明が必要なのだと感じました。
ここに書けない説明になるので、厳密には正しい説明になっていませんが、
頭痛で作業ができなくなっています。頭痛でもChromium OSをビルドするくらいはできるので。
頭痛制御の精度は、普通の人の常識をはるかに超えるものという感じです。非破壊制御ではないです。
日記では8bit CPU(ICF3-Z)の話が多くなっていてSSLアクセラレータのSnakeCube(ICF3-F)の進捗が
気になった人もあるかと思ったので書きます。
1月9日にSnakeCubeのサイトを立ち上げていますが、本日、サイトの色を黄緑から水色に変更しました。
https://openicf3.idletime.tokyo/snakecube/
頭痛が続いていてSnakeCubeの作業時間が、あまりとれていないのが現状ですが、
これから増えていく予想。マイクロコード用のアセンブラの開発中です。
8bit CPU ICF3-Zの割込みは除算をやっている途中でも
1サイクル間隔で割込みは入ります。圧縮命令の実行中でも1サイクル間隔で割込みは入ります。
DISABLE命令で割込み禁止にしない限り、毎サイクル割込みが入る仕組みになっています。
割込み処理の中で、演算レジスタA,B,C,Dを使っている場合、使っている演算レジスタを
汎用レジスタかスクラッチパッドに退避させ、割込を終了するところで復帰させます。
割込みもZeviosに実装済みです。
ICF3-Zの汎用レジスタは8bit×16本の2バンクです。
他社のマイコンでは4バンクあるようです。
アプリのスレッド3バンク、割込みで1バンクみたいな使い方をしたら、どうするんだみたいな、うわさが。
ICF3-Z Zeviosコアでは2バンクを4バンクや16バンクに改造することは、とても簡単にできます。
4バンクにしなかった理由は、なるべくトランジスタ数を少なくしたかったからです。
4バンク以上のZeviosコアも考えてもいいのかもしれません。
割込み中は汎用レジスタを全く使わずに、スクラッチパッドだけで処理をすることも考えられます。
4バンクのZeviosコアとか種類を増やすとコスト増に繋がりそうなので。
ICF3-Zのアーキテクチャはスクラッチパッドでも汎用レジスタと比較して、あまり性能は落ちません。
昨日の日記にあるIntel特許。侵害であるかどうかの判定基準をエミュレーションか否か
の状態を保持する記憶装置の有無と考えたことを言いました。
特許の判定基準が、どうなのかというは、僕では、難しいのかもしれないですが、もう少し考えます。
命令コードの全フィールドをユーザー定義できる命令セットを考えると、
エミュレーションの状態を保持する記憶装置がなくてもエミュレーションできる。
前日の判定基準ではパスしてしまう。
インテルの特許第5984865号 「命令エミュレーションプロセッサ、方法、およびシステム」を読んでもらえば、
わかるのですが、恐らくこの特許は、エミュレーションできることを特許にしているのではなくて、
通常命令と命令をエミュレーションするハードを持っていて、命令をエミュレーションする
場合には、エミュレーションハードを使って高速に処理できることを特許にしている。
命令コードの全フィールドをユーザー定義できる命令セットを実行するハードウェアは、
通常命令か、エミュレーションなのか、わからなければ、高速に処理することは難しい。
エミュレーションか否かの情報があれば、高速にエミュレーションできるように思います。
しかし、前日の判定基準ではNGとなるのです。
ICF3-Zが前日のIntel特許以外に特許侵害していなかについて。
年末年始、特許を調べていました。保証できませんが、恐らく問題ないように思います。
基本的にICF3-Zは、非常に少ないトランジスタ数で構成されるため、
特許になりそうな部分があまりないのです。
ただ、何としても、ICF3-Zを潰すそうと考える人達は、無理に攻撃してくる可能性はあります。
それとICF3-Zは、他のCPUと比較して特長あるCPUなので、模倣判定が容易です。
命令セットアーキテクチャを見れば、すぐにわかります。そのあたりも気を付けてください。
CPUに詳しい人にとってICF3-Zが独自なものであることは一目瞭然なのですが、
普通の人にとっては、何が元になっているのか、知りたいということはあると思ったので書きます。
元になったものはありません。僕が考えたものです。
既存のアーキテクチャと似ていないことを2017年に本を買って調べて確認しました。
「ディジタル回路設計とコンピュータアーキテクチャ 第2版」
著者
David Money Harris ハーベイ・マッド大学教授、スタンフォード大学電気工学科で博士、IntelでItaniumとPentium IIプロセッサの設計
翻訳
天野英晴 慶応義塾大学教授、慶応大学電気工学で博士
鈴木貢 島根大学准教授、博士(工学)
中條拓伯 東京農工大学准教授、博士(工学)
永松礼夫 神奈川大学教授、博士(工学)
ICF3-Zの公式サイトでICF3-Zの圧縮命令が
Intel特許侵害をしていない説明
をしています。その補足になります。
エミュレーションか否かの状態を保持する記憶装置の有無が特許侵害の判定基準と考えています。
エミュレーションか否かでハードウェアが動作を変更するという特許なのだと思われますが、
ICF3-Zは、そもそもエミュレーションという状態が存在しないという説明です。
ICF3-Zを良く思わない人たちによって、この話が煽られているのかもしれないと思って補足してみました。
QuickJS
という仮想マシンで動作するJavaScritpのエンジンを見つけました。
中は見ていないので、ICF3-Zの仮想マシンで動くのか、
全く調べていません。小型のスタックマシンであるように読めています。
というわけでICF3-Zの仮想マシンについて説明してみたいと思います。
ICF3-Zにはユーザーが定義できる16bit長の命令があります。これまで圧縮命令と読んできたものです。
この圧縮命令を利用することで仮想マシンになるのかもと考えています。
圧縮命令は公開したZeviosコアに実装されています。
圧縮命令を仮想マシンとして利用するための注意点があるので説明します。
32bit長の命令コードと16bit長の命令コードの混在は可能ですが、
32bit長の命令に2つの16bit長の圧縮命令を入れることしかできません。
16bit長の命令コードが続いているなかで奇数番目の命令コードへの分岐はできません。
しかし分岐先が16bit長でも32bit長のどちらでも問題ありません。
圧縮命令で分岐命令を実装するにはPOPSP命令を使います。
圧縮命令はサブルーチンで実装されているためスタックをクリアする必要があるからです。
32bitの前半のコードか、後半のコードかを記録しているビットもあるので、それもクリアします。
圧縮命令でCALL命令のようなサブルーチンコール命令を作った場合、32bitの後半のコードに配置しないといけません。
コンパイラでそういうコードを生成する必要があります。
圧縮命令は通常のCALL命令と同じ仕組みでスタック上にリターンアドレスを格納しています。
したがってサブルーチンコール命令の実装は、普通に分岐命令を使うだけでできます。
圧縮命令であるか、否かを、判定するビットが命令コードの最上位bitにあるので、
実質、仮想マシンの命令コードは、15bit長になります。
そして7bitのオペコード+8bitのオペランドという形式のみなので、
既存の仮想マシンを移植することは困難であるように思います。
ICF3-Z用の仮想マシンを作ることになると考えています。
ICF3-Zで動作する自分の仮想マシンの仕様を開発して、いろいろな言語を移植したり、
ICF3-Z以外のマシンでも動作させるのも、いいのかもと思います。
ICF3-Zで動作する仮想マシンの仕様であれば、他のマシンでほぼ確実に動作する仮想マシンになるでしょう。
仮想マシンの応用編
あまり本気にする必要はありませんが、面白いかもと思って書いています。
ICF3-Zのプログラムメモリは32bit単位でアクセスされますが、これを8bitの命令コードとして扱うような
仮想マシンを作れば、Z80のようなレガシーなCPUのエミュレーションも、できるのかもしれません。
プログラムメモリが4倍必要になりますが、32bitを1バイトにした、バイト単位のアドレスに分岐できます。
前半の16bitにZ80のプログラムコードを入れて、後半は空の圧縮命令に分岐してもいいのですが、
空では、もったいないのでLCDやキーボード入力などの制御をさせれば、ちょっといいかも、とか。
今月15日に除算命令のサンプルコードを公開しました。
それをテンプレートに性能を評価する人も、あるのかもと思っています。
ICF3-Zのアーキテクチャは普通のCPUではないので、慣れた人がアセンブラでプログラムを
書かないと十分な性能を出せないと思っています。
ちなみに32bit÷16bitの除算のサンプルコードですが、
A,B,Cの8bitレジスタを連結させて1サイクルで1bit左シフトできる機能を使っています。
3レジスタ同時に左シフトすることもできるのですが、実際のコードは、A,B,Cに値をセットしてA,Bだけ先に左シフト。
後からCを左シフトします。このときに除算の結果、1bitを最下位ビットに取り込みます。
Cレジスタを同時に左シフトしてしまうと除算結果を取り込めないので、Cレジスタの左シフトは敢て遅延させています。
8回繰り返した後にはCレジスタには8bitの除算結果が入っているというような感じです。
実際に比較しないと、わからない人が多いと思いましたので、小型のRISC-VコアであるlowRISCのibexと比較してみました。
ICF3-ZのZeviosは8bit CPUですが、lowRISCのibexは除算器を持った32bit CPUです。
lowRISCのWebページにXilinxのローエンドのFPGA(7シリーズ)に実装した場合の周波数が50MHzと書かれてありました。
そして除算は37サイクルで動作と書かれています。
Zeviosは同じくXilinxのローエンドのFPGA(Artix-7)に実装した場合、周波数は150MHzになります。つまり3倍の周波数で動作。
0除算などのチェックや演算レジスタへのロード、ストアの補正として3～6サイクル追加しています。
除算 | ibex
RISC-V
[サイクル] | Zevios
ICF3-Z
[サイクル] | ibexを1とした
倍率 | 周波数を考慮した
倍率 |
16bit÷8bit | 37 | 20 | 1.85 | 5.55 |
24bit÷8bit
条件付き | 37 | 21 | 1.76 | 5.29 |
32bit÷8bit | 37 | 55 | 0.67 | 2.02 |
32bit÷16bit | 37 | 約350 | 0.11 | 0.32 |
ZeviosはXilinxのFPGA XC7A35TICSG324-1Lです。
ibexは2500LUTの面積ですが、Zeviosは400LUTの面積です。
外部I/OなどZeviosに不足しているものがあるかもしれませんが5分の一の面積で5倍以上の性能が出ることは、考えるべき点ではないでしょうか
8bit CPU ICF3-Zが正式に、Apache Licenseとして運用が開始されました。
32bit÷16bitの除算のサンプルコードがgithubに追加され、
ダウンロードしてverilogでシミュレーション可能です。
ブログ「8bit CPU ICF3-ZのZeviosの除算性能のメモ」も参考になると思います。
1月10のブログ「8bit CPU AVRとICF3-Zとの違い」で
『ICF3-Zでは(a) レジスタ読出しに1サイクル使えるので大きなレジスタファイルを使うことができます。』
と書いたのですが、そこに疑問を感じた人があったようです。
確かにデバイスに依存するところがあるのですが、
おおよそクリティカルパスは8bit加算のキャリーがあるALU演算になることを考えていました。
例えば(a)(b)(c)を逐次実行する場合で、かつ1サイクルの割合は(a)25% (b)50% (c)25% になると考えます。
(a)(b)(c)を並列実行すると(b)がクリティカルパスになって周波数は2倍になります。
そして(a)のレジスタ読出しに使える時間は、逐次実行の2倍になるため、大きなレジスタファイルやRAMが使える。
メジャーな8bit CPU AVRの一つであるATmega328の除算性能を実測してブログにした。
こちら↓
8bit CPU ATmega328の除算性能を測定してみた
AVRに除算命令はないのでArduino UNO R3で使われているソフトウェア除算の性能を測ったということになる。
ICF3-Zは16bit÷8bitで20倍高速。24bit÷8bitでは50倍高速という予測
(ICF3-Zは同じ半導体素子ならAVRの2倍の周波数が出せるため)
Arduinoの開発環境、便利ですね。Arduinoに3ドル寄付しました。
頭痛だと半日とか、長くても１週間くらいで、痛みが止む。
このところの問題は目が霞んでいることが長期化して、元に戻らなくなっていないか。
パソコンをやっていると、気づかないうちに画面に顔を近づけていて、
背骨が筋肉痛になって姿勢を保つのが厳しくなっている。
最近は、ほとんどなくなったことだが、食事をとったあと、強制的に眠らされるとどうなるか、ご存知だろうか。
それほど痛くはないが、腹痛とともに、食べたものがあまり消化されずに、排出される。
数えていないが、これまで数百回は行われている。
監視を休みたくなったら、眠らせていたのかもしれないが、本格的に体調を壊されると
問題になると感じるようになったのか、ここのところ食事の後に眠らせることは、
ほとんどなくなった。
この状況でも体調が崩れるリスクを抱えながら1日3時間くらいは、ICF3-Fが進むのかもしれない。
しかし、それでは、例えば1年で完成するものが3年以上かかる。
どうにか、ならないのか、考えている。
8bit CPUのICF3-Zのほうは、随分前に別サイトに分離していましたが、ICF3-Zを
Apache License 2.0として正式運用を開始すると、ICF3-ZとICF3-Fの区別がつかず、
間違えることもあるかと思い、ICF3-FをSnakeCubeと命名して別サイトに分離しました。
こちらです↓
https://openicf3.idletime.tokyo/snakecube/
頭痛が続いている。倒れるまで頭痛になることはないかもしれないが、
頭が悪い状態ではICF3-Fがうまく完成しない。
頭痛でICF3-Fを手放すことがあれば、それを受ける先が、頭痛関係者として疑われ、うまくいかないはずです。
ICF3-Fを手放す前に僕の脳が破裂していると思いますけど。
頭痛が続く将来を予想して欲しいのです。
僕は頭痛を認めていません。僕のようなケースでは非人道的だと考えています。
痛い。寝ます。
パナソニック半導体事業売却による軍事技術の流出の話題を考えていたら、
ICF3(1999年)が良く売れた理由が、わかった。推定なので正しいのか、わかりませんが。
米国では2000年まで暗号技術の輸出規制が厳しかったのです。
IBMの大型コンピュータの暗号装置も規制で世界へ販売できなかったか、あるいは、
思うように販売できなかったのでしょう。
日立のIBM互換機なら、米国からの輸出ではなく日本からの輸出なので、規制の対象にならなかった。
そして東大卒がいっぱいいる部署で開発しているIBM互換機のCPUは安心のIBM製。
暗号装置はIBMの仕様をもとに僕が開発したので、規制の問題を回避できた。
ちなみに英語で書かれた
モンゴメリ乗算のアルゴリズムの本をもとに
ゼロから僕が製品化したもので、1回目(RSA暗号)で完成度の高い製品になったのは、日立の技術というより、僕の才能と幸運によるもの。
(天の声ではなく)
会社は、いっぱい儲かったのに、どうしてと、思う。
パナソニック半導体事業売却で軍事技術が中国へ流出する問題が話題になり、
「国を守れ！」と歓声が上がっているところもあるようです。
暗号プロセッサのオープンソースハードOpenICF3の
差し押さえを考えた人もあると思います。
公開鍵暗号はCPUやGPUでも効率的に演算できます。
GPUの価格性能比は非常に優れているので暗号プロセッサを抑えたところで
あまり影響しないと思います。
差し押さえることより、わが国の技術力を見せることに役立てたほうがいいと思います。
現在ではFPGAがあるため、大学生のお小遣い程度で技術的には開発できる状況にあります。
差し押さえると、他国に抜かれて、この国が劣勢になる問題のほうが大きい。
ちなみにSSLアクセラレータのICF3-Fはクローズドです。
Apache License 2.0で公開予定のICF3-Zは8bit CPUで、しかも暗号演算器をはずしたものです。
国内のマイコンメーカーでも乗除算命令がないマイコンのみしか扱っていないところがある。
32bitのARM Cotex-M0+が最上位マイコン。32bitなのですが除算命令がないため除算1回で数百サイクルかかります。
ICF3-Zは8bitですが16bit÷8bit(条件付きで24bit÷8bit）が17サイクルで演算できるため
除算命令のないマイコンよりも10倍高速。
マイコン製品で、どういった処理が多いのかは、わかっていないのですが、
例えばセンサーの入力値を乗算して除算するループがメインの仕事である場合、
1ループに必要なサイクル数が半分になることはあるように思います。
つまり、半分の周波数で動作する。しかも8bitだから恐らく同じ周波数でも32bitより低消費電力。
ICF3-Zによる低消費電力技術になるのかも
除算命令のある廉価な32bit マイコンでも34サイクルだから16bit÷8bitで足りるなら、
より低い周波数で動作させられる可能性があり、低消費電力になることはあるような気がします。
ほとんど問題ないと思っているのですが、まだ特許侵害調査をしています。
特許を見ているとデバッグ関係の特許が多く申請されているようです。
気を付けたほうがいいなと思いました。
頭痛が止まらない。
いろいろ問題を起こして回復はしても全部は回復しているとは限らない。脳神経が壊れていく感じ。
8bit CPU ICF3-Zの特許侵害調査をしています。
詳しくはこちら。
筋肉痛で動けなくなることはあるが、今日は筋肉痛にはなっていない。
しかしUSBメモリ(東芝製)のキャップを取ることができないくらい手の筋肉が動かない。
頭の中も恐らく同じ。CPUで例えるならレジスタ数が1個未満という状況で、頻繁に苦痛を強いられる。
そういえば、僕って、かつて開発で最も稼いだ大手電機メーカーの社員だったんですけど。
SSLアクセラレータとしてICF3-Fを進めているが、
公開鍵暗号の鍵長を長くする必要がでてきた場合、
ハイエンドのスマホでICF3-Fが使われるかもしれない。公開鍵暗号には、署名と検証の２つの演算がある。
スマホでは、多くの場合は検証で、時々、署名をするという使い方が一般的だと思う。
RSA暗号について言えば、Microsoftの特許を使うと検証処理をかなり軽減できる。
署名にかかる時間が長くなっても、あまり気にならない処理が多いという前提を考える。
例えば、銀行振り込みのような処理で５秒くらいかかっても、それほど気にならない。
ハイエンドのスマホならICF3-Fを使って0.2秒みたいな。
ICF3-Fを搭載するとチップ面積が大きくなるのですが、３次元積層技術が進み、ICF3-Fのチップを
重ねることができるのではないかと思います。
３次元積層技術に詳しくはないが、恐らく放熱が問題になる。
しかし、署名はたまにしか使わない。ICF3-Fでの署名中は、CPUの稼働率を必要最低限にすれば、
放熱の問題も起きない。
頭痛で作業できずChromium OSのビルドを始めた。痛みで脳が正常動作していない。
8bit CPU ICF3-Zが、どのくらいの面積か
確認してみたい。
そういう人のためにボード Artyでの手順を
ダウンロードのページに追加しました。
今日は筋肉痛で動きが鈍っていました。
昨日は目を開けているのに真っ暗、いやほとんど見えているのだが、そんな感覚に悩まされた。
昨日の日記の補足。
8bit CPU ICF3-Zが
高速な8051互換(FPGA用IP)の2倍高速と書いたのは同じXilinxのArtix-7の実装でICF3-Zのほうが
2倍の周波数だったこと。運よく8051互換チップのCPI(Clock per Instruction)が書かれていて1.5～1.8であった。
ICF3-Zは加減算、論理演算であれば、同程度のCPIが出そうだと思ったので、2倍高速と書いた。
ただICF3-Zは加算器1個のアーキテクチャなので乗除算は、多少遅い。
しかし乗算の乗数が小さい場合は少ないサイクル数で演算できたり、
8051ではできない16bit÷8bitが可能だ。
ICF3-ZにはLOOP命令というものがあって2サイクルのディレイスロットをもつ特殊な命令だが
加減算とは条件付きで同時実行可能。つまり1サイクルで同時に2命令が実行できる。
LOOP命令はループで使われるため実行頻度が多く性能に影響する。
アセンブラで、こういった最適化をすれば、「2倍高速」になるかもしれない。
8bit CPU ICF3-Zと8bit CPUのIntel 8051との比較です。
正しくはIntel 8051の互換チップとの比較で、互換チップには高速なものから面積最小のもの様々ある。
カタログスペックからの予測なので間違っている可能性はあるかもしれないが、
同じクロックならオリジナルの8051より27倍、高速なものもあるがICF3-Zは、それよりさらに2倍高速かもしれない。
そして面積最小化を目標にしているlight52の半分の面積なのです。
IoT用途として期待されますが、制御用途では8bit CPUも多く使われているようです。
ICF3-Zは面積最小化した8051の半分の面積しかないのに、高性能な8051の2倍の性能。
技術革新と言えないだろうか。これくらい、あれば、ICF3-Zをゆるいオープンソースライセンス(Apache License 2.0)にすれば、
世界中の8bit CPUがICF3-Zになっていくことが、ないだろうか。
そこに、うまいビジネスは生れてくれる気がしている。
頭痛が続いて脳が壊れていく感じ。僕の頭が壊れていくと、うまくいくはずのものが、
うまくいかなくなるように思うのです。
頭痛を止めるほうが、いいと思えないだろうか。
8bit CPU ICF3-Zは、
全てを僕がゼロから設計したものです。
新規に追加した圧縮命令が他人の特許を侵害していないか、念入りに調査中。
昨日は頭の痺れで、ほとんど動けずベッドで横になっていました。
数日前までは脳内の文字認識系の動作が不安定でしたが、昨日は文字認識は回復、意味解析部がほぼ停止。
特許などの文章が、ほとんど読めない状況になっていました。
今日は、記憶にダメージがあることが何度も検出され、やれやれと思っているところ。
通常0.5秒で思い出されるはずの物が、思い出せず、数十秒かけて思い出す作業が必要。
連日の頭痛で、今もなお思考能力低下が著しく、思考速度にいたっては20分の一くらいに低下。
回復はするが、思考能力は通常の70%くらいか、思考速度は10%くらい。
思考速度が遅くなったことでアニメを見ても、速度が追い付かず、人生の楽しみを失った。
もっと回復しても少なくとも十分には、楽しめない。
今日はARMの時事問題や、ICF3の僕の功績についての検証が議題のようだ。
前述のとおり、万が一、頭が本格的に壊れると、ICF3の開発秘話の真実が消える。
そう思ったので急遽、問題となったところの記憶を、ここに記す。
1996年ごろ米国サンノゼにあるAMD本社の正門前にあるホテルに３ヶ月間、IBM互換機の
製品出荷のため滞在した。帰国後、暗号LSI ICF1(1997年)のリーダーとして僕は仕事を始めた。
米国滞在中にIBMの暗号LSIについて研修を受けていたのではないかという疑問を
持った人はいるかもしれない。全くそういうことはない。
帰国直前に、次の仕事は暗号LSIだと言われて、帰国しただけです。
滞在中の仕事は、ほぼ日本人スタッフルームで控えているだけでした。
ICF1(1997年)を出荷した後、ICF2(1998年)がスタート、僕がリーダーだったような
気がしますが、東大卒の小国氏が途中から参加、主にMulti2暗号や、RSA暗号の
実装のための検討を、いっしょにやりました。
小国氏は僕より4年くらい上なので実際の検討作業のほとんどを僕が担当しています。
大型加算器の検討を小国氏自身がやった事実が残っていますが例外的なこと。
同時期に僕の方でも検討していました。
ICF2のときもRSA暗号を実装できないか、検討していたのです。
しかし期限に間に合わずRSA抜きでICF2の実装作業に入りました。
僕が、この会社に入ったのはCPUを作りたかったからでした。
自宅で、こっそりSHA-1の論理を作っていました。
僕の論理設計のHELLO WORLDです。これがICF3のときに使われIBMの5倍の性能になったという伝説。
会社では雑用が多かったですが、論理設計をしたいという熱意が冷めず、
自費でVHDLのシミュレータを20万7900円で購入。(領収書の画像が文章の最後にあります)
しかし長時間残業のため、ほとんど購入したVHDLを使うことはありませんでした。
その頃、会社ではMulti2暗号の実装検討が、はじまりました。
恐らく、既に他でMulti2暗号をハード実装した製品があったと思います。
小国氏から仕様と、ともに作り方のポイントを享受しました。
Carry Save Adderのことで、実は加算器の初歩の初歩のFull Adderと同じです。
その使い方を、ちょっとうまくやると、大きな加算器のキャリーを非常に短くする効果を得られるのです。
魔法であるかのように小国氏に説明をされたので、思わず、魔法なのかと思って、その場で
C言語でシミュレーションして魔法の確認をしてしまいました。
魔法のように説明されなければ、すぐに理解できたと思っています。
乗算器の実装ではお馴染みのテクニックで、
当時の「トランジスタの技術」にも掲載されていたと思います。
それでもFull AdderがCarry Save Adderの効果を持つのは昔は発明だったのだろう思います。
そしてMulti2の高速化実装の検討を開始、これ以上無理ですと、小国氏に報告すると、
もっとやれと返事が返ってきたのです。
一見、正しくないと思われるローテーション加算の証明をしてみると、正しいことが
証明できてしまったのです。この発明は特許化され、僕の貢献率が5%ということでしたが、
本当に発明したのは僕です。この特許は地デジのチューナーで使えたはずなので、会社が、
かなり儲かった可能性ありと思っています。しかし特許手当として6000円くらいしか、
僕には入ってきませんでした。
儲けに貢献したのは、僕の発明力よりも、会社の政治力と思ったのでおとなしくしていますが、
今の僕の現状を考えるなら、問題かもしれない。
ICF2(1998年)の製品出荷が終わり、ICF3(1999年)がスタートしました。
リーダーが正式に小国氏になって、僕はRSA演算器(剰余演算器)の担当になりました。
ICF2のときと同様、期限が迫り、モンゴメリ乗算を採用するか否か僕は考えていました。
モンゴメリ乗算を使ってRSA暗号の演算ができるようになっていましたが、
いま一つと思い、モンゴメリ乗算の採用を見送ろうと思っていました。
これがスパコンなら悩む必要はなかったのです。
大型コンピュータの暗号装置では銀行などで使われたりするので、
モンゴメリ乗算のアルゴリズムの誤用で、万が一でも間違いを起こすと、大惨事になるからです。
僕が卒業した大学の電気工学科に暗号の授業は全くありません。
大学１年の頃の数学に整数論がありました。四則演算が閉じるとか、閉じないとかの説明を覚えています。
1988年のことですが、ICF3の検討をしていたのは1998年ですから10年前の授業を数学者でもないのに、思い出せていた。
モンゴメリ乗算のR^(-1)が、普通の整数や実数の-1乗と同じなのか、きちんと理解できていなければならないのです。
このあたりが、才能で、このおかげで、いきなり仕事で必要なところだけ勉強して事業に貢献できる仕事ができるのかも。
SONYのプレステで楕円暗号の乱数に固定値を使って失敗したニュースがあったような気がしますが、
才能があれば、いきなり楕円暗号を勉強しても、失敗する「確率」は少ないのかもしれないと思います。
そしてICF3にモンゴメリ乗算を採用するか否かの期限まで、あと数日というタイミングで
小国氏にモンゴメリ乗算の演算器は通常の加算とは違ってCarry Save Adderの効果を
得られないという誤った結果を持って、モンゴメリ乗算の採用は見送りましょうと提案しました。
ところが、モンゴメリ乗算器においてもCarry Save Adderの効果を得られるという情報を、
得ていたらしく、その場で、僕の誤った結果を否定して、モンゴメリ乗算の採用を決断したのです。
僕のほうの言い分になりますが、期限が迫っていなければ、
Carry Save Adderの効果を得られないという誤った結果を持って行くことはなかった。
Carry Save Adderの効果が得られないか？と考えながら探索しているわけですから、
最初、誤った結果になっても、他をいろいろ探したはずだからです。
ただし小国氏が、モンゴメリ乗算のR^(-1)が、
普通の整数や実数の-1乗と同じだと思い込んでいた、あるいは、
それを知らずに決断していたことも付け加えておきます。
2019年12月25日 10:20AM 追記
ちなみにICF3-F(2018年)では、
Carry Save Adderは使っていません。モンゴメリ乗算器を全部、取り換えました。
Carry Save Adderの効果に相当する部分は、
僕の発明
「モンゴメリ乗算の累積加算における分割加算の証明」によって置き換えられています。
2019年12月25日 5:25PM 追記
12月12日の日記の繰り返しになりますが、
モンゴメリ乗算器の採用が決まったところで、リーダーの小国氏は、
IBMのCPUとのI/Fの設計に移行し、僕は「プロセッサ」の設計に入りました。
誰からも、何もアドバイスされることなく、快適な環境で１人で設計を完成させました。
OpenICF3のサイトでは「プロセッサ」の
設計図を公開しているので、
独自なプロセッサだということが確認できます。
そして退職時に正式な打ち合わせをして会社から正しくICF3を持ち出しています。
2018年にモンゴメリ乗算器を全部取り換えた
ICF3-Fを発明しました。
つまり、ICF3-Fは、小国氏の承認した部分すらない、完全な僕の設計で、従来プロセッサからも、
うるさく言われることもない、ものになっています。
また8bit CPUのICF3-Zも、
モンゴメリ乗算器をはずしているので、ICF3-Zについても同様です。
CQ出版の領収書の画像、インターリンクの文字がなくなっているような気がする、、、
パソコンにウィルスが入って改ざんされたのだろうか。相変わらず証拠隠滅能力が高い。
8bit CPU ICF3-Zのverilogファイルを数日前、
githubのほうにアップロードしましたが、少し修正しました。
30個以上のテストベンチがPerlスクリプト1個を起動するだけで全部、実行できるようになりました。
githubからICF3-Z Zeviosをダウンロードして、テストベンチが動作すれば、あとは、
それを参照して、自分に必要な修正ができると思います。
頭の痺れで丸１日以上、何もできませんでした。
今朝は眠れなくなるくらい歯が痛み、朝起きて歯医者の予約をしました。
しかし歯の痛みは、なぜか治ったので狙い撃ちできるようです。
痛みに耐えることはできても、失われた時間は取り戻すことができません。
このままの状態が続くと、どうなっていくのでしょうか？
2010年あたりの広島大学の論文の話です。
RSA暗号の演算をXilinxのFPGAに実装して、その乗算器(DSP)の利用率が100％に近い値
であることを実証したようです。論文がIEEEなどに掲載されているようです。
乗算器の利用率100％が理論限界かどうかは、わかりませんが、
それに近いであろうと考えることはできるかもしれない。
ICF3-Fのモンゴメリ乗算器の乗算器(DSP)の利用率は、どのくらいかというと、
現在、製品化しようとしている物は、75％くらいになると思います。
この数字はスレッド数を上げると100%に近づきます。
製品化しようとしているものは2スレッドです。
RSA暗号の演算の並列度は4ですから4スレッドで演算できます。
つまりRSA暗号の演算に限っていえば、ICF3-Fのモンゴメリ乗算器は
利用率100%に近い数字がでる予想です。
ただスレッド数を上げるとRSA暗号のように並列度のある暗号アルゴリズムでないと性能がでない問題がでてきますが。
広島大学はDSP 1個(あるいは数個)で演算する方式なのでレイテンシ性能が悪く、
今後、RSA暗号の鍵長が長くなれば、使えるケースが減っていきます。
ICF3-Fは鍵長に比例したDSPを使って並列に計算させても、利用率100%に近い数字が
出るという極めて優れた方式です。広島大学の数十倍～数百倍の性能になると思われます。
並列計算機をやっている人は、良くご存知だと思いますが、8個のプロセッサを使って
1個のプロセッサの1.5倍とか、そういうことは良くあります。
ICF3-Fは、8個のプロセッサを使って約8倍の性能が出るというような話なのです。
2019年12月22日 7:00PM 追加
ICF3-Fの周波数について説明が抜けたため指摘がありました。
広島大学の論文では400MHzを超えるデータもあるようですが、
実際にはCRTを使う必要があるので325MHz程度のようです。
ICF3-Fが目標としている周波数は285MHz。
広島大学は１世代前のプロセスですが、
高性能クラスのFPGAデバイス(システム性能２倍)です。
デバイス差があまり明瞭ではないので、なんとも言えないですが、
少しICF3-Fが遅いのかもしれません。
利用率が100%近い値だというのが、もう少し下がるということなのかも。
それを考慮しても、優れた並列計算性能であることに問題はないように思います。
2004年の琉球大学の論文
「並列加算を用いた高速モンゴメリ乗算器の設計」の概要を読むと、普通の人は、
僕のICF3-Fのモンゴメリ乗算器と同じものかと疑われそうなので、説明します。
概要には並列加算について「2回の加算を並列に行う」と書かれています。
僕の並列加算は巨大整数を分割して並列に加算することです。
同じ並列加算ですが内容が全く異なります。
もう一つ、この論文の概要の最後に「従来のWMM乗算器の遅延時間を約63%削減できることがわかった.」
とあります。この数字、前提条件がありません。
僕のモンゴメリ乗算器の場合、巨大整数の桁数に応じて、削減量が変化するため、
この点からも、琉球大の論文と僕のモンゴメリ乗算器が全く異なるものだとわかると思います。
別の判定方法としてCarry Save Adderというキーワードが論文に入っていれば、
僕のモンゴメリ乗算器とは異なると考えられます。
Carry Save AdderはICF3(1999年)では使っていますが、ICF3-Fでは使っていません。
IEEEなんかにもdynamic instruction set computerとか慶應大学のWASMIIとか動的再構成するハードの研究があります。
ICF3-Zは再構成可能な機能ユニットは存在しません。
圧縮命令の実装実体は特殊な分岐命令なので問題ないと思います。
2010年ごろ日立製作所 中央研究所でFPGAを使ったSSLアクセラレータを開発していたようです。
僕も1994年4月～1995年1月まで日立製作所 中央研究所の超高速プロセッサ部に所属していましたが、
僕が現在、開発しているICF3-F(SSLアクセラレータ)とは全く関係ありません。
海外の特許を調査、ICF3-Zの圧縮命令が特許侵害を疑われそうな特許を見つけました。
韓国の特許「構成可能機能ユニットを含むプロセッサを使用してコンピュータープログラムを行う方法、
プロセッサ及びコンピューター判読可能記録媒体」
ICF3-Zは再構成可能な機能ユニットは存在しません。
圧縮命令の実装実体は特殊な分岐命令なので問題ないと思います。
年末年始、休まず作業予定。
8bit CPU ICF3-Zは来年1月15日に、
Apache License 2.0として公開予定で、現在準備中です。
XilinxのFPGAに実装したverilogファイルをgithubにアップロードしました。
これまで限定公開したバージョンとほどんど違いはありませんが、
不要なファイルを削除したので、これまでより読みやすくなっていると思います。
Xilinx依存な記述はないのでverilogが使えるシステムなら、使えると思います。
ICF3-Zのオリジナル実装をZeviosと命名しました。
名前の由来は、アーケード版ゲーム XEVIOUS(1983年)のデッドコピーXEVIOSの頭文字XをZにしたもの。
XEVIOUSはBASICマガジンに連載されるなど当時、大人気でした。
CPUは8bitのZ80が3個、使われているそうです。
僕が1999年に設計・開発し、世界の銀行などに売れた暗号LSI ICF3。
この影響かもしれないが、日本の特許にはICF3のモンゴメリ乗算器の改良型が、
大手メーカー(含む早稲田大学)で特許にされているようです。
これらの改良型はブースの乗算アルゴリズムを使っています。
僕が2018年に発明したICF3-Fのモンゴメリ乗算器は、これらの特許よりも性能がいい。
面積を小さくする目的では、ブースを使った改良型のほうが、いい場合があるかもしれないですが。
つまり、この分野では僕が日本で一番、頭がいい、ということのように思った。
しかし、連日の頭痛で、劣化が進んでいる。
遠隔頭痛装置を止めないと、問題ということには、ならないのだろうか。
昨日は、失明の前兆が現れている。
1999年のICF3、2018年のICF3-F、２度あった。２度あることは３度あると思えないだろうか。
特許を調べているとマイクロソフトの高速RSA署名検証の特許を見つけた。
ソフトウェアのアルゴリズムで、100%の正しさはないが、計算量が10分の一以下になるようなことが書かれている。
つまり量子コンピュータの解読脅威のためにRSAや楕円の鍵長を長くするのだが、スマホでの検証の性能や電池に問題が生じる。
元々、RSAのほうが楕円よりも検証コストが小さいのだが、マイクロソフトの特許によって、
RSAが有利になるのではないかという予感。
マイクロコード関連の特許を調査、ICF3-Zの圧縮命令に影響するのではないかと
疑われそうなインテル特許を見つけた。
「命令エミュレーションプロセッサ、方法、およびシステム」
ICF3-Zの圧縮命令は、命令をエミュレーションするものではない。
エミュレーション論理は存在せず、圧縮命令を解釈するにも、ICF3-Zのアーキテクチャが前提になっている。
ICF3-Zのアーキテクチャに適合しないエミュレーションはできない。
2000年ごろの日立製作所(現ルネサス)が特許申請して拒絶された２件と、一見、酷似している。
1件は内容を読むとICF3-Zの圧縮命令と、すぐに異なることがわかるが、
もう一見は精読しないとICF3-Zの圧縮命令と異なることがわからない。
ICF3-Zの圧縮命令は、後方互換性のための機能ではないため、実装が全く異なる。
もっと単純な実装方法で、実現されていることである。
8bit CPU ICF3-ZをApache Licenseとして公開するため特許を調査した。
メモリ効率を上げるためプログラムコードを圧縮して、それを伸長する回路などの特許がいくつかみつかった。
ICF3-Zの圧縮命令は16bitの命令コードを使ってメモリ効率を上げるものでプログラムコードを圧縮しているわけではない。
インテルの特許「ミドルウェアとしてのプラットフォーム独立のＩＳＡエミュレータ」が危ないと思ったが、
ICF3-Zの圧縮命令はISAエミュレータではなく、ICF3-Zの圧縮命令というICF3-ZのISAなのです。
先日、ICF3-Zを公開した後、ネットの反応を見ていると「後方互換の機能があっていいね。」というのがありました。
ついつい誘導されて、ICF3-Zには後方互換性の機能がありますとか言うと、ISAエミュレータだと勘違いされて、
インテル特許でICF3-Zを抑えられてしまうところだった。ネット上は、工作員いっぱいだと感じた。
今年も休まず営業していると思います。
昨年、10年ぶりくらいにOB会に参加したのですが、ある先輩に学生の頃と風貌が
変わったといわれましたが、全然、学生の頃と変わっていません。お気軽にお声掛けください。
以下、OB会とは関係ない話になります。
Chromium OSのQEMU版だけですがR76,R77,R78を公開しました。
これからICF3-Fの開発作業に戻るわけですがFPGAの実機で性能が測定できるように急ぎます。
12月11日の日記に20年前、社会人しながら大学の先生の
講義を受けた話をしていますが、期間がICF3の開発期間と重なっていたので、あれっと思ったのです。
LSIを製造するためのファイルを送付した後なので、重なっていても時間的には受講できるかもしれない。
しかし僕は製品のマイクロコード開発もしていたので、銀行に収める暗号装置のマイクロコード開発中に
外部の人と接触していたのかという感じです。残業も多くて、とても勉強時間なかったろうし。
当時のホテルの領収書を調べて確認しました。
一泊二日なのですが、連日の残業で疲れているので、受講日１日目の朝の早起きに耐えられず、
前日の夜に移動してホテルに宿泊しています。
自費です。偉くなるからと思って油断しないほうがいいです。
領収書をスキャンした画像を13枚、アップロードします。→ホテルの領収書(全部ではないかも)
僕も暗号プロセッサを開発して、日本では大きなメーカーを退職して、新会社を設立しているので、
GIGAZINEの記事を読んでみました。
「Appleが退職後に新企業を設立して
58億円を調達したiPhoneやiPadプロセッサの元開発者を訴える」
この記事にあるAppleが訴えていることの中に、僕にあてはまるものがあるのかというと、全くないです。
この機会に、少しだけ暗号LSI ICF3(1999年)の「プロセッサ」について説明します。
RSA暗号はプロセッサ＋モンゴメリ乗算器で構成されます。
僕はICF1(1997年)のリーダーを担当して、ICF2(1998年)もリーダーだったように思いますが、
途中から東大卒の小国氏が参入しました。そしてICF3のリーダーは小国氏が担当となりました。
僕はRSA暗号の演算器(剰余演算器)の設計担当になっています。
ICF3は、まだ新しかったモンゴメリ乗算のアルゴリズムを、どうやってASICに実装するのか、
あれこれ僕が考え、東大卒の小国氏が承認する形式で、設計が進められました。
僕のほうは、ICF1、ICF2を経て仕事にも慣れていたので、小国氏に、
それほど指導していただくことはありませんでした。
僕はICF3でモンゴメリ乗算器を採用するのは、やめましょうと進言したのですが、
小国氏の判断により、モンゴメリ乗算器が採用されたことは大きな事実です。
そしてモンゴメリ乗算器の設計案が決まったところで、リーダーの小国氏は、
IBMのCPUとのI/Fの設計に移行し、僕は「プロセッサ」の設計に入りました。
誰からも、何もアドバイスされることなく、快適な環境で１人で設計を完成させました。
OpenICF3のサイトでは「プロセッサ」の
設計図を公開しているので、
独自なプロセッサだということが確認できます。
そして退職時に正式な打ち合わせをして会社から正しくICF3を持ち出しています。
2018年にモンゴメリ乗算器を全部取り換えた
ICF3-Fを発明しました。
つまり、ICF3-Fは、小国氏の承認した部分すらない、完全な僕の設計で、従来プロセッサからも、
うるさく言われることもない、ものになっています。
また8bit CPUのICF3-Zも、
モンゴメリ乗算器をはずしているので、ICF3-Zについても同様です。
20年前の話です。
大型コンピュータを開発している事業部の同期で、この研修に参加したのは、僕だけだと思う。
ざっと30人に1人の確率。話では、各事業部から幹部候補生が集まるところらしい。
僕は、ICF3の開発者として、受講生や、大学の先生たちにも知られていたようです。
早稲田大学の村岡先生や、慶應大学の天野先生など有名な先生の講義が多かったと思います。
2週間に1度、東京に集まり一泊二日で講義を受けるコースでした。
受講生によっては、真面目に勉強をしてくる人もあったようですが、
僕は仕事を休ませてもらってなかったので、ロクに勉強もせずに受講していたので、それなりの結果でしたけど。
欠席があまりなければ、全員、修了できるみたいでした。
図をマウスでクリックすると拡大されます
僕のブログ
「大きなモンゴメリ乗算器は実装できるのか？」の最後の行に書いた
ICF3-Fの「鍵長２倍で計算時間４倍」が理論のように見えてくるのかも。
というのが論文の要点になるのではないだろうかと思っています。
この法則は、僕の考えたアーキテクチャを前提とした法則ではあるものの、
少なくとも、この性能が出るという下限値を正確に予測できる。
システムを設計するうえで役に立つことだと思っています。
鍵長を長くしても演算器の周波数が全く下がらず、効率がほとんど落ちない
アーキテクチャの発明も要点だと思っていますが。
早くICF3-Fの作業を進めたいのですが、人工頭痛に耐えながらの作業中。
今も、両目を開けることができず、片目をつぶって、これを書いています。
自分で言わないと、良くない予想しかしてくれない人が大勢いて、自分で言うのですが、
僕は、修士卒なのです。研究室の同期の修士卒は6名、その中で成績１番で研究室に入っています。
博士課程に進学した人は、いません。
ちなみに２つ上の学年は3名、博士課程に進学、1つ上は１名博士課程に進学。
一つ下は、正確な数字は知らないのですが、少なくとも１名は博士課程に進学しているという状況。
自分で論文が書けないか、ちょっと考えているところです。
もう少しでR76、R77、R78の3っつをCanalビルドのサイトで公開予定です。
ICF3-Fを進めたいのですが、軽度ですが人工頭痛が止まらず、
Chromium OSの独自ビルドをやっています。
数年前に亡くなった叔父、元国会議員だったのですが、コンビニの経営戦略
について語っていたことがありました。敵のコンビニ店を両側から、
挟み撃ちにして、潰すということだった。
(自) (敵)
-------------------------------------
道路
-------------------------------------
(自)
左から来る人は(敵)より近い(自)のコンビニ店に入ることが多い。
右から来る人も(敵)より近い(自)のコンビニ店に入ることが多い。
(敵)のコンビニ店は、非常に少ない範囲の客しか来ないということが、
先にわかり、１店舗しかなければ倒産が自明になる。
こういったきコンビニが複数店舗あれば、全店を潰すほどの資本がない
ことが先にわかり、倒産を免れる。
Chromium OSの独自ビルドも、そういうことなのです。
XilinxのFPGAへの実装を急いでいます。
昨年の試作には論理演算の機能がなかったのですが、面積の増加や、
ディレイの増加なくORを追加できそうなので、やってみました。
暗号プロセッサとモンゴメリ乗算器の配線をして、暗号プロセッサから
モンゴメリ乗算器のマイクロコードを起動できるように作業中です。
人工頭痛が最も問題で、これだけで作業効率が半減しています。
|
