IchigoJam web のマシン語の実行のバグの解析
はじめに
IchigoJamはjig.jpの登録商標です。
去年のアドベントカレンダーで、IchigoJam web でマシン語の実行ができるようになったものの、
なぜかうまく動かないコードがありました。
そこで、今回はどのようなバグによってこの誤動作が引き起こされているのかを考えてみました。
バグ
以下のXorshiftのプログラムがうまく動かず、RUNするたびに違う数値列が出力されるという不都合が発生しました。
10 'Xorshift
20 POKE#700,#3F,#A3,#18,#68,#C1,#02,#48,#40
30 POKE#708,#59,#68,#19,#60,#99,#68,#59,#60
40 POKE#710,#D9,#68,#99,#60,#D9,#68,#CA,#0C
50 POKE#718,#51,#40,#02,#0A,#48,#40,#50,#40
60 POKE#720,#D8,#60,#7F,#21,#09,#02,#FF,#31
70 POKE#728,#08,#40,#70,#47
80 POKE#800,#15,#CD,#5B,#07,#E5,#55,#9A,#15
90 POKE#808,#B5,#3B,#12,#1F,#33,#13,#49,#05
100 FOR I=1 TO 20
110 PRINT USR(#700,0)
120 NEXT
そこで、とりあえずマシン語を実行する前後でXorshiftの状態を保存している配列の値がどう変わっているかをチェックしました。
10 'Xorshift
20 POKE#700,#3F,#A3,#18,#68,#C1,#02,#48,#40
30 POKE#708,#59,#68,#19,#60,#99,#68,#59,#60
40 POKE#710,#D9,#68,#99,#60,#D9,#68,#CA,#0C
50 POKE#718,#51,#40,#02,#0A,#48,#40,#50,#40
60 POKE#720,#D8,#60,#7F,#21,#09,#02,#FF,#31
70 POKE#728,#08,#40,#70,#47
80 POKE#800,#15,#CD,#5B,#07,#E5,#55,#9A,#15
90 POKE#808,#B5,#3B,#12,#1F,#33,#13,#49,#05
100 PRINT[0],[1],[2],[3],[4],[5],[6],[7]
110 PRINT USR(#700,0)
120 PRINT[0],[1],[2],[3],[4],[5],[6],[7]
実行結果は例えば以下になりました。
-13035 1883 21989 5530 15285 7954 4915 1353
21989 5530 15285 7954 -24133 -30309 4915 1353
ここから、以下のことがわかります。
ただし、配列の要素2個をペアにして「n番目」とカウントします。
- 1番目と2番目の値は、正しくシフトされている。
- 3番目の値は、正しくシフトされず、謎の値が入っている。
- 4番目の値は、変わっていない。
比較のため、
IchigoJamでXorshift(疑似乱数) マシン語 vs BASIC - Qiita
に載せた(IchigoJam webでも正しく動く)BASIC版でも配列の値を見てみました。
10 'Xorshift (BASIC)
20 LET[0],#CD15,#075B,#55E5,#159A,#3BB5,#1F12,#1333,#0549
30 PRINT[0],[1],[2],[3],[4],[5],[6],[7]
40 T=[0]^([0]<<11):U=[1]^([1]<<11|[0]>>5FF)
50 [0]=[2]:[1]=[3]
60 [2]=[4]:[3]=[5]
70 [4]=[6]:[5]=[7]
80 V=[6]^([7]>>3FFF)^T^(U<<8|T>>8&#FF):W=[7]^U^(U>>8&#FF)
90 [6]=V:[7]=W
100 ?VFFF
110 PRINT[0],[1],[2],[3],[4],[5],[6],[7]
実行結果は以下になりました。
-13035 1883 21989 5530 15285 7954 4915 1353
21989 5530 15285 7954 4915 1353 17898 -9053
1番目~3番目の値が正しくシフトされています。
メモリアクセスの調査
3番目の値を書き込む所までのマシン語のソースコードは、以下のようになっています。
R3 = PC + #40
' t = x ^ (x << 11)
R0 = [R3 + 0]L
R1 = R0 << 11
R0 ^= R1
' x = y
R1 = [R3 + 1]L
[R3 + 0]L = R1
' y = z
R1 = [R3 + 2]L
[R3 + 1]L = R1
' z = w
R1 = [R3 + 3]L
[R3 + 2]L = R1
1番目~3番目の値は、全て同じ Rd = [Rn + u5]L
命令を用いて読み込み、[Rn + u5]L = Rd
命令を用いて書き込んでいます。
とりあえず、読み込みが上手くいっていないのか書き込みが上手くいっていないのか切り分けたいです。
そこで、まずは読み込みをうまくいっている1番目のものにしてみます。
すなわち、
' z = w
R1 = [R3 + 3]L
[R3 + 2]L = R1
を
' z = w
R1 = [R3 + 1]L
[R3 + 2]L = R1
にします。なお、[R3 + 1]L
は2番目の値の処理で書き換え済みであり、新しい値になるはずです。
10 'Xorshift
20 POKE#700,#3F,#A3,#18,#68,#C1,#02,#48,#40
30 POKE#708,#59,#68,#19,#60,#99,#68,#59,#60
40 POKE#710,#59,#68,#99,#60,#D9,#68,#CA,#0C
50 POKE#718,#51,#40,#02,#0A,#48,#40,#50,#40
60 POKE#720,#D8,#60,#7F,#21,#09,#02,#FF,#31
70 POKE#728,#08,#40,#70,#47
80 POKE#800,#15,#CD,#5B,#07,#E5,#55,#9A,#15
90 POKE#808,#B5,#3B,#12,#1F,#33,#13,#49,#05
100 PRINT[0],[1],[2],[3],[4],[5],[6],[7]
110 PRINT USR(#700,0)
120 PRINT[0],[1],[2],[3],[4],[5],[6],[7]
実行結果は
-13035 1883 21989 5530 15285 7954 4915 1353
21989 5530 21989 5530 28199 -14600 4915 1353
あれ?3番目の値として書き込む値を変えたはずなのに、2番目の値が書き換わっています。
4番目の値が書き換わらないことも考えると…そもそも処理を行う位置全体がずれているかもしれません。
処理を行う位置がずれている…?
このマシン語のプログラムは #700
に配置し、R3 = PC + #40
で配列の先頭 #800
のアドレスを取得する仕組みになっています。
きちんと取得できているか、確認してみましょう。
最近のバージョンでは、R1
にRAMの#000
相当のアドレスが渡されるので、このR3
からR1
を引けば#800
になるはずです。
確かめてみましょう。
R3 = PC + #40
R0 = R3 - R1
RET
これをBASICに組み込みます。
10 POKE#700,#3F,#A3,#58,#1A
20 POKE#704,#70,#47
30 ?HEX$(USR(#700,0))
実行します。
あれれ…?4足りません。
実機でも実行してみます。
予想通り800
と出力されました。
したがって、IchigoJam webのRd = PC + u8
命令には、
格納される値が本来のものより4少なくなるバグがあることがわかりました。
workaround
バグがわかったので、回避方法を考えます。
PC
に頼らずR1
からRAMのアドレスを得る方法もありますが、これはIchigoJam 1.0.0では使えません。
そこで、プログラム中のアドレスを取得してメモリを読み込み、正しい値が読み込めているかで判定します。
具体的には、R3 = PC + #40
のかわりに以下のプログラムを用います。
' プログラムの先頭から4バイト先のアドレスを取得
R3 = PC + 1
' 取得したアドレス+1のデータを読んでみる
R1 = [R3 + 1]
' IchigoJam webのバグにより、
' (4バイト先ではなく)プログラムの先頭のアドレスになっているかもしれない
R1 - #A3
IF 0 GOTO @BUGGY
' 4バイト先になっていれば、4を引いて先頭のアドレスにする
' (バグの影響を回避してアドレスを統一する)
R3 = R3 - 4
@BUGGY
' 得られたプログラムの先頭のアドレスに #100 を足して、配列の先頭のアドレスを得る
R3 += #80
R3 += #80
BASICに組み込みます。
10 'Xorshift
20 POKE#700,#00,#A3,#59,#78,#A3,#29,#00,#D0
30 POKE#708,#1B,#1F,#80,#33,#80,#33,#18,#68
40 POKE#710,#C1,#02,#48,#40,#59,#68,#19,#60
50 POKE#718,#99,#68,#59,#60,#D9,#68,#99,#60
60 POKE#720,#D9,#68,#CA,#0C,#51,#40,#02,#0A
70 POKE#728,#48,#40,#50,#40,#D8,#60,#7F,#21
80 POKE#730,#09,#02,#FF,#31,#08,#40,#70,#47
90 POKE#800,#15,#CD,#5B,#07,#E5,#55,#9A,#15
100 POKE#808,#B5,#3B,#12,#1F,#33,#13,#49,#05
110 FOR I=1 TO 20
120 PRINT USR(#700,0)
130 NEXT
実行します。
無事、IchigoJam webでも正しいXorshiftの値を得ることができました。
また、実行結果は省略しますが、実機でも正しいXorshiftの値を得ることができました。
結論
IchigoJam web でマシン語を使ったXorshiftの値が正しく求まらなかった原因は、
Rd = PC + u8
命令のバグにより状態を格納しているとみなすアドレスが意図したものより4バイト手前にずれ、
意図と違う状態に初期化されてしまったことだということがわかりました。
プログラム中のアドレスを指定し、読み取った値を見てアドレスが正しいかを判定することで、
このバグの影響を回避し、実機とIchigoJam webの両方で正しいXorshiftの値を求めることができました。
しかし、今回はこれで正しい値が求まりましたが、IchigoJam webのバグはこれだけとは限りません。
またいつか新しいバグを踏んだら、また解析することになるかもしれないですね…
Author And Source
この問題について(IchigoJam web のマシン語の実行のバグの解析), 我々は、より多くの情報をここで見つけました https://qiita.com/mikecat_mixc/items/125e065e3c81aa61e4a2著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .