Home

2019年
2020年

11月25日 ICF3-Zの仮想マシン技術は新しいのか?

CPUのハード支援による仮想マシン技術は従来のCPUにもあって新しい技術ではないという意見がありました。

ICF3-Zの仮想マシン支援ハードは非常に少ないトランジスタ数で実装できていること。
製品出荷後のCPUにユーザーが自由に仮想マシンを作ることができること。

でしょうか。後者は、従来CPUでも、ユーザーに開発環境を公開すれば、可能かもしれない。 性能を考えるとマイクロアーキテクチャを公開しなければならない問題から、 ユーザーが自由に仮想マシンを作るというのは困難ではないだろうか。
ICF3-Zは、他のCPUとは設計方針が違うのです。 コンパイラやOS実装の利便性を考えず、 ハードウェア実装が極力シンプルで小さくなる範囲で、コンパイラやOS実装の利便性を考えるというもの。 そういった方針から生み出される特異なアーキテクチャになっているのです。 例えば、ICF3-Zの仮想マシンの命令コード長は15bit固定。 オペコード7bit+オペランド8bitです。仮想マシンの命令コードのオペランド(8bit)が、 そのまま通常の命令セットのオペランドになるように設計されています。 そしてICF3-Zの通常の命令セットは、一般のCPUと異なり、ハードの信号線の集合体となっているので、 仮想マシン支援ハードを含め非常に小さく実装できているのです。 (命令セットアーキテクチャの設計時に、最初から作りこまれている)
非常に少ないトランジスタ数でできているICF3-Zは、 他のCPUが実装できないような領域の用途でも動作します。


11月24日 ICF3-ZをICF3-Fのオマケにする案

ICF3-Fは、今、僕が最優先で推進しているSSLアクセラレータのプロジェクトです。 ICF3-Fの最初のバージョンはXilinxの小型のFPGAを考えています。 オマケでICF3-Zをつけるという案を思いつきました。 ライセンスが決まらなないままでも、僕が出すので、面倒な問題が一切なく、僕の作業だけで実現する。 そしてオマケという位置づけで、あまりサポートしない。これでICF3-Zの可能性を存続させることが、できるのかも。
必ずオマケをつけるという話ではなくて、そうすることもできるという話です。


11月22日 ICF3-Zに興味がある方

もし8bit CPU ICF3-Zに、ご興味を持っていただけた方があれば、 匿名でない方法で、お気軽にご連絡ください。その時、限定公開したVerilogファイルを希望であれば送信します。
注意!オープンソースのライセンスを、まだ良く決めていません。 ICF3(1999年)のオープンソースの件と、合わせて、僕に憑依している闇を一掃できればと考えています。 重たいかもしれませんが、どのみち、憑依されたままでは、ICF3-Zは、あまり成功は期待できないので。 みんなで考えれば、なんとかなるかもしれません。
他の8bit CPUと比較して、ICF3-Zは、かなり優れているように思います。 そしてトランジスタ数が少なくても動作するICF3-Zは、ARM、RISC-Vなどの 32bitでは実現できない領域を持っています。


11月16日 ICF3-Zの除算が高速だと言った件

日記11月14日で「除算器を持たない廉価な32bitCPUより10倍高速かもしれない。」と 言いました。オープンソースの小型なRISC-V(lowRISCのibex)で除算器を持ったものがあるので、 そういったものと比較すれば、10倍はいかないという意見があった。(ライセンスはApache License 2.0) ibexのドキュメントには除算は 37サイクルと書いてありました。 ICF3-Zの17サイクルと比較するには周波数がわからないといけないのですが、同じ周波数と仮定した場合、ICF3-Zが2倍以上高速。 RISC-Vは小型でも32bitなので面積(LUT数)は、ICF3-Zよりもかなり大きいことが予想され、 ICF3-Zの高速な除算が優位であることには、違いはないように思いました。
ところでibexが実際に製品化されたものってあるのだろうか。 実際、ibexを使って製品を作ると、どうなるんだろう。


11月15日 ICF3-ZのソフトCPUとしての用途

FPGAでICF3-ZのソフトCPUが便利なもの。 1つのプログラムで多数のI/O制御をするより、多数の独立したCPUを使ったほうが簡単な場合とか。 ICF3-Zは、割り込みを無効にしていれば、プログラムの命令列から、 実行サイクルが厳密に決まるのでI/O制御をし易い。 良くできたパイプラインのCPUを組み込み向けに改良した奴では、 逆にパイプラインのストールによってI/O制御では使いにくいこともあるのかも。 (軽量なRISC-Vに、そういったCPUもあった。)

XilinxのFPGA(XC7A35TICSG324-1L)にICF3-Zを実装 した場合、16bit÷8bitの除算が高速で400 LUT程度なので、 これまで実現ができなかった多数のCPUを使った高度な制御システムができるのかも。 FPGAによるICF3-Zが最適解になるのかは、わからないですけど。


11月15日 ICF3-Zのメモリ効率

