ビッグエンディアン対応

[jg1uaa]

ビッグエンディアンのマシンでIchigoJam-BASICを動かすケースがどの程度あるかはわからないのですが（秋月電子のH8ボードで動かしたいという需要はあるかも）…コードをざっと見るに、以下の部分で非互換が発生しそうです。

1. POKE/PEEK文における、VAR領域に格納される変数および（非公開？）I2C領域に格納される値
2. LIST領域における、行番号の値

1.についてはBASICプログラムの非互換が、2.については例えばEEPROMカートリッジのエミュレーションを行いそのROMイメージをやり取りするような場合に支障が起こるのではないかと想定します。

[taisukef]

ビッグエンディアン環境でもIchigoJam BASIC仮想マシン的にはリトルエンディアンにする形で対応する感じがいいですね

[jg1uaa]

変数に関してはvarへの格納/読み出しの際にリトルエンディアンならそのまま、ビッグエンディアンならバイトオーダーを変えて格納、で良さそうに思われます。

BASICリストに含まれる行番号なのですが、basic.hにあるBASICリストの格納形式とプログラムの構造を見るに、

// {
//         int16 linenum;                  行番号 1-32767  行番号=0 プログラムの末尾、末尾も兼ねる
//         uint8 n;                                ステートメントのバイト数 0-254 // 必ず 2の倍数
//         char statement[n];              ステートメント
//         (char dummy)                    for 2 byte align
//         uint8 termination = 0;  end flg
// }*

(char dummy)…これによりlinenumが必ず2byte境界になるようsetLength(), basic_execute()で調整されています。
これ、linenumのアクセスを必ず8bit単位で行うようにして（これと併せてエンディアン変換も行います）、この調整部分を取り払うというアイデアはどうなのでしょうか？

問題としては

• EEPROMに保存された旧形式（と便宜上書きます）のコードはそのまま持ってくることができる反面、新形式で保存したEEPROMを旧形式のみ理解するIchigoJamには持っていけない
• BASICプログラムの作りによっては、新形式への対応が必要(?)

があるのではないかと想定します。

[jg1uaa]

（出先なので簡単に）この問題は以前PRに出したALLOW_UNALIGNED_ACCESS(#15)に関する問題の解決もできる反面、setLength()などはS_INLINE付きだったと記憶しているので、LPC1114向けのバイナリサイズの変化も勘案して検討する必要がありますね。

[jg1uaa]

basic.hを

S_INLINE list_getNumber(uint16 index) {
	uint8 *n = (uint8*)list + index;
	return n[0] | (n[1] << 8);
}
S_INLINE uint8 list_getLength(uint16 index) {
	return *(uint8*)(list + index + 2);
}
S_INLINE void list_setNumber(uint16 index, int16 num) {
	uint8 *n = (uint8*)list + index;
	n[0] = num;
	n[1] = num >> 8;
}

この部分だけ改造してARMv6-M向けにビルドしてみましたが、

-rwxr-xr-x 1 uaa uaa 39056  4月 17 22:10 IchigoJam_BASIC
-rwxr-xr-x 1 uaa uaa 38964  4月 17 22:05 IchigoJam_BASIC.orig

バイナリサイズは若干増加するようです。

#15は#15で、こちらはこちらで解決していくしかなさそうです。また、2byte alignするための(char dummy)によるpaddingを取り払うのも、影響が大きいので現状のままの方が良いと判断しました。