すｚのAVR研究: AVR互換コア(テスト)

<< AVR互換コア(設計メモ) | TOP | Digikeyで買い物(2011-4) >>

2011年04月05日

AVR互換コア(テスト)

もう最初に想定した機能レベルは実装が済んでしまった。そろそろ、いろいろなパターンでちゃんと動くかテストする段階だ。gcc は完成度が低く不満があるがどうせ gcc だけでは使う命令が少なくてテストしきれないのだ。ここらで見切りを付けてテストに入りたい。

まずは、ベース。

rtavr-wk08.tar.gz

これをベースにする。テストに使う gcc は自分で作ったもの。問題はあるがなんとかごまかして使っていこうと思う。再現性の問題があるので、バイナリを固定する。具体的には以下のもの。

AVR_Toolchain-20110409-win.tar.gz Windows 版ベース (27MB ぐらい)
AVR_Toolchain-20110409-lin.tar.gz Linux 版ベース (25MB ぐらい)
AVR_Toolchain-20110409-src.tar.gz パッチ集

これでも完成度は低い。が、当面 20110409 版で固定する。

20110409 版では、1word lds/sts に対応できた。ちょっとしたテストコードならなんとかなるレベルになった。あとはごまかして使う。

さて、ここまで楽しく作ってきたがテストはやっぱり面倒そうだ。一体どうしたら良いのだろう？

ちょっと案を考えてみよう。

ひとつは、他のシステムのテスト用ツールを借りる方法。-- 調べてみると simulavr がそれを持っている。

もうひとつ考えてみた。

ある命令列を実行して、どこかの IOR を SBI/CBI する。そうすると、レジスタをダンプするような test bench を組んでおく。で、正しい結果と diff を取る。

正しい結果は、別のもので作る。たとえば実際の AVR でも良い。テストできないのは、1word LDS/STS のみだし、それは gcc では当面使えない。SBI/CBI すると割り込みを起こすようにしておいて、レジスタダンプを取り、ホストに転送するようにしておけば良い。

メモリの内容をテストするなら、レジスタにロードしてダンプさせれば良いし、SREG や SP のテストも同様にできる。

もうひとつは、md5 とが gzip のような圧縮・伸張あと暗号化、ランダム。こういったデータを変換するもの。正しく動いたかは出力を照合することで判断できる。

もっともダメならどこでおかしくなったのか調べる必要があるから、レジスタダンプのやりかたも併用することになる。

それと基本的な命令パターンの確認もやらないといけないだろう。どういう命令が動いたのか一覧表を作ってテストしてないものが分かるようにしないと。一区切りするタイミングがわからない。

追記: libgcc.a で使っていない命令


    avr-ar -x libgcc.a 
    avr-ld -r -o ../xx.o *.o
    avr-objdump -d ../xx.o | ....

テストプログラムの選定

ここ

USBNIX

08A

rtavr-wk08a.tar.gz

テストするためのフレームワークとして、INT0 を使うことにした。... が、良く考えたら INT0 はまだちゃんとテストしていない。
```
ISR(INT0_vect) {
        bit_clear(PORTC, PC2);
}

int main() {
        MCUCR = (3 << ISC00); // posedge
        bit_clear(PORTC, PC2);
        bit_set(DDRC, PC2);
        bit_set(GIFR,INTF0);
        bit_set(GIMSK,INT0);
        sei();

        nop();
        bit_set(PORTC, PC2);
        PINC;
        PINC;
        bit_set(PORTC, PC2);
        nop();
        nop();
        return 0;
}
```
テストプログラムは、こういう風にした。PC2 に SBI することで INT0 の posedge で INT0 を発生させる。割り込み処理の方では、PC2 を元に戻す。

INT0 をソフトウェア割り込みとして使ったのは初めてなのだが、例外(フォルト)ではなく、あくまで割り込みなので、数命令ずれて割り込みが発生する。それを確認するために PINC; とか nop とかいれている。

実はこれをコンパイルするのが一苦労。add4 でようやくちゃんとコンパイルできるようになった。

