日記帳だ! with Tux on Libserver

古いマイコンで使っていたプログラムを移植するに当たって、

バイトオーダーをどうすればいいんだろうという話をしていた。

新しいマイコンはバイトオーダーが変わるのは確定していて、

外部とのインターフェースは従来のバイトオーダーであるというのも決まっている。

どこでバイトオーダーを切り替えるかという問題である。

というのもマイコンにつながるバス部分はある程度自由度があるからである。

バイトオーダーというと2バイト以上の数値をメモリ上にどう並べるかという話である。

0x1234という数値をメモリ上に{12 34}と並べるのがビッグエンディアン、

{34 12}と下位ビットを含むバイトから順番に並べるのがリトルエンディアンである。

リトルエンディアンの方が処理性能を出しやすいとか見たことがある。

人間が足し算・引き算・かけ算をやるときも下の桁から順番に計算するように、

コンピュータにとってもLSBから順番に計算する方が好都合なのだ。

一方でネットワーク上を流れるデータというのはビッグエンディアンが多いらしい。

例えばデータ長が0x1230というのを伝達するために{12 30}と送信して、

受信した側は届いた順番にメモリに格納してそのデータを4byteの整数として解釈すると、

ビッグエンディアンのシステムでは0x1230と解釈できるが、

リトルエンディアンのシステムでは0x3012となってしまうのでこれではいけないと。

なので実際には読み出し後にビット順を入れ換えたり(ex. 0x3012→0x1234)

メモリの順番を入れ換えてから読んだり(ex. {12 30}→{30 12}と入れ換えてからリードすると0x1230)、

そういう変換処理を挟まなければいけなくなるわけである。

とはいえ、外部とのやりとりでも、そういう変換が必ずしも必要とも言えないところはある。

例えば、バスに接続されるペリフェラルの内部レジスタへのアクセス、

32bit幅のバスで、必ず4byteアクセスするという約束もあるので、

レジスタに0x80000000をライトすれば、レジスタのMSBがセットされる。

こういう作りにする方が自然ではないかと思う。

問題が起きやすいのは、データの順番が決まっている場合と、メモリを共有する場合ではないかと思う。

データの順番が決まっているというのは冒頭に書いた例の通りである。

届いた順に前から書く、前に書いてあるデータから順番に送るというのは、そうならざるを得ない。

メモリを共有する場合も、ビックエンディアンのシステムで0x12345678を書いて、

リトルエンディアンのシステムで読めば0x78563412となるのは当然である。

ただ、回避策がないとも言えないところはある。

データの順番が決まっている場合、後ろから書く、後ろから送るという方法が

バイトオーダーの雑記 (へっぽこ実験室)

Intelはメモリ構造を図示するときに、右下を最下位アドレスとして、

右から左にバイトを並べて、上の行に進んでいくという書き方をしているらしい。

この方法でメモリダンプを表示するとあまり違和感なく読めますねとある。

このようにアドレスを減らす方向に使って行くという考えは1つある。

メモリを共有する場合も必ず32bit幅でアクセスするとか約束して、

結線時に入れ換えておけばそれはそれでうまくいきそうな気がする。

共有メモリの実データはビックエンディアンで格納されていて、

必ず4byte単位でリード/ライトして32bit幅のバスとやりとりする。

共有メモリ上に{12 34 56 78}と並んでいれば、エンディアンによらず必ず0x12345678と読める形にすると。

4byte単位でしかデータを使わないならば、これで全く問題ない。

ただ、このデータを1byte単位で使いたいとなれば面倒である。

ローカルのRAM上にデータを転写して操作する必要があるが、

ビックエンディアンのシステムでは{12 34 56 78}と共有メモリと同じ順に並ぶ一方、

リトルエンディアンのシステムでは{78 56 34 12}と共有メモリとは異なる並びになる。

読み出したデータを0x12345678→0x78563412と入れ換えて格納すれば、

{12 34 56 78}と共有メモリと同じ順番で格納することはできる。

これを書きながらいろいろ考えていたけど……

うまくやればバイトオーダーを入れ換える操作を意図して書くべき場所は減らせそうな気がした。

