|
8bit CPU WZeta
のコンパイラの話をしていると、次はOSの話になってくる。
GCC-IA16(16bit版のGCC)でELKS
という組込み向けのLinux風のOSがある。
64KBの制限があるものの、その範囲内では32bitではなくて16bitで済む。
そして必要があるところだけ32bitでアクセスすれば、プログラムコードが
小さくなったり、高速に動作したりするメリットがある。
昨日からELKSを調べはじめたのですがNEC PC98のCPU、V30(i8086互換)に
対応していた形跡もある。PC98で動作させている形跡もありOSの選択肢として
ELKSが入ることがあるのだろうかという気がした。
ELKSのコードを１行も読んでないけど、感覚的には、国産CコンパイラLSI-Cに
置き換えることも、できるかもしれない。
ここらで僕の目的を書いておくと、国産化が目的なのではなく、8bit CPU WZetaを
広く普及させること。国産化に重点はない。むしろ国産化によりWZetaが孤立する
問題が大きいと考えています。
国産OSで言えばTRONが有名ですが、あまり普及していなのが現状なのだと思います。
勝手に、どんどん税金を使って整備されるOSは、一般の国民にとって、
使いたくないOSということなのではないでしょうか。
税金の問題を考えるあまり、輸入に頼り切って自給率が低下するのも、
困ることなんだと思う。自給率という言葉で曖昧にしていますが。
そういったことを考えたOSとかが、いいのかも。
CPUを普及する立場では、いろいろなOSを考えるのかもしれない。
参考までアセンブラだけで書かれたOSというのも、あるようです。
MenuetOS.net
これは数年前、ブラウザの中で動作する仮想マシン、
PNaCL QEMUで
動作させたことがあるので、動作することは確かです。
GCC-IA16(16bit版のGCC)を使ってWZetaのシミュレータをコンパイルしています。
3月19日の時点ではシミュレータ(wzsim)が動作していましたがアセンブラ(wzasm)は、
何故かバグっていました。Intel x86特有のメモリモデル「スモール」を意識して、
ソースコードを整備したところGCC-IA16(16bit版のGCC)でも、動作するようになりました。
これでMS-DOS版で動くバイナリが作れます。Open WatcomのCコンパイラでも可能なのですが
日本に中古として眠っているPC98のMS-DOSで正しく動作するのかは不明。
ネット上には、GCC-IA16で生成したバイナリをPC98で動作させた人があるようです。
マルチプラットフォームで展開することを考えているので、どうしても国産Cコンパイラを、
と思ってもう一度、LSI-Cの試食版で動作させることを始めましたが、多くの関数を
小さく分割しないと実行できるバイナリを生成できない。試食版の制限が厳しく途方に暮れました。
MS-DOS版のバイナリを作って、何がいいかといえばWindows95すら動作しないマシン、
恐らく死蔵されているマシンを、子供の教育向けに復活させることが、できそうだと
思ったからですが、中古マシンを持っているわけでもなく、すなわち、儲かるあてがあるわけではないので、
LSI-Cの有償版を購入することは、難しいという状況。
結局、WZetaのシミュレータはWindows95まで、ということになりそうですが、
MS-DOS版に興味がある方は、ご連絡ください。
8bit CPU WZetaを広めるために時間を割いています。
昨日の日記はC言語で書かれたWZetaのシミュレータをコンパイルする話でしたが、
今日は、WZetaのCコンパイラの話です。
昨日の日記を見て気になった人があったので書いてみます。
WZetaのサイトの
ライセンスのページの下のほうに書いてある通り、
日本の税金を使ったプロジェクトによるCコンパイラは不可です。
8bit CPU WZetaは、従来にないハードマクロ命令を持っているので、
これを活かす方法は、一つではないと思っているので、Cコンパイラを
一つに絞らない方がいいと思っています。
データの配置アルゴリズムが最適化にないと十分な性能にならないと
予想されるため、過去の焼き直しのCコンパイラでは、十分な性能が
でないかもしれない。
WZetaのCコンパイラの開発は厳しい状況にあるため、当面はアセンブラで
使えばいいように考えています。データ配置を工夫して性能を出すことが
容易なので。
SoCマイコンのTPM(暗号プロセッサ)として需要があるように思えています。
WZetaはICF3(1999年)の暗号プロセッサを開発した僕が設計しているので、
暗号演算は効率的です。ただ8bit加算器1個なので十分な性能が出せるかは、
公開鍵暗号のアルゴリズムと製品に依存します。
スパコンや量子コンピュータを駆使しても解読されないことを期待しなければ、
技術的にはWZetaは、とても良い選択になるはずです。
標準メモリ(640KB以下)のMS-DOSで動作するコードを出力できる無償の
Cコンパイラを調べています。
オープンソースの8bit CPU WZeta
のシミュレータをフリーウェアとしてリリースしてみようかと思っています。
(MS-DOS版は)ほとんど趣味なので、無償のコンパイラがあれば使ってみたい
と思っていたところに、国産Cコンパイラ LSI-C試食版があったので調べています。
LSI-C試食版のWikiにはフリーウェアを作るなら良いみたいなことが書いてあったが、
ダウンロードしたLSI-C試食版のREAD.MEの「使用条件」を良く読んでみる。
READ.MEからの抜粋
4. 本パッケージを使用して作成したプログラム
本パッケージを使用して作成したプログラムは、自由に配布すること
ができます。その際に手数料と認められる額を超える金銭の授受を禁じ
ます。利益を得るためのソフトウェアの開発には、別途製品版の LSI C-86
をご購入の上、ご利用ください。
WZetaのアセンブラ、シミュレータをフリーウェアとして誰にでも使って
貰えるように公開すれば、良さそうだと最初に思ったのですが、良く読むと、
フリーウェアと中古パソコンをバンドルして売ると、利益を得るためのソフトウェアの
開発になるようにも、考えられる。
LSI-C試食版を配布しているエル・エス・アイ ジャパン（株）では、現在でも
8086のCコンパイラを販売する事業をしているし、価格も48000円なので、
無理な価格ではないのだけど、ほとんど趣味のフリーウェアには、厳しいので、
他のCコンパイラを探し始めたという状況。
学生時代にボーランドのPascal、C、Debagger、Assembler、Profilerを結構、
購入している。ただ「学生に正規ライセンスを学んで欲しい」みたいな宣伝文句で、
学校のサイトライセンスではなく、学生個人向けのエディションがあって、
それを購入していた。1言語、1バージョン、1万2000円くらいだったと思う。
現在、これらのボーランド製品は「アンティークソフト」としてダウンロード
できて利用可能。この「アンティークソフト」というのが、良くわからないけど、
このボーランドのTurbo C 2.0が、良さそうな感じかも？？？
MicrosoftのCコンパイラでMS-DOSの16bitのコード出力できるのは
Virual C 1.52。MSDNサブスクリプションを何度か、
過去に購入したこともあるので、
そのときにダウンロードしていれば、今、使えた。が、しかし、
ダウンロードしていなかったから。Microsoftライクなダウンロードサイト
からダウンロードして使うというのも、良さそうな案の、一つ。
Open Watcomのバイナリ配布は、どうなんだろう。国産Cコンパイラとか、、、。
というところです。
最近は小学生でもプログラミング教育が当たり前の時代になっているようです。
8bit CPU WZeta
を搭載したボードでもあればBASICみたいな言語を用意して、
プログラミング教育の役に立てばいいかなと思うのですが、幸か不幸か、まだ無い。
MS-DOSが動作するNECの初代PC-98クラスの中古パソコンが、WZeta搭載の
ボードになればと思って、国産C言語 LSI-C 試食版でWZetaのシミュレータが
動作しないか、作業中。試食版のライセンスでもフリーウェアの配布はできる。
16bit OS特有のfar、nearポインタの使い分けだけでLSI-C試食版でコンパイル
できるようになるかと思っていたが、実際にやってみると、もう少し窮屈。
ほんの少しコードサイズの大きい関数は、コンパイル中でOut of Memoryになるし、
ファイルを読み込むfgetc()関数も1018回、呼び出すと落ちる。
学生の頃は、アカデミック・ライセンスのTurbo Cを使っていたのでLSI-C試食版を
使ったことはなかったのですがソフトバンクのCマガジンのおまけFDDに
添付されていたこともあって、当時の人たちは、無償のLSI-C試食版を良く使っていたようです。
おかげで無償とはいえ、そこそこ使えるCコンパイラなのかもと、思っています。
昨日、FreeDOSに1ドル寄付
したけど全世界で毎月46人しかいない。その1人に僕もなったけど、来月まで、続かないかも。
GIGAZINE記事
「パスワード認証なし」の世界に向けて足りなかったピースをFIDOアライアンスが発見
僕は、認証ハードの技術については、非常に詳しいと思う。
最近は、勉強不足という感じかもしれないけどGoogleが立ち上がる前から、やっている。
認証ハードウェアの初期の時代はイスラエル アラジンのeTokenが最も有名。
eTokenはMicrosoft Windowsの最初のAPIを実装していたけど、Microsoftの仕様に多少の問題点があった。
これは日立のシステム開発研究所が試作実装していたので、気付いた人は多かったと思う。
そして次にMicrosoftはICカード向けにBaseCSPをリリースするけど、これもWindowsXPまでは
大きめの欠陥があった。
2007年ごろに自社開発のICカードmyuToken
をリリースしているけど、Microsoftの仕様上の問題を対策していたセキュリティの高いカードだったと思う。
個人でやっていたけど、世界で製品化されていたものより、高いセキュリティだったことは、
良くやっていたと思う。
何度も自慢している話では国税e-Taxで使わせた日立のICカードリーダのドライバは、
複数アプリからのアクセスすると、処理しきれず、予期せぬタイミングでエラーを
発生させる問題点があった。当時はICカードアプリは、ほとんどなかったので、
大きな問題にはならなかったのか、このバグが対策されるまで
１年以上かかっていたと思う。
僕が作ったUSBメモリをICカードリーダにするためのドライバでは、そういった問題はなかった。
営業部署で１人でプログラムしている僕のプログラムより、
日立が国に使わせる製品(中国製)は品質が低い。
この分野の製品は、どうも、いろいろあるらしく、僕のような専門家が非常に大事かもしれない。
GIGAZINE記事に話を戻すと、まだセキュリティ不足かなという感じで、より高いセキュリティを、
2008年の「組込み総合技術展」で発表しています。
場所の提供は、独立行政法人IPA。
C言語のシミュレータではなくてverilogシミュレータを追加しました。
verilogのソースコードではなくてicarus verilogでコンパイルされた
シミュレーションファイル。C言語シミュレータでは信用ができない人向けの
verilogシミュレータです。メモリモデルTINY、4KB限定のシミュレータですが、
いろいろ試せると思います。ただ１人で平行していろいろやっているので、
修正をしているうちに、いままで動作していたものが動かないということは
あるのでbeta版に満たないものですが参考にはなると思います。
2022年5月2日、公開終了
SHA-1 : 2abf41d94e2874d9a1a82cc9b4f3b13b42d9a8ae
お試し公開の４回目です。Win95/98/ME版のバイナリが追加されました。
FreeDOS版はありませんが、FreeDOS版をコンパイルしたものと同じソースコード。
以下同文
オープンソースの8bit CPU WZetaですが正式リリースまで待てない
という人も、あるような気がしたのでシミュレータのWindows版の
バイナリだけでも先にお試しで公開しています。ベータとかRCの
ような公開ではなく、とにかく動いていることを見てもらうことが
目的です。
力のある人は楕円暗号のプログラムが、どのくらいの性能になるか
を確認したりすることにも、使えたらいいなと思っていますが、
まだまだ仕様変更は、あるかもしれないので、コアの部分の性能を
見てみるくらいのことしかできないかもしれません。
アセンブラ仕様は、まだ自分用のメモなので、わかりずらいと思
います。ご了承ください。書いてあることは、だいたい実装してい
ますが、間違いは多数あるような気がします。
2022年5月2日、公開終了
SHA-1 : 74a7d50b2ccd450947a078e7ad8402166971f25e
サンプルコードとして32bitの仮想マシンでハッシュ関数のSHA-1を演算する
プログラムが付いています。
お試しでWZetaシミュレータをWindowsのクローズドのバイナリで配信しています。
C言語の標準関数しか使っていないのでクローズドで問題はないはずなのですが、
オープンソースではなくなったのかと、心配している人も出てきたので日記に書きます。
WZetaはオープンソースにするつもりです。
WZetaのライセンスのページ
に最初から書いていることですが、産業スパイが妨害しないように転職させることも、
よろしくお願いいたします。
1人でいろいろやっているのでソースコードが乱れていてオープンソースとして整備された
ソースコードにするには、時間がかかります。そこで先にクローズドで配り、
先端8bit CPUの技術を使ったアプリの試作を考えることが出来ればと思っています。
WZetaは高効率ですが、効率を引き出すには、プログラミングテクニックが必要です。
GNUのCコンパイラGCCが16bit版(GCC-IA16)を開発しているようです。
8bitのCコンパイラよりも16bitのCコンパイラのほうが作りやすいという「気がしています」
WZetaは8bit CPUですがハードマクロ命令で16bitアクセス命令を追加すれば16bitのCコンパイラの
ノウハウを持ってこれるのかなと。ただ性能は、それほど期待できないかもしれません。
前回は16bitアプリ化したWZetaシミュレータしか動作しませんでしたが、今回は、WZetaのアセンブラも16bit化して、
なおかつ、シミュレータからアセンブラを起動してSHA-1のプログラムを実行させることに成功しました。
厳密にはバッチファイルでアセンブラ(wzasm)とシミュレータ(wzsim)をパイプで繋いでいます。
コンパイラはOpen WatcomC 1.9を使いました。GCCの16bit版でもコンパイルできましたが、
SHA-1のプログラムをアセンブルするとバグります。(FreeDOS 1.3の)
GCCのオプションにメモリモデルの指定があるのですがsmallとmedium以外は、オプションが
存在しないというエラーになるようです。
wzsimはgccのsmallモデルでsha-1を演算できました。
watcomでコンパイルしたwzasmとgcc 16bitでコンパイルしたwzsimをパイプで繋いでも、正しい計算結果になりました。
下記画像はFreeDOS 1.3をQEMU上で動作させています。vgaのキャラクタ表示でターミナル内に表示されるので、
開発環境として便利、、、と言いたいところですが、QEMUのvgaの設定がうまくないのか、時々、画面が乱れて使いにくい。
VirutalPCや実機では、そういった問題はないと思われますけど。
とてつもなく古いPCでも8bit CPU WZetaのアセンブラ・プログラミング環境になります！
もし興味がある人で、悪意の無い人は、お気軽に、ご連絡ください。
図をマウスでクリックすると拡大されます
FreeDOSの16bit向けにコンパイルしたWZetaシミュレータがSHA1を演算するプログラムを実行して正しい答えを出力。
コンパイラはOpen Watcomを使いました。
WZetaシミュレータ(wzsim)は、int型が2バイトになる場合があることを考えていないので
完全16bit対応できたということではないけど、少し作業すれば、できるかもしれない。
WZetaアセンブラ(wzasm)は、コンパイルができて実行も可能ですがStack Overflowで異常終了。
アセンブラのほうも省メモリ化を進めれば、どうにかできる可能性はある。
ただたとえ対応できたとしても機能拡張していくうちに16bit版を切り捨てることはあるかもしれない。
学習用なら全機能を使えることもないから問題はないという考え方もある。
つまりIntel 16bit CPU、80286を搭載したFreeDOSのマシンでも頑張れば、動作させることができるかも。
そのことが、どれくらい役に立つのかは、僕のほうでは、わからない。
ただ遠い将来、8bit CPU WZetaを搭載した独自OS？マシンで、WZetaのプログラミング環境を作れる可能性はある。
これも、どれくらい役に立つのかは、難しいかな。
とてつもなく古いPCでも8bit CPU WZetaのアセンブラ・プログラミング環境になる。
もし興味がある人で、悪意の無い人は、お気軽に、ご連絡ください。
昨日の報告では、動作したのはWZetaのシミュレータのみで、
アセンブラはlsearch()、lfind()関数が無いためにコンパイルできなかった。
これらの関数は数行で実装できそうだったので、実装してアセンブラも動作させることに成功した。
シミュレータwzsimからアセンブラwzsimを起動してアセンブラのコードを直接シミュレーション
させることも、FreeDOSで、うまくいった。
相当、古いPCでも8bit CPU WZetaのアセンブラ・プログラミング環境になる。
もし興味がある人で、悪意の無い人は、お気軽に、ご連絡ください。
WZetaシミュレータをWindowsのバイナリでダウンロードできるようにしていますが、
WindowsがないPCでもFreeDOSなら動作すると思って半ば趣味でやってみた。
現在、ダウンロードできるバイナリはWindows2000までしか動作しない。Windows95/98/MEでは動作しない。
Microsoft Visual C++ 6.0sp6 PlatformSDK 2003Febでコンパイルしたところwzsimがwzasmを内部起動できないものの、
wzasmでシミュレータ用のファイルを出力して、wzsimで実行できた。
Windows95/98/MEで動作させることに成功した。
FreeDOS 1.3が最近リリースされたのでC言語のWZetaシミュレータをコンパイルできるC言語を探してみた。
FreeDOSではOpen Watcomが良く使われているようなので整数型のintのバイト数をコンパイルして調べると
2バイトだったのでFreeDOSのためだけにソースコードを改良することはできないと判断しOpen Watcomを断念。
FreeDOSで動作する32bitコンパイラを探すとdjgppが見つかる。FreeDOS 1.3のボーナスCDのほうに収録されているため、
インストールは簡単。wzsimは何の問題もなくコンパイルできて32bitの仮想マシンによるSHA-1の演算が正しい答えを出した。
ただアセンブラのwzasmのほうは標準ライブラリのlsearch()、lfind()が無いためにコンパイルできなかった。
自作版のlsearch()、lfind()を作れば良さそうなのだが、そこまで時間は無いので、今回は断念。
FreeDOS版のWZetaシミュレータをどうするのか?
Windows95/98/ME版のWZetaシミュレータまではMicrosoftのCコンパイラにお金を払っているけど、
FreeDOS版は、OSとCコンパイラのどちらも無償なので、寄付とかを考えることになりそうなので、
FreeDOS版の必要度を考えると、無理してFreeDOS版のWZetaシミュレータを配布することは、
ないかなぁと思っているところ。
でもFreeDOS版だとIntel 486、メモリ32MBの中古マシンでも動作しそう。
儲かるから、やりたいという人があると、もしかすると考えるかも。
図をマウスでクリックすると拡大されます
普通の人は読む必要、無しです。
パソコンにサイバー攻撃された日記を書いているせいか、SNS上に
Windows11のセキュリティ機能が有効になっているのかというツイートがありました。
PC Watch記事
Windows 11のセキュリティ機能は性能を下げるのか？仮想化ベースのVBSを検証
セキュリティ機能は、全部、有効です。
記事によれば、Windows10からのアップグレードでは有効にならない「メモリ整合性」も
有効になっていました。
記事は昨年のもので、Windows11は2022年1月28日にアップグレードしていますから、
最近のアップグレードでは「メモリ整合性」が有効なのかもしれない。
あるいはサイバー攻撃が頻繁に起きているので、Windows10時代に手動で有効化していたのかも。
あるいはWindows11にアップグレードした後、セキュリティ設定の見直しをしていたかも。
少なくともコア分離については、手動で、有効化した記憶がある。
図をマウスでクリックすると拡大されます
パソコンではMicrosoftがAMD・Intel・Qualcomm と共同で開発したセキュリティプロセッサー「Microsoft Pluton」
が搭載されたパソコンが発表され、それなりに話題になっているようです。
マイコン向けのセキュリティプロセッサとして8bit CPU WZeta
は低性能であることを除けば最適だと思います。
ICF3(1999年)など暗号プロセッサの開発経験のある
僕がWZetaを作っているので無駄がなくて公開鍵暗号性能の効率が良いCPUになっています。
小型のCPUではハーバードアーキテクチャが多いためプログラムメモリとデータメモリの２種類を搭載する
必要がありますが、WZetaは1個で動作します。
8bit加算器1個では、やはり性能は低いですがRSAの検証は計算量の少ない演算なので、インターネットから
ダウンロードしてきたファームを検証する用途には使えるように思います。
メモリがある限り演算できる鍵長に制限はありません。
また軽量な暗号アルゴリズムを採用すれば、コスパの良いマイコン製品が作れるように思います。
まだお試し段階ですが、この日記でWZetaのシミュレータをダウンロードできるようにしました。
SHA-1を演算するサンプルコードがついています。ハードマクロ命令を使った仮想32bit CPUを使っています。
WZetaの命令コードは2バイト固定長ですが、通常モードでは15bit、高速モードでは16bit、
ハードマクロ命令を使わない場合は14bitで動作する命令セットになっています。
WZetaの面白い機能の一つかなと思っています。
15bitや14bitの場合、空いているビットをパリティにすることもできます。
14bitではプログラムコードが冗長になるため、より大きなメモリ容量が必要となりますが、
パリティ付きメモリがない場合でも、パリティの信頼を得られるメリットがあります。
現在は正常に復帰した模様。
3月13日に午前３時ごろメール受信障害が発生。
メールサーバの過負荷であるメッセージをメールソフトが警告メッセージを出しました。
２月末に１週間近くメール受信障害を起こしていましたが、この原因を
サーバ過負荷に置き換えるサイバー攻撃かもしれません。
サーバ過負荷が原因だったなら１週間受信障害ということは、なかったはず。
サイバー攻撃によるウィルスによってメールソフトから見るとサーバ過負荷と判断するような、
工作をされた疑いがあるということ。
ここ数年、散々、サイバー攻撃されたため、サイバー攻撃は
利用者に原因を誤判定させる偽装をしてくる場合が多いということを知りました。
僕の持つ暗号プロセッサSnakeCube
の技術は日本の将来を左右すると思います。
この国の状況を理解すれば、このままではまずいということは、わかるように思います。
邪魔が多く入って困難であろうことは、わかりますが、このままではまずいことになるでしょう。
状況を良くわからない人は、僕以外の人から暗号プロセッサの技術を得ればいいと思うかもしれない。
僕の発明した技術は、世界中の人が常時httpsのときにRSA暗号の高速化を、いろいろやった後、発明されています。
つまり僕以外できなかったことが、はっきりしているのです。
この発明を他の日本人がマネをすれば、僕を監視する世界の人が自国で開発しても良いと思うようになるのです。
僕はARMと同じようにライセンスのビジネスができればと考えいます。
簡単に言えばSnakeCube
は小さいプロセッサを並べたSIMD型が基本系。これに魔法の配線をすることでRSA暗号を高速化しています。
これから主流となる耐量子暗号向けの命令セットをSnakeCubeの小さいプロセッサに追加。
RSA暗号と耐量子暗号のどちらも性能加速できるような暗号プロセッサに改良することは、
できるかもしれない。
言い換えると大きな整数を使わないタイプの耐量子暗号にSnakeCubeは対応できるかもしれないという話です。
これが可能なら量子コンピュータの解読問題の影響を受けずに、開発したほうが良い暗号プロセッサになります。
近いうちに検討します。まだ少しも検討していないので、何とも言えませんが、うまくいくときは、うまくいくので、
SnakeCubeに期待をしてください。
シングルスレッドでは周波数を上げられないので２スレッド化して周波数２倍を実現。
まったく別の演算で２スレッドにするのではなくA×B mod P、A×A mod Pの２つを実行するハードウェアにする。
この２つの演算であれば、おおよそ鍵長と同じビット数のA、Pのレジスタを共用できるため、
トランジスタ数当たりの性能に貢献する。
RSA暗号ではタイミングアタックのサイドチャネル攻撃を回避するため、
A×B mod P、A×A mod Pはすべて有効な演算となる。
楕円暗号でも、A×B mod P、A×A mod Pを有効に使うと性能を上げることができます。
これはICF3(1999年)にIEEE P1363のドラフトにあるアルゴリズムを実装して確認しています。
何度も紹介している資料なので、ご存じの方も多いかもしれませんが
OpenICF3のサイトにあります。
RSA演算器(暗号プロセッサ)で楕円暗号の試作実装
A×B mod P、A×A mod Pがハードウェアで高速であることを知っておいたほうが良さそうです。
量子コンピュータが着実に進歩している。
EE Times Japan記事
「量子コンピュータ、クラウドで提供進むも課題は山積」
量子ビットの数の伸びが年間90％に到達するか、どうか「賭け」ができそうなほどになっていると
記事の結末に書いてあります。
RSA 2048bitの解読に必要な量子ビット数が状況によって違うため、この記事のIBMの量子ビットが
いくつになればRSA 2048bitが解読できるのかが、わからないと、大騒ぎできない。
2048bitで解読できるということであれば2024年には到達しそうであり、まだこれから選定結果が
出される耐量子暗号の安全は十分に確保できていない。
大きな鍵長のRSA演算器を流用できる耐量子暗号を選定すれば
SnakeCube暗号プロセッサを導入することで、
低コストに量子コンピュータの解読対策ができるように思う。
まず産業スパイに転職していただいて、いろいろと連絡が取れるようにと思っています。
これまで考えてきていますが、こちらも状況を知らなければ効率的な取引にならないため、
取引に至らないことしか、起きない。幸いにも(株)iCanalが既にあるので、できる可能性はあると思います。
妨害され進捗なくて困っているという報告かも。
LCD付きWZetaシミュレータの開発をしています。
LCD付きシミュレータはクローズドのフリーウェアにする予定ですが、配布するサイトだけ先に作ってみた。
subnoteのサイトのサブディレクトリをサイトっぽくしたもの。
https://subnote.icf3.net/wzlcd/
subnoteのサブディレクトリにしたのは、頻繁に更新するのを容易にするため。
サイバー攻撃に弱い問題があるので更新頻度が下がったところで別サイトのサブディレクトリに
移転する予定にしています。
開発パソコンも別パソコンにしてサイバー攻撃が、WZeta本体に及ばないように気を使っています。
シミュレータのソースコードをフォークすることになりますが、フォーク後のメンテナンスが
楽になるような仕組みで作る予定。
産業スパイによるサイバー攻撃で脳が痺れて思考力低下と視力低下。
満腹中枢を活性化されて眠気もある。脳の痺れは脳劣化に怯えることになるのでキツイ。
長期間の観測でも劣化して回復していない。普通の速度では文字は読めない。
１文字に１秒くらい時間をかけないと正しく読み取れない。単純なカタカナのほうが、読みずらい。
EE Times Japan記事(3月8日)
「着実に実用化に近づくO-RANの最新状況、MWC 2022」
特に記事の内容に関心があったわけではなくてO-RANが進んでいて、僕が置いていかれる感じで焦っています。
O-RANにはXilinxが参加しているのですが、僕は2020年11月にはXilinxの30万円のPCIeカードを購入している。
だから、このPCIeカードAlveo U-50に鍵長の大きなRSA暗号を演算できるアプリを開発することもできたはず。
しかし開発は妨害され中止された。
RSAは量子コンピュータによる解読リスクがあるためXilinxのFPGAデバイスは、都合が良かったはずで、
Xilinxも儲けそびれたような気がしています。
量子コンピュータでRSAが解読されたというニュースがあれば、耐量子暗号のアプリに入れ替えるだけで、
ハードを交換する必要がなかったのですから。
SDLのサンプルコードをコンパイルしてみた。320x200ドットのLCDを想定した大きさ。
WZetaのシミュレータのメモリを読んで画像に書き込むスレッドにすれば良さそう。
すぐにできるかも。CPUで直接、LCDに書き込む方法は、とりあえず後でもいいかな。
図をマウスでクリックすると拡大されます
8bit CPU WZetaの開発をしていますが、世の中の人はRSA 2048bitの安全性を
心配している人もあるように思ってます。僕も気にしています。
メジャーなメールソフトThunderbirdで標準となったOpenPGPは既にRSA 3072bitに
移行しているみたいです。いつ移行していたのだろう。
鍵生成でRSA 2048bitは、もう選択できません。
暗号プロセッサSnakeCube
に御用がある方は、ご連絡ください。
マイコン向けのRedCoderコアの開発に向かう予定でしたがLCD付きのWZetaの
シミュレータを作れば、ここ数週間で日記にしてきた
WZetaの新技術の可能性(1)～(5)
の低コスト化の話を進められるように思ったので。
LCD付きWZetaシミュレータは画面表示ライブラリを使うため、
単体のシミュレータとは別扱いにします。
画面表示ライブラリのライセンスを考えたライセンスになるのですが、
クローズドにしてしまえば、ソースコードを整理整頓することなく、
素早くリリースできるかもと考えています。
今のところSDLのzlibライセンスなら、可能かと考えています。
LCD付きWZetaシミュレータはクローズドであっても、
WZetaのSDogコアをApache License 2.0(予定)で公開してしまえば、オープンと同様だと考えています。
僕の目的は、お金よりは、産業スパイに転職していただいて、円滑に開発が進み、
世界のマイコンの低コスト化になればと思っています。
すぐに販売価格に繁栄されるのかは販売するところに依存することになるのですが、
思惑通り地球資源に優しいマイコンになれば、緩くは普及することになるように思います。
アセンブラの定数の表記に2進数を追加しました。
wzasm.exeのバイナリだけ差し替えました。
2進数表記が可能なのはLD命令など、命令のオペランドとデータの初期値。
定数の先頭2文字を'0b'とすると2進数として解釈されます。
命令では次のような表記が可能です。
LD A, 123 ; 10進数
LD A, 0x7F ; 16進数
LD A, 0123 ; 8進数
LD A, 0b00111100 ; 2進数
データの初期値
.DATA
MEM 8 gamedata \
0b00111100
0b01000010
0b01000010
0b01000010
0b01000010
0b01000010
0b01000010
0b00111100
2022年5月2日、公開終了
SHA-1 : 81bd277b1505d35e7385f7b0f063fbbbe71bb293
(1)の日記で公開したバイナリの対応OSは
x86_64のWindows10/11版だったのでネットからダウンロードした
実行ファイルを試すのは、厳しいかと思ったのでWindows2000/XP対応のバイナリを
追加しました。操作方法は同じです。
公開ファイル WZetaシミュレータ Windows版のバイナリのみ
WZetaSim2022_03_04.zip
SHA-1 : bc9d7174e9a83c2101034d82359592b10b237781
WZetaに乗算器が無いので設計できないのか？という質問があるなら、
そういうことはない。大型コンピュータの設計部にいたときに１カ月以上、
乗算器を設計していたと思う。仕事が尽きてやることがなくなったときに
乗算器の設計をしていた。上長に乗算器をASIC上に実装したいと言ってみたが通らなかった。
しかし設計のほうは、いろいろやっていてIEEEの50年以上前の論文にあった乗算器を
再現するようなこともしていた。ICF3(1999年)の後継の暗号プロセッサの開発するべく、
検討していたときに、暗号プロセッサに合わせた周波数で設計できるのかを、上長に聞くと、
CPUの周波数に合わせるように言われたため、普通やらない演算ゲートの
途中でフリップフロップを入れることをした。
OpenICF3のトップページの「幻のICF4 設計資料」
に前述したような歪んだ設計のことが書かれている。資料に書いた「はみ出しwallaceツリー」のこと。
カラーのグラフで中央が陥没した絵になっているところ。実際の製品化のためのドロドロな設計を
見てもらうのに、ちょうど良いような資料です。
ICF3(1999年)の後継では、通常の乗算器を大型化したものを採用しようとしていた。
このため乗算器の設計についても僕は詳しい。暗号演算向けなので符号無しのみですけれども。
オープンソースの8bit CPU WZetaですが正式リリースまで待てない
という人も、あるような気がしたのでシミュレータのWindows版の
バイナリだけでも先にお試しで公開しています。ベータとかRCの
ような公開ではなく、とにかく動いていることを見てもらうことが
目的です。
力のある人は楕円暗号のプログラムが、どのくらいの性能になるか
を確認したりすることにも、使えたらいいなと思っていますが、
まだまだ仕様変更は、あるかもしれないので、コアの部分の性能を
見てみるくらいのことしかできないかもしれません。
アセンブラ仕様は、まだ自分用のメモなので、わかりずらいと思
います。ご了承ください。書いてあることは、だいたい実装してい
ますが、間違いは多数あるような気がします。
2022年5月29日、公開終了
3月4日の日記にWindows2000/XPでも動作するバイナリを追加した3月4日版があります。
サンプルコードとして32bitの仮想マシンでハッシュ関数のSHA-1を演算する
プログラムが付いています。
結局、何がうれしいのか。短く説明すると割込みを使わないマルチタスクによって
銀行向けトランザク認証端末などの液晶LCDから(SRAMなど)表示メモリとコントローラを削減できること。
液晶LCD搭載端末全般に応用ができる。
多数のトランジスタを搭載する必要がなくなったLCDデバイスは「恐らく」製造行程が減り
原価が下げられる予想。
液晶LCDの中には表示メモリを搭載していないものもあるかもしれない。
40年前のポケコン(PC-1251)はCPUと共用だったような気がする。
この割込みを使わないマルチタスクはWindows3.1のようなノンプリエンプティブマルチタスクだが、
自分に都合の良い仮想CPUを作り、命令単位で、タスクスイッチが可能な作り込みをするため、
Windows3.1のように無限ループで止まることはない。
このマルチタスクをWZetaの新技術といっているのは、良好な性能になる性能レンジが狭く、
これを積極的に利用することはなかったため、技術開発されなかったからだと思われる。
端末製品のコストを下げることを考えた結果、周波数を限界まで抑えると、
WZetaの新技術のマルチタスクの領域になる。
8bit CPUで仮想マシンというのも珍しく、これまで例がないと思われる理由。
|
