Listing file size vs. on-chip size

[cjw]

Hi!

I was wondering (out of need and out of curiousity) what the relationship is between the size of the listing file (.s19) on my windows computer and the amount of RAM/ROM occupied on the M68HC912B32 chip. For example, I have a listing file that is 960 bytes according to Windows. Does this translate directly to 960 bytes on the chip? If not, is there a mathematical relationship or a rule of thumb?

Thanks,

Christian

[rocco]

Hi, Christian:

The ratio depends on the number of bytes that the linker puts on each line, but it is typically around 2.5 to one. In other words, your 960 byte .S19 file would contain approximately 380 to 400 bytes of code.

Note that data that exists in ram is not represented in the .S19 file, so there is no indication of the amount of ram used.

The linker typically puts 32 bytes of code in each line. All values are represented as hexadecimal, so each byte of code takes two characters. That means 64 bytes for code, and 11 bytes for overhead ("S1", count, address, checksum and carriage-return) add up to 75 characters for every 32 bytes of code.

Message Edited by rocco on 03-30-200605:38 PM

[bigmac]

Hello Rocco,

The overhead is actually slightly greater than you indicate.  For CW S19 files (.SZ), the first line seems to be an extra one containing ASCII path information in S19 format.  I presume this gets stripped during the programming process.

Regards,
Mac

[rocco]

Hi, Mac:

Yeah, I skipped the S0 record and the S9 record. Since most of my firmware is between 8k and 30k, those records don't have much impact.

But to be complete, the file usually starts with an S0 "header" line, which can be anything. CW usually puts a mangled version of the path to the .PRM file, but nothing I know of uses it. The Suite56 linker puts an empty S0 record, so that is 11 more bytes of overhead.

The S9 record at the end of the file simply defines the program start address. It's useful to the debugger, but it isn't used to program the flash. That's another 11 bytes.

[CrasyCat]

Hello

 Just some additional input on this one.

Yes CodeWarrior for HC(S)08 and CodeWarrior for HC(S)12 put the full path to the actual executable file in the S0 record.

You can disable generation of the path in the S0 record using burner option -Ns=p.
You can prevent generation of the S0 record using the burner option -Ns=0
You can prevent generation of the s9 record using the burner option -Ns=9.

For more details, check the description of the option -Ns in the Burner manual or on line help.

CrasyCat

[bigmac]

Hello CrasyCat,

As a matter of curiosity, is there a similar method of preventing the S0 record from occurring in the SZ file directly generated by the assembler (absolute assembly, no linking)?

Regards,
Mac

[CompilerGuru]

Hi Mac,
also out of curiosity, why do you need a SRecord file without S0?
To answer the question, the same method that does apply to linked application does also apply to applications generated directly by the assembler (-Fa2).
The reason is that not the assembler or the linker are (usually) generating the SRecord, but instead the burner.
You may have noticed that in crazycat's explanation the option was added to the burner preference.
The burner is automatically called whenever there is a *.bbl file in the project, regardless if the project is absolute assembly or is using the linker.

Message Edited by CompilerGuru on 04-01-200602:56 PM

[bigmac]

Hello Compiler Guru,

Thankyou for your response.

also out of curiosity, why do you need a SRecord file without S0?

The reason for my previous query is to maintain backward compatibility with S19 files generated by CASM08 - at the moment I am using both CW and P&E tools.  The output from CASM08 does not generate an S0 record, and I am not yet sure if the presence of one will upset PROG08 programmer.  Of course, I can always strip out the record by hand if it proves to be a problem.

Regards,
Mac

[cjw]

---

rocco wrote:
Hi, Christian:

The ratio depends on the number of bytes that the linker puts on each line, but it is typically around 2.5 to one. In other words, your 960 byte .S19 file would contain approximately 380 to 400 bytes of code.

Note that data that exists in ram is not represented in the .S19 file, so there is no indication of the amount of ram used.

The linker typically puts 32 bytes of code in each line. All values are represented as hexadecimal, so each byte of code takes two characters. That means 64 bytes for code, and 11 bytes for overhead ("S1", count, address, checksum and carriage-return) add up to 75 characters for every 32 bytes of code.

Message Edited by rocco on 03-30-200605:38 PM

---

Thanks for the detailed explanation. That makes sense, as I have yet to run out of memory but I only had 512 bytes available. I had a faulty board earlier that gave me issues, which I assumed was code stored in RAM running into the stack. However, on a newer board (same kind) the code had no issues at all.

Again, thank you.