半導体デバイスには詳しくないのですが新しい半導体デバイスの研究は、いろいろあるようです。 エネルギー効率10倍の半導体デバイスとか、本当にできれば、電池の持ちが数倍になるとか。 あまり関わると税金の無駄遣いを叫ばれるので、いいませんが。 そういった研究とは、まったく独立して、トランジスタ数の少ないCPUを作っておくことはできるのかも。 あれば、いち早く新デバイスを商用化できて、いいのかなぁくらいですが。
ICF3-Z はトランジスタ数を少なくすることに特化したCPUですが、メモリ効率が悪いため、 トータルでのメリットが少ないと思う人もあるようです。 メモリ効率の悪さは圧縮命令を駆使することで改善できると考えていますが、さらに言えば、
例えば新デバイスでスイッチとメモリのコスト比を考えて、相対的にスイッチのコストが 大きい場合はメモリ効率が悪いことが気にならなくなる。 特にROMのコストが小さいことは、考えられます。
日記 11月14日日記 11月15日のようなことを考えてみることは、 できるかもと思いますが、僕が気づいている問題に、マイコン少年は半導体デバイスが上から目線なのが嫌みたいな話はあるようです。


11月15日 次世代MSXのファーム書換えでICF3-Zに変更でいいのか

次世代MSX のハードはFPGAに実装するみたいだから、Z80互換なCPUをICF3-Zに書き換えれば、 いいということに気づいた。FPGAのコンフィグを複数持てば、 Z80互換なCPUとICF3-Zを電源を入れるときに切り替えることができる。


11月14日 8bitパソコン時代のMSXに次世代の構想が

こちらです→ 「 次世代MSXについて現在明かされていること」 僕は8bitパソコン時代はSHARP MZ-2000だったのでMSXについて詳しくないのですが、 次世代MSXが、どのようなものかちょっと読んで見ました。過去の互換性を、あまり考えていないような感じがしています。 つまり新しい時代の8bitパソコンの共通規格みたいな。 CPUはR800というやつらしくZ80互換なようです。Z80の命令セットの問題を考えるなら、 オープンソースの8bit CPUにすればいいのにと。
僕のICF3-Zは、Z80にない乗算、除算命令らしきものがあるので高速です。
仮想マシンの加速支援機構つきの新型8bit CPU!?
特にこのクラスのCPUとしては除算が高速で、同じ周波数のCPUなら、 除算器を持たない廉価な32bitCPUより10倍高速かもしれない。 16bit÷8bitの演算が17サイクルなのでADCで12bitのデータをサンプルして制御するような目的にはいいかなと。
ただICF3-Zは、トランジスタ数を少なくすることに全てをかけたアーキテクチャなので、 一般の人にはハードルが高く、難しいかもしれません。 独自の仮想マシンで、非C言語を動作させるようにすれば、いいのですが。
ICF3-Zは、従来のCPUではトランジスタ数が多すぎて、実現できないような用途に最適です。 例えば新型の半導体デバイスが開発され、トランジスタ数の多いCPUが作れない場合に、このCPUは役に立つように思います。 税金プロジェクトはNGですが。


6月28日 HCVのリバースエンジニアリング対策

そういえばHCVのUSBデバイスのファームに書かれている公開鍵のデータを 暗号化しておけばリバースエンジニアリング対策になるかと思った。 そしてUSBデバイス毎に異なる暗号化データになるような仕組みにしておけば、別のデバイスにコピーされることはない。 方法は、48bit程度のシード(メーカー24bit、ユーザー24bit)を8bit CPUのライト・オンリーメモリにUSBデバイス事に書いておく。 そのシードと基板情報をもとにチップ内で128bitのデータにする。 8bit CPUはAES暗号のサブルーチンを読んで新しい128bitの鍵を作る。 それを使って公開鍵のデータをAESで暗号化してファームに書き込む。 専用のカギ導出回路を使う手もあるが、AES暗号で代替すれば、専用回路なしで済む。


6月27日 RSA署名と検証の演算量の違い(改訂版)

昨日の日記でRSA検証のみの8bit CPU搭載のUSBデバイスが、かなり安価という説明をしました。 これまで普通に使われているUSB認証デバイスはRSA検証ではなくて、RSA署名の演算です。 RSA署名と検証で、どのくらい演算量が違うのかをopensslのspeedコマンド (第4世代Core i3)で調べると、約30倍違います。 つまり検証のみならCPUのスペックは、かなり低く抑えられるのです。
厳密に言うとHCVで必要な処理は、SHAなどのハッシュ演算とRSA検証の演算になります。 大きなファイルではハッシュ演算が8bit CPUでは性能的に問題になる可能性がありますが、 そういう場合はファイルのハッシュ値の記載されたテキストの検証ということにすればハッシュの性能は問題なくなります。


6月27日 Linuxのソフトウェア配信にはいいかも

LinuxにはWindowsのような証明書のROOTストアがないのでコードサイニング証明書が使われていない場合も多い。 そういったソフトウェアには寄付を兼ねてHCVはいいかもしれない。


6月26日 HCVはコードサイニング証明書を代替できるか?

HCV(Hard Code Verifier)は、RSA検証のみの8bit CPU搭載のUSBデバイスが、 かなり安価であることに目をつけたものです。 ただしHCVはソフトウェアを配信する人が、8bit CPU搭載のUSBデバイスを利用者に確実に届ける手段がない限り、 コードサイニング証明書の信頼性に及びません。
フリーソフトに寄付しても、何のリターンもない問題を解決するのにいいのかもと考えています。 コードサイニング証明書か、HCVか、どちらでもいい場合、HCVになることもあるので、 コードサイニング証明書の市場が小さくなることはあると思います。 やはり、僕にとって、このあたりは問題なのかも。 HCVを含めた全体としては市場は大きくなっているはずなのですが。


6月23日 サブの日記をはじめました

いろいろな話題、とりあえずHCV(Hard Code Verifier)の話題について、思ったことを書いたり、 メインの日記noteと同じことを書くこともあります。


暗号プロセッサ OpenICF3