をアセンブル・リンクしMOT形式までもっていきます。$(CCOPT)は通常使っているものを そのまま指定してください(呼び出し側と一致しないとまずいオプションがあります)。 gccで自前で書いたmyfunc.oをROM化したい場合はここで追加するとよいでしょう。 Makefile の一部を示します。
superROM.mot: superROM.exe h8300-hms-objcopy -O srec superROM.exe superROM.mot superROM.exe: superROM.o $(LDS2) h8300-hms-gcc $(CCOPT) -nostartfiles -T $(LDS2) superROM.o -o superROM.exe h8300-hms-objdump -t superROM.exe > objectdump.txt superROM.o: superROM.s h8300-hms-gcc $(CCOPT) -c superROM.sリンカスクリプト(上記の例では$(LDS2)マクロ)はこんな感じです。( ENTRY("_main")ははずしました)
OUTPUT_FORMAT("coff-h8300")
OUTPUT_ARCH(h8300h)
MEMORY {
rom(rx) : o = 0x20000, l = 0x20000
ram(rwx) : o = 0xffdf10, l = 0x02000
}
SECTIONS {
.text : { } > rom
.data : { } > rom
.rodata : { } > rom
.bss : { } > ram
}
実際の割付の様子を必ずobjdumpで確認してください。実際にはobjdumpの結果を見ながら
↑のリンカスクリプトをいじることになるでしょう。純正モニタ
の割付を変更してリビルドした方がスムーズに収まる場合もあるでしょう。
(ウチでも最新版はちょっと変えています…スタックをちょっと若い側にずらし、その後ろに
gccライブラリ用ワークを持ってきました)
bash>h8300-hms-objdump -h superROM.exe superROM.exe: file format coff-h8300 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0000c70a 00020000 00020000 000000f8 2**1 CONTENTS, ALLOC, LOAD, CODE 1 .data 000006ca 0002c70a 0002c70a 0000c802 2**1 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0000000e 00ffdf10 00ffdf10 00000000 2**1 ALLOC 3 .vectors 00000000 0002e06e 0002e06e 00000000 2**1 ALLOC, LOAD, READONLY 4 .rodata 0000129a 0002cdd4 0002cdd4 0000cecc 2**1 CONTENTS, ALLOC, LOAD, CODE
ようはあたらなければどこでもOKということですね。(※後注：.dataセクションの話)
あとは別個に用意した純正モニタ(monitor.MOT)とまとめてROMに焼けばOKです。 ２本のMOTが焼きにくい場合は 別ページのawkスクリプトで１本にまとめれば簡単です。
呼び出し側…上記Makefileであればobjectdump.txtができてますから、その中から
[1791](sec 1)(fl 0x00)(ty 24)(scl 2) (nx 1) 0x0002046a _sprintf
となっている行を探します。0x0002046aからに焼かれているのがわかりますので、
#define sprintf ((int (*)(char *,const char *,...))0x02046a)
とマクロ定義すれば通常のsprintf()関数と同様に呼べます。もちろんこの場合stdio.hは
取り込まないか、#undefしてから再定義してください。また、このアドレス取り出しを自動的に行うことも…できるでしょう。トラ技版の方を 参考にしてください。⇒後述。「ROM内アドレスの自動取り出し云々」
注意！…手抜きして.dataセクションをそのままROMに焼いています。 int n=0x1234;で確保した変数はn=0x2345;としても0x1234のまま変化しません。当然動かない関数 がでてくるはずです。静的変数がインチキなわけですから、目安としては「呼ぶたびに違う結果が返って 来る関数」が危ない と言えます。現実rand()が毎回同じ戻り値を返すのを確認していますし、 他にもあるでしょう。トラ技Cのrand()では、静的変数seedをbssに 取り、srand()で設定しない限り不定、となっていると思われます
[追加.03/OCT/29]いやな予感はしていたのですが…某mon4.c で利用しているstrtok()が.dataセクションをRAMと思っているようで、この インチキROM化では動きません。 mon4.c用にはウルトラサブセット版StrtoK()を用意しました。
ほとんど再収録になりますが
gcc添付FILE系関数…はまったくわかっていません。試しにfputs()を 含む関数をコンパイルすると、トラ技版( こちらでごにょごにょ やってます)では「write()となんとかがみつからない」→「write()を 必要なだけ書いてリンクすればいいのか」と見当ついたのですが、 gccではすっきりコンパイルできてしまいます。動くはずもなく、 ちと次の手が思い浮かびません。
ずっとVer2.95.3[追加.03/NOV/06]…の話ですが、 他のCPU用gccVer3.2.2で試したところ、 .importでは関数そのものをひっぱってくれずうまくいきませんでした。また.globalでは 内部参照の解決が不十分なままa.out⇒Sレコード化されてしまいました。 .longとしてポインタテーブルのインスタンスを作ってうまくいっている ようです。H8/300H用Ver3.2.2を持っていないのでなんとも言えませんが。
ROM内アドレスの自動取り出しawkスクリプト[追加.03/OCT/20]… をここに置きました。 別ページのmon4.cによる シンボリックデバッグ用シンボル情報も抜けます。 よろしければどうぞ。
bash>h8300-hms-objdump -t superROM.exe | gawk -f symPickG.awk > spROMsym.s
bash>h8300-hms-gcc $(CCOPT) -c spROMsym.s
bash>h8300-hms-ar r /usr/local/h8300-hms/lib/h8300h/libspROMsym.a spROMsym.o
- RAM側プログラムにspROMsym.oをリンクすれば特に意識することなくROM内の関数を 呼べます。この場合、呼び出し側には標準のプロトタイプ宣言をincludeしてください。
- また３行目の作業をしておけば、RAM側プログラムのリンク時に-lspROMsym を指定することでも実現可能です。(intが32ビットだと違うディレクトリかも)
sprintf()が焼けたところで[追加.03/OCT/20]… printf()に近いzprintf()です。
- 内部的にごにょごにょしてsprintf()を呼び出し、さらに一行出力ルーチン を呼んだ後もどります。
- sprintf()に渡すchar zprintfBuf[]のサイズや確保の仕方など は適宜調整してください。(やけに.bssを広く取られているような… よくわかってません^^;)
- printf()もsprintf()もint型ですが、zprintf()はsprintf()に渡したバッファへのポインタ を返しています。戻り値を利用しないのであれば、マクロでzprintf⇒printf置換 してもいいでしょう。
- 一行出力ルーチンとして、ウチではROMに_OUT_STRING() (の話はこちら) があったのでそのまま流用しました。独自のputs(char *)互換を呼んでいただいても もちろんOKです。
- zprintf()(つまり_OUT_STRING())はそのままSCI1へ送り出します(hterm.exe相手なら改行は"\r\n")が、 "\n"を内部的に"\r\n"に変換して送出するzzprintf()を追加しました。 [追加.03/OCT/29]
- 呼び出し側ではプロトタイプ宣言をお忘れなく
へもどる