aki_iic’s blog

己の欲せざる処人に施す事無かれ、狂人の真似するは即ち狂人なり

ベンチマーク(独自:)

集合写真(その2.5)eb6802_v0,ebz80_v0,eb6809_v0,eb9995_v0,eb6502_v0

 折角縛り ノスタルジー企画でEBシリーズ(勝手に命名)で5種類のプロセサ(6802,6809(6309),z80,tms9995,r65c02)ボードを製作したのでベンチマークを取ってみようかと思います。

集合写真(その2.5:) - aki_iic’s blog

eb6502_v0 ブロック図(他もcpu以外は同じ構成)

 とはいえ既定のベンチマークは結果が知れているので今回はdba(debug agentのつもり、ロードとダンプとGoしか出来ない簡易ROMの方言です:)でFT245RLのUSB2.0FSで56KBのデータをロードした時間を計測するというつまらんが実用的な測定とします。

1.測定環境

 各ボードのdbaではGoコマンドでpb7のledをOn(PB7='L')にして戻ってきたらOff(PB7='H')にする(Goの間PB7のLEDを点灯する)のでその状態をロジアナで計測する事にしました↓

eb6502_v0 回路図(PB7はPortbコネクタのpin8,11から抽出)

eb6502_v0 56KB ロード時間測定(PB7をモニタ)

 画面上のCH0がPB7であり、1.837sec程度の時間が掛かっている様です。データは56KBですから、56KB/1.837sec=30.48KB/secと計算されます。

2.測定結果

 同様にeb9995_v0,eb6802_v0,ebz80_v0,eb6809_v0でも同様の測定をした結果を以下に示します。

データ量:56KB
伝送路:USB2.0FS、x1tablet SelfpowerHUB経由
対象:eb6502_v0,eb9995_v0,eb6802_v0,ebz80_v0,eb6809_v0
結果:
eb6502_v0 r65c02@2Mhz  56KB/1.837sec 30.48KB/sec 15.24KB/Mhz
eb9995_v0 tms9995@3Mhz 56KB/2.083sec 26.88KB/sec(1wait) 8.95KB/Mhz 
eb6802_v0 mc68b02@2Mhz 56KB/2.036sec 27.50KB/sec 13.75KB/Mhz
ebz80_v0  z84c00@8Mhz  56KB/0.788sec 71.01KB/sec 8.87KB/Mhz
eb6809_v0 hd63b09@2Mhz 56KB/1.175sec 47.65KB/sec(HD63B09E) 23.82KB/Mhz

・順位(転送速度):

z80@8Mhz > 6809@2Mhz > 6502@2Mhz > 6802@2Mhz > 9995@3Mhz(1w)

・順位(Mhz辺りの転送速度):

6809 > 6502 > 6802 > 9995(1w) > z80

3.分析

 16bitのtms9995が一番遅い結果ですがこれはautoready(自動1wait)の影響の可能性と当方のプログラミングの下手(BL使いすぎなど)が支配的な可能性があります。

 8ビット系は6502(r65c02だが意図的に6502命令で構成)が当方のプログラミングの下手さと16ビットアドレス処理の点から速くは無い様です(あくまで当方の環境にて)。

 6802が6809に比べて遅いのはやはりインデクスレジスタが2本使えるかの差が大きい印象。6802ではixをsave/restoreして使用しているのでオーバヘッドが大きいです(あくまで当方の拙いプログラムでの話)。

 6809はオートインクリメントとIYをループカウンタに使用出来るので6802に対して有意な結果となっております(チェリーピッキングな面が亡きにしもあらず)。

 意外というかそういうものかとの印象を持ったのはz80@8Mhzが71.01KB/secと最高スコアを出した事でcpuクロックと豊富なレジスタでワーク無しでデータ転送が行える点も有利に働いたのかもしれません。

 Mhz辺りの転送速度(意味があるかどうかは別にして)を計算してみると68xx,6502,9995,z80の順でCPI(と呼ぶには些か・・・)では・・・という独自解釈も(モトローラ寄りでしょうか:)。

 

4.まとめ

 まあ、だからどうしたという処ではありますが(ネタに乏しいので・・・)、使い方によっては6809は案外効率的ではあるし、Z80はレジスタ数とクロック周波数で本ベンチマーク(ここ笑う処です:)の如きIoとメモリ間のデータ転送で16ビットアドレス空間をリニアに処理する場合にはそれぞれの特徴(と当方のポンコツプログラム:)が現れたのかもしれません。

 蛇足ですが5インチ2Dのフロッピーが250kbps=25KB/s(理論値)ですからUSB2.0FSのFT245RL(CDC-ACM)でUbuntu 24.04LTSのX1Tablet(CoreM5)でそれより速い(何を比較しているやら・・・)であると(あはは)。

20260517 05:17追記:eb9995_v0 でautoreadyをoff(nRESET時にREADY='L')して0waitにして測定しました(他の条件は同じ、56KB、測定環境共)。

eb9995_v0 0wait で56KB ロード時間

 1.304sec程度の様なので、56k/1.304=42.94KB/sec 14.31KB/Mhz となりました。

 更新しますと、

・順位(転送速度):

z80@8Mhz > 6809@2Mhz > 9995@3Mhz(0w) > 6502@2Mhz > 6802@2Mhz > 9995@3Mhz(1w)

・順位(Mhz辺りの転送速度):

6809 > 6502 > 9995(0w) > 6802 > 9995(1w) > z80

 当方の9900のプログラムスキルがポンコツなのでコード最適化の余地があると思いますが、プログラムメモリ領域のwait無しという条件(これは公平と言って良いかと)で、当方の環境ではこうなりましたというお話です。

 8ビットや初期のレトロマイコンはキャッシュだのパイプラインだのと面倒な事が少ないので性能測定も容易で安定した結果が出ます(プログラムにも依るが。