出来たコードの一部を載せるとこう。
```
0000005e <__vector_1>:
  2f:    933f           push    r19
  30:    932f           push    r18
  31:    b72f           in      r18, 0x3f       ; 63
  32:    932f           push    r18
  33:    e030           ldi     r19, 0x00       ; 0
  34:    98ea           cbi     0x1d, 2 ; 29
  35:    912f           pop     r18
  36:    bf2f           out     0x3f, r18       ; 63
  37:    912f           pop     r18
  38:    913f           pop     r19
  39:    9518           reti

00000074 <main>:
  3a:    ec80           ldi     r24, 0xC0       ; 192
  3b:    bf8a           out     0x3a, r24       ; 58
  3c:    98ea           cbi     0x1d, 2 ; 29
  3d:    9ae2           sbi     0x1c, 2 ; 28
  3e:    9a58           sbi     0x0b, 0 ; 11
  3f:    9a60           sbi     0x0c, 0 ; 12
  40:    9478           sei
  41:    0000           nop
  42:    9aea           sbi     0x1d, 2 ; 29
  43:    b38b           in      r24, 0x1b       ; 27
  44:    b38b           in      r24, 0x1b       ; 27
  45:    9aea           sbi     0x1d, 2 ; 29
  46:    0000           nop
  47:    0000           nop
  48:    e080           ldi     r24, 0x00       ; 0
  49:    e090           ldi     r25, 0x00       ; 0
  4a:    9508           ret
```
シミュレーション結果の一部はこれ。9AEA が INT0 を発生させる SBI 。次の B38B が PIN の変化を見るための IN 命令 (x2) 。この IN 命令 2 つを実行して割り込みが受け付けられる。

実を言うとこの動作は、実際のAVR とタイミングが違う。まず PIN の読み込み。マニュアルには、PORT に out した次の命令で PIN から in しても反映されないと書いてある。nop を１命令入れないと正しい値は読めない。 ( 当然ながら PORT を in する場合は nop は不要 )

だが、RTAVR は nop は不要。周辺装置は postedge で動作するので PORT の変化は postedge 。これを PIN に移すのは、negedge 。次の PIN はその次の postedge でちゃんと読める。

ちなみにイメージの INST は S1 の状態。実行（S2) は 1クロックずれる。9ARA の sbi の実行の次のクロックで割り込みの要求が出ているのだが、それが受け付けられるのはさらに 1 クロック後。なので、sbi から 2 命令すべって割り込みが実行されている。
これを元にして、レジスタダンプのテストベンチを作る予定。

あと ldd/std 命令を入れてみた。1word LDS/STS と競合するのは、変位が 32-63 の範囲。0-31 に制限すれば競合を避けられる。

動くかどうかは分からないが、まずは規模を見積もるのが目的。50A 用の rtavr_defs.v に追加すると 665 スライスが 682 スライスになった。... なんとかなるかも。
ちなみに avr-gcc には、 -mmorder1 とか -morder2 とかのオプションがある。同じようにして、ldd/std に対応させるようなオプションは作れそう。ただ binutils も対応しないといけない。

binutils -- いじっていたら 1word lds/sts がサポートできそうな感じになってきた。これなら..というわけでバイナリを全部作りなおすことに。パッチも整理する。

暫定的に AVR_Toolchain-20110408 版を置いた。


queen_r.c:(.text+0xa): warning: internal error: out of range error
queen_r.c:(.text+0x10): warning: internal error: out of range error
queen_r.c:(.text+0x70): warning: internal error: out of range error
queen_r.c:(.text+0x80): warning: internal error: out of range error
queen_r.o: In function `main':
queen_r.c:(.text+0x282): warning: internal error: out of range error
c:/avr_toolchain/bin/../lib/gcc/avr/4.4.3/../../../../avr/lib/avrtiny10\libc.a(printf.o): In function `printf':
/xhl1/as5/avr-libc-1.7.1-fix2/build2/avr/lib/avrtiny10/../../../../libc/stdio/printf.c:44: warning: internal error: out of range error


.global aaa
        .type   aaa, @function
aaa:
/* prologue: function */
/* frame size = 0 */
        mov r30,r24
        mov r31,r25
        std Z+1,__zero_reg__
/* epilogue start */
        ret
        .size   aaa, .-aaa