ちょっと実験してみないとわからないところはあるんだけど。

メモリ上のデータの取扱単位を4byte単位に揃えることが出来れば、

バイトオーダーの入れ替えを意図的にあれこれする場面は減りそうな気がした。

実際に並ぶデータの順番を意識してやらないといけないところはそこを考えて作る必要はあるが。

あとはメモリダンプみたいに何らか取得できればよいというものもありますからね。

読む側で解釈すればよいからという理屈である。

ここのところ、アセンブラを書くことがけっこうある。

以前、実験用に使っていた無償提供されている開発環境から、

実際の製品に使う開発環境、これは有償で買ったのだが、

この乗換のときにアセンブラの方言の差がかなり大きくて全書換ぐらいになってしまった。

Cのコードもいろいろ書換はあったけど、こちらは限定的である。

その中で以前紹介した1bとか2fのようなラベル表記ができなくなった。

ちなみに bne命令の分岐先1bというのは上にあるラベル1という意味らしい。

逆に下にあるラベル2は2fと書ける。そういうアセンブラの記法があると。

(予約してメモリを書き換える)

こういうのも方言なんですね。

マニュアルを見たのだが、少し表記を変えれば済むというわけではなく、

数字のラベルはすべて名前を付け直すこととなってしまった。

で、アセンブラにはマクロというのがあって、

繰り返し使う命令の並びをあらかじめ書いておくことをやっている。

元々、マクロ内でも数字のラベルが多用されていたのだが、

使えなくなったらまともにラベルを振らないといけない。

それでラベルを振ったらラベルが重複するというエラーが出てくる。

で、こういうのはどうやったら回避できるのかとマニュアルを見たら、

マクロの定義の中でローカルのラベルであることを規定すればよいと。

.macro CHECK_AND_STORE
     local store1, store2, hang, exit
     teq   r0, #1
     beq   store1
     teq   r0, #2
     beq   store2
hang:
     b     hang
store1:
     str   #1, [r1]
     b     exit
store2:
     str   #2, [r1]
exit:
.endm

exitとかいうラベルを使うことはけっこう多い気がするけど、

localと書いておけば、マクロを実体化したときに重複しないように処理してくれる。

アセンブラも書いてある順番に命令並べるだけじゃないんですよね。

疑似命令というのもあって、実際には存在しない命令を書けることがある。

ARMだとビットシフトの命令がそうで、MOV命令にビットシフトを付加したものとして処理されたりする。

それはそういう別名みたいなものですけど。

実際に使われる命令を意識して書かれたものもありますけどね。

アドレスをロードするとか、1命令で書けない場合に複数命令に展開したり、

そういう疑似命令もある。1行1命令とは限らないと。

アセンブラを使って記述する理由というのは、

命令の並び順を厳密に決める必要があるというのが理由のほとんどではないか。

割り込みハンドラのレジスタ退避なんていうのはまさにそういう話で、

正しい順番でやらないと割り込み前の状態を保存できなくなってしまう。

スタックを使わないで処理するのもアセンブラで書けば確実である。

そういう用事が済んでしまえばCのコードにジャンプさせてしまう。

今回の開発プロジェクトでアセンブラで書く部分って僕が全部書きそうだけど、

これを見てレビューできる人って他のメンバーにいるのかなというのは気になる。

機械語の挙動を把握してレビューしないといけないわけだからね。

そういう意味でも用事が済んだら早々Cのコードに飛ばすのは重要で、

そうしておけばCのコードは多くの人が平易に理解できるし、

コンパイラはそれを正しく機械語に落とすことが出来るはず。

それでも残るアセンブラ部は極小といいたいところだけど、数行というわけにはいかない。

あと別の話として、既存のシステムのアセンブラで書かれたコードを解読しないといけない話がある。

「これ設計資料あるの?」と聞いたら「ないでしょう」とのことで、

ああやっぱりリバースエンジニアリングかと。

元はアセンブラだけど、書き直すときはCで書いてよいところのはず。

元々のシステムだといろいろ初期化されるまでなのでアセンブラだが、

今回は手順が違うので、Cのコードで書ける部分になるはず。

