そこでちらりと浮かんだのがTiny対応である。

HOSに関わることになった、そのきっかけ。H8/3664をターゲットとする、gcc開発環境によるHOS-V3ビルドの試み。…しかし、h8300-hms-gccは、ノーマルモードに 対応していなかった。("追記 2001/2/11"の部分参照)

後に4個目以降の引数の問題は、H8 Users MLに投稿されたパッチで解決した訳だが、 それ以外の、アドレスが32(24)bitで扱われてしまう点は残っている。

勿論、4個目以降の引数問題さえクリアしていれば、動作上の支障はない。 だが、本来16bitで済むことを、メモリを食って、時間をかけてやっているという 事を思うと、貧乏性がうずかずにはいられないのだ。また、日立のコンパイラが当 然に300Hのノーマルモードに対応しているという意味でも、もう少しどうにか したいではないか。

そこで今度はほんの少し頑張って、-mnオプションに対して

• @0xffXXは@0xffXX:8に
• :8にならない@_labelは@_label:16に
• @(disp,erX)は@(disp:16,erX)に
• スタックフレームはer6ではなくr6
• __NORMAL_MODE__を定義する

http://h8300-hms.sourceforge.net/ で公開されている http://prdownloads.sourceforge.net/h8300-hms/h8300-hms-gcc-3.1-1.patchと、 H8 Users MLに投稿されたパッチを含んだ、gcc-3.2.1への差分がh8300-hms-gcc-3.2.1+mn.diff.bz2である。

追記(2003/03/28)

↑のパッチには、自動変数領域へのオフセットを誤るという致命的なバグが含 まれていた。それを修正したのが、h8300-hms-gcc-3.2.1+mn_2.diff.bz2 である。インストーラは既にこれを適用した1.2版に差し替えた

追記(2003/03/30)

この修正に関しては、メモ７の追記にまとめて 書いてある。

こうした結果をHOS-V4のsampleで比較すると、

text data bss dec hex filename 4782 44 780 5606 15e6 h83n.0/sample.coff

2.95.2で"4個目パッチ"のみ

text data bss dec hex filename 4362 44 780 5186 1442 h83n/sample.coff

3.2.1で今回の改造

本来なら、完全同一バージョンで比較したいところだが…マシンは遅いし、面 倒なので省略。大差はないだろう。

それにしても、僅かとはいえ、出力オブジェクトは小さく速くなった筈なので、 これで良しとしておこう！ (新たな問題を引き起こしていなければ、の話だが…)

追記(2003/04/02)

GCCは、3.3からノーマルモード対応になる。

bisonの問題か、MinGWでは少してこずったが、20030331のスナップショットは 一応出来た。4個目以降の引数問題は勿論、正しくポインタサイズは2byteだし それに関するロードや演算もワードサイズになっているようだ。

当然、デバッグもより広く行なわれ、完成度も上がるだろう。これはもう、 ちまちまパッチを当てている場合ではない。3664を使うならば、だが。

追記(2003/05/21)

GCC 3.3がリリースされた。手元では良い感じなのだが、某所の某インベーダー ではうまくないらしい…困ったことだ。どこでどうなっているのやら全く 分からないので、対処のしようもないのだが。

取り敢えず16日に置いた初版はそのままだったが、@labelな絶対アドレスと、 @(disp,er?)なディスプレースメント付きレジスタ間接を-mnで:16にするよう 手を入れたものに差し替えた。差分はh8300-gcc-3.3+idrect_disp_16.diff.bz2。

大した差はないが、サンプルで比較すると次のようになる。

text data bss dec hex filename 3640 16 754 4410 113a sample.3.3.coff 3458 16 754 4228 1084 sample.3.3.i16.coff

この辺りに関しては、どうやらbinutilsなんかで対応がされつつあるようなの で、じきにそのままでOKになるだろう。

この項終り