.global aaa
        .type   aaa, @function
aaa:
/* prologue: function */
/* frame size = 0 */
        mov r30,r24
        mov r31,r25
        subi r30,lo8(-(1))
        sbci r31,hi8(-(1))
        st Z,__zero_reg__
        subi r30,lo8(1)
        sbci r31,hi8(1)
/* epilogue start */
        ret
        .size   aaa, .-aaa

AVR_Toolchain 20110409

08B

rtavr-wk08b.tar.gz

上で書いた変更を反映した。
tb_008 に ldd/std テストを追加。
ldd/std の変位の加算

あと、テストのためのプログラム tb_shuffle 追加。乱数のようなもので種を元にデータを変更していく。演算の種類を増やしたものを適当に作ってみた。どこかでループしていたりするかも知れないが乱数自体が目的ではないので気にしない。

PC で検算できるようにしておいた。すくなくとも結果が同じでないとダメなわけだから演算結果をダンプしてみようと思う。

08C

rtavr-wk08c.tar.gz

tb_shuffle をテストしたが、shuffle_init からリターンするときに 0x555 に飛んでいってしまうというバグがまず見つかった。

調べたところ、
```
  b4:    40f0           sbci    r31, 0x00       ; 0
  b5:    9508           ret

0000016c <shuffle>:
  b6:    930f           push    r16
  b7:    931f           push    r17
  b8:    93df           push    r29
```
ここが該当するところで、ret の後 push が続くと起きるバグということが分かった。

push 命令が無効化されているのに v_ea_push が 1 になってしまうために、v2_ea の計算が push 用になってしまうのが原因。

08C ではこのように直った。

だが、２つ目のバグがすぐ見つかる。

次は、shuffle() のリターンで。0x25E に飛んでいくバグ。期待されるのは、0x05E。
これは、上位バイトのメモリ(0x162)に 0x62 が書き込まれているためと分かった。

さらに調べると。ここで 0x62 を書き込んでいる。... ここまでは分かった。が、なぜなのかサッパリ分からない。gcc のバグかも知れないし。

... これは、AVR Studio のシミュレータでどうなるか追ったほうが良いかも知れない。
実際に AVR Studio 4.18SP3 までインストールしてみたところ
- SP3 は、"Simulator 2" で attiny40 をサポートしていた。
- 違うパスの avr-gcc を使うことができるようになっていた。
... というわけで、変更なしにシミュレータにかけることができることがわかった。ソースから生成しても同じ HEX になることを確認して
```
  Debug → "Start Debugging"
```
とすると Disassenbler リストが出てきた。この上で動かしていくことができる。
まずは、走り切るのかどうか。
- 1 回目の shuffle() call すら無限ループらしく戻って来ない。
どうも動かないものが出来てしまったようだ。途中までテストはできるが ... その先が困ってしまう。なかなかに、厳しい。
さて、どうしよう。
- rtavr 側では、SP / SREG はいつでもわかる(ようにできる)。だがレジスタの内容は直接は分からない。
- 分かるのはせいぜい Rd を指定して書き込んだ値。
- メモリの内容もわからない。... が、書き込んだ値は分かる(ようにできる) 。
ここから考えて ...
- rtavr.v から GPR と RAM を切り離し test bench の方で組み込んで Watch できるようにする。
- あるいは、切り離さずに Watch するデータを output として test bench で見えるようにする。
- test bench では、$fdisplay() とかを使って Watch するデータを契機にログを取る。
  取るログは、SREG と SP あとレジスタにロードした値 (＋レジスタ番号) と　メモリにストアした値。(＋EA )
