|
(1)(2)(3)は、日記(1)、
日記(2)、
日記(3)をクリックすれば読めます。
日記(3)のところで署名端末では乾電池が不要になる話をしました。
乾電池が不要でも時計の時刻を維持するために水銀電池が必要なのではないかという意見。
例の無線通信経由の意見なので、いいと思っていませんが。
脆弱性が無いことを保証するのは難しいのかもしれませんが、時計も水銀電池も不要なのではないかと、
思っています。銀行側のサーバで乱数を生成して、署名端末に送信。
送られてきた乱数を使って返信データを作成すれば、いいように思いました。
参考までにジャパンネット銀行で、もらったトークンは、10年で新しいカード型のトークンに
交換してもらってます。つまり、10年間、正確な時間を維持できる程度には、
時計の品質も、水銀電池の品質も、良くないといけないので、削減できれば、端末のハードは安くできるのかも。
地球環境にも良さそう。
ただUSB接続のチップは信用がなくてもいいので激安なものが使えると(1)で書いたのですが、
10年間動作する程度には、品質の高いものを入手する必要があるように思いました。
(改竄、盗聴は問題がなくても、気分で故障されると問題という話です)
作業報告です。それ以上ではありません。
ほぼ1日中、眠っていました。
Verilog版のSnakeCubeシミュレータで大量シミュレーションをしているところですが、
SnakeCubeの開発環境は、サイバー攻撃に備えWindows環境や、その他のOSでも
動作するように考えています。Windowsには標準ではPerlが入っていないため
PerlがなくてもシミュレーションできるようにC言語のプログラムで代替しているのですが、
C言語の標準ライブラリではシミュレーションのプロセスの標準入力か、
標準出力のどちらか一方しか操作できず、Perlの便利さを痛感しました。
このためverilogで連続シミュレーションのための仕組みを入れ込むことになったのですが、
verilogの標準関数の$fopenでは、ファイルが存在しているとき、書き込みオープンをすると
エラーになってくれなくて困ったのと、$randomが毎回同じ乱数しか生成してくれなくて困りました。
乱数はC言語で生成してコマンドラインでverilogに渡すということで乗り切りました。
新しい技術を使って実用性のあるものを作れないか考えている人向け。
8bit CPU ICF3-Zは利用者が自由に
定義できる命令を最大127個作れる。作れる命令は16bit長の命令コードで、
最上位ビットは常に1、オペコード7bit、オペランド8bitです。
サブルーチンコール命令や、ジャンプ命令も、
実装できるため自分のオリジナルCPU(仮想マシン)を作れます。
そしてICF3-Zで作られた仮想マシンは、ハードウェア支援によって高速に動作します。
ICF3-Zの仮想マシン機能(利用者定義16bit命令)をサブルーチンコール命令の
一種として実装することで、実に良くできた実装になっています。
つまりサブルーチンコール命令を作るには、ジャンプ命令を実行すればいいのです。
ジャンプ命令を作るには、サブルーチンのスタックを１つ減らす命令を実行して、
ジャンプ命令を実行すればいいのです。
自分の仮想マシンをarduinoなどのコンピュータに移植すれば、
仮想マシン上で動作するプログラムは、いろいろなコンピュータで動作します。
自分のオリジナルCPU(仮想マシン)を作るのは面白く、価値があることになると思われます。
先日の日記で書いたTTL版のICF3-Zに
仮想マシンを移植することは容易なのでTTLで作ったCPUの世界とつながっていくと思われます。
ICF3-ZはTTLで実装できるCPUとしては高速なので、TTLならではの用途が見つかれば、
TTLのCPUが、売れるようになるのかも。
既存のJAVAとの違いは、何かというと、TTLでも実装できそうなくらい、
非常に小さいCPUで仮想マシンが高速に動作する「ICF3-Zの仮想マシン機能」です。
新しく仮想マシンを作るので、JAVAのAPIの紛争問題も起きません。
命令コードの最上ビットが常に１になっていますが、将来、
ICF3-Z以外の仮想マシンの拡張用として考えることもできます。
パリティつきのメモリは高価なのでパリティビットとして使えば、
安価なメモリで高信頼なものが作れます。
追記
TTLが強調されていますが、TTLがなくても、多くのコンピュータで
動作するということだけでも、オリジナルCPUを作る価値はあるように思っています。
その価値を大きくできるかは、自分で考える必要がありますけど。
ICF3-ZをTTLで作ることを散々考えている理由は、SRAMがとても安価なので
大容量のSRAMを搭載したマイコンを作りやすいから。
AMD 6コア12スレッドのCPUでverilogによるSnakeCube(48bit)シミュレーションを
大量に実行中です。RSA暗号を演算するための、改良型のアルゴリズムを使ったマイクロコードで
シミュレーションをすると数分でエラーになったので、何が原因か、
調べたのですが改良型では演算できる鍵長が2bit小さくなることを忘れていただけでした。
エラーでシミュレーションが止まってくれたおかげで、SnakeCubeのverilogが間違った
答えを出力すれば、エラーで止まると確認できました。
左目の眼球を筋肉が外側に引っ張るので、左目をつぶって作業をしたり、日記を書いたりしています。
SnakeCubeは、
すばらしい発明だと思っていますが、まだ僕は、筋肉制御されていなければ、
ならないのでしょうか？このために作業速度は半分も出ていないと思います。
産総研の人のツイッターを見ていると
「ハードウェアに入っている楕円暗号の秘密鍵をリモートからのアクセスで盗める」
という話が書かれたサイトのリツイートが、あったので、さっそく概要を読んでみました。
楕円暗号のハードウェアの実装によっては、リモートからアクセスで秘密鍵が盗める。
しかもタイミングだけで盗めるということのようです。
僕の考えは、組込みソフトウェアによってタイミングを調整し、例えばどんな値でも
同じ時間で計算するようにするなどの対策をすれば、いいのかもと。
サイトには、それが難しいと書いてありますが。
ちなみに産総研の人のツイッターをフォローしているだけで税金を使っているのと同じという人が
出てきそうなので説明すると、8bit CPU ICF3-Zは税金を使わないことを宣言していますが、
SnakeCubeでは、宣言していません。ただSnakeCubeも税金を使うことで評判が落ちるので、
税金を使いたいとは考えていませんが、SnakeCubeは次世代ICカードなど、
社会インフラでの活躍が期待されるため、必要なら、やむを得ないと考えています。
クレジットカードで買い物をしたと思われる支払い(2000円弱)が、
思い出せなくて苦労しました。普通では数週間前に買った物とか、
日常の小さい出来事を、いちいち記憶しようとしなくても、覚えていることは多いでしょう。
たとえすぐに思い出せなくても、思い出そうとすれば、
思い出せることもあると思います。記憶は消され続けているような感じ。
このことは今に始まったことではありませんけど。
作業報告です。それ以上ではありません。
Verilog版のSnakeCubeシミュレータに標準入力を使ってRSA暗号の演算データを入れて、
Verilogのシミュレータを実行、演算終了後、期待値と比較。
結果が違っていれば、シミュレータを異常終了させる。
これを適切な乱数データで大量シミュレーションできる仕組みでテストできるようになりました。
正しくは、動き始めた。
シミュレータを異常終了させる方法はicarusのvvpで-Nオプションを付けると
$stopで異常終了するようです。
TTLに実装するために機能を削減したICF3-Zを作り、
仮想マシンで互換性を維持するというアイディア。
ICF3-ZはTTLで実装することを考えて設計しているわけではないのですが、
トランジスタ数を減らすことに特化していたりSRAMチップが安価だったりするので
TTLに実装するのにも向いていると思っています。
そしてTTLのCPUとしてはかなり高速になるかなと。
ただ、やっぱりTTLでは規模が大きいかなという気はしています。
少しでも作りやすくするには8bitの汎用レジスタ16本を無くして、
スクラッチパッド256バイトだけにするという方法もあるかなと。
安価な量産品のSRAMに効率的に実装できるようになります。
汎用レジスタを使ったプログラムは動かなくなりますが、ICF3-Zでは、
普通のCPUとは違った命令セットなので、スクラッチパッドだけでも、
問題がなく、多少、性能が落ちるくらいです。
また通常のICF3-Zと、TTL版ICF3-Zの仮想マシンを作れば、
その仮想マシンのコードの互換性は保つことができる。
つまり、スクリプト系の言語を仮想マシンで実装したものはTTL版ICF3-Zでも、
多少、性能が落ちる程度で動くかもしれないということです。
うまく仮想マシンを使った言語がICF3-Zに乗ってくれば、
TTL版のICF3-Zでも、動くアプリが多くなるみたいな。
あまり効果がないかもしれないですがAND演算とNOT演算があれば、
プログラムでOR演算やXOR演算が可能なので、仮想マシンにOR命令、XOR命令が作れたりします。
オープンソースのソフトウェアと同じでCPUもTTLで作りたいという人はあるかもしれない。
ICF3-Zは、プログラムメモリを多く消費するアーキテクチャで、
圧縮命令によってプログラムを圧縮しないと、メモリ効率の悪いアーキテクチャですが、
その分、CPUコアが小さくなっているのでTTLでも作れる規模かもしれない。
僕はTTLでCPUを作った経験がないので、適当なことを言って恐縮ですが。
ICF3-Zは8bitの演算レジスタA,B,C,Dを持っているので
8bitの汎用レジスタ16本は、リードもライトも転送だけで1サイクルのアーキテクチャなのです。
つまり汎用レジスタをSRAMに置けそう。ディユアルポートのSRAMもあるみたいですが高価なので、
1ポートのSRAMで、前半ライト、後半リードみたいに時分割すれば、なんとか、なる。多分。
言いたいことはICF3-Zは、既存の8bit CPUより優れている。
maxim integratedが自社のCPUと8bit CPUで有名なAVRとメモリコピーの性能を
比較している資料を見つけました。
MAXQ命令セットアーキテクチャとRISCのベンチマーク比較
maxim integratedは高性能の結果ですがパイプラインがないCPUなので、
あまり高周波数では動作しない予想なので、ベンチマークで示される
性能ほどではないのかも。
上記資料では64バイトのメモリコピーの性能ですがICF3-Zの都合で
16バイトのメモリコピーで比較します。
AVRは5命令、115サイクル。
ICF3-Zは10命令、133サイクル(8命令、85サイクル)
カッコ内の性能は16ビットポインタの上位8bitが16バイトの先頭と最後で同じ条件の場合
AVRのアーキテクチャとICF3-Zのアーキテクチャの違いから、
ICF3-Zが2倍の周波数になるという予想のもと補正をすると、
ICF3-Zが高性能かもしれない。
プログラムコードのメモリが多く必要になりますが、そこは圧縮命令で、
プログラムコードを小さくなるように、すればいいのかと。
ICF3-Zの説明書と少し命令数、サイクル数が違うように見えますが
AVRと比較できるように補正しています。
カメラ端末に比べて署名端末はUSBケーブルを使うので、少し利便性が落ちる。
しかしカメラ端末は乾電池を使っているが、署名端末はUSBケーブルから電源を取れるので電池不要。
端末の製造原価や地球環境的にもUSBケーブルから電源を取れるほうがいいと思います。
乾電池ではなく充電式電池であっても、同じことが言えるでしょう。
作業報告です。それ以上ではありません。
僕の稼働率を１日、２時間くらいまで抑えることを目標としているらしい。
おかげで寝ている時間が長くなっています。
verilogシミュレーションの入力データにファイルではなく、標準入力を使うように改造しています。
icarusでは動作するようになったのですがXilinxのxsimでは、まだうまくいっていなくて、
少し時間が、かかっています。標準入力をあきらめるか、どうするか。
考えてみた(2)の結論は署名端末、良さそうです。
カメラ付き端末ではブラウザでQRコードを受信、
端末が表示する数桁の数字をブラウザで送信する方法でした。
署名端末ではBASE64で送受信をすればいいと思います。
これには専用のBASE64アプリが必要になります。
銀行への送受信はブラウザでするため、このアプリはネットワークにアクセスすることもなく、
署名端末と送受信するだけです。ソースコードを公開しても問題がないものなので、
アプリのインストールが心配な顧客がいても対応できると思います。
BASE64のデータは、送受信データに署名を付けることで改ざんされることはありません。
そして読み取られても、それほど影響はないようには思いますが、共通鍵で
暗号化しておけば、安心です。
共通鍵暗号で最も利用されているのはAES暗号ですが、AES暗号は8bit CPUでも
高速に演算できます。
無責任ながらパソコンで銀行振込をするための「署名端末」を考えてみた。
「署名端末」は、現実的なところにあるように思っています。
銀行によってはカメラ付きの端末でQRコードを読ませるタイプのものを導入しているみたいです。
この方式だと、恐らく、客と同じ鍵をサーバ上に持つ
必要があるので、サーバの管理は、かなり厳しいと思われます。
これまでの実績があるので、それほど問題を感じない人も多いかもしれないですが、
公開鍵暗号の署名を併用することで、サーバ側の管理コスト、経営リスクを軽減できるように思うのです。
個人で言うには大きなことを言っていますがOpenICF3や、
ICF3-Zの利権を持っているのは僕で、
その運用を僕が考えないといけないと思って「署名端末」なるものを言っているのです。
経営リスクについて、ピンとこない人は、あったかもしれません。
厳重に鍵を管理していると思われますが、なんらか鍵が漏れると大きな損害が出ます。
行員やシステムに詳しい内部の人間が離反すれば、その可能性も考えられるように思います。
公開鍵暗号を併用すれば、サーバ側に秘密鍵はないので漏れる心配がなく、
これまでの鍵が漏れても、公開鍵暗号側のチェックで、防げるというもの。
署名端末の原価が安ければ、署名併用をする署名端末を採用を考える銀行はあるように思います。
そしてOpenICF3とICF3-Zの2つを持つ、僕が、やれば、安価になるのではと考えているのです。
署名端末ではカメラが不要なので、その分のコストを下げることができます。
かわりにUSB接続が必要ですが、USB接続のチップは信用がなくてもいいので激安なものが使えます。
公開鍵暗号の鍵を長くする必要が出てくる場合も、僕がいれば
SnakeCubeがあるので対応が容易です。
SnakeCubeの利権を持つ人は僕以外に無く、恐らくSnakeCubeより高性能高効率なものは、他にない。
ハッシュは32bit CPUでないと実装しにくいと思われるかもしれませんが、ICF3-Z上に32bitの
仮想マシンを実装することで、既存の32bitコードを、ICF3-Z上に比較的容易に移植できると
思われます。
署名端末の原価を安くするのに8bit CPU ICF3-Zは、役に立つかもしれません。
言えることはICF3-Zは流行ったほうがいいのかも。
急に動画(R18)を買いたくなったので1万円分買った。
うち6600円は12本のまとめ買い。
これは、まとめ買いではないけど→
自宅警備員 1stミッション イイナリ巨乳長女・さやか～編/PoROre
CPUの話をすると、良く家電が壊れたりするのだけど気のせいだろうか。
家族に家電(トースター)を買うように勧められた。既に価格は調査済みで予算は5000円ということだった。
amazonで買うのが楽なのだが、市民が気になり、わざわざ、近所の家電量販店(Joshin)に行った。
5000円弱のトースターを買いました。
作業報告です。それ以上ではありません。
サイバー攻撃で身体に負荷がかかり１日に数時間以上、完全に
動けなくなることも多い状況です。以前として作業の進み方は遅い。
作業をしていても負荷が、かかっていることも多い。
Verilogのシミュレーションを乱数データで大量に流す仕組みを開発中。
C言語のシミュレーションで開発したものを流用するので、わずかな時間で開発ができるだろう。
知財に興味のある方のみ。
SnakeCubeのサイトで
「逆数演算の知財」のページを追加しました。
無事、Verilog 48bit版SnakeCubeでRSAの署名演算が計算できました！
まだ完全ではありませんが、暗号プロセッサとモンゴメリ乗算器の接続がうまくいったので、
完成に近いです。これから1032bit版に拡張していきますが拡張することを考慮して
開発環境を作ってきたので、それほど時間はかからない予定。
そこから、XilinxのFPGAへ貼り付ける作業をして、性能測定へ。
作業報告です。それ以上ではありません。
まだバグっているのかと不安になった人がいるかもと思ったので。ご心配無用です。
久しぶりにDSPを制御するマイクロコードを書いたのですが、
レジスタ系と演算制御系でタイミングが違うの忘れていて、修正しているところです。
2年前の試作のときC++言語で作ったマイクロコード用アセンブラを、最近C言語で作り直しました。
デジタルなタイミングを合わせるだけなので、心配いりません。
雑談を、さらにするなら、日記にも書いていますが、2年前C++で作ったのは、
マイクロコードを保存する分散RAM(LUT-RAM)の数を動的に少なくするためでした。
マイクロコードのプログラムに依存してverilogが生成されるというもの。
2年前の試作でBRAMが余ることがわかったのでマイクロコードの保存先をBRAMにしました。
C++を使うほど難しいアセンブラを作る必要がなくなってCになったのです。
頭痛で足止めされていなければ、こんなことを書くこともなく、あっという間に完成していたと思います。
作業報告です。それ以上ではありません。
Verilog版のSnakeCubeのシミュレーションを動かしているが、
まだバグがあって動いていません。しかし頭の調子が悪い状態でのデバッグは厳しい。
僕の稼働率２０％といったところか。おかげでインターネットのニュースが、いっぱい読める。
昨日の日記でICF3-ZにMRAMを搭載するとどうなるのか、
考えてみました。ここでもう一度、日記に書くのは案外使えるのかもと思ったからです。
解説を、もう一度しますが、わかりやすさを重視したため数字にズレが
生じている可能性はあります。ただ多少ズレていても、だいたいのところは
合っているというような感じだと思います。
SRAMのように使える高価なMRAMより、SRAMの5分の一のアクセス時間でいいから安価な
MRAMを考えます。そして1度に512bit(16命令分)の読み出しに5サイクルかかるとする。
読みだされた後は、CPUはウェイトなく毎サイクル実行できる。
すると分岐命令がない場合はCPUの稼働率は
16/(16+5)*100 = 76%
SRAMの5分の１の性能のMRAMでSRAMの76%の性能というのは、なかなか良さそう。
分岐を入れて50%くらいまで稼働率が下がっても、SRAMの半分の性能が出る。
そして不揮発だから、電源オンしてすぐに使えるマイコンになる。
もし電源オンですぐに使えると便利な家電とかあって、
急激に立ち上がる可能性とかあれば、ICF3-Zも、その波に乗ることができれば、ということでした。
今日、東北大でMRAMが動作したというニュースがあった。
東北大、読み書きが同時に可能なデュアルポート型SOT-MRAMセルアレイの動作実証に成功
MRAMについてメディアで報道される以上のことは知らないのですが、
ICF3-ZでMRAMを使うとどうなるのか、風呂に入りながら考えてみた。
MRAMはフラッシュ以上、SRAM未満なメモリということでフラッシュの代替とか、SRAMの代替とか、
ではなくMRAMの性能特性を活かしたCPUの設計みたいな、ものがあるのかもしれない。
MRAMの性能について調べていると、次の記事が見つかった。
組み込みフラッシュ代替が見えたか、TSMCが22nm世代MRAMで見せた本気
今のところ、バイト単位の高速書き換えや、書き換え速度に興味はなく、
フラッシュより読出し速度が高速でランダムアクセスができてマスク数が少ないから安価
というところに関心を寄せている。つまりTSMCの、このMRAMが最もいいということではないのかもしれない。
記事には22nmで10nsアクセスと書かれている。XilinxのArtix-7は28nmでSRAM読出しが数nsなので、
ICF3-Zで言うと、おおよそ、4～6サイクル程度読出しにかかる。
フラッシュと違って、分岐予測が外れたときくらいの速度で読み出せるのかと、思うのだが、どうだろう。
そうすると、MRAMの性能特性を活かしたCPUの設計ができないだろうか？
ICF3-ZのZeviosはメモリがキャッシュ上になければ割込みを発生させて
キャッシュへの読み込み完了を待つということが簡単なのです。
例えば512bit(16命令分)のデータ幅を持つMRAMを用意して、アドレスを設定してから、4～6サイクル待って、
マルチプレクサで32bitの命令コードを読み出す。SRAMを一切使わない。
言いたいことは、あまり性能を低下させずに大容量のMRAMを活かしたマイコンが作れるのかと。
もう少し、わかりやすく言うなら、少し性能の悪い不揮発SRAMとして、便利かも。(商用できる?)
ツイッターのタイムライン上に激安ARMが1個、0.69ドルというのを見かけた。
見てみるとCortex-M3のARMでした。
Cortex-M3のスペックを調べるとハードウェア除算器を持ち、かつ、
演算サイクルが2～12サイクルなので、僕のICF3-Zよりは、
高度な除算アルゴリズムを使っているみたいです。
ICF3-ZはXilinxのFPGAに実装した結果があるのですが、ちょうど同じFPGAに
Cortex-M3を実装した結果がインターネットで検索して見つかりました。
http://fpga.cool.coocan.jp/cortex-m3.html
これが正しいと仮定すると、
ICF3-ZはCortex-M3のARMに対して
16÷8bitの性能が0.35～2.1倍(ICF3-Z 175MHz時)なので、
高速な除算器を持ったARMに対しても、いい勝負ができていると思います。
(面積性能ではなく性能です!)
Cortex-M3の上記実装の補足をするとプログラム128KB、データ64KBで50MHzは
厳しいと書かれていたので、50MHzとして計算しました。
同程度の性能でありながら、さらに、ICF3-Zは値に依存せずに除算サイクル数が一定なのでPWM制御で使いやすい！
たまに、この日記を読む人向け。
ICF3-Z
の広報をやっていたので遅れ気味ですが、SnakeCube(暗号プロセッサ)の開発を進めていきます。
大雑把に説明をすると、僕の発明
により、あまりうまくパイプライン化できていなかったものが、限界までパイプライン化され、
高効率化されました。このブログの
「SnakeCubeが高周波数で動作する秘密」が参考になるかもしれません。
さらにSnakeCubeは作りやすく、巨大な鍵を演算するのにも向いているため、人類は公開鍵暗号の鍵を長くするという
選択肢を得ることができるように思っています。この効果は大きく、重要な発明になったと思っています。
２年前に発明されたにもかかわらず、思うように開発が進まないのは、なぜなのか。
今もなお、頭痛に悩まされ、足止めされ続けている状況で、大事に至る前に、考えてみる必要があると、思います。
このまま足止めが続くことの予想をしてみてください。
新しい髭剃りを買ったけど、壊れ止めに5年保証 930円も買った。
情報オリンピックの日本代表選手がQiitに投稿した記事を読みました。
この記事を僕が読んで、僕の顔色がどう変化するのか、気になる文系のため日記に書くことにしました。
超高速！多倍長整数の計算手法【前編：大きな数の四則計算を圧倒的な速度で！】
僕の言っている大きな数の四則演算は、暗号演算向け四則演算です。
(それでも汎用の整数演算で使えるかもしれない)
半導体チップ上では、必ずしも数学の理論通りには、ならない。
要するに、僕のSnakeCubeに影響しない。
しかしながら、掛け算の計算量を減らすカラツバ法の話が面白かったです。
こんな方法が1960年まで発明されていなかったのかと思うくらい簡単なのです。
結果が簡単だからと言って、それを発明することが簡単かというと、
そうではないと思いました。
8bit CPU ICF3-Zは、乗算コストが加算コストよりも大きいCPUなので、
2バイト×2バイトの乗算をソフトウェアでするのにカラツバ法は使えるかも。
ほんの少し高速化できるような気がします。いや実際のコードでは高速化してないかも。
ICF3-Zの数値演算ライブラリとか誰か作って、昔のZ80みたいに本になって売れると、
いいのですが。これです。
Z80の数値演算ライブラリの本
Vivadoのバージョンを2019.2から2020.1にして合成しました。
周波数175MHzでのLUT数が減り、性能を保ちながら約１１％面積が小さくなったようです。
githubのほうは更新していませんが、公式サイトの
downloadのページに結果を書きました。
作業報告です。それ以上ではありません。Vivado 2020.1のインストールを開始。
プレスリリースによる高負荷に耐えられるように公式サイトを新しいサーバに移動しています。
サーバ１年分の費用とSSL証明書、高負荷オプション合わせて8000円くらいお金をかけています。
Google アナリティクスで、アクセス状況を確認していますが、まだあまりアクセスがない状況です。
数百のメディアに配信されただけなので、これからアクセスが増えるのかもしれないですが。
＠PressのプレスリリースのURL
https://www.atpress.ne.jp/news/214871
良くできた読み物になっているので是非読んで拡散してください。
このICF3-Zは実用性が高く仮想マシンの機能によりコンパイラが作りやすい。
いろいろなコンパイラがICF3-Zで動くようになれば、いろいろな言語の
プログラマが引き込まれ、コンパイラが作りやすいCPUとして広まり、
さらにコンパイラが作られ、プログラマが引き込まれる。
そうなるように、なれば、なるのかもしれない。(^^;
8bit CPUに税金を投入できる理由も、あまりなく、
たとえ、やっても風当たりが強くて潰されてしまうでしょう。
(僕の中学生の経験では)趣味でアセンブラ、コンパイラを作れる人達が、
楽しめる世界が、できると思っています。
公式実装のZeviosを派生させてI/Oを追加して
自分のマイコンを作ってみるのも良し。
そうやって本格的に立ち上がってくれば、産業に貢献するような、
すごいCPUになってくれることを期待しています。
OpenICF3の公式サイトの文章も
更新して綺麗になっています。
USBテスターが複数ないと心配なので、もう一個買いました。
抵抗器の抵抗はテスターで測ると5.5Ω。別のテスターで抵抗を測定しても5.5Ωでした。
普通の人は、ここまで気を使う必要は、ないと思うのですが。
創刊記念放送のYouTube。
中学生のころ、たまたま本屋で創刊２号目のBASICマガジンを購入し、
300円という安さも手伝って、大学に入った前後くらいまで毎月購入していたと思う。
あるとき、松下のJR-100というパソコンのゲームが掲載されていて、
それをSHARP MZ-2000に移植した。上から落ちてくるICBMを迎撃するゲームで、
中学生でも作れるお粗末なものだった。
親にBASICマガジンに投稿してもいいかと聞くと「やってみたら」
と返答が返ってきたので、作文をして10分のカセットテープにゲームを録音して、
BASICマガジンに投稿をした。
次のBASICマガジンの発売日になって、本屋に急いで行って掲載さているか確認すると、
僕と同じ名前の人が、他の本で掲載されていたMZ-2000(MZ-80B)のテニスゲームを丸パクリしていた。
その後、盗作であることが判明したのだが、とても印象に残っている。
今の僕が、こんなことを書くと、冗談を言っているのだと思うかもしれないが、
本当の話。
mstdn.jpの自分のアカウント
のプロフィールに英語で「輸出規制などの法律に注意してください。」
と書きました。法律に気を使ってます。ということです。
XilinxのVivado 2020.1が公開されていたので35GBのファイルをダウンロード。
BD-DLに書き込みをしたが2回、謎の失敗を繰り返した。1枚300円のBD-DL2枚、合計600円を失った。
作業報告です。それ以上ではありません。
相変わらず、ゆっくりとしたペースでしか動けませんが、峠を越え時間の問題になっています。
インターネットで調べてみました。
Wikiに書いてあるのですが、Javaと同様な利点と欠点のようです。
利点は、移植性が高く、コンパイラが作りやすい、など
欠点は、実行速度が遅いこと。
Wikiには実行時コンパイラによって改善されることがあると書かれているが、
8bit CPUでは、メモリ容量など厳しいかもしれない。
そ・こ・で
僕の8bit CPU ICF3-Zの仮想マシンハードウエア支援機構(仮)が役に立ちます。
僕が主張しているのは、仮想マシンという考え方ではなく、
非力なCPUで仮想マシンを高速に実行するためのハードウエアを
コンパクトに実装して、実用化できそうなところまで、できたこと。
非力なCPU向けです。
ICF3(1999年)は当時、Pコードと発音されていたことがあった。社内ではCOBOLと言う人もありましたが。
PコードはICF3の加算器を改造した四則演算器と、それを制御する命令コードのことを指しています。
名前の由来は、僕の作ったC言語によるシミュレータのマイクロコードを入れる配列の変数名がPCODEだったからです。
最近、Pコードという呼び方をする人が出てきたのでギョーカイではPコードと呼ばれているのかと思ったら、
Wikiにpコードマシン
とか言うのがあって、なるほどと思った。
言いたいのはICF3のPコードと、pコードマシンのpコードは、全く別物。
ICF3のPコードは、ハードウェアの制御信号を命令コードにしたハードに強く依存したコード。
pコードマシンは、ハードウェア非依存の中間的なコード。
全然、違います。
ICF3のプロセッサが1978年、カリフォルニア大学サンディエゴ校（UCSD）で開発された
UCSD p-Systemの影響を強く受けたもののように見せて、
ICF3の足を引っ張ろうとしたのだろうと、思われます。
非常に紛らわしいのですが、ここから、別件の話になります。
悪いことにICF3から派生した8bit CPU ICF3-Zが新機能を追加したことでpコードマシンに、そっくり。
カリフォルニア大のPコードは、恐らくハードウェアに依存しない中間的なコード、Javaのバイトコードのような
仮想マシンが有用であることを主張するもの。
ICF3-Zは、有用である仮想マシンを、ハードウエア支援で、
とてもコンパクトに実装して実用化したことがICF3-Zの成果なのです。
カリフォルニア大のUCSD p-Systemについて、今日、Wikiで初めて知ったので、
実在性の確認はしていません。
8bit CPU ICF3-Zのサイトを突発的な高負荷にも耐えるようにするためサーバを変更しました。
オプションで従量制になるので高負荷で接続できなくなることは、なさそうです。
URLに変更はないので、これまで通りアクセスしていただいて大丈夫です。
SSLサーバ証明書がアルファSSL(グローバルサイン)のDV証明書からJPRSのDV証明書に変わっています。
サーバの負荷分散のためneo.idletime.tokyoをneo.icf3.netに移転させました。
neo.idletime.tokyoにアクセスするとneo.icf3.netに転送されます。
今年の2月1日のブログで8bit CPU ICF3-Zと32bitのRISC-Vを比較してICF3-Zが面積性能25倍という報告をしました。
「オープンソースのCPUの除算性能 RISC-V vs ICF3-Z」
RISC-V SoftCPUコンテスト2018で１位になったVexRiscv
との比較では、どうなのかを推測してみました。厳密なデータが得られていないので不確実な推測ではありますが、
算出根拠を明確に示しているので参考になる数字は出せたと思います。
ICF3-Zの公式サイトのトップページの下のほうに記載しました。
SoftCPUコンテスト1位と比較してもICF3-Zは面積性能12倍！！！
この性能を活かしたビジネスを考えてもいいような。
ごめんなさい。そうなって欲しいの間違いです。
ICF3-Zを税金の投下無しに経済に貢献するようなCPUにするべく考えています。
ICF3-Zは小さい面積の割りに除算が高性能であることから低消費電力で
コストパフォーマンスに優れるCPUになれる能力を持っているように思っています。
昨日、「BOOTHが情報商材の販売禁止に」というニュースがあって、
プログラミングなどの技術書はOKということらしく、ICF3-Zも電子書籍で
儲けられるように考えたほうがいいかもと思ったのです。
要点は、僕に関係するものか、そうでなく勝手にやっているものか、
明確にして、勝手にやって全力で儲ける人が増えればいいかなと。
公式サイトに明文化しました。
ICF3-Zの運営資金
|