それはちょっと救いだな。

以前、wfi命令で割り込みを待つときには割り込みマスクをする話を書いた。

wfi命令で割り込みを待つ意味

フラグがなければwfi命令で割り込み待ちする場合、

フラグがないことを確認した後に割り込みが発生してフラグが立ったらうまくいかないので、

割り込みマスク→フラグ確認→wfi命令→割り込みマスク解除 の順番でやらないといかんねという話である。

で、本当にそうなるんかいとICEでブレークポイントを置いて実験をしてみた。

そしたら、確かに割り込み処理の復帰先がwfi命令の場所になってしまい、

さらにその次の割り込みが来るまで待たされるケースがあることが確認できた。

というわけで、ちゃんと割り込みマスクしてwfi命令しないといけませんねと。

ただ、割り込みの復帰先を書き換えてやれば問題は回避できるんだなと。

1. 休止状態のフラグを立てる
2. 処理するべきフラグが立っていたら休止状態のフラグを消して処理に遷移する
3. 何もフラグがなければwfi命令を実行して休止する
4. 割り込みハンドラで1.のフラグを確認し、休止状態の場合は割り込みの復帰先を2.にする

こんなことをやれば割り込みマスクをしなくても正しく動くはず。

何でこんな話を書いたのかというと、ある種の割り込みをマスクする期間を作りたくないという話があって、

割り込み処理の仕様上、最低限のレジスタ退避の間だけはマスクせざるを得ないが、

それ以外は可能な限り割り込みマスクせずにやりたいねと。

でも、wfi命令って割り込みマスクしないと正しく使えないよね、

と気になって、上のようなことを試して気づいたわけである。

ただ、実際のシステムでこういうプログラムを書くのかというと、

それはよくわからないんだけど。休止でwfi命令を使わない可能性もある。

(元々そういう処理をしてなかったし、電力的にシビアなシステムではない)

ベクタテーブルというと、割り込みのジャンプ先のアドレスを格納するものだと思っていたが、

割り込みでジャンプする命令が並ぶタイプのものもあるらしい。

というのがARMのCortex-M以外のベクタテーブルなんですけどね。

Exception vectors and the exception base address (ARM)

例えばVBARレジスタの値がベースアドレスで、IRQ割り込みの場合は、

IRQのオフセットが0x18なので PC←VBAR+0x18 にジャンプすると。

(このとき、割り込み前のPCなど復帰に必要な情報は別のレジスタに保存する)

ただ、ジャンプ先のアドレスは4byte間隔で並んでいるわけで、テーブルに置ける命令は1個だけ。

なので、ここに置くのはジャンプ命令というのが通例である。

ジャンプ先が近い場合は命令1個でジャンプできるのでよい。

(例えばA32のB命令の場合、PC(プログラムカウンタ)から±32MB の範囲でジャンプできる)

ただ、遠い場合はそうもいかないわけですよね。

実際のところ、ARMではベクタテーブルの後ろにジャンプ先のアドレスを並べているケースが多いようだ。

これを参照してジャンプする命令を並べる形である。

ベクタテーブルの前後32MBの範囲に割り込みハンドラがあればその必要はないのだが。

それならアドレスを並べたテーブルから割り込みハンドラのアドレスを得るところまで自動でやってほしいものだが、

PCをセットするだけなら割り込み処理が高速化できるケースもあるので、こうしているのでは?

ベクタテーブルの後ろに並べたアドレスにジャンプするというのは、

PCからの相対アドレスで指定したメモリ上のデータをPCに格納するという形で書ける。

LDR PC,=IRQHandler

という形でアセンブラで書くのだが、実際には

0x0018: MOV PC,[PC,#0x20]
0x0038: DCD IRQHandler

というような形でデータが生成されるようだ。

これを1命令で書けるのはARMらしいのかもしれない。

ARMならそれでいいんですけどね。

PCの値を振り分けるというのはプロセッサ内部で済む話だが、

PCの値を外部のメモリから取得した値にするのは確かに複雑で、

そこはユーザーが書くコードでなんとかしてよというのは理由はあると思った。

でも、あんまり嬉しくない作りだよなとも思う。