- このログに合わせたデータをシミュレータから取り出す。
- 検証は、形式を合わせて diff をとれば良い。
- こういうことをしたいなら、simulavr を使うのが良さそうだ。... が、attiny40 には対応していないように見える。改造しないと。
- simulavr は、python 以外に TCL にも対応しているそうだ。それを使うという手もある。... だがどうせ改造するなら、ダイレクトに log を取るコードにしてしまうのも手かも知れない。
```
L r17 = 00 : PC 0013 FLAGS 02 SP 0000
L r29 = 3f : PC 0015 FLAGS 00 SP 0000
L r29 = 01 : PC 0016 FLAGS 00 SP 0000
L r26 = 00 : PC 0019 FLAGS 02 SP 013f
L r27 = 60 : PC 001a FLAGS 00 SP 013f
L r30 = 00 : PC 001b FLAGS 02 SP 013f
L r31 = 06 : PC 001c FLAGS 00 SP 013f
L r16 = 45 : PC 001d FLAGS 00 SP 013f
L r26 = 00 : PC 0024 FLAGS 02 SP 013f
L r27 = 60 : PC 0025 FLAGS 00 SP 013f
L r16 = 00 : PC 0026 FLAGS 02 SP 013f
S mem[0060] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0061] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0062] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0063] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0064] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0065] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0066] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0067] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0068] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[0069] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[006a] = 00 : PC 0028 FLAGS 2d SP 013f
S mem[006b] = 00 : PC 0028 FLAGS 2d SP 013f
```
こんな風にレジスタ、メモリの変化をログすることは出来た。ただし注意点があって、(1) PREDEC/POSTINC による変化はログされない。(2) PC は常に +1 の値。

面白いことに、bss のクリアは PREDEC/POSTINC を使っているので、(ログでは)レジスタの変化なしで連続にメモリに書き込んでいる。ループの終了判定もフラグだけ変化させる cpi/cpc なのでレジスタの変化なし。

改造した結果バグが入っていないことを検証するなら自己完結するのだが、正しいかどうか検証するなら他のもので同じデータを作らないといけない。

さて、検証用データをどう作ろう。... って simulavr でなんとかするつもりだが、別の方法もある。たとえば、kx_avr など他のコアを rtavr に組み込むとか。.. 想定のうちだからなんとかなるかも知れない。組み込めてしまえば、同じ test bench が使える。

さて、どっちが楽だろう？

あ、kx_avr は xilinx のプリミティブ使っているから無理。AVR Core は VHDL だし。... ちょっと厳しいか。

simulavr を見てみる。...

AVR Core の部分は、decoder.c のようだ。でこんな風に使っている。
```
    opi = decode_opcode (opcode);
    result = opi->func (core, opcode, opi->arg1, opi->arg2);
```
ざっとみたところ命令は、16bit 長だから 65536 個の配列を作っておいて、そこに opcode に対応する関数を登録しているようだ。で、table 引き 1 回で済ましている。

decoder.c だけ使ってあと適当にでっち上げても動かせそうな感触。ちょっとやってみるか。
```
L r17 = 00 : PC 0013 FLAGS 02 SP 0000
L r28 = 3f : PC 0015 FLAGS 00 SP 0000
L r29 = 01 : PC 0016 FLAGS 00 SP 0000
L r17 = 00 : PC 0019 FLAGS 00 SP 013f
L r26 = 60 : PC 001a FLAGS 00 SP 013f
L r27 = 00 : PC 001b FLAGS 00 SP 013f
L r30 = 06 : PC 001c FLAGS 00 SP 013f
L r31 = 45 : PC 001d FLAGS 00 SP 013f
L r18 = ff : PC 001f FLAGS 00 SP 013f
S mem[060] = ff : PC 0020 FLAGS 00 SP 013f
L r17 = 00 : PC 0024 FLAGS 00 SP 013f
L r26 = 60 : PC 0025 FLAGS 00 SP 013f
L r27 = 00 : PC 0026 FLAGS 00 SP 013f
S mem[060] = 00 : PC 0028 FLAGS 00 SP 013f
S mem[13f] = 2b : PC 002c FLAGS 35 SP 013f
```
なんかでっち上げることが出来た。使わない命令は全部削ってしまって 1word LDS/STS と reduced LDD/STD に対応。IOR は SREG と SP のみ。当然割り込みもない。

フォーマットもすり合わせた。($fdisplay は fprintf とちょっと違うようだ)
rom ファイルは、rom_data.mem があるのを前提にできるから安易に fscanf で読み込む。

使い方は、
```
   avr8l_trace [-l loops] [-f rom_file]
```
パラメータなしだと rom_data.mem を読み込んで 200 回実行する。

