Added script to visualize memory usage after compilation

[JuanSapriza]

@davideschiavone this is intended to be used to check the progression of the code miniaturization for HEEPidermis
I am requesting to merge into develop

$ make mcu-gen MEMORY_BANKS=3 MEMORY_BANKS_IL=2 BUS=NtoM
$ make app PROJECT=example_something

. . . 
Invoking: Disassemble
Invoking: Hexdump
Invoking: SREC Hexdump
Invoking: Binary dump
make[4]: Leaving directory '/home/juan/Desktop/ESL/0_x-heep/sw/build'
[100%] Built target main.elf
make[3]: Leaving directory '/home/juan/Desktop/ESL/0_x-heep/sw/build'
make[2]: Leaving directory '/home/juan/Desktop/ESL/0_x-heep/sw/build'
make[1]: Leaving directory '/home/juan/Desktop/ESL/0_x-heep/sw'


Total space: 160.0 kB = 3x32 kB + Interleaved 2 x32 kB
Region 	 Start 	End	Size(kB)	Used(kB)	Utilz(%) 
Code:  	  0.0	 58.0	 58.0		38.0		65.5
Data:  	 58.0	 96.0	 38.0		8.1		21.4
ILdata:	 96.0	160.0	 64.0		12.0		18.8

C PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP 	100.0%
C PPPPPP-------------------ddddddd 	40.6%
C dd------------------------------ 	6.2%
I dddddd-------------------------- 	0.0%
I dddddd-------------------------- 	0.0%

[JuanSapriza]

For some reason the results in the CI are all wrong :/
Do not merge yet please

[JuanSapriza]

the same script locally runs properly

[davideschiavone]

Are you sure there is no already such tool that parse the elf ? I would be surprised

[JuanSapriza]

i parsed the map. I honestly thought it was going to be much simpler than it ended up being hahahaah but now that i understand how the .map format works i think its working very neatly. The advantage of the custom implementation are

1. I lost a day of work 👍
2. We can tune it as we want
3. there are a few "custom things in x-heep" that were probably a pain to tell to a tool

I didnt check actually, but now im using it to prune the code and is very convenient :)

[davidmallasen]

Could you add a few more lines of comments for our future reference? Especially at the beginning of the file to explain what it's about and the second half that is out of any function definition.

[JuanSapriza]

Could you add a few more lines of comments for our future reference? Especially at the beginning of the file to explain what it's about and the second half that is out of any function definition.

1000% agree. Added comments now, and also simplified a bit the functions.

Note: It is cool to see how much each application is using, you can check the building apps CI to take a look. Maybe we could later improve the CI to show how much the overall code has grown due to the changes introduced or something.

[JuanSapriza]

Found a bug when using flash load as linker..., will be working on this

[JuanSapriza]

ok, i was going crazy doing all the manual parsing. I tried using readelf, a tool that comes with binutils. I believe that we might all have it on our systems, could you please try? @davidmallasen @davideschiavone

Because the CI does not have it, and in the docker image there is no apt (if i remember properly), it is not possible to see it in the CI runner.

[davidmallasen]

I just tried the latest version of this PR and it is working for me for on_chip and flash_load. For flash_exec it outputs a not available message. Then, binutils and the readelf I have them available both locally and on the server, but worst case we can add a not available message if it's not found and/or add that package to the dependencies in the setup.

[JuanSapriza]

I just tried the latest version of this PR and it is working for me for on_chip and flash_load. For flash_exec it outputs a not available message. Then, binutils and the readelf I have them available both locally and on the server, but worst case we can add a not available message if it's not found and/or add that package to the dependencies in the setup.

i THINK that binutils is already a requirement somehow (like, its installed along some other requirements on XHEEP)..... i only dont know why its not available on the CI runner then

[davidmallasen]

The CI runner depends on the docker if I'm not mistaken, and we're changing that in #603. Maybe we could add the explicit reference there? @LuigiGiuffrida98