Improve get_metrics.py

[PhilippvK]

I have implemented what was beeing discussed in #68 in addition with further smaller improvements to the get_metrics.py script.

I had to add the argparse package as a requirement to be able to use optional command line parameters. This should hopefully not break too many existing setups...

For parsing the INI containing the memory layout, I have used the following as a reference. Can I expect that there are always 2 memory segments, the first being for ROM and the other one for RAM? If not, then I am not sure how to find out which one is which...

$ cat memsegs.ini
# [IntConfigurations]
# simple_mem_system.memseg_origin_00=0x0
# simple_mem_system.memseg_length_00=0x100000
# simple_mem_system.memseg_origin_01=0x100000
# simple_mem_system.memseg_length_01=0x5000000 

BTW: heapStart is unfortunately still relying on the symbol table.

[PhilippvK]

@rafzi It would be great if you could test this together with the corresponding MR in the ml_on_mcu repository before merging.

Also feel free to suggest any other approaches @wysiwyng.

[PhilippvK]

I added this to be able to run the get_metrics.py script without a trace file, so just getting the ROM usage metrics from the ELF file. Is it fine implemented like (if the trace file is not found) this or should I throw an error is this is the case and eventually add an command line flag --skip-trace to disable tracing mode?

[PhilippvK]

Also, it would probably be useful to (optionally) write the parsed/traced memory stats into a CSV file instead of just printing it to the terminal, as this would get rid of the need to parse the command line output for evaluating benchmarks...

[rafzi]

this is fine for me.

yes, i agree. we could directly output a machine readable format here.

[rafzi]

I have tested this in the full flow and it is working as expected, thanks! Just a small comment, then this is good to merge.

The memsegs could theoretically be used more flexibly, but I don't see a use-case for this in the near future. We would then also want the access permissions of the segments in that ini file, which would tell us whether the segment could be placed in ROM or RAM. But then again, this would require some guess-work to figure out where the stack is.

For the heap, we could track all memory accesses outside of known sections (except stack space) and classify them as heap area. But I'd say the current compromise is fine.

[rafzi]

these should use the same default as the example in the etiss repo, so 0x80000 and 0x80000

[rafzi]

dead code

[rafzi]

this is fine for me.

yes, i agree. we could directly output a machine readable format here.

[wysiwyng]

A quick thought on the memory segments: Currently there should only be 2 of them for most (if not all) applications, but this might not be the case for some special project. You could use the ELF entry point and check in which segment this falls and assume this is ROM. With our linker scripts at least the stack begin is also defined as a symbol in the ELF file, whatever this segment falls into is most likely RAM.

Also like @rafzi said, the access permissions give hints on the type of memory, these are also best read directly from the ELF file. simple_mem_system already supports specifying access attributes for memory segments, see #61. If they are not specified in the .ini files simple_mem_system reads them from the ELF file.

[PhilippvK]

@rafzi I will resolve your comments later, thank you for the review.

@wysiwyng You have mentioned some good points! Would you mind if I implement the determination of the memory segments in a later PR? I would really like to implement it but currently I can not invest too much time in contributing to ETISS as I have to finish by master thesis first.