それは良いのだが、結果が全然違う。まぁどちらかがバグっているわけで、同じになるようにデバッグしていけば良い。必ず先に進めるわけでだいぶ気が楽になった。

08D

rtavr-wk08d.tar.gz

すぐバグが見つかるのだが、ここまでを一旦スナップショット。

バグは、0x60 から連続でメモリに書きこんでいるところ。フラグが 0x2d になっているが 0x35 が正しい。
フラグは、cpc 命令での変化で、S と V が違う。V が違えば S も違うので V の計算が原因。
調べたら確かに間違い。修正できた。

次に 0x4e あたりフラグが 0x81 になっているが正しくは 0xa1 。似た様な感じで SUBI での H flag の計算のバグ。

続く MOV で今度はフラグを変更してしまっている。これは、OP3_WRF の条件の間違い。

さて、これを直して diff を取ってみたら今度は SP がずれているのが見えてきた。
```
(avr8l_trace)
< S mem[013f] = 2b : PC 002a FLAGS 02 SP 013f
< S mem[013e] = 00 : PC 002a FLAGS 02 SP 013e
< S mem[013d] = 00 : PC 0038 FLAGS 02 SP 013d
< S mem[013c] = 00 : PC 0039 FLAGS 02 SP 013c
< S mem[013b] = 01 : PC 003a FLAGS 02 SP 013b
< S mem[013a] = 3f : PC 003b FLAGS 02 SP 013a
(rtavr)
> S mem[013f] = 00 : PC 002a FLAGS 02 SP 013e
> S mem[013e] = 2b : PC 002b FLAGS 02 SP 013d
> S mem[013d] = 00 : PC 0038 FLAGS 02 SP 013c
> S mem[013c] = 00 : PC 0039 FLAGS 02 SP 013b
> S mem[013b] = 01 : PC 003a FLAGS 02 SP 013a
> S mem[013a] = 3f : PC 003b FLAGS 02 SP 0139
```
AVR Studio に判定を仰ぐと　0x13f には 0x2b が　入るのが正しい。が、0x3b 終了時の SP は 0x139 が正しい。後者は、avr8l_trace でメモリに書く前に SP を変更しておかないと表示が合わなくなるという問題。

前者には問題が 2つ rcall での HI-byte と LO-byte の積む順番が逆ということと、PC 。rtavr では PC を進ませているが、 avr8l_trace では、進ませずに一気に書く。PC は表示だけの問題だから rtavr に合わせるよう細工する。

これを直すと次は
```
> L r31 = 00 : PC 0041 FLAGS 00 SP 0139
39a41
> L r23 = 80 : PC 004b FLAGS 00 SP 0126
```
なんだろう？
実際のトレースは、
```
L r28 = 26 : PC 003e FLAGS 00 SP 0139
L r29 = 01 : PC 003f FLAGS 00 SP 0139
L r18 = 00 : PC 0040 FLAGS 00 SP 0139
L r31 = 00 : PC 0041 FLAGS 00 SP 0139  <<<
L r24 = c0 : PC 0045 FLAGS 00 SP 0126
L r23 = 80 : PC 004b FLAGS 00 SP 0126  <<<
L r16 = 26 : PC 004c FLAGS 80 SP 0126
```
コードはこれ。
```
  3e:    51c3           subi    r28, 0x13       ; 19
  3f:    40d0           sbci    r29, 0x00       ; 0
  40:    b72f           in      r18, 0x3f       ; 63
  41:    94f8           cli
  42:    bfde           out     0x3e, r29       ; 62
  43:    bf2f           out     0x3f, r18       ; 63
  44:    bfcd           out     0x3d, r28       ; 61
  45:    ec80           ldi     r24, 0xC0       ; 192
  46:    bf8a           out     0x3a, r24       ; 58
  47:    98ea           cbi     0x1d, 2 ; 29
  48:    9ae2           sbi     0x1c, 2 ; 28
  49:    9a58           sbi     0x0b, 0 ; 11
  4a:    9a60           sbi     0x0c, 0 ; 12
  4b:    9478           sei
  4c:    2f0c           mov     r16, r28
```
なるほど、cbi/sbi はロードしてストアしているが、なぜかレジスタへのロードもしているわけか。
-- 修正。

