コンパイラやメモリダンプの出力形式がバイナリデータとも限らず、
Sフォーマット(モトローラ形式とも)だとか、Intel Hexだとか、そういう形式が使われることがある。
16進数のテキストで記載されているのだが、解読にはそれぞれの形式の特徴を知っていなければならない。
SフォーマットはSから始まるテキストでメモリデータを記述している。
S1130110DF107A02000FDF10690369930B800B81F3
こんなのがひたすら並んでいる。
最初のS1がレコードの種類、S1は16ビットアドレスのデータという意味だったはず。
13はレコード長、16進数の13なので、レコード長が19byteであることを表している。
0110が先頭アドレスで、DF……81がデータ、レコード長はアドレス+データの長さを表している。
最後のがチェックサムで、レコード長からチェックサムまで全て足すと0xFFになるように計算されている。
Intel Hex形式はこんなのがひたすら並んでいる。
:100130003F0156702B5E712B722B732146013421C7
10がバイトカウント、この行は16バイトのデータを格納することを表している。
次の0130がアドレス、00がレコードの種類でこのレコードはデータを格納していることを表していて、3F……21がデータ、
最後のC7がチェックサムで、バイトカウントからチェックサムを全て足すと0x00になるように計算されている。
というわけで、この2つのフォーマットの考え方はそう変わらない。
アドレスとデータをそれぞれ16進数で表したものをひたすら並べているということだ。
ただ、あまり直感的とは言いがたく、なんとなく解読できるというものではない。
種別・データ長・アドレス・データ・チェックサムが詰め詰めで書かれてますからね。
ROMライターの書き込みなどで使われるフォーマットだそうだが、職場で作っているシステムではバイナリデータでROMライターに入力している。
以前使っていたコンパイラでは、出力データがSフォーマットだったが、即バイナリデータへの変換を行っていた。
というわけで、現在、主に使っているコンパイラでは最初からバイナリデータで出力しているわけである。
そうやって考えると、やや汎用性の劣るSフォーマットやIntel Hexには何のメリットがあるんだろうとなる。
でも明確なメリットもあるんですよね。
セクション間に空白があるようなデータの場合、バイナリでは空白区間を埋めるデータが必要になる。
ところがSフォーマットやIntel Hexの場合、空白区間は書かなければよいだけである。
例えば0x00000000から64kB、0x20000000から16kBというデータを出力する場合、
バイナリデータの場合、ゼロデータで埋めてしまうから512MBにも及ぶ巨大データが生成されてしまう。
ところが、SフォーマットやIntel Hexの場合、64kBと16kBのデータを記載するだけでよい。
16進数のテキストデータなので、2倍以上のデータ量になるが、200kB程度のデータで済むだろう。
SフォーマットもIntel Hexもテキストデータですから、意味さえ理解できれば加工は容易である。
条件次第だが、中間形式としてはSフォーマットやIntel Hexは有益な気がする。
もちろん、ROMライターなどで最終的に必要なのが、これらの形式ならそれでいいんだけど。