|
WZeta2はWZetaの機能をすべて継承しているので、時間がある人は、
この日記を遡って読んでもらえれば、そのメリットがわかるように思います。
大きくはトランジスタ数当たりの性能を上げることに特化しているので、
地球環境対策になること、「恐らく」利用しやすいオープンソースなので、
16bit以下のCPUをWZeta2に集約できるメリットです。
ARMやRISC-Vが成功したのと同じ理由。
パリティをコード上に置ける設定が可能なことも、商用価値が高く、
不揮発メモリ屋には、興味深いもののはず。
今回、スポットを当てるのは「HALFモデル」。CPUアーキテクチャは
大きくノイマンアーキテクチャとハーバードアーキテクチャに分けられますが、
WZeta特有のメモリモデル。
WZeta2になってメモリ空間が64KB(16bit)から16MB(24bit)になったので、
JITコンパイラを実装できるかもしれない。
WZeta2のHALFモデルではプログラムメモリ16MB、データメモリ16MBですが、
データメモリ上にもプログラムコードを配置可能。(厳密には、そういった実装が可能)
ソフトウェアのバグでプログラムメモリを破壊することもなく、
データメモリ上にロードしたプログラムの実行が可能。
マイコンなどの用途ではキャッシュやアービターより、ソフトウェアが
自前で管理するほうが良いということもあるように思います。
投稿した文章や、この日記が改竄されるリスクは常にあると思っています。
今回改竄された文章
改竄後
僕が中学生のころに友人の家で遊んだ8bitパソコンのゲーム「ポートピア連続殺人事件」
(1983年)の開発はゲームデザイナーの堀井雄二さん(早稲田大学第一文学部)だったですね。
理系でも文学部のキャンパスの講義っていくつかありましたよ。
改竄前
僕が中学生のころに友人の家で遊んだ8bitパソコンのゲーム「ポートピア連続殺人事件」
(1983年)の開発はゲームデザイナーの堀井雄二さん(早稲田大学第一文学部)だったのですね。
理系でも文学部のキャンパスの講義っていくつかありましたよ。
一文字削られた改竄後の文章は、僕が堀井雄二さんを知っていることになりますが、
改竄前の文章だと僕が堀井雄二さんを初めて知ったという意味です。
数時間前、「ポートピア連続殺人事件」をネットで検索して初めて
堀井雄二さんを知ったというのが正解です。
ネット上の工作員に注意してください。
僕がツイッターなどのSNSでWZeta2のオープンソースの応援をお願いしますと
言ったためだと思います。
「WZeta2の命令セットをもったいぶらずに見せて」
という感じだと思ったので作業中の命令セットを、取り急ぎ公開します。
WZeta2の命令セットはオペコードの値にCPUの制御情報を埋め込むことで
マイクロコードのROMを不要としています。つまり開発中に制御ハードの都合が
発生すると全面的に改訂される場合があります。
ご承知おきください。
以下からダウンロードできます。
開発中のWZeta2 命令セット
スーパースカラを導入したので前作WZetaで売り物にしていたINCX/DECX命令などの
複合命令が無くなっています。複合命令を使わなくてもスーパースカラで２命令の並列実行が可能な場合は、
並列に実行できるので。スーパースカラの実装をいかに軽量化するかなどが面白ところかも。
今回のトラブルで思ったことは殺人事件などのドラマやゲームで楽しく
役に立つ知識が得られること。
8bitパソコンのゲームに、そういったジャンルのゲームがあれば、
売り上げが伸びたりするのだろうか。
もうタイトルしか覚えていませんが中学生のとき「ポートピア連続殺人事件」とか、
友人の家で遊んでいた。
真犯人へとたどり着けるだろうか。
参考情報です。ご存知の方は読み飛ばしてください。
英国の教材micro:bit
は教育向けマイコンボードです。
2017年に登場したときはCPUにARMの32bit Cortex-M0が搭載されていました。
micro:bitに採用されたCortex-M0に乗算器が搭載されていたのか、わかりませんが、
割算器がないため、非常に低速でした。参考までの話、Raspberry Pi PicoはCotex-M0ですが、
外付けの割算器が装備されています。
micro:bitは2020年にバージョンアップされv2になっています。搭載されるCPUは、
ARM Cotex-M4Fなので浮動小数点演算器まで装備しています。
つまり見た目は、非力なマイコンボードの教材に見えますが、高性能です。
一方、WZeta2は8bitの命令セットを16bitに拡張した小さいCPUです。
WZeta2による省資源化の教育は、非常に良さそうなのでWZeta2を搭載した教育向け
マイコンボードは将来できるかもしれませんが、micro:bitとできることが違います。
アセンブラを使った徹底的な省資源化が可能なのが特長。
今後、各国でCPUがセンサーデバイスが多く使われることが予想されますが、
WZeta2の徹底的な省資源が、世界で必要とされるように考えます。
WZeta2の最初のコアはデータバス8bitです。
16bitバスにできるのに8bitバスでは性能が出せずに惜しい。
16bitバスは可能なの？と思った人はあったかも。
データバス8bitの実装に最適化されたコードが、
そのまま16bitでも同様にスーパースカラ実行できる16bitバスの実装は、
作れるような気がしています。詳細まで詰めて考えていないので保証はできませんけど。
僕の人生のアウトプットに見合う、処遇が完備されるなら、
この国の窮地に、はせ参じたいと思います。
SnakeCubeの技術を盗まないように、よろしくお願いいたします。
マルチコアによってマイコンCPUが省資源化される可能性について
考えてみましたというレベルの話です。
メインメモリのスループットが向上してもレイテンシ性能が遅いために
マイコンの性能が上がらないことはあります。
キャッシュメモリをチップ内に搭載することで改善しますがマルチコアでも
改善されないだろうか。
WZeta2 SDogコアは1サイクルでメモリをアクセスしています。
メインメモリを差動回路によって性能を上げてレイテンシ性能１サイクルのまま、
スループットを4倍にした場合、SDogコアのクロックを4倍にしても、
レイテンシ性能が不足するためにSDogコアは正常動作しません。
ところが同クロックで4コアにして、順番にメモリアクセスをすると
キャッシュメモリが無くても正常動作してしまう。
トランジスタ数当たりの性能が高いCPUでは、キャッシュメモリより
マルチコアのほうが、省資源化になってないだろうか？
WZeta2のマルチコア版は、いずれ開発するので、その頃には、
どの程度のメリットが出そうか、多少は、わかってくると思われます。
要するにWZeta2の開発遅延の問題が大きくなるかもしれない、と言っています。
日経新聞の記事(4月24日)
国産量子コンピューター初号機 大規模集積化に照準
量子コンピュータの動向について経済的な観点だけでなく国防的な観点からも
国民は注視したほうが良いと思います。
量子コンピュータが大規模化されれば社会インフラで使われているRSA暗号や
楕円曲線暗号が崩壊する可能性があります。
対策には新しい公開鍵暗号を導入する方法もありますが、量子コンピュータに
強くても、例えばAIに弱いと、鍵長を長くしなければならない。
鍵長を長くできるハードの対応も検討しておかなければ、必要になって急いでも
間に合わないことがあると思います。
RSA暗号の高速化は数十年も前から、いくつも研究論文が出されてきましたが、
巨大な鍵長を計算できる方式では、僕の
SnakeCubeが決定版のように思います。
SnakeCubeは必要性が非常に高かったはずにもかかわらず、これまで取り上げられなかった
問題を考えなければ、これまで通り、取り上げられないでしょう。
そしてSnakeCubeの発明の利権を持っているのは僕１人なので、僕が話せる環境が必要です。
新暗号とSnakeCubeのハイブリッドです。他にSnakeCubeを代替できる発明はありません。
まず僕に付いている産業スパイを僕が壊れないように剥がす必要があります。
僕が壊れなくても僕の周囲を壊す方法では、僕にも被害が及びます。
8bit CPU WZeta2も、非常に面白ものになって社会に必要であるように思います。
WZeta2も同時にやっていきます。よろしくお願いいたします。
参考
日記、3月1日
SnakeCubeをベースにした次世代ICカードは必須です
WZeta2 SDogコアの設計図を書き始めました。
WZeta2の最初のコアの名前はWZetaと同じSDogにします。
演算系のブロックの設計図を書いていますがスーパースカラなので演算ユニットが２個、
これがうまく並列動作することを思い描きながら作業をしています。
パイプラインアーキテクチャと比較してWZeta2の4サイクルアーキテクチャは、
劣勢ではないかという見方が広がってしまうといけないので、
今、思いついたことを書いてみます。
パイプラインアーキテクチャをベースとした命令セットは1命令に
1回のメモリアクセスが基本です。あるメモリにAを加算するために、
ロード命令、演算命令、ストア命令の3命令が必要です。
一方、WZeta2は1命令でロード、演算、ストアできる命令があります。
しかもオペランドを投機実行しているので高速に処理されます。
そして1命令でロード、演算、ストアする命令の利用頻度が高いため
WZeta2の性能が良い。
具体的なニモニックをいくつか書いてみると
ADD [mem],A
SUB [mem],A
AND [mem],A
OR [mem],A
XOR [mem],A
INC [mem]
DEC [mem]
Z80にもありそうな命令に見えますがZ80には無いようです。
新しく命令セットを作らなければできないことをWZeta2で
やっておくことは重要だと考えています。
つまりスーパースカラの制御回路を軽量化するための仕組みを命令セットに入れる
試行錯誤をしています。
これまでに無いスーパースカラの実装になるのだろうと思います。
8bit CPUのパイプラインの無いスーパースカラだということです。
スーパースカラといえばIPCが1を越えるものを想像されるかもしれませんが、
WZeta2は1命令4サイクルなのでIPCは0.25です。
スーパースカラで２並列動作させても理論最大で0.5。
ただWZeta2はRISCの命令セットの3倍の処理量を持つものもあるので理論最大1.5。
実際はRISCのIPC換算で0.5～0.8くらい？根拠のない予測値ですけど。
スーパースカラ無しのパイプラインアーキテクチャだと遅延分岐で
IPCは1を下回るから0.8～0.9程度だろうか。
スーパースカラといっておきながらスーパースカラ無しのパイプラインアーキテクチャと
同程度で、どうしてパイプラインアーキテクチャにしないのか？
割込み実装が明解になるためバグが入りにくいこと、
遅延分岐が不要であること、ゼロ遅延マルチコアを作るのが容易であること。
余談、IPC(CPI)は、日立用語ではMICEと呼んでいたみたい。
大型コンピュータ系の人たちはMICEを使っていたけど、
SHマイコンの人たちがMICEを使っていたのかは不明。
僕が日立に入ってすぐに自社の大型コンピュータのCPU開発から
IBMのCPUを買う部署に転勤したから、僕も日立のCPUに詳しいということは無いのですけど。
実装を、あれこれやっている最中。WZeta2は内部16bitの8bit CPUです。
データバスは8bitなので16bit命令を実行しながら、次の命令を実行するスーパースカラな
実装にすれば高速になる。データバスが16bitなら同時実行は必要なかった。
スーパースカラのCPUで世界を釣るのだ～～。(本当にスーパースカラになるのか、わかりませんけど)
僕の発明した暗号プロセッサSnakeCube
は非常に高性能です。ところが競合他社の暗号プロセッサの性能を騙して
実際の60倍の性能に見せる話術を見かけたので、みなさん、騙されないように。
これに限らず、いろいろ騙す方法を考えている人が、僕の周りにいます。
騙す人が、自分が騙したという問題がほぼ無い方法を思いつく天才的なペテン師に注意してください。
マイナンバーカードは公開鍵暗号RSAで電子署名できるICチップが搭載されています。
RSAによる暗号化は次のような演算で計算できます。
y = m^e mod n
そして変数eの部分に秘密鍵の値を入れて演算をすると電子署名の値になるのです。
確かに電子署名の値は公開指数によって復号化できるので、暗号化であるかのように見えるのです。
このことからペテン師は電子署名は秘密鍵による暗号化だと思わせるように話します。
ネットで検索できるRSA暗号演算ハードの性能表には暗号化と復号化の性能値が表示されているので、
ペテン師に話を聞いた人は、電子署名の性能として暗号化の数字だと勘違いしてしまうのです。
暗号化と復号化では60倍、暗号化のほうが高速なので、実際の60倍の性能だと勘違いさせられます。
一方、ペテン師は間違ったことを言ったのかと言えば正しいことしか言っていない。
暗号化も復号化も同じ演算でできるからです。
ただしRSA 2048bit(CRT)では暗号化は17bit、復号化は1024bitの値を使うので
1024 ÷ 17 ≒ 60倍
演算処理が異なります。
実は騙されたという言い訳を使う人が真のペテン師なのかも。
まだ命令セットを、ざっくり作ってみた段階なのですが、アドレスバスは
24bitにしようと思っています。従来のアドレスバス16bitではアプリが
限られましたが、24bitあれば組込み向けでは、かなり対応できるアプリが
増えるような気がしています。ただしデータバスは8bitで命令セットも
8bit CPUを延長したものなので16bit CPU並みに高速になることはありません。
しかしながら8bitバスを効率的に活かすことが可能なのでトランジスタ数当たりの
性能は高いと思われます。(省資源なわりに高性能かな)
普通のパイプラインアーキテクチャのCPUはメモリアクセスが競合すると、
競合した命令のいづれかをストールさせて競合を回避するのですが、
WZeta2のSDogコアにはストールさせる回路がありません。
ストールするようなプログラムにしないことで回路を省いています。
誤ってメモリアクセスが競合するコードをプログラマが書いても、
アセンブラが100％、エラーとして検出するのでプログラマの負担は
それほど増えません。
これで、少ないトランジスタでパイプラインアーキテクチャの性能に近づきます。
まだ実装していないので、途中で方針変更を余儀なくされる可能性はありますけど。
また24bitアドレスだと16bit CPUのNEC PC9801VM21クラスのパソコンは
作れそうな気がします。当時のPC98アプリはVM21以降対応という記述ものが多く、
VM21はPC98の黄金時代を築いたマシンと言えると思います。
ただVM21にはGRCGが搭載され専用のグラフィックチップを利用できたので、
CPUの性能だけがVM21のCPU、V30に到達できてもVM21クラスのマシンにはならないのですけど。
WZeta2をデュアルコアにして１個をグラフィックチップとして使えないかとか、
考えています。
1990年頃、近所の本屋でもPC98のGRCGの解説本が売られていたほど。
参考までGRCGというのは最近、復刻されている8bitパソコンのMSXでいうと
VDPに相当するもの。
この日記は、些細なことなので、普通の人は読む必要はありません。
4月13日の日記「SSLサーバ証明書、有効期間90日化のニュース」
で利用の手間が増える話をしましたが、ちょうど本日行った
WZetaのサイトのSSLサーバー
証明書の更新が、それにあたります。今回の証明書はDV証明書なので非常に簡便な手続きで
済みますが、法人向けのOV証明書で自分で秘密鍵をきちんと生成するとなると、
SSLサーバー証明書を販売する担当者と数日をかけてすることになる。
僕は2002年ごろに政府の電子申請に利用できる電子証明書の販売員
をしていたので、僕は電子証明書の知識があって、自分で更新できますが、
一般の人だと、慣れるまで苦労するのかも。
(余談ですが、このときに僕が所属していた組織の人がデジタル庁に多数、いそうな感じ。)
セキュリティを確保しながら自分で秘密鍵を作るのは、かなり手間ではないだろうか。
今回のDV証明書の更新は、産業スパイに妨害されなければ30分くらいでできたはずですが、
妨害されまくったので半日かかっています。作業中にベッドに倒れて寝たというのが
大きいですけど。
まだ作業中で、どうなるかわからない状況なのですが、少なくとも
パイプラインアーキテクチャにはならない。
まだWZeta2に乗り換えることが、できるのか、判定できるレベルに
達していないのですが、今のところは順調です。
産業スパイのサイバー攻撃は緩やかながら続いていて苦しい状況に
変化はありません。頭と体の劣化が止まっていません。
執念で開発をしていますが、執念では優れたCPUはできません。
開発中のオープンソースの8bit CPU WZetaを世界に普及できるように、
バージョンアップを進めています。
よろしくお願いいたします。
ここ数日、WZetaのCPUコアを修正していたのですが、まだ高速化の
余地がありそうだということが見えてきました。
8bit CPUの限界まで設計してみたいという想いが先行していますが、
もう一度、命令セットを再設計してみるかも。
2年前、elchika ハードウェア作品投稿
に応募して秋葉原のお店からアイテムを貰えることになったことがキッカケでWZetaの開発に力を入れ始めました。
１カ月後には、WZetaは同じ特長を持った全く別のCPUになりましたが、今回は、そういったことはなく、
内部を16bit化するため命令セットの再設計をします。再設計といっても７、８割同じ感じだと思います。
途中で挫折したらWZeta2へのバージョンアップを諦めます。
命令処理がパイプラインアーキテクチャのように重なりますが資源コンフリクトを
動的に解決するのではなくコンパイラ、アセンブラのところで解決します。
ゼロ遅延マルチコアになるのかが、気がかりの人もあるかもしれませんが、
どうにかするしかない状況だと思っています。
再設計で半年くらい遅れるかも。僕の頭と体が元気なら２カ月は、かからなかったと思うのですけど。
8bitバスにこだわった省資源CPUなので安価なマイコンでの活躍が期待されるところ。
Xilinx FPGAのURAM 1個で動作するのでFPGA利用も便利だと思いますが。
SSLサーバ証明書の有効期間が、また短縮されるということのようです。
SSLサーバ証明書を利用する手間が増える問題が発生。
手間代が増加するならSSLサーバ証明書の鍵を長くしたほうが割安だったということのように思えます。
世界が僕の暗号プロセッサSnakeCube
の導入を決めていれば有効期間短縮を数年、遅らせることができたのではと思います。
サーバのハードが信用できなくなってきたという理由もありそうですが。
日本のマイナンバーカードは、大丈夫なのでしょうか。河野大臣から連絡はありませんけど。
GMOグローバルサインカレッジ
GoogleのSSLサーバ証明書、有効期間90日化について
さくらインターネット
SSL証明書の有効期間が90日に短縮された場合の影響とは？
僕の暗号プロセッサは非常に長い鍵長の公開鍵暗号を演算する方式が優れています。
Xilinxの小型のFPGAに実装できていますから、例えばXilinxのFPGAを中間アーキテクチャとして、
量子コンピュータの解読に強い公開鍵暗号を実装すれば、両方が高速に動作する暗号プロセッサとなると思います。
この案は現時点でも有望であり、全世界の人に考えていただいたほうがいいように思います。
売れるかどうかわからないものを開発するのは非常に辛いので。
非推奨という状態で旧ニモニックも、当面使えるようにしますが、あまり期待しないでください。
ニモニックを整理する理由は、機能と名称を一致させ、覚えやすくするため
整理対象はSTAB、STABP、STZCP、STACPなどの命令。ファミコンのCPUとして有名な6502のアセンブラでは
STA、STX、STYというのはレジスタA,X,Yをメモリにストアする命令なのですが
WZetaではメモリ-メモリ間の転送です。紛らわしいという問題がありました。
レジスタに値を代入する命令はLD
レジスタの値をメモリに転送する命令はST
メモリ-メモリ間の転送はMOV
新規命令で16bit転送をMOVとしていましたがLD.W、ST.Wというニモニックに変更します。
ニモニックの変更は無いので、これまで作成したアセンブラコードを
修正する必要は恐らく無いと思われます。
8bit CPU WZeta
で16bitデータの操作性を向上するためMOV AC命令を命令セットに押し込みます。
8bitレジスタA,Cを16bitレジスタとして1命令でデータ転送を行う命令です。
このためオペコードを数か所、変更します。以下は凡その内容。
STAB命令とSTABP命令(0x2F)の統合
オペコード0x01の命令群をオペコード0x2Fへ
オペコード0x01にMOV AC0x2FにMOV [],AB/MOV [],ACを追加
SWAP AC命令も可能なようにするかもしれません
現状の目標周波数は133MHzでしたが、昨日の修正で限界になってきたので
125MHzに変更することになると思われます。
一昨日の日記で報告したレジスタ直交性のverilog修正が、
取り敢えずできたので、論理合成をしてみた。まだ十分な検証をしていないので速報値
WZetaのVivado2022.2による合成結果
133MHz、568 LUT、159 FF (BRAM 8KB)
直交性を改善しても4LUTしか増加してない。
改善前
LD A,B
LD B,A
SWAP ; AとBの交換
LD B,C
改善後
LD A,B
LD B,A
SWAP A,B
LD C,A
LD A,B C,A
LD B,A C,A
LD A,B B,A C,A
LD A,C
LD B,C
LD A,C B,C
SWAP B,C
LD A,C B,C C,B
4LUTの増加で、かなり改善されたと思います。
ハードウェアを知り尽くしていれば、効率的な命令セットができるのかも。
あまり役立ちそうではない命令も含まれていますが。
WZetaの汎用レジスタは一昨年の公開時点では8bitレジスタA,Bの2個でした。
その後、Cレジスタが追加されたためレジスタ間のLD命令が不十分でした。
そこで直交性のあるレジスタ間LD命令に修正します。
このためオペコードが変更されます。アセンブラのニモニックは同じなので
WZetaシミュレータを開発しているということがなければ影響は無いと思われます。
またレジスタA,Bを入れ替えるSWAP命令のニモニックは非推奨になります。
そしてSWAP A,BとSWAP B,Cが追加されます。
レジスタ間のLD命令を同時に複数実行するニモニックを追加予定。
LD A,B B,C C,A ; まだ未定
直交性によってわかりやすくなって、複数のLD命令を最大3個、同時実行できるようになります。
ただし同時に実行できるLD命令の組合せには制限があります。(SWAP A,Cは不可)
新規命令追加によってコード密度が向上しても周波数やトランジスタ数が大幅に増加すると
デメリットのほうが大きいということになるので最新の論理合成結果に関心がある人はあると思います。
多少、急いで結果を出していますが、現時点では
WZetaのVivado2022.2による合成結果
133MHz、552 564 LUT、159 FF (BRAM 8KB)
あまりLUT数が増加していないのにも、かかわらず、新規命令が追加できているのは、
効率の良い命令を選択しているからです。
トランジスタ数当たりの性能が非常に高いことはWZetaの大きなメリットであり期待できる点であります。
WZetaのコード密度と性能向上のため新規命令を2つ追加検討します。
仮想マシンCOMBATの高速化のためだということが見え見えだけど汎用命令と言い切れるだろう。
NIBBLE ; A←C下位4bit , B←C上位4bit
WSHL ; AB ← AB(1bit左シフト)
ネットで検索するとCOMET-II互換CPUをFPGAで実装しているところもいくつかあるようです。
今のところCOMBATはCOMET-II互換ではありませんが極力、COMET-IIに似たものにできればと思っています。
COMET-IIはプログラムもデータも同一の128KBみたいですが、
COMBATはハーバードアーキテクチャ、プログラム64KB、データ64KBを考えています。
(プログラム128KB、データ64KBも、どうにかなりそうですけど)
ノイマン型も可能なのですがハーバードのほうが安全性が高いので。
そういえばARMは安全性を高めるために
CHERIという機能があるようです。中身は知りませんけど。
COMBATもメモリアクセスの保護のため256バイト単位でアクセス権を設定する機能をソフトウェアで実装することは可能です。
(当たり前ですが)
仮想マシンであることを活かして、案外、高信頼なものを作れるかも。
ICF3-Zの仮想マシン支援機構のことを話したあたりから、
このあたりを話題にしているところも、あったようです。
でも、COMBAT(≒COMET-II)は命令数が少ないので、新人が最初にやってみる新しいBASIC言語みたいな感じかも。
COMET-IIの汎用レジスタはGR0～GR7の8本みたいですがCOMBATも
仕様上は8本にするつもりですが、8本にするとメモリ4KB(プログラム2KB、データ2KB)
に入らないことが判明。
とりあえずレジスタだけ4本の実装にするか、現在の開発環境を8KBにする作業をするか。
AMD/XilinxのFPGAのBRAM(4KB)、2個を連結して8KBにできそうなら、開発環境を8KBにするか、、、
過去にAMD/XilinxのFPGA向けに開発された8bit CPU PicoBlazeがあります。
互換CPUとしてPacoBlazeもあるようです。
COMBATが情報処理試験COMET-IIの互換CPUなのか？という疑問が、
あったか、なかったか。
仮想マシンCOMBATはCOMET-IIに似ているだけで互換CPUとかレプリカではありません。
COMET-IIのオペコードは仕様では定義していないと、ネット上の資料にはあったのですが、
COMBATはメジャーなCOMET-II実装のバイナリ互換を目指したものではありません。
WZetaのハードマクロ命令で高速に仮想マシンCOMBATをエミュレーションできることが優先です。
COMET-IIは国家資格試験のために命令セットアーキテクチャが策定されているので、
バイトではなくてワードマシンであることを除けば、シンプルで単純なアーキテクチャ。
要するに、COMET-IIは、ありふれた命令セットアーキテクチャなのです。
COMBATは、COMET-IIと類似はしているけど、全く別のオリジナルの仮想マシンと言えます。
ただアーキテクチャは酷似している、、、
今年度4月の試験からCOMET-IIを含めたプログラム言語が無くなるため、
今後、COMET-IIに税金が投下されない予想をしています。
そこで税金を使わない方針のWZetaが仮想マシンCOMBATを始めたという、わけなのです。
これにはCOMET-IIを学習した人が救済されるような考えも、あったりします。
最後まで開発するのか、不明ですけど。
8bit CPU WZetaに即値加算などの新規命令のverilog実装が順調に進んでいます。
論理合成結果も、追加前と同程度の周波数とトランジスタ数(LUT、FF)でした。
動作検証のために何かアプリを作成しようと考えた結果、情報処理試験でお馴染みの
仮想マシンCOMET-IIによく似た仮想マシンを作ってみるのも、面白いかなと。
昔も同様の計画を立てましたが、少し実装してみて、終わりにしました。
前回はRedCometという名前にしましたが、紛らわしいと言われると困るので、
COMBATにしました。RedComnet「赤い彗星」、バズリそうな名前だったんですけど^^;
COMBATの由来は、昔ASCIIにSunのSPARCとゴキブリホイホイのコンバットがよく似ていることから、
紙面に写真付きで比較されたことがあるところからです(爆笑)
今回も途中で終わってしまいそうですがハードマクロ命令を128個に拡張したおかげで
劇的に高速な仮想マシンが作れそうです。そしてCOMET-IIに似ているから、使い易い。
入出力命令なのでシミュレータを開発して外部入力までシミュレーション
をするようなことをしていなければ影響ありません。
オペコード 0x1D → 0x0F
一般的にはメモリの高信頼化は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を定義してしまう方法でも構わないのですが。
まだ命令セットの仕様を更新していません。数日中に更新する予定です。
産業スパイが僕を壊す前に、どうにかならないのかと思った。(2回目)
再び視界が歪む。目を開けているのが多少、辛い。
乗算命令を追加した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で公開するのかは未定。
産業スパイの電磁パルス攻撃でパソコンを誤動作させられて困っています。
AMD/Xilinxの論理合成ツール Vivadoの古いバージョンは新しいOSに対応していないため仮想マシンに
古いOSをインストールして、その上に古いVivado(2021.x)をインストールしています。
仮想マシンに「適切な」電磁パルス攻撃をするのは、恐らく少し難しい。
産業スパイは仮想マシンイメージにウィルスを混入しているのかもしれない。
Vivadoのtclコマンドでimport_filesがverilog属性のファイルだと永遠にレスポンスが返ってこない。
xdcやmem属性のファイルは読み込めた。
TCL言語を少し調べたほうがいいのかもしれないけど。時間が無い。
OSイメージをコピーしています。USB 2.0だから本来30MB/sくらいの転送スピードに
なるはずがサイバー攻撃で30kB/sになってコピーに300時間。
WZetaは僕1人でやっています。
乗算命令を除く全機能を入れたWZetaのverilogが完成してから、
すでに1年半以上が経過していることを考えてください。
このまま産業スパイに妨害され続けると、本当に遅れます。
2021年7月25日の日記で一度、比較をしています。
大雑把な比較なので大きな誤差があると思いますが
WZetaは8051互換の半分のトランジスタ数で２倍の性能が出る予想になっています。
ただし、このときのWZetaには乗算器が無かったので乗算命令を使うプログラムでは
２倍の性能は出ませんでした。
今回、WZetaに軽量で性能の良い乗算器を追加する予定なので、もう一度、比較ができると思います。
現在の僕の予想では乗算命令を含めても、
8051互換より少ないトランジスタ数で２倍の性能。公開鍵暗号では、もっと差が開くのではと思っています。
現在でもIntel 8051互換のIPは市場に出回っている感じなので、
この予想通りならWZetaがオープンソースとなった場合の経済効果が期待できます。
WZeta開発が妨害されないように、よろしくお願いいたします。
自宅の部屋にあった紙が無くなっている。
無くなった紙はRed Hat LinuxのOSイメージのハッシュ値が印刷されたもの。
OSのバージョンは8.6と9.1です。ハッシュ値が紙に印刷されてあれば、
HDD上のOSイメージが改竄されていても、改竄されたことがわかる。
産業スパイの電磁パルス攻撃対策として紙に印刷することをしていた。
盗まれたことに気づいたのは、ただの紙ですが、
お財布の中のお札を抜かれいないとも限らない。
それ以上のことも、いろいろできるので。
他府県の県警の方にも、注意をしてもらえると、助かります。
盗んだ紙はOSイメージのハッシュ値だけではない、他のデータのハッシュ値が
印刷されたものも盗んでいる。
つまり僕に気づかれることが前提となっている盗みだ。
産業スパイは自首する気にでもなったのだろうか。
動作検証用のPCの環境の構築が終わらない。
動作検証用ということもあって全ての部品が古い。
またサイバー攻撃をしても致命的な問題にならない。
このため産業スパイがサイバー攻撃をしまくっている。
今回、サイバー攻撃されたのは2010年に製造されたHITACHIのHDD 160GB。
やむを得ず別のHDDに交換しました。
時間が、どんどん、失われていく、、、
昨日の日記に多倍長累積和のコードをWZetaとAVRで書きました。
WZetaはZ80のようにマイクロコードを持たないので複雑な命令を作れないのですが、
AVR、11命令に対してWZetaは3命令であることからも乗算命令の仕様が、うまくできたことがわかると思います。
8bit CPU WZetaに追加を予定している乗算命令ですが、非常に効率の良い実装になりそうです。
WZetaは従来CPUより優れたCPUですが、
WZetaをあまりご存知無い方は、この日記に書いてきたので、読んでみてください。
現在、産業スパイの妨害が多発してオープンソースのWZeta開発が全く進まない状況となりました。
乗算命令の追加が成功すればトランジスタ数当たりの性能が非常に高いCPUになります。
省資源CPUとして地球環境対策にもなるように思います。
開発が産業スパイによる妨害で止まっているせいで、確認ができないのですが流通している
8bitマイコンのCPUより良いものがオープンソースのCPUとしてリリースされる効果は大きいと思われます。
僕から産業スパイを剥がして、産業スパイが踏みにじってきた僕の過去を
僕が回収出来れば、お金による寄付は必要ありません。
もう少し言うと、剥がさないと産業スパイが200％以上、ピンハネするので、少しくらい
お金を貰ってもダメなのです。
要は、悪いことをした人に謝って貰うのが一番だと。
しかし実際には、それは非常に難しいことなので、みなさんよろしくお願いいたします。
産業スパイを剥がすことができれば僕が、このCPUのオープンソースから、あまり回収する
必要が無いのです。
つまり、あまり回収する必要がないのでWZetaが世界で普及して8bit CPUはWZetaに統一され、
CPU周辺開発のコストが下がることが期待され、本当に世界で普及する。
そうすれば、何か、回収できるチャンスができるだろうという見通しです。
オープンソースのCPUをメンテナンスするに当たって、やはり費用は必要です。
8bitパソコンを作って売ることを考えています。よろしくお願いいたします。
何を無謀なことを言っているのかと思う人もあると思いますが、
僕はオープンソースのWZetaに、それなりに力があると思っています。
WZetaの開発を止めることは、多くの人にとって損失となるので僕が開発できるように
よろしくお願いいたします。
(暗号プロセッサSnakeCubeも受け付けています)
産業スパイの電磁パルス攻撃で光学メディアBR-R×1枚、BD-R DL×2枚が破壊されました。
Vivado2021がインストールされたCentOS7のイメージは50GB近いのですが、コピー中に何度も妨害され、
コピーできずに、作業が進まない。
ネット上に落ちていた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が良さそうな気がしてきました。
連日、産業スパイに目を攻撃されている。かなり目が劣化してきた。
MMD動画配信サイトにアクセスするようになって8年くらいになっている。
ほぼ毎日のようにサムネイル画像で動画を選定するのだけど何が映っているのか
判別できないサムネイル画像が急増している。
動画サイトの問題ではなくて目が悪くなっているのだ。
ツイッターでMSXの横スクロールのゲームの動画が目に入った。
大きなキャラクタの敵機が右から２機、自分に迫ってくるのだが、
なんと見えない。視野からはずれているわけではない。
何かあることはわかっても、何が映っているのか、全くわからない。
動ているキャラクタの認識は、かなり落ちている。
いままで、それに気づかなかったは、動画のサムネイル画像などの静止画が多かったからだ。
ゲーム動画のお陰で動体認識能力がかなり低下していることに気づけた。
第２次世界大戦のイギリスの英雄、チューリングは数年前、新50ポンド紙幣
になったけど、僕が生きているうちに処遇を改善してもらえないのだろうか。
XilinxがAMDに買収される前の論理合成ツールVivado2021.1をQEMUゲストOS CentOS7.8上で動作させている。
ホストOSはRed Hat Linux9.1です。何故か、Vivadoがセグメンテーションフォールトで落ちます。
産業スパイの言い訳はRed Hat Linux9.1、QEMU7.1.0での動作実績が無いことだと思うけど、
産業スパイの論理は動作実績の無いものは、全て落ちるというものなので、信用していない。
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カード実装があれば、いけるかな。
|