次、
```
< S mem[0139] = 00 : PC 005a FLAGS 80 SP 0126
```
```
  59:    2f90           mov     r25, r16
  5a:    8b4b           std     Y+19, r20       ; 0x13
```
LDD/STD がバグっていた。-- 修正。

次
```
< L r20 = 40 : PC 0104 FLAGS 99 SP 0106
---
> L r20 = 02 : PC 0104 FLAGS 99 SP 0106
```
... 値が全然違う。
```
 103:    9555           asr     r21
 104:    9547           ror     r20
 105:    956a           dec     r22
```
これ、間違っていたので直そうとしたが、まだダメ。フラグは posedge で変化するので GPR が取り込むタイミングで値が変わってしまっている。ROR などで C_in を GPR が取り込む場合ラッチしておかないとダメなようだ。これは直すが、他に該当するものがないか気になる。
```
< L r27 = 00 : PC 010f FLAGS a1 SP 0106
< L r20 = 00 : PC 0110 FLAGS a1 SP 0106
< L r21 = 00 : PC 0111 FLAGS a1 SP 0106
---
> L r27 = 00 : PC 010f FLAGS a3 SP 0106
> L r20 = 00 : PC 0110 FLAGS a3 SP 0106
> L r21 = 00 : PC 0111 FLAGS a3 SP 0106

 10d:    1fbb           adc     r27, r27
 10e:    5aa0           subi    r26, 0xA0       ; 160
 10f:    4fbf           sbci    r27, 0xFF       ; 255
 110:    914d           ld      r20, X+
```
これは ... Z flag が立ってしまっているわけだが、SBC/SBCI は前の状態が Z=1 でなければ 0 になってしまう仕様だった。... 知らなかった。--- 直した。

次
```
< S mem[0106] = 39 : PC 0138 FLAGS 80 SP 0105
< S mem[0105] = 01 : PC 0139 FLAGS 80 SP 0104
---
> S mem[0106] = 39 : PC 0138 FLAGS 80 SP 0105
> S mem[0105] = 00 : PC 0139 FLAGS 80 SP 0104
```
rcall での PUSH 。HI/LO 入れ替えた修正をしたが失敗。

これを直す前に... 気分転換に規模確認。

50A 用の設定で 711 ... 厳しくなった。が、動かす方が先。
次、
```
< L r22 = b8 : PC 024b FLAGS ac SP 0104
< L r23 = 84 : PC 024c FLAGS 8c SP 0104
---
> L r22 = b8 : PC 024b FLAGS b4 SP 0104
> L r23 = 84 : PC 024c FLAGS 94 SP 0104

 24b:    0f66           add     r22, r22
 24c:    1f77           adc     r23, r23
```
V flag (overflow) の計算式が add と sub で違った。前の修正は add 用を sub 用に変えただけだった。

08E

rtavr-wk08e.tar.gz

行き詰まった。とりあえず、スナップショット。
```
< L r18 = b8 : PC 0249 FLAGS 94 SP 0104
< L r21 = 84 : PC 024a FLAGS 94 SP 0104

< L r18 = 38 : PC 0249 FLAGS 99 SP 0104
< L r21 = d0 : PC 024a FLAGS b4 SP 0104

< L r25 = d0 : PC 0255 FLAGS 82 SP 0104
< L r24 = 38 : PC 0256 FLAGS 82 SP 0104
---
> L r25 = 00 : PC 0255 FLAGS 82 SP 0104
> L r24 = 00 : PC 0256 FLAGS 82 SP 0104

 247:    ff80           sbrs    r24, 0
 248:    c002           rjmp    .+4             ; 0x496 <__mulhi3_skip1>
 249:    0f26           add     r18, r22
 24a:    1f57           adc     r21, r23

00000496 <__mulhi3_skip1>:
 24b:    0f66           add     r22, r22
 24c:    1f77           adc     r23, r23
 24d:    1763           cp      r22, r19
 24e:    0773           cpc     r23, r19
 24e:    0773           cpc     r23, r19
 24f:    f029           breq    .+10            ; 0x4aa <__mulhi3_exit>
 250:    9596           lsr     r25
 251:    9587           ror     r24
 252:    5080           subi    r24, 0x00       ; 0
 253:    4080           sbci    r24, 0x00       ; 0
 254:    f791           brne    .-28            ; 0x48e <__mulhi3_loop>

000004aa <__mulhi3_exit>:
 255:    2f95           mov     r25, r21
 256:    2f82           mov     r24, r18
 257:    9508           ret
```
問題の場所。レジスタの変化がないのに、違うところが動いている。最後には <__mulhi3_exit>: には来る。

cp/cpc が見えるし、レジスタやメモリに変化がなくても SREGが変化したりや PC が +1 でないケースもログを取るようにしている。だがこんな感じなのだ。

ちなみに AVR Studio で 255 -- <__mulhi3_exit> まで実行させると 2679 サイクル。結構動いているかも。

AVR Studio で確認したら 247 の sbrs でスキップしないと次の rjmp で 249/24a の次に飛ぶ。3 回目の sbrs でスキップして 249/24a が初めて実行される。r24 の値は 0x11 。

で、調べてみると skip 周りなにか変。そもそも s2 に入ってから skip することが分かっても遅い。副作用のある s0 があるから s1 で skip することが分かるようにするか skip 命令だと分かった時点で副作用のある s0 を止めておかないといけない。だが、現状そうなっていない。
... というわけでじっくり検討しようと思う。

skip 命令は一ヶ所しかないようなので、ちょっと後回し。

次の問題は、 CPC で Z flag が立ってしまうもの。SBC/SBCI と同様だった。サイクル数 458。

次。ANDI/ORI で C flag を 0 にしていた。サイクル数 507。

次。BRTC でブランチしない。C flag を 0 にしていた。サイクル数 828。
これは、rcall の後ろにある無効化されたスキップ命令が、BRTC を無効化してしまっていたため。

次。27b の com 命令のフラグが違う。サイクル数 1034。
81 が正しいが 99 。V flag が間違っている。COM は無条件に 0 。

次からは不定値が出だす。このまま続けてもどうせ int0 を起こして結果が変わるので少しコードを変更。

次のコードは、上記のバグが出た所。
```
 107:	 2f94       	mov	r25, r20
 108:	 7097       	andi	r25, 0x07


 265:    9508           ret
000004cc <__divmodhi4_neg1>:
 266:    f7f6           brtc    .-4             ; 0x4ca <__divmodhi4_exit>   
 267:    9590           com     r25
 268:    9581           neg     r24
 269:    4f9f           sbci    r25, 0xFF       ; 255
 26a:    9508           ret

 278:    955a           dec     r21
 279:    f7a9           brne    .-22            ; 0x4de <__udivmodhi4_loop>
 27a:    9580           com     r24
 27b:    9590           com     r25
 27c:    2f68           mov     r22, r24
```
不定値は、00f1 の LD Z+ 。5 回目でサイクル数 1244。アドレス(Z)は 0x130 。
どうも書きこんでいないエリアを初めてアクセスしたようだ。RAM に初期値 0 を設定することでクリア。

08F

rtavr-wk08f.tar.gz

次 4 回目の 0x260 の and 。結果が 1 なのに Z flag が 1 になっている。既に 2000 命令を越えている。
verilog シミュレータで該当箇所を探すのも億劫になってきた。

とりあえず、スナップショット。この問題もあるが skip 命令も修正しないと。

skip 命令を修正したら、仕切りなおして別記事にしようと思う。随分動くようになったし、テスト方法も新たなもの検討すべき時期になった。

バグも沢山出ている。場当たり的に直してきたが、一度整理して同じようなバグがないか調べてみる必要もある。

そういえば、avr8l_trace 仕様を変更した。-d オプションを付けると、フラグが変化したとき等のログを出力するようになる。ただ、これだと差分が大量にでるので標準にはしない。

（続く）
関連記事:

著作権について

posted by すｚ at 21:22| Comment(0) | TrackBack(0) | AVR_CORE

この記事へのコメント

コメントを書く

この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/44154956
※ブログオーナーが承認したトラックバックのみ表示されます。

この記事へのトラックバック

<< 2024年06月 >>
日	月	火	水	木	金